Finally got round to getting a SPI chip today, a 2-channel digital pot from Microchip.
Just wanted to clarify a couple of things though please, not specific to that chip but SPI general:
First, this page tells me that SPI pins MOSI, MISO and SCK come out at Uno digital pins 11, 12 and 13 and ICSP header pins 4, 1 and 3. This is a two part question: 1) may those assignments be moved and 2) I beeped the pins out with my meter and it's a hard connection between eg i/o pin 11 and icsp4, so even if I use the icsp header I lose the pins for other uses?
Second, the same table in the reference says SS is pin10, yet the tutorial includes the code line const int slaveSelectPin = 10; implying that that one may be moved? CrossRoads told me elsewhere "D10 must be an output, even if you use a different pin for SS" which inducates it may be moved.... so what's the point of always making D10 an output? Seems odd to me.
Lastly, the tutorial includes the lines:
digitalWrite(slaveSelectPin,LOW);
// send in the address and value via SPI:
SPI.transfer(address);
SPI.transfer(value);
Presumably the order address followed by value is expected by a slave as part of the protocol which is why there's no indication of "here comes the address" and "here comes the value" in the code?
The first: yes, the ICSP most probably will stay. The pin 11, 12 and 13 are on SPI pins on ATmega168/328 based Arduinos.
I beeped the pins out with my meter and it's a hard connection between eg i/o pin 11 and icsp4, so even if I use the icsp header I lose the pins for other uses?
Correct, they are connected on the board.
Second, the same table in the reference says SS is pin10, yet the tutorial includes the code line const int slaveSelectPin = 10; implying that that one may be moved? CrossRoads told me elsewhere "D10 must be an output, even if you use a different pin for SS" which inducates it may be moved.... so what's the point of always making D10 an output? Seems odd to me.
With SPI in master mode, the SS pin can be any GPIO pin but as CrossRoads told you, pin 10 must be configured as an output if the hardware SPI is used. But you can use it as a standard digital output in this case.
In slave mode pin 10 is fixed as Slave Select.
Presumably the order address followed by value is expected by a slave as part of the protocol which is why there's no indication of "here comes the address" and "here comes the value" in the code?
This depends on the SPI slave. Consult the device's datasheet for that specification.
Assignments cannot be moved. They are tied to hardware in the '328.
SS pin must be an output for the SPI master. A different pin may be used to go out to your device tho.
If SS is an input and taken Low, the '328 will go into SPI slave mode, and expect something else to drive the SCK line.
See section of the datasheet:
"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."
Presumably the order address followed by value is expected by a slave as part of the protocol which is why there's no indication of "here comes the address" and "here comes the value" in the code?
This depends on the SPI slave. Consult the device's datasheet for that specification.
Hmmm, might be a problem with the MCP, but I'll only test it tomorrow. Its data sheet says that the first byte is the "command byte" and apart from containing the channel number- which potentiometer- it also contains a 01 bit pair that says the next byte is the data. So, if the transfer command merely sends the channel number, it's unlikely that the command byte will contain that 01, it's more likely to contain 00 which is NOP for the MCP.
I can't see an explicit description of the bit by bit makeup of the 2 bytes for the AD5206 for which the tutorial was written.... but I'll look again.
Update.... seems the 6502 oops showing my age, 5206 expects 2 bytes of which it uses 3 bits from the first as the address and the other byte as the data... so no "01" required and sending the two bytes address & val will do the trick for that one. So I'm thinking (try it tomorrow) that I might have to make the correct bit high in my address byte (= command byte in mcp-speak) to give it the right format to be interpreted as "next byte is data".
SS pin must be an output for the SPI master. A different pin may be used to go out to your device tho.
If SS is an input and taken Low, the '328 will go into SPI slave mode, and expect something else to drive the SCK line.