Mesmerizer not driving 64x64 panels

[robertlipe]

Bug report

Setting MATRIX_HEIGHT to 64 does not bring joy for a HUB75E display.

Problem It seems a reasonable expectation that setting MATRIX_HEIGHT to 64 would light up the additional address line for strobing data on the HUB connector, allowing square matrices to work and larger real estate (yes, doubling the pixel draw load) and most effects to just rescale automatically.

Steps

1. Edit MATRIX_HEIGHT section of mesmerizer hardware
2. Build, load mesmerizer configuration
3. Replace panel.
4. Observed whacked out video

Example A representative panel would be https://www.amazon.com/gp/product/B0BYJHMFSQ/ or a variety of products of similar dot pitch and resolution from Asian suppliers.

Notes HUB75E theoretically can drive up to 256x256, but the 64x64 configurations are Really Common...and they're awesome looking.

I think the problem is that Address Line E is not being driven. The electrical specs at https://justanotherelectronicsblog.com/?p=636 https://www.sparkfun.com/news/2650 and https://www.makermodules.com/led-display-panel/ explain that the rows (the key variable when we double the height) are controlled by the four OR FIVE address lines. We shift out 64 RGB values (horizontal), pop the latch and output enable, select the LINE by driving the address pins, then strobe latch and OE again.

The taller displays (MATRIX_HEIGHT > 32) need one more address line, so they steal a ground from the original HUB75 and instead of driving ABCD, they drive ABCDE. If that 'E' pin isn't plumbed through, the addressing will be corrupted. Possible suspects include the 'E' pin not being wired, the GPIO not being configured as an output, or MATRIX_HEIGHT not being communicated to the lower levels. include/MatrixHardware_ESP32_Custom.h looks like it's trying to support 'E', s I don't think it's a case of just being forgotten.

I can get a scope on pin 8 if needed. A full logic analyzer trace would be a challenge, but not out of the question. I'd rather get confirmation whether this configuration has ever been observed to work or is even expected to work first. Is there some configuration knob beyond MATRIX_HEIGHT?

