[En-Nut-Discussion] Driver configuration at runtime

[Ole Reinhardt]

Hi Harlad,

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

No problem :-)

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

Yes. I agree, that working on the configurator could also be of much
benefit for the users.

Just a few ideas to mention:

- Storing the current setup of the Configurator GUI (content of
  "edit/settings" dialog along with your project (locally) and not
  referenced by the name of the .conf file in a global configuration
  file. Currently this prevents me from having different configuration
  setups for the same board. And working in different trees with the
  same setup is not easy without re-configuring the edit/settings
  dialog all over again.

- Adding a "conflicts" rule.
  We have a "provide" and a "requires" rule, but nothing to define
  options that exlude eachother.

- Re-structuring of the driver tree, etc. Perhaps sub-grouping drivers
  (SPI drivers, I2C drivers, Network drivers, ...)

- Add options to enable / disable build of drivers.
  Currently all are on by default. And lots of options just show "yes
  this is available" but without any further option behind.


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

I think I did not get your point, sorry :-)

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

Thanks :) Exactly my opinion. :)

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

Exactly. The second ones are the USART drivers of the cortexes. These
provide that much different options for the pin-settings, that adding
all options to the configurator is horrible. But defined as a struct,
these settings became quite lightweight.

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

Yes, AVR is quite simple in this regard. Therefor: Why not keep the
known, well working code here? We don't need to implement this kind of
setting for each and all devices. That could be done over the time.

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

Yes, sure. I don't want to remove the preprocessor configuration
wherever it is of benefit.

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

Nice idea! And yes, why not? Or even better: provide both.

Let the preprocessor disable some options, and the remaining could be
configured ideally on both ways. (e.g. the configurator could provide
the default settings for the structs during compile time).

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