Moved to shared code and cms.c refactoring
Added missing line endings and comments
Passing tests - defines added
Added missing definition
Added check for USE_USB_CDC_HID in cmsUpdate
Code refactoring and condition change
Remove unnecessary include
Disable stick commands when HID is active and USB is connected
cdcDeviceIsMayBeActive refactored
Disable stick commands when HID is active and USB is connected
value when DMA was used. For example, if one byte was waiting, the function
returned one less than the size of the buffer.
The reason the bug didn't cause serious problems is that almost all
calls to this function check only whether the returned value is zero or not.
(The only exceptions I found were in "src/main/telemetry/hott.c". Perhaps
that code was tested on a target that did not use DMA.) The case of zero
bytes waiting was the only case in which the correct result was returned.
The detection logic in the MPU6000 and ICM20689 drivers had unnecessary "retry" logic that would try to read the `WHOAMI` register 5 times for MPU6000 and 20(!) times for ICM20689 - with a 150ms delay for each iteration. So the problem is that all the enabled drivers need to be probed in order so on a board that had a LSM6DSO for example (or any sensor further down the list) it would introduce about 4 seconds of initialization delay (dual gyro board would take 8 seconds!). Revised logic completes in about 0.4 seconds in the worst case.
After removing the unnecessary retry/repeat logic for the MPU6000 an initialization problem became visible. The driver was not following the datasheet guidelines and clearing the signal path after resetting the device. This lead to detection issues on warm reboots that were accidentally masked by the excessive delays with the retry logic.
The improvement in boot speed depends on the device's position in the list. So any device with a MPU6000 won't see any difference. All other devices will boot about 1 second faster (like ICM20602, ICM20689). Devices after the ICM20689 (like BMI160/270, LSM6DSO) will boot about 4 seconds faster.
If the RSSI channel PWM values were outside the expected 1000-2000 range, the `scaleRange()` function does not work properly. In particular if the value was below the minimum the result would be negative. Then this would cause an underflow when applied as a `uint16` to `setRssiDirect()`. This fix constrains the input range from 1000 to 2000.
