32x32 1/8 scan panel support

[arahasya]

Hi Robert, really need your help here. I have got the matrix driver board and populated it

I am able to flash the Atxmega successfully. But when I connect to the pi and start the pi the LED on the driver board is turned on for a couple of seconds and it turns off. Also tried connecting to a display. Didn't get any output.

[arahasya]

It is working now. I think the problem was with pi. Using a different pi made it work

I have 4 chains with 4 panels each of 32x32

Which are 1/8 scan. When I connected the first chain this is the output : -

The internal mapping is different of these panels. Can you use panel arrangement code from henner's library?

[rjrouquette]

I've added the RemapInterleaved32A class for you. You can create an instance of it and set it as the active pixel mapping using *void MatrixDrive::setPixelMapping(PixelMapping pixelMap). If you are already using a custom PixelMapping instance, you can invoke void RemapInterleaved32A::remap(unsigned &x, unsigned &y)** as the last line within your own remap function.

Keep in mind that from the perspective of the driver, you have four chains with 8 x 64 panels. I'm sure you've already updated your pi config to match this, but if you have not, the math is fairly simple:

• DPI Height = 8 * PWM_BITS + 1 (with 11-bit PWM this is 89)
• DPI Width = 32 + 64 * CHAIN_LENGTH (with 4 panels in a chain this is 288)

[rjrouquette]

One additional note. You'll also need to use the new HUB75R row format to support the 1/8 scan panels. The HUB75 format expects 16 rows and will produce dead regions in the canvas that are not displayed. Hope this helps.

[arahasya]

I tried all the changes you have given but getting blank output with it

Why is the matrix height getting calculated to 64 instead of 128?

[rjrouquette]

256 x 64 is the raw chain raster as seen by the driver. RemapInterleaved32A translates that into a 128 x 128 canvas. The panel is blank because I made a mistake when I estimated the DPI height. It should actually be 121. I had forgotten that are 15 bit planes for 11-bit PWM depth with a chain length of 256. The panel appears blank because the MSBs of the PWM are effectively blank.

As to your earlier email about the DPI resolution, here's a basic rundown: My driver code and the adapter board use the DPI which is a 24-bit parallel video interface that includes HSYNC, VSYNC, and a pixel clock. The software does not drive the GPIO pins directly, but instead uses the linux frame buffer to populate the DPI with 24-bit words that are clocked out to the driver board. Those 24-bit words are level shifted and clocked into the RGB panels directly, The XMega on the adapter board snoops on the red byte of the DPI bus to determine the PWM length and row select address value. The adapter board can only drive 4 chains because there are only 24-bits on the DPI bus and each panel consumes 6-bits (2x RGB bits). As a result, the DPI frame buffer height is the product of the number of scan rows and the number of PWM bit planes in addition to a dead scan line to allow for the completion of the PWM pulse for the last scan line.

[rjrouquette]

I've added two new functions to the MatrixDriver class that estimate the new dimensions of the canvas after the pixel mapping is applied. Hope that helps.

[arahasya]

Now getting similar previous output with height 121 and regular mapping.

The remap is giving blank output. Is there a bug with this new remapping?

Also the remapping dimension is getting calculated slightly wrong : -

matrix canvas remapped as 129 x 130

[rjrouquette]

I think the blank output with remapping is because void displayAddress(uint32_t addr) is still using the getWidth() function which puts the text outside of the displayable range. I've also pushed a hopeful fix for the dimension estimation.

[arahasya]

Yes. So I set x as 0. This is the output -

[rjrouquette]

I sadly don't have that type of panel to test with, so I apologize for the back-and-forth. I've pushed a change to RemapInterleaved32A that should hopefully make it work.

[arahasya]

Awesome!

Thank you for your amazing work!

So I plan to display videos to a matrix with 448x128 resolution. which is more than thrice of my current setup. I have got more panels which I will arrange soon. Just want to know how do you calculate the refresh rate used in the boot config? What refresh rate should I expect for 448x128 1/8 scan with video output from pi?

[rjrouquette]

Assuming that your y = 0 in that image, I think the interleaving order is backwards, so I've pushed a fix for that.

For an array with a width of 448 and a height of 128 using those same 32x32 1/8 scan panels you should configure the DPI as such:

• width = 928 ((448 * 2) + 32)
• height = 121 ((8 * 15) + 1)

This will give you a refresh rate of about 282 Hz with a pixel clock of 32 MHz.

[rjrouquette]

Also, I didn't notice it at first, but it looks like there is horizontal bleed on the "1". This is probably because 32 MHz is too fast for the panels you have, so I would recommend trying 19.2 MHz as the pixel clock if you continue to see that. This would reduce your refresh rate to around 170 Hz.

[arahasya]

Oh sorry. Please undo the last commit. The earlier code was fine. My last chain in the image is actually the first output chain from the driver. Can you please give the formula for the refresh rate calculation?

[rjrouquette]

My bug fix wasn't for your chain order, it was to fix the 8-pixel vertical offset. refresh rate = pixel clock / (dpi width * (dpi height + 1))

[arahasya]

with the latest commit -

[rjrouquette]

Oh, sorry about that I had the XOR bit mask wrong. Should be correct now.

[arahasya]

All good now. Thanks for your help! I will try adding support for 1/4 scan panels when I arrange them. Hopefully soon.

[rjrouquette]

Glad it's working. Hope your project goes well.