Somewhat related, we use protocol buffers for real-time robot
control on a PC. Specifically, we're using protobuf-c over a
shared-memory IPC. This can send small messages at a
kilohertz on a Pentium M without any significant CPU overhead.
Here is our sysem:
http://www.golems.org/node/1241
Here is our IPC:
http://www.golems.org/node/1526
> We're considering using it to communicate with an auxiliary, non-realtime
> system over ethernet. The idea is that the second system sends commands to
> the embedded processor and receives status messages (each a few hundred
> bytes) at 30 Hz. One of the concerns is processor load; has anyone
> measured the additional processing required to encode messages?
30Hz sounds very doable. What kind of CPU does your embedded system
use? Something like an ARM should work fine. You'll probably have
much more latency introduced by the IP/ethernet network than from
the protobuf encoding.
> I'm evaluating nanopb (http://koti.kapsi.fi/jpa/nanopb/) for this, due to
> its small code size and the ability to avoid dynamic allocation. I'd
> appreciate any feedback on this implementation.
Not familiar with that one.
Protobuf-C can avoid dynamic allocation, but you need to give it
your own allocator. We have one (a region based allocator) in our
library here:
https://github.com/golems/amino
Good Luck!
-ntd