- fix null pointer dereference in VFS when VFS implementations are added
and removed in different order
- vfs_fat_sdmmc, vfs_fat_spiflash: pass correct drive to mkfs
(previously it would always do mkfs in the first drive)
- add test case
vfs_fat_link opened two files to perform copy operation. File structures
were allocated on the stack. When _MAX_SS setting was increased in
ffconf.h due to wear levelling feature, the size of these structures
increased to ~4k each (~8k total). This exceeds stack size allocated for
tasks in most typical cases.
This change makes file structures dynamically allocated.
Originally, prepend_drive_to_path was designed to be a macro, and it
modified local path variables to point to a temporary buffers.
When it was converted into a function, modification to path variables
were no longer visible outside of this function.
In addition to that, prepend_drive_to_path allocated 2k bytes on the
stack for temporary path buffers. This is replaced with path buffers
allocated as part of vfs_fat context object. Locking is added around
parts of code which use these temporary buffers.
Additionally, _lock member of vfs_fat_ctx_t was placed after the
variable-sized files array, which caused the first entry in the
array to be never used. This change fixes the order of members
and adds comments.
wear levelling
This MR adds wear levelling component. It presents an interface similar to the interface of spi_flash and esp_partition. Inside, it stores data inside a partition to in a way that reduces worst case number of erase cycles for any given sector.
Also included are APIs similar to the ones provided for SDMMC to mount FAT filesystem on top of the wear levelling partition. A simple example shows how this API can be used.
Ref TW10338.
See merge request !567
Failure to call f_mount(NULL,...) makes FATFS attempt to clean up the old
FS object upon next mount. If previous mount operation has failed, some
parts of FS object may not be fully initialized, which will cause errors
(such as attempting to delete a mutex which wasn’t allocated).
FATFS enable support for multiple drives
Current implementation has drive numbers and paths hardcoded to support
only one FATFS drive. Arduino has it's own SPI driver to allow
compatibility and flexibility. With the MR it is possible to have up to
```_VOLUMES``` drives connected (SPI, SDMMC and others) at the same
time and accessed through VFS
See merge request !478
Current implementation has drive numbers and paths hardcoded to support
only one FATFS drive. Arduino has it's own SPI driver to allow
compatibility and flexibility. With the MR it is possible to have up to
```_VOLUMES``` drives connected (SPI, SDMMC and others) at the same
time and accessed through VFS
