Support for built-in memory drivers: ICN2053\FM6353\MBI5153 (PWM)

[LAutour]

In them, data transfer is divided into: transfer of control data, data of pixels, switching of memory buffers (double buffering) and support for switching lines of the built-in memory when the image does not change (generally, line switching occurs in all buffers). Each transmission has its own DMA buffer. The CPU intervenes in the DMA only when it needs to transfer another buffer, that is, when sending frame data to driver memory.
Of the problems, this is a large amount of memory per DMA line, since the full length of the driver (16 bits) is sent to the color of each pixel. A full screen buffer in DMA RAM may simply not fit. But since the drivers have a built-in double buffer, it is possible to transfer only a few lines through the DMA buffer, if necessary filling the DMA buffer (with the help of the CPU, but for a limited time) with data from the frame buffer located in any non-DMA memory of the microcontroller, and any color depth per pixel .
Of the pluses, we get a very high screen refresh rate of up to several kHz, since it depends only on the number of lines, but not on their length. And the periodic transmission of control commands for drivers through the DMA buffer provides protection against failures of the LED panels themselves.
Implementation (interface compatible with ESP32-HUB75-MatrixPanel-I2S-DMA except initialization, support for shift drivers removed):
https://github.com/LAutour/ESP32-HUB75-MatrixPanel-I2S-DMA-icn2053

[DarrylStrong]

This is VERY interesting! I have just returned some modules with this type of driver fitted. I shall have to try this library out when I get a chance.

[mrcodetastic]

So the ICN2053 generates the Binary Code Modulation (https://hackaday.com/tag/binary-code-modulation/) for each LED? And you don't have to keep sending it data to display anything on screen?

That's a fundamental change to what this library was designed for (which was the dumb HUB75 panels that need to be driven with BCM).

Can look to include, but I think a seperate codebase is probably the best bet for the moment.

[board707]

You need to understand how these drivers are designed to operate. It is impressive how simple and effective it is.)

Ok, but where I could obtain the information to understand this?
If you start talking about this, then be consistent and tell us how it works. Don't worry about licensing restrictions - I won't rat you out :)

[board707]

@daveythacher
Seriously speaking, I would really like to understand how pvm drivers work. But in our discussion on my Github - as soon as I started asking questions - you curtailed the conversation.
You write that the drivers from TI are well documented. Is their principle of operation similar to those drivers whose datasheets are covered by a license agreement? Can documentation from Ti be a source of understanding how pvm drivers work? If yes, please provide a link to those datasheets that may be useful.

[board707]

@daveythacher
and again silence...
Why are you writing something if you are not ready to continue the discussion?
To show off how much you know?

[daveythacher]

Technically it is protected by a patent. I maybe able to find it.

[daveythacher]

Here is one patent which mentions it. (Note the versions I implemented were slightly different.) US8760458B2

Edit:
I discovered this from TI datasheets, they did not explain this very well. However the concept is captured. The patent mentions scrambled PWM or S-PWM. TI mentions ES-PWM. They would appear to be similar, however this is the limit to my speculation.

[LAutour]

Yes, once you sent a picture and you only switch the addresses of the lines via DMA. PWM brightness modulation is built into the drivers.

[DarrylStrong]

The driver ICs have 16k memory built in and the GCLK is used to increment the address of memory that is output to the LED drivers. This means that much higher refresh rates are possible as the whole image doesn't need to be sent continously.

A major advantage is that slower CPUs can be used to perform the scanning as they only have to change the row data and provide the sync signals to the ICN2053 ICs for scanning to take place, once the image has been sent that is.

[mrcodetastic]

Where do I get my hands on one of these? Got a supplier?

[DarrylStrong]

I had some but returned them as my other CPU board cannot drive the GCLK pin continously. I believe that the 'high refresh' rate outdoor boards have them but worth checking with the supplier before committing. I purchase modules from AliExpress.
These had them ...
https://www.aliexpress.com/item/32614289298.html

[LAutour]

Moved the possibilities of the virtual matrix inside the main matrix (virtual pixel redirection is enabled when there are several panels in the vertical or when the matrix is rotated). Added rotations by 90, 180 and 270 degrees, mirroring. I ordered the names so as not to get confused when expanding the code - therefore I created a new repository https://github.com/LAutour/ESP32-HUB75-MatrixPanel-DMA-ICN2053

[mrcodetastic]

Excellent work. I have updated the README to link to your library.

