Is it necessary to call pb_ostream_from_buffer before each pb_encode call?

69 views
Skip to first unread message

Stephen Hersey

unread,
May 17, 2023, 10:54:24 AM5/17/23
to nanopb
I'm implementing nanopb for an embedded system, and none of the documentation or examples address the question in the subject line. All of the example code I've seen for nanopb does stream initialization and message encoding as a once-through process. None of the examples appear to send a second message using the same buffer or stream object, and the docs are silent on this as well. Permit me to complain that this does not reflect real-world conditions. (It is probably a gap in test coverage as well.) 

In most applications, there will be a transmit or receive loop that runs many times. The prudent firmware designer will attempt to minimize stack variables, and may therefore be inclined to statically allocate both the message buffer and the pb_ostream_t or pb_istream_t objects.

With this in mind, can someone tell me whether it is necessary to reset the stream object with pb_Xstream_from_buffer (and if applicable the message buffer) before each call to pb_encode when receiving, or pb_encode when sending? 

Thanks,
Steve Hersey


Petteri Aimonen

unread,
May 17, 2023, 11:51:05 AM5/17/23
to nan...@googlegroups.com
Hi,

Putting multiple messages into same stream is unfortunately unaddressed
in protobuf format in general. Though I agree that nanopb documentation
could at least explain the situation better. Google's protobuf docs have
a very small mention of message delimiting here:
https://protobuf.dev/programming-guides/techniques/

Nanopb directly supports delimiting with null bytes or with varint length
prefix. User code can use other delimiting methods as well.

If you reuse the same stream, it will just append the new message there.
If there is no delimiter, you cannot decode the messages separately.

For encoding/decoding with buffer, consider reseting the stream to mean "restart
from the start of the buffer".

--
Petteri
Reply all
Reply to author
Forward
0 new messages