[En-Nut-Discussion] Driver configuration at runtime

[Ole Reinhardt]

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

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/mach-at91/board-sam9260ek.c?id=refs/tags/v3.2.51

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;
}

main()
{
    ...
    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,

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