This backend will keep all updated data in RAM and
persist the data between reboots using flash memory.
Using only flash memory would result in a slow backend that
would decrease the lifetime of the flash memory, using both
we can reduce the several cycles of erase & write into flash
and keep the performance of the backend almost as fast
as the RAM only backend.
Note: Do not use this backend on a sector from the same flash memory
bank as the memory bank that STM32 read instructions or it can block
the CPU from fetching instructions from flash during the erase and
write operations and cause your drone crash.
The maximum number of missions was increased in almost 8 times in
recent commit: 9369262e63 navigator: allow more mission items.
As this board loads missions in RAM, now it don't have enough memory
to allocate causing dataman start to fail, so mark it as a memory
constrained system and reduce the number of maximum missions
supported.
This board don't have a SDCard to save crash dumps and it was causing
the board to get stuck into '[boot] There were %d reboots with Hard
fault that were not committed to disk - System halted', until user
connect to the serial console and clear the fault.
Measure the battery voltage of Aero RTF kit will be done by FPGA
and read by AeroFC using I2C bus.
The protocol is a little bit odd, it have different I2C slave
address for each "register", in future the FPGA RTL will
have a protocol more similar to other I2C sensors.
Also Aero RTF don't have a ADC line to measure current consumption.
This way user can set aftwards any other AUTOSTART value and it will
not be overwritten.
Also move the block up and set SYS_AUTOCONFIG, this way if air frame
configuration was reset in ground station it will wipe the parameters
before load new ones.
AeroFC is updated by Aero board using the UART between AeroFC
and Aero board.
This script will copy firmware and px_uploader.py to Aero board and run
px_uploader.py with the correct paremeters. User only needs to have a
network connection (Ethernet over USB or WiFi) with Aero board to update
AeroFC firmware. The IP/hostname can be given by AERO_HOSTNAME
environment variable.
As ASC use a non-standard UART for mavlink it is necessary check for
the board name and set SYS_AUTOSTART to initialize mavlink on the
right interface otherwise there is no way to change the SYS_AUTOSTART.
By default the baudrate in flight stack (Mavlink or NSH) 57600 and the default
baudrate of bootloader is 115200. So we may need to set different
baudrates.
The Mavlink reboot messages was only requesting the board to reboot.
If the flashed bootloader has a small or no timeout user will
never be able to update firmware.