[En-Nut-Discussion] Driver configuration at runtime

[Harald Kipp]

Hi Ole,

sorry for not responding earlier. I'm aware, that you are not getting
tired pointing out deficiencies of the current driver implementation.
Let me tell you, that I appreciate your effort and that I feel bad not
having had a chance to test your devnut-select branch. I'm really very
busy these days.

On 07.10.2013 18:37, Ole Reinhardt wrote:
>> #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.

Yes, introducing warnings into Nut/OS builds is a bad idea. Several
developers curse this rule. I'm not willing to relax this. It's an
important part of maintaining clean and reliable code.


> Current situation:
> ==================
...
> - 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.

In early days everything was small, clear and manageable. These days are
definitely gone. Some enhancements to the Configurator would help here too.


> 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

At least for the majority of 32-bit systems, this looks like a good
solution to me. On the other hand, why not introduce a new function?
That may avoid all kind of backward compatibility issues. (I'm
suggesting this without knowing the details.)


> Pro:

Without quoting your full list again, I agree.


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

Not really. Embedded developers without knowledge about pin-assignments
may be found in the Raspberry Pi camp, but not among us.


> Implementation:

I'd suggest to go ahead. IMHO, the best candidates are the Ethernet
drivers. Specifically these bootstrap pins for PHY addresses and modes
are a real pita.


> Any comments are very welcome.

How about tiny systems? If you look to the AVR UART driver, you will
notice, that a majority of code handles hardware handshake and special
modes. Most boards do not need or do not even support such functions.
With preprocessor macros we can exclude that code, making the remaining
code small and much more responsive. How can we avoid, that your
runtime-configuration creates larger and slower code on these platforms.

One idea I can think of is providing separate drivers: One with all
bells and whistles and one architecture-specific version optimized for
small size and higher performance, but without features like
hardware-handshake. What do you think?

In fact, we already have this situation for the AVR UART driver. The
full blown version usartavr.c has many features, but is limited to
115kBaud on a 16MHz target. The old uartavr.c (note the difference,
u_s_art vs uart) supports 230kBaud on a 8MHz target and is significantly
smaller.

Regards,

Harald