Re: [lwip-users] blocked udp

[Noam Weissman]

Hi Gary,


Linux is heavy for a small project and complicated. If you can find an example 
with FreeRTOS

this would be great.


It is not the best one but it is free and stable. One thing that I love with 
FreeRTOS that the interrupt

service routines are the same as with standalone software. VxWorks, eCos and 
other OS are

more complicated and interrupt service routines are connected to the OS and the 
scheduler.

http://zedboard.org/content/freertos-820-freertos-cli-lwip-140-bsp-xilinx-zynq
[http://zedboard.org/sites/default/files/styles/thumbnail/public/userpic.jpg?itok=4KlXgPXl]<http://zedboard.org/content/freertos-820-freertos-cli-lwip-140-bsp-xilinx-zynq>

FreeRTOS-8.2.0 + FreeRTOS-CLI + LWIP-1.4.0 bsp for Xilinx 
...<http://zedboard.org/content/freertos-820-freertos-cli-lwip-140-bsp-xilinx-zynq>
zedboard.org
Hi, all, I want to share my customized FreeRTOS-8.2.0 FreeRTOS-CLI LWIP-1.4.0 
bsp for microzed Zynq, currently tested under microzed 7010 using Vivado 
2014.4. It can ...




http://www.freertos.org/RTOS-Xilinx-SDK-BSP.html
FreeRTOS BSP for Xilinx Software Development Kit 
(SDK)<http://www.freertos.org/RTOS-Xilinx-SDK-BSP.html>
www.freertos.org
Introduction The Xilinx Software Development Kit can automatically generate a 
board support package from a hardware definition file. The board support 
package ...



Have fun,

Noam.




From: lwip-users <lwip-users-bounces+noam=silrd@nongnu.org> on behalf of 
garibaldi pineda garcia <chano...@gmail.com>
Sent: Wednesday, September 28, 2016 7:10 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] blocked udp

Hi Noam,

I was trying to avoid dealing with setting memory addresses for DMA transfers 
in Linux/RTOS, but running an OS might be the better option.




Best,
Gary

On 28 September 2016 at 13:51, Noam Weissman 
<n...@silrd.com<mailto:n...@silrd.com>> wrote:
Hi Gary,

As a continuation to what Simon wrote…

See section 6. This does not contradict what everyone said so far.

You can call sending data functions in your main loop and the difference is how 
to do it properly.
Dirk answered this earlier and explained how to do it with or without OS.

By the way why aren’t you using an OS and the Socket API. You have sufficient 
resources
and that would simplify things.

BR,
Noam.



From: lwip-users 
[mailto:lwip-users-bounces+noam<mailto:lwip-users-bounces%2Bnoam>=silrd@nongnu.org<mailto:silrd@nongnu.org>]
 On Behalf Of garibaldi pineda garcia
Sent: Wednesday, September 28, 2016 3:34 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] blocked udp

Xilinx application notes seem to contradict the don't-mix interrupt/polling 
domains:


Creating an lwIP Application Using the RAW API

The lwIP RAW mode API is more complicated as it requires knowledge of lwIP 
internals. The typical structure of a RAW mode program is as follows:

1. The first step is to initialize all lwIP structures using lwip_init.

2. After lwIP has been initialized, an Ethernet MAC can be added using the 
xemac_add helper function.

3. Because the Xilinx lwIP adapters are interrupt-based, enable interrupts in 
the processor and in the interrupt controller.

4. Set up a timer to interrupt at a constant interval. Usually, the interval is 
around 250 ms. In the timer interrupt, update necessary flags to invoke the 
lwIP TCP APIs tcp_fasttmr and tcp_slowtmr from the main application loop 
explained previously.

5. After the application is initialized, the main program enters an infinite 
loop performing packet receive operation, and any other application specific 
operation it needs to perform.

6. The packet receive operation (xemacif_input), processes packets received by 
the interrupt handler, and passes them onto lwIP, which then calls the 
appropriate callback handlers for each received packet.



Best,
Gary

On 28 September 2016 at 13:20, garibaldi pineda garcia 
<chano...@gmail.com<mailto:chano...@gmail.com>> wrote:
Hi,
Dirk you're right, I'm using LWIP with the NO_SYS flag set to true.

I'm somewhat confused, do I have two options?
1) Do a polling-like application that manages input/output without interrupts 
(I have no clue how to do this, should I follow the sample code?).
2) Send everything out when I get the ethernet input interrupt
I really don't need any of the data I get from the receiver side of ethernet 
(other than getting the MAC address), could I skip any checking of that input?



Best,
Gary

On 28 September 2016 at 12:44, Dirk Ziegelmeier 
<d...@ziegelmeier.net<mailto:d...@ziegelmeier.net>> wrote:
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 no

