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 .
Another problem beside the lwIP API not being designed for multiple thread
access on the same socket, is an inability to detect stale socket (file)
handles.
Say you have an application 1 with two thread A for sending, B for receiving. Both
threads share a socket allocated as "1" and hold refe
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 sam
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
"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, why doesn't ev
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: lwip-users-bounces+ss=picio
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 r
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
exter
Hey Steffen,
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 modified LwIP to silently exit the select() call if th
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
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 mut
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 pro
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.
13 matches
Mail list logo