@timb I couldn’t get any of my Digole displays to run on I2C. I wan’t using pull up resistors though. I tried to use 1k resistors but they didn’t work either, other resistors were recommended.
1K should be fine, that’s what I’m running. I’d have to see a picture of your wiring setup to make sure everything looks good. Just to make sure, you did solder the I2C jumper on the back of the display, correct?
I just ran one end of the resistors to 3.3v out on the Spark, and the other end of the resistors I ran to each of the I2C data lines.
The Digole backpack was in I2C mode, it was displaying it on the main screen. I2C would not work with the 3 different displays I purchased. I’m glad it didn’t because now I’m running SPI which is faster, I wouldn’t have tried it if the I2C was working.
Weird, clearly there was something wrong there because I2C has worked on all of my displays. Might have been a software thing. SPI is faster, but uses up more wires. I like I2C because I generally use other I2C devices, so I don’t lose any pins.
Glad it’s working in SPI mode at least!
timb, I’m using a generic 128x64 monchrome LCD with a Digole backpack on I2C without problems. Hiowever, the Spark is in dire need of your upgraded I2C code!
Has anyone connected both a Digole and a microSD on SPI together?
So I’m in touch with Victor from Digole. He’s now aware of and reading this thread! I’m getting some 
samples to him so he can do compatibility testing and iron out SPI issues at higher speeds.
@peekay123 are you using pull up resistors to get the I2C working?
Yes, he has to be. Anything on the I2C bus requires them (unless it has built-in pull-ups, which these don’t). I’ll make you a Fritzing Drawing. 
Yes I am… 4.7K on each line.
@peekay123 Thanks for the info. 1k Resistors didn’t work for me.
How about that example code that will show me how to use these bitmap codes that the Digole converter is creating for me?
RWB, for uploading fonts or drawing bitmaps? Which interface are you using… SPI?
I’m using SPI.
I want to be able to display the bitmaps I create in Corel Draw in 128x64 pixel format and then use the Digole Online Converter to turn that file into the code that is required to get that Bitmap to show up on the Digole LCD screen.
I’ll post the code when I get home in a few hours.
RWB, once you finish with your drawing, export it as png or jpg. If your drawing is in color, it may not export to b&w due to dithering if you are using a monochrome display. Take a look at your final file to make sure it looks the way you want in either b&w or color.
Go to the digole converter site and select the file on the LHS then select the “Used for” mode, likely the first three choices depending on which display you use, color or b&w. After you hit “submit” you will see the conversion in the lower window along with a preview of your image. You can then copy that code to your file in an array like this:
const uint8_t myBitmap[] ={ the digole data here };
Obviously, it will be longer than this. A full screen 128x64 monochrome bitmap takes 1024 bytes. A 256 color one takes 8KB and a 262K color one is too big.
Your program can then draw the full screen bitmap, for example, as follows:
mydisp.drawBitmap(0, 0, 128, 64, myBitmap);
Try and and let me know how it works!
Cool, I’ll give that a shot.
So I can create mutiple bitmaps and all I need todo is crate unique names different than myBitmap right?
Then when I want to call those bitmaps to be displayed I can just call the myBitmap or myBitmap2 ?
Also can these bitmap’s be stored in the Digoles backpacks flash memory also so the bitmap code does not have to be placed in the main loop sketch?
RWB, you got the idea! As for storing bitmaps, therein lies the rub. The Digole allows for storage of up to 4 fonts that must be in the u8glib font format. So these are not bitmaps per say. It is, however, possible to create “fonts” that achieve similar results, though not full screen of course. The Digole can allocate up to 16KB for a single font, if I understand correctly. So theoretically, you could have 512 32x32 monochrom “sprites” or “cells” defined and stored on the Digole. However, you are limited to the number of ASCII characters available which is 256. So two “fonts” would need to be used. Now, I just need to figure out how to create the fonts!
So when you say 4 fonts can be stored on the Digoles Flash do you mean each font would cover the whole A-Z and 1-9 number layouts?
RWB, that’s a great question. Looking at the stock u8glib fonts, I see that they go from 0x20 to 0xFF or 32-255. This is 223 characters. I am not sure if it is necessary to leave the first 32 character empty or not. So, that would mean you could access two 32x32 “fonts” of 223 characters each. Here is a tiny u8glib font for illustration:
I’m getting confused here
So are you saying that with the flash memory avaliable we could have 2 complete a-z letter fonts uploaded with each pixel having a dimension of 32 pixes by 32 pixels?
RWB, not A-Z, but more like 0x20 to 0xFF or 223 different characters. And each “character” would be 32x32 pixels. That means for a 128x64 display, it would be 2 characters wide by 4 characters high.
OR… you could use 16x16 pixel characters if 32x32 is too large.