Thanks Jeff, Simon, Sylvain, Please bear with me since I'm a little bit out of my comfort zone.
Sylvian first suggestion is to not called tcpip_input from the interrupt and provided a suggestion that is probably safer in the case of SYSBIOS having or not a different context between ISR and other threads. I would try to implement this change as it sounds it will be safer in either OS type. I did a little research and SYSBIOS (TI kernel) there is no distinction between hwi (isrs), swi, tasks, etc. Seems like it treats everything in the same context.I could be wrong. Simon, thanks, I already made that change to the port. Instead of calling the "input function" directly I call "return netif->input(p, netif);". On the other hand I think the port is not calling tcpip_input from the ISR context, I will still implement the change to eliminate some variables. This is how I start my code in SYSBIOS: (these are what I think are the relevant pieces to the conversation) 1. task = Task_create( (Task_FuncPtr) echo_thread, NULL, &eb); 2. tcpip_init(echo_init, &init_sem); On Fri, Jul 8, 2016 at 12:29 PM, Jeff Barlow <[email protected]> wrote: > On 07/08/2016 05:23 AM, Simon Goldschmidt wrote: > >> I know what's behind technically, with that question I'd rather meant >> what's the big deal for an OS >> to make this difference? It knows about which task is currently running >> and which got runnable, >> so it's not a big deal to know it's in interrupt context. From all the >> embedded OSes I've used so far, >> FreeRTOS is the only one to make this difference. >> >> And in my view, passing the "fromISR" around up to portions of the code >> that should be independent >> of whether run from task or from ISR sometimes makes the code design >> worse. >> > > I think you will find that ChibiOS does much the same. The reasoning as I > understand it is to keep ISR code paths as short as possible to minimize > latency in hard real time systems. > -- > Later, > Jeff > > > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
