Closed andreyk0 closed 2 years ago
Hi! I am not sure if I read your diagrams correctly. As far as I understand the difference between mode 0 and 1 is that sampling happens on the rising or falling edges respectively. When I compare both diagrams the values are sampeled correct in both cases. Tha's probably because the 'clock' (MOSI or SDO) is shifted by a half cycle and the SDI (or MISO) values are sampled allways in a steady state of the signal. Of course that's more obvious in case of mode 2. I have to test this on the Raspberry.
Right! So the diff between 0 and 1 is as you say but notice the "default" state of the pin (yellow line is MOSI you use to construct "fake clock"). In mode 0 on this board it goes high and in mode 1 it stays low.
So, initially when I tried (without the missing leading 0 in the enum fix, with mode 0) there was effectively an extra transition because the pin would go up "high" in between 4-pulse "clock" bytes. If the next pin transition is to "high" (due to high bit set) - it still works, it just "stretches" a bit but if the next bit is 0 - there's an extra transition.
Hope that makes sense.
So, I guess we can close it, you've merged my PR, thanks!
Hey! I've tried connecting it to an stm32f103 ("blue pill") board and ran into a couple of issues that this patch seems to address.
First
ChAGain128
seemed to be missing a0
, noticed only because initially I tried with SPI mode0
where the MOSI (used here as a clock driver) pin was going "high" in between bytes, resulting in an extra 1/0 transition.That said running SPI in the mode 1 seems closer to the original intention of the code (not sure about rpi though).
This PR seems to fix it for me.
See a couple of screenshots below:
SPI mode 0 (the missing![SPI-mode0](https://user-images.githubusercontent.com/393902/161451638-de04b8dd-4e86-40a0-9717-2a0bd352eabd.png)
0
fix already included)SPI mode 1![SPI-mode1](https://user-images.githubusercontent.com/393902/161451640-9460018a-1b07-40e7-b064-f1d4ab10893c.png)