Open ken-voly opened 2 years ago
Based on other issues I've seen I'm currently wondering if we should stop scanning between all these protocols (by default) and instead simply have the user explicitly configure which to use.
Thoughts?
That's basically what we've done internally, except at build time, because that makes sense for our use case. For general purpose use, having it be configurable would likely be the best bet. Then you can get the safety of only 1 protocol, but keep the flexibility of having multiple options.
Yeah. I think making it configurable using a parameter would be the best approach. A register could be added to the IO to indicate which method the IO should use, if any.
To be clear, we can probably still fix the buffer reuse bug.
I agree. There's too much potential for bugs by using a shared global buffer.
Describe the bug DSM overwrites SBUS data in the global frame buffer, causing the SBUS frame to be unsuccessfully decoded.
Both DSM and SBUS use the same global buffer to store their work between function calls. Each iteration of the IO main loop,
sbus_input()
is called, followed bydsm_port_input()
. Because it takes more than one iteration of the main loop to read an entire SBUS packet, DSM can end up overwriting the SBUS data in the global buffer. This leads to the packet being unsuccessfully decoded. In the worst case, DSM may be able to overwrite with data that results in a valid SBUS packet containing garbage data.To Reproduce Steps to reproduce the behavior:
px4_fmu-5_default
, and upload to a Pixhawk 4.bytearray(b'\x0f\xac\xf0\x9e\xf7\xc0\x07>V\xb0\x02|\xac`\x05\xf8\xc0\x07>\xf0\x81\x0f|\x00\x00')
Expected behavior DSM should not be able to overwrite the SBUS data and the SBUS packet should be decoded successfully.
When DSM is commented out, it behaves correctly.
Log Files and Screenshots![Screenshot from 2021-09-15 13-54-52](https://user-images.githubusercontent.com/83845273/133508220-83be2370-181f-47f9-9a3b-ce9ed7bf0779.png)