Open Serhii-the-Dev opened 1 month ago
Hello! I didn't know there were dynamically sized packets. To implement them maybe we can make the length dynamic(no longer a constant in the trait impl) and be returned by the encode function. The use of it was to convert inside each packet's implementation the slice into an array ref which would remove safety checks. The beauty of it was that we could have macros that would implement the any payload trait. Or another way to tackle this would be to set the LEN
constant to the maximum packet length(64), not that elegant. For zero terminated strings, I have no idea. If we use slices(or anything else that does not copy the string), we will have to add lifetimes to all packets. I don't think it would break anything, though I am not sure. We could use CStr
, instead of slices.
Some CRSF packets, for example CRSF_FRAMETYPE_DEVICE_INFO or CRSF_FRAMETYPE_PARAMETER_SETTINGS_ENTRY may contain null-terminated strings, such as a device or a property field name, which makes an exact packet size unknown at compile time (although the max size constraint is still well-defined). I'm currently working on an implementation of the CRSF config protocol and would like to contribute to this lib however it's unclear how the
LEN
constraint within a packet module should be handled in such a case. Also, how it's expected to represent strings, should it be a&'static str
or it's better to keep a raw byte buffer and left for an end-user to decide how to convert the data?