|Subject:||Re: [lwip-users] blocked udp|
|Date:||Tue, 27 Sep 2016 11:35:07 +0000|
Sorry but I did not understand completely your answer.
Do you use FreeRTOS or any other OS or no OS at all ?
I presume you use an OS and my reply is based on that estimate.
Let me explain. LwIP in RAW mode is not thread safe and more than that you are not
allowed to call LwIP functions outside of the LwIP context. In RAW mode all the TCP code
run’s within one task. That means that timers, TCP handshake, your application code etc…
All that is running under the same context.
So if you get some data in recv callback only after you exit the function the TCP stack returns
To do its own house keeping etc.
Were the problem is?... If you call any of the LwIP functions from your application not from within
The TCP stack context you are not synchronized with the internal code and may find your code
unstable or even crashing.
Now that I explained the above lets assume you define an array of 500 bytes. Fill it with random
data and every time you get some data in your recv function callback you call tcp_write and send
the random data. This is fine and runs within the TCP context. No problems here.
If you try calling tcp_write from within one of your task, not from inside the TCP context it may fail
or have strange behavior. The most common problem that people complain is “memory leaks”
I had that for a long time until I understood the problem and added synchronization code.
You must find a way to synchronize your data creation and the need to send it out.
One way is to create a cyclic buffer or set of buffers accessed from your application (fill data)
And on the TCP side periodically check if there is new data to send and send it from within the
LwIP own context.
A second way to do it, not so preferred by some peoples but worked for me, is to add critical
Sections in code that call’s LwIP functions. Adding a critical section means that you block other
Tasks for a short time. Especially the TCP task from running. It means that if you allocate a buffer from
the LwIP pool until you do not Call exit from the critical section the TCP task will not run and therefore
will not interfere.
If we stick to the “correct” way to do it use LwIP sys_timeout … for example if you need to send out
data every 50 ms you set the sys_timeout to call a function. Once the 50ms time has been passed LwIP
will call your function from within the TCP own context and do something.
Lets assume you fill a cyclic buffer from your application and the above call back checks this buffer for data.
If it has something it will send it out but it will work from within the TCP context.
Another BIG overlooked problem is the Cortex-M3 interrupt levels definitions. If you work with FreeRTOS
And probably other OS have the same problem or misunderstanding… The OS has its own timetick interval
Or OS priority. If your TCP priority is higher than the OS tick the OS will not be able to musk the TCP stack
Task when it enters its own critical sections. That also leads to unpredictable system behavior and may cause
hanging, lowness etc…
Sorry for the long text and for repeating myself.
I hope that will help you stabilize your code.
From: lwip-users [mailto:lwip-users-bounces+address@hidden
On Behalf Of garibaldi pineda garcia
I'm using the RAW API, I chose that for performance.
By sending random data I mean I allocate a buffer in the ARM core and continuously send that through Ethernet/UDP. I'm also trying to send the video through Ethernet/UDP, I'm basically sending the differences between consecutive frames.
Thanks for your time!
On 26 September 2016 at 16:09, Noam Weissman <address@hidden> wrote:
What API are you using?... RAW, Netconn or Socket ?
When you say you send random data, how do you send it. I mean do you send it from
Within the LwIP context or via the route you try to send the video?
I'm building a system which encodes video in a Zedboard FPGA and sends it out through the ethernet port. I have tested sending random data out and it works, but when I try to use the data from the video source I manage to set the ARM core/network in a locked state. I've also tested the system without sending any data through etherenet and it works fine.
I've increased memory and pool sizes; I also decreased the Time-To-Live for all protocols and tried using a global pbuf or a dynamic local pbuf.
These setting seem to get the system working a bit longer, but I still get locked whenever the video encoding requires to send more than random data.
Does anyone have suggestions on what I could do?
|[Prev in Thread]||Current Thread||[Next in Thread]|