On Thursday, August 22, 2013 6:27:08 AM UTC-7, Trepi Dacious wrote: > > 1) I'm guessing the STM32F4 MCU? In that case yes, I've used protobuf in > an identical environment (chibios, etc.). >
You guessed it. Yeah, Olimex STM32-H407, ChibiOS/RT, fatfs, and nanopb. It was *extremely* helpful to be able to log intermediate data as optional fields without breaking backwards compatibility. > 2) Yes, I've used nanopb extensively, and it works very well. I've only > run into one issue with inter-operation with the Java version of protobuf > (and also protoc) - nanopb perfectly reasonably doesn't check that the enum > values you use are actually in the enum, whereas some other implementations > do. The result of this is not terrible - if you encode with nanopb and > decode with such an implementation, the decoder will just ignore the > invalid enum values, possibly adding them as unknown fields. In addition > you might want to validate your own enums on the MCU before encoding and > after decoding, if the results of an invalid value are bad... > > In general it's really no harder to use nanopb on the firmware and GPB on > the PC than to use the same on both ends, since they both follow the > protobuf spec., although it's a little different for me since I'm using > Java on the PC so I'm automatically not using the same libraries. I've also > tried with a ruby protobuf library, which was also happy talking to nanopb. > > Yeah, I agree. I've been looking at the nanopb+stm32+fatfs generated data on my PC using the C++ Google protobuf library. Works very well. I originally implemented things in Python, but it is silly slow compare to C++. I could just be doing something stupid but I saw 100x speedups by using the C++ API directly. > As a general protobuf point, I've found it very helpful to stick with the > "standard" delimited form for multiple messages, where the data has a > varint encoded length for each message in the data. The Google Java > protobuf library supports reading this directly, and encoding it with > nanopb is also pretty easy. > > I will probably do this next time. What I ended up doing was writing 2-byte (LSB, then MSB) message size delimiters prior to each message. In my case, it probably wasn't worth the extra work and I should have gone with the varint apprach. The nice thing about my approach is that I only had to encode the data once and it gets encoded directly into the memory buffer, so there is no double encoding or copying of the message after it is encoded. On the flip side, I had to make my buffers a bit bigger and handle the case where the message "overflows", and copy the overflowing bytes into the next buffer. You can check it out here in case you are interested: https://github.com/hazelnusse/robot.bicycle/blob/master/firmware/src/sample_buffer.cpp#L42 Such optimizing was probably not necessary for my application, but if you were trying to push the hardware harder, it might be. > I actually found this post looking for anyone with some code to wrap a > fatfs file as a nanopb stream, I'll continue my search! > > Let me know if you find something like that, it would be really cool to have. Luke -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/groups/opt_out.
