Digole UART/I2C/SPI Display Library

timb, you may want to add another project to your book… a robotic typing assist to help you while your finger is healing, especially with 500 pages!! Or perhaps that is your mousing hand so then it would be a robotic mouse button clicker!!

BTW, impressive work. When I move towards robots, I will absolutely pick up a copy of that book

:smile:

We are going to have start calling @timb the Bionic Man…we can rebuild him, better, faster, stronger! :smile:

I have one of those busted up fingers too and it makes a great weather predictor: whenever a low pressure storm front is coming in, I can tell.

Seriously, I hope you feel better soon!

Haha, good idea! I'll be sure to post a thread with a discount code when the book comes closer to release this summer!

I'm already talking to my Editor for my second book to be about the Spark Core.

It's funny, a few years ago when I got two metal crowns I asked the dentist if I was now officially part cyborg. The two wires sticking out of my middle finger would make perfect taser probes. I want to ask my surgeon to route some insulated wires to them up my arm. Go Go Gadget Stunfinger! I could really flip someone off then!

1 Like

@timb Very cool on the book. I had the book “Robot Builder’s Bonanza”. I have been in robotics for many years 15-20? I haven’t used the PI but heard great things.

Have to share my current project love to get your input.

Doug

timb, I vote for your finger to have a frikin laser beam in it!

:wink:

Okay, I know this is verging on perhaps maybe being annoying but timb, I am porting a digole project over to Spark and I really want to avoid having to port the their library. Can you give me an idea of the ETA on your digole code?

Thanks!

I got the bandages off my hand today and a pair of splints put on, which allows me to type much, much easier! My Digole 1.8" Color OLED also came in, so I just got that hooked up. Now that I've got this and can type, I'm back on the library and should have an actual release for you tonight! :smiley:

1 Like

timb, the hand is looking better, somewhat. Given the activity on the Spark forum with your name on it, I appreciate your work! Oh, and please let me know what you think of the color Digole.

:smile:

No worries man, I know a bunch of people are waiting on this!

So far I really like this display! As you can see in the picture of my hand in the last post, the 1.8" Color and 1.3" White OLED modules are displaying the same thing. I simply plugged the Color OLED in—and since they both use the same I2C address—it automatically mirrored the smaller display, which gave me a chance to confirm one set of commands produced identical results.

I just uploaded a 160x128 256 Color Image of the Spark Logo and it looks damn good in person! Due to the white background, it was really hard to get a picture of it without banding from the refresh rate (this only seems to be an issue when there's a lot of white on the screen). I finally managed to get a decent shot using HDR and heavy processing afterwards:


Note: This is a heavily processed photo designed to show the size and clarity of the pixels only! The blue speckling you see is refracted light from the screen's glass/filter and not bleed through; likewise the uneven color bands are remnants of me cleaning up tearing artifacts caused by the camera's shutter speed. The actual display is very vibrant and clear!

I will say, it took several minutes for that image to fully draw; you can actually see it loading pixel by pixel, line by line. I think I might switch to SPI for a speed boost and bump the "SVG-to-Native-Drawing-Commands" part of my library up the priority list a bit. :smiley:

1 Like

There’s three little solder pads on the back of all the Digole modules that let you select between UART/SPI/I2C. Since I need to test all three interfaces that means easily switching between them. I just made a quick mod to my new 1.8" Color OLED to make that possible:

You just need a very small right angle header, liquid flux, copper desoldering braid and very steady hands! :smiley:

Nice job. And in your case, that would be a very steady HAND since the other one is kind of partial at this point, no?

:smile:

LOL! Yes! The splint on my middle finger extends about an extra inch from the fingertip to protect the pins sticking out; I kept bumping it into the soldering iron, so I ended up wrapping it in tin foil to at least protect the padding and my finger.

It took damn near 30 minutes just to solder that on there. Sighs :frowning:

Well, going to bed. Thinking about the SPI speeding up things. I am not too sure since the PIC on the Digole puts everything through that 2K byte buffer. With full color, that will fill up very fast but for most everything else, it should scream. I look forward to testing my color unit on I2C and SPI as well. Right now, I am trying to debug the idDHT22 library and the gal darn DHT22 refuses to start up! If I pull the data wire to the Core and re-insert it, it starts! It will wait till tomorrow.

:smile:

Hold it!! I just realized that you said your image took minutes to draw at 160x128x256 colors. That essentially 20,480 bytes of data, which is not that large. Did you use Digole’s online converter for your image and use the drawBitmap256() command? That should have drawn pretty fast! I can understand the 262K color taking longer but 256?!

Ready and waiting :smile: I have a need for a dial gauge demo… got anything in your library for drawing stuff like that? BTW those SPI/I2C jumper pads are much smaller than they look in Tim’s pic. I think I’ll just wait for the fastest mode and solder blob it! UART 115.2k baud (~57.6kHz), I2C 100kHz, SPI (? MHz). Looks like MODE0, 8bits, MSB first…

Keep in mind we've got to delay 10ms for every byte written over I2C. So, 160 x 128 x 0.01 = 204.8 seconds.

Yeah I've got some gauge code from a previous graphics library project I can have working in no time. Do you just need a single full screen gauge that you can define a range on (0 to 100, 0 to 3.3, etc.) and have a needle move to the appropriate position when the function is called? Maybe two main calls like this:

gauge.setup(lowRange, highRange, label);

gauge.update(value, label);

So good news on the library front! Basic SPI is working and it's really fast. I've found SPI_CLOCK_DIV32 seems to be the fastest I can go right now—and that's with CS tied directly to ground. That 256 color bitmap writes in a couple of seconds and I'm working on making that faster. (I'm doing a 50ms delay after every 1KB of data by inserting a if((j%1024)==0) statement into the for loop that writes the bitmap data, but we can bring that down to 10ms I think.)

Once I get SPI implemented I'll go ahead and release the first version of the library with support for all the basic commands (parity with Arduino version of the library) over I2C and SPI. I'll add UART support and some of my custom sprite commands in the second release which I can hopefully have out by Thursday. Expect this first release sometime today (I'll be going to sleep in an hour or two, so I'd say early afternoon (Eastern), for reals this time! :smiley:

1 Like

Sounds great! Once you release the library, I will run tests on each comm type to establish some metrics. I have the color digole and a few b/w units as we’ll. If I add an SD card, the CS pin can’t be pegged so I will try that out as well.

Good work! :slight_smile:

Ok... I haven't been paying any attention, clearly - why is this? That would seem to rule out I2C as a driver protocol for any significant display functionality.

I’m not sure it does rule it out. This was to send bitmap data. The power of this solution is that it off loads much of the processing to the device its self. So if you just want to draw lines/shapes/text i2c will be more than quick enough.I’ll try and stick with i2c for as long as I can… It’s so much simpler and neater as a solution… To be fair sending bitmaps to the device will be the exception rather than the rule… Unless of course you want a really small gaming device.

1 Like

w00t! Yeah that would be excellent, thanks! I know tons of people would also love to see a gauge so easy to use. The static parts of the gauge can be changed and customized later on, no big deal there. As soon as you have an example, I'll probably go nuts customizing it.

That's amazing can't wait to play!

This digole display looks so great powered off, I can hardly wait to see it when I turn it on! After many years of being required to design with cheap sucky contrast LCDs, I :blue_heart: OLEDs and want to jam them into everything I can think of now.

1 Like