Any update on if or when the files for this project will be shared? I plan on taking the original design and morphing it to a credit card sized format.

I really liked your project and decided to create something similar for my engineering thesis.

As far as I understand, it's not possible to update GPIO pins using DMA on the STM32L4xx series.
It works on my STM32F103, but not on my STM32L467RG.

How did you manage to make it work?

I implemented the display using two 4-bit decoders instead of using Charlieplexing. This way, I don’t have to deal with tri-state outputs — I just need to update the GPIOA register.

QUOTE (MrFastfinger)

I really liked your project and decided to create something similar for my engineering thesis.

As far as I understand, it's not possible to update GPIO pins using DMA on the STM32L4xx series.
It works on my STM32F103, but not on my STM32L467RG.

How did you manage to make it work?

I implemented the display using two 4-bit decoders instead of using Charlieplexing. This way, I don’t have to deal with tri-state outputs — I just need to update the GPIOA register.

DMA to GPIO is definitely possible on both L476 and L432. The setup is probably different to the F103 though as they have a different number of streams/channels, I can't remember the details. It's also different again on the newer generation of chips with their GPDMA.

Any update on if or when the files for this project will be shared? I plan on taking the original design and morphing it to a credit card sized format.

I'm working on a personal project using similar hardware (STM32L432 + Accelerometer) to drive a charlieplexed matrix. I could use some pointers.

I can run the matrix in a timer and the refresh is mostly flicker free. But i'd love to know how you worked the DMA magic as I've spent days struggling to get it to work with both GPIOA and B banks. I've gotten the DMA to work if I pretend it's a traditional matrix and treat A as columns and B as rows. It only allows 1/2 the leds to work.

I did the same thing and started my fluid simulation by watching the 10 minute physics demo, creating an example in language i know well (javascript), then rewriting it in C (which i'm ok at). It's.... ok. It's very very slow, and mostly has to do with the logic where i'm enforcing density. So maybe the timer based logic for the led's is eating up my CPU overhead?