Paul and all,
As @mjs513 mentioned, we have been testing out lots of the LittleFS versions, as well as some SD card stuff. And as mentioned doing most of it with T4 and T4.1 as to compare locked version versus unlocked...
I have also done a little now with T3.6, as a quick and dirty sanity test to make sure our updates to FS two classes compiles and the like.
I used one of @mjs513 sketches that does do a little FS on several different media, including the Memory board that Paul built with 4 memories. As well as an SD Card connected to pin 8...
It built and runs.
Ran into a few interesting things.
A couple of times, I receive the message in the build area, about not being able to open the port... Something like reporting ready before it was...
Also had issue with one SDCard that this sketch could not open. Also the listfiles SD example could not open...
But then I ran the SD example: SDFat_usage and it appeared like it worked... I then took card over to PC, which looked ok, copied a few more files to it...And then brought back to T3.6 and it liked the cared then...
Probably some hiccup like corrupted. Or maybe it does not like a Card with nothing on it... Will play some more.
LittleFS_RAM ... So far I am only using this mostly for test cases and I can see if I want a quick and dirty drive for MTP... sometimes persist/never-persist. Probably something to discuss after the release cycle...
But maybe the right answer for this is to make two different classes for it... That is if you want you can create something like: LittleFS_RAMPERSIST... or some such name.
But since it is setup to not persist, wondering if this code within the class is needed
Code:
static int static_sync(const struct lfs_config *c) {
if ( c->context >= (void *)0x20200000 ) {
//Serial.printf(" arm_dcache_flush_delete: ptr=0x%x, size=%d\n", c->context, c->block_count * c->block_size);
arm_dcache_flush_delete(c->context, c->block_count * c->block_size );
}
return 0;
}
Also wondering how often it is called. That is, is this called every time LittleFS writes out a block of memory? Or when file closed...
What overhead does this give us: That is if I am reading this right, if I have a T4.1 with an 8MB SRAM on it with LittleFS, this will call the arm_dcache_flush_delete on the whole 8mb range, so
the loop in the call will loop 262144 times... So hope not called often. Also not sure why it does flush_delete? So the next memory reads in LittleFS will then have to fetch back from real memory.
Anyone bench marked this to see if any differences?
Just wondering
EDIT: Tried with T4.1... Created RAM of 4mb... so far working... Calls static_sync reasonably infrequent. I built it with MTP... When I copied files to it maybe twice for the file... Actually maybe one per file plus one for index...
So for side by side compare use bool bPrintExtra = true; to see the raw numbers.
Originally Posted by KurtE