Re: [lwip-users] blocked udp

[garibaldi pineda garcia]

Hi Noam,

I was trying to avoid dealing with setting memory addresses for DMA
transfers in Linux/RTOS, but running an OS might be the better option.




Best,
Gary

On 28 September 2016 at 13:51, Noam Weissman <n...@silrd.com> wrote:

> Hi Gary,
>
>
>
> As a continuation to what Simon wrote…
>
>
>
> See section 6. This does not contradict what everyone said so far.
>
>
>
> You can call sending data functions in your main loop and the difference
> is how to do it properly.
>
> Dirk answered this earlier and explained how to do it with or without OS.
>
>
>
> By the way why aren’t you using an OS and the Socket API. You have
> sufficient resources
>
> and that would simplify things.
>
>
>
> BR,
>
> Noam.
>
>
>
>
>
>
>
> *From:* lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] *On
> Behalf Of *garibaldi pineda garcia
> *Sent:* Wednesday, September 28, 2016 3:34 PM
> *To:* Mailing list for lwIP users
> *Subject:* Re: [lwip-users] blocked udp
>
>
>
> Xilinx application notes seem to contradict the don't-mix
> interrupt/polling domains:
>
>
> Creating an lwIP Application Using the RAW API
>
> The lwIP RAW mode API is more complicated as it requires knowledge of lwIP
> internals. The typical structure of a RAW mode program is as follows:
>
> 1. The first step is to initialize all lwIP structures using lwip_init.
>
> 2. After lwIP has been initialized, an Ethernet MAC can be added using the
> xemac_add helper function.
>
> 3. Because the Xilinx lwIP adapters are interrupt-based, enable interrupts
> in the processor and in the interrupt controller.
>
> 4. Set up a timer to interrupt at a constant interval. Usually, the
> interval is around 250 ms. In the timer interrupt, update necessary flags
> to invoke the lwIP TCP APIs tcp_fasttmr and tcp_slowtmr from the main
> application loop explained previously.
>
> 5. After the application is initialized, the main program enters an
> infinite loop performing packet receive operation, and any other
> application specific operation it needs to perform.
>
> 6. The packet receive operation (xemacif_input), processes packets
> received by the interrupt handler, and passes them onto lwIP, which then
> calls the appropriate callback handlers for each received packet.
>
>
>
>
> Best,
>
> Gary
>
>
>
> On 28 September 2016 at 13:20, garibaldi pineda garcia <chano...@gmail.com>
> wrote:
>
> Hi,
>
> Dirk you're right, I'm using LWIP with the NO_SYS flag set to true.
>
> I'm somewhat confused, do I have two options?
>
> 1) Do a polling-like application that manages input/output without
> interrupts (I have no clue how to do this, should I follow the sample
> code?).
>
> 2) Send everything out when I get the ethernet input interrupt
>
> I really don't need any of the data I get from the receiver side of
> ethernet (other than getting the MAC address), could I skip any checking of
> that input?
>
>
>
>
> Best,
>
> Gary
>
>
>
> On 28 September 2016 at 12:44, Dirk Ziegelmeier <d...@ziegelmeier.net>
> wrote:
>
> 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.
>
>
>
> Depends on what you mean by "critical section". If this is disable/enable
> interrupts, that only works if you don't use an OS.
>
> NoSys:
> 1) Your ethernet MAC interrupt directly calls into lwIP to deliver RX
> packets in IRQ context​ (this implies all your lwIP callback functions are
> called in IRQ context). If you call into lwIP from your application code,
> then yes, all you need to to is disable interrupts. If timers are involved,
> even more locking code is needed to lock out timer IRQ and ethernet IRQ
> from each other (assuming these may be nested).
>
> 2) Use "mainloop" code: http://git.savannah.gnu.org/
> cgit/lwip.git/tree/doc/NO_SYS_SampleCode.c
>
>
>
> ​OS:
>
> ​1) Use lwIP core locking. Then you only need to aquire the lwIP core lock
> using LOCK_TCPIP_CORE() / UNLOCK_TCPIP_CORE()​
>
> ​​
>
> ​ before calling into lwIP.
>
> ​2) Use tcpip_callback() to get called back from TCPIP thread and do the
> sending work there.​
>
> ​In both OS cases, take care of ethernet RX, you need to use t

Re: [lwip-users] blocked udp

[Noam Weissman]

Hi Gary,

As a continuation to what Simon wrote…

See section 6. This does not contradict what everyone said so far.

You can call sending data functions in your main loop and the difference is how 
to do it properly.
Dirk answered this earlier and explained how to do it with or without OS.

By the way why aren’t you using an OS and the Socket API. You have sufficient 
resources
and that would simplify things.

