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

Reply via email to