Misc Improvements (SD card saving/loading, PS2 compatibility, concurrent syncing, protocol simulation improvements etc)

[darrena092]

Hi!

This builds on top of my earlier SD card work and brings with it the following improvements:

• The SIO protocol simulation is offloaded onto Core1 and is no longer blocked by sync operations. Meaning we have no more random disconnects.
• Sync operations are now "sector-at-once" rather that "card-at-once" and use a FIFO queue to get around concurrency issues.

Other things are included from my now-closed PS2 compatibility MR, including:

• Stateful SIO simulation. The benefit of this is that constantly resetting core1 to restart this simulation causes weird issues and crashes. With this we can just reset the state machine in the PIO0 IRQ0 interrupt without affecting the overall state of core 1. It also allows us to cleanly terminate a transaction, which the PS2 likes to do frequently.
• Using pio_sm_drain_tx_fifo to clear the FIFO for smDatWriter. This has the benefit of also clearing the OSR, where the last TX byte from the last transaction will otherwise be hiding, ready to be sent out on the DAT line the second a new transaction starts!
• Slower PIO programs, with the benefit that we don't respond to some of the faster clocked signals on the PS2 for other devices. I assume maybe for multitaps etc.
• The ACK line will only now be asserted after 8 clocks are counted.
• Sync logging to a "queue.log" file on the SD card, which can optionally be disabled by removing the define in CMakeLists.

I know this is a big deviation from the original project - and I had initially tried to get this to work with littlefs and internal flash storage but the chip just kept hard faulting and I couldn't figure it out, while it works perfectly with the FatFS SD driver. Which is why I've requested to merge to the PMC+ dev branch.

[dangiu]

Really great work! As already mentioned, I wanted to keep the USB functionality but it's a bit pointless to keep delaying this pull request since it introduces many fixes. I'll merge it and add it back later since this is a development branch is not that big of an issue. The hard faults you were experiencing are likely because you were running two cores while trying to write to flash memory: the code responsible for writing flash memory is automatically copied and executed in RAM but the code executed by Core1 is not. This results in a flash access operation (to fetch instructions for Core1) while is being reprogrammed (by Core0) which causes the hard fault.