I don't have much experience with embedded systems so I honestly don't know
for sure how well-suited Cap'n Proto is. I would think it would work pretty
well in that the format is simple and therefore should be possible to
interpret with relatively few instructions. Though when people start
talking about hard limits of 1024 bytes, I wonder if pointers being 8 bytes
or having a 16-byte header (8 bytes segment table, 8 bytes root pointer)
starts to become a problem? That's all I was trying to say on the other
Presumably you would want a lean C-based implementation in this scenario,
so I'd suggest looking at:
On Wed, Oct 12, 2016 at 3:27 PM, Andrew Lentvorski <bsd...@gmail.com> wrote:
> I was hoping to get away from the plethora of hand written parsers that we
> have scattered across multiple devices, languages, and roles (sensor, phone
> apps, server backend microservices of various languages).
> Obviously, I'd like to say "Here's the schema, compile it, and use the
> code." So, your advice to use hand-written parsers to the guy running on
> HDLC made me very sad: :'-(
> For my stuff, I basically have a small, fixed info header (version, type,
> sequence number, etc.) with a list of int32_t data(probably stays under 1K
> per packet) at the back.
> Is there really no good way to use Cap'n Proto to do this? Would SBE or
> FlatBuffers be any better?
> You received this message because you are subscribed to the Google Groups
> "Cap'n Proto" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to capnproto+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/capnproto.
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email
Visit this group at https://groups.google.com/group/capnproto.