Hello Sergio and all,
I could not see how to use pbuf_cat for UDP purposes (aside from not
being able to store the ip somewhere), since it adjusts the len and
tot_len's and I would lose track of the packet boundaries (if I'm
mistaken here, please yell). I use it to great success for the TCP
()? This uses the next pointer of the last
pbuf in a chain.
Simon
On 15.02.2018 18:55, Michael Steinberg wrote:
Hey,
right, it was silly to even ask really ;)
Would I cause considerable harm to the RAM-pool if I allocated the
necessary storage for queueing (basically a linked list node) from
signed to actually handle this case
without my intervention (f.e. "snipping" at packet borders) before
calling API functions?
Kind regards
Michael
Am 15.02.2018 um 21:52 schrieb goldsi...@gmx.de:
Why don't you use pbuf_cat()? This uses the next pointer of the last
pbuf in a chain.
Hey,
right, it was silly to even ask really ;)
Would I cause considerable harm to the RAM-pool if I allocated the
necessary storage for queueing (basically a linked list node) from it
with a RAW allocation? The packet and node pbufs would be deallocated
together again later-on. The
Hello,
My proposal: Chain up the handed pbufs in the recv callback
("push_back", instead of handling) to a private chain of pending
data, and call tcp_recved with the amount of bytes you consume from this
received-chain at your own discretion at some other point in time (and
be sure to free
API calls which would be easy to replace...
Cheers,
Simon
Am 29. Jan. 2017, um 12:34, Michael Steinberg <michste...@gmail.com
<mailto:michste...@gmail.com>> schrieb:
Hi guys,
for my private work with lwip I ended up using NO_SYS=1 and rolling my
own thread and ap
Hi guys,
for my private work with lwip I ended up using NO_SYS=1 and rolling my
own thread and api based upon the low level interfaces. But now I'm in a
situation where I have to use the tcpip thread and am left with either
the socket api or the netconn api. In my personal opinion, the bsd
Am 03.12.2016 um 17:37 schrieb Surya Chaitanya:
Hi,
The scenario is something like this. I have created an array of say, 5 UDP
PCB's.
I'd like to bind all these 5 UDP PCB's to the same local IP address and port
number
combination. Isn't this posible? Like you said, if we cannot bind an
Hey,
the problem being discussed here is happening on an Atmel device
(ATSAME70). Is the bug on the STM32F767 device already in the errata
sheet? I'm currently using a 745 device, so I'm hopefully good. Apart
from the cache issues I ran into nothing special. I had a look at the
sheet don't
thanks,
Mike (a different one!).
On 25/11/2016 16:35, Michael Steinberg wrote:
Hi,
You were reporting the same software works on m4 but fails to work
reliably on m7. The most prominent difference that can cause issues
between m4 and m7 is that the latter has data caches, where the
former has
Hi,
You were reporting the same software works on m4 but fails to work
reliably on m7. The most prominent difference that can cause issues
between m4 and m7 is that the latter has data caches, where the former
has none. Possible situation: The dma writes a frame to cached memory,
the mcu
Hello,
are you paying attention to the fact that Cortex-M7 such as the SAM E70
devices usually sport data caches which don't get invalidated
automatically when the mac-dma units transfer data to memory?
Michael
Am 24.11.2016 um 14:11 schrieb Noam Weissman:
So it’s a low level issue,
Hello,
rather than discussing whose fault this is, might I suggest to improve
how this kind of error might be implemented? Like having a ERR_TEMPORARY
or ERR_CONTENTION flag in the error codes which tells a higher level
that the reported error condition will eventually seize existance
Hey,
is using their netif driver plus a vanilla lwip (ie. savannah git
master) no option? I don't think the netif-interface changed much. I had
no real troubles from 1.41 to head.
I'd rather ask them to contribute their changes in a generic way, after
all they're profitting from a free stack as
On Aug 10, 2015, at 05:08 PM, Michael Steinberg m...@tu-clausthal.de
wrote:
Hello,
you make it sound like this was a limitation of lwip... but if at all,
it would only be one of the berkeley socket API emulation layer...
That being said, the socket API uses the netconn API, which in turn
one thread blocking on send/recv and another
thread issuing a close.
The new option LWIP_NETCONN_SEM_PER_THREAD enables each thread
operating on the netconn to have its own semaphore
Joel
On Aug 11, 2015, at 09:54 AM, Michael Steinberg m...@tu-clausthal.de
wrote:
Hi Joel,
well I had
Hello,
you make it sound like this was a limitation of lwip... but if at all,
it would only be one of the berkeley socket API emulation layer...
That being said, the socket API uses the netconn API, which in turn uses
mailboxes for receiving packets from the lwip core/driver. I cannot see
any
Hello again,
[...]
- RAM: TX buffer, in one piece, struct pbuf and its payload are
contiguous memory (although the in one piece might be removed in
future versions)
- POOL: RX buffer, can be chained (e.g. scater-gather-RX), struct pbuf
and its payload are contiguous memory
- REF: can be
Hello Simon,
I could not find a mechanism where lwip notifies me that a lwip-pbuf
is available again
LWIP_HOOK_MEMP_AVAILABLE(memp_t_type)
I'm using lwip version 1.41 stable here, searched for this macro but
could not find anything. Is this included in an upcoming release? I
found a
), because I needed to be
able to directly send my own pbufs without copying, since the meta data
needs to reach the driver.)
I will see that I get up to date with current git master, thank you for
the pointer!
Kind Regards,
Michael
Am 05.08.2015 um 22:27 schrieb goldsi...@gmx.de:
Michael
space is there already and
timestamped event messages are so small that it's basically free in all
thinkable circumstances!
Kind Regards,
Michael
Am 05.08.2015 um 23:12 schrieb goldsi...@gmx.de:
Michael Steinberg wrote:
One of the services which are running
here is a Precision-Time-Protocol
be great if you could hook up for such events in the pbuf api.
(I'm only argumenting upon my own intermediate conclusions here, maybe
these are wrong alltogether...)
Kind Regards,
Michael
Am 04.08.2015 um 18:21 schrieb Michael Steinberg:
Hello,
during my implementation of a zero copy port
using a super loop to emulate
threads for each service because we don't use an rtos in the
bootloader.
Bob
On Aug 4, 2015 17:24, Michael Steinberg m...@tu-clausthal.de
mailto:m...@tu-clausthal.de wrote:
Hello,
during my implementation of a STM32F4 port I'm running across
Hello,
during my implementation of a zero copy port to stm32f4 I ran into some
difficulties. As in presumably all implementations, a dma chain/ring is
used to exchance data with the MAC core. I do fill the related dma
descriptors with lwip pbufs (well, custom buffers, read below). However
a
Hello,
during my implementation of a STM32F4 port I'm running across the
situation where I want to roll my own ip-thread, because I have more
base protocols (ptp for instance, more to come) rolling in that service
(want to use raw api) and I'm crossing thread boundaries very often. Now
the NO_SYS
Hello,
I am deeply sorry for the resends, I initially registered with the wrong
email still these messages went through.
Kind Regards,
Michael
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Hello,
during my implementation of a STM32F4 port I'm running across the
situation where I want to roll my own ip-thread, because I have more
base protocols (ptp for instance, more to come) rolling in that service
(want to use raw api) and I'm crossing thread boundaries very often. Now
the
27 matches
Mail list logo
