[En-Nut-Discussion] Nut/OS Initialization

[Thiago A. Corrêa]

On Tue, Sep 16, 2008 at 8:28 PM, Henrik Maier <hmlists at focus-sw.com> wrote:
>> -----Original Message-----
>> > If HardwareInit() is kept in a separate linker module
>> > (this is important!), users like myself can simply override it on a
>> project
>> > basis by providing project specific object file with a custom
>> implementation
>> > of HardwareInit().
>>
>> Yes, this "hidden initialization" should not add any code if not
>> configured. Or the other way round, it will be configured by default to
>> allow an easy start for newbies. Programmers may disable it without
>> penalty.
>
> This sounds like a way to go forward then!
>
> Henrik
>

The Atmel library for 802.15.4 MAC has several functions that can be
implemented or not, and when they are implemented, they act as
callbacks from the stack.

I don't know exactly how this is implemented in the C code, but we
could use this approach to remove the hardware init from main.
If some void hardwareInit() is provided, then it will be called before main (?)

This way it remains compatible with older software.

Personally, I wouldn't change my own firmware with that, as it's much
cleaner from reading main what things do than expecting someone to
previously know of the magic callback or whatever does the
initialization.

Either way, this is not much different than making your own
hardwareInit and calling it from main as Harald pointed out. Thus the
cleaner main could be said to be more related to how you organize your
code than an Nut API issue IMHO.

We already have times when we need to recompile ethernut to target
small hardware variations (such as different display sizes, and
sometimes one hardware has RTS/CTS options and the other doesnt), so
adding more of those variations with the hw initialization on the Nut
Configurator is something that I would really rather not have.

Kind Regards,
   Thiago A. Correa