Full multiplexed display for RC2017/10

I’ve now got full multiplexed display operating on the breadboard prototype for my RC2017/10 project:

37498309356_4428950004_z

I also shot a brief video showing chaning hexadecimal values.

There are six 5×7 displays, physically all in one column to fit the breadboard, but logically arranged as two rows of three columns. The code running on the Microblaze configures a timer to get a 15 kHz interrupt, and each invocation of the interrupt handler outputs 32 bits via the SPI port to the display drivers. 15 bits are the column data, with only one bit set at a time. 14 bits are the row data. The remaining three bits are unused.

Each successive interrupt advances to the next column. Since there are 15 columns, the entire display is refreshed at a 1 kHz rate.

While I’m glad to have it working, it does not work as well as I would have liked. The pixel intensity varies more than I’d hoped, and pixels that should be off are dimly illuminated. (This shows up worse in the photo and video than looking at it in-person.)

I think the pixel intensity variation occurs because I don’t really have enough voltage. There’s nominally 5V from USB Vbus, but the Cmod-A7 has a schottky diode between Vbus and the header pin. At the supply pins of the display driver ICs, the measured supply voltage ranges from 4.27 to 4.4 volts. The source drivers can drop up to 2.5V, and the LED forward drop is around 2V, leaving insufficient voltage range for the current-controlled LED sink drivers to actually achieve good current control

The variation between 4.27 and 4.4V is due to variation in the load. I was lazy and didn’t put any decoupling capacitors on the breadboard. Adding typical 0.1uF decoupling capacitors is probably nowhere near enough to filter this out; I probably need 1.0 or even 10 uF ceramic capacitors paralleled with much higher capacitance electrolytics, as close to the driver chips as possible.

The problem with off pixels being dimly illuminated seems to be due to the source drivers turning off very slowly. Here are the SPI waveforms along with one representative column drive waveform:

37498309506_123cd5df7b_z

When the column driver is enabled, 1/15 of the time, its voltage is about 2.43V. When it is disabled, there is a small immediate drop, but it takes it quite a while to drop to its minimum of 51mV. At a 15 kHz rate, a 32 bit word is shifted out the SPI port of the processor into the display drivers. Channel 02 shown is the SPI “slave select” which acts as the latch signal to the drivers. Channel 04 is the analog waveform of one of the column source drivers.

When the column driver is enabled, 1/15 of the time, its voltage is about 2.43V. When it is disabled, there is a small immediate drop, but it takes it quite a while to drop to its minimum of 51mV. Because of the slow drop, the row drivers that are active during the next few columns will sink a lesser amount of current from this column.

I will have to make a decision soon as to whether to continue with this design for the RC2017/10 project, or to revert to using the traditional 5082-7340 or TIL311 hexadecimal displays.

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

Leave a Reply