Hi Sylvian, I think I have found proof that the tcpip_input is not a blocking call. If I break in my low_level_input, the function that will call
return netif->input(p,netif); the isr is not in the function stack [image: Inline image 1] (this is a snippet of CCS TI IDE) and actually stepping into low level input: [image: Inline image 2] which is interesting is that the tcp_thread never breaks in the expected case but tcpip_inout is being called. [image: Inline image 3] Again thanks for your assistance. On Fri, Jul 8, 2016 at 7:45 PM, Jaime Fernandez Hoffiz < [email protected]> wrote: > 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
