FPGA-Elf display drivers and multiplexing

For my previous FPGA-Elf, I used actual hexadecimal displays as per the Popular Electronics construction article. The only hexadecimal LED displays still made are from Broadcom/Avago, don’t have the integral red filter, and cost around $40 each. Used or NOS HP and TI displays are also rather expensive, so I’ve now chosen to use the LiteOn LTP-305HR 5×7 dot matrix LED display, available for $3.67 each in quantity one from Digi-Key. It is based on the TI TIL305, which in turn was based on the Monsanto MAN2A. The packaging is nearly identical to the TIL311 hexadecimal display.

Unlike the hexadecimal displays, the LTP-305HR contains only 36 bare LEDs (including one decimal point, which I won’t use), with no drivers. Since they are in a matrix, with anodes connected to five column lines, and cathodes connected to seven row lines, they require multiplexed drive. I want to have up to six digits (to display both address and data), so the most efficient organization will require 15 anode drivers and 14 cathode drivers. Electrically this is an arrangement of two rows of displays by three columns, although physically they will be mounted on the PCB with all six in a single row.

While the Digilent Cmod-A7 FPGA module has 44 digital GPIOs available, I don’t want to dedicate 29 of them to the display, so I prefer to use driver chips controlled by an SPI synchronous serial interface. In the past I’ve used Allegro drivers such as the A6275 octal LED sink driver and the UCN5891A or UCN5895A octal source driver, but unfortunately these have all been discontinued.

The A6275 sink driver was quite convenient in that it used internal current mirrors, so it controlled the current on all outputs based on a single external resistor, avoiding the need for current-limiting resistors for each LED cathode line. Allegro also made a 16-bit version, the A6276.

It is not easy to find suitable parts still made in DIP (through-hole) packages, since so much of the world has moved to SMD. As it happens, Microchip, which acquired Micrel a few years back, still offers the MIC5891 source driver in a DIP package, though the saturation voltage specs is slightly worse than the Allegro UCN5891A, and much worse than the Allegro UCN5895A.

I wasn’t quite so lucky with the A6275. Toshiba made a pin-compatible part, the TB62705, but they’ve discontinued it. On Semiconductor offers the CAT4008, which is pin-compatible, but not available in through-hole. Finally I found the TI TLC5916, which is not pin-compatible, but is still offered in DIP. The TLC5916 actually has increased functionality compared to the A6275 et al., including programmable intensity compensation and fault detection, but I have no plan to use those features.

The board will run on nominally 5V from USB, provided through the MicroUSB connector of the Cmod-A7 module. However, the Vbus voltage at a USB device may be as low as 4V, and the Cmod-A7 has a schottky diode in series from the USB Vbus to its header pin, dropping another few hundred millivolts. The LEDs have a forward voltage of around 2V, and the saturation voltage of the MIC5891 can be as high as 2.5V when sourcing 350mA. The TIL5916 sink driver controls the current by varying its output voltage. After adding this all up, it’s unclear whether there’s enough voltage to drive the LEDs. The MIC5891 saturation voltage is lower when the current is lower, so I need to determine what LED current is needed at 15:1 multiplexing.

I’ve put a Cmod-A7-15T, TLC5916, MIC5891, and LTP-305HR on a breadboard for testing, along with a TIL311 hexadecimal display for comparison:


I used a MicroBlaze soft-core processor in the FPGA to control everything for test purposes. I am using PWM to control the enable of the source driver, so I can test running at 1/15 duty cycle, even though I don’t yet have the actual display multiplexing running.

I’ve found that with approximately 1/15 duty cycle and with a 1.5K ohm resistor on the sink drivers, I get LTP-305HR display intensity that seems comparable to the TIL311. The TLC5916 sink driver will sink current at 18.75/Rext A, so with a 1.5K resistor that’s about 12.5mA per LED. For the full matrix, a maximum of 14 LEDs will be on simultaneously, so the maximum source driver current will be 175mA, so the MIC5891 source driver saturation voltage should be under 2.4V, though I haven’t actually measured it.

The hexadecimal font to look like the traditional displays will never have more than three LEDs on in any single column of the center three columns of a character, so if I electrically stagger the two logical rows of displays, so that the left and right edge columns of the top row displays are not coincident with the edge columns of the bottom row displays, then no more than 10 LEDs will be illuminated simultaneously, which will further reduce the peak current to 125mA. I may also put some higher value capacitors next to the decoupling capacitors for the drivers, to further average the overall display current.

The FPGA output pins have Voh below 3.3V, while the display drivers, which run on 5V, have Vih(min) of 3.5V. I’m cheating on my breadboard, counting on the drivers to actually have a threshold somewhat below 3.3V, which in practice at they typically do, at least at room temperature. On the real FPGA-Elf board, I will use an SN74AHCT245 to act as a level translator for various signals. One channel of the ’245 will be used with a voltage divider to shift the data output of the last driver chip down to 3.3V level for input back to the FPGA.

One issue with the LTP-305HR compared to the older HP and TI hexadecimal displays is that it uses 635nm “high efficiency red” LEDs, rather than 650nm LEDs which were much more common in the past. To me, 635nm looks orange-red rather than red, but then, I have partial red-green color blindness, so the frequency response of the green pigment in my eyes is shifted closer to red, and I see some colors differently than people with normal color vision. I need to show the TIL311 and LTP-305HR to someone with normal color vision, and see whether they perceive as much difference in the hue.

This entry was posted in FPGA, General, RetroChallenge. Bookmark the permalink.

Leave a Reply