This was found by the logfs unit tests.
This may be useful if we want to use empty files as existence
flags in the future. Doesn't make any sense for UAVOs but
is valid in the general sense of a filesystem.
Verify that the flash component on the board matches exactly
what we're expecting. This is a simple way to verify that we
are communicating properly with the JEDEC flash chip.
Conflicts:
flight/targets/board_hw_defs/freedom/board_hw_defs.c
flight/targets/board_hw_defs/quanton/board_hw_defs.c
When storing an opaque pointer value in a uint, the
appropriate type is uintptr_t which is guaranteed to
be wide enough to hold a pointer.
This is particularly important when the code can be
compiled in a sim or unit test environment which is
intended to run on a 64-bit machine.
Conflicts:
flight/PiOS/Common/pios_flash_jedec.c
flight/targets/DiscoveryF4/System/pios_board.c
flight/targets/FlyingF4/System/pios_board.c
flight/targets/Freedom/System/pios_board.c
flight/targets/Quanton/System/pios_board.c
When storing an opaque pointer value in a uint, the
appropriate type is uintptr_t which is guaranteed to
be wide enough to hold a pointer.
This is particularly important when the code can be
compiled in a sim or unit test environment which is
intended to run on a 64-bit machine.
Conflicts:
flight/targets/DiscoveryF4/System/pios_board.c
flight/targets/FlyingF4/System/pios_board.c
flight/targets/Freedom/System/pios_board.c
flight/targets/Quanton/System/pios_board.c
Filesystem magic value has been updated to deal with the
format change.
Conflicts:
flight/targets/board_hw_defs/discoveryf4/board_hw_defs.c
flight/targets/board_hw_defs/flyingf4/board_hw_defs.c
flight/targets/board_hw_defs/freedom/board_hw_defs.c
flight/targets/board_hw_defs/quanton/board_hw_defs.c
The flashfs layer is now entirely decoupled from the UAVO
data types. All UAVO related calls are now properly
contained within uavobjectmanager.c.
This will make the flashfs layer more portable as well as
more testable in a standalone environment. Eventually,
this layer could be used to store arbitrary files.
Also fixed all of the doxygen headers for the flashfs API.
A new flash driver abstraction is also provided to allow
for future support of other types of flash device under
the filesystem.
Conflicts:
flight/PiOS/Common/pios_flash_jedec.c
When more than one task is concurrently trying to access
the same i2c bus and a timeout occurs on bus lock the
transfer would just continue and blow up the pios_i2c
driver. This has been fixed.
There shouldn't be any reason to need 8-byte alignment on the
F1 platform. This allows better packing of all malloc'd data.
Reducing this below 4-byte alignment is not recommended and will
likely result in misaligned pointers being passed to peripherals.
RAM savings is another 300 bytes.
When reading the jedec device id the code only transfered one byte via spi leaving
the expected input buffer uninitialized. This may lead to the problem that flash
initialization fails because the expected input may be whatever the stack was set
when entering the function. The impact of the bug is somewhat limited tough as the
initialization usually takes place before starting up the rtos and thus is pretty
deterministic. So if the code passed init while testing it should pass init in
production as well.
Serial ports now have a new HW setting called DebugConsole
which can be used to dump internal state to a serial port
for debug.
To enable this feature, you need to:
- make fw_coptercontrol_clean
- make fw_coptercontrol ENABLE_DEBUG_CONSOLE=YES
- configure one of the serial ports as DebugConsole in the GCS
- save settings
- power-cycle your board
Things to note:
- The console is at 57600,8N1.
- This is not currently configurable via the GCS.
- You can only have a single console enabled at a time.