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 <[email protected]> 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:[email protected]] *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 <[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/ > 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 > [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
