Allows reordering OSD post-flight statistics without affecting the storage bit position and requiring Configurator changes. Previously the display order was one and the same with the enabled flag bit position. Additionally this ordering was also used by the configurator. So if the ordering was changed then the user settings would become corrupted (different stats would be enabled/disabled). Also the Configurator had an internal representation that had to match the definition enumeration otherwise the flags returned when saving would also set the wrong bits.
Now the definition remains constant and unchanging. The bit positions for the enable flag will not be changed. A separate array defines the presentaion order of the permanent stats ID's.
Added the display order to MSP to allow the configurator to also present the stats in the same order displayed in the firmware.
* On boot SPI or SDIO is initialised.
* Filesystem is initialised (including creation of blackbox freespace
file)
* Empty config file is created if it doesn't exist, or read if it does.
* If config is invalid/empty then config file is written to, then read
back and verified.
Enable as follows.
target.h:
target.c:
uint8_t eepromData[EEPROM_SIZE];
Changes:
- Replace boolean init flags with single initFlags variables.
- Avoid unused variable warnings.
Since the only target specific code was for SITL, and really it wasn't
target specific but EEPROM_IN_FILE specific the code is just gated by
the EEPROM_IN_FILE define.
If the MCU also supports PERSISTENT ram (not erased on a warm boot) it
allows testing of config changes without wearing out your flash.
e.g.
linker script
-------------
comment out __config_start/__config_end
target.c
--------
PERSISTENT uint8_t eepromData[EEPROM_SIZE]; // persistent, so it
survives warm boots.
target.h
--------
extern uint8_t eepromData[EEPROM_SIZE];
SITL actually keeps the EEPROM in a FILE, loaded into RAM using
alternate FLASH_* implementation.
Flash operations can specify how long to wait before the next operation
is issued.
Prior to this the amount of time waited, and when, was wrong.
e.g.
m25p16_eraseCompletely - possibly waits ages TO START, starts, exit.
m25p16_pageProgramContinue - waits DEFAULT_TIMEOUT_MILLIS to START,
starts, exits.
m25p16_pageProgramContinue would fail to write to the flash as the
device was still busy erasing and didn't wait long enough.
what happens now is:
m25p16_eraseCompletely - waits using the current timeout, starts, sets
timeout to be `now + BULK_ERASE_TIMEOUT_MILLIS`, exits.
m25p16_pageProgramContinue - waits using the current
`BULK_ERASE_TIMEOUT_MILLIS`, starts, exists, sets timeout to be `now +
DEFAULT_TIMEOUT_MILLIS`.
Since the timeout is stored in the flashDevice_t the solution also works
for multi-die devices which use an instance of flashDevice_t for each
die.
