From e0238df359dc4a540d8ae37c55bf1b535775e4cd Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Mon, 10 Aug 2015 12:23:53 -0600 Subject: [PATCH] SPI Slave: Summarize DMA issues in SPI slave header file --- include/nuttx/spi/slave.h | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/include/nuttx/spi/slave.h b/include/nuttx/spi/slave.h index 2fb7dd3762..ac551e79f6 100644 --- a/include/nuttx/spi/slave.h +++ b/include/nuttx/spi/slave.h @@ -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