> receive side uses a per-packet interrupt to finalize a received packet This ha...

rscott2049 · 2024-08-29T17:49:13 1724953753

Fortunately, the receive ISR isn't cracking packets, just calculating a checksum and passing the packet on to LWIP. I wish there were two DMA sniffers, so that the checksum could be calculated by the DMA engine(s), as that's where a lot of processor time is spent (event with a table driven CRC routine).

dmitrygr · 2024-08-30T12:47:40 1725022060

You can do it using PIO. I did that for emulating memory stick slave on rp2040. One PIO SM plus two dma channels with chained descriptors. XOR is achieved using any io reg you don’t need, with 0x3000 offset (manual mentions this as the XOR alias)

crote · 2024-08-29T17:47:38 1724953658

Luckily the RP2040 has a dualcore CPU so one core can be dedicated entirely to receiving the interrupts, passing it to user code on the other core via a FIFO or whatever else you fancy.

sulandor · 2024-08-30T13:06:49 1725023209

almost

context switching between processors will reduce cache coherence and hence hits, but yea, it might be worth the tradeoff on busy systems

crote · 2024-08-31T22:10:08 1725142208

Why would there be context switching? One core is exclusively running user code and polls for new pre-processed packages in some loop, the other core is exclusively running low-level network code and dealing with interrupts.

It's a Cortex M33, so there's no meaningful cache to speak off. Access to all memory takes essentially the same amount of time. If you're really worried about access time you could probably use SRAM banks 8&9 (each 4k, with their own connection to the AHB crossbar) and flip-flop between the two - but I highly doubt it's going to have a measurable impact.

sulandor · 2024-09-01T09:13:28 1725182008

if interrupt and usespace code run on the same core, there is a chance that the data will still be in the cache line of the processor and it wont have to go thru main memory.