[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] blocked udp

From: Noam Weissman
Subject: Re: [lwip-users] blocked udp
Date: Wed, 28 Sep 2016 16:57:26 +0000

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.

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 ...

Introduction The Xilinx Software Development Kit can automatically generate a board support package from a hardware definition file. The board support package ...

Have fun,


From: lwip-users <lwip-users-bounces+address@hidden> on behalf of garibaldi pineda garcia <address@hidden>
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.


On 28 September 2016 at 13:51, Noam Weissman <address@hidden> 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.







From: lwip-users [mailto:lwip-users-bounces+noam=address@hidden] 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.





On 28 September 2016 at 13:20, garibaldi pineda garcia <address@hidden> wrote:


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?





On 28 September 2016 at 12:44, Dirk Ziegelmeier <address@hidden> 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.

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).



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.




lwip-users mailing list



lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]