Shaved about 150us each strip update.
This commit leaves in some timing trace code for the CC3D target, the
results of which can be seen in the debug variables for the sections
being timed.
A later commit will remove/disable the timing code.
series development board.
These boards can be picked up for less than $11, coupled with a 10DOF
sensor board they make a great development platform or cheap expandable
FC.
Pretty much all pins are available to be used, unlike on the less
capable and more expensive OLIMEXINO.
Each flag was previously a whole byte, now all of the flags only take up
4 bytes as they are represented by bit masks.
This is cleaner because the different kind of flags are now separated.
Additionally this changes the behaviour of arming slightly. When using
a switch to arm the aircraft will not arm unless the switch has been in
the off state once. This prevents arming if you power the aircraft with
a low throttle and the switch in the on position.
just use it in-place. This saves ~308bytes of memory.
Prior to this there were 4 profiles in ram all the time, the 3 main
profiles and a copy of one of them.
This commit was aided by a side effect of the work done to clean up the
output of the cli dump command since it is now easy to conditionally
apply the changes to the memory addressed used to read/write cli
variables. See 8c3a869251.
gps.c now only has code that deals with gps hardware, state and
messaging.
navigation.c now only has code dealing with flight
navigation/waypoints/home/hold/etc
Added documentation.
Added LED_STRIP feature, can only be enabled under certain circumstances
depending on target due to pin/timer mappings - see documentation.
Previously, on the OLIMEXINO at least, initial readings are lower than
normal readings and that meant that the battery warning voltage was
incorrectly set.
using different values in different.
The cause was the IMU init code which triggered calculation was never
called after switching profiles - it couldn't be called twice because it
also initialised the compass.
The solution was to decouple compass initialisation from IMU
initialisation and extract the code to recalculate throttle angle scale
to a new method.
It was noticed that GPS startup time increased when the change was made
from using EGNOS by default to using AUTO by default.
The default is still AUTO but faster GPS startup times may be achieved
by telling the GPS receiver what region you are in.
This also removes more unfinished MTK gps provider support.
