tact1m4n3 / crsf-rs

A work in progress crsf protocol packet parser
MIT License
10 stars 7 forks source link

Variable length packets #29

Open Serhii-the-Dev opened 1 month ago

Serhii-the-Dev commented 1 month ago

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?

tact1m4n3 commented 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.