I'm currently working on the SPI low-level driver (for stmf4discovery) corresponding to the interface introduced by @haukepetersen some weeks ago. The interface does not provide a parameter for a multi-slave bus setup, where different "chip select" pins are needed (one for each slave). Now the questions are:
- Is the multi-slave setup ever needed in our context or will one fix master-slave setup suffice?
- Will it be ok if the chip-select pins of a multi-slave setup are handled manually outside the driver?
- Or is it useful to adapt the SPI interface for this functionality?
I'm currently working on the SPI low-level driver (for stmf4discovery)
corresponding to the interface introduced by @haukepetersen some weeks
ago. The interface does not provide a parameter for a multi-slave bus
setup, where different "chip select" pins are needed (one for each
slave). Now the questions are:
- Is the multi-slave setup ever needed in our context or will one fix
master-slave setup suffice?
Multi-Slave mode is indeed needed.
- Will it be ok if the chip-select pins of a multi-slave setup are
handled manually outside the driver?
The concept is, that a high-level device driver has to take manually
care of CS lines. In the driver model this is done using the GPIO driver.
- Or is it useful to adapt the SPI interface for this functionality?
I would vote not to do so. The concept right now is, that all CS pins
are handled manually by the high-level device driver. This has some
important advantages:
- not all platforms support CS lines per hardware, and further the
number of supported pins differs vastly
- there are some SPI devices, that need a high-active CS line. This
means that the SPI driver would need a parameter for this -> higher
complexity of the low-level driver
- timings for CS can be better controlled for each device -> again: less
complexity for the low-level SPI driver
- the pin-mapping for the CS lines is more flexible
The disadvantage of this approach is of course, that the code for
high-level device drivers looks a little more cluttered with additional
gpio_set|clear calls, but I think the advantages above make up for it.
