This is the mail archive of the
mailing list for the eCos project.
Re: tidy STM32 SPI driver
- From: Chris Holgate <chris at zynaptic dot com>
- To: ecos-patches at sourceware dot org
- Date: Wed, 11 Feb 2009 11:29:22 +0000
- Subject: Re: tidy STM32 SPI driver
Apologies for breaking the thread, but I don't actually subscribe to the
patches list so can't just hit reply!
> 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.
That bit of code was essentially a cut and paste from the AT91 SPI
driver, which sounds as though it may suffer from the same problem.
> 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.
Getting rid of the 'bus enable' checkboxes would definitely be a good thing.
Generally, the configuration options are only used to statically
initialise the 3 bus data structures - so it should be fairly easy to
pull each bus data structure declaration into a separate compile unit
with per-bus constructors and function tables. The common core
functions would then only be pulled in if at least one of the per-bus
compile units were actually referenced.
I'll have a look at it.