Change order of spi send and read #11
Conversation
There was a problem hiding this comment.
The reason why we didn't do this before is 'cause a small delay between both bytes (which will happen with this approach) messed up the previous implementation. Since #8 was merged, this might be less of an issue, but I'll need to test a few platforms to see if it makes a difference.
| block!(self.spi.send(0))?; | ||
| self.spi.read().ok(); | ||
| block!({ | ||
| self.spi.send(0); |
There was a problem hiding this comment.
| self.spi.send(0); | |
| self.spi.send(0).ok(); |
| @@ -101,8 +101,8 @@ where | |||
| block!({ | |||
| // Some implementations (stm32f0xx-hal) want a matching read | |||
| // We don't want to block so we just hope it's ok this way | |||
| self.spi.read().ok(); | |||
| self.spi.send(patterns[bits as usize]) | |||
| self.spi.send(patterns[bits as usize]); | |||
There was a problem hiding this comment.
Oh, this won't work properly.
block! will call send & read until read doesn't block any more, which means the same byte might be sent multiple times.
There was a problem hiding this comment.
All right, I'll be honest and say I don't understand any of the inner workings (not yet anyway). It just happened to work for my use case then ;)
..whereas the original code did not. I can try some more poking around, unless you have any hints/suggestions?
Btw, I've only found one other guy on the internet briefly describing the same issue as I'm having (before he gives up and uses the timer variant): https://albertskog.se/embedded-rust-timer-timeout-problem/
|
Hi, could you try if #12 works for you? Under the hood it should accomplish the same things as this PR, while being simpler |
|
Hey. |
|
@abjorck I switched to a different approach, it now works for me on the stm32f1 which has a similar spi peripheral. Could you test it again? |
|
yes! that does it :) thanks |
Hey
I had trouble using SPI with my strip, constantly getting Overrun errors after a first successful write. After som trial and error guesswork, I made it work with the following changes to the lib.
Maybe it needs a config flag if it works differently for other hardware..
(I'm using stm32f4xx_hal on a STM32F401CEUx, the strip is just called "ws2812b led strip" (from "BTF-lighting"))