The USE_DSHOT_TELEMETRY_STATS define was is gating a closing bracket '}',
so that the scopes are breaking in case telemetry stats are not enabled.
This commit fixes this behaviour by moving the closing bracket out of the
ifdef.
Signed-off-by: Mimoja <git@mimoja.de>
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).
F405 working (OMNIBUSF4SD target)
F411 not tested
F722 working, needs testing (OMNINXT7 target)
F74x not working
NOX target (temporary)
bb_dshot with telemetry on f4
bbshot f7 targets and fix crash due to missing debug pins
remove empty line
add empty lines
remove OMNIBUSF4 specific debug pins
add missing comma
add missing comma
Use separate bbTimerHardware array to fix unified targets
eliminate now unneeded timerGetByUsage
don't duplicate timer1 def
Add auto mode, rename dshot_bbshot to dshot_bitbang
remove newline
renamve various files
various changes to address feedback
address feedback
address feedback
add pacer timers to timer show
don't disable telemetry if dshot_bitbang is on or auto
Address feedback, add faster decode implementation based on bit banding, modify dma parameters to reduce required memory bandwidth on half
remove debug output
remove NOINLINE
Protect gpio direction change with critical sections
FIXWS_SAVE_INDEX
add static back in
no forward typedef
address review feedback
disallow proshot1000 with dshot bitbang
Extracted and plumbed up 'dbgPin'.
It turns out that two calls to micros() and the calculation of
directionChangeDurationUs took 581 cycles, vs 396 cycles without the
calls to micros() and deferred calculation of the duration which is only
needed in the CLI.
This brings the time down from around 7 microseconds to 5.5 microseconds
on an F3 at 72Mhz.
This makes the difference between 100% invalid telemetry and 4% invalid
telemetry on the first motor on the F3.
Squashed commits:
* Remove the forward declaration for `pwmDshotSetDirectionInput` and make
it static.
* Remove unneeded forward declaration of `motor_DMA_IRQHandler`.
* Remove duplication in DMA IRQ Handler.
Doesn't affect resulting code but improves readability.
* Use an inline function to read DWT->CYCCNT.
* Remove unneeded forward declarations from cli.c now that the correct
header is included.
* Update DWT unlock method.
Refactoring steps were as follows:
* Duplicate pwmDshotSetDirectionOutput to pwmDshotSetDirectionInput and
remove `output` variable in preparation for removing the `output` variable from each method.
* Delete all trace of `output` flag from `pwmDshotSetDirectionInput`
* Delete all trace of `output` flag from `pwmDshotSetDirectionOutput`
* Cleanup now that pwmDshotSetDirectionInput is only called when USE_DSHOT_TELEMETRY is
enabled.
* Remove redundant code paths.
* Move #ifdef outside the method.
* Removed parameters that are never needed.
* Delete unneeded forward declarations.
Reduce code by supporting only GCR, fix serial_4way, fix f7 dshot bidir
fix ws and eliminate superfluous buffer
use GCR constant instead of 32
decode optimization
bump 4way prot version mumber
bump if version
Having the stats data structures incorporated into the `dmaMotors[]` array structure was causing excessive CPU load on F4. The actual cause is unknown, but likely some kind of negative cache interaction. Moving the stats to a standalone array separate from `dmaMotors[]` solves the problem.
Captures packet quality statistics per motor to provide a platform for troubleshooting and in-flight alarms or warnings.
Continuously monitors and captures packet stats over the past second to be used to determine DSHOT telemetry link quality.
Update the CLI to move the DSHOT telemetry data/stats out of the `status` command and into a dedicated `dshot_telemetry_info` command. Reformatted the motor data to include the invalid packet percentages. Will aid in debugging by identifying ESC's that may be misconfigured (not supplying data), or those with problems generating high invalid packet percentages.
Data can later be used to generate OSD and beeper-based warnings if invalid packet percentages exceed thresholds.
Included a blackbox logging debug mode (`set debug_mode = DSHOT_RPM_ERRORS`) to record the per-motor invalid packet percentages in hundredths of a percent (so 123 is 1.23%).
If DSHOT telemetry is enabled but one or more ESC's are not supplying valid telemetry packets, then send the DSHOT command to enable telemetry once a second while disarmed until all ESC's are supplying telemetry.
Addresses the issue of the flight controller booting without the ESC's powered. In this case the initial command at boot to enable bidirectional telemetry will be missed by the ESC since they're not powered. If the battery is subsequently plugged in the ESC's will default to bidirectional telemetry disabled.
This change will detect that ESC's are not supplying telemetry and attempt to preiodically enable them.
If the RPM filter is enabled, requires all motors to have received a valid DSHOT telemetry frame before arming is allowed. Otherwise sets the arming disabled reason `ARMING_DISABLED_RPMFILTER`.
