[En-Nut-Discussion] Nut/OS Initialization

[Henrik Maier]

Hi Harald,

I actually like the way how it's done currently. 

I do the registration of the UART device drivers as part of the power on
self test and test the return code. The initialisation of the Ethernet
device driver is done at a later stage.

I share one Nut/OS binary amongst a dozen of projects but none of them have
the same init code. Moving the registration into Nut/OS itself would require
maintaining a Nut/OS binary for every project. Not ideal.

I understand the reasoning about the Hello world example. Like you suggested
what about including a basic HardwareInit() which works for simple projects
like Hello World. 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(). The linker will find that first and then not search the
library.

Henrik

> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Harald Kipp
> Sent: Tuesday, 16 September 2008 2:56 AM
> To: Ethernut User Chat (English)
> Subject: [En-Nut-Discussion] Nut/OS Initialization
> 
> I'm opening this new topic to share my view about Nut/OS initialization,
> which is related to the latest discussion about NutRegisterDevice used
> on Ethernet devices.
> 
> Most operating systems handle device driver initialization different
> from Nut/OS. Most OSes include all required drivers, either directly
> linked to the kernel or dynamically loaded from external storage.
> 
> Nut/OS runs without external storage, dynamic loading/unloading is no
> option. In order to avoid rebuilding the kernel each time a new device
> is used, Nut/OS uses the linker to include just the device drivers used
> by the application. The link reference is provided by
> NutRegisterDevice().
> 
> Many tiny OSes use a similar approach. The other side of the coin is,
> that a number of initialization calls are needed at the beginning of
> main(). My initial intention had been to allow
> 
> int main(void)
> {
>    printf("Hello world!");
> }
> 
> In fact, the Nut/OS version looks less beautiful:
> http://www.ethernut.de/nutwiki/Hello_World!
> 
> As more complex devices are added, the main() routine becomes
> contaminated with system specific code.
> 
> One suggested solution would be to implement a callback function like
> HardwareInit(), which has to be included into the application
> "somewhere". IMHO, this is not more elegant than simply calling
> HardwareInit() at the beginning of main.
> 
> Another solution may be to find a compromise between both worlds. The
> Configurator may allow to preregister some initializations, like it is
> doing now with heap memory. So the user may select to use UART0 for
> stdin/stdout, the SMSC driver for Ethernet etc. Of course, changing
> devices requires a rebuild then. But in addition the application is
> still free to add more devices in the old way, without rebuilding the
> kernel.
> 
> On some hardware, stdio will always go to the first UART at 115200 Baud
> and, if the Ethernet driver is included in the CPU, exactly that
> Ethernet driver will be used, typically with DHCP. Why not pre-register
> these devices and services via the Configurator's .conf files (or
> hardware specific header files when building in the source tree without
> using the Configurator)?
> 
> Harald