Bart Veer <[email protected]> writes: > For the chip select handling, if I understand the code correctly then > currently the SPI driver is responsible for both setting up the GPIO > pins and for driving them. There are other ways of handling this. One > approach is for the platform HAL to set up all the pins early on > during initialization, before the static constructors, on the theory > that the platform HAL author knows what devices are attached to which > pins. That saves having to do pin setup in each driver, so saves a bit > more code.
However, I have come to almost the exact opposite conclusion. The HAL should do the minimum necessary to get the board up and running. Device drivers should then configure their own GPIO lines when they start up. This is the approach I have tried to adopt in the Cortex-M HAL, and have implemented macros and functions to make this easy to do. This simplifies the platform HAL since the author doesn't need to worry about which devices are present, and avoids ending up with a maze of ifdefs, or a lot of complicated CDL to define the pin configuration. With multi-function pins, it ensures that they get set to the correct mode for each of the loaded drivers. If a driver is configured but never used, it's pins don't get changed. This also make it easier to implement dynamic reconfiguration of the pins if they need to be shared between different devices. The cost of this is not high since the pin configuration work is usually passed off to shared functions in the HAL. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 Besuchen Sie uns vom 3.-5.03.09 auf der Embedded World 2009, Stand 11-300 Visit us at Embedded World 2009, Nürnberg, Germany, 3-5 Mar, Stand 11-300
