[En-Nut-Discussion] Nut/OS Initialization

[Harald Kipp]

Alain M. wrote:
> The reason is not only phylosophical, it makes simple debugging become 
> possible nightmares. As you apen a nut system in Eclipse it goes 
> straight to main() and you cannot debug anything before that. I had to 
> do it with Nut, and it took me 2 days to find a simple error in one 
> initialization ... :(

Another good argument to let us distinguish between system and 
application initialization.

If you are an application programmer, you rely on a bug free OS and 
start debugging at main(). If main calls your application specific 
HardwareInit(), you need to debug this as well.

If you need to debug the OS, you have to find a way to start debugging 
at the reset entry.

And luckily this will perfectly fit with my initial intention. :-) 
Here's my view so far:

1. Basic hardware initialization is typically done for a specific CPU, 
sometimes for a specific board. We should move this out of NutInit to 
new modules. Example: System timer initialization.

2. Default initialization is done for a specific board, pre-initializing 
the available hardware to some meaningful defaults. When building the 
Nut/OS libraries, the developer must have the choice to disable this 
fully or partly. Example: NutRegister the UART device, set the baud rate 
and redirect stdout to it.

3. Application initialization is done by the application programmer and 
takes place after main is called.

I'm happy with this and you all like it too, right? ;-)

Harald