Digole UART/I2C/SPI Display Library

Should be nice if someone could create a list of what librarys is working on Spark and what displays/hardware is used with the library.

@timb thanks for the info, its really helps me.

@peekay123 Yea the wires for the backlight are pretty short but there is a spot to solder the backlight wires to also if you watned to extend them alittle. I like the small backpack that comes with the 2.7 inch display, I’m not sure why you would want to go with the larger one you linked to?

RWB, it shinny and clear! No really, I found the smaller single color oled units broke easily and the larger one is robust. My favorite is the color oled.

RichardP, I use the combo I outlined above, 4D systems units (way more expensive) and the new Digole color OLED display. I also have the other digole mono LCD displays with their controller. :smile:

Anyone else getting random errors? I am doing some very fast updating of the display and sometimes text ends up on the wrong line and sometimes some chats are just plain wrong. I am guessing that these are artifacts of noise or something. FYI, I am using the digole color oled. The only solution thus far has been to do a lot of extra line cleaning and redrawing. Is this normal?

In the header section, try setting the SPI_CLOCK_DIV from 16 to 32 or 64. Let me know if this helps.

billprozac, I saw the same thing when I was writing the demo code for the digole_geometry library. When doing filled shapes or the pie shapes, the code uses line primitives. So a LOT of lines are being sent to the display, each with about 7 bytes of data. With no handshaking, I suspect the display buffer is over filling or the SPI handler is dropping data. I had to introduce 10ms delays in each loop of 50 random filled triangles, for example, for it to work flawlessly. This is not uncommon for zero handshake interfaces. Slow things down a bit and see what happens. :smile:

Oh ya, and what timb say also!

Well, I’ve got some bad news. All of a sudden my 1.8" Color OLED stopped recognizing the SPI and I2C interface selections. I can only get it to work with UART. I think I’m going to have to send it back. :frowning:

I still have my 1.3" White OLED so I’ll be able to finish up the work I was doing, but it’s just disappointing.

timb, could the centre pad/wire on the SPI/I2C selection jumper area be cut or damaged? That would make it impossible to select either SPI or I2C and only UART (no jumper) would work. In other words, neither jumpers would work.

I checked that, even tried applying the appropriate selection voltage directly to the analog input. No dice. :frowning:

Wow, that sucks. :frowning:

It’ll take a few weeks to get the new display in but in the meantime at least I’ve got the small OLED to test with!

Guys, this lib is awesome. I adjusted the clock div to 64 (it was already at 32) and added a 10ms delay after large writes. I also noted that there is a 50ms delay before writing a bitmap but I needed another 50ms, so I changed that.

Since I am pretty new to this type of graphics, is there a good overview of the boolean drawing modes when dealing with color? I am trying “dim” some icons and would rather do that with a rectangle that “darkens the pixels” if possible. Otherwise I need to have each icon in two modes, which is an immense waste of space.

@timb, you should point the Digole folks to this thread. They may throw a few your way since your lib is directly contributing to the profitability of their device. Hope you get it sorted quickly ;).

billprozac, you may also want to check out the digole Geometric library I did based on timb’s library. Ultimately, the idea is to have one library that does UART/I2C/Soft & Hard SPI along with geometrics and some sprite stuff that timb is cooking up.

I like your idea of contacting Digole though. Hey timb, do you want to do that? If not, I can do it.

:slight_smile:

Thanks. I have been using your library as it was already split into header and cpp. Things are looking great! Thanks for all of the work.

@timb and @peekay123, I had a need for text that can be center aligned and also optionally be able to “clear” the previous text on refresh. I wrote some simple code that you guys might want to adapt to this lib. I had to guess at font height an widths and created an array for the ones I am using. If you know of a better way, that would be ideal. Also, this only supports strings.

void centerTextBox(int font, int width, String text, int x, int y, const int color[], const int bgcolor[], int mode){
    mydisp.setMode('C');
    mydisp.setTrueColor(bgcolor[0], bgcolor[1], bgcolor[2]);
    mydisp.drawBox(x, y,width,fontheight[font]);
    centerTextBox(font, width, text, x, y, color, mode);
}

void centerTextBox(int font, int width, String text, int x, int y, const int color[], int gmode){
    switch(gmode){
        case 0:
            mydisp.setMode('C');
            break;
        case 1:
            mydisp.setMode('&');
            break;
        case 2:
            mydisp.setMode('|');
            break;
    }
    mydisp.setFont(fonts[font]);
    mydisp.setTrueColor(color[0], color[1], color[2]);
    int xoff=(int)((width-(text.length()*fontwidth[font]))/2);
    mydisp.setTextPosAbs(x+xoff, y+fontheight[font]);
    mydisp.print(text);
}

Hope this helps someone else :smiley:

billprozac, what a great idea! It could also be adapted to the setTextPosAbs(x,y) function. It makes me think about background/foreground colors which are not done by the Digole. The library could be adapted for bg/fg colors or it can be managed by the user code.

I was also thinking today about a “terminal” type text function where text would print across the screen and when it hits the bottom, scroll up like a terminal. Any thoughts?

timb, any thoughts on the background/foreground stuff and the terminal-type print function?

I was about to do the scrolling box for a logging function, but got lazy and just used the serial output :stuck_out_tongue_winking_eye:

Finally got around to doing this... and turning off optimizations works and increases the bin size by about 20k! That's fine, but when I add the -S it fails to link the .o files.

@bko @mattande @zachary do you have any ideas here how I can generate disassembly listings either from each object file? I tried adding -S to the CFLAGS and also ASFLAGS without luck. I've also been playing with the rules and trying to splice in a objdump -d ... without much success. I got some disassembly to display on in the console with objdump -d $@ but I'd just like an ASM file with line numbers preferably for each .cpp and .c file. Or even one large .S file in addition to the .Elf .Hex and .Bin

@timb Hey Tim, when do you think the I2C version of this library will be done and uploaded?