BR,
Noam.



From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On 
Behalf Of garibaldi pineda garcia
Sent: Wednesday, September 28, 2016 3:34 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] blocked udp

Xilinx application notes seem to contradict the don't-mix interrupt/polling 
domains:

Creating an lwIP Application Using the RAW API

The lwIP RAW mode API is more complicated as it requires knowledge of lwIP 
internals. The typical structure of a RAW mode program is as follows:

1. The first step is to initialize all lwIP structures using lwip_init.

2. After lwIP has been initialized, an Ethernet MAC can be added using the 
xemac_add helper function.

3. Because the Xilinx lwIP adapters are interrupt-based, enable interrupts in 
the processor and in the interrupt controller.

4. Set up a timer to interrupt at a constant interval. Usually, the interval is 
around 250 ms. In the timer interrupt, update necessary flags to invoke the 
lwIP TCP APIs tcp_fasttmr and tcp_slowtmr from the main application loop 
explained previously.

5. After the application is initialized, the main program enters an infinite 
loop performing packet receive operation, and any other application specific 
operation it needs to perform.

6. The packet receive operation (xemacif_input), processes packets received by 
the interrupt handler, and passes them onto lwIP, which then calls the 
appropriate callback handlers for each received packet.



Best,
Gary

On 28 September 2016 at 13:20, garibaldi pineda garcia 
<chano...@gmail.com<mailto:chano...@gmail.com>> wrote:
Hi,
Dirk you're right, I'm using LWIP with the NO_SYS flag set to true.

I'm somewhat confused, do I have two options?
1) Do a polling-like application that manages input/output without interrupts 
(I have no clue how to do this, should I follow the sample code?).
2) Send everything out when I get the ethernet input interrupt
I really don't need any of the data I get from the receiver side of ethernet 
(other than getting the MAC address), could I skip any checking of that input?



Best,
Gary

On 28 September 2016 at 12:44, Dirk Ziegelmeier 
<d...@ziegelmeier.net<mailto:d...@ziegelmeier.net>> wrote:
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.

Depends on what you mean by "critical section". If this is disable/enable 
interrupts, that only works if you don't use an OS.

NoSys:
1) Your ethernet MAC interrupt directly calls into lwIP to deliver RX packets 
in IRQ context​ (this implies all your lwIP callback functions are called in 
IRQ context). If you call into lwIP from your application code, then yes, all 
you need to to is disable interrupts. If timers are involved, even more locking 
code is needed to lock out timer IRQ and ethernet IRQ from each other (assuming 
these may be nested).
2) Use "mainloop" code: 
http://git.savannah.gnu.org/cgit/lwip.git/tree/doc/NO_SYS_SampleCode.c

​OS:
​1) Use lwIP core locking. Then you only need to aquire the lwIP core lock 
using LOCK_TCPIP_CORE() / UNLOCK_TCPIP_CORE()​
​​
​ before calling into lwIP.
​2) Use tcpip_callback() to get called back from TCPIP thread and do the 
sending work there.​
​In both OS cases, take care of ethernet RX, you need to use tcpip_input() as 
input function in netif_add() to make RX thread-safe.​​

​Dirk

___
lwip-users mailing list
lwip-users@nongnu.org<mailto:lwip-users@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[garibaldi pineda garcia]

Oooh, I see. Then I believe I have to revisit my code because I based my
design on their app note.




Best,
Gary

On 28 September 2016 at 13:41, goldsimon  wrote:

> On the contrary: Xilinx does it perfectly right. They use their hardware
> at interrupt level but feed rx packets into lwip in the main loop.
>
> Simon
>
> Gesendet mit AquaMail für Android
> http://www.aqua-mail.com
>
> Am 28. September 2016 2:35:54 nachm. schrieb garibaldi pineda garcia <
> chano...@gmail.com>:
>
>> Xilinx application notes seem to contradict the don't-mix
>> interrupt/polling domains:
>>
>> Creating an lwIP Application Using the RAW API
>>
>> The lwIP RAW mode API is more complicated as it requires knowledge of
>> lwIP internals. The typical structure of a RAW mode program is as follows:
>>
>> 1. The first step is to initialize all lwIP structures using lwip_init.
>>
>> 2. After lwIP has been initialized, an Ethernet MAC can be added using
>> the xemac_add helper function.
>>
>> 3. Because the Xilinx lwIP adapters are interrupt-based, enable
>> interrupts in the processor and in the interrupt controller.
>>
>> 4. Set up a timer to interrupt at a constant interval. Usually, the
>> interval is around 250 ms. In the timer interrupt, update necessary flags
>> to invoke the lwIP TCP APIs tcp_fasttmr and tcp_slowtmr from the main
>> application loop explained previously.
>>
>> 5. After the application is initialized, the main program enters an
>> infinite loop performing packet receive operation, and any other
>> application specific operation it needs to perform.
>>
>> 6. The packet receive operation (xemacif_input), processes packets
>> received by the interrupt handler, and passes them onto lwIP, which then
>> calls the appropriate callback handlers for each received packet.
>>
>>
>>
>>
>> Best,
>> Gary
>>
>> On 28 September 2016 at 13:20, garibaldi pineda garcia <
>> chano...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Dirk you're right, I'm using LWIP with the NO_SYS flag set to true.
>>>
>>> I'm somewhat confused, do I have two options?
>>>
>>> 1) Do a polling-like application that manages input/output without
>>> interrupts (I have no clue how to do this, should I follow the sample
>>> code?).
>>>
>>> 2) Send everything out when I get the ethernet input interrupt
>>>
>>> I really don't need any of the data I get from the receiver side of
>>> ethernet (other than getting the MAC address), could I skip any checking of
>>> that input?
>>>
>>>
>>>
>>>
>>> Best,
>>> Gary
>>>
>>> On 28 September 2016 at 12:44, Dirk Ziegelmeier 
>>> wrote:
>>>
 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.
