Selecting a Microcontroller to use with Memory LCDs

Several customers of my Sharp Memory LCD breakout boards have asked me what microcontroller it is best to use to control a Memory LCD. It’s a good question and one which requires consideration of several different aspects of a microcontroller’s specification.

SRAM and Framebuffers:

The first question is:

  1. Do you want to create and hold each image you wish to display on the LCD in a framebuffer before sending it to the display?
  2. Or are you are able to generate images on the fly and send them direct to the display line by line using only a linebuffer?

The framebuffer option imposes a hefty SRAM requirement on your microcontroller whereas the linebuffer option is more trivial in terms of memory use.

Display dimensions (pixels):96 x 96128 x 128400 x 240
Linebuffer SRAM (bytes):121650
Framebuffer SRAM (bytes):1152204812000

The chart shows the minimum SRAM required by the LCD. You need to take into account how much SRAM your project requires for other variables and data when selecting a microcontroller too.

Theoretical LCD Refresh Rates:

Data is sent to the LCD over SPI. The Memory LCD datasheets recommend an SPI clock frequency of 1 MHz and a maximum of 2 MHz. However I have successfully used an SPI clock of 4 MHz on some Memory LCDs.

So, the theoretical maximum refresh rate of the display can be defined as the inverse of the time taken to send one whole frame of data to the display over SPI.

Display dimensions (pixels):96 x 96128 x 128400 x 240
Bytes per line:12 + 216 + 250 + 2
Total bytes per line:141852
Bytes per frame of data:1344230412480
Plus command & trailer bytes:1346230612482
Additional SCS pin
High/Low Hold times (us):
3 + 1 + 16 + 2 + 23 + 1 + 1
Frame Time /
Refresh rate @ 0.5 MHz:
21.5 ms
46 Hz
37 ms
27 Hz
200 ms
5 Hz
Frame Time /
Refresh rate @ 1 MHz:
10.7 ms
93 Hz
18 ms
54 Hz
100 ms
10 Hz
Frame Time /
Refresh rate @ 2 MHz:
5.4 ms
185 Hz
9.2 ms
108 Hz
50 ms
20 Hz
Frame Time /
Refresh rate @ 4 MHz:
2.7 ms
370 Hz
4.6 ms
216 Hz
25 ms
40 Hz

There is some additional ‘overhang’ before and after the frame data is sent over SPI caused by SCS pin timing requirements but even taking that into account, the refresh rates appear reasonable, even with a slow SPI clock. And by this metric alone – there’s no advantage in using an 800 MHz Raspberry Pi over a 16 MHz Arduino Uno – they’re both limited by the maximum SPI clock frequency the Memory LCD can handle.

Now this metric is unrealistic for two reasons. First, the LCD is a Memory LCD and doesn’t need to have the frame data repeatedly sent in order to keep the image displayed. Once the image is on the display, it stays there. Second – it assumes zero processing time for frame creation.

Frame Data Creation

The main influence on the refresh rates you can obtain is simply how long it takes you to generate that data you want to display.

Here, your main microcontroller’s clock frequency is key. The faster your clock, the faster you can generate a frame by any given method. But if you are wanting to use the the Memory LCD in your project because of its low power requirements, the trick is going to be seeing how low your main clock can be before the display refresh becomes noticable. Fortunately, microcontrollers have multiple clock divider settings so you can buy a fast uC and then underclock it by setting a conservative clock divider to accomplish this.

That said, these displays were never designed to display fluid, fast moving video!

Whether you’ve chosen to use a complete framebuffer or just a linebuffer will also affect how the display appears to refresh when  you’re generating a particularly complex frame. By complex, that could mean mathematically complex, or complex as in data needs to be polled from multiple sensors, or complex as in image or font data needs to be fetched from EEPROM or an SD card. I can’t give you a definitive answer, it depends purely on your particular application.

With the framebuffer method, there may be a pause between frames as the new frame is constructed in SRAM and then BANG! the new frame suddenly appears on the screen as all lines are quickly written to the display in a single “multiple line write” command over SPI. You can’t see the progression of the lines being written to the display – it’s all over too quickly, in the order of milliseconds as you can see from the table above.

With the linebuffer method, there may be a noticeable progression of lines being updated on the LCD – depending on how much processing is involved in creating each line. Each new line is computed in to the line buffer and then written to the display in a “single line write” before calculation of the next line starts.

This difference between the framebuffer and linebuffer for computationally intensive frames is well illustrated in my Youtube videos of the Memory LCDs. There is one sequence in particular that illustrates this well – the scrolling sinewave. I use the linebuffer method to create the sinewave and you can clearly see the progression of lines down the display when the Arduino Uno is running the demo but the animation of the sinewave is much smoother when the Raspberry Pi is in control.

However that’s not to say that a 16 MHz Arduino shoud be written off as a choice of microcontroller for use with a Memory LCDs. For most of the other sequences in the demo, I’m deliberately inserting delays of 5 -10 milliseconds between writing each line in order to slow the Arduino down in order to create a more pleasing visual effect.

Microcontroller Pin and Peripheral Requirements

The final point to consider is how many microcontroller pins it’s going to take to control the Memory LCD. The short answer is – up to 5 data pins (plus power and ground).

I’ll start with power first. Some Memory LCD models require a 5V input voltage, others can take either 3.3V or 5V. If you’re planning on using a 3.3V microcontroller and a 5V Memory LCD, how are you going to supply the 5V the LCD needs?

Related to the supply voltage level is the 3V logic level voltage required by all Memory LCD models. This, however, is not a problem for Memory LCDs attached to my breakout boards as I have included a logic level converter that will take either 5V or 3.3V logic level inputs from a microcontroller and convert them to the 3V logic level the LCD needs.

Next, the data pins. 3 of them are concerned with the SPI data transfer. Data, clock and chip select. Make sure your chosen microcontroller has an SPI peripheral, although plan on using a general purpose IO pin for the chip select as the behaviour of the dedicated SPI chip select pin on your microcontroller may not be what the LCD expects.

The final 2 pins required are for turning the Memory LCD on/off and providing a polarity inversion signal to the LCD. The display on/off pin could just be tied high at the breakout board header if you want to save a microcontroller pin and just leave the Memory LCD permanently on. The pin that provides the polarity inversion signal should ideally be a dedicated hardware PWM pin, so you can just set it up to generate a 2 Hz to 60 Hz squarewave and forget about it. If you can’t spare a pin for this polarity inversion signal then there is the possibilty of implementing the polarity inversion signal through commands sent over SPI, but to properly implement this software/SPI polarity inversion method, you’ll need to set up a timer based interrupt.

One thought on “Selecting a Microcontroller to use with Memory LCDs

  1. I think there’s something wrong with your arithmetic; perhaps you misplaced a factor of 8 for bytes vs. bits. For the 2.7 inch display, there are 240×400 = 96000 pixels. If we ignore the overhead, and divide that into a 2 MHz SPI clock, we get a maximum frame rate of 20.83 Hz.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s