The MSPv2 parsing was missing a check (present in v1) to prevent a possible buffer overrun if the payload exceeded the buffer size.
Also some code formatting cleanup.
The following driver files only contain initialization and configuration fuctions and were erroneously set up for speed-optimization. Moving them to size-optimization saves significant space. They all share common runtime functions contained in `drivers/accgyro/accgyro_mpu.c` which is correctly speed-optimized.
```
drivers/accgyro/accgyro_mpu6050.c
drivers/accgyro/accgyro_mpu6500.c
drivers/accgyro/accgyro_spi_mpu6000.c
drivers/accgyro/accgyro_spi_mpu6500.c
drivers/accgyro/accgyro_spi_mpu9250.c
drivers/accgyro/accgyro_spi_icm20689.c
```
Also added explicit `#ifdef USE_` around the code of some of the drivers missing it. Doesn't result in any space savings as the compiler optimizes out the unused functions. But better in the long-term as it will flag any cases where the code might be called without proper bounding.
Saves 10704 bytes on STM32F7X2.
The function that checks for each motor having valid telemetry broke with the implementation of bitbang. Effectively the motor count was zero and this caused the logic to fall through with a false-positive. The check relied on a local motor count that was set when the PWM dshot was initialized. When bitbang is active this initialization no longer runs and the motor count was defaulting to zero. This was missed in the bitbang implementation.
Fixed to get the motor count from a common source initialized by both timer and bitbang dshot.
Also changed the logic to prevent a false-positive fallthrough if the motor count is zero (shouldn't happen).
The addition of previous checks of bidirectional DSHOT being enabled were not sufficient. Additionally RPM filter must also be active (harmonics > 0) for dynamic idle to determine the minimum motor RPM and function correctly.
Just a very minor correction to the gyro scaling factor. All gyro drivers were using the hardcoded value of 16.4 msb/dps which is actually a rounded value of the true factor of 16.384 msb/dps. This value actually comes from the `abs(INT16)` range divided by the full scale. So 32768 / 2000. To be fair the Invensense gyro datasheets list this 16.4 rounded value so they're the cause of the mistake. Other manufacturers correctly list the scale as `(1 << 15) / 2000`.
The actual variance is trivial (about 0.1%) and only accounts for 2dps error at full scale so the situation is not dire. iThis variance is the reason we only see +-1998dps maximum rate in logging for example. But since we're already using a float for the scaling factor there's no reason not to use the more accurate value.