What's the fastest LCD/OLED display I can use for feedback? I2C / SPI / Serial?

I've got an Arduino controlling a Canon lens, and I need to hook up an LCD or equivalent so I can get feedback on lens position and other state variables.

Everything's happening very fast, though - I'm updating things at 25Hz and need a way to see what's happening in the code, what the lens is saying etc. I'm trying to track down glitches causing my lens to jump around.

I can't just use the Serial monitor as I'm using the serial connection to feed data in from a separate app, so I want to hook up some sort of alphanumeric display - an LCD or OLED.

The lens communications require tight timings, so when I add a display I need to minimise the impact on the timings in my code as much as possible (ie not slow things down too much. What's the fastest type of display communication I should be using?

For example: I can get the fastest, lowest impact feedback from code by just sticking an LED on an Arduino pin (especially if I use direct port writes rather than digitalWrite). I really need to see numbers, though.

Is the plain old 44780 LCD likely to be the best way forward, or is an SPI or I2C interface likely to be faster?

**** edit: I've worded this better in reply #3, below ****

Please post your sketch, there may be some glitches that other sets of eyes can see.

Can you please post a copy of your sketch, using code tags?
They are made with the </> icon in the reply Menu.
See section 7 http://forum.arduino.cc/index.php/topic,148850.0.html

Tom..... :slight_smile:

UNO can do 500Kbaud over serial IF your terminal supports it (the IDE only supports only up to 115200)

500Kb means 50KB/sec in theory => 25KB in practice means you can do 1KB @ 25Hz

Still HW SPI is fastest.

how much data do you need to sent per screen update?

@TomGeorge - the sketch is spread over 3 classes and 7 files, so may be impractical to put up here (not to mention it may be hard to decipher without the protocol documentation which I'm still discovering (damn Canon and their proprietary products (!))

@robtillaart - Can't use hardware serial as that's already in use (and part of the thing I'm trying to debug) but softwareSerial could be an option. Thanks for the SPI tip, though - I'll have a go :slight_smile:

Crikey, it's only after posting a question that I often find I coul have worded it better. Perhaps I should have said:

I have a complex and timings-critical sketch running on my Duemilanove/328, and I need to add a display with the minimum of effect on timings. Impossible not to alter the sketch, obviously (Heisenburg), but which form of display comms will let me send the data and get back to my sketch's execution as quickly as possible?

I suppose I only need to push 8-10 characters to the display every 40ms, so nothing hugely taxing, but I want to pick a display communication method that won't tie up the Arduino for very long.

Software serial can't go that fast, you need to write your own bitbanging code then (send only)

How fast can your eyes read the display? I think much more slowly than most displays are updated. Especially with only 8 characters. But SPI protocol is probably the fastest.

+1, you're overthinking this. Your eyes are the slow link in the chain. Any of the displays you are looking at will be able to update a hundred times in the time it takes for your eyes to pick up the change and your brain to recognize the letters and numbers. Spamming data to the screen faster than you can see it is useless. If you need to make adjustments faster than that then you're going to have to abandon the idea of having a human in the mix and just let the computer do it all, in which case you don't need a display at all. Your brain cannot tell the difference between it taking 100us or 1000us or 10000us for a number to change on a screen.

Also bear in mind that although SPI is probably the fastest way available to transfer data between the Arduino and a display, in general SPI displays are high resolution bitmapped and often colour. So the Arduino may have the large overhead of rendering the text you want to display in a suitable large font, and then sending quite a lot of data to the display.

Serial, parallel and some i2c displays may be slower at communicating, but the volume of data the Arduino has to send, and the overheads of formatting it, are tiny. So they may actually be best for your application.


D'oh, yes, sorry, I really did word my question badly :slight_smile:

Agreed - I can't read numbers off a display very swiftly, but I can certainly spot a flicker - if I'm expecting, say, the lens responses (25 a second) to be in the low 10s, but one comes in as 0, or one comes in at FF, I'll certainly be able to spot that, even if it's only on the display for 40ms.

But the main issue is not that I want to update an LCD at high frequency, I just want the Arduino to spend as little time as possible doing it. In each 40ms frame, the Arduino is reading 8 bytes in from the serial port, processing it, querying the lens, receiving data from the lens, calculating a new delta, sending a new lens command, waiting for an ACK from the lens, sending 8 bytes out the serial port.

I've only got 40ms to do all that otherwise I lose my frame sync, so while I'm debugging (and trying to work out what Canon are up to with their weird lens behaviour) I don't want my temporary LCD hook-up to be causing timing issues of its own.

I'm gonna try just hooking one up as the usual 4-bit / 7 wire 44780 way first, then try an SPI display if necessary.

Thanks for the input!

I suppose I only need to push 8-10 characters to the display every 40ms, so nothing hugely taxing, but I want to pick a display communication method that won't tie up the Arduino for very long.

The little 128x64 pixel monochrome SPI OLED displays I've played with can easily do that. The last time I benchmarked my code it was able to draw 21 5x7 characters (one line) in 388us, on a 16MHz Uno. Even the Adafruit graphics library which is more than ten times slower would meet your easy to achieve qualifications.

What I can't tell from your posts is whether a 8x21 character display is large enough.

40 milliseconds is a virtual eternity in processor time. You've got time for 640,000 instructions in 40ms.

40 milliseconds is a virtual eternity in processor time. You've got time for 640,000 instructions in 40ms.

Hehehe - that may be, but there's a lot of waiting for external stuff to happen (like slow and temperamental lenses) and I don't want to complicate my code more than I have to.

So I may as well pick a display out of the box with the minimum possible overhead so I don't start introducing too many new delays into things.

Ultimately I'm trying to find out why this particular lens (and not others) sometimes seems to report its position incorrectly, but only when queried at 25Hz. It could be my timing (I'm bit-banging it) or it could be the lens itself, as it's a function I don't see the camera asking the lens very often (if at all). But I need it to work for my nefarious purposes -->

Ace when it works, but I gotta track down why the lens sometimes tits off and does its own thing.

If that's the case then I'd go with a Serial interface. With Serial you call once and stuff everything you want to send in a buffer and the rest is handled via interrupts. So your code can keep doing its thing without having to diddle with the display.

This comes back to the point in reply #7 sort of. While the actual data transfer is slower with the Serial interface, the amount of overhead for your code is less.

If you go with something like SPI or I2C then you have to keep coming back and sending the next byte out after the last byte finishes. With serial that will happen "in the background" while your code does its thing with the lens.

Gah - I was thinking, Nope, can't use serial as that's how I get the motion data in, but of course - the Megas have extra hardware serial ports - I'll dig one out. Thanks :slight_smile:

I sell serial port displays that can easily do this. Up to 115200 baud rate. Just send "\f123" as fast as you can and it has a buffer to only refresh display every 40ms, if there is change. The '\f' clears screen. Then you can add anything else to display. "\f123\t456\n789\tABC" will give you tab spaces ('\t') and two line display ('\n').


Cool video. Were you (or whoever shot it) adjusting focus automatically so it always stays on the storm trooper mini-figure?

Nope, that's the Arduino controlling focus. (The motors that actually move the camera are mostly controlled with Teensys)