ther recipients: bsd...@gmail.com
Most embedded protocols that evolve over time eventually adopt the kind of
thing as found in Cap'n Proto anyway. It's a little bigger than I'd like,
but not terribly so. I'd rather start general and move to specific than
the other way around.
In addition, it's quite clear that your programming is going to be *WAY*
better than a million little parsers written by my teams in terms of
And while embedded programming is odd, it's not as odd as people think,
nowadays. Mostly it's like programming a computer from 1996/1997. The
small RAM(100K) being the primary exception.
I have chewed on the encoding a bit and it doesn't seem out of line if I'm
careful about how I build descriptions.
Thanks for the thoughts about this.
On Thursday, October 13, 2016 at 9:46:26 PM UTC-7, Kenton Varda wrote:
> Hi Andrew,
> 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
>> 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
>> 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.