This is done to make it clearer in configuration dumps which ports are
enabled and configured.
There is a nice code size reduction due to less strings being needed.
Serial documentation updated.
Closes#966.
This primarily is to avaoid stalling the main loop when beeping and
flashing.
This is needed because oneshot ESCs do not receive updates when the main
loop is stalled.
Additionally the beeper code for sticks held in disarm position is
changed since it also clashed with profile selection. Now profile
selections can be seen and heard clearly.
Other subsections of the system that changed the LED0 state while the
main loop is running have been updated to use the status indicator API
instead of blindly hitting the hardware which previously caused lots of
odd LED flashing behaviour - now it is consistent.
Use C++11 for the C++ unit test code to make the tests easier to read.
Previously we were using a 17 year old standard (!) (g++98)
GoogleTest is compiled with some additional flags to avoid some specific
warnings. Consider enabling the warnings when upgrading GoogleTest.
See https://code.google.com/p/googletest/issues/detail?id=433Closes#941
This also ensures that the PWM mapping does not use the sonar pins when
sonar is enabled in a board agnostic way.
Conflicts:
src/main/config/config.c
src/main/drivers/pwm_mapping.h
src/main/main.c
src/main/target/CC3D/target.h
...and apply them after a soft reset (which also required an additional
write to flash), it is now such that features and settings are modified
and stored in flash as before.
After initialisation completes, the active features are latched and are
not to be modified until the next startup. This guarantees that all
saved modifications are persistent even when power is switched of
(without a reset in between).
When a soft reset is required, the active features and the currently
configured features are used to detect if the oneshot feature has
changed state, in which case motor PWM outputs are stopped and soft
reset is done after a 1.5 second delay.
During normal operation the active features will not change and all
changes to features ordered via MSP commands or the CLI are applied to
the configuration that gets saved to flash.
The required effect of modifying features without changing the actions
in the running mainloop is achieved. The user needs to be aware that
changes to features are not applied immidiatly.
sensible/fix min/max settings for those settings.
This fixes erratic flight behaviour before failsafe kicks in on SBus
receivers.
An X8R SBus RX in failsafe mode outputs 880 on all channels.
See #918 and #919
