Hey! I was just in the process of doing my own crsf library when I saw that this already existed, so I thought I would try to contribute instead.
While the bitfield method of parsing the bytes for RcChannels is nice in that the bulk of the parsing is handled by the library, it also leaves a lot of performance on the table. I have the following parsing code, which is quite efficient, and can never panic, since all indexing can be verified by the compiler.
I tried running some benchmarks on an stm32f405, with the code above against two variants of the bitfield parser. One with RcChannelsPacked<&[u8]> so the parsing includes bounds checking and a panic path, and one with RcChannelsPacked<[u8; 22]> which cannot panic. These are the results for parsing 100_000 slices:
Benchmark 1: 0.175008 s (The one I propose)
Benchmark 2: 4.306767 s (RcChannelsPacked<&[u8]>)
Benchmark 3: 3.401365 s (RcChannelsPacked<[u8; 22]>)
I also ran a similar benchmark on a PC with criterion and the results are equally convincing. I have yet to implement the inverse "dump" method for this style, but it should be even less ugly than the parsing code. I will gladly make a PR if you agree to do it this way.
Hey! I was just in the process of doing my own crsf library when I saw that this already existed, so I thought I would try to contribute instead.
While the bitfield method of parsing the bytes for RcChannels is nice in that the bulk of the parsing is handled by the library, it also leaves a lot of performance on the table. I have the following parsing code, which is quite efficient, and can never panic, since all indexing can be verified by the compiler.
I tried running some benchmarks on an stm32f405, with the code above against two variants of the bitfield parser. One with
RcChannelsPacked<&[u8]>
so the parsing includes bounds checking and a panic path, and one withRcChannelsPacked<[u8; 22]>
which cannot panic. These are the results for parsing 100_000 slices:I also ran a similar benchmark on a PC with criterion and the results are equally convincing. I have yet to implement the inverse "dump" method for this style, but it should be even less ugly than the parsing code. I will gladly make a PR if you agree to do it this way.