Sorry press sent by mistake 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 a unknown. This is how I start my code in SYSBIOS:
(these are what I think are the relevant pieces to the conversation) Create and call task: task = Task_create( (Task_FuncPtr) echo_thread, NULL, &eb); tcpip_init(echo_init, &init_sem); netif_add(&netif, &laddr, &netmask, &gw, 0, arm9emac_init, tcpip_input); Set the callbacks: cppiram->txmsg = tcpip_callbackmsg_new(arm9emac_tx_callback, netif); cppiram->rxmsg = tcpip_callbackmsg_new(arm9emac_rx_callback, netif): Set the interrupts: Hwi_Handle rxisr = Hwi_create(34, (Hwi_FuncPtr) arm9emac_rx_interrupt, NULL, NULL); Hwi_Handle txisr = Hwi_create(35, (Hwi_FuncPtr) arm9emac_tx_interrupt, NULL, NULL); The interrupt for RX calls the callback and input function does not seem like it is called inside the interrupt. tcpip_input() or (ethernet_input) are called directly inside the callback not the ISR by this function: void arm9emac_rx_interrupt(void *arg)..... /* Callback */ #if !NO_SYS if (!cppiram->rxevent) tcpip_trycallback(cppiram->rxmsg); #endif maybe this is like calling it but the documentation "tcpip_trycallback" does not suggest it: /** * Allocate a structure for a static callback message and initialize it. * This is intended to be used to send "static" messages from interrupt context. Not sure what else I could be missing. Please remember that ethernet_input works. This should give some confidence that the configuration and initialization is sort of correct. Regards On Fri, Jul 8, 2016 at 7:32 PM, Jaime Fernandez Hoffiz < [email protected]> wrote: > 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
