Marty wrote:
> Mason,
>
> In my phy interrupt, I use:
> err_t tmp = tcpip_callback_with_block( s_HandlePhyInterrupt, NULL, 0);
>
> That puts a callback to s_HandlePhyInterrupt into the tcpip thread.
> Then in s_HandlePhyInterrupt is all the phy status processing and the
> calls to netif_set_link*().
Hello Marty,
Thanks for pointing out tcpip_callback_with_block, I wasn't
aware of such a function.
My code would look like this:
static void do_netif_set_link_down(void *netif) {
netif_set_link_down(netif);
}
static void do_netif_set_link_up(void *netif) {
netif_set_link_up(netif);
}
static int mac_link_callback(ethernet_device_t *dev, unsigned status)
{
if ((status & LINK_STATUS) == 0)
{
tcpip_callback(do_netif_set_link_down, mynetif);
}
else
{
tcpip_callback(do_netif_set_link_up, mynetif);
}
return 0;
}
But then I start to wonder: what is the point of the entire
netifapi module?
If LWIP_TCPIP_CORE_LOCKING is 0, tcpip_netifapi looks
fairly similar to tcpip_callback_with_block.
Does netifapi make sense when LWIP_TCPIP_CORE_LOCKING is 1,
in which case there is no message passing, the operation is
done within the calling context holding LOCK_TCPIP_CORE?
--
Regards.
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
