sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

SPI Slave: Summarize DMA issues in SPI slave header file

Browse Source
This commit is contained in:
Gregory Nutt 2015-08-10 12:23:53 -06:00
parent 17b0153f4b
commit e0238df359
1 changed files with 36 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
include/nuttx/spi/slave.h
View File

@ -387,7 +387,42 @@
* upon it.
*
* A typical DMA data transfer processes as follows:
* To be provided
* To be provided -- I do not have a design in mind to support DMA on the
* Slave side. The design might be very complex because:
*
* 1) You need DMA buffers of fixed size, but you cannot know the size of a
* transfer in advance, it could be much larger than your buffer or much
* smaller. The DMA would fail in either case.
*
* 2) You cannot setup the DMA before the transfer. In most SPI protocols,
* the first word send is a command to read or write something following
* by a sequence of transfers to implement the write. So you have very,
* very limited time window to setup the correct DMA to respond to the
* command. DMA setup time can be longer. And I am not sure it I can
* make it reliable.
*
* 3) I mentioned that you do not know the size of the transfer in advance.
* If you set up the DMA to terminate to soon, then you lose the last part
* of the transfer. If you set the DMA up to be too large, then you will
* get no indication when the transfer completes.
*
* The chip select going high would be one possibility to detect the end
* of a transfer. You could cancel a DMA in progress if the CS changes,
* but I do not know if that would work. If there is only one device on
* the SPI bus, then most board designs will save a pin and simply tie CS
* to ground. So the CS is not always a reliable indicator of when the
* transfer completes.
*
* 4) The option is to use a timer but that would really slow down the
* transfers if each DMA has to end with a timeout. It would be faster
* non-DMA transfers.
*
* If the device as a very restricted protocol, like just register reads
* and writes, then it might possible to implement DMA. However, that
* solution would not be general and probably not an appropriate part of
* a general OS. But if the interface is unpredictable, such as reading/
* variable amounts of data from FLASH, there is more risk. A general
* solution might not be possible.
*/
enum spi_smode_e