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

[Defragster]

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

[Defragster]

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]

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]

Filling a disk now ...

[Defragster]

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]

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]

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]

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]

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]

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]

120 sounds good

[Defragster]

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