[En-Nut-Discussion] Hardware init

[Harald Kipp]

Hello Henrik,

to me, I/O-pin defaults is something general and would look
good in the architecture specific part of nutinit. However,
not only the CPU but also external hardware may be involved.
This can blow up nutinit over the time.

They way I included Arthernet is the worst hack. I did it
pragmatically, because I like this project and Guido started
shipping the boards. Martin Thomas sent a hacked modification
and I had been unable to sort things out in time. Frankly,
I'd become most upset, if somebody else contaminates the code
like I did. :-)

With ImageCraft you need to modify the assembler files in
arch/avr/init. That would of course require adjustments in
the Configurator scripts.

With GCC you can still add .init segments into the driver
code. If they are the same segments, they will be executed
after the segments in nutinit. That's because nutinit will
(should) be linked first. In case your driver is part of a
library (libnutdev.a), then the .init segment of your driver
is added only, if the module (C file) is referenced. At least
I hope, that it is working this way. OK, but that still gives
the disadvantage of modifying main.

May be d) is one solution, which would solve a second issue.
I never liked the requirement for NutRegisterDevice() in the
application code. The final goal is to have

int main()
{
   printf("Hello world!\n");
}

running of every hardware. Actually this was one of the motivations
for creating the Configurator.

Thus, I'd vote for using the Configurator to register all
hardware devices. And additionally assign stdin, stdout and
stderr in a further step. All this is of course optional to
maintain backward compatibility.

The big question is still unanswered: How to do it finally?
A list of

#ifdef NUTINIT_hardwarexy
    ...
    NutRegisterDevice();
    ...
#endif
#ifdef NUTINIT_hardwareyz
    ...
    MyDriversEarlyInit();

would not really make the code less readable, if the ... are
reduced to a minimum. At least I'd be able to remove Arthernet
specific code and the bad Realtek EEPROM simulation from nutinit.
But I'm not fully sure about this and would welcome other
suggestions.

Once more regarding pin settings: If you need specific pin
settings, then there is some hardware. Thus, there is a
driver somehow. A simple case are LEDs. I'd suggest to create
an LED driver with init and certain other functions for
switching an LED on or off etc. Or even more simple: A
basic port pin I/O driver. Believe it or not, I've got several
requests from Ethernut users about how to do this. Software
people do not like to read datasheets, they want API functions.
Beside that, outb(PORTF, 0x02) is not portable.

The result of my long post: I haven't found the final answer
myself, but wanted to throw in some of my thoughts. Ole, who
is currently not available, suggested some major changes to
the driver model. I'd be interested in getting more details
from him when he is back.

Harald

At 15:50 02.06.2005 +1000, you wrote:
>Hello,
>
>I like to incorporate some hardware specific initialisation into Nut/OS 
>projects to support our Ethernut compatible XNUT hardware module. In 
>particular I/O pin defaults.
>
>There are several options how this can be accomplished:
>
>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.
>
>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.
>
>c) Moving the hardware specific code into a device driver.
>Disadvantage: Source files need to be modified to load a driver in main().
>
>d) Using nutconf to add the custom hardware init code based on information 
>in the .conf files to nutinit.o or Makefiles.
>
>e) Creating a generic AVR I/O pin init module which configures all DDR and 
>PORT registers based on nutconf settings
>
>f) Other suggestions?
>
>I like to discuss which method should be the preferred one and used in the 
>future.
>
>Cheers
>
>Henrik
>
>--
>proconX - Protocol Converter, Device Server and Industrial Gateways
>http://www.proconx.com  Tel: +61-402 970 933   Fax: +61-7-3009 0399
>_______________________________________________
>En-Nut-Discussion mailing list
>En-Nut-Discussion at egnite.de
>http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion