How is SPI communication initiated?

hello there,

i've been wondering for some time. Let's presume this scenario. Pin 13 (SCK) of the arduino has a pulsating output. At the same time you try to upload something trough SPI, from an external programmer/board.
How does the incomming SPI pulse on pin 13 interact with the pulsating output on the same pin?

I was guessing that just before SPI communication the board is reset, and while booting the SPI takes control with an initialisation message or something.

Unless you are currently using SPI, the SCK pin doesn't do anything. Even if you have devices on the SPI bus that you have talked to, when not talking to one of the devices, SCK is held... I forget if it's low or high... but it only outputs a clock signal while the SPI bus is actually transferring data.

When programming the chip over SPI (ie, isp/icsp programming), the reset line is held low, so the program stops running, so whatever signal the arduino was outputting on SCK, or any other pin - it's not outputting it there anymore.

If the chip was acting as an SPI slave, and that was trying to talk to the avr over SPI (hence outputting clock and probably data on SCK), this would prevent programming over SPI from working. Likewise, any other sort of signal on those pins while trying to program it would cause problems. You can still have other SPI devices on the bus, as long as the CS line is kept high (ie, with an external pullup) while programming the AVR over SPI.

far_1:
hello there,

i've been wondering for some time. Let's presume this scenario. Pin 13 (SCK) of the arduino has a pulsating output. At the same time you try to upload something trough SPI, from an external programmer/board.
How does the incomming SPI pulse on pin 13 interact with the pulsating output on the same pin?

I was guessing that just before SPI communication the board is reset, and while booting the SPI takes control with an initialisation message or something.

The SPI bus is a shared bus, to negotiate the sharing, the 'master' device controls the SCK all of the time, (not really shared). to select which slave should be responding to the 'Master' request, each of the slaves has a CS (chip Select) pin that is taken LOW as a control,attention signal. So, for the Arduino to control 3 SPI devices you use 6 pins; three pins shared by all devices (MOSI, MISO, SCK); three pins exclusively used. One CS pin is connected to each individual SPI device.

Pin Master Slave 1 Slave 2 Slave 3
SCK X X X X
MOSI X X X X
MISO X X X X
_CS1 X X
_CS2 X X
_CS3 X X

To program an AVR chip, the programmer puts the chip into reset. Then it drives the SS pin LOW. This causes the AVR chip to become a SPI Slave. (DrAzzy pointed out my error.) It initialized the SPI hardware and starts 'running' a hardware program as a SPI SLAVE device. this mode allow the programmer to read and write all of the Flash and most of the Fuses.

Chuck.

chucktodd:
To program an AVR chip, the programmer puts the chip into reset. Then it drives the SS pin LOW. This causes the AVR chip to become a SPI Slave. It initialized the SPI hardware and starts 'running' a hardware program as a SPI SLAVE device. this mode allow the programmer to read and write all of the Flash and most of the Fuses.

Chuck.

No it doesn't.

It holds RST low, but it does not do anything to the SS pin. The SS pin is not used when programming the chip and is not connected to the programmer. It is used for normal operation when configured as an SPI slave, but not when programming the chip.

Aha, so it guessed it sort of correctly. The reset/slave mode is needed.

I was also wondering, why is TWI not used for programming AVR chips, in other words...is there a TWI solution floating out there i don't know about? It would be one wire less, that's for sure.

DrAzzy:
No it doesn’t.

It holds RST low, but it does not do anything to the SS pin. The SS pin is not used when programming the chip and is not connected to the programmer. It is used for normal operation when configured as an SPI slave, but not when programming the chip.

Your Right, I’m wrong. I Don’t know what I as thinking.

Chuck

far_1:
Aha, so it guessed it sort of correctly. The reset/slave mode is needed.

I was also wondering, why is TWI not used for programming AVR chips, in other words...is there a TWI solution floating out there i don't know about? It would be one wire less, that's for sure.

The SPI ISP mode is a hardware function, to support a TWI reprogramming, you would have to provide a software solution. I think the design considerations evaluated the SPI interface as a better choice because of:

  • Speed
    4mhz clock speed for SPI
    0.400mhz for TWI
  • bus compatability
    The SPI protocol requires a Separate CS, these CS pin disable the slaves
    Using the TWI bus, all slaves would/could interfere with the programing
    byte stream
  • extra Hardware
    The SPI interface requires no additional hardware to use.
    The TWI interface requires pullup resistors on SDA, SCL.

Chuck.