Hi All, To close the loop on my original question maybe it can help another rookie like me.
My goal was to set my ethernet device so that it will act as a cable, received packets from the netif, modulates them, send them over a cable, have another device demod, the exact same packet, and last transmit the packet out over its netif. My initialization changed from: // netif->flags = NETIF_FLAG_BROADCAST | NETIF_FLAG_ETHARP | NETIF_FLAG_IGMP; netif->flags = 0; Now I'm able to receive all incoming packets but not answer or react to any of them. For example, if I ping the target I see the packet but lwip does not ack and replies back. Thanks all for the help and suggestions. Jaime On Sat, Jul 9, 2016 at 3:30 PM, Jeff Barlow <j...@wb6csv.net> wrote: > On 07/09/2016 12:10 PM, goldsi...@gmx.de wrote: > >> Jeff Barlow wrote: >> >>> I think you will find that ChibiOS does much the same. The reasoning >>> as I understand it is to keep ISR code paths as short as possible to >>> minimize latency in hard real time systems. >>> >> >> Without knowing ChibiOS in detail, I'd be interested in knowing what >> would be the actual penalty of removing the need for the API user to >> supply the "bool inIsr"... >> > > I don't claim to be an expert on ChibiOS in particular. It seems fairly > obvious to me though that inserting extra code in the ISR path that inspect > some globals only to figure out that it is indeed in an ISR will have an > adverse effect on latency. ChibiOS is very tightly tuned to minimize > latency. For some of us this makes the difference between a working system > and one that almost works. > > -- > Later, > Jeff > > > _______________________________________________ > 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
