SPI has MODE2 and MODE3 swapped
domnulvlad opened this issue · 3 comments
I have a sketch communicating with an SPI device that uses MODE3 (CPOL1 CPHA1), which works as expected on an Arduino UNO with the regular SPI library.
On an ATTiny85 using this core, setting MODE3 in the SPISettings object given to beginTransaction() causes the data to be clocked incorrectly, like MODE2.
Setting it to MODE2 produces the expected results and communication works correctly. So it seems these two modes are swapped.
Thanks, There was never a "rigorous QA" carried out after the universal SPI and Library libraries went in. In order for me to investigate further can you please confirm that this was in 2.0.0, not 1.x.x and retest in 2.0.0 if it wasn;t in the V2 dev version? Significant changes went in such that a report from 1.x.x may relate to an issue that is fixed or behaves differently the current codebase. Right now for a period of a few months I have limited access to basic tools like an oscilloscope, so while I can can reverse the meaning of mode 2 and 3 in the USI SPI implementation, since I don't have a scope set up (both are in storage and I'm working in a tiny space until I can find a new place to live, I can't verify that it;'s behaving wrong and hasn't already been fixed as I do remember doing something that might have included that for 2.0.0
The bug was observed on the latest release, 1.5.2.
Right now I tested 2.0.0.
With my logic analyzer hooked up, I first tested 1.5.2 again as a sanity check. Indeed, what the code describes as MODE3 comes out as MODE2.
Then I tested 2.0.0, with the exact same code and fuse settings, and there's just no SPI anymore... at all.
I probed all pins with the analyzer, and there is activity only on a pin which is controlled by regular digitalWrite(). I tried comparing the old and new SPI.cpp, major differences were some digitalWrites replaced by port manipulation on some "USI" registers.