Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
9 years, 10 months ago.
Is switching SPI modes on the fly expected to work?
I'm currently using two types of SPI devices - those that work with mode 3, and others that work with mode 0. I seem to be able to talk to one or the other using different programs that have SPI configured for the respective mode. However, if I run my test program that switches modes on the fly, it doesn't work. Granted, I have some management-level code to lock the SPI bus before each device tries to access it, and twiddling the CS line happens before changing the mode, but I wouldn't expect this to have any effect on the timing between CLK and data pulses.
It's also important to note that I am able to have multiple devices on the same SPI bus because there is an SPI mux on my board as well. I don't believe the mux is an issue because I can talk to multiple devices (other than the mode 3 devices) without any trouble.
Has anyone out there tried to do this before?
Question relating to:
2 Answers
9 years, 10 months ago.
Not sure that I fully understand the question, but one issue could be that the modes use different steady state levels for the SCLK and changing the mode after the CS went low may cause the slave to see a spurious clock edge which takes it out of sync such that the transmitted/received data values are shifted by one bit. It may also just be a bug in the implementation for your specific mbed platform.
I just posted a followup comment to my question, and thank you for your answer. I think you could be right, which would explain what I had observed. Maybe any time the mode changes, I should "flush" the clock pulses. However, I'm not sure how to do that other than sending another command. I found that declaring another DigitalOut using the same pin will prevent the SPI library from being able to use that pin afterward, so I wouldn't be able to set the correct idle state of the CLK line. I'll pull up the source and see if I can figure out what format does, and if it does anything with CLK before data is later sent.
posted by 29 Jan 2015
9 years, 10 months ago.
You can declare multiple spi objects with different clockrate, bitnumber and modi on the same spi port. The mbed code is looking every time the spi is used if the last access was from the same object. If it is a different object, the SPI is initialized again.
I think I found a solution that I like a little bit better - since I already associate a device with an SPI mode, I just keep track of the last-used mode. If the mode changes, I switch my mux to address 0, which is NC, then write a 0. Then I switch the mux to the target device and write the real data. This gets the clock in the right state before each transfer.
The problem now is that it works in my test code, but in my real application I get random results... Time to debug some more.
posted by 29 Jan 2015
I observed something interesting during debugging and from that realized that if I call the mode 3 device's function twice in a row, the data is always correct the second time around.
posted by Dave M 29 Jan 2015