I am trying to specify a microcontroller for a very simple task. All it does is show an image at boot up (which will most likely be black and white).

The display itself is 240*240 and 12bit color depth which means it would have a total memory of (240*240*12)/(8*1024)=84KB. This seems quite high to me. Should I not be calculating for worst case? Do certain compression techniques come into play here?

I will have to leave some space spare for a bootloader etc. which I believe would take a fair bit of space too.

Where on the micro will this image be stored before it's sent via SPI to the LCD.


Worst case it could be a black and white image with no gray scale. Which alleviates the issue somewhat.

But anything with color, is there any reading material to see roughly how much memory I need to source for my display?

Previously I was thinking of animations with multiple images, but with my cost constraints, memory seems to be a premium and so this is out of the question.

Finally, is it generally cheaper to find a micro of the right size or a really cheap micro with external memory (EEPROM?)

  • 1
    \$\begingroup\$ There are probably compression techniques you could use, yes, but you have to consider the code size tradeoff too. MCU pricing is heavily driven by flash size, moreso even than core capability, so it may be more economical to use a small external storage device to hold the image, and have a low end MCU transfer it. If you are seriously targeting production you can do both, since MCU's usually offer multiple flash sizes in a footprint and you can always not populate the external flash device. For a one off, worry more about what is going to be easy - easier to get the image into internal. \$\endgroup\$ – Chris Stratton Dec 18 '18 at 15:58
  • \$\begingroup\$ If your image has no grayscale packing it as a monochrome bitmap (1 bit per pixel) would be 12x smaller and require little code to re-expand. That would be fine for a generated image like a logo but bad for anything pictorial. At present your question is too broad and non-specific to be answerable. \$\endgroup\$ – Chris Stratton Dec 18 '18 at 16:00
  • \$\begingroup\$ Edited to hopefully make it more specific. \$\endgroup\$ – Hassan Nasir Dec 18 '18 at 16:07
  • \$\begingroup\$ In terms of pricing, decide on your quantity and shop at that quantity for MCUs and external flashes. If you want data-based animation or color I would definitely look at external SPI flash, but programmatic animation might be done internally. In terms of compression you can easily try compressing your image in various ways on PC first (or perhaps a raspberry pi if you want to actually see the result on the display), though you'll need to consider the size of the decompression code for the promising candidates. \$\endgroup\$ – Chris Stratton Dec 18 '18 at 16:13
  • \$\begingroup\$ I'd go with off-chip memory. There are fast SPI based FRAM chips that you could read and send the data to the display. \$\endgroup\$ – CrossRoads Dec 18 '18 at 16:22

Let me be rash and predict you are actually trying to use an ST7789? based controller/LCD (since Ebay is awash with cheap 240*240 LCDs based on this controller).

If this is true then the first thing to understand is the LCD controller has a RAM frame buffer to store the image, so you may not have to supply as much RAM/EEProm for image storage as you might think. The ST7789 datasheets are here at Crystalfontz.

  1. If you are dealing with photos and the like then you will need to be able to store the image(s) in either compressed or uncompressed form. If you store them compressed to save storage then you need at least a partial buffer into which to decompress before sending to the display. Pre-compressing at the display resolution will significantly reduce the storage required, but you need to define both the resolution and compression (image/line-by-line) that you want to use.

  2. If you are dealing with images based on sprites (for animation) or alphanumerics you only need storage for the base content and can redraw, move and rotate onto your display.

  3. If you are dealing with patterns that are programmatically created you need almost no storage memory and only a partial buffer to write to the display.

If your MCU is network connected it may be possible to send just partial uncompressed buffers to the MCU and transfer these immediately to the display. e.g. a UDP stream --> buffer --> display. This can work very well for grown up IP connectivity @100Mbps on a decent MCU.

If you want to view the effects of lossy compression on the images you have you could use an online service such as OptimiZilla to show the effects on storage size. For example a typical 240*240 JPEG image might compress from 26kb (web typical) to just 2.1kb and still be quite viable.

| improve this answer | |

Your approach is right if you want it to be as generic as possible. If you don't know anything about the image someone want to load, you have to assume worst case. Image compression can not save you either, because it's theoretically impossible to compress every image.

For everything else you have to set limits. You can for example decide that you're OK with a gray image, in which case you only need 4 bits per pixel. You can decide to only allow 16 kiB large JPEG images with a fixed set of supported parameters. JPEG isn't that heavy, and was designed to be relatively easy to implement by microcontrollers. There are good external tools that can shrink images down to a given file size. For less compression and complexity decide on a different format, maybe GIF or PNG. This of course requires more room for decompression.

Then again, I²C and SPI flash memory is cheap and small.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.