@KurtE - Could I talk you into creating another branch from the large_files branch? I'll use it to do the stuff I was planning before the chip shortages hit. I normally use only the simple git command and github website, so syncing back to your repository will be much simpler (for me) if the branch starts created on your repository.
Sorry, I took yesterday late afternoon and evening off. I created: pauls_branch
I hear you about git commands. These days I normally do most stuff using the github desktop. Which you can now install on linux as well.
Commands to install GitHub Desktop on Ubuntu 24.04, 22.04, or 20.04 via multiple methods: APT PPA, .deb installation, or Flatpak via Flathub.
linuxcapable.com
I even have it installed on my RPI5.
Note: yesterday I pushed up some new versions of the sendObject and getObject - that is #if on a #define in the file as well as only
on T4.x. It uses the 4k static buffer (disk_buffer_) we had defined for T4.x but was not in use. With this:
The sending or receiving a 5GB file went from > hour to about 10 minutes. It would need lots more testing, before merging into main...
FS is meant to abstract the filesystem, so adding this sort of API pretty much goes against the primary purpose of FS.
Yes and No... In the same way why does the SD library allow you access to SDFat?
But here are some of the things that code like MTP might want to know about the underlying file system.
a) cluster size - probably not the best name, but more like preferred write size. That is 4K works a lot better on many fat systems than 512 bytes, but littleFS maybe not so much.
b) Max file name length
c) Max file size
...
Alternative to this is to allow some form of callouts, to the sketch that can influence such things.
Indeed, and my main goal before merging this into the core library is the trade-off between optimizing the transfer performance versus blocking the user's application. As currently implemented, a call to MTP.loop() can take many seconds or even minutes if the host wants to transfer a large file. I'm going to restructure the code as a state machine, so each call to MTP.loop() moves at most 1 more block.
Sometimes it is hard to find the right tradeoffs, as each of us may have different priorities for different things in their sketch. For example, someone who plugs in their Teensy to a PC to download their log files may want that done as fast as possible, as to not have to wait around for a long period of time, whereas someone else, may simply want to copy a new song to their jukebox app and not want it to interfere listening to their current music.
That is where I really wish we had some form of tasking, where one could set the priorities of each task, in much the same way one can now set
the priority of different interrupts....
Now back to playing... And merging