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
andyp1per
force-pushed
the
pr-littlefs-flash-v3
branch
from
d13260d to
97e57c2
Compare
andyp1per
force-pushed
the
pr-littlefs-flash-v3
branch
2 times, most recently
from
22d62f5 to
7b5a799
Compare
|
Please consider this alternate approach for locking, based on the "ensure sitl uses ./scripts" commit: cc679cc...tpwrules:ardupilot:xpr/littlefs-alt It's two code lines and avoids touching the rest of the code. It should be simple to remove later if and when the underlying issue is fixed as well. Did some more testing and it all still looks good. I can't crash the board and scripting restart in flight works properly. |
Avoids issues with (alleged) corruption if writes happen between.
andyp1per
force-pushed
the
pr-littlefs-flash-v3
branch
from
659959d to
2a94fb4
Compare
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