[En-Nut-Discussion] Driver configuration at runtime

[Henrik Maier]

Hi all,

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.

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

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

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

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


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.


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.

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

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.


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.

Cheers

Henrik



On 8/10/2013 2:37 AM, Ole Reinhardt wrote:
> Hi all,
>
>> This would expand to something like:
>>
>> #ifndef NUT_DRIVER_hd44780_DISABLED
>>
>> <driver code>
>>
>> #else
>> #warning "Driver hd44780 is disabled"
>> #endif
>
> Please note that Nut/OS compiles with -Werror enabled and the warning
> will stop compilation. So you would not be able to compile the Nut/OS
> tree without having configured default values for each driver.
>
> At this place I would like to start the discussion about general driver
> configuration again.
>
> We just talked about it at several places before, but obviously we did
> not find a final good solution until now :-)
>
> Current situation:
> ==================
>
> - Almost all drivers will be configured during configuration time in
>    the configurator
>
> - Configuration includes I/O pin configuration, Addresses, Default
>    values etc.
>
> - As long as you can not live with the default settings, the settings
>    have to be modified for each board seperately and the settings are
>    widespread all over the configuration tree.
>
>
> Pro:
>
> - For the reference boards, the user can take the board configuration
>    file and compile the Nut/OS libraries. The arch/xxx/boards/my_board.c
>    file includes the perhaps needed special configuration. Further
>    configurations are mostly not needed during the boot process.
>
> Con:
>
> - The Problem Thiago pointed out: For non-standard boards you need to
>    configure the driver settings seperately.
>
> - Lots of drivers (like EMAC driver for AT91 for example) does not even
>    provide a configuration option for each of the I/O pins used.
>
> - When writing a driver you have to add a whole bunch of settings to
>    the configurator.
>
> - There is no common place to configure the drivers.
>
> - ...
>
>
>
> My Idea:
> ========
>
> - When configuring the drivers on run-time, we won't need any
>    configurator entries for pin and address etc. configuration at all.
>
> - Currently we have NutRegisterDevice(dev, address, irq). Nearly no
>    driver uses the parameter address or Irq
>
> - Other systems (Linux for example) implement a run-time configuration
>    for platform specific devices. Which I would like to introduce as an
>    example below.
>
>
>
> Pro:
>
> - If consequently implemented for all drivers, we could compile one
>    Nut/OS tree and use it on several boards of the same platform without
>    re-building it, just because one setting (like an assigned I/O pin)
>    has changed. This can be helpful especially for different boards of
>    the same type (e.g. different boards revisions or mounting variants).
>
> - The developer can easily check if all settings are correct as he has
>    all settings together in one C file.
>
> - You can easily change a setting without re-compiling the whole Nut/OS
>
> - You can provide the setting structs in your board file.
>
> Con:
>
> - You have to write a board file for each board or provide the needed
>    configuration structs in you main.c
>
> - If you are a newbie you might have to understand the pin-assigment
>    etc. to be able to change the driver configuration.
>    But in fact: As a newbie you would have got problems with the
>    configurator as well... Finally changing a driver setting always
>    needs at least a basic knowledge of what you are doing.
>
>
>
> Implementation:
>
>
> This is just a very rough idea and needs to be worked out:
>
> Extend the NUTDEVICE by a void pointer "platform_data";
>
>
> typedev struct {
>     ...
>     ...
>     void *platform_data;
>     ...
> } NUTDEVICEM
>
> New device registration api:
>
> NutRegisterPlatformDevice(dev, void* platform_data)
>
>
>
>
> gpio.h:
>
> struct io_pin {
> 	int pin;
> 	int port;
> 	int af_function;
> }
>
> my_driver_header.h / avr_usart.h / ...
>
> struct uart_platform_data {
> 	struct io_pin rx_pin;
> 	struct io_pin tx_pin;
> 	long   baudrate;
> 	...
> }
>
> board.c / main.c / ...
>
> 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);
> }
>
>
>
>
> In the above example most of the defines will be implemented once in the
> driver header files. The user won't have to implement them by their own.
> The user only have to fill the  uart_platform_data struct and pass it to
> the NutRegisterPlatformDevice().
>
> Any comments are very welcome.
>
> Best regards,
>
> Ole Reinhardt
>