Add a way to return git version string through make_protocol_ro_property

[tmagik]

There does not seem to be any obvious way to return a compile-time known constant string through fiber. If I try to use a 'version.c' file with a const char* string like
const char* fw_version_ = "fw-v0.4.10-50-g71984c07*";
then I get many pages of template errors when trying to use something like
make_protocol_ro_property("fw_version", fw_version_),
or with a #define fw_version "some_string"
make_protocol_ro_property("fw_version", FW_VERSION_)

Any ideas or direction on how to fix this?

[samuelsadok]

make_protocol_ro_property is no longer part of the new Fibre architecture (on the devel branch). The new way is to expose properties and functions is by adding them to the interface descriptor file (in the case of ODrive that's "odrive-interface.yaml").

Now regarding string support: The main problem currently is that the size of the input and output arguments is limited by the packet size of the underlying transport layer. So long strings would be pruned. There are plans to fix this by upgrading the low level protocol.

In the meantime, if you can cope with this limitation, here's a quick rundown of what to do:

• Pick a C++ type to represent your string (for instance char* but it would be safer to use a struct to include length).
• Pick and name a codec that defines how a given string is serialized from/to raw bytes. For example "ASCII with the length prepended as 8-bit int" or "UTF-8 with a the length prepended as variable length int". You could also decide on a fixed length string. If you pick a codec with notable limitations it should be named experimental_[...].
• Specialize Codec<T> for your C++ string type (see existing specializations for reference) to convert between raw bytes and C++ type.
• Add the new type to the interface generator
• Implement the string codec in pyfibre and add it to this list
• Let libfibre know about the length of the string argument by adding it here. Now the problem is that this code assumes that the argument length is known ahead of time. So you probably need to change codecs to be a map of functions and change the code that depends on it. This cross-dependency is also something I'd like to address in a future protocol change.