Arduino for STM32

updated SPI.h
https://github.com/ag88/stm32duino_spi_ ... /SPI/SPI.h

• added externs to SPI instance (this defaults to SPI 1)
• SPIDMA classes are different for each series and SPIDMA uses a different/specific class for each SPI peripheral.
  Typedefs are defined for SPIClass1, SPIClass2, SPIClass3 in spi.h
  This is so that codes like

  Code: Select all

  SPIClass1 spi1;
  SPIClass2 spi2;
  SPIClass3 spi3;
  

  should work, and does not need to reference the specific class name for each series and peripheral.
  Note that each SPIClassN is actually derived from SPIClass, hence they can be passed to functions / methods
  that use SPIClass for the SPI api.
  each SPIClass1, SPIClass2, SPIClass3 connects to the specific SPI peripheral 1, 2, 3 respectively

This is still untested codes, but just compiled.
If you do test that, do drop a comment about it here or in github discussions etc.

edit:
there is a 'catch' in that actually for series that do not have a SPIDMA class, it uses SPIBasic which is generic (across SPI 1, 2, 3) and follows the original SPIClass definition instead. But that if no pin parameters are given, it defaults to SPI1.
I'd need to figure out how to make the declarations similar.
edit2:
this is done, SPIClass2 spi2; and SPIClass3 spi3; now works for SPIBasic based class as well, it is done by deriving a class and passing default pins to the constructor.

SPIBasic remains as a generic SPIClass implementation that can be used for any SPI peripherals.
SPIDMA implementations are specific to each SPI peripheral, i.e. it isn't possible to use SPIClass2 for SPIClass1 and vice versa.

I'm also thinking about in the constructor to add a parameter to specify the particular SPI peripheral used (e.g. using the SPI_BASE symbol for the register base address). This would deviate from the current constructor, but that it could make defaulting behaviour simpler to implement.
Such an implementation can enable specific pins tied to the SPI peripheral by default and helps avoid usage errors binding the incorrect pins,

refactor getClkFreq, SPIDMA use generic getClkFreq from SPIBasic
https://github.com/ag88/stm32duino_spi_ ... A.cpp#L300

added stm32f7xx
https://github.com/ag88/stm32duino_spi_ ... DMA_F7XX.h
https://github.com/ag88/stm32duino_spi_ ... A_F7XX.cpp

this is based on stm32f722rc generic variant, this is still untested codes, just compiled

stm32f7(22rc) is practically similar to/same as f4xx for the DMA
it has both channels and streams, but unlike H7, H5, it does not use a DMA MUX.
Hence, the channels/streams are pre-bound to DMA specifically as like in F4.

stm32f7(22rc) has an SPI with FIFO, but that instead of using a different structure / register as like H5, H7 it uses DR (data register),
and similar flags as TXE (transmit buf empty), RXNE (receive buf not empty), to flag the status.

added stm32L4xx
https://github.com/ag88/stm32duino_spi_ ... DMA_L4XX.h
https://github.com/ag88/stm32duino_spi_ ... A_L4XX.cpp

this is based on stm32L431cc generic variant, this is still untested codes, just compiled

stm32L4(31cc) is again different, it looks a little like stm32f3xx, but different. There is a mux at each channel, which CubeMX generaged codes call it a 'request', yet this is different from streams as like those in F4xx which are parallel. But in L4xx, I think it is a single DMA thread, just that the priorities are different. I'd guess it is partly as it is after all a 'low power' mcu. Hence, using parallel streams would likely consume more power.

stm32L4(31cc) SPI peripheral is similar to F7, in that it has a FIFO and unlike H5, H7 which uses different register design for FIFO.
stm32L4(31cc) SPI uses the 'old' F4 style DR register and TXE (transmit buf empty), RXNE (receive buf not empty) flags.
I'd guess the FIFO if used correctly could help with latency issues. But that the current implementation is 'simple' in a sense that it is just reading the byte (buffer) in the same way as if it is f4/f3 etc.

edit:
updated Readme.md
https://github.com/ag88/stm32duino_spi_dma
--
did a round of spihandle bug fixes
https://github.com/ag88/stm32duino_spi_ ... 0436f19a90

another round of bug fixes
https://github.com/ag88/stm32duino_spi_ ... d94fa76925
^ well, to get differentially faster speeds, I hit the registers this time round, and all the hairy bummers surface
avoiding stacking and unstacking by avoiding function calls can save quite a bit of cpu cycles when transmitting / receiving a whole buffer of data.

I'd stop changing or adding things (e.g. other series) at least for a while as after all, I've yet to test anything.
And that stm32{F,G,H,L}xxyy are 'cherry picked' single soc variants used to build and compile the codes.
It is unknown if within the series if they may vary.

The assumption is that 'cherry picking' a smaller mcu in the series, for the build, and 'bigger' chips would likely have same/similar architecture for the spi and dma peripherals, but still it is a guess.