defragster
Senior Member+
Was just posting when crosspost email came in. Will do a sync here. Just gave them a look and they seem like they should build.
It does build - not even a warning
First run the loopCnt was not decrementing again (noted below) ???? It has something to do with 'a'uto formatUnused being sent in ??? Seems to get cleared up after hitting '0' Enter ???? Gave it a glance and not seeing it - it happens when I start a '#' of iterations and then while running interject 'a'uto because I forgot it. Minor bug, '0' seems to resolve it, or perhaps entering 'a' when paused at prompt.
... What I was posting:
Left that running on the MRAM - The ROHM FeRam.
LFSintegrity.INO for some reason running 'k' for thousand iterations stopped decrementing - same with 'h'undred after that was seen ( done while running) ????
Did a '0' to stop, then a couple of single digits and then the 'h' worked and stopped?
So that resulted in a really long running set of MRAM iterations with NO PROBLEMS!
The "#define MAXFILL 2048" leads to skipping file create or extend when reported size left is not more than 2048 bytes. That is enough to prevent failed Err=-28 on write, but led to 75,854 of those writes and instead a file delete typically.
So that is good and in the process 34,670,470 Bytes were written to the 128KB drive, and in verification confirmations 71,820,190 Bytes were read back - while doing the 'occasional' formatUnused(20, res).
As indicated this run is on ROOT and 8 subdirectories and at this paused point this is the case:: "Bytes Used: 123392, Bytes Total:131072"
Bottom line - MRAM and LittleFS in general seems stable with normal operation - including reFormatting during use.
And the $4 FeRAM works as well as the $12 MRAM for 128KB of static, but not fast, storage.
I dropped the 50ns delays to 10 and it worked but no faster, same with the two 250's dropped to 50ns. So they seem okay if they assure function. Still 500 to 600 KB/Sec - into 700's with larger files.
Note: Turning on 'a'uto formatUnused with //ROOTONLY seems to keep the unformatted mess down, but doing ROOTONLY to make bigger files doesn't get called often enough to prevent dirty Blocks.
It does build - not even a warning
First run the loopCnt was not decrementing again (noted below) ???? It has something to do with 'a'uto formatUnused being sent in ??? Seems to get cleared up after hitting '0' Enter ???? Gave it a glance and not seeing it - it happens when I start a '#' of iterations and then while running interject 'a'uto because I forgot it. Minor bug, '0' seems to resolve it, or perhaps entering 'a' when paused at prompt.
... What I was posting:
Left that running on the MRAM - The ROHM FeRam.
LFSintegrity.INO for some reason running 'k' for thousand iterations stopped decrementing - same with 'h'undred after that was seen ( done while running) ????
Did a '0' to stop, then a couple of single digits and then the 'h' worked and stopped?
So that resulted in a really long running set of MRAM iterations with NO PROBLEMS!
Code:
0 dirs with 0 files of Size 0 Bytes
FILE A_file.txt 800
FILE B_file.txt 440
FILE C_file.txt 480
FILE D_file.txt 520
FILE E_file.txt 560
FILE F_file.txt 600
FILE G_file.txt 640
FILE H_file.txt 680
8 dirs with 9 files of Size 47728 Bytes
Total 40 files of Size 103758 Bytes
Bytes Used: 123392, Bytes Total:131072
Loop Count: 162 (#fileCycle=541462), Bytes read 71820190, written 34670470, #Files=40
Free Space Warn COUNT =75854
The "#define MAXFILL 2048" leads to skipping file create or extend when reported size left is not more than 2048 bytes. That is enough to prevent failed Err=-28 on write, but led to 75,854 of those writes and instead a file delete typically.
So that is good and in the process 34,670,470 Bytes were written to the 128KB drive, and in verification confirmations 71,820,190 Bytes were read back - while doing the 'occasional' formatUnused(20, res).
As indicated this run is on ROOT and 8 subdirectories and at this paused point this is the case:: "Bytes Used: 123392, Bytes Total:131072"
Bottom line - MRAM and LittleFS in general seems stable with normal operation - including reFormatting during use.
And the $4 FeRAM works as well as the $12 MRAM for 128KB of static, but not fast, storage.
I dropped the 50ns delays to 10 and it worked but no faster, same with the two 250's dropped to 50ns. So they seem okay if they assure function. Still 500 to 600 KB/Sec - into 700's with larger files.
Note: Turning on 'a'uto formatUnused with //ROOTONLY seems to keep the unformatted mess down, but doing ROOTONLY to make bigger files doesn't get called often enough to prevent dirty Blocks.