Re: tidy STM32 SPI driver

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Chris" == Chris Holgate <chris@zynaptic.com> writes:

    >> This SPI driver did not use linker garbage collection the way I
    >> intended for SPI drivers. It created a C++ object in
    >> src/spi_stm32_init.cxx which was places in libextras.a. Hence
    >> the C++ object was always part of any application link, and
    >> because of the KEEP(*.ctors) in the linker script its
    >> constructor would never get garbage-collected. Net result: all
    >> applications would end up with the C++ object, the constructor,
    >> and the cyg_spi_cortexm_stm32_init() function, even if SPI was
    >> never used.

    Chris> That bit of code was essentially a cut and paste from the
    Chris> AT91 SPI driver, which sounds as though it may suffer from
    Chris> the same problem.

It does - and is next on my list of things to fix.

    >> I also looked at moving the three SPI buses into separate
    >> modules, built unconditionally. Again linker magic would ensure
    >> that only buses actually used by the application would end up
    >> in the application, with no need for developers to enable the
    >> relevant CDL components. This does not look entirely feasible
    >> right now, there are too many per-bus configuration options.

    Chris> Getting rid of the 'bus enable' checkboxes would definitely
    Chris> be a good thing.

    Chris> Generally, the configuration options are only used to
    Chris> statically initialise the 3 bus data structures - so it
    Chris> should be fairly easy to pull each bus data structure
    Chris> declaration into a separate compile unit with per-bus
    Chris> constructors and function tables. The common core functions
    Chris> would then only be pulled in if at least one of the per-bus
    Chris> compile units were actually referenced.

That is the general idea. Ideally things always "just work", with some
careful coding and linker garbage collection eliminating any
functionality that the application does not actually need.
Configuration options can be used when that is not possible, but do
require more effort from application developers - especially in the
absence of any driver documentation.

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.

A more flexible approach is used in the coldfire HALs, see the mcf5272
processor HAL's gpio.cdl and CYGHWR_HAL_M68K_MCF5272_BOARD_PINS in the
m5272c3 platform HAL. That exposes all the pin settings to the
configuration system, with the platform HAL providing default
settings. The approach makes it possible to support boards with
expansion connectors etc., where the platform HAL author does not
necessarily know exactly what hardware will be used. It offers a lot
of flexibility, and involves very little target-side code or data, but
at the cost of significant programming effort.

If pin setup can be left to the platform HAL then the SPI driver only
needs to worry about driving the chip select pins. That can be
handled by putting the pin id into the SPI device structure instead of
the bus structure. That should save more code and data.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
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