Support for scripting in flash using littlefs #28724
Conversation
|
Oh excellent!! Have you tried with both NOR and NAND? |
No, still a lot of work to do as there is lots of duplication currently. The code is from @ntamas but needs a bunch of rework to get into master. I have a plan, but the main thing is that it now works for me locally and I know how to proceed from here. |
|
Let me know if I can help with reworking this PR for inclusion. This is something that we at @skybrush-io would also be interested in. |
|
Oh yes, there are a lot small H743 based FPVDrone FCs that only have dataflash. This will be important update to all those (and others). Thanks Andy. |
|
Thanks Andy, this will be most useful! |
|
@ntamas actually it's not so bad - I think what you have done is correct. I really want the block logger to die, but I don't think that's going to be possible on boards with very small flash chips |
|
it will be very interesting to see how this goes! and some stats on storage overhead (and flash cost) would be useful |
|
@andyp1per assuming this works out and testing is good, we should fork littlefs so we point to our own github org, we've tended to regret it when we don't do that |
|
Working quite nicely for me now. Not yet flown it. |
andyp1per
force-pushed
the
pr-littlefs-flash-v3
branch
3 times, most recently
from
01c281d to
424f673
Compare
|
Unfortunately I have yet to be convinced that the architecture of littlefs is suitable for logging, there are a lot of unaddressed issues which particularly bit hard. |
|
Are you experiencing performance issues with LittleFS? If so, how about splitting the flash memory into two partitions, one for logging with the old block logger, and one for storing files (scripts etc) that are assumed to be mostly static? |
That's obviously the fallback, but at an even higher flash cost and would require modifying either lfs or the block logger to cope with some kind of partitioning scheme. I'm going to see what is achievable with LFS first before going that route. |
|
We don't have a block logger based build to check the size against |
andyp1per
force-pushed
the
pr-littlefs-flash-v3
branch
from
bc0fd66 to
92f9c58
Compare
|
Actually this is looking pretty promising |
andyp1per
force-pushed
the
pr-littlefs-flash-v3
branch
from
6c40ab4 to
ed2df88
Compare
There was a problem hiding this comment.
it would be good to know what the flash cost is - is it comparable to FATFS/sdcard? (likely it is)
worth thinking about supporting this in SITL with a command line option to enable instead of normal file system support, like we do for the logger block support in SITL
improve performance by avoiding block validation on writes
provide more meaningful feedback if write() results in ENOSPC address review comments
Avoids issues with (alleged) corruption if writes happen between.
…n littlefs. optimize configured defaults on littlefs and address review comments support lseek() in littlefs in a way that enables terrain to work rename file and directory structures in littlefs code in littlefs glue should be C++ rather than C check for strdup failure on littlefs
add HAL_OS_POSIX_IO to defaults ensure explicitly configured DATAFLASH is prioritized correct inclusion of fat malloc only create storage backups on fatfs
ensure SITL uses ./scripts
Allows future variables to propagate down to board subclasses. only build littlefs when hwdef or board calls for it Avoids issues with build on QURT due to QURT's poor POSIX implementation.
andyp1per
force-pushed
the
pr-littlefs-flash-v3
branch
from
9e9251f to
217821e
Compare
|
yay! |
This completely replaces the flash based support, including logging with a littlefs backend. This results in much more reliable FS access as well as support for things like scripting.
With thanks to @ntamas for the original code