[board707]

@LAutour
Great work!
I have experience with these drivers, I managed support for the RGB 128x64 panel with the FM6353 driver in my library for STM32 boards.
Did you succeed to determine the code in the configuration bytes that is responsible for the brightness or do you change the brightness by changing the color?
If you don't mind, I would like to communicate with you by email without english translate

[LAutour]

board707
Написал в привате Амперки

[daveythacher]

@LAutour Do you use the SRAM or not? There was another library for the ICN2053, but they did not use the SRAM. They just used it as hardware PWM driver without SRAM. The chain length and/or refresh rate is reduced by this. (Should still be better than BCM for the same color depth. BCM actually wins at low color depth.)

[LAutour]

The OE frequency is equal to the half frequency as the CLK frequency, because it travels via the I2S data bus. If the CLK also transferred to the data bus, then the frequencies will be equal, but this is not necessary.
I don’t have a controller compatible with LEDVision and i don’t know what they will actually generate (only descriptions of driver register bits were taken).
I have a controller compatible with HDPlayer: approximately the same (may differ in supported drivers), and I have not seen any license agreements with it.
The main thing is to get a description of the driver commands and registers (well, also timings and signal polarity, but they can be found in available datasheets), otherwise at the hardware level all the drivers are simple (if you understand the level of designing digital devices), and are similar.

[board707]

@LAutour
a complete datasheet for the 2053 driver with a description of the format and values of the configuration registers was recently posted on one of the forums.

[daveythacher]

I thought the same thing about the MBI5353 or MBI5153. However the datasheet was missing register 3. It was documented in LEDVision, but not in the datasheet. Apparently it could matter, and there was likely behavior not documented in LEDVision. I may be able to discover some of it, however that would have been against the user agreement.

I was kind of disappointed, I had got a netcard implementation for the receiver cards going. (This has been accomplished by several people for different vendors.) However Colorlight would never give me a straight answer on the legality of it, so I hide it. (It was pretty rough anyhow.)

[LAutour]

By the way, LEDVision and HDPlayer do not always describe all the bits. I found the total brightness (or current) bits for the ICN2053 by searching through the undefined bits.

[daveythacher]

I would be careful with those. Some of those can do really bad things if you do not know the exact meaning of them.

[board707]

You need to understand how these drivers are designed to operate. It is impressive how simple and effective it is.)

Ok, but where I could obtain the information to understand this?
If you start talking about this, then be consistent and tell us how it works. Don't worry about licensing restrictions - I won't rat you out :)

[drvkmr]

This maybe doesn't fully belong here, but I've got my hands on hundereds of panels using MBI5153 (similar to ICN2053 from what I understand) and am struggling to get them to work. They were about to get binned but took them in just before.
I am more than happy to ship a couple of them to anyone who's interested in figuring them out - pictures here.
Also happy to send a box-full of them if you aare able to figure it out, enough to cover a wall of your living room !

[daveythacher]

In theory you can make a microcontroller proxy the microprocessor. This would soften the deadline almost completely. This is really hard to do on GEN 1 and GEN 2. However the async property of GEN 3 allows this to be mostly passive. RP2040 likely supports this.

GCLK and multiplex would need to be installed into RP2040. While the data would just pass thru. The microprocessor/microcontroller interface is no longer bound by HUB75. The microcontroller proxy will sort this out. This would allow a more traditional networking approach.

The receiver cards conceptually work like this except they have memory for GEN 1 and GEN 2. Kind of shocked they never built anything like this until I consider the multiplex timing which can vary per panel. They more than likely sort this out with the FPGA firmware. The RP2040 would need to manage this in a configurable manner.

Would be neat if the panels have a mini receiver card built in and we just had a standard IO protocol to worry with. Would also be neat if the mini receiver card was open source. Been looking into this, but NDAs are likely going to cause me to focus on TI components and GEN 1 panels without fancy initialization. (MBI5124 works pretty good by default.)

This trick would allow something like 24576 pixels on the Pi using GPIO which is 50 percent more than it would be with DPI. On a standard microcontroller the limit is likely just 8192 on the outside. The difference is more color depth and high refresh rates compared to GEN 1, so for some supporting these panel would be nice. However for many maybe nothing would come from it.

Technically you may be able to do more with GPIO on the Pi but this requires output banks. However I am making assumption about the IO stability from memory and IO access internally. This would be why using DPI is pretty much required unless using a full proxy like what is used in the receiver cards. (GEN 1 can leverage BCM to somewhat cheat this.)

