Reorganize the and optimize the code to avoid redundant code and thus
reduce code size, while making sure to zero-initialize the used areas
on the SD card. These are the "clean" part of this change.
The "dirty" part:
Optimize the FAT16 export code further by introducing small deviations
from the FAT16 specification. These deviations should not be harmful
at all, unless the SD card is used for something requiring the jump
instruction and/or boot code in the boot sector to be valid. This is
typically only required when booting off the filesystem.
After these changes, a considerable reduction in code size can be
observed for sys_controller.elf and sys_onchip_memory2_0.bin:
sys_controller.elf:
text data bss dec hex filename
32392 2936 2652 37980 945c sys_controller.elf
sys_onchip_memory2_0.bin:
size: 35328 bytes
This reduces the cost of the FAT16 export feature to 446 bytes.
Replace an array of const char* literals with a single const char*
literal containing all the messages in the rotating prompt and an
array of alt_u8 containing the offsets of each message within the
literal.
This ends up yielding a larger size reduction than expected, a
healthy 20 bytes, despite a meager 8-byte difference in the size
of local variables and slightly more complex pointer math in
calculating the address of the current message within the string
literal.
The behavior of the menu option was all over the place, and would
easily leave the OSD in a weird state, requiring the user to blindly
do something that completely redraws the OSD.
Fix this by making the behavior similar to that of the userdata import
feature, with the difference of giving a more specific error message
when something goes wrong.
A very simple implementation, as we are very short on remaining
block RAM. Simply blindly copies the entire userdata area to the
SD card. This may subject the SD card to some extra wear, as well
as potentially read-disturb some Flash memory pages, but this would
require more code.
In the Flash info structure, the field containing the end address of
the Flash storage is documented to be non-inclusive.
However, when this field is compared to the end address of a read or
write, which is also non-inclusive, it is considered an error that
these two values match, which is incorrect, as this would error out
on an attempt to fully read/write the last page.
Fix this by simply changing the >= comparison into a > one.
There were a few things wrong with the SD card write implementation:
1. The protocol change regarding the interpretation of offsets
introduced with SDHC cards was not taken into account in the write
path, unlike in the read path.
2. All SPI writes involved in the process were actually issued as reads
due to the use of the SPI_RW() function, the implementation of which
seems to have gone through some churn. Likely just an instance of
bit-rot.
Ari Sundholm