Seven Segment Displays are one of the oldest and most popular LED displays tailored for decimal numerals by origin. They are also as much pin hungry as their popularity, making them cumbersome to interface and drive directly in circuits.
Seven Segment Display
Driving a single display requires 7 data pins (8, if decimal point included) and a common anode/cathode pin, also called GND pin/enable pin. Often, the display comes as panel, like x2 or x4 or x8 to be able to display more digits. Does this also mean 2 or 4 or 8 times pin count!?? No, the engineers instead multiplex the data pins and keep the enable pin separate for each digit. How does this work? We will see that later.
x4 Seven Segment Display Panel with G1, G2, G3, G4 as enable pins
While this reduced some complexity in terms of pin count, displaying something ‘useful’ requires work. The data pins have to be time multiplexed, and enable pins have to be time de-multiplexed. Sometimes, the user may not want to directly drive the data pins, but wants to deal only with BCD codes. Say, you want digit ‘1’ to be displayed. It is simpler to convey through BCD rather than saying “data pins b and c should be active, and other pins should be inactive”. So here, there is a need of BCD decoder before driving the display.
Seven Segment Decoders to simplify the job!
All of the above mundane work just to display something can be offloaded to a separate chip in the circuit, which is typically called Seven Segment Decoder. The job of Seven Segment Decoder is to decode and drive seven segment displays. These chips comes in market in different flavors like SPI or I2C based decoders. The user can program the data to be displayed through simple serial interface from a micro-controller or so. This setup requires minimum no. of pins as the display is not directly driven by the micro-controller but by the decoder. Thus, controllability becomes much easier from user perspective.
I see no fun in buying one of them and using. Instead, let us design a Decoder of our own, an SPI based Programmable Seven Segment Decoder. All it needs is just four pins to interface with any host system!
Time Multiplexing/De-multiplexing with Seven Segment Decoder
Seven Segment Decoder’s primary job is to drive the data on each digit of the seven segment display panel. Say, to drive a x4 display panel, four 8-bit buffers are required to store the panel data. As we discussed earlier, the decoder should drive data in time multiplexed manner as the panel has only 8 data pins (Like 32:8 mux). The data enable should be time de-multiplexed at the same time to the corresponding digit (Like 1:4 de-mux). Controlling data enable is analogous to circular shifting ring counter {0001} –> {0010} –> so on…
Decoder output data multiplexing for x4 panel
The idea is to time multiplex the data fast enough to give an illusion that all four digits are displayed at the same time, while they are actually not!
Well, this doesn’t look right! We have to speed up even more…
When the rate is fast enough, the display should look static like this:
So, how much is “fast enough”? The trick is to exploit the Persistence of Vision. Human eye can be “cheated” to perceive smooth motion of frames with no observable flickering, when frames are displayed at 16 \text{ Hz} or more. This rate of diplay is called refresh rate. Ideally, I would say 60 \text{ Hz} is required for smooth display effect. It is also the reason why monitor displays use 60 \text{ Hz} refresh rate as the de-facto standard.
Since the whole x4 panel has to be refreshed at 60 \text{ Hz}, each digit has to be refreshed at 60 \text{x} 4 = 240 \text{ Hz}. Is there an upper limit to the refresh rate? Yes, because a typical seven segment display panel uses LEDs. At higher refresh rates, pulse width modulation reduces the power delivery to LEDs significantly, thereby reducing the brightness of the display. So, it is ideal to keep the refresh rates well below 1 \text{ kHz}.
Designing Seven Segment Decoder
Now that, we have a fair bit of idea on what’s the overall functionality of the decoder. Let’s draft the basic requirements of the Seven Segment Decoder to be designed before designing the architecture.
- The data to be displayed should be run-time programmable. Data buffers are required.
- Ability to enable/disable any digit any time, to save power if no need to display that digit.
- The data has to be time multiplexed based on the refresh rate. Refresh rate should be run-time programmable.
For run-time programmability feature, let us provide 8-bit peripheral registers and address space in the core to configure data, data enable and refresh rate. Let’s also provide SPI interface to program these registers via some high level command protocol defined by us. Something as simple as: <opcode+address byte><data byte>. The reason why I chose SPI is because it has no constraint on clock speed unlike I2C, and it is simpler to implement. SPI is available in almost all modern micro-controllers, making our Seven Segment Decoder easier to integrate into any systems or circuits.
The block diagram of Seven Segment Decoder v1.0 looks like:
Seven Segment Decoder v1.0 – Block Diagram
SPI Slave is the soft IP that converts the serial data received in SPI bus to parallel data (and vice versa) for Controller. This core was also designed by me :). Hopefully, I will write a blog about this core in future.
Controller is responsible for decoding the commands received via SPI, configuring the register bank, and dynamically controlling the data flow for motion control. Motion control is an extra interesting feature that I have added in the IP core to enable/disable horizontal scrolling effect. It is also responsible for generating interrupts on roll over and the host/system can update the next word to be displayed during the motion. For this purpose, addition four data buffers are provided in the core. This is analogous to double buffering; while one buffer actively displays the data, the other one is updated background. You can read more about this motion enable/disable feature in the IP documentation.
The configuration data (in register bank) from Controller is read by Display Driver aka Decoder. Decoder controls the refresh rate of displays by dynamically multiplexing data and dataen as we discussed earlier.
On-board Testing
The Seven Segment Decoder v1.0 IP package comes with a configurable test application in Embedded C to test the IP on board with micro-controller. The test setup looks like:
Seven Segment Decoder – Test Setup
The test environment consists of a micro-controller (I used Arduino UNO board) which configures the IP on FPGA through SPI. It also enables motion and interrupt in the core. The core drives a 4-digit seven segment display on my Basys-3 board.
hEY thErE…this is JuST For Fun….
On interrupt, the micro-controller updates in real-time the next word to be displayed once scrolled over. Thus it is possible to display long strings even though we are limited to eight data buffers in the core!
Seven Segment Decoder v1.0 – Source Codes & User Guide
Seven Segment Decoder v1.0 is a fully tested, portable, configurable, and synthesisable soft IP core. All source codes of Seven Segment Decoder v1.0 IP are open-source licensed and can be downloaded for free from the links below. The source codes include:
- Design source codes.
- Makefile to compile, build, and simulate.
- Test application to test the IP on board with a micro-controller.
Download Seven Segment Decoder v1.0 – IP Source Codes
Download Seven Segment Decoder v1.0 – IP User Guide
Support
Leave a comment or visit support for any queries/feedback regarding the content of this blog.
If you liked Chipmunk , don’t forget to follow!:
Like this:
Like Loading...
Related