Re: [lwip-users] pbuf handling / possible bug?

[Michael Steinberg]

Hi Simon,

there's ptpd for starters, but it is heavily influenced by the aparent
unix way to handle things and really carries much unnecessary weight for
microcontroller usage (also really I find the overall design a bit
lacky, but that is open for taste, there is no real hardware-driver api
there just yet and the one that is up to come is really more complicated
to support than to write an own slave client...). That being said, I
have talked to people who adapted ptpd for microcontroller usage, even
using lwip for this. I can look this up for you if you're interested
(oh, also ptpd use floating point ops for the clock discipline
controller, which might not be a problem stm32f4, but for others, even
though the project site mentions it would not).
I did not follow this route and started my own implementation, which
works in conjunction with ptpd running a master clock on a raspberry,
but is far away from being in alpha stage. Also it's C++, which might
not be the general taste of the mcu community. If you want to take a
peek, it's online visible on github
(https://github.com/decimad/microptp) without any license stuff yet, but
nobody except me would use it anyways in current state. Feel free to
take a look!

To your thoughts:
I think it would not be worth making such compromises on the pbuf side
for a single protocol that is not used very often. A flag and additional
payload in a hidden buffer spot behind the usual one would serve the
same needs at next to costs, the buffer 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 address@hidden:
> Michael Steinberg wrote:
>> One of the "services" which are running
>> here is a Precision-Time-Protocol slave clock. This protocol relies on
>> hardware time stamping of arrival or transmit of so called "event"
>> messages.
>
> I'm aware of the difficulties a PTP slave (or even bridge
> implementation) faces with lwIP. I think these would be best met by
> adding custom members to struct pbuf that are initialized to 0 by
> pbuf_alloc. The reason we haven't done so yet is that "sizeof(struct
> pbuf)==16" fits quite well to small targets. However, having PTP
> support should be a good reason to drop this 16-byte requirement.
>
> I guess having (yet another) define to add custom pbuf members would
> be the way to go here.
>
> However, you wouldn't easily get these flags passed to socket layer,
> so that might not solve your API problem - although netconn API might
> work with some sort of hacked code accessing the netbuf's pbuf flags.
>
> BTW: what kind of PTP stack do you use? I have been searching, but
> alhough PTP seems like a well-documented, small protocol, there
> doesn't seem to be an open source solution for this, or did I miss
> something?
>
> Simon
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users