[lwip-users] multiple timers.c in project

Dear lwip community, I am using lwip on freeRTOS 7.4.2 and everything is working. Now I would like to use additionally the freeROTS timer (defined in timers.c). The problem is that my CrossStudio has some linking problems, I think it could not deal with two timers.c within the same project.

Re: [lwip-users] multiple timers.c in project

Sebastian Subik wrote: I am using lwip on freeRTOS 7.4.2 and everything is working. Now I would like to use additionally the freeROTS timer (defined in timers.c). The problem is that my CrossStudio has some linking problems, I think it could not deal with two timers.c within the same

[lwip-users] Multi-threaded socket access once again

Dear all, I'm trying to access a TCP socket from multiple threads. One thread is listening for incoming data while multiple threads are submitting data. I've learned and understood from other postings that lwIP's sockets are not thread safe, so I protected the calls to the send routine with a

Re: [lwip-users] UDP Raw receive / pbuf_free?

Hi Friedrico, I see you call udp_connect lots of times (once every new incoming packet), without actually calling udp_disconnect(). I don't know if this causes trouble, or the function will just return an error condition. BUT, in such a case that this function is returning != ERR_OK, you will exit

Re: [lwip-users] Multi-threaded socket access once again

Hey Steffen, insert the usual not supported answer here first Having said that, it seems like an okay setup if there are no other unexpected accesses. For example if another task closes the socket while your receive task is in the select() you'll also be in trouble. For our adaptation we

Re: [lwip-users] Multi-threaded socket access once again

Hi, We used LwIP in similar scenario, but with one task responsible for this socket/netconn. Using internal RTOS queues to pass data to this single task was relatively simple, and all multitasking problems were avoided. Are there any reasons you cannot use this socket in single thread with

Re: [lwip-users] Multi-threaded socket access once again

Hi Fabian, thanks for your reply. The submitting threads should always be stopped before the application closes the socket. The receiver thread does all the socket management, like open, close, bind, accept etc. and also controls the other submitting threads. But I'm not sure what happens if the

Re: [lwip-users] multiple timers.c in project

Thanks Simon, I hoped that there are better solutions available, but your solution should definitely work. Maybe lwip can consider renaming their timers.c within a future release to avoid such kind of problems... Best Sebastian -Ursprüngliche Nachricht- Von:

Re: [lwip-users] multiple timers.c in project

Sebastian Subik wrote: I hoped that there are better solutions available, but your solution should definitely work. Maybe lwip can consider renaming their timers.c within a future release to avoid such kind of problems... You could ask the same from FreeRTOS. In fact, sarcasm why doesn't

Re: [lwip-users] multiple timers.c in project

Hi, On Fri, Jul 18, 2014 at 06:32:57PM +0200, Simon Goldschmidt wrote: Sebastian Subik wrote: I hoped that there are better solutions available, but your solution should definitely work. Maybe lwip can consider renaming their timers.c within a future release to avoid such kind of

Re: [lwip-users] multiple timers.c in project

On 18/07/2014 17:32, Simon Goldschmidt wrote: Sebastian Subik wrote: I hoped that there are better solutions available, but your solution should definitely work. Maybe lwip can consider renaming their timers.c within a future release to avoid such kind of problems... You could ask the same

[lwip-users] Change CONFIG_LINKSPEED_AUTODETECT to CONFIG_LINKSPEED

Hello all, In the board support package i can change the value for temac_adapter_options from CONFIG_LINKSPEED_AUTODETECT to CONFIG_LINKSPEED100. Then i can see in the haeder file, that #define CONFIG_LINKSPEED_AUTODETECT 1 is changed with #define CONFIG_LINKSPEED100 1. But in the function