Driving multiple seven segment displays in mOS

General
#1

Hi all,

Just wondering if anyone could share some experience or advice in driving multiple seven segment displays in a RTOS like mOS.

pcy0P.jpg907×570 59.4 KB

I think I understand the principal that would drive the schematic above - each display is set individually and then the anode corresponding to the display is driven at the same time, and this is cycled for each display multiple times a second.

This would be great for a cyclic execution like Arduino but I’m unsure how or if it’s even a good idea to attempt this in freeRTOS/mOS.
I’ve not seen any drivers available in the mOS library that seem to do something like this, so any suggestions would be appreciated.

Thanks.

#2

This is no different to doing what you normally do for driving 7-segment displays.
Digits are first completely blanked, then the proper segment information for the current digit is presented, then that digit is enabled. This goes on for every digit, for all digits. One digit lights at a time and the whole cycle has to be performed at a frequency higher than what the human eye perceives, depending on the application. For normal cheap devices standing still on a desk you can use above 50Hz, preferably 100Hz. For other applications perhaps you’d have to follow some regulation indicating higher frequencies.
Obviously you will not wait in a loop for 20ms, you either fire an interrupt or set up a task or periodically request a timer event. A four-digit display updated at 50 Hz means 4x50=200Hz = do it every 5ms.
Your application never writes to the display, it stores to memory and the code driving the display does that.
If you will be performing animations, you have to sync your updates to a full display refresh, in order to avoid ghosting and artifacts. In this case, an irregular update frequency might cause some tearing in the movement, in which case I would favor interrupts.
It is always preferred to defer updating the display to a full display refresh, if you perform periodic writings anytime there will be a clash between app update frequency and display update frequency and some ghosting or blinking may appear.
I wrote this in 68HC08 assembly 20+ years ago and ported to several other microcontrollers, and to C. It is working nice in many devices. I always use a hardware timer interrupt for this activity since I mostly work on bare metal (no OS). I set a flag when the driver has finished updating the last digit and the app stores desired value before first digit update begins. More practical and elegant solutions can be used on something like mOS, for example, like a callback…

#3

Maybe try something based on MAX7219.

#4

Thanks for the detailed response @scaprile. I was expecting I’d have to do something like what you mentioned, but I’m unsure how this will impact performance of mOS as I imagine it will add significant load to my device. Not sure how to assess this without trying it.

Thanks for the suggestion @nliviu, I saw this driver available but the chip is in excess of 10USD from what I’ve seen online, which makes it 3+ times the cost of my MCU :smiley: I was looking for a lower cost option.

#5

In 8-bit micros, assembly written code has no impact on performance. Looks complex but only a handful of instructions run every time.
Application processors are not intended to drive I/Os, but well written C code should not incur in noticeable CPU load as long as the 5ms interrupt is routed outside of the OS (a hardware timer interrupt). A 5ms repeating timer in mOS, though, I would not recommend.
Perhaps cheaper than a Maxim is a low pin count microcontroller… though you’ll have a longer (and tougher) development time, just delegate the display to an 8-bitter (or a cheap Cortex-M0+, btw).