What's the maximum resolution possible with 24bpp colour?

[mrcodetastic]

I am curious to know what the resolution possibilities are with the RP2040. Coming getting an esp32 background I have no idea.

Any ideas what is possible with this SoC? I see it generally has much less SRAM than an esp32, but not sure if that translates to less possibilities of long chains.

[daveythacher]

The max resolution for 24bpp on standard panels would be 16x32. This would be near the max refresh of 240Hz used by many 16x32 panels. I got a set that is capable of more if you lower the color depth and doctor them a little.

This actually comes in really close to the max color depth for them too. Most LEDs are only visible at 2-4nA. In my panels the blue LED has the lowest forward current of 8mA. Which means 11-12 bits of color depth, however with multiplex of 8 this becomes 24bpp. This does not include any dot correction. (My current thinking is dot correction would reduce the refresh to 120Hz to keep 24bpp color. I am thinking this belongs in the application logic off controller.)

This code base is built to use a micro-controller per panel. (This assumes 25MHz is fully used.) I connect the controller directly to the back for signal integrity issues. The cost of the controller is very important.

If you lower the refresh you could do 16x64 or 32x32, but this may have serious flicker problems. For hardware PWM panels and hardware PWM panels with SRAM I am targeting 64x128 as the max.

In my application I lower the color depth to lower the power for PoE which allows me to increase the refresh to get less flicker. I looked at this using small FPGA but the cost was too high compared to using multiple RP2040s. I was able to use 2D array with PIO to lower interrupt rates.

[daveythacher]

Now this assumes you want 24bpp color. There is a configuration trick where you get less than 24bpp but market 24bpp. This involves zeroing out the lower bits. (Hold the display off for the time of these bitplanes in BCM. Then start shifting when you have more time.) This allows you to increase the period without increasing the period.

The truth of the matter is you lower the color depth or the accuracy of the lower colors. The reason to do this is configuration. If you do not know the multiplex or need to update the bit count at runtime to improve locality, re-scaling the look up table can be painful. This can be corrected in some implementations at compile time.

In practice you can get fairly good color depth with 9-12bpp. Distance and resolution will determine color depth anyhow.

So if you wanted 12bpp, this increases the resolution by a factor of 16. This would in theory be capable of 64x128 or 128x128. For 9bpp, I think it may be possible to do 128x128 or 128x256. (I am planning to say do not exceed 64x128.) Anything below 9bpp is asking for trouble.

To get higher color depth with higher refreshes you need parallel chains or hardware PWM. The RP2040 lacks the memory for parallel chains. For the most part I am using the RP2040's large L1 cache, which supports DMA access. PIO is used for timing and clock automation in BCM. PIO is used for timing, lat and clock automation in traditional PWM, which lowers interrupt rate. BCM lowers interrupt rate, but you still have to allocate enough CPU as if it doesn't. (Unless you use preemption, which is hard to do in library friendly manner on RP2040.)

This code base is compile time configuration. Therefore there is no configuration tricks. If you configure it for 9bpp it is not 24bpp. The serial interface uses 48bpp which will be scaled into 9bpp. The application logic will create a 9bpp value then scale it to 48bpp linearly. The firmware will scale it back to 9bpp. (This is done for consistency between panel types, however this could be changed.)

[daveythacher]

I am not sure how well the CPU will handle 128x256. You could offload the computation, but this would be syncing 48KB at 30FPS or 1.5MBps. (This is doable with a 4 or 8 bit parallel bus using PIO. Not many of the serial links are capable of this unless bonded together.)

[daveythacher]

The RP2040 uses SRAM so there is little need for a runtime trick to improve stability refresh with DRAM. I do not drop least significant bit planes to improve refresh. I know I can reliably do the least significant bit plane at compile time. To get this level of confidence in a DRAM system you would need to verify the DRAM system or build a custom cache using DMA/MCU on small SRAM block, which may not work with wide DRAM. A dedicated single core with L2 may provide this. (A dual core could be used to prefetch.) However I would want wide RAM bus with low latency RAM and arbitration would need to be enforced. This would be multi-SMP domain, which gets expensive. Using internal MCU is likely cheaper but the locality is lower without custom tricks.

If you increase the locality the cost explodes. LEDs love SRAM as we mostly build memory mapped controllers. These controllers generally favor high bandwidth over latency. Particularly for high channel count. Traditional PWM increases the memory density and bandwidth, which is where BCM usually steps in. (Along with reducing computation and memory look ups.) As you increase the density you increase the cost.

