[En-Nut-Discussion] Driver configuration at runtime (was: Disabling drivers during compile time)

[bon at elektron.ikp.physik.tu-darmstadt.de]

>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:

...
    Ole> In the above example most of the defines will be implemented once
    Ole> in the driver header files. The user won't have to implement them
    Ole> by their own.  The user only have to fill the uart_platform_data
    Ole> struct and pass it to the NutRegisterPlatformDevice().

    Ole> Any comments are very welcome.

Several comments:

- How does the notion of compile time configured driver play together with the
  idea of default drivers for our examples?

  The one-wire GPIO driver was first run-time configurable. However this
  required a lot of ifdefs in the example code. I rewrote as a library
  compile time configured driver and both the driver and the (non STM32
  specific) example got smaller.

- If some configuration items are non-ortogonal, like GPIO access for the
  AVR8, or timer capabilities for the STM32, things get ugly and you need to
  clean up non-orthogonality at run time. Other such non-orthogonal items
  are probably already there and new chips will bring new strange
  things. At library compile time, this can be resolved at no costs for run
  time with things like piotrans.h or stm32timertran.h.

- Much of the complexity in common drivers is caused by our failure to
  provide and use a common GPIO API. porttran.h exposes functionality not
  available on all architectures, and for the restrictid pioarch.h approach,
  nobody from other archs chimmed in yet.

- Have a look at the STM32 USART driver and try to estimate how many
  configuation items we would need for run-time configuration.

- How often do we attach a new device to our embedded system? So run-time
  configuration is not a needed function per se, but people hope that
  RT gives better maintainable code and perhaps flash size reduction. But it
  costs at run-time as at least the configutation structure needs to
  be resolved, not speeking of equalizing eventual non-orthogonalities. It
  will cost RAM as probably the init function will calculate many things in
  advance, and the run-time configuration will be a RAM item and not a flash
  item.

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------