Various muxpattern types

[vortigont]

Let's make it a new discussion here, @mrfaptastic.
So I've checked the reference - muxpattern is just a way to handle panels with indirect address lines and scan types, right?
for ex:

1. a panel has 64x32 physical pixels, but electrically it is 16 rows of shift regs 128 px each, it just wraps on 64's pixel as a new row physically.
2. a user (or manufacturer) intentionally connects one of the color line's output to another color line input, i.e. R0 output connects to R1 input. So resulting in less pins used and twice as long rows of shift regs and less address lines.

So how to deal with that? My idea is both options are a question of coordinates transformation like we have in a VirtualDisp class. And it would be best to keep DMA buffers size match to the physical length of resulting shift registers. All overlaying transformations should take place in wrappers, VirtualDisp or something new. We may think of some inherited classes from the base, each one implements some specific mux pattern. The idea is to keep base logic as fast and simple as possible, so as no to mess with Fast functions which are heavily optimized to shift regs length. We may end up in a two layers of transformation - first is a VirtualDisp and second is muxpattern.

[board707]

hello @vortigont
this topic is interesting to me, because I work with similar panels on stm32 in the arduino environment.

One small note to your referencing the PxMatrix library.
It seems to me that there is one inaccurate concept in the comments in PxMatrix, which is very important for the issue under discussion.
The author considers to be normal the sequential arrangement of pixels, row by row (below is a quote from the file PxMatrix.h, line 838):

// Normally the bytes in one buffer would be sequencial, e.g.
  // 0-1-2-3-
  // 0-1-2-3- 

But this is true only for panels with a single row mux pattern - i.e., indoor panels where a scan is one half of the height - for example 64x32, scan 1/16.
For panels where the mux pattern contains several rows, normal is not a sequential passage of rows, but a zigzag:
Not this: (pattern 1)

[0L-0H] - [1L-1H] - [2L-2H] - [3L-3H] - to line 2
[4L-4H] - [5L-5H] - [6L-6H] - [7L-7H] - to line 3

but this (pattern 2)

[0L-0H]   [2L-2H]   [4L-4H]   [6L-6H] 
   |    /    |    /    |    /    |
[1L-1H]   [3L-3H]   [5L-5H]   [7L-7H] 

if we state the last as the norm and will reconstruct internal program buffer according to it - the geometric transformation for indoor panels will become much easier.
At the same time, for panels with a single line mux pattern, this will not add complexity, since it is easy to see that for a single line, the patterns 1 and 2 are equivalent.
After I changed the internal buffer structure in my program from pattern1 to pattern2 , the size of the coordinate transformation code for the zigzag pattern decreased from more than 20 lines to only 2

[vortigont]

Hi @board707,
yes, you are right about the line pattern, but it is only true for a panel chain in a normal horizontal orientation.
Real life combined panels usually a bit more complicated than a simple zig-zag. It might include cascaded panels in both horizontal or vertical orientation and two types of chaining - zig-zag and serpentine. This makes a real mess in an attempt to create a universal transformation patterns for all cases. So this lib takes a very simple approach - a basic class implements not transformation at all. It assumes it's internal DMA buffer structure is not associated with any mux pattern at all. It just implements an array of bytes for a very long shift register - one row per each address selector.
It makes pretty easy to pump this structure to the matrix considering BCM modulation repeats etc.
All the other stuff like coordinate transformation should be implemented outside the scope of DMA buff and applied on top of plot(X,Y) methods or alike.
Some time ago I implemented some of the fastfunctions methods to speedup drawing batches of data to the DMA buff. It gives quite reasonable fill rate boost, but it quickly degrades to nothing if wrapped with various transformation conditions.
I came up to the conclusion that all such cases requires double buffering to stay fast, otherwise it does not worth the efforts.

[board707]

Hi Real life combined panels usually a bit more complicated than a simple zig-zag. It might include cascaded panels in both horizontal or vertical orientation and two types of chaining - zig-zag and serpentine. This makes a real mess in an attempt to create a universal transformation patterns for all cases.

Hi @vortigont,
I fully agree that making a universal conversion formula for all patterns is a pointless job. From my point of view, it is more correct to create a separate handler for each type of pattern, may be as template This is exactly what I do in my library.

However, this is not what I wrote in my reply. Changing the structure of buffer to "zigzag" form, as I suggest above, allows you to significantly simplify geometry transformation for each separate mux pattern. In this case the coordinate transformations will be completely independent from number of panels and its horizontal and vertical orientation. The coordinate conversion formula (very simple) for one panel and for the whole chain will be exactly the same.

[vortigont]

The coordinate conversion formula (very simple) for one panel and for the whole chain will be exactly the same.

Could you, pls elaborate here more? Sorry, I'm not catching the idea. A code example would be great also :)
Our main idea here is that we do not operate on matrix pixels collected in a dots of X and Y rows and cols, we operate with just a bunch of shift registers (6 actually - R1R2G1G2B1B2) that has n-width long. And we make sure that we fill it bit by bit with sequential data.
Its simple, but yes, it does not cover any cases were one shift register is physically wired to different rows of a square matrix.
In this lib we only transform Y coordinate for the half bottom of the panel. Actually we transform the shift register's address to the memory offset, not pixel's xy-coordinate in memory! :)
You can find that peace of code here.