In smaller displays using external MCUs like RP2040 can be economical. However their scaling becomes more subjective with size. GEN 3 panels use small SRAM memories which are fairly economical if you die shrink. This magic likely has to do with pin driver scaling. You pay for the space not the transistor. So if the geometry of the shrinking creates extra space you can increase the transistor count without increasing the cost. This scaling will always be better than the scaling for external logic based on geometry.

Now external logic has a trick it can play. This trick is DRAM. The irony is SRAM LED drivers improve density against DRAM. Eventually DRAM could break down on GEN 1. (I doubt it.) However GEN 2 and GEN 3 improve the locality/density requirements. This is why most controllers are actually based on DRAM. I suspect there could be a custom implementation within the receivers and possibly a processor. (Maybe a coprocessor for traditional PWM, however I suspect they use BCM on GEN 1.)

Microcontrollers are low cost platforms which in 32-bit core generally have a large amount of RAM. Microcontrollers generally use SRAM for cost and performance reasons. Microcontrollers generally favor determinism and random operations. This mostly a function of locality and latency within the subsystem. Microprocessors are becoming more capable, however can still struggle with random operations. Many protocols are moving toward sequential operations, which DRAM prefers. (Sequential can see the future, but random cannot.)

Low latency audio is random by definition. Increasing the latency, channels, bit rate, etc. tends to make it more sequential. LED displays tend to be sequential. LED displays become random when the locality is violated. Many processors bail themselves out with huge locality and wide DRAM. Microprocessors may switch to small locality with wide DRAM and manual prefetch? (In embedded systems.) The only microprocessor I am aware of which is capable of this is Zynq.

Note a runtime configuration tool more than likely could detect the timing issues and scale back the number of bit planes and time per bit plane.

[daveythacher]

I can calculate the max amount of RAM from the HUB75 connector it self. Find the min refresh rate, which is something like 95Hz. Find the max serial clock assuming no fan out issues, which is something like 25MHz. Assuming I need 1 byte per HUB75 then I am left with 256KB per chain. If I support double buffering this increases to 512KBs required.

This is significantly more than the RP2040 has available and I need SRAM for the CPU to run a full speed. Therefore the max for the RP2040 is something like one third of this or around 192KB. (This is calling it fairly close. I reserve 64KB for code and 8K for stack(s).)

This would enable 48 LEDs in single scan to use 12 bit PWM. I can increase the number of LEDs using higher multiplex ratios. So I think the max is something like 768 LEDs in 16x48 or 512 LEDs in 16x32. (Using 24bpp.)

Using BCM the number of pixels increases to something like 2048 in 32x64. (Using 24bpp.) In this case the RP2040 has more than enough RAM. The processing power is likely capable of this also.

The issue with the standard panels is the refresh rate is fairly low. Trying to increase the refresh rate from 95Hz to 3000Hz reduces the max color depth to something like 9bpp for the same number of LEDs. Or reduces the max LED count to 16 for PWM and 64 for BCM to keep 24bpp.

Note you do not get to use all of the 24bpp for color due to dot correction. Also 3000Hz may be unsuitable for BCM.

[daveythacher]

If willing to make some tradeoffs you can increase the size, however the question forbids this.

[daveythacher]

When you factor in inter-process communication in the worst case with double buffering the memory size required is something like 4-5 times the memory requirement per chain. This means 1MB to 1.25MB per chain. We will not find many micro-controllers with this.

We will likely need to use DRAM to get this kind of capacity and we will need to manage the memory interface carefully. DDR is certainly capable of this however SDRAM used in some micro-controllers may struggle. Not all microprocessors are capable of providing DDR capable of this in all cases.

[daveythacher]

The processing power of the RP2040 is probably the biggest issue. Assuming it takes 10 cycles per pin, there are 6 pins, you compute 30 frames per second, etc. This limits the amount of memory required to around 64KB per chain without double buffering. (Assuming 125MHz Cortex-M0+ core. Cortex-M7 would do better. Multi-core Cortex-A with NEON would be even better given decent memory performance.)

This predicts another problem which is you need to draw the frame off chip. This requires some kind of communication to the RP2040. This can be as high as 24-768KB, 30 times a second. Or 0.7-22.5MBps, which is possible with PIO implementing 8-bit bus. Things work differently with SRAM LED Drivers, which could allow you to use more RAM than you actually have.

[daveythacher]

Note I do not really believe the SRAM LED Drivers are sane for most applications. PWM LED Drivers seem very practical.

[daveythacher]

The limit per chain is something like 8192 or 16384 per chain and this may be aggressive. This holds regardless of LED driver type. SRAM PWM LED drivers unlocks full quality and size. PWM LED drivers unlocks fully quality at 16x32. Standard drivers require some kind of trade off.