>
>
> Depends on what you mean by "critical section". If this is
 disable/enable interrupts, that only works if you don't use an OS.

 NoSys:
 1) Your ethernet MAC interrupt directly calls into lwIP to deliver RX
 packets in IRQ context​ (this implies all your lwIP callback functions are
 called in IRQ context). If you call into lwIP from your application code,
 then yes, all you need to to is disable interrupts. If timers are involved,
 even more locking code is needed to lock out timer IRQ and ethernet IRQ
 from each other (assuming these may be nested).
 2) Use "mainloop" code: http://git.savannah.gnu.org/cg
 it/lwip.git/tree/doc/NO_SYS_SampleCode.c

 ​OS:
 ​1) Use lwIP core locking. Then you only need to aquire the lwIP core
 lock using LOCK_TCPIP_CORE() / UNLOCK_TCPIP_CORE()​
 ​​
 ​ before calling into lwIP.
 ​2) Use tcpip_callback() to get called back from TCPIP thread and do
 the sending work there.​
 ​In both OS cases, take care of ethernet RX, you need to use
 tcpip_input() as input function in netif_add() to make RX thread-safe.​​

 ​Dirk

 ___
 lwip-users mailing list
 lwip-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/lwip-users

>>>
>>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[goldsimon]

On the contrary: Xilinx does it perfectly right. They use their hardware at 
interrupt level but feed rx packets into lwip in the main loop.


Simon


Gesendet mit AquaMail für Android
http://www.aqua-mail.com


Am 28. September 2016 2:35:54 nachm. schrieb garibaldi pineda garcia 
:



Xilinx application notes seem to contradict the don't-mix interrupt/polling
domains:

Creating an lwIP Application Using the RAW API

The lwIP RAW mode API is more complicated as it requires knowledge of lwIP
internals. The typical structure of a RAW mode program is as follows:

1. The first step is to initialize all lwIP structures using lwip_init.

2. After lwIP has been initialized, an Ethernet MAC can be added using the
xemac_add helper function.

3. Because the Xilinx lwIP adapters are interrupt-based, enable interrupts
in the processor and in the interrupt controller.

4. Set up a timer to interrupt at a constant interval. Usually, the
interval is around 250 ms. In the timer interrupt, update necessary flags
to invoke the lwIP TCP APIs tcp_fasttmr and tcp_slowtmr from the main
application loop explained previously.

5. After the application is initialized, the main program enters an
infinite loop performing packet receive operation, and any other
application specific operation it needs to perform.

6. The packet receive operation (xemacif_input), processes packets received
by the interrupt handler, and passes them onto lwIP, which then calls the
appropriate callback handlers for each received packet.




Best,
Gary

On 28 September 2016 at 13:20, garibaldi pineda garcia 
wrote:


Hi,

Dirk you're right, I'm using LWIP with the NO_SYS flag set to true.

I'm somewhat confused, do I have two options?

1) Do a polling-like application that manages input/output without
interrupts (I have no clue how to do this, should I follow the sample
code?).

2) Send everything out when I get the ethernet input interrupt

I really don't need any of the data I get from the receiver side of
ethernet (other than getting the MAC address), could I skip any checking of
that input?




Best,
Gary

On 28 September 2016 at 12:44, Dirk Ziegelmeier 
wrote:


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.


Depends on what you mean by "critical section". If this is

disable/enable interrupts, that only works if you don't use an OS.

