Previous logic was updating updating the DMA buffer for all possible LED positions (32) regardless of how many were used. Since there are 24 bytes per LED, this performed a lot of unnecessary processing in cases where the user had less than 32 LEDs configured.
Also includes a bug fix in that if the LED count was decreased (like making changed using the Configurator LED tab), the now unused LEDs at the end of the string would remain on at the last color applied. Now they will be properly turned off. The bug was minor as it was resolved by a reboot, but made setup using the Configurator confusing since changes made are reflected when the user clicked the "Save" button (which does not reboot).
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'.
In 4.0x the dynamic notch range was set by default to AUTO mode.
This would set range to low, medium or high based on the dynamic lowpass max setting, which the user was supposed to configure to suit the maximum rpm of the quad.
In 4.1 we are moving the maximum value of the dynamic gyro lowpass very high whenever the rpm filter is enabled. And, generally, it is OK to do this even on non-rpm quads.
The problem then becomes that the dynamic notch quietly shifts itself to HIGH mode, and that can cause it to not track ordinary frame and prop resonances like it should.
I think it will be better overall in medium mode, which works best for most quads out of the box. Users of very high RPM quads can choose high. XClass quads or machines with low frequency resonance should choose low, and should set the dyn_notch_min_hz value low enough to reach the resonant peak.
Servos marked as forwarded from RC channels and not written previously
should be written after gimbal servos and before forwarding by
FEATURE_CHANNEL_FORWARDING.
Higher feed forward improves stick responsiveness and reduces bounce back on lower authority quads.
Feed forward defaults in 4.0 were slightly conservative even for typical quads.
In association with ff_boost and ff_max_rate_limit, overshoot with even higher feed forward is less of a problem than before.
I think these values should be about right for 4.1
