From 33664a3451a81ec64eca58424925c435f23d6a25 Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Tue, 11 Aug 2015 09:30:52 -0600 Subject: [PATCH] SAMV71-XULT: Add discussion of the SPI slave driver in the README file --- configs/samv71-xult/README.txt | 89 +++++++++++++++++++++++++++++++++- 1 file changed, 87 insertions(+), 2 deletions(-) diff --git a/configs/samv71-xult/README.txt b/configs/samv71-xult/README.txt index f00e64000e..581e8b18e5 100644 --- a/configs/samv71-xult/README.txt +++ b/configs/samv71-xult/README.txt @@ -21,6 +21,7 @@ Contents - Audio Interface - maXTouch Xplained Pro - MCAN1 Loopback Test + - SPI Slave - Debugging - Configurations @@ -132,8 +133,9 @@ for additional issues specific to a particular configuration. does not work if the D-Cache is configured in write-back mode; write- through mode is required. - 8. And SPI slave driver as added on 2015-08-09 but has not been verified - as of this writing. + 8. An SPI slave driver as added on 2015-08-09 but has not been verified + as of this writing. See discussion in include/nuttx/spi/slave.h and + in the section entitle "SPI Slave" below. Serial Console ============== @@ -1077,6 +1079,89 @@ MCAN1 Loopback Test System Type -> MCAN device driver options CONFIG_SAMV7_MCAN_REGDEBUG=y # Super low level register debug output +SPI Slave +========= + + An interrutp driven SPI slave driver as added on 2015-08-09 but has not + been verified as of this writing. See discussion in include/nuttx/spi/slave.h + and below. + + I do not yet have a design that supports SPI slave DMA. And, under + certain, very limited conditions, I think it can be done. Those + certain conditions are: + + a) The master does not tie the chip select to ground. The master must + raise chip select at the end of the transfer. Then I do not need to + know the length of the transfer; I can cancel the DMA when the chip + is de-selected. + + b) The protocol includes a dummy read after sending the command. This + is very common in SPI device and should not be an issue if it is + specified. This dummy read time provides time to set up the DMA. + So the protocol would be: + + i) Master drops the chip select. + ii) Master sends the command which will indicate whether the master + is reading, writing, or exchanging data. The master discards + the garbage return value. + iii) Slave is interrupted when the command word is received. The + SPI device then decodes the command word and setups up the + subsequent DMA. + iv) Master sends a dummy word and discards the return value. + During the bit times to shift the dummy word, the slave has time + to set up the DMA. + v) Master then reads or writes (or exchanges) the data If the DMA + is in place, the transfer should continue normally. + vi) At the end of the data transfer the master raises the chip + select. + + c) There are limitations in the word time, i.e., the time between the + interrupt for each word shifted in from the master. + + The controller driver will get events after the receipt of each word in + ii), iv), and v). The time between each word will be: + + word-time = nbits * bit time + inter-word-gap + + So for an 8 bit interface at 20MHz, the words will be received from the + master a 8 * 50nsec = 400 nsec + inter-word-gap. That is the time + during which the dummy word would be shifted and during which we + receive the interrupt for the command word, interpret the command word, + and to set up the DMA for the remaining word transfer. I don't think + that is possible, at least not at 20 MHz. + + That is far too fast even for the interrupt driven solution that I have + in place now. It could not work at 20MHz. If we suppose that interrupt + processing is around 1 usec, then an 8 bit interface could not have bit + times more than 125 nsec or 8 KHz. Interrupt handling should be faster + than 1 usec, but not a lot faster. I have not benchmarked it. NuttX + also supports special, zero latency interrupts that could bring the + interrupt time down even more. + + Note that we would also have a little more processing time if you used + 16-bit SPI word size. + + Note also that the interrupt driven approach would have this same basic + performance limitation with the additional disadvantage that: + + a) The driver will receive two interrupts per word exchanged: + + i) One interrupt will be received when the word is shifted in from + the master (at the end of 8-bit times). This is a data received + interrupt. + + ii) And another interrupt when the next words moved to the shift-out + register, freeing up the transmit holding register. This is the + data sent interrupt. + + The ii) event should be very soon after the i) event. + + Without DMA, the only way to reduce the interrupt rate would be to add + interrupt-level polling to detect the when transmit holding register + is available. That is not really a good idea. + + b) It will hog all of the CPU for the duration of the transfer). + Debugging =========