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
<[email protected]>:
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 <[email protected]>
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 <[email protected]>
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
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
----------
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
