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

[Ole Reinhardt]

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

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