-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for scripting in flash using littlefs #28724
base: master
Are you sure you want to change the base?
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. |
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 |
bc0fd66
to
92f9c58
Compare
Actually this is looking pretty promising |
6c40ab4
to
ed2df88
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
optimize free space when using littlefs
use correct read status for nor flash implement format on littlefs optimize device calls in littlefs flash usage check for fileops allowed in littlefs littlefs optimization and support for mtime
99fcb68
to
ea198c4
Compare
I've added SITL support, but can't get it to work. It seems there are some issues with the filebd provider and littlefs provides no working examples. There is an open issue asking how to make it work. A project for someone else in the future maybe :) |
[submodule "modules/littlefs"] | ||
path = modules/littlefs | ||
url = https://github.com/ArduPilot/littlefs.git |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would much prefer to just vendor the two relevant files. Git submodules are always a pain and adding another means constantly making sure it's updated or removed when switching branches...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really excited to see this; sorry for not properly testing yet. Glad my vague memories of littlefs were helpful! Some miscellaneous notes.
Is this meant to be mutually exclusive with FATFS support? Could a board have both NAND/NOR and SD?
Also a new littlefs version 2.10 just came out.
#ifndef AP_TERRAIN_AVAILABLE | ||
// enable terrain only if there's an SD card available: | ||
#define AP_TERRAIN_AVAILABLE HAL_OS_FATFS_IO | ||
#define AP_TERRAIN_AVAILABLE (HAL_OS_FATFS_IO || (HAL_OS_LITTLEFS_IO && (BOARD_FLASH_SIZE>1024))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is LittleFS big enough for a meaningful amount? Is it okay with the terrain access patterns? Is there a need to consume the flash before we are sure it is useful?
@@ -56,6 +56,14 @@ extern const AP_HAL::HAL& hal; | |||
#define HAL_LOGGER_ARM_PERSIST 15 | |||
#endif | |||
|
|||
#ifndef HAL_LOGGER_MIN_MB_FREE | |||
#if AP_FILESYSTEM_LITTLEFS_ENABLED | |||
#define HAL_LOGGER_MIN_MB_FREE 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably needs to be bigger so that a meaningful amount can be logged. Also to match the parameter range annotation.
@@ -980,6 +985,11 @@ void AP_Logger_File::io_timer(void) | |||
write_fd_semaphore.give(); | |||
return; | |||
} | |||
|
|||
#if AP_FILESYSTEM_LITTLEFS_ENABLED && CONFIG_HAL_BOARD != HAL_BOARD_SITL | |||
bool sync_block = AP::littlefs().sync_block(_write_fd, _write_offset, nbytes); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be done later, but it would be nicer to have a bytes_until_sync
method on every filesystem, coupled with some logic to sync after a minimum number of bytes logged.
I would prefer not to add another singleton.
the best strategy for minimizing corruption on microSD cards | ||
seems to be to write in 4k chunks and fsync the file on each | ||
chunk, ensuring the directory entry is updated after each | ||
write. | ||
fsync on littlefs is extremely expensive (20% CPU on an H7) and not | ||
required since the whole point of the filesystem is to avoid corruption |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs updating/combining.
@@ -125,7 +129,11 @@ class AP_Logger_File : public AP_Logger_Backend | |||
// data and failures-to-boot. | |||
uint32_t _free_space_last_check_time; // milliseconds | |||
const uint32_t _free_space_check_interval = 1000UL; // milliseconds | |||
#if AP_FILESYSTEM_LITTLEFS_ENABLED | |||
const uint32_t _free_space_min_avail = 4096; // bytes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably need more on NAND.
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