@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:
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?
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.
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 ( Pull requests · pixelmatix/SmartMatrix · GitHub ), 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
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
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?
@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?
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.
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)
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?
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
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)?
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!