SmartMatrix and PSRAM?

#1

@Louis, I’ve been doing a bit of work with PSRAM and had a look at your code.
It seems that all the memory you use, needs DMA, outside of a very small bit:

    if((COLOR_DEPTH_BITS == 12) || (COLOR_DEPTH_BITS == 16)){
        tempRow0Ptr = ps_malloc(sizeof(rgb48) * numPixelsPerTempRow);
        tempRow1Ptr = ps_malloc(sizeof(rgb48) * numPixelsPerTempRow);

I thought you created some bitplanes and those we used for DMA, but that the 2 full framebuffers that you swap back and forth were not used for direct DMA since the bitplanes were used for that.
Did I mis-understand that part?
As a result, is it correct that virtually all the memory used by SmartMatrix must be DMA and therefore can’t be PSRAM?

#2

also please see https://github.com/pixelmatix/SmartMatrix/pull/106 for alternate wiring required by PSRAM chips

#3

Look for malloc in Layer_Background_Impl.h, those are the big bitmap framebuffers for the background layer, and they are normal RAM, not DMA RAM. The bitplanes, and linked lists to transfer the bitplanes, need to be DMA RAM.

It helps a bit, see above. PSRAM will help you store bigger bitmaps, but not send them to the panel.

#4

Thanks. I’m not sure how my grep-foo failed there, those 2 FBs were exactly what I was looking for.
I just checked and PSRAM worked fine, as expected.
This does save up non trivial amount of RAM without slowing things down too much. Still, it is a bit visible (slowdown) as PSRAM goes through the IRAM cache and things slow down a bit when the cache is refilled.

Happy to send you a patch if you want to apply it, although you’re already a few patches behind ( https://github.com/pixelmatix/SmartMatrix/pulls ), so before going through the work of making a clean patch for you (my tree is ahead of yours), I’ll wait to hear that you want it :slight_smile:

Before:
Heap/32-bit Memory Available     : 212284 bytes total, 73672 bytes largest free block
8-bit/malloc/DMA Memory Available: 138612 bytes total, 64624 bytes largest free block
Total PSRAM used: 0 bytes total, 4194252 PSRAM bytes free

After:
Heap/32-bit Memory Available     : 249056 bytes total, 113792 bytes largest free block
8-bit/malloc/DMA Memory Available: 175508 bytes total, 113792 bytes largest free block
Total PSRAM used: 36864 bytes total, 4157356 PSRAM bytes free
#5

Glad you got it to work, and thanks for asking, I’m putting my limited resources into the APA102-HUB75 adapter project right now. Maybe create a GitHub Issue for this, so it doesn’t get lost, and I can ask you for the patch when the issue bubbles up to the top?

#6

I had to make a diff for myself, so here’s a PR:


and bug: https://github.com/pixelmatix/SmartMatrix/issues/108
It also includes https://github.com/pixelmatix/SmartMatrix/pull/106
since the new wiring option is required for PSRAM (since PSRAM disables pins that were used by the other wiring option)
@rorosaurus try this out, it should save you a fair amount of RAM on your display, and allow for full color gifs

#7

Before, 128x64 was the practical limit, without PSRAM:

Heap/32-bit Memory Available: 176224 bytes total,  84752 bytes largest free block
8-bit/DMA Memory Available  :  91472 bytes total,  48240 bytes largest free block

with PSRAM:

Heap/32-bit Memory Available: 214900 bytes total,  74376 bytes largest free block
8-bit/DMA Memory Available  : 140524 bytes total,  57332 bytes largest free block
Total PSRAM used: 49152 bytes total, 4145068 PSRAM bytes free

Now, with PSRAM, 128x96 is possible:

Heap/32-bit Memory Available: 153588 bytes total,  74376 bytes largest free block
8-bit/DMA Memory Available  :  79212 bytes total,  23040 bytes largest free block
Total PSRAM used: 73728 bytes total, 4120492 PSRAM bytes free

128x111 is the new limit with PSRAM, sadly short of 128x128

Heap/32-bit Memory Available: 122300 bytes total,  74376 bytes largest free block
8-bit/DMA Memory Available  :  47924 bytes total,  15024 bytes largest free block
Total PSRAM used: 85248 bytes total, 4108972 PSRAM bytes free
#8

If I recall, you’re using the circuit without latch, right? If so, the latch may get you to 128x128

#9

@Louis: correct, no latch, nothing against it, it’s just that there is no pre-printed board I can buy on tindie, that has them.
That said, didn’t you recently say that the latch circuitry would get in the way of sending the FM6126A reset code, or am I mixing things up?

#10

I think it’s not a problem even with the latch. Anyway, the new hardware I have solves that for sure.

@rorosaurus now that you know there’s hardware designs to go with the ESP32 library, would you be interested in selling one of the designs on Tindie to help people out like Marc? The design will be close to the THT version that’s in the repo already, but tweaked to use an ESP32 pico board instead. I don’t have any plans to sell an ESP32 shield even though people want it, so it would fill a gap.

1 Like
#11

I think the issue was latch circuitry getting in the way of AB panels. That’s also hopefully fixed in the latest hardware but pending me getting a panel to test to verify my hardware works (plus I have to write the code)

#12

Ah, sorry that I got AB and ABC confused.
So, how are they different outside of the number of address lines obviously?
I can see that a 128x64 ABC panel only pushes 8 lines instead of 32, but each address line really shifts 512bits, which means that the lines are brighter/flicker less since they are on 1/8th of the time instead of 1/32th.
How is AB not the same thing, but with 4 lines instead of 8?

#13

When I say AB, I mean a panel that expects a latch and clock signal on the AB lines (or is it AC lines now?)

#14

And from what Louis is saying, yes, I do think there is a real need for a proper shield for ESP32 that uses safe pins and supports ESP32 with PSRAM and 16MB of flash (i.e. the lolin pinout would be fine).
I do believe there is a real need for it, my using the Jason Coon shields, and then cutting a trace, patching with a wire, and then doing my own ribbon cables, works, but is non optimal :slight_smile:

#15

Aaah right, the AB panels aren’t actually AB panels, they are totally different in how they are addressed, I keep forgetting about that.
Do they actually exist for anything big (128x64)?

#16

I’ve always wanted to design a board that uses the PICO and breaks out the proper pins! But that would involve me committing considerable time to learning/test/failing/learning again how to wire the ESP32, add the USB chip, attaching the PSRAM (I agree with Marc, it should be mandatory), etc.

Sadly I don’t have the bandwidth to do it now, but I would love to revisit this project in the future. I also would specifically love to use >5V USB-PD as the input, and regulate it back to 5V to make it super simple for new makers and portable projects!

#17

Dunno, I’ve never been able to source one despite trying repeatedly