When using the kinetis spi driver and processor expert is there a way to artificially hold the spi line low (to wake the device before communication). I am using a mkl27
已解决! 转到解答。
Bud
The KL27 has DMA, which can be triggered by the SPI flags.
However the SPI is double-buffered so as long as you keep the buffer full you shouldn't have any gaps between bytes in a sequence.
That is, fill the next byte to be sent when the TX buffer full flag is not set and read out the received data on the RX buffer not empty flag - don't do the Tx on the Rx buffer empty flag otherwise there may be a gap due to the internal synchronisation (which is probably always there on the start byte).
Regards
Mark
Bud
Unlike the SPI in the K family, the one in the KLs has very little chip select control in master mode.
It is probably easiest to use the pin in GPIO mode, negate it and program a delay (eg. using timer and interrupt) before starting the SPI transmission.
Regards
Mark
Kinetis: http://www.utasker.com/kinetis.html
KL27: http://www.utasker.com/kinetis/FRDM-KL27Z.html / http://www.utasker.com/kinetis/Capuccino-KL27/Capuccino-KL27.html
For the complete "out-of-the-box" Kinetis experience and faster time to market
:smileyinfo: Out-of-the-box support for 47 Kinetis boards and 10 IDEs (460 combinations from a single code source with no porting required)
I was hoping that was not the case as there is a 4.26us delay after the cs goes low and the first spi clock and a 11.52us delay after the last spi clock before the cs returns high (12Mbit/s). i do however see the same 4.26us delay between bytes. this chip does not seem to have dma, is there any way to speed this up?
Bud
The KL27 has DMA, which can be triggered by the SPI flags.
However the SPI is double-buffered so as long as you keep the buffer full you shouldn't have any gaps between bytes in a sequence.
That is, fill the next byte to be sent when the TX buffer full flag is not set and read out the received data on the RX buffer not empty flag - don't do the Tx on the Rx buffer empty flag otherwise there may be a gap due to the internal synchronisation (which is probably always there on the start byte).
Regards
Mark