NoSys:
1) Your ethernet MAC interrupt directly calls into lwIP to deliver RX
packets in IRQ context​ (this implies all your lwIP callback functions are
called in IRQ context). If you call into lwIP from your application code,
then yes, all you need to to is disable interrupts. If timers are involved,
even more locking code is needed to lock out timer IRQ and ethernet IRQ
from each other (assuming these may be nested).
2) Use "mainloop" code: http://git.savannah.gnu.org/cg
it/lwip.git/tree/doc/NO_SYS_SampleCode.c

​OS:
​1) Use lwIP core locking. Then you only need to aquire the lwIP core
lock using LOCK_TCPIP_CORE() / UNLOCK_TCPIP_CORE()​
​​
​ before calling into lwIP.
​2) Use tcpip_callback() to get called back from TCPIP thread and do the
sending work there.​
​In both OS cases, take care of ethernet RX, you need to use
tcpip_input() as input function in netif_add() to make RX thread-safe.​​

​Dirk

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users








--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[garibaldi pineda garcia]

Xilinx application notes seem to contradict the don't-mix interrupt/polling
domains:

Creating an lwIP Application Using the RAW API

The lwIP RAW mode API is more complicated as it requires knowledge of lwIP
internals. The typical structure of a RAW mode program is as follows:

1. The first step is to initialize all lwIP structures using lwip_init.

2. After lwIP has been initialized, an Ethernet MAC can be added using the
xemac_add helper function.

3. Because the Xilinx lwIP adapters are interrupt-based, enable interrupts
in the processor and in the interrupt controller.

4. Set up a timer to interrupt at a constant interval. Usually, the
interval is around 250 ms. In the timer interrupt, update necessary flags
to invoke the lwIP TCP APIs tcp_fasttmr and tcp_slowtmr from the main
application loop explained previously.

5. After the application is initialized, the main program enters an
infinite loop performing packet receive operation, and any other
application specific operation it needs to perform.

6. The packet receive operation (xemacif_input), processes packets received
by the interrupt handler, and passes them onto lwIP, which then calls the
appropriate callback handlers for each received packet.




Best,
Gary

On 28 September 2016 at 13:20, garibaldi pineda garcia 
wrote:

> Hi,
>
> Dirk you're right, I'm using LWIP with the NO_SYS flag set to true.
>
> I'm somewhat confused, do I have two options?
>
> 1) Do a polling-like application that manages input/output without
> interrupts (I have no clue how to do this, should I follow the sample
> code?).
>
> 2) Send everything out when I get the ethernet input interrupt
>
> I really don't need any of the data I get from the receiver side of
> ethernet (other than getting the MAC address), could I skip any checking of
> that input?
>
>
>
>
> Best,
> Gary
>
> On 28 September 2016 at 12:44, Dirk Ziegelmeier 
> wrote:
>
>> 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.
>>>
>>>
>>> Depends on what you mean by "critical section". If this is
>> disable/enable interrupts, that only works if you don't use an OS.
>>
>> NoSys:
>> 1) Your ethernet MAC interrupt directly calls into lwIP to deliver RX
>> packets in IRQ context​ (this implies all your lwIP callback functions are
>> called in IRQ context). If you call into lwIP from your application code,
>> then yes, all you need to to is disable interrupts. If timers are involved,
>> even more locking code is needed to lock out timer IRQ and ethernet IRQ
>> from each other (assuming these may be nested).
>> 2) Use "mainloop" code: http://git.savannah.gnu.org/cg
>> it/lwip.git/tree/doc/NO_SYS_SampleCode.c
>>
>> ​OS:
>> ​1) Use lwIP core locking. Then you only need to aquire the lwIP core
>> lock using LOCK_TCPIP_CORE() / UNLOCK_TCPIP_CORE()​
>> ​​
>> ​ before calling into lwIP.
>> ​2) Use tcpip_callback() to get called back from TCPIP thread and do the
>> sending work there.​
>> ​In both OS cases, take care of ethernet RX, you need to use
>> tcpip_input() as input function in netif_add() to make RX thread-safe.​​
>>
>> ​Dirk
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[Simon Goldschmidt]

Dirk Ziegelmeier wrote:
>> A second way to do it, not so preferred by some peoples but worked for me,
>> is to add critical Sections [..] 
> 
> Depends on what you mean by "critical section". If this is disable/enable
> interrupts, that only works if you don't use an OS.

Just to clarify this for other readers: when doing this with an OS, it could
be that you block the tcpip_thread in the middle of processing something
(depending on your thread priorities), which again gives you 2 execution
contexts running the lwIP code at the same time.


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[garibaldi pineda garcia]

Hi,

Dirk you're right, I'm using LWIP with the NO_SYS flag set to true.

I'm somewhat confused, do I have two options?