[board707]

This is all interesting, but seems to go too far from the topic of the thread - support a S-PWM drivers by various MCU.

[daveythacher]

Again my current experimentation is moving away from a threaded library design. While cheaper and convenient, it comes with some issues. I am considering using small microcontroller as receiver card, which would work with anything in theory. This gets expensive with scale but that may depend. Memory and IO costs are high with LED panels.

The resource management alone breaks the user space design. Generally speaking you are looking for some kind of special interface, which you can assemble in microcontrollers but something has to manage conflicts by declaring usage. Which means it is not a pure library per say. You can try a process design on microkernel but that does not work super well either in most cases. Your kind of just stuck on IPC, which was the big advantage of threading.

DMA secretly drives the IPC under the covers. The AXI/APB buses are IPC. This is faster and cheaper than UART in many cases, but this comes with complexities of its own as mentioned before. Conflicts on these buses can create performance and priority inversions.

However the point of the matter is GCLK is critical and it wants a decent amount of time resources. Offloading this increases cost but may simplify the design. This is applicable to S-PWM drivers.

[board707]

However the point of the matter is GCLK is critical and it wants a decent amount of time resources. Offloading this increases cost but may simplify the design.

It is why I decided to move GCLK by separate hardware timer.
Multi-threading and multi-cores, including the use of a dedicated microcontroller, are other ways to solve this problem. But if the controller has a large number of timers with rich settings, like on the STM32, why not use them. The task assigned to such a timer is completely independent of the main program.

[daveythacher]

You can over provision the CPU if not careful.

[ergindemir]

The price difference between high refresh and legacy modules have vanished very recently. Soon legacy modules will be obsolete and we will have to hunt pawn shops to find a working module. I was sent a module with icnd2153 by "mistake", does anybody have an idea how to make it work?

[daveythacher]

Honestly I do not believe this will come to pass. There are three generations of panels. Most if not all hobbyists use the first generation. The current panels are made in second generation configuration. Some of these are using third generation components.

Third generation components such as this one are used for huge panels, such as 256x256 LED panels. Note these are likely only implemented in indoor and high scan configurations. I have never seen these components on anything but the upper end video wall equipment. Most of the third generation components are not documented and protected by NDA.

In summary second and third generation pre-made panels will be disappearing from the hobbyist market due to a lack of economical support for hobbyists. I have been looking into this for a while now. However NDAs and user agreements stop this cold. I know how to make many of them work using reverse engineering. I even found one trick which allows me to potentially work around this, however it is somewhat expensive and I could not determine the legality of it.

The only reason third generation is used in these panels if for high refresh/flicker free usage. This first generation largely did not support this. The second generation supports it up to around 16x32. Third generation goes significantly farther, however most limit this at 64x128. Beyond this point the controllers start to have issues potentially.

Pixel density and brightness drive the design requirements hard. In some of these cases second generation and first generation are still viable. (Mostly outdoor.) Indoor applications with large density will likely shift to third generation, but these will not be of interest to the majority of the hobbyist market without better documentation. Also high pixel density leads to other complications.

My understanding is the fast majority of people are looking for around 512 to 32768 LEDs. This is a weird split depending on the refresh rate and color depth requirements. Note most hobbyists do not even white balance. More than likely hobbyists will go back to 8x8 modules. Some may run to neopixels, which have low refresh internally and are not likely white balanced.

Hobbyist like the cost and convenience of the first generation components on second/third generation panels. Most ignore the hard core electrical stuff like ghosting which accompanies high refresh panels. Large LED counts increase processing, memory, IO and networking requirements.

[daveythacher]

Most of the panels are just hardware. Open sourcing the controllers which is mostly software is still a major hurdle which has yet to be overcome. These NDAs and user agreements are blocking this. The scaling the cost of the controllers for this software is a topic in of itself.

[mrcodetastic]

Looks like somebody made a library to drive these panels: https://github.com/CamelCaseName/HUB75Enano
and/or
https://github.com/PhantomRay/stm-led-esp32/tree/main

[hugojgl]

Hi @LAutour I am in a Project with ESP32 and Matrix LED with ICND2153, I need help and advice, are you available? i can pay you a fee

[lautour2]

in progress

[board707]

Hi
@lautour2, do you have a ICND2153 chip matrix?