[Active] Seven Segment Display Driver

Overview:

An extensible hardware and software solution for driving a wall of seven segment displays. A "display module" will consist of multiple LED driver chips each driving a maximum number of digits, commanded by a single STM32 driver MCU. A master controller decodes animated gifs and sends a serial byte command of SPI to the display modules, then sends a synchronized update command. Per-segment brightness control will be implemented in version 2.

Goals:

• lowest possible cost – a preliminary calculation is at $0.20/digit, so for a 36x36 digit display around $260
• module-based – user can string modules together to drive bigger and bigger display walls
• (stretch/v2) individual segment-level control — see why this is a v2 goal below (depends on driver chip)
• (stretch/v2) integrates with current libraries like SmartLED/FastLED

Links and Supporting Posts:
See supporting blog posts and links below. You can always drop me a line if you have comments, advice or want to collaborate.

• Working notes
• Detailed post on Tm1637 library and logic analyzer captures (In Progress)
• General post on multiplexing architectures (In Progress)

Current Architecture

First, the Master Controller will send a byte string of length M_modules x N_bytes/module over a daisy-chained SPI configuration representing the whole display frame – this is the shift register approach where to update any single digit we have to shift in the whole frame and then enable the output when all the modules have their respective parts of the frame. This of course takes a lot of processing for the Master Controller but it can be implemented with DMA so that the Master Controller can also do things like decoding animated GIFs in real time (see the SmartLED/SmartMatrix library).

Each STM32-based module will then send out three interleaved I2C-like signals to the TM1637 display driver chips. Since each driver chip drives 6 digits each we will update all 6 digits, giving a digit refresh rate of ~290us for a 250kbps serial clock. The TM1637 modules then continuously multiplex/refresh the displays with this given data without further commands.

Since all of the driver chips are commanded at about the same time (the STM32 can easily interleave 3 bit-banged 250kbps Clock and Data lines) we should have a synchronized update across all digits.

The timing requirements are calculated based on a 24Hz refresh rate for the whole frame, giving for example a required processing period of a module of 2ms for a 24Hz refresh rate.

1/24Hz ~= 42ms → 42ms/20modules ~= 2ms/module.

Each module must take in the SPI data, update its internal memory mapped registers that hold the status of the display segments (or an internal array), and then wait for the command to send the data out to the TM1637 driver. In reality below only during the last module period (e.g. M20) will this command be sent since only at this time will all of the modules have their data.

Note that the limiting factor is how fast the TM1637 serial clock runs that updates the individual digits, which in this case with some buffer time is calculated around 288us for updating all 6 digits at 250kbps.[[1]]

Details (Working Notes)

Project Outline - Seven Segment STM32 Driver - Spencer’s Working Notes

Project Outline - Seven Segment STM32 Driver - Spencer’s Working Notes

Spencer's Working Notes

Inspired By

The DigitGrid

The DigitGrid is a new type of display. Typically used to display numbers, seven segment displays have been around in various forms for over 100 years. The t…

Movie-Style Hacking With A Wall Of Glowing Hex

Over the years, the media has managed to throw together some pretty ridiculous visual depictions of computer hacking. But perhaps none have gone as far down the road of obfuscation as The Matrix, w…

HackadayTom Nardi

[[1]]: Note that the limiting factor is how fast the TM1637 serial clock runs that updates the individual digits, which in this case with some buffer time is calculated around 288us for updating all 6 digits at 250kbps.