jobytaffey/bus-ninja — pull request #5 by pfalcon (2012-03-26 01:01:46+00:00)
Title: Fix for #2: Remove superflous SPI_CS signal, use SPI_SS as intended.

Quoting https://github.com/jobytaffey/bus-ninja/issues/2 :

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.