Using a display in a "real" design... best approach for MCU control?

[JKIM]

This may be a fundamental or "it depends" type question, but I haven't found any guidelines or benchmarking for the topic.

I am thinking about using a graphic display in my next project, something like a 128x32 graphic OLED display.

Basic use of the display is no problem, but I wondered how much overhead there is when also using a single MCU (Teensy 3.6) for the main code execution.

Do most designs with displays use two MCUs? One for main functionality (timing critical, etc), and one just for the display?
What usage patterns have the most overhead, animations, refresh rate, resolution?

As an example, say I want to receive an incoming analog signal and then display an oscilloscope waveform in realtime on the OLED...

I'm just looking for tips or places to begin doing some research on the topic.

JK

 

[GremlinWrangler]

Given most small displays have a controller in anyway, having a slave teensy won't gain much unless you are trying to are rendering a complex UI on the fly or are genuinely short of cycles on the Teensy.

Most displays are SPi or i2C so can tolerate short interruptions to the data stream.

Memory can be a constraint, but a OLED like that only needs 512 bytes, and many of the small displays are 'clear and then write your image' types where the display has screen memory you write your pixels to asynchronously. Can make for flicker if you update to fast but means your memory needs are low.

 

[JKIM]

Given most small displays have a controller in anyway, having a slave teensy won't gain much unless you are trying to are rendering a complex UI on the fly or are genuinely short of cycles on the Teensy.

Most displays are SPi or i2C so can tolerate short interruptions to the data stream.

Memory can be a constraint, but a OLED like that only needs 512 bytes, and many of the small displays are 'clear and then write your image' types where the display has screen memory you write your pixels to asynchronously. Can make for flicker if you update to fast but means your memory needs are low.

Thanks for the comments. My previous experience for "displays" is with 7-segment LEDs, which are obviously much simpler. I guess I'm not sure about how the underlying graphical assets are generated/displayed on a graphic display like that. Things like rounded tabs, fonts, icons, etc. Do they have to be mathematically calculated (each display refresh!?) or they have to be stored in memory somewhere and combined to create a frame (sprites?)

I was imagining the main MCU doing the main code execution and then sending simple commands to a slave MCU that just handles the display, like "show the utility menu". Then the slave MCU puts together all of the graphical elements of the "utility menu" and updates the display.

As an example, here is the graphical interface of a Rigol oscope, how is the display of something like this handled:

 

[GremlinWrangler]

Adafruit GFX is pretty much the baseline for this
https://github.com/adafruit/Adafruit-GFX-Library
Even though not all libraries use it as intended (bridge between display low level library and your code) most current display libraries implement the graphics primitives in the same way (and using the same commands) it does which simplifies things to the point that often you can port code just by swapping the library and re-defining your resolution.

Also means people can do build on top of it like (random google hit "adafruit gfx menu', not something I've used) https://github.com/neu-rah/ArduinoMenu and have some chance of things working for some other display.

Though if you were after a true menu API there doesn't yet seem to be one that has reached wide adoption yet.

In any case there are two basic methods to make the UI, either drawing assorted boxes and lines, or having bitmaps saved to flash or SD card and layering them together, neither of which is going to be as neat and tidy as you might have wanted for your scope project.

 

[jwatte]

The "controller" for displays is typically just a framebuffer, and some serial bus (SPI or I2C) that receives bits to put in the framebuffer. Unfortunately, all the work of arranging the bits in the first place, and sending them over the serial bus, can soak up significant MCU cycles.

So, this depends on your timing. Figure out the best you can do for data aquisition, and then driving the display with what's left over in CPU power.

Typically, if you have strict timing constraints, you'll want those functions to run off of interrupts, or even using DMA, rather than have it share the main loop with driving a serial display that may require many milliseconds to update.

If the strict-timing parts you have somehow cannot be driven sufficiently based on interrupts and DMA, and you need to drive a sluggish display that requires the MCU to spend a lot of time doing so, then splitting into two MCUs may be useful.