[En-Nut-Discussion] Hardware init

[Ole Reinhardt]

Hello folks,

I'm back again from Stuttgart, so let's discuss a bit about driver
models :-)

> a) Modify the Makefiles and add an additional object file with a .init1 
> section. This is how I am currently doing it. Disadvantage: All standard 
> Nut/OS apps makefiles need to be changed. Works only with gcc not icc.

I don't vote for any changes in the initialisation modell that makes the
code hardware dependent. In my eyes the init code should only initialize
the cpu itself and (if possible) nothing else. Even CPU internal
periphals should not be initialized at this point as long as one could
do so later.

This makes the code much more flexible and portable to other plattforms.
For me NutOS is a well designed system that runs on different
plattforms, all with different IO initialisation. So doint the init in
the .init sections I would mess up with lot's of hardware specific
changes.

> b) Adding some lines of code within an #ifdef to nutinit.c. This is how 
> arthernet does it. Disadvantage: Source code will get polluted over time 
> with custom init code. Code maintenance issues.

Same as above... The maintenance would suffer from it.

> c) Moving the hardware specific code into a device driver.
> Disadvantage: Source files need to be modified to load a driver in main().

This is, what I would vote for. We should create device drivers for
nearly every internal / external periphals as long as this makes sense.

The first stage of the main program should then initialize all the
needed device drivers.

To configure the device drivers we should either think about more
general device driver model where such configuration parameters could be
passed more or less with the driver initialisation or we should make
them configurable in header files (which could be created by the
configurator)

For me I would vote for a mixed approach.

Parameters like Memory region and interrupt should be configurable
directly when calling NutDeviceInit. Other like io-port pins and so on
should be either configurable using ioctls or using header files.

> d) Using nutconf to add the custom hardware init code based on 
> information in the .conf files to nutinit.o or Makefiles.

No, better not to nutinit.o. And also this has nothing to do with the
Makefiles. Add this settings in a plattform dependent header file if
possible.

> e) Creating a generic AVR I/O pin init module which configures all DDR 
> and PORT registers based on nutconf settings

Right, that's what I was thinking of.

Just my 2 cent,

Ole

-- 
kernel concepts    Tel: +49-271-771091-14
Dreisbachstr. 24   Fax: +49-271-771091-19
D-57250 Netphen    E+ : +49-177-7420433
--