This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
Re: tidy STM32 SPI driver
Bart Veer <bartv@ecoscentric.com> 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