[En-Nut-Discussion] Driver configuration at runtime

Ole Reinhardt ole.reinhardt at embedded-it.de
Thu Oct 10 16:30:05 CEST 2013

Hi Henrik,

> I think it is a good idea to have another look at the way hardware is
> configured.
> These are my thoughts:
> a) Run-time configuration
> - Run-time configuration will usually always be more costly in regards
> to code, so we may even more so increase the code size of our humble
> 8-bit AVR targets.

The only code size that will be added is the size of the configuration
struct itself. And in fact you can't avoid it.

> - I believe there are too many variants of configuration items and
> methods, to mention interrupts controllers, logic, FPGAs, DMA, alternate
> pin combinations and so forth that I believe what ever smart method we
> come up now, the day will come when another #define hack is needed
> because the new method won't do its job. There is a reason why the
> current NutRegisterDevice's  address and IRQ parameter is hardly used by
> a driver.

Sure you may still end up with some defines. But I'm note sure if you
got my point:

I do not want to remove all #ifdefs and I also do not want to place any
configuration option into the configuration struct that will be passed
to the driver on registration.

The main purpose of this run-time configuration shall be the I/O pin
configuration and perhaps other default values like a baudrate of an
UART or SPI, etc. For I2C drivers it could also be the I2C address to
use etc.

> - We can't compare with Linux, it has different requirements as the same
> binary has to run on different hardware as most drivers are dynamically
> loaded. Nut/OS does not have this requirement and is almost always
> compiled for a specific hardware.

I do not compare Nut/OS to Linux, but one can learn from eachother (ok
Linux won't learn much from Nut/OS, but we can learn from Linux).

Why not take over a good working concept?

And even on linux this method is not used for dynamically loaded drivers
but for those which are platform specific. So called "platform devices".

In other words: exactly the same as on Nut/OS. Those devices and their
configuration are very specific to the hardware.

A quite nice example is


I took an older kernel tree with intent, as more recent kernels mostly
use device tree for configuration.

> - Some configuration stuff is so hard to do at run-time and requires
> considerable more effort by the developer. There are also cases where
> configuration settings apply to multiple peripherals.

Again I'm not sure if you got my ideas correct. It's not my intention to
create a runtime setting for each possible configuration, but I just
want to move a few device specific config options from the configurator
to the user code.

For example see my first sample of an uart:

static struct uart_platform_data = {
	.rx_pin = {27, NUTGPIOPORT0, AF_3},
	.tx_pin = {28, NUTGPIOPORT0, AF_3},
	.baudrate = 115200;

    NutRegisterPlatformDevice(devUsart0, &uart_platform_data);

> - How are all the possible (and not possible) configuration parameters
> documented?

Good point! For sure they would need to be documented along with the
driver implementation.

Each driver (that supports this kind of configuration) will need to
define a struct xxxx_platform_data {} which holds all its possible
options. For sure this struct needs documentation.

Anyway: The settings in the configurator mostly are not well documented
as well.

> b) Compiling drivers which are not required/suitable for a hardware
> This has bothered me for a long time too when compiling drivers I am not
> using and they fail with an error or warning. This could be solved by
> adding driver selection to the configurator, so only
> "approved/certified" drivers get compiled for a particular board.

This however is a complete different discussion :)

But ideally I would like to compile all possible drivers during build of
Nut/OS. Compilation may take a little longer, but it will allow us to
use them later on if needed (during link time of the application).

> c) nutconf and friends
> As a user I like nutconf because it documents the vast set of drivers
> and features of Nut/OS. The power and flexibility of Nut/OS is best
> understood by browsing the nutconf's tree. I even thought wouldn't it be
> great to have an Eclipse based Nut/OS IDE where nutconf becomes an
> Eclipse plugin one day.

You are wellcome to implement it :-)

> But then I guess most users use nutconf only to compile Nut/OS and never
> tweak the configuration settings.

Exactly. I only use Nutconf once for setting up the tree... In reality I
could live well with nutconfigure, the command line version.

But again: I do not want to replace nutconf, but move just a little of
the configuration complexity into the code.

Would'nt it be great, if you could use the same libraries on different
boards without re-configuring it all over again?

> As an OS developer it puts additional burden on me as instead of adding
> a simple #define to choose a feature I have to understand LUA syntax and
> add entries to the hierarchy of conf files.

Exactly. This cost me lots of time to add just an I/O pin configuration
for lets say an ethernet driver, where you have to configure 10 +
signals on some boards.

> d) Conclusion:
> I am yet to be convinced that there are really advantages. The coding
> effort and in particular increased code size (even only for range
> checking of parameter values) is a big drawback for my opinion.
> Before we roll it out at least I would like to see one or two reference
> implementations of non-trivial drivers.

Well, I'd be happy to open a new branch and implement this concept at
least for some platform specific drivers e.g. for the cm3/lpc.

We could easily add other drivers step by step without breaking any
code. If you like you could even stay with the old way in parallel...

Best regards,


kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen

More information about the En-Nut-Discussion mailing list