[En-Nut-Discussion] Driver configuration at runtime

[Ole Reinhardt]

Hi Uwe,

Am 10.10.2013 19:03, schrieb bon at elektron.ikp.physik.tu-darmstadt.de:

> Several comments:

First of all:

Thank you for your objections and ideas! Most of them are important to
think aboud.

But anyway, I have a feeling, that no one of the critics want to take a
few minutes to at least think about the concepts and no one really wants
to find a working trade-off between both concepts.


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

Good point. And not that easy to solve.

As mentioned in my first mail, we won't get arround writing board files
for the maintained and supported eval boards.

Anyway that would be a good idea to seperate board initialisation and
driver loading from the application code.

In other words:

- in my eyes, basic initialisation of the Pin-muxing for example should
  be done in the board init.

- Loading of the basic drivers (NutRegisterDevice()) should be done in
  the board init as well. This way the end-user would not need to care
  about any configuration at all and just can run the main application
  code.


Beside of that:

As we get more and more supported plattforms with different
capabilities, we will come up with more and more samples, that are not
easy to use on all platforms.

Just have a look into your own "nut/hwtest/cm3/stm"


So why not slip the samples into a generic part (inner application code)
and the low-level hardware initialisation part.

The end-user may finally learn more...

>   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.

How much space has been saved?

And especially the STM32 OWI driver looks like a good example for run
time configuration, just 5 selections...

Sure, you may want to do some sanity checking for the values set, but if
needed you could do this with NUTASSERT(), which will be included only
for debugging builds.

> - 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.

Sure, you will always find situations, that won't fit perfectly to this
concept. I just mentioned a few times, that we also won't completely get
rid of the confiugrator. But perhaps we can clean up the configuration
options and provide the basic options during run-time.

> - 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.

We discussed this over and over again... And I agree, we shoudl _try_ to
get a common api. But not only GPIO settings are of interest. Also the
assignment of interrupts, I2C addresses, baudrates, SPI modes und much more.

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

Really? Not _that_ much.
And with the current implementation you can not even freely select the
I/O pins but only have a choice of two alternatives?

I/O pin configuration: Could be done by defining a set of Pin settings
Handshake, Duplex mode, irda-mode, rs485 mode etc. could be configured
using flags.

rs485 configurations would be implemented by a sub-struct...

> - 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.

It will enhance code readability. Flash size may even perhaps increase a
little. But only a very little.

And it will allow you to compile the OS libraries once and use it on
several boards.

> But it
>   costs at run-time as at least the configutation structure needs to
>   be resolved, not speeking of equalizing eventual non-orthogonalities.

I realy don't see the overhead. Most of the settings are implemented in
code anyway. The only difference is that you do not read the value from
a constant, but from a struct member.

And these orthogonalities: Where do you handle them now? In the
configurator? Yes if you want to write a total error proof driver, you
will have to check the settings...

>   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.

What use case do you think off here? I do not know what kind of
calculations would be needed...

And yes, we will need a few bytes of ram. The configuration itself will
be a flash item as long as you do not run the code in ram.



Best regards,

Ole


-- 
kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de