Move SharedSpi and SharedI2c drivers into CoreN2G

[dc42]

Andy S. has requested that we move the SPI driver to CoreN2G. This makes sense. We should move the SharedI2C driver too. This work will also avoid having the same code duplicated in RRF and D3E.

Questions:

• Should we move SharedSpiClient and SharedI2cClient too? [Probably.]
• Should we add a DMA option to these drivers? [Probably.]
• Can we use a common SPI base class between SharedSpi and the TMC drivers that use SPI? [Perhaps, but we need to preserve the efficiency of the SPI code when called by the TMC driver. DMA operation is mandatory.]

[gloomyandy]

Hi David a few comments that may be of interest...

We have an SPI layer in our STM and RPXXXX CoreN2G. On H7 we support 6 hardware channels and 3 software spi (because some boards need spi on pins that do not support hardware spi). On RPXXXX we support 2 hardware devices and a single PIO device.

We have a simple spi master api that is very similar to that used by the RRF shared SPI interface (which sits above this API). We have extended the shared SPI API to support multiple SPI busses. We use this interface for sensors, the SD card on some boards, TMC drivers and for the SPI based CAN-FD interface. This API supports read, write and read/write transactions. On read only transactions the master side will clock out FF bytes (mainly for SD card support). We currently only support 8 bit transfers.

The master API is basically blocking. Hardware devices use either DMA or interrupt based I/O. On devices that use DMA we will use interrupt based I/O if the memory area is not available to the DMA controller or if the length of the request is very short. On the H7 SPI devices support a FiFo and for short requests it is faster to simply fill this rather than setup a DMA transfer.

We use the same interface on both mainboards and expansion boards (so both stm32 and rpxxxx), it seems to work pretty well.

We also have a slave SPI interface that is used for both the WiFi module and the SBC interface. This is a little more complex as it is non-blocking and allows a call back on completion. It only supports hardware based devices and is not used on the RPXXXX. It works reasonably well but could probably be cleaned up and improved.

[dc42]

Completed moving the SPI stack from RRF and D3E to CoreN2G. This will also make it easier to support new processors. I2C support has yet to be moved. Some SPI functions that have strong performance requirements (e.g. WiFi, SBC and TMC drivers) still use dedicated drivers.

[dc42]

We should consider using dynamic DMA channel allocation as part of this work, it would remove the need to allocate DMA channels in the Pins file and pass them in the SPI parameters. For SAME5x we could allocate high priority DMA channels (the ones with separate interrupts) and low priority ones separately.

[dc42]

Completed. Dynamic DMA channel allocation has not been implemented.