RP2040 HUB75 DMA Driver

it would be interesting to consider using a cheap rp2040 Rasberry Pico board. It is relatively fast with a very interesting PIO interface and has a built-in memory up to 16 MB.
The RP2040 code for working with RGB HUB75 matrices already exists in several libraries, including my implementation.

Very cool to see a HUB75 driver for the RP2040. I don’t have time to dig into your code but I’m curious about the details. Is DMA able to refresh the whole panel without significant CPU usage? How often do you need to have (I assume) an interrupt to maintain the DMA engine? What color depth do you currently support and do you think it can support 12 bit per channel color to be competitive with the Teensy and ESP32?

(I moved this to a new topic as I think it was off topic for the thread you posted in, but also wanted others to be able to find your post easier if they’re looking for a RP2040 HUB75 library)

Hi
The library was initiated as tool for using monochrome HUB12 panels. The first version for HUB75 RGB matrices was based on the code of the Adafruit RGBpanel library, which uses the 16bit HighColor pixel format. Initially, the library is focused on the popular STM32 Bluepil boards, which have only 20k RAM, so I did not think about a greater colour depth.
The library now also supports controllers with much more memory, so 8-bit colour support is planned but not yet a priority. Support for higher colour depth, such as 12bit - I did not even plan. As far as I know, even the most powerful boards in other libraries can support 12bit colour on small panels only - 64x32 or 64x64. When the screen size increases, any library quickly encounters the limit of the update rate of the matrices themselves and already at a size about 256x256 is forced to reduce the colour depth to 3-4bpp and update rate below100fps. So I still use 16bit colour.

Support for rp2040 mcu in the library appeared only in the latest release, so the code is not final at all. However, it can drive a chain of 16 panels 64x32 16sc (i.e. screen of 1024x32 or 512x64 size) with a colour depth of 4bpp and a refresh rate of about 100 fps.

Yes, the library used DMA and can refresh the panel data without directly involve the CPU, it used only to initiate process. So the loading of the CPU depends little on the screen size and is mainly determined by the refresh rate. For RP2040 board the CPU usage will be about 3% on 100 fps update and near 5% for 200fps.
The interrupt interval also depends on frame rate. The library uses BCM coding for colour levels therefore interrupt interval is variable.It base value for 200fps rate is 40us.

Of course, the low colour depth puts the library at a disadvantage. However, 8-12 bits per channel is not always needed. For info-boards and pointers, size is much more important. With the exception of colour bpp , it seems to me that the library features is quite at the level of similar libraries for the esp32 boards :slight_smile: Of course, the Teensy core is much more powerful.

By the way, the library has its advantages. Support for outdoor multi-row matrices ( like 32x16 2scan, 32x16 4scan or 64x32 8scan) is not a problem and mostly included in base code. As I already wrote in the other topic, due to the non-standard pixel order in the buffer , outdoor matrices can be connected into daisy chains just as easily as regular panels.

@Louis
I looked under hood of Smartmatrix and if I understood correctly, the RP2040 refresh process is very similar to the Teensy update method in the SmartMatrix library. As I see in the MatrixTeensy4Hub75Refresh_Impl.h file - after the next portion of data is displayed on the matrix, a timer interrupt is configured with a period proportional to the display duration of the current bitplane. After the period expires, an interrupt is fired, which starts the DMA transfer to load the next portion of data into the FlexIO state machine. All data output to the matrix and clocking control is carried out by FlexIO without loading the main MCU.
The brightness is controlled by launching another timer, the duration of which is the duration of the bitplane display, multiplied by dimming factor.

I hope I correctly described the general principle. If so, then in the case of RP2040 everything works very similarly, with the only difference being that for this processor a small state machine is called PIO.