How does the proffieboard drive SSD1306 OLED Display modules?

1

Fair warning, I’m completely new to Arduino-type projects and I’m trying to dive in.

My plan is to create a device which uses an RFID reader/writer module, an SSD1351-driven OLED display (a cousin to the 1306 from what I can tell) and an MKRZERO Arduino board, and put it into a datapad-esqe package.

I don’t have the hardware on hand yet, I’m trying to figure everything out first, but I think I’ve got most of it sorted out. The main thing I’m a bit hung up on is the OLED.

I want it to act as the interface for the device, and my (albeit extremely janky and probably not very resource-efficient) idea was to have bitmap images stored on an SD card for every single item and menu I would want to display, then just taking inputs from buttons and such to navigate everything, using variables to keep track of where the user is, then displaying the corresponding bitmap.

However, I can’t seem to find a whole lot of documentation on the subject, mostly related to playing animations. From what I can tell, Adafruit has a library for loading up bitmaps from the SD card and putting them on the OLED in a specified color (good enough for me, I’m using a color display but only want a couple colors at a time)

That works for static images, but I want to know how the Proffie takes those stacked bitmaps and turns them into animations, if that process is resource intensive, and if anyone has ideas for a better way to do it with my context. I have noticed that drawing these bitmaps has seemed to take a minute in videos I’ve seen demoing the library, but that’s been on 8 bit devices and with larger screens.

TL;DR, how does the Proffie get it’s bitmaps on the SD Card drawn on the OLED, and is there anything special it does to do it quickly without impacting other performance? More importantly, how does it do animations?

Any help or insight would be greatly appreciated, as I said I’m out of my element trying to push myself and don’t have a great grasp on the whole thing.

2

I would suggest going through the files in the /display folder to see how ProffieOS does it.

3

All the current ProffieOS code is written for one-bit-per-pixel displays. Once you go to 16-bit-displays the amount of data you need to read/write goes up quite a bit. Also, there aren’t a lot of image formats available that supports 16-bit images, so you might need to invent one.

Once you have that, animations is mostly a matter of reading an image at a time and feeding it out to the display. Bonus if you can do both at the same time. Extra bonus if you can do it while the CPU is doing something different. Quadruple bonus if you can prioritize the reads from the SD card such that audio takes precedence. :slight_smile:

Adding support for color displays is on my todo list for future ProffieOS updates, but it will most likely require a V3 Proffieboard since it will have an SPI bus available.

4

Ah, yeah, making the thing do multiple things at once it probably going to be the most fun part. From what I understand, adafruit’s library draws a image using the specified color, just using a normal bitmap?

So then if I understand correctly the proffie doesn’t really do anything special for animations, just splits out the stacked image and feeds one at a time?

5

Pretty much.
But as you say; the trick is doing multiple things at once.
ProffieOS does have a priority system for sd card requests that make sure that the audio doesn’t glitch while reading from the sd card, and I recently rewrote the i2c handling to use interrupts which speeds up the animations quite a bit.

6

Ok, that’s really all I wanted to know. I’ll have to wait until the actual hardware gets here so I can start tinkering with it all and wrapping my mind around it, lol, but thank you so much for the insight and information, I appreciate it a lot!