3

I am attempting to read/transfer data between an instrument and Raspberry pi 2, using the RPi as the Master and instrument as the slave. The data sheet states I must have a 9 ms delay between sending the command byte and the second byte, which I am currently unable to do using the py-spidev library for the RPi. The docs show a delay variable you can set, however when I set this, it seems to extend the amount of time the chip select is held low, but not much else. How can I actually introduce a delay between bytes without just bit-banging? Has anyone had success trying this?

Attached is an output from my Saleae logic analyzer showing the lack of delay with the following command:

spi.xfer2([0x03, 0x00], 500000, 0)

There is a 3 us delay between bytes and the /ss is held low for 84.2 us.

enter image description here

If I try adding the 9 ms delay, I see the following:

It has the same 3 us between bytes, but now the /ss is held low for the ~9ms.

enter image description here

Any thoughts/recommendations on things to try?

Improve this question
2
  • 1
    Worst case all you have to bit bang is chip select while sending two separate transfer commands.
    – Samuel
    Mar 27, 2015 at 16:42
  • Very true. I will have to try that asap
    – David Hagan
    Mar 27, 2015 at 22:50

1 Answer 1

Reset to default
3

The documentation is really vague about what a "block" is, but you might want to try sending your bytes using two separate calls:

spi.xfer2([0x03], 500000, 9000) # leave CS asserted after first byte, 9 ms delay
spi.xfer([0x00], 500000, 0)     # transfer second byte, negate CS
Improve this answer
5
  • Thanks for the suggestion. It appears that the chip is still re-asserted after the 9 ms delay. Basically with the xfer2 command it just adds a 9 ms delay before re-asserting the cs. I wonder how I can get it to stay low..?
    – David Hagan
    Mar 27, 2015 at 22:48
  • An analysis of the module source code shows that while the intent may have been as I described, the actual implementation of the two methods is functionally identical. I'd call this a bug, which means you'll either have to fix it or find a workaround for it.
    – Dave Tweed
    Mar 28, 2015 at 0:21
  • @DaveTweed I did a quick experiment and xfer/xfer2 do behave identically. All I did was send two xfer followed by two xfer2. In each case the CS was de-asserted after each xfer/xfer2.
    – joan
    Mar 28, 2015 at 9:46
  • I will be making my best attempt to fix this in the py-spidev source and sending a merge request. I have also logged it as an issue.
    – David Hagan
    Mar 30, 2015 at 12:25
  • Have you figured this out? I need to add a delay between bytes to accomplish a strange burst mode firmware upload in a device.
    – PhilBot
    Jul 22, 2016 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.