ATtiny1626 SPI

[eCtune]

Hi, is it possible to see an example on how to properly configure the attiny1626 to communicate over the SPI port on pin 12,13,14,15.

I tested a few online example and had no success using the attiny1626. I tested the same example with UNO and it worked. I dont know if the pins for the SPI are set correctly. Is this something someone can help me with?

Thanks

[SpenceKonde]

So you want to use it on PC0-PC3?

Note: Using arduino pin numbers is discouraged, as those are arbitrary numbers assigned for the purposes of the Arduino core, whereas the port and bit within the postwithin the port is set by the hardware. Because the headers already #define constants like Pxn (eg, PC0, PA3 etc) in a non-useful way (they're defined such that Px0 is constant for all x, so they don't uniquely identify a pin), my cores and a number of other third party cores now define PIN_Pxn (ex, PIN_PC0). Under the hood they are just defined as the arduino pin numbers, but by using something that explicitly contains the port/bit, code readability is greatly improved since you can easily be cross-referenced with any resource (eg, Microchip tech briefs, datasheet, and so on) without needing to look up what pin a pin number refers to - which is what I just did, because I certainly don't know the arduino pin numbers from memory (I use them exactly once in the general case: When I make a variant file for a new part and have to write out the PIN_Pxn macros. The only other times I need to know the numeric values is writing test code that loops over large numbers of pins to check something (though oftentimes this code is actually procedurally generated rather than hand written, and in that case I can avoid the numbers), and occasionally when fixing bugs in macros in the variant files; the original variant files often contain the raw numbers, though as I work over the files those get replaced with the constants).Any library example that uses numbers instead of PIN_Pxn or other named constants to refer to pins should be reported as a bug. I'm sort of on a crusade to root out the use of numbers to reference pins, largely because I've seen that taken to it's illogical conclusion on ATTinyCore and the pin mappings it inherited, some of which I doubt could have been conceived by any human, and are actually the work of satan or a minion of his; and that's why ATTC has multiple pin mapping options for more than half of their parts: a recommended one and a legacy one; one part even has a third pin mapping, because commercial boards have used two pinouts, both of which are inspired works of evil. The PIN_Pxn notation makes those differences magically vanish)

Sorry, as you can see, I'm rather passionate about that.

To answer your question, SPI should work on pins PA1-PA3 or PC0-PC2 (SS pin is not relevant, see note below).
Calling SPI.begin alone will set up SPI on the PORTA pins.
Calling SPI.swap(1); before SPI.begin() , will set up SPI on the PORTC pins.
SPI.pins() is also supported, but swap is more efficient and is preferred.

See the SPI library documentation, which was apparently missing from this core for reasons unclear to me.

https://github.com/SpenceKonde/megaTinyCore/tree/master/megaavr/libraries/SPI

Note on SS: SS is on PA4 or PC3, but SPI.h doesn't support slave mode and we always set the SSD (Slave Select Disable) bit when configuring SPI, so the SS pin has no bearing on SPI (the pin you connect to the CS/SS pin of the slave device, traditionally, has been the SS pin. But that is only a matter of personal preference - it's no better or worse than any other pin on modern AVRs (on classic AVRs, where that convention started, doing that was considered desirable as a way to ensure that SS was set as output, because on those parts, because they didn't have an SSD option, the pin had to be an output or it could cause SPI to switch into slave mode unintentionally; that's not an issue on modern (post 2016) AVRs because of the SSD option).