Open patrickpollet1966 opened 5 years ago
Hi @patrickpollet1966, sorry about late response. littlefs has not been tested on a 16-bit MCU, and I suspect it will take some work to get it running.
If you do get it working, please create a PR!
One issue is my laziness in using ints/unsigneds, especially for loops. You may have some success if you replace all of those with their respective int32_t/uint32_t.
But it may take some work before you have a working filesystem.
Related https://github.com/ARMmbed/littlefs/issues/146
On another hand, reading the file size with lfs_stat show a size of 4, but reading the same size with lfs_file_size atfer opening this file, show 0 ...)
This is expected. The filesystem does not reflect what is written to a file until you call either lfs_file_sync or lfs_file_close. While you are writing to a file, the lfs_t and lfs_file_t see different versions.
When you first open the file, littlefs creates a placeholder of size 0 (there may be a way to work around this, but I haven't been able to implement it yet). This placeholder is what lfs_stat is reporting until you call lfs_file_sync or lfs_file_close. This is also what will be on disk if you lose power.
You can get the size the lfs_file_t sees through the lfs_file_size function. This is because lfs_stat reports what the filesystem sees, whereas lfs_file_size reports what the file sees.
Hopefully that helps clear things up.
@patrickpollet1966, I have positive experience of porting LFSv1.3 to ATmega2560.
Did you use some kind of malloc functions for LFS or you allocate memory pools statically? Can you show a piece of code?
Unfortunately, I have some problems to upgrade existing code to LFSv2.0.3 and up due to strange errors in "file tags" while porting. (#178) And much more memory comsumption, which is critical for me.
I have success on porting LFS 2.2 to Atmega2560. Is it work for you, @patrickpollet1966?
Dear All,
I try for a few days to port littlefs on mega2560.
At first run after a freshly erased flash the "boot_count example" seems to works (the flash is formated, mounted, the file boot_count is created and seems to be written). (i can also said that parsing the root directory show a "boot_cont" file)
But as second run there's an issue at write time (pcache->block == 0xffffffff).
Investigations seems to show that block and pcache->block are different conducting to never flush the cache.
(But there's maybe something else beside that because trying to only read the file written at the first run only read "0". On another hand, reading the file size with lfs_stat show a size of 4, but reading the same size with lfs_file_size atfer opening this file, show 0 ...)
Last detail, i used exactly the same source (and same spi flash) with an arm cortex-m3 (lpc1768) and everything is fine, so there's something wrong with a 8bits proc and not with a 32bits one but i am not able to understand.
Thanks for your help.
Patrick