Development of new filesystem for f7/f12e

the Devo F12E and F7 both have tiny 64kB external flash storage. This flash also has a 4kB sector size. That makes it completely unsuitable for the current FAT filesystem since only ~12 files could be stored on the flash device.

I went looking for a better solution, but was unable to find a filesystem that met all of my criteria. Specifically, I need:
* very low per-file/directory overhead
* low RAM usage (can't keep a whole sector in RAM)
* wear-leveling (can't continually use the same sector for temporary storage during erase)
* small code size

the best solution I came up with was the MicroMonitor TFS: www.umonfw.com/
However, it is not very well documented, and it fails my3rd point above.

In the end I spent the last couple days and developed my own filesystem: DevoFS

It is optimized for very small flash devices, and will not work well on the > 4Mbit flash found in other Walkera devices. So don't expect it to be used in the Devo8 or Devo10. It also comes with the disadvantage that you can't access it with USB (theroetically a FUSE driver could be written, but that wouldn't help on Windows, and I have no inclination to do so)

Currently I am developing it in the devof7 branch. It isn't quite ready, but is passing my basic tests, so I expect to put it on my F7 soon.

The filesystem is log based, which helps with wear leveling. It also does not have a dedicates 'temp' sector, so no single sector will be over-abused. Each file/directory has an overhead f just 15 bytes (11 of which is the file name) so it is well optimized for space, although it does require one sector to be kept free, so the filesystem size is actuallyon 60kB.

Using this, It should be possible to have maybe 4 or 5 protocol modules and maybe 15-20 models installed on the 64kB stock flash (depending on modle complexity). For the F12E, the protoocols will fit on the MCU flash, so we can use the remaining space for bitmaps or more models.

While installing a larger flash (and using FAT) will still be supported, this will enable using Deviation of the F7 and F12E without needing a hardware hack.

Here is the readme:

---

The DevoFS filesystem is designed to provide a filesystem to very small FLASH
memories with large sector sizes (ex 64kB flash with 4k sector-size). It is
optimized for flash layout efficiency over all else.

The only supported file attributes are file/directory bit and file-size. No
other data is stored. **** The maximum file size is 65535 **** (this could be
changed by adding an extra byte to the file-system header)

The file-system is a log-based filesystem with built in wear-leveling.
Sequential read and write speeds will be very fast, however, open and read-dir
functions will be quite slow.

DevoFS will slow down linearly with the number of files present, as well as
with the number of files written since the last compact() event

The filesystem will automatically run compact() when necessary, butit is
recommended to run it more frequently to optimize performance

The filesystem has an overhead of 15 bytes for each file and directory, and does
not require file alignment to sector boundaries. Additionally, one sector must
be left vacant to allow for running the compact operation (unless the equivalent
amount of RAM is available)

A very simple algorithm is used:
* find current filesystem start
- will be sector aligned
- not restricted to the 1st sector. Will move backwards by one sector
every time compact() is run
* read file header (15 bytes)
* use current file-header to identify start of next file-header
* repeat until requested file/directory is found

Support for creating new files or directories is not currently implemented, but
could easily be added in the future. Also, file-size cannot currently be
changed.

For efficiency, it is required that a directory be created before any files that
reside within that directory. The code does not check this condition, and it
leaves the burden to the developer

Reads and writes will automatically be partitioned to sector boundaries so the
sector-id bytes are not inadvertently read

DevoFS layout:

---

The constant values below assume the FLASH resets to 0xff. negate all values if reset is 0x00
sector boundaryfiledirectory
compacting

I think Walkera is entirley focused on the drone market now. They know exatcly how little they need to invest and still provide the needed capabilities.

I don't think I undersrand your question regarding DevoFS. Do you mean how does a user copy models from a PC to the transmitter? I plan to start with a utility that will convert a set of directories into a dfu file that can be uploaded. The next step would be to enhance the deviation-uploader app to allow you to drag-and-drop files on and off it.

I have written a bunch of tests to ensure the devofs file system is working properly. I found several bugs, and now have confidence that all of the basic functions work as intended. I haven't yet tested recovery (what happens if the tx loses power during data compaction?) but other than that everything seems to be working well.

As I mentioned before, the bug issue is how to get a filesystem onto the devof7 in the 1st place. i haven't yet solved that issue.