SPI has MODE2 and MODE3 swapped

[domnulvlad]

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.

[SpenceKonde]

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

[domnulvlad]

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.

[ptvagner]

Hello Spence.

First off, thanks for all your hard work on this project, you've made these tiny chips accessible to us all and I'm very grateful for that :)

I'd like to report a similar (same?) issue as domnulvlad here.

• ATTinyCore 1.5.2 > SPI > working.
• ATTinyCore 2.0.0 > SPI > not working, occasional spurious activity[1].

Note: I don't have a scope and have no clue what "MODE2" and "MODE3" are ... above my pay grade i guess ;)

My Setup (working):

• ATTinyCore v 1.5.2

  

• Arduino IDE 2.3.2 (MacOs Sonoma)

  

• ATTiny84 (non A variant)

• Maxim MAX7219

  • Chip Enable => PIN_PA7
  • Clock => PIN_PA4 (SCK)
  • Data => PIN_PA5 (DO)

• Rotary Encoder

  • Channel A => PIN_PA0
  • Channel B => PIN_PA1

The rotary encoder controls 7segment LEDs via the MAX7219, everything works as expected with core v1.5.2.

However, when the exact same setup but using core v2.0.0 there is no activity on the SPI pins.

I followed the your instructions for manual installation of core v2.0.

I then re-burned the bootloader and uploaded the exact same sketch (via an Arduino Nano clone), on the exact same breadboard.

There's now no communication between the '84 and the '7219.

As a sanity check, I added a tell-tail led between DO and GND, this shows activity with v1.5.2 but no activity with 2.0.0, same for the SCK pin.

Fortunately, v1.5.2 is sufficient for my needs so i'll stick with that for now.

I hope this info helps fix this issue :)

All the best.

Petr.

[1]. under v2.0.0 there is no significant activity on DO (as evidenced by a telltale led between DO and GND), spinning the rotary encoder occasionally makes the LEDs all light up, sometimes one or other digit will light random segments (but not the telltale LED). there's no consistency as to which digits / segments light up, I'm guessing this is just noise ?