|
From: | Bram Peeters |
Subject: | [lwip-users] LWIP_NETCONN_SEM_PER_THREAD => sys_sem_t type problems |
Date: | Wed, 23 Nov 2016 11:30:40 +0000 |
Hi,
I am enabling LWIP_NETCONN_SEM_PER_THREAD and currently trying to work out the LWIP_NETCONN_THREAD_SEM_GET LWIP_NETCONN_THREAD_SEM_ALLOC LWIP_NETCONN_THREAD_SEM_FREE functions/defines on a freertos based system (using lwip 2.0.0). I am a bit running into a wall however because of the way sys_sem_t is typedef'ed in my port (sys arch): typedef osSemaphoreId sys_sem_t; with typedef SemaphoreHandle_t osSemaphoreId; (cmsis layer) typedef QueueHandle_t SemaphoreHandle_t; (freertos layer) typedef void * QueueHandle_t; (freertos layer) In the end this means: sys_sem_t = void *
So there is a mismatch because lwip wants a type that matches with the actual semaphore and not an indirect handle, while freertos
does not give you visibility on the underlying type and only defines the indirect handle type publicly. Now, I run into issues with
LWIP_NETCONN_SEM_PER_THREAD because
LWIP_NETCONN_THREAD_SEM_GET is supposed to return a
sys_sem_t *, so a pointer to a pointer. In LWIP_NETCONN_THREAD_SEM_ALLOC you would want to store the SemaphoreHandle_t = void * pointer to the semaphore object in thread local
storage, but then what do you return in LWIP_NETCONN_THREAD_SEM_GET ? It needs to be a pointer to some persistent intermediate pointer to the real semaphore object, but I do not have such a persistent
intermediate pointer available. Solutions I see: [1]
In LWIP_NETCONN_THREAD_SEM_ALLOC do an extra malloc of a pointer variable besides creating the semaphore, fill in the handle of the semaphore in that pointer variable and return
the address of the pointer variable in LWIP_NETCONN_THREAD_SEM_GET [2] Expose the real semaphore type from freertos and typedef that to
sys_sem_t (instead of the handle/pointer type).
[3] Replace the sys_sem_t type in lwip by a sys_sem_handle_type. Stuff below (sockets.c) gives me the impression that this would make things much cleaner #if LWIP_NETCONN_SEM_PER_THREAD #define SELECT_SEM_T sys_sem_t* #define SELECT_SEM_PTR(sem) (sem) #else /* LWIP_NETCONN_SEM_PER_THREAD */ #define SELECT_SEM_T sys_sem_t #define SELECT_SEM_PTR(sem) (&(sem)) #endif /* LWIP_NETCONN_SEM_PER_THREAD */ [4] ... ? Option [3] is the only clean one I think but would take way too much time, so I will go either for [1] or [2] unless someone has a
nice [4] ? TLDR: choice for 'direct' semaphore type in lwip seems to lead to messy workarounds because not all OS'es support direct semaphore
types.... Any thoughts / suggestions ? Regards Bram
From: Bram Peeters
Hi,
What is the recommended sequence to start DHCP with the latest git sources (anno 20150910) ? In the past dhcp_start() would automatically bring up the interface, and there is still a lot of references floating around to that way of working. Eg in netif.c /** * Bring an interface up, available for processing * traffic. *
* @note: Enabling DHCP on a down interface will make it come * up once configured. *
* @see dhcp_start() */
void netif_set_up(struct netif *netif) { if (!(netif->flags & NETIF_FLAG_UP)) { netif->flags |= NETIF_FLAG_UP; So that note is wrong now because dhcp_start has an error on a down interface: err_t dhcp_start(struct netif *netif) { struct dhcp *dhcp; err_t result; LWIP_ERROR("netif != NULL", (netif != NULL), return ERR_ARG;); LWIP_ERROR("netif is not up, old style port?", netif_is_up(netif), return ERR_ARG;);
I have some stm cubemx generated code that says the following: void LWIP_Init(void) { tcpip_init( NULL, NULL );
ipaddr.addr = 0; netmask.addr = 0; gw.addr = 0;
/* add the network interface */ netif_add(&gnetif, &ipaddr, &netmask, &gw, NULL, ðernetif_init, &tcpip_input); /* Registers the default network interface */ netif_set_default(&gnetif); if (netif_is_link_up(&gnetif)) { /* When the netif is fully configured this function must be called */ netif_set_up(&gnetif); } else { /* When the netif link is down this function must be called */
netif_set_down(&gnetif); }
dhcp_start(&gnetif); ... } But this appears incorrect (netif_is_link_up checks a flag that is set by netif_set_up, does not seem to make any sense at all in a chicken vs egg kind of way ??). I tried the following in my polling loop which checks the phy for the link status: if ( regvalue
& PHY_C1R_LINK_STATUS ) /* Link detected */ But that still triggers the
LWIP_ERROR("netif is not up, old style port?", netif_is_up(netif), return ERR_ARG;); in dhcp_start.
Suggestions are welcome ... |
[Prev in Thread] | Current Thread | [Next in Thread] |