dfu-cc.proto output manually adjusted?

[jeffs]

I was redefining the init packet and when it came time to generate the nano-pb files, it looks like there is a fair amount of difference in the newly auto generated pb.c and pb.h files. Since I ran into problems installing modules necessary to follow the process documented here, I regenerated the files using nano-pb as a protoc plug-in. I wanted to make sure there wasn't a command line flag I was missing that would generate the same output from the dfu-cc.proto file.

I guess the question is: are the dfu-cc.pb.c and .h files in the dfu example untouched after they were generated by nano-pb, or were they manually modified to fit Nordic code format standards?

e.g. #define DFU_FW_TYPE_MIN DFU_FW_TYPE_APPLICATION --- > #define _dfu_FwType_MIN dfu_FwType_APPLICATION

enums dfu_hash_type_t --- > dfu_HashType

[bjorn-spockeli]

Hi Jeffs,

you are correct, the files are modified after they are generated using the , i.e. we run a CamelCase splitter script to align it the rest of the SDK, i.e. with our internal code standard.

Best regards

Bjørn

[jeffs]

Thanks, Bjørn.

Care to share the script? I didn't see it in the source distribution. It might be helpful for customers if it was released with nRFUtil source and mentioned in the docs, or, maybe even better, use an adapter header file to redefine them instead of modifying the tool's output file directly.

[bjorn-spockeli]

@jeffs: You can find it, camel_case_splitter.py, in the \external\nano-pb\generator folder.