The lwIP demo that ships with FreeRTOS initialises the network interface in the task that runs the webserver, having tried to move the code out, I now know why it’s in there. (it causes a data abort if called from outside a task!) Inside the ethernetif_init routine is a call to sys_timeout, now this will only work if it is called from a task because its timeout list is per task, otherwise it returns NULL. I don’t want the network initialisation code inside a task because to me it’s not conceptually the right place for it to be, my solution has been to replace the sys_timeout call with a task which blocks the same amount of time and then calls the arp_tmr function. (it’s doing exactly the same as sys_timeout call). Are there any disadvantages to doing this? Is there any reason that richard didn’t do this? Ok, I’m eating up a bunch of RAM having this task doing it this way, but it means that my other tasks have access to the tcp stack as soon as they start up, they’re not dependant on another task initialising the ethernet interface. Thanks.
The initialization will have to be in the task if either it blocks (what happens if the network cable is not connected?), calls a blocking function, or uses a queue or semaphore that is not created until the task is running. Any of these things could cause it to crash. Otherwise I don’t see why to do in in the task. My hardware is initialized before the scheduler is started.
This is an "after the event" question, it works absolutely fine. I was just wondering why richard chose to do it the way he did it rather than starting a task to handle the arp timer.
Probably because that is how it is done in the uIP demo – and that come first ;-)
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.