Complete refactor logging rate selection in cli, msp and blackbox code
Retains backward compatibility
Fixed tests and requested changes
Fixed blackbox device "SERIAL" not showing in cms menu and whitespace of "FLASH"
Fixes a bug in the HAL USP vcp serial logic that would cause communication to hang after receiving a packet containing exactly 64 bytes.
When a packet is exactly 64 bytes the USB specification requires an empty (0 byte) pack to be additionally sent. The receiving logic was not handling this 0 byte packet properly. The logic error would cause it to not trigger receiving he next packet and communication would stop.
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.
Fixes a problem with dynamic idle not checking for bidirectional DSHOT being enabled. So the code would run but have no RPM data available leading to elevated motor idle.
Fixes a problem with dynamic idle not resetting accumulated static variables that continue to be used when dynamic idle is switched off via a PID profile change. Depending on the state of the variables this could cause excessive motor idle speed. In some cases enough to cause the quad to spontaneously take off on arming or be unable to descend in flight.
Fixes a problem with dynamic idle inappropriately modifying the static `motorOutputLow` that is set based on the chosen motor protocol. Downstream code that relies on this value to determine the acutal motor output range was adversely affected.
Motor and DSHOT refactoring broke blocking DSHOT commands as the check for commands being enabled was not taking into account that "blocking" type commands need to operate only when the motors are not enabled.
Fixes the CLI `dshotprog` command.
Most people who have tested IllusionFPV's expo on the dynamic D lowpass filter have found it to improve propwash without adverse effects.
It achieves this reducing D lowpass delay more quickly on throttling up.
This allows us to retain, at idle, the strong lowpass filtering we currently have, but quickly reduce lowpass delay and improve propwash by mid throttle.
A value of 5-7 is OK I'm proposing 5 as a conservative start.
I know this is a new feature but it is really good . It would be great if it could be made active by default, if possible, in 4.2.
