search

PaulStoffregen / LittleFS

75 stars 20 forks source link

Limit progressChar SPEW chars - assuming .block_count is a large number #5

Closed Defragster closed 3 years ago

Defragster commented 3 years ago

Only print the progressChar every 1/40th of the media

Defragster commented 3 years ago

tested QSPI, SPI, RAM '.' chars stay on screen limited to 40, but show progress

LittleFS_Program Very fast since it is already formatted

ran sketch a bit then llformat again and it did slow where it was formatting

PaulStoffregen commented 3 years ago

Before I merge this, have you tried completely filling a 16 MByte chip with (large) files before doing the low level format? The printing goes much faster when the majority of the sectors are already blank and don't require erase time. Consider the Winbond datasheet says the max erase time is 0.4 seconds. In the unlikely case a chip actually erased that slowly, wouldn't this change cause a (edit) 40 second wait between each character? Even if each sector takes the normal ~40ms, when there are 4096 sectors this prints about every 1/100th sector. Please give it a try with a completely-full-with-large-file test and see if you're happy with the printing speed.

Defragster commented 3 years ago

Filling a disk now ...

Defragster commented 3 years ago

Running and not out of space - but anything FREE has been written in: Total 705 files of Size 13965000 Bytes Bytes Used: 15450112, Bytes Total:16777216 Loop Count: 20 (#fileCycle=5925), Bytes read 149734100, written 58843000, #Files=705

Doing 'F"ormat - lowLevel takes :: 1min 46 sec

So 40 Chars in 96 seconds means 2.4 secs each on average

I tapped the LAP button on a series of 8 and they were ~2.57

And I count 41 dots.

Defragster commented 3 years ago

Doing Repro on SPI now ... took longer to fill - about 2X

Total 726 files of Size 15141000 Bytes Bytes Used: 16654336, Bytes Total:16777216

 Loop Count: 20 (#fileCycle=5176), Bytes read 116625000, written 51623000, #Files=726

SPI format is longer too 5:48 or 348 seconds ... 8.7 seconds each for 40 dot chars. On the same chip ... That 9 secs matches the lap times I did between some dots. you could bump the 40 up if 9 secs/dot is too long ... but having it violently scroll off the screen isn't helpful.

PaulStoffregen commented 3 years ago

Maybe 120 to 200 dots would be better? Ideally we should have 1 dot print every 1-2 seconds.

Also keep in mind these times are far from the worst case. Other chips could be faster, but could also be much slower according to the Winbond specs.

Defragster commented 3 years ago

Ick! Not all SerMon's JUMP to EOL as it grows ... TyComm just adds a scroll bar so then no feedback at all it what I initially saw

Is a newline every 'x' chars allowable?

Defragster commented 3 years ago

I have a stuffed full disk now ... just got err -28 'no space left'

I suppose 120 could fit on most screen lines well enough?

Defragster commented 3 years ago

Added a timer to CMDLine so I don't have to stare at dots or miss the end ... changed to 120 - lap times on them 2.9 secs.

Odd the SPI format is 3X slower than same chip QSPI ? Or is it?

Came back - according to the timer that is probably right on first try it took 9.52 minutes - or 4.76 secs /dot with 120 dots ... with 5 dots off the side of SerMon, that would be 27 off the landscape 2nd screen if left frame wasn't hidden. Font is not proportional.

How about 300 dots with \n every 100? or 320 with \n every 80?

PaulStoffregen commented 3 years ago

120 sounds good

Defragster commented 3 years ago

PR should be edited ... and tested : https://forum.pjrc.com/threads/58033-LittleFS-port-to-Teensy-SPIFlash?p=260027&viewfull=1#post260027