1) Do a polling-like application that manages input/output without
interrupts (I have no clue how to do this, should I follow the sample
code?).

2) Send everything out when I get the ethernet input interrupt

I really don't need any of the data I get from the receiver side of
ethernet (other than getting the MAC address), could I skip any checking of
that input?




Best,
Gary

On 28 September 2016 at 12:44, Dirk Ziegelmeier 
wrote:

> 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.
>>
>>
>> Depends on what you mean by "critical section". If this is disable/enable
> interrupts, that only works if you don't use an OS.
>
> NoSys:
> 1) Your ethernet MAC interrupt directly calls into lwIP to deliver RX
> packets in IRQ context​ (this implies all your lwIP callback functions are
> called in IRQ context). If you call into lwIP from your application code,
> then yes, all you need to to is disable interrupts. If timers are involved,
> even more locking code is needed to lock out timer IRQ and ethernet IRQ
> from each other (assuming these may be nested).
> 2) Use "mainloop" code: http://git.savannah.gnu.org/
> cgit/lwip.git/tree/doc/NO_SYS_SampleCode.c
>
> ​OS:
> ​1) Use lwIP core locking. Then you only need to aquire the lwIP core lock
> using LOCK_TCPIP_CORE() / UNLOCK_TCPIP_CORE()​
> ​​
> ​ before calling into lwIP.
> ​2) Use tcpip_callback() to get called back from TCPIP thread and do the
> sending work there.​
> ​In both OS cases, take care of ethernet RX, you need to use tcpip_input()
> as input function in netif_add() to make RX thread-safe.​​
>
> ​Dirk
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[Dirk Ziegelmeier]

>
> 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.
>
>
> Depends on what you mean by "critical section". If this is disable/enable
interrupts, that only works if you don't use an OS.

NoSys:
1) Your ethernet MAC interrupt directly calls into lwIP to deliver RX
packets in IRQ context​ (this implies all your lwIP callback functions are
called in IRQ context). If you call into lwIP from your application code,
then yes, all you need to to is disable interrupts. If timers are involved,
even more locking code is needed to lock out timer IRQ and ethernet IRQ
from each other (assuming these may be nested).
2) Use "mainloop" code:
http://git.savannah.gnu.org/cgit/lwip.git/tree/doc/NO_SYS_SampleCode.c

​OS:
​1) Use lwIP core locking. Then you only need to aquire the lwIP core lock
using LOCK_TCPIP_CORE() / UNLOCK_TCPIP_CORE()​
​​
​ before calling into lwIP.
​2) Use tcpip_callback() to get called back from TCPIP thread and do the
sending work there.​
​In both OS cases, take care of ethernet RX, you need to use tcpip_input()
as input function in netif_add() to make RX thread-safe.​​

​Dirk
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[Noam Weissman]

Hi Dirk,

I forgot about this completely… I checked my own code and found that I already 
used it before ☺

Thanks for reminding  this.

BR,
Noam.

From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On 
Behalf Of Dirk Ziegelmeier
Sent: Wednesday, September 28, 2016 1:59 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] blocked udp

Whenever your application wants to send, use tcpip_callback() macro to get a 
function called in tcpip thread and do the sending work there.


Ciao
Dirk

--
Dirk Ziegelmeier * d...@ziegelmeier.net<mailto:d...@ziegelmeier.net> * 
http://www.ziegelmeier.net

On Wed, Sep 28, 2016 at 12:52 PM, Noam Weissman 
<n...@silrd.com<mailto:n...@silrd.com>> wrote:
Hi Simon,

What is the preferred way to send data from within LwIP context.

Beside running sys_timeout and hooking a function to it ?

If I want to send data at a high rate and I will set sys_timeout to say 1ms it 
will cause load
on the system. Is there another clean way to do it ?


BR,
Noam.


-Original Message-
From: lwip-users 
[mailto:lwip-users-bounces+noam<mailto:lwip-users-bounces%2Bnoam>=silrd@nongnu.org<mailto:silrd@nongnu.org>]
 On Behalf Of Simon Goldschmidt
Sent: Wednesday, September 28, 2016 1:33 PM
To: lwip-users@nongnu.org<mailto:lwip-users@nongnu.org>
Subject: Re: [lwip-users] blocked udp

garibaldi pineda garcia wrote:
> What I do is have an interrupt to receive the data from the FPGA and,
>in the main program loop (would this be the LWIP context?),

I guess so. That would mean you don't use an OS but use lwIP in NO_SYS=1 mode.

> I call a function to send data out. I also have an interrupt for the
> receive function for the LWIP data.

That would mean you call the lwIP TX functions from main loop while calling the 
RX functions from ETH RX interrupt. That's not supported and this most probably 
is your problem.


Simon