https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/blob/2526ca0d2db520e3fbe4c46919e1cfd066f7f480/ESP32-HUB75-MatrixPanel-I2S-DMA.cpp#L512-L516

X coordinate is used as-is, no transformation at all, it's simply an offset in a shift register. The whole chained matrix shift register is mapped to consecutive memory region.

https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/blob/2526ca0d2db520e3fbe4c46919e1cfd066f7f480/ESP32-HUB75-MatrixPanel-I2S-DMA.cpp#L546-L547

Although if you have some nice idea how to implement a nice geometry transformation than it could be done in a VirtualMatrixPanel class or it's derivatives for different panel types. Yes, this lib is quite short of flexibility in this area.

[board707]

Our main idea here is that we do not operate on matrix pixels collected in a dots of X and Y rows and cols, we operate with just a bunch of shift registers (6 actually - R1R2G1G2B1B2) that has n-width long. And we make sure that we fill it bit by bit with sequential data.
Its simple, but yes, it does not cover any cases were one shift register is physically wired to different rows of a square matrix.
In this lib we only transform Y coordinate for the half bottom of the panel. Actually we transform the shift register's address to the memory offset, not pixel's xy-coordinate in memory! :)

Of course, I fully understand this :) But as you say yourself that such a simple direct mapping only works when each register is connected to single row on the display. If we consider panels where one register controls more than one row, the most important question is - in what order these rows are connected to each other.
I'm only talking about this, i.e. not about your current library, but about its development. In order to properly prepare a buffer for loading by DMA, you must understand the principle of joining rows in a matrix, right?

Let's go back to my first post. Take for example the case when the register controls two lines. There are several possible connections here. As I wrote before, the authors of the Pxmatrix library believe that a typical scheme for joining two rows is linear, row by row:

// 0-1-2-3
// 4-5-6-7

On the contrary, I believe that the scheme should be considered as:

// 0-2-4-6
// 1-3-5-7 

where each digit is represent 8pixel section of the matrix.
Obviously, one general scheme will not be able to cover all mux pattern options. But I made sure that the second variant requires significantly less additional transformations for each new pattern. That's exactly what I wanted to say, nothing more.

I'm sorry for the confusing explanation...
Code examples of handling outdoor matrices you can see in my library https://github.com/board707/DMD_STM32
As we discussed, I did not try to invent one general formula for all possible mux patterns, but created template classes for each specific matrix. You can see them at the end of DMD_RGB.h file.

I started building a library recently, so don't ask too much of it :)
Regards,
Dmitry

[vortigont]

Hi @board707
I've checked your project for STM32 - very interesting, although I'm not that familiar with STM's. Can't find the clocking setup, what's the fillrate for STM's with HUB75 panels?

I'm only talking about this, i.e. not about your current library, but about its development. In order to properly prepare a buffer for loading by DMA, you must understand the principle of joining rows in a matrix, right?

I got your point. This lib should have named it's methods something line updateMatrixDMABuffer(shiftreg_offset, hub75_address, r, g, b) instead of updateMatrixDMABuffer(x. y, r,g,b). It confuses people thinking that DMA buffer maps to physical rows and columns. Actually it does not.

As I wrote before, the authors of the Pxmatrix library believe that a typical scheme for joining two rows is linear, row by row:
// 0-1-2-3

I'm not quite sure what do you mean by that 0-1-2-3? Why only 4 digits? One digit => one shift register chip? I.e. FM6126A chip is 16 bit wide shift register, while SM5266P is 8 bit. And same 64x32 panel could be made in following options:

1. 4x16 bit shiftregs (per HUB75 color pin), 4 bit addressing, 1/16 scan - one chain of shift registers matches one physical row of panel's pixels
2. 8x16 bit shiftregs (per HUB75 color pin), 3 bit addressing, 1/8 scan - one chain of shift registers matches two consecutive physical rows of panel's pixels
3. 8x8 bit shiftregs (per HUB75 color pin), 4 bit addressing, 1/16 scan - one chain of shift registers matches one consecutive physical rows of panel's pixels

Whatever... I mean to say that this lib needs an additional set of classes to translate arbitrary rectangular X:Y display into (shiftreg_offset, hub75_address) pairs. I was thinking about implementing this, but I do not have the variety of those panels to test on. Well... maybe someday... :)

Pls, feel free to join our discussions on any subject!
Cheers!

[board707]

Hi @vortigont,

I'm not quite sure what do you mean by that 0-1-2-3? Why only 4 digits? One digit => one shift register chip?

It is quote from PxMatrix library, each digit is represents 8 pixels, so four digits 0-1-2-3 are represents single row of leds, because most of outdoor panels has 32x16 dimensions.

I mean to say that this lib needs an additional set of classes to translate arbitrary rectangular X:Y display into (shiftreg_offset, hub75_address) pairs. I was thinking about implementing this, but I do not have the variety of those panels to test on.

Yes, you can see similar classes in my library.
And about variety of such panels.... After implementing first two or three patterns I now can add new one without having the panel itself in my hands.

If you really interesting, please email me directly to [email protected], because is quite hard to discuss complicated thing out of native lenguage ^)
Dmitry