Extension idea - a method to do a direct framebuffer transfer from PC

[kocinski15]

I am throwing in an idea that is very simple to implement that opens a new mode of operation:
Raw writing the whole framebuffer.
A new method:

/--------------------------------------------------------------------------------------/
void DMD_RGB_BASE::loadFrame(const uint8_t* src, uint16_t len)
{
uint16_t expected = nRows * WIDTH;
if (len != expected) return;

uint8_t* dst = matrixbuff[backindex];
uint16_t dl = displ_len;

for (uint16_t row = 0; row < nRows; row++) {
	for (uint16_t col = 0; col < (uint16_t)WIDTH; col++) {
		uint8_t packed = src[row * WIDTH + col];
		uint8_t upper = packed & 0x07;
		uint8_t lower = (packed >> 3) & 0x07;
		uint8_t val = (lower << 3) | upper;

		uint16_t base = row * WIDTH + col;
		for (uint8_t p = 0; p < nPlanes; p++) {
			dst[base + p * dl] = val;
		}
	}
}

}

this method opens opportunity to do the graphics preparation on external machine and simply transfer bulk farmebuffer basically turning controller into a simple pixel pump.
If you share my thoughts, please check out the code and add this functionality.
A fast DMA based UART transfer will be enough to offload all graphics and focus on abstraction layer of pixel pumping to various models of LED modules.

[board707]

Hi @kocinski15
I think this is a great idea. Moreover, I've been thinking for a while about separating the library graphic functions from the actual hardware handling of the panels.
The portion of the library that works with the panels should contain only the hardware interaction functions that loads the data from the buffer. Furthermore, the library's operation will be independent of how the buffer is filled—by the built-in graphics library, an external package, or even transmitted over the network or serial.
This would allow for the integration of various graphics libraries, not just Adafruit, as is currently the case. Furthermore, buffer handling functions could be made more efficient if the buffer format weren't tied to the data format of a specific panel.
However, this approach also has its drawbacks. Firstly, another intermediate buffer would require additional memory, which could be problematic on boards with low RAM. Secondly, I don't think the code changes would be as simple as you describe.

Regarding your code, I understand it's just an example to illustrate the idea? Since it writes the same value across all bitplanes...

        uint16_t base = row * WIDTH + col;
		for (uint8_t p = 0; p < nPlanes; p++) {
			dst[base + p * dl] = val;

[kocinski15]

Yeah, treat it as a template. I haven't realy tested it yet.
I am going to use it to mirror PC screen region through usart.
With such simplified version the next step is to utilize more color depth of spwm chips , ultimately adding gamma correction to the process.
Stm32f412 is easy accessible with 256kB ram and full compatibility with f401/f411 defined in maple core.

[board707]

the next step is to utilize more color depth of spwm chips , ultimately adding gamma correction to the process.

The first thing we'll have to do is separate the graphics and hardware components in the current code. After that, it's logical to move on to what you've written.
Unfortunately, I don't have time to work on that right now. If you come up with anything, please keep me posted.

Stm32f412 is easy accessible with 256kB ram

I think that using RP2040/2350 is more promising

[kocinski15]

the next step is to utilize more color depth of spwm chips , ultimately adding gamma correction to the process.

The first thing we'll have to do is separate the graphics and hardware components in the current code. After that, it's logical to move on to what you've written.

Unfortunately, I don't have time to work on that right now. If you come up with anything, please keep me posted.

Stm32f412 is easy accessible with 256kB ram

I think that using RP2040/2350 is more promising

Right. RP is more capable and supported by newer arduino core in your library. For now i worked more with STM just because it resulted in stable picture as opposed to RPI code. Shall i give RPI a try after all discoveries while working on icn1065? My modules use FM6373/DP32020 set.