It’s taken me a while but I’ve just noticed that Engineering.com featured my breakout boards back in July in an article on Memory LCDs.
Just a quick update on progress as I’ve not posted anything in a while. The very hot weather in July made it difficult for me to spend much time up in my ‘lab’, which being a converted loft spent much of the time so hot as to be unusable. It was in the mid/high 30s during the day and only dropped to the high 20s at night (i.e 4 am!).
July also featured some server related unpleasantness, the result of which was that I’m now hosting my site on Amazon Web Services. I needed a spare, clean installation to quickly move the site to and AWS’s free usage tier fitted the bill. The upshot of this is that page load times have markedly reduced.
No sooner than I’d got my new webserver sorted out, I suffered a hard drive failure on my desktop. A 500 GB Samsung Spinpoint F1 on which my /home was mounted failed (reasonably gracefully, at least) after 4.5 years of operation. Fortunately it was one half of a RAID1 array and additionally I had backups on an external HD so no data was lost.
I took the opportunity to replace the failed drive and it’s still-working twin with a pair of 1GB Toshiba drives (DT01ACA0100). Annoyingly, the new Toshiba drives emit an annoying “tick-tock” sound every few seconds. It doesn’t sound like a click of death but all the same, I’d rather they didn’t do it at all.
At the same time as the HD failure, I decided to change my OS drive to an SSD – entailing the re-installation of both SuSE and Windows.
It’s the time it’s taken to sort it out all these problems out that’s annoyed me. I have my next product all sketched out but haven’t had the time to start developing it properly as I’ve been mostly occupied with computer admin and repair.
Oh, and I finally got round to trying out Strava
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:
- 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?
- 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 96||128 x 128||400 x 240|
|Linebuffer SRAM (bytes):||12||16||50|
|Framebuffer SRAM (bytes):||1152||2048||12000|
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 96||128 x 128||400 x 240|
|Bytes per line:||12 + 2||16 + 2||50 + 2|
|Total bytes per line:||14||18||52|
|Bytes per frame of data:||1344||2304||12480|
|Plus command & trailer bytes:||1346||2306||12482|
|Additional SCS pin
High/Low Hold times (us):
|3 + 1 + 1||6 + 2 + 2||3 + 1 + 1|
|Frame Time /
Refresh rate @ 0.5 MHz:
|Frame Time /
Refresh rate @ 1 MHz:
|Frame Time /
Refresh rate @ 2 MHz:
|Frame Time /
Refresh rate @ 4 MHz:
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 stupendously fast, 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.
This is a really quick and simple hack that really improves the take-off behaviour of the R10 when carrying a large battery. I’ve been using larger 5000 mAh Turnigy batteries on my R10 and these have caused havoc when mounted on the original battery mounting plate.
The problem was that upon taking off, the quad would want to ‘stick’ to the grass on the corner that the battery was mounted towards, with the result that the quad would suddenly flip over if the throttle was raised slowly. Three props would simultaneously develop enough lift to lift their corners of the quad, while the heavier corner closest to the battery remained anchored to the ground. The result was a very rapid 180 degree flip, that once started, was too fast for me or the quad to control. The damage caused by the flip was probably also compounded by my long landing gear design.
I broke two motor shafts and bent one before realising that it was really just pilot error and working out what I had to do to prevent this. Without moving the location of the battery, the solution was not to take off by being gentle with the controls and slowly raising the throttle but instead by giving the R10 a quick burst of full throttle to quickly and decisively lift all four corners simultaneously before cutting back the power to maintain a hover a few feet off the ground.
Now, unlike other users, I’d not broken the original battery and thalamus mounting arrangement in any of my crashes because in addition to the supplied vecro loops for securing the battery to the mount, I’d been strapping it to the frame with a couple of reusable cable ties.
These cable ties were now used to secure the battery to a new location beneath the quad that is as close as I can get to its centre of mass. The two reusable cable ties are all that are holding the big battery and it feels quite secure. There’s a battery voltage monitor with a siren connected to the balance port too – a very useful addition to the quad.