2009-05-03 18:31:10     SPI: CS-timing topics

Document created by Aaronwu Employee on Aug 15, 2013
Version 1Show Document
  • View in full screen mode

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

Outcomes