___
lwip-users mailing list
lwip-users@nongnu.org<mailto:lwip-users@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org<mailto:lwip-users@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[Dirk Ziegelmeier]

Whenever your application wants to send, use tcpip_callback() macro to get
a function called in tcpip thread and do the sending work there.


Ciao
Dirk

--
Dirk Ziegelmeier * d...@ziegelmeier.net * http://www.ziegelmeier.net

On Wed, Sep 28, 2016 at 12:52 PM, Noam Weissman <n...@silrd.com> wrote:

> Hi Simon,
>
> What is the preferred way to send data from within LwIP context.
>
> Beside running sys_timeout and hooking a function to it ?
>
> If I want to send data at a high rate and I will set sys_timeout to say
> 1ms it will cause load
> on the system. Is there another clean way to do it ?
>
>
> BR,
> Noam.
>
>
> -Original Message-
> From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On
> Behalf Of Simon Goldschmidt
> Sent: Wednesday, September 28, 2016 1:33 PM
> To: lwip-users@nongnu.org
> Subject: Re: [lwip-users] blocked udp
>
> garibaldi pineda garcia wrote:
> > What I do is have an interrupt to receive the data from the FPGA and,
> >in the main program loop (would this be the LWIP context?),
>
> I guess so. That would mean you don't use an OS but use lwIP in NO_SYS=1
> mode.
>
> > I call a function to send data out. I also have an interrupt for the
> > receive function for the LWIP data.
>
> That would mean you call the lwIP TX functions from main loop while
> calling the RX functions from ETH RX interrupt. That's not supported and
> this most probably is your problem.
>
>
> Simon
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[Noam Weissman]

Hi Simon,

What is the preferred way to send data from within LwIP context.

Beside running sys_timeout and hooking a function to it ?

If I want to send data at a high rate and I will set sys_timeout to say 1ms it 
will cause load
on the system. Is there another clean way to do it ?


BR,
Noam.


-Original Message-
From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On 
Behalf Of Simon Goldschmidt
Sent: Wednesday, September 28, 2016 1:33 PM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] blocked udp

garibaldi pineda garcia wrote:
> What I do is have an interrupt to receive the data from the FPGA and,  
>in the main program loop (would this be the LWIP context?),

I guess so. That would mean you don't use an OS but use lwIP in NO_SYS=1 mode.

> I call a function to send data out. I also have an interrupt for the 
> receive function for the LWIP data.

That would mean you call the lwIP TX functions from main loop while calling the 
RX functions from ETH RX interrupt. That's not supported and this most probably 
is your problem.


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[Noam Weissman]

Simon :-)

You answered In much less words then I did.

Noam.

-Original Message-
From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On 
Behalf Of Simon Goldschmidt
Sent: Wednesday, September 28, 2016 1:33 PM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] blocked udp

garibaldi pineda garcia wrote:
> What I do is have an interrupt to receive the data from the FPGA and,  
>in the main program loop (would this be the LWIP context?),

I guess so. That would mean you don't use an OS but use lwIP in NO_SYS=1 mode.

> I call a function to send data out. I also have an interrupt for the 
> receive function for the LWIP data.

That would mean you call the lwIP TX functions from main loop while calling the 
RX functions from ETH RX interrupt. That's not supported and this most probably 
is your problem.


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[Simon Goldschmidt]

garibaldi pineda garcia wrote:
> What I do is have an interrupt to receive the data from the FPGA and,
> in the main program loop (would this be the LWIP context?),

I guess so. That would mean you don't use an OS but use lwIP in NO_SYS=1 mode.

> I call a function to send data out. I also have an interrupt for the receive
> function for the LWIP data.

That would mean you call the lwIP TX functions from main loop while calling the
RX functions from ETH RX interrupt. That's not supported and this most probably
is your problem.


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[Noam Weissman]

Hi,

No problems, I enjoy it.

I head lots of help from people here when I started so it’s just reasonable 
that I will help
others when I can ☺

As far as I understand and also from my own experience there is no memory leak. 
You
simply do not use LwIP properly.

In RAW mode when you call tcpip_init function and I it will call (inside) 
sys_thread_new.
This is where (as I understand) the LwIP own task is created.

When you try to send data from your own main it is not from within the LwIP 
context
and that is what is causing you to get into memory leaks.

By the way you did not answer if you use an OS or not 

If you use an OS the problem is that TCP stack task should be one of the 
highest priority tasks.
That means that you send data from your main task but you have no control when 
the OS does its
context switch and let LwIP run before it returns the context to your own task.

As a result you get into synchronization issues with LwIP and that causes the 
memory leaks.

It is like accessing a shared buffer or data base without protecting that with 
semaphores etc…

I hope this is understood now.

Is this the board you are using ?
   
http://store.digilentinc.com/zedboard-zynq-7000-arm-fpga-soc-development-board/

If this is the board why do you use LwIP and more than that why use RAW mode ??

You use LwIP RAW mode when you do not need or cannot use an OS in systems 
limited
with resources. If this is the board you use it has 512Mb RAM This is almost 
unlimited RAM
compared to what I am referring to. I am running LwIP on systems that have 
96-192 Kbyte
Ram !!


BR,
Noam.

From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On 
Behalf Of garibaldi pineda garcia
Sent: Wednesday, September 28, 2016 12:46 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] blocked udp

Hi Noam,
 I really appreciate your help and thank you for the time you've taken to reply.

I believe my problem might be related to memory leaks, although I'm using a 
bare-metal application. The Zedboard has a dual Corex-A9 processor. So I 
process the video on the FPGA then transfer that via DMA to an ARM core; once 
the data is in a buffer in the ARM core I send things through the ethernet 
(Marvell 88E1518 PHY) using UDP.
What I do is have an interrupt to receive the data from the FPGA and, in the 
main program loop (would this be the LWIP context?), I call a function to send 
data out. I also have an interrupt for the receive function for the LWIP data.

Cheers!


Best,
Gary

On 27 September 2016 at 12:35, Noam Weissman 
<n...@silrd.com<mailto:n...@silrd.com>> wrote:
Hi Gary,

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

Re: [lwip-users] blocked udp

[garibaldi pineda garcia]

Hi Noam,

 I really appreciate your help and thank you for the time you've taken to
reply.

I believe my problem might be related to memory leaks, although I'm using a
bare-metal application. The Zedboard has a dual Corex-A9 processor. So I
process the video on the FPGA then transfer that via DMA to an ARM core;
once the data is in a buffer in the ARM core I send things through the
ethernet (Marvell 88E1518 PHY) using UDP.

What I do is have an interrupt to receive the data from the FPGA and, in
the main program loop (would this be the LWIP context?), I call a function
to send data out. I also have an interrupt for the receive function for the
LWIP data.


Cheers!



Best,
Gary

On 27 September 2016 at 12:35, Noam Weissman <n...@silrd.com> wrote:

> Hi Gary,
>
>
>
> 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.
>
>
>
>
>
>
>
> BR,
>
> Noam.
>
>
>
>
>
> *From:* lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] *On
> Behalf Of *garibaldi pineda garcia
> *Sent:* Tuesday, September 27, 2016 12:31 PM
> *To:* Mailing list for lwIP users
> *Subject:* Re: [lwip-users] blocked udp
>
>
>
> Hi Noam,
>
> 

Re: [lwip-users] blocked udp

[Noam Weissman]

Hi Gary,

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.



BR,
Noam.


From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On 
Behalf Of garibaldi pineda garcia
Sent: Tuesday, September 27, 2016 12:31 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] blocked udp

Hi Noam,
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!
Best,
Gary


Best,
Gary

On 26 September 2016 at 16:09, Noam Weissman 
<n...@silrd.com<mailto:n...@silrd.com>> wrote:
Hi,

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?

BR,
Noam.

From: lwip-users 
[mailto:lwip-users-bounces+noam<mailto:lwip-users-bounces%2Bnoam>=silrd@nongnu.org<mailto:silrd@nongnu.org>]
 On Behalf Of garibaldi pineda garcia
Sent: Monday, September 26, 2016 4:27 PM
To: lwip-users@nongnu.org<mailto:lwip-users@nongnu.org>
Subject: [lwip-users] blocked udp

Hello all,
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, bu

Re: [lwip-users] blocked udp

[garibaldi pineda garcia]

Hi Noam,

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!

Best,
Gary


Best,
Gary

On 26 September 2016 at 16:09, Noam Weissman <n...@silrd.com> wrote:

> Hi,
>
>
>
> 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?
>
>
>
> BR,
>
> Noam.
>
>
>
> *From:* lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] *On
> Behalf Of *garibaldi pineda garcia
> *Sent:* Monday, September 26, 2016 4:27 PM
> *To:* lwip-users@nongnu.org
> *Subject:* [lwip-users] blocked udp
>
>
>
> Hello all,
>
> 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?
>
>
>
> Best,
>
> Gary
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] blocked udp

[Noam Weissman]

Hi,

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?

BR,
Noam.

From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On 
Behalf Of garibaldi pineda garcia
Sent: Monday, September 26, 2016 4:27 PM
To: lwip-users@nongnu.org
Subject: [lwip-users] blocked udp

Hello all,
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?

Best,
Gary
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] blocked udp

[garibaldi pineda garcia]

Hello all,

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?

Best,
Gary
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users