Sorry, my brain is sort of toast for today... So will try to give some more complete answers on some of this stuff tomorrow.
Format timing... I was playing around with some of the support for this today. I was trying to get to the point where in most cases the Forrmat starts, and we wait until completion and then we send the response to the host saying yep we are done... On most drives this is working OK.
Issue however is if it takes greater than time X, MTP will fail and nothing else works... So code is trying by starting up an Interval Timer, than start the format.
Then the IT checks to see if any pending messages are received, it will then try to respond with I am busy... Mentioned this before.
Addition however is that it then checks to see if Time X has occurred since I started the format, in which case it tries to send the response of I am done (More specific MTP_RESPONSE_OK)
That I tried to get to post from the IT... I am hoping that I can get it to send this, at which time the Host is free to send new messages, which I again will try to say I am busy.
Problem is it does not appear to be working fully. I do get the timeout, and I do look like I send a response back to host, that appears like the normal response like if the format had ended on time...
But in this case the host does end the Format busy dialog and say that the format failed... So something wrong... And even after the format completes which may be awhile, nothing works....
Note: put the MTP_Teensy changes in a WIP branch... In case anyone wishes to look before I get back to it in the morning.
One of the main things with MTP is everything is transactional. That is if for example if the user drops a 3mb image onto the storage, it will send a SendObjectInfo message, then followed by the whole set of bits... So there is no chance of any additional status or messages from the host until the whole 3MB has been sent and we have replied to the message.
Side note: I am thinking I may need to try an IntervalTImer approach to the SendObject as to hopefully allow us to pace the reading in of data to keep the host happy, especially when we do writes to some LittleFS storages which can take a long long time.
USB stuff more tomorrow.
PFSLib stuff versus FSLib stuff - Will need to refresh on all of it. But If I remember correctly for example with your current SD.format() code, it is using the SDFat FSLib (actually then to Fatlib and ExFatLib) format functions.
Will suppose you pop in a nice shiny SDCard setup to use with an RPI. There are multiple partitions on this, including a small Fat partition and then most a Linux Format. With SDFat code, if I remember correctly and my few minutes of checking out the SD library usage, I believe that we simply pass in the BlockDevice and this format code will wipe the entire SDCard clean, ie. it cares less about what is on the MBR...
I believe the code in PFSLib is setup to be able to understand the MBR record and only format within an actual Partition. This is obviously needed for MSC like drives, but maybe needed for SDcards for the reasons I just mentioned. Sort of the difference on windows from using Windows Format a drive which only formats that specific partition versus SDFormater app, which blows away everything... Both have their purposes.
Other things we have played with and would really like to address is Fat32 used/Free space. Several postings about this by Mike, and wwatson and myself on this.
What I would like to see is some ability to get this number without taking seconds...
Couple of different partial approaches:
a) Read and update the Information sector: Which has a guess of how much space is free on disk... (
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FS_Information_Sector)
This is completely ignored by Fatlib, except to write out the default one when formatted. Would be good if we read this and at different points updated it, with at times maybe doing some version of background read of fat and generate...
b) I get the impression that ESP32 has an option (default turned off I think), that says as an estimate return back simply the last cluster allocated as an estimate. It will be off as probably some earlier custers were freed, but maybe good enough up till a point.
c) When we do want a better update would be nice if we could somehow read each cluster in the background when the SD was not busy, and generate the count. Probably some issues with suppose we have read half it in and then sketch decides to allocate 50 clusters. What now? do we know or want to know if the new allocations were below or above how far we processed? And how accurate in most cases do we need. That is if my 32gb card is 95% empty do I care if actually it is 96%...
I know there is probably other stuff but ...