I have two of these panels plus the half-height one from Mesmerizer and would like to drive different subsets of the frame buffer over the bus to composite a larger display. For multiple panels, are we back to the issue that describing any non-rectangular subset of the frame buffer is DOA? (Let's focus on a single panel first...)

[smiliea]

Check out this library:

https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-DMA

The LED board I have uses the RUC7258 and FM6124 chips, which seem to be supported.

If the E pin is wired to the ESP-32, it looks like we need to map it to any available pin.

[davepl]

Is there anything it does that we can’t do now, or that it does better? We can already chain panels, the problem is available DMA memory, and that’ll be true of any ESP32 I think!

On Aug 28, 2023, at 7:41 PM, Andrew Smilie @.***> wrote:

Check out this library:

https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-DMA

The LED board I have uses the RUC7258 and FM6124 chips, which seem to be supported.

If the E pin is wired to the ESP-32, it looks like we need to map it to any available pin.

— Reply to this email directly, view it on GitHub https://github.com/PlummersSoftwareLLC/NightDriverStrip/issues/397#issuecomment-1696684762, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4HCF5IWRWXUCEF7Z4KIYDXXVJEVANCNFSM6AAAAAA3FYV7II. You are receiving this because you are subscribed to this thread.

[robertlipe]

There are a couple of ESP32-HUB75 libraries. That one is very popular. Maybe you're right and that starting with that and then bringing mesmerizer over to that (then known working) hardware is a wiser move than trying to debug a board I don't have schematics for.

Being able to DMA from the PSRAM to the octal SPI ram flash would be the hotness. Existing Mesmerizer isn't S3, though.

[robertlipe]

Dave, look at the SPIRAM_FRAMEBUFFER option in the page he linked. Being able to DMA from any of the available 8MB of RAM instead of just hte inbuilt 512K would be the bee's knees, no?

This discussion started because 64x64 on Mesmerizer Does Not Work. Setting a MATRIX_HEIGHT of 64 goes nowhere.

[davepl]

Huh? You lost me. Why would you move it to a different software platform because you don’t have schematics to some hardware? What hardware do you need schematics for?

I don’t know if you CAN run DMA on the S3, and that’s a hardware limitation, not a Mesmerizer issue.

Maybe I missed some context, and it’ll make more sense on the GitHub discussion page, and that’s on me, but what problem are you solving?

Cheers. Dave

On Aug 28, 2023, at 8:54 PM, Robert Lipe @.***> wrote:

There are a couple of ESP32-HUB75 libraries. That one is very popular. Maybe you're right and that starting with that and then bringing mesmerizer over to that (then known working) hardware is a wiser move than trying to debug a board I don't have schematics for.

Being able to DMA from the PSRAM to the octal SPI ram flash would be the hotness. Existing Mesmerizer isn't S3, though.

— Reply to this email directly, view it on GitHub https://github.com/PlummersSoftwareLLC/NightDriverStrip/issues/397#issuecomment-1696727289, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4HCF6CDBZJWKJFVWAR6QDXXVRV3ANCNFSM6AAAAAA3FYV7II. You are receiving this because you commented.

[davepl]

I don’t believe SERIAL peripheral interface ram can be used in place of DMA. We can (and so) use SPIRAM for the offscreen framebuffers that are ultimately copied to the DMA memory.

I think you’ve got to have enough DMA memory for every pixel in your matrix.

I’ve demonstrated 64x64 in several past videos, so it worked last I tried. Maybe it’s broken now, for all I know. But I’ve even does 64x96 with three panels and got that to work. Four was no go.

• Dave

On Aug 28, 2023, at 8:57 PM, Robert Lipe @.***> wrote:

Dave, look at the SPIRAM_FRAMEBUFFER option in the page he linked. Being able to DMA from any of the available 8MB of RAM instead of just hte inbuilt 512K would be the bee's knees, no?

This discussion started because 64x64 on Mesmerizer Does Not Work. Setting a MATRIX_HEIGHT of 64 goes nowhere.

— Reply to this email directly, view it on GitHub https://github.com/PlummersSoftwareLLC/NightDriverStrip/issues/397#issuecomment-1696728848, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4HCFZT6B5LJUEIIVOOK7LXXVSBFANCNFSM6AAAAAA3FYV7II. You are receiving this because you commented.

[robertlipe]

This bugreport was filed because 64x64 panels don't work. The different library thing is a distraction. The S3 thing is a distraction. I've lost track of how many times I've asked you if the E line is even connected.

But for the distraction - Octal SPI uses four bits and transfers on leading and trailing clock edges. At 80/120Mhz, it's pretty spiffy. As long as the DMA controller is on in the joke, it can totally DMA SPI and the later ESPs can do so. mrfaptastic's branch of the Smartmatrix code is already doing it, as demonstrated. But the ESP32 (no S2, No S3) that's in Mesmerizer hardware won't do that. It doesn't support octal SPI.

On Mon, Aug 28, 2023 at 11:02 PM David W Plummer @.***> wrote:

I don’t believe SERIAL peripheral interface ram can be used in place of DMA. We can (and so) use SPIRAM for the offscreen framebuffers that are ultimately copied to the DMA memory.

I think you’ve got to have enough DMA memory for every pixel in your matrix.

I’ve demonstrated 64x64 in several past videos, so it worked last I tried. Maybe it’s broken now, for all I know. But I’ve even does 64x96 with three panels and got that to work. Four was no go.

• Dave

On Aug 28, 2023, at 8:57 PM, Robert Lipe @.***> wrote:

Dave, look at the SPIRAM_FRAMEBUFFER option in the page he linked. Being able to DMA from any of the available 8MB of RAM instead of just hte inbuilt 512K would be the bee's knees, no?

This discussion started because 64x64 on Mesmerizer Does Not Work. Setting a MATRIX_HEIGHT of 64 goes nowhere.

— Reply to this email directly, view it on GitHub < https://github.com/PlummersSoftwareLLC/NightDriverStrip/issues/397#issuecomment-1696728848>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AA4HCFZT6B5LJUEIIVOOK7LXXVSBFANCNFSM6AAAAAA3FYV7II>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/PlummersSoftwareLLC/NightDriverStrip/issues/397#issuecomment-1696731867, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD32RD3KTMWV4JDAATB3XXVSVXANCNFSM6AAAAAA3FYV7II . You are receiving this because you authored the thread.Message ID: @.***>

[smiliea]

Dave,

Sorry - this started because I mentioned in a different thread that I just purchased a 64x64 matrix and Robert said he was having trouble getting it to work by changing the width and height #defines. He pointed me over to this bug report thread, and I have been reading up on how the hardware works for a few hours. Shift registers and latches. What I didn’t realize is the display works by interleaving like our TV’s used to do at really high speed.

I haven’t tried out the 64x64 yet, but once I do I will let everyone know how it goes. I posted a link to that library just for reference to get a different viewpoint on other implementations, and thought there may be a fix in it if a bug were in the current library.

That’s positive you were able to connect 3 panels together!

Cheers ,

Andrew

[smiliea]

I just tried a 64x64 panel, and am having errors too. I bought this matrix: xicoolee 4096 RGB Full-Color LED Matrix Panel Display 64×64 Pixels for Raspberry Pi 3mm Pitch with 2 HUB75 Interface

I changed the MATRIX_HEIGHT variable in the globals.h file and here is the output from the monitor window: Starting SmartMatrix Mallocs Heap/32-bit Memory Available: 221080 bytes total, 110580 bytes largest free block 8-bit/DMA Memory Available : 190788 bytes total, 110580 bytes largest free block Total PSRAM used: 17472 bytes total, 4174315 PSRAM bytes free SmartMatrix Layers Allocated from Heap: Heap/32-bit Memory Available: 219604 bytes total, 110580 bytes largest free block Starting SmartMatrix DMA Mallocs sizeof framestruct: 00008000 DMA Memory Available before ptr1 alloc: 123744 bytes total, 77812 bytes largest free block matrixUpdateFrames[0] pointer: 3FFD2C38 DMA Memory Available before ptr2 alloc: 123744 bytes total, 77812 bytes largest free block matrixUpdateFrames[1] pointer: 3FFE46C4 Frame Structs Allocated from Heap: Heap/32-bit Memory Available: 154036 bytes total, 77812 bytes largest free block 8-bit/DMA Memory Available : 123744 bytes total, 77812 bytes largest free block Total PSRAM used: 68416 bytes total, 4123243 PSRAM bytes free Allocating refresh buffer: lsbMsbTransitionBit of 0 requires 49152 RAM, 77812 available, leaving 28660 free: Raised lsbMsbTransitionBit to 0/7 to fit in RAM lsbMsbTransitionBit of 0 gives 38 Hz refresh, 180 requested: lsbMsbTransitionBit of 1 gives 76 Hz refresh, 180 requested: lsbMsbTransitionBit of 2 gives 150 Hz refresh, 180 requested: lsbMsbTransitionBit of 3 gives 287 Hz refresh, 180 requested: Raised lsbMsbTransitionBit to 3/7 to meet minimum refresh rate Descriptors for lsbMsbTransitionBit 3/7 with 16 rows require 6144 bytes of DMA RAM SmartMatrix Mallocs Complete Heap/32-bit Memory Available: 147860 bytes total, 77812 bytes largest free block 8-bit/DMA Memory Available : 117568 bytes total, 77812 bytes largest free block Total PSRAM used: 68416 bytes total, 4123243 PSRAM bytes free Setting up parallel I2S bus at I2S1 Matrix Refresh Rate: 95 (W) (SetupBufferManagers)(C1) Reserving 252 LED buffers for a total of 3104640 bytes... (I) (setup)(C1) Initializing splash effect manager... (W) (InitSplashEffectManager)(C1) InitSplashEffectManager (W) (InitEffectsManager)(C1) InitEffectsManager... (I) (LoadJSONFile)(C1) Attempting to read JSON file /effects.cfg (W) (LoadJSONFile)(C1) Out of memory reading JSON from file /effects.cfg - increasing buffer to 6814 bytes (W) (LoadJSONFile)(C1) Out of memory reading JSON from file /effects.cfg - increasing buffer to 8862 bytes (W) (LoadJSONFile)(C1) Out of memory reading JSON from file /effects.cfg - increasing buffer to 10910 bytes (I) (InitEffectsManager)(C1) Creating EffectManager from JSON config Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.

Core 1 register dump: PC : 0x400f2054 PS : 0x00060030 A0 : 0x800e9b35 A1 : 0x3ffb20f0 A2 : 0x3ffb2140 A3 : 0x3ffb2138 A4 : 0x00000000 A5 : 0x00000001 A6 : 0x3f418f38 A7 : 0x3ffbdb08 A8 : 0x800f2049 A9 : 0x3ffb20d0 A10 : 0x00000000 A11 : 0x3ffc08a4 A12 : 0x3ffbdac0 A13 : 0x3ffb214c A14 : 0x00000001 A15 : 0x3ffb2150 SAR : 0x00000010 EXCCAUSE: 0x0000001d EXCVADDR: 0x00000004 LBEG : 0x4008dca9 LEND : 0x4008dcb9 LCOUNT : 0xffffffff

[smiliea]

I pulled a new copy of the NightDriver Repo, changed #define MATRIX_HEIGHT 32 to #define MATRIX_HEIGHT 64 I then recompiled and uploaded it to the Mesmerizer board. I took a video of what it looks like. Please see attached.

https://github.com/PlummersSoftwareLLC/NightDriverStrip/assets/24381908/67373ce4-2902-4b67-8a2f-63d702d87a05

I had to record a very short video due to the 10 MB upload limit on GitHub.

@robertlipe, is this what you are seeing?

[davepl]

Yeah, there’s not quite enough RAM free in that scenario I think. 63K before it even gets drawing. You might want to try with a single effect in the effects table.

On Sep 2, 2023, at 5:29 PM, Andrew Smilie @.***> wrote:

68416

[smiliea]

Gotcha. I will give that a go.

[smiliea]

The ESP-32 is happy now, but the display is still now drawing incorrectly. The audio bar on the top is working perfectly.

https://github.com/PlummersSoftwareLLC/NightDriverStrip/assets/24381908/4289ff42-4918-4265-9c4a-e3554253b1f5

[smiliea]

How does this pinout compare to the 32x64 LED matrix display that works? I don't have any info on it.

[smiliea]

I am pretty sure the answer to this is buried in this documentation. I believe it has to do with the scan rate 1/16 vs 1/32 on the 64x64 panel.

https://www.sparkfun.com/news/2650

[smiliea]

This is the issue:

You must define which panel type you are using. The kPanelType define comes from the MatrixCommonHub75.h file in the SmartMatrix library! Go to this header and select your panel. MOD32SCAN is for a 1/32 scan rate.

[smiliea]

https://github.com/PlummersSoftwareLLC/NightDriverStrip/assets/24381908/974d7e00-6620-479f-84b5-0cce492ff004

[smiliea]

@davepl Can we possibly store effects on external RAM on the Mesmerizer board? We could load the effect we want into ESP32 high speed RAM dynamically. I think the ESP-32 we are using has external storage. Could that be utilized? Just shooting in the dark here...

Also, this bug should be marked as resolved.

[rbergen]

@davepl Can we possibly store effects on external RAM on the Mesmerizer board? We could load the effect we want into ESP32 high speed RAM dynamically. I think the ESP-32 we are using has external storage. Could that be utilized? Just shooting in the dark here...

@smiliea If the external RAM you mention is PSRAM then the answer is "partly, and we're already doing that". Basically, on devices that have PSRAM we use an allocator that claims PSRAM whenever we can dictate which allocator is used and it concerns a scenario where the "PSRAM delay" is acceptable.

Also, this bug should be marked as resolved.

Agreed. I'll close it.

[robertlipe]

Don't close it unless the fix is wrapped in an #ifdef that sets the panel type based on MATRIX_HEIGHT and appropriate doc is added.

If globals.h is our universal 'this is where you configure the hardware' place, we shouldn't send people into other source files for specific cases.

We (I?) probably need to make a pass over all our effects and be sure they display sensibly (even if "letterboxed" or only in one half) when MATRIX_HEIGHT = 64.

[rbergen]

I don't think it's possible to cover every case in globals.h, due to the immense amount of possible permutations of boards, things that blink, etc. It's one of the consequences of this project (also) supporting a user base of people creating unique solutions out of combinations of hardware they specifically select.

That said, if you intend to actually pick this up and "formalize" the support for 64x64 matrices in the Mesmerizer project then feel free to open a "feature" issue for that which references this one. Or, if you prefer we can also reopen and rename this one instead.