Add support for LED drivers with upper and/or lower ghosting

[daveythacher]

In order to support higher refresh rate you need to use LED drivers with ghosting logic. This may not work with the existing logic. However is probably easy to integrate.

These are required due to parasitic capacitance in LED Matrix which cause the LEDs to light slight for brief periods of time in a manner which is undesired. Current flows through the LEDs into the capacitors during charge of the capacitors. This stops when the capacitor reaches a voltage which blocks the LED from having enough forward voltage to allow enough forward current to light the LEDs. The solution to this is, is to charge the capacitors from the low side.

The high side may also have some capacitance which could cause problems during row changes. This is generally fixed by using pull down resistors and blanking time. This function should mostly be supported already. This feature needs low side drivers to be meaningful. The low side will block all the LEDs from lighting while the high side capacitors discharge, allowing the display to be completely off.

Note without these the max refresh rate is usually something like 240Hz. Most other code bases are only capable of this. Drivers which are believed to be accessible supporting this are TI drivers and MBI5124.

[daveythacher]

This is feature will be used to build custom panels without the use of hardware PWM LED drivers. This should allow the refresh rate to be 1-2kHz. This is a somewhat pricey way to go, however it avoids NDA and Ti components are expensive.

It is potentially possible to get this working using pull up and pull down resistors using standard constant current shift registers or basic shift registers. However this has not be fully explored. This would enable just about anyone to build a high refresh LED display on PoE. However the power loss and cost have not been factored in. Timing performance is casually assumed to be trivial.

[daveythacher]

Note you need around 3kHz for this to be flicker free. This is required due to multiplexing and there is nothing you can really do about it. This can be done on pre-made panels in many cases but requires lowering the color depth and possibly chain length. Note as the refresh rate increases ghosting generally becomes more observable and blanking time is required to allow the RC times to pass.

Anti-ghosting technology without discrete blanking signal will need to use S-PWM. Analog dot correct may not be required however dot correct is likely required as part of this. See issue #6 and #7 for more details.

Anti-ghosting technology can be added without special logic. On the high side, assuming PMOS drivers, you will need a pull down capable of draining the parasitic capacitance. On the low side you will need a pull up capable of charging the parasitic capacitance. For highest power efficiency these will need to be dis-connectable. For quickest RC times these may wish to have low resistance values. Note low resistance may result in EMI. Using 10k resistors may provide low cost options, but may struggle with RC times.

Note the high side drivers, assuming PMOS, should be low resistance for the sake of color consistency if not using constant current drivers. This can save cost but may result in less color accuracy and consistency. Dot correct would be required to manage this. It is believed this can be done using digital control. If the dot correction values range from 0.5 to 1.0 of the current limit. (Using fixed point math.) Increasing the number of bit should allow granularity required. This will increase the number of PWM bits potentially significantly or by only a single bit.

Careful observation of the PWM period time is required for flicker free using high refresh rate. The whole period time must be present. There is an interesting trick of zeroing out some of the BCM shifts, however I am not sure BCM is recommended at higher refresh rates. This puts more stress on the controller. However for some applications the RP2040 is capable.

[daveythacher]

In order to support non-hardware PWM drivers, I will need to create custom panels using 2 HUB75 connectors. Each responsible for a 16x8 section of a 16x16 module. This complicates the code somewhat and I am still considering this.

[daveythacher]

In order to support non-hardware PWM drivers, I will need to create custom panels using 2 HUB75 connectors. Each responsible for a 16x8 section of a 16x16 module. This complicates the code somewhat and I am still considering this.

Non-hardware PWM drivers are painful. They require so much IO. Before the RP2040, the only known configuration capable of flicker free is with a FPGA. The RPI PICO module is well under the cost of a MCU and FPGA combination. This combination is also believed to support the required power efficiency for supporting control logic plus microprocessor within 15 W (PoE) power budget.

There may be a way for the MCU and FPGA combination or using the FPGA alone to break even with multiple RPI PICO modules. However this may have EMI and signaling issues. The complexity of code support is not as good with HDL as it is with C/C++. Non-hardware PWM drivers also require a lot of data movement which may complicate things in other ways also. (Was able to avoid this in smaller scale conceptual experiments. However this is to be taken with a grain of salt.)

FPGA was previously believed to be the only means of getting traditional PWM instead of BCM. However the RP2040 is capable using software tricks to achieve this in small sections. This is believed to require decent memory performance.

[daveythacher]

1.25kHz is the min frequency recommendation for low flicker. At 3kHz it is assumed that no flicker will occur. Cameras may still see this multiplexing however there should be minimal flicker from the panel if the frequency is this fast.

[daveythacher]

Relates to #14, #15 #16, #17 and #22