Small I2C OLED displays are common nowadays, and thanks to the work of helpful developers, there are also a variety of graphics libraries for using them. Most of them work by using a RAM buffer, which means that anything one wants to draw gets written to a buffer representing the screen, and the contents of that buffer are copied out to the display whenever it is updated. The drawback is that for some microcontrollers, there simply isn’t enough RAM for this approach to work. For example, a 128×64 monochrome OLED requires a 1024 byte buffer, but that’s bad news if a microcontroller has only 512 bytes of RAM in total like the ATtiny85. [David Johnson-Davies] has two solutions: a Tiny Graphics Library that needs no RAM buffer and an even slimmer Tiny Function Plotter, which we’ll discuss in order.
[David]’s Tiny Graphics Library works by taking advantage of a feature of SH1106 driver-based displays: the ability to read the display over I2C as well as write to it. With the ability to perform read-modify-write on a section at a time, using a large RAM buffer can be avoided. The only catch is that the library only works with OLEDs using the SH1106, but the good news is that these are very common at the usual Chinese resellers. ([David] notes that SH1106 is sometimes misspelled as “SSH1106”, so keep that in mind when searching.)
What about all those other SSD1306-based OLED displays out there? Are they out of luck? Not quite. [David] has one more trick up his sleeve: his Tiny Function Plotter works on the SSD1306 and also requires no RAM buffer. It’s unable to write text, but it can easily handle drawing graphs plotting things like values over time while needing very little overhead.
Another approach we’ve seen for using OLEDs driven by microcontrollers with limited memory is the solution [Michael] used in Tiny Sideways Tetris, which was done in part by realizing the smallest screen element he needed was a 4×4 block, and using that premise as the basis of a simple compression scheme.
Ah ha existential minimalism suits me too well, thanks for post :-)
“Most of them work by using a RAM buffer, which means that anything one wants to draw gets written to a buffer representing the screen, and the contents of that buffer are copied out to the display whenever it is updated”
That is simply just not true. Nothing special with this post.
Do you have any sources you can link? Seems like a person who could write a graphics library for one of these screens would bother to learn how they work first and would have a reason if they choose to deviate from that.
When will we see the 1st computer built as a cluster of T85s?
I want a T128 with at least 16k RAM!
https://www.mikrocontroller.net/attachment/31544/Tiny128L-8PU_1024x768.jpg
8 pins are enough, but pleaaaase more flash and RAM…
Naming that chip “*TINY” seems a bit incongruous.
Thanks to Photoshop, this is possible :D
Ahhh!
Ha! Nicely done :)
Interesting, didn’t know about the SH1106. However, as mentioned in the Tiny Function Plotter, if you use page mode you do not actually need a pixel buffer if you can recreate tiles of the screen contents on the fly and are willing to redraw (i.e. resend) the whole frame with every update. If you’re using tiles (e.g. a 7×7 font) you even just need to store the tile identifier in your internal buffer.
One thing I find more annoying about the SSD1306 (and similar) than the lack of the buffer is the lack of position reset and clear screen commands…
Here is my take on the same subject: https://github.com/notisrac/SH1106Lib
However mine is not limited to the ATtiny family. (And most definitely does not use the Wire library :) )
Feature wise, it is a bit more packed (even though it cannot draw lines, yet :) ), it:
– can display bitmaps
– can draw filled rectangles
– implements (almost) the full functionality of Arduino’s Print class
– allows you to use any font (not just the built in), in any size (can be multiple pages tall)
– can use HW or SW I2C (thanks to the SoftI2CMaster lib: https://github.com/felias-fogg/SoftI2CMaster)
That’s great work! Thanks for sharing!
While it is an interesting challenge, there is some questionable decision for the choice of microcontroller with limited resource. The price of the LCD/OLED is far more expensive than your uP. Go learn to use other uP and not living in a one horse town.
So you mean that this would not be a good match for the 3 cent MCU recently featured by EEV-Dave then? ;-) ;-) ;-)
Any chance of a link please, search didn’t find that item under that Nick or similar parsing on hackaday ?
Ive seen the 8pin otp devices from a China web site linked on hackaday but, no specific article on them as far as I have seen so far, curious as to their utility/efficacy could have lots of you potential as well as solving few size/process issues on few other more challenging implementations to cut ones teeth on for new entrants to micros…
Ah ha think I found it under EEVblog, worth a look for the OCD minimalist
https://www.youtube.com/watch?v=Rixo78hv_lw
I’ve been following closely. Once someone clones the writer, this chip will be useful… Unless you have boots on the ground in Shenzhen to find it for you. $150 writer for a 3c part. Until then it’s just a great talking point.
Not so in the toy industry! Manufacturers are loathe to spend more than a nickel on a processor, but a display(Basically anything the user can actually see)? Have at it!
I actually have a graphics library for the SSD1306 that runs on a 6502 with 256 bytes of RAM. I also run a mesh network in that same project.
What is the clock speed of the 6502 you’re using? Is the graphics library open source by chance? I’m trying to do exactly that at the moment, but I’ve got 16k of ram to work with.
While going for the green is an interesting challenge, there is some questionable decision for the choice of a driver with limited skill. The cost of going out of bounds is way more than an extra shot to lay up. Learn to use your irons rather than smashing every time.
…nah smash every time and prove it can be done. Therein lies the spirit of a true hacker – in golf or electronics!
No way. Learning to program with very restricted resources is always useful. Even in our current age of enormous memory and godlike processing power, people need to know how to write efficient code. Look at our bloated web design these days, for instance. We have ludicrous speed broadband but websites still chug and hang and reflow all damn day because for some reason an article on a news site requires a page that weighs more than a full install of Windows 95.
It’s good exercise to learn how to do it with the smallest computer. And if the oled is so expensive, why not save on the processor if it still works fine? What happened to the “could have done it on a triple-five” crowd and where’d the “just use a Linux sbc for everything” people come from?
> why not save on the processor if it still works fine?
More capable processors are available for about the same price. And learning to program those is also useful. There’s a difference between writing good efficient code, and spending way too much time on extracting the last byte, in return for making the code harder to understand and modify.
I’m waiting for the projects where the display shows gibberish for a moment while the micro is using it as scratch-RAM for computations, then reverts to displaying an image while things are idle…
hello pic is i2c library available for ccs c. Could you help
If you turn the Tiny Function Plotter idea sideways, you get a flexible progress bar with only a few lines of code:
https://thecavepearlproject.org/2020/11/15/adding-two-oled-displays-to-your-arduino-logger-with-no-library/