2009-05-03 18:31:10 SPI: CS-timing topics
Rob Maris (GERMANY)
Message: 73533
With reference to thread id=27593 I have experienced some problems while using current trunk version (intended to have them inserted each as separate posting).
When CS is GPIO-based and cs_change_per_word is set, the CS deactivate pulses appear to arrive too early, see logic analyzer screenshot.
cs_gpio+cs_change_per_word=1.png
QuoteReplyEditDelete
2009-05-03 19:53:21 Re: SPI: CS-timing topics
Rob Maris (GERMANY)
Message: 73534
When no GPIO_mode and SPI_MODE_3 is activated as to intend to have no CS-pulses in between words of a message, the intended behaviour cannot be established - using spidev-fdx.c (where the array has been filled with 55 AA 56 AB).
The corresponding executable is invoked as follows:
$ spidev -m4 -r2 /dev/spidev0.4
And the CS-signal is practically active always after the first message is sent. See attachment with SPI_MODE_3 in the name. The result is regardless the values of cs_change, as specifyable for each individual message (prior to message 1, a 1-byte message is sent, according to the function do_msg().
When instead, SPI_MODE_0 is activated, the results are quite confusing, dependent on cs_change set only upon the first message, only upon the second message, or both - in three attachments marked as ...01, ..10, ...11. The case ...00 is okay, but as is inherent with SPI_MODE_O, with CS pulses after each byte.
SUMMARY: In no case, CS is high between messages and steady low between bytes within a message.
Did I parameterize anything wrong, or has a bug been entered with recent changes in SVN?
SPI_MODE_3+cs_change_regardless.png
SPI_MODE_0+cs_change_01.png
SPI_MODE_0+cs_change_10.png
SPI_MODE_0+cs_change_11.png
