Update README.md: uses internal esc
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
Update README.md: introduction about RC input
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
Update README.md: introduction about PWM groups
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
remove defaults.parm and defined default params in hwdef file
EXPECT_DELAY_MS was used in direct contravention of the comment so it
must be okay. Even when it wasn't and the comment was accurate,
expecting a delay off the main thread never worked properly anyway.
This reverts commit 8dabd6cefc.
Setting up expected delays from a non-main thread never worked properly
due to the redundant main thread check, and isn't used today.
The delays will be canceled on return by the EXPECT_DELAY_MS(3000)
destructor at the start of the function. The current behavior will
unexpectedly cancel delays from higher levels up the stack and is likely
not what was intended.
Each of the six available timers now handles two consecutive PWM output
channels. This also implements support for changing the group PWM
frequency in a similar manner to the ChibiOS HAL.
Enabling/disabling the timer would apply the setting to whole groups of
channels. Fix to poke the comparator so that the setting only applies to
the particular channel.
Conveniently, though not necessarily intentionally, this avoids
truncating the output pulse and causing unexpected reactions from
servos. This also preserves the old behavior.
If you over allocate the number of analog channels this results in a
crash. It's easy to trigger this if you have voltage only monitors as we
still eat up a current input channel, regarless of if we use it. There
are only 16 channels at this time on ChibiOS, so if you have 9 voltage
only battery monitors you are out.
This PR improves that situation by only allocating channels when needed,
and in the case where we run out we now set a ConfigError, which on a
flight controller is much more friendly then a instant segfault the
moment we read a battery monitor. NOTE: on AP_Periph this takes the
node off the bus, rather then just sitting in the bootloader. This was
consideted acceptable as the current behaviour was to segfault and then
sit in the bootloader, unless you made new firmware that limited the
number of channels allocated it wasn't possible to recover in this
situation anyways.
