[En-Nut-Discussion] Nut/OS Initialization

[Alain M.]

Just my 2c:

a function called NutInit() or something ... could do whatever is needed 
and create a thread to do initializations that take a considerable time, 
like DHCP or ethernet if a cable is disconected. Such thread could 
detect at any time when the cable is reconected.

Such structure could be easely be modified for any specific need, as 
long as basic structuture like ioctl and appropriate fucntions are 
available.

Alain

Harald Kipp escreveu:
> 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
> 
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 
>