7 The things outlined here are common to both the encoder and the decoder part.
13 All Protocol Buffers implementations use .proto files to describe the message format.
14 The point of these files is to be a portable interface description language.
16 Compiling .proto files for nanopb
17 ---------------------------------
18 Nanopb uses the Google's protoc compiler to parse the .proto file, and then a python script to generate the C header and source code from it::
20 user@host:~$ protoc -omessage.pb message.proto
21 user@host:~$ python ../generator/nanopb_generator.py message.pb
22 Writing to message.h and message.c
25 Compiling .proto files with nanopb options
26 ------------------------------------------
27 Nanopb defines two extensions for message fields described in .proto files: *max_size* and *max_count*.
28 These are the maximum size of a string and maximum count of items in an array::
30 required string name = 1 [(nanopb).max_size = 40];
31 repeated PhoneNumber phone = 4 [(nanopb).max_count = 5];
33 To use these extensions, you need to place an import statement in the beginning of the file::
35 import "nanopb.proto";
37 This file, in turn, requires the file *google/protobuf/descriptor.proto*. This is usually installed under */usr/include*. Therefore, to compile a .proto file which uses options, use a protoc command similar to::
39 protoc -I/usr/include -Inanopb/generator -I. -omessage.pb message.proto
44 Nanopb uses streams for accessing the data in encoded format.
45 The stream abstraction is very lightweight, and consists of a structure (*pb_ostream_t* or *pb_istream_t*) which contains a pointer to a callback function.
47 There are a few generic rules for callback functions:
49 #) Return false on IO errors. The encoding or decoding process will abort immediately.
50 #) Use state to store your own data, such as a file descriptor.
51 #) *bytes_written* and *bytes_left* are updated by pb_write and pb_read.
52 #) Your callback may be used with substreams. In this case *bytes_left*, *bytes_written* and *max_size* have smaller values than the original stream. Don't use these values to calculate pointers.
61 bool (*callback)(pb_ostream_t *stream, const uint8_t *buf, size_t count);
67 The *callback* for output stream may be NULL, in which case the stream simply counts the number of bytes written. In this case, *max_size* is ignored.
69 Otherwise, if *bytes_written* + bytes_to_be_written is larger than *max_size*, pb_write returns false before doing anything else. If you don't want to limit the size of the stream, pass SIZE_MAX.
73 This is the way to get the size of the message without storing it anywhere::
75 Person myperson = ...;
76 pb_ostream_t sizestream = {0};
77 pb_encode(&sizestream, Person_fields, &myperson);
78 printf("Encoded size is %d\n", sizestream.bytes_written);
84 bool callback(pb_ostream_t *stream, const uint8_t *buf, size_t count)
86 FILE *file = (FILE*) stream->state;
87 return fwrite(buf, 1, count, file) == count;
90 pb_ostream_t stdoutstream = {&callback, stdout, SIZE_MAX, 0};
94 For input streams, there are a few extra rules:
96 #) If buf is NULL, read from stream but don't store the data. This is used to skip unknown input.
97 #) You don't need to know the length of the message in advance. After getting EOF error when reading, set bytes_left to 0 and return false. Pb_decode will detect this and if the EOF was in a proper position, it will return true.
99 Here is the structure::
103 bool (*callback)(pb_istream_t *stream, uint8_t *buf, size_t count);
108 The *callback* must always be a function pointer. *Bytes_left* is an upper limit on the number of bytes that will be read. You can use SIZE_MAX if your callback handles EOF as described above.
112 This function binds an input stream to stdin:
116 bool callback(pb_istream_t *stream, uint8_t *buf, size_t count)
118 FILE *file = (FILE*)stream->state;
123 while (count-- && fgetc(file) != EOF);
127 status = (fread(buf, 1, count, file) == count);
130 stream->bytes_left = 0;
135 pb_istream_t stdinstream = {&callback, stdin, SIZE_MAX};
140 Most Protocol Buffers datatypes have directly corresponding C datatypes, such as int32 is int32_t, float is float and bool is bool. However, the variable-length datatypes are more complex:
142 1) Strings, bytes and repeated fields of any type map to callback functions by default.
143 2) If there is a special option *(nanopb).max_size* specified in the .proto file, string maps to null-terminated char array and bytes map to a structure containing a char array and a size field.
144 3) If there is a special option *(nanopb).max_count* specified on a repeated field, it maps to an array of whatever type is being repeated. Another field will be created for the actual number of entries stored.
146 =============================================================================== =======================
147 field in .proto autogenerated in .h
148 =============================================================================== =======================
149 required string name = 1; pb_callback_t name;
150 required string name = 1 [(nanopb).max_size = 40]; char name[40];
151 repeated string name = 1 [(nanopb).max_size = 40]; pb_callback_t name;
152 repeated string name = 1 [(nanopb).max_size = 40, (nanopb).max_count = 5]; | size_t name_count;
154 required bytes data = 1 [(nanopb).max_size = 40]; | typedef struct {
158 | Person_data_t data;
159 =============================================================================== =======================
161 The maximum lengths are checked in runtime. If string/bytes/array exceeds the allocated length, *pb_decode* will return false.
165 When a field has dynamic length, nanopb cannot statically allocate storage for it. Instead, it allows you to handle the field in whatever way you want, using a callback function.
167 The `pb_callback_t`_ structure contains a function pointer and a *void* pointer you can use for passing data to the callback. The actual behavior of the callback function is different in encoding and decoding modes.
169 .. _`pb_callback_t`: reference.html#pb-callback-t
175 bool (*encode)(pb_ostream_t *stream, const pb_field_t *field, const void *arg);
177 When encoding, the callback should write out complete fields, including the wire type and field number tag. It can write as many or as few fields as it likes. For example, if you want to write out an array as *repeated* field, you should do it all in a single call.
179 The callback may be called multiple times during a single call to `pb_encode`_. It must produce the same amount of data every time.
181 .. _`pb_encode`: reference.html#pb-encode
183 This callback writes out a dynamically sized string::
185 bool write_string(pb_ostream_t *stream, const pb_field_t *field, const void *arg)
187 char *str = get_string_from_somewhere();
188 if (!pb_encode_tag_for_field(stream, field))
191 return pb_encode_string(stream, (uint8_t*)str, strlen(str));
198 bool (*decode)(pb_istream_t *stream, const pb_field_t *field, void *arg);
200 When decoding, the callback receives a length-limited substring that reads the contents of a single field. The field tag has already been read.
202 The callback will be called multiple times for repeated fields. For packed fields, you can either read multiple values until the stream ends, or leave it to `pb_decode`_ to call your function over and over until all values have been read.
204 .. _`pb_decode`: reference.html#pb-decode
206 This callback reads multiple integers and prints them::
208 bool read_ints(pb_istream_t *stream, const pb_field_t *field, void *arg)
210 while (stream.bytes_left)
213 if (!pb_decode_varint(stream, &value))
215 printf("%lld\n", value);
220 Field description array
221 =======================
223 For using the *pb_encode* and *pb_decode* functions, you need an array of pb_field_t constants describing the structure you wish to encode. This description is usually autogenerated from .proto file.
225 For example this submessage in the Person.proto file::
228 message PhoneNumber {
229 required string number = 1 [(nanopb).max_size = 40];
230 optional PhoneType type = 2 [default = HOME];
234 generates this field description array for the structure *Person_PhoneNumber*::
236 const pb_field_t Person_PhoneNumber_fields[3] = {
237 {1, PB_HTYPE_REQUIRED | PB_LTYPE_STRING,
238 offsetof(Person_PhoneNumber, number), 0,
239 pb_membersize(Person_PhoneNumber, number), 0, 0},
241 {2, PB_HTYPE_OPTIONAL | PB_LTYPE_VARINT,
242 pb_delta(Person_PhoneNumber, type, number),
243 pb_delta(Person_PhoneNumber, has_type, type),
244 pb_membersize(Person_PhoneNumber, type), 0,
245 &Person_PhoneNumber_type_default},
251 Return values and error handling
252 ================================
254 Most functions in nanopb return bool: *true* means success, *false* means failure. If this is enough for you, skip this section.
256 For simplicity, nanopb doesn't define it's own error codes. This might be added if there is a compelling need for it. You can however deduce something about the error causes:
258 1) Running out of memory. Because everything is allocated from the stack, nanopb can't detect this itself. Encoding or decoding the same type of a message always takes the same amount of stack space. Therefore, if it works once, it works always.
259 2) Invalid field description. These are usually stored as constants, so if it works under the debugger, it always does.
260 3) IO errors in your own stream callbacks. Because encoding/decoding stops at the first error, you can overwrite the *state* field in the struct and store your own error code there.
261 4) Errors that happen in your callback functions. You can use the state field in the callback structure.
262 5) Exceeding the max_size or bytes_left of a stream.
263 6) Exceeding the max_size of a string or array field
264 7) Invalid protocol buffers binary message. It's not like you could recover from it anyway, so a simple failure should be enough.
266 In my opinion, it is enough that 1. and 2. can be resolved using a debugger.
268 However, you may be interested which of the remaining conditions caused the error. For 3. and 4., you can set and check the state. If you have to detect 5. and 6., you should convert the fields to callback type. Any remaining problem is of type 7.