PIOS_Flash_Jedec_EraseChip is called during early
init when the table_magic has changed. This call
happens on CC/CC3D prior to the OS being initialized
so it is not OK to call vTaskDelay() yet.
This was leading to boards locking up (no flashing blue
LED) immediately after jumping to the application when
the table_magic had changed or was being init'd for the
very first time.
Refactored the updating of ChannelUpdateFreq so that it is done only when the actual update rates changes.
The actual update of the servo channel is moved inside the ActuatorTask.
Now the problem happen only in very few cases when modifying update rates.
Extra message context is also useful even when building more
than one target in the same invocation of make.
This example would enable extra context:
make fw_coptercontrol bl_coptercontrol
When building the various all_* targets, it was hard to tell which
board/build-type that each line of output applied to. Now, the
all_* target types will include something like:
CC [fw|cc ] flight/PiOS/STM32F10x/pios_gpio.c
which includes the necessary additional context.
This will help with identifying the context for warnings and errors
when building a group of targets.
Conflicts:
Makefile
The simposix build doesn't work on Windows or Mac so it shouldn't
be in the all_flight build target that is used as a pre-submit
check on all platforms.
number of QTimer instances and the number of redraws to hopefully
increase performance.
Changed so that when a child gets hilighted it will hilight its parent.
flash so it says completed. However, it still blocks the system for a long
time. During an erase the heartbeat will flash at 10 Hz to indicate what's
happening.
This still blocks telemetry even after lowering hte system priority (and there
is a vTaskDelay) which makes me think that the SPI bus being locked is blocking
Sensors or somethign else. This should not be permited when the system is
armed.
The reason the system locks up during the erase is that the file system
operations occur within the event dispatcher thread. It is very bad practice
for anything to block this (i.e. callbacks should never take very long). We
should probably move the object persistence handling into the system thread or
something but that can be a separate issue.
GCS will crash when HITLv2 plugin is started if there is no
HITLv2 configuration in the OpenPilotGCS.xml. This is a workaround
to prevent this behavior. Better way might be to rework the GCS config
handling, but as a workaround this should work.
