LEONARDO SPI - pinouts correct? can it be a slave?

Projects Networking, Protocols, and Devices
1

I've been trying to get 2 Leonardo's to talk to each other over SPI
I know I should post photos of how they're connected, and what code I'm using, but, this should be something that someone can answer without having to debug my rotten code.

I have connected the ICSP headers to each other (I've tried it with just 3 jumpers - SCK, MISO, MOSI, with 4 jumpers RESET, with 5 jumpers Vcc and Gnd and all 6 jumpered)

In the "master", it appears to send a value
Serial.println(SPSR);
SPDR=5;
Serial.println(SPSR);
before the transfer, SPSR=0, afterwards SPSR=128 (1<<SPIF)

In the "slave", the SPSR never changes from 0. And if I ignore SPSR and just read SPDR it's always 0

I've tried making SS an INPUT or an OUTPUT, setting it HIGH, and LOW.

I read somewhere that the pinouts for the SPI/ICSP header are incorrect, but it looks to me that
SS=PB0, SCK=PB1, MOSI=PB2, MISO=PB3
in both the pinout drawing (http://arduino.cc/en/Hacking/PinMapping32u4)
and pins_arduino.h
static const uint8_t SS = 17;
static const uint8_t MOSI = 16;
static const uint8_t MISO = 14;
static const uint8_t SCK = 15;
_BV(3), // D14 - MISO - PB3
_BV(1), // D15 - SCK - PB1
_BV(2), // D16 - MOSI - PB2
_BV(0), // D17 - SS - PB0

So I think that was a wild goose chase.

My question is this:

I have seen where others have used Uno's and Mega's but no-one has a documented case of a Leonardo acting as an SPI slave.

Can it be done? Has anyone got a Leonardo to act as a slave over SPI and receive data? Specifically a Leonardo.

2

I have connected the ICSP headers to each other (I've tried it with just 3 jumpers - SCK, MISO, MOSI, with 4 jumpers RESET, with 5 jumpers Vcc and Gnd and all 6 jumpered)

I don't see any mention of controlling the SS pin.
Master drives it low, slave see it low to go into slave mode.
See pages 177, 178 of '32U4 data sheet.

The interconnection between Master and Slave CPUs with SPI is shown in Figure 17-2. The system
consists of two shift Registers, and a Master clock generator. The SPI Master initiates the
communication cycle when pulling low the Slave Select SS pin of the desired Slave. Master and
Slave prepare the data to be sent in their respective shift Registers, and the Master generates
the required clock pulses on the SCK line to interchange data. Data is always shifted from Master
to Slave on the Master Out – Slave In, MOSI, line, and from Slave to Master on the Master In
– Slave Out, MISO, line. After each data packet, the Master will synchronize the Slave by pulling
high the Slave Select, SS, line.
When configured as a Master, the SPI interface has no automatic control of the SS line. This
must be handled by user software before communication can start. When this is done, writing a
byte to the SPI Data Register starts the SPI clock generator, and the hardware shifts the eight
bits into the Slave. After shifting one byte, the SPI clock generator stops, setting the end of
Transmission Flag (SPIF). If the SPI Interrupt Enable bit (SPIE) in the SPCR Register is set, an
interrupt is requested. The Master may continue to shift the next byte by writing it into SPDR, or
signal the end of packet by pulling high the Slave Select, SS line. The last incoming byte will be
kept in the Buffer Register for later use.
When configured as a Slave, the SPI interface will remain sleeping with MISO tri-stated as long
as the SS pin is driven high. In this state, software may update the contents of the SPI Data
Register, SPDR, but the data will not be shifted out by incoming clock pulses on the SCK pin
until the SS pin is driven low. As one byte has been completely shifted, the end of Transmission
Flag, SPIF is set. If the SPI Interrupt Enable bit, SPIE, in the SPCR Register is set, an interrupt
is requested. The Slave may continue to place new data to be sent into SPDR before reading
the incoming data. The last incoming byte will be kept in the Buffer Register for later use.

3

I have tried that, as stated in the original post, "I've tried making SS an INPUT or an OUTPUT, setting it HIGH, and LOW"

Have you seen it work on a Leonardo?

4

Try the examples Nick Gammon has here.

I have only done Arduino as SPI Master, not as a slave.

5

Tried that. Tried every example I can find through dozens of pages worth of google search.

It works with my UNO.

Leonardo as master, uno as slave, just fine.
Leonardo as master, leonardo as slave, can't get it to work.

Has anyone seen a leonardo (specifically a leonardo) work as a slave with SPI?

6

I was trying to comunnicate 2 Leonardos too. I had the same question, because i couldnt get any example to work.
And I realised that the problem was i didnt know the SS pin for Leonardo, so i decided to Serial.print what was the SS default pin, its pin 17. Then i looked what was the pin 17 located, so after some time i reached this site: http://provideyourown.com/2012/arduino-leonardo-versus-uno-whats-new/

Then i tried this example [Arduino SPI Serial Peripheral Interface Master & Slave Demo Tutorial - YouTube] with both RX cathodes wired and the comunnication seemed to work.

Im gonna try my original project and let you know if it works

Sorry for my bad english and my plain reply im new in this forum, hope this helps you

7

Why do you need the specific SS pin located on RX led. Why don't you use one of the digital ones to act as SS?

8

I did a test to see if bringing PIN 17 to ground (no physical pin but it can be located in the cathode terminal of the RX LED) will permanently make the LEONARDO a slave... and it worked.

But when I connected that pin (17) to SS Pin of an UNO board, the serial monitor spits out garbage... maybe it's because of timing issues at 115200 baud rate.

Anyway, for my purpose of having only 1 Leonardo slave it served my purpose.

9

OK. I have verified the above.

The Leonardo has no convenient SS pin so cannot work as a slave out of the box. My first attempt at fixing this was to hack the libraries so I could override references to SS=17. This did not break anything else but the ISR was still never called. Then I soldered onto what would be pin 17 if there was a pin, as @arnoldvillasanta had done. Lo and behold, the ISR now gets called so my hardware SPI slave can work.

I fail to see why they designed it this way. There could be a setting to allow SS to be on another pin but they did not provide that.