tobyjaffey / bus-ninja

AVR Bus-Pirate-a-like
http://blog.hodgepig.org/busninja/
89 stars 33 forks source link

Confusion regarding SPI_SS and SPI_CS #2

Closed pfalcon closed 12 years ago

pfalcon commented 12 years ago

It seems there's confusion in how bus-ninja handles SPI_SS and SPI_CS signals. SPI_SS is the native AVR SPI Slave Select signal. The issue, it is driven automatically by MCU only in slave mode. In master mode it is, well, just a GPIO, which is described in ATmega168 datasheet:

page 79: SS: Slave Select input. When the SPI is enabled as a Slave, this pin is configured as an input regardless of the setting of DDB2. As a Slave, the SPI is activated when this pin is driven low. When the SPI is enabled as a Master, the data direction of this pin is controlled by DDB2.

page 162: 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.

So, essentially, it is a convention that master will use the same SS signal, it could use any other GPIO (and in case of multiple slaves it will have to use different GPIOs as Slave Selects). But nonetheless, it is good convention to follow.

So, what's SPI_CS then? Answer: there's no such thing in SPI, and so its presence in bus-ninja is likely result of confusion, and leads to even more confusion for its users (took me some time to wade thru this stuff).

Suggested fix:

  1. Remove SPI_CS defiinition.
  2. Make hw_spi_cs_assert() & hw_spi_cs_deassert() to operate on SPI_SS.

After that, there may be feature request:

  1. Make SPI_SS pin configurable, with default still being native MCU SS pin per datasheet.
tobyjaffey commented 12 years ago

Merged, thanks.