Hello Espressif Community,
I'm developing an application that must update a LED matrix. In parallel, the application is also responsible for receiving data packets via ESPNOW, saving them to FLASH, and updating the graphical information on the LED matrix.
Basically, the LED matrix was developed with arrays of shift registers controlled via SPI (CPU_1), and the rest (such as ESPNOW, File System, etc.) is handled by (CPU-0).
Between SPI writes, there's a timing of 200us controlled by the timer [High Resolution Timer - One Shot Timer]:
Write SPI DMA -> Start Timer One Shot (200uS) -> Timer Interrupt -> Write SPI DMA -> Start Timer One Shot (200uS) -> Timer Interrupt -> ...
The problem is that when I receive a packet via ESPNOW on CPU_0, CPU_1 also becomes blocked. This affects the LED matrix, causing flickering on the screen.
How can I make CPU-1 completely independent of CPU-0?
MultiCore: SPI, Timer, ESPNOW, and File System
-
- Posts: 1
- Joined: Mon Apr 01, 2024 10:33 am
-
- Posts: 1706
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: MultiCore: SPI, Timer, ESPNOW, and File System
You can't. There's only one flash chip, so writes to flash must halt all code running from flash irrespective of the CPU core.leonardo.ceolin wrote: ↑Wed Apr 17, 2024 5:26 pmsaving them to FLASH...
The problem is that when I receive a packet via ESPNOW on CPU_0, CPU_1 also becomes blocked.
...
How can I make CPU-1 completely independent of CPU-0?
The only way around this is to put everything you need to keep running during flash writes into IRAM-ISRs.
A potential 'work-around' for your case could be to only start a flash write during the 200us 'idle' time when there's nothing going on which would be disrupted by the write. 200us isn't much time though, so I'd expect a flash write to delay the next LED maxtrix update, but that may be more acceptable than halting an update mid-way.
Who is online
Users browsing this forum: Bing [Bot], cdollar and 95 guests