Could memset like this be replaced by dma?
I donāt know, but NUM_SLABS is only 40 at most, and all weāre doing is zeroing it out. All the binning is Core0, anyway. Iāve made a test branch and pushed the changes I tried earlierāno dice, unfortunately. I have collision detection disabled on the latest commit, as well. If you want to try it for yourself, change GV_TEST to 1.
I was able to smooth things out for Core1 by marking renderAndFlushFrame() as __no_inline_not_in_flash_func. No more spikes on the debug output for Core1.
After this and a modest overclock, thanks to Geoff, itās running smoother than ever. Iām having so much fun with this thing.
And thank you too, Kuratius. I never would have Googled for that macro if you hadnāt mentioned putting code in memory.
There is this thing Iāve noticed where the space bar sometimes gets read as not pressed (like youāre holding it and the space ship changes direction for a split second), but I think that is probably an issue with the hardware or the keyboard firmware, like maybe the button just doesnāt have good contact.
Hmm⦠I did boost the clock a bit. You could try setting it to 133MHz in PicoPlatform and set the SPI baud rate back to 65.5MHz in the display file. The keyboard is on I2C and I havenāt seen the same behavior, but you might try that to rule it out.
I didnāt check if you tryied to use different SRAM banks for the CPU/DMA ping-pong. The AHB interconnect can cause some stall if CPUs and DMA try to R/W in the same bank.
Just giving the idea if you want to squeeze out a few more FPS!
If the post by the raspberry pi engineer I linked earlier is to be believed the 4 main ram banks are striped across the address space so for most cases it sounds like it should be near impossible to have significant contention unless the data is stored in the scratchpad/stack XY banks.
Ah sorry, I must have read it too quickly.
But in this case, you should be perfectly in sync between both core and DMA to ensure stripping do the job right?
Iāll give it a try