KurtE
Senior Member+
Quick update: I just merged in my experiment branch of MTP_Teensy back into the main branch.
With this, if you are running on T3.5/3.6 or T4.x - that uses the Record block code. I added a simple Memory FileSystem , which can create exactly one file. Sort of like earlier version of Frank's MemoryFile stuff.
Except this one allocated/reallocates the buffer on the fly when needed.
You can tell the storage system to use it by setting the storage to use to index -2...
But the main reason I added it, was I kept running into cases where for example I have a couple of storage units I add to the MTP list. And lets say the first one was my SD Card adapter, and suppose that the slot is empty. And if the user goes and wants to enumerate the 2nd storage, the system would just fail as it could not create the index file.
This delta detects that the storage file was not created and instead creates the index file on this FS...
Which I think is working pretty well. Note: I left in some debug messages for now, that shows when memory is allocated for this file and when it needs to realloc the memory to grow... An interesting thing is that my current configuration with the record blocks code is keeping a cache of 4 blocks in memory already, and I found for example a SD card of 60+ files, that I still did not actually need to allocate the buffer for this memory file.
I also fixed a few other probable bugs in the MTP code while doing this. When we did a format, the code was not telling the host after it completed to do a reset, but we killed our own cache... Now I have the code after the format completes, send the reset device event to host. Also the reset did not properly clear my high water mark for the block file, so could run into some issues.
There are still some issues that we need to investigate, that we have seen while testing some of this code.
As part of the testing I added the mtp_sd_debug sketch for now... Also it was extended to have 2 SD drives defined.
a) Format of SD cards, does not always properly reset the MTP stuff in some cases. And we see something like:
Which is wrong, but other times it would look correct:
After @mjs513 found the issue with two 64MB SD cards, but would not replicate on my machine where I was running a 32mb or 16 or 8mb, I tried a 128MB SD in the SDIO and I showed the failure state.
Best Guess Issue: Our code in SD.format() has code in it to try to restart the file system with the new setup. And my guess is that this is not working fully for ExFat on SDIO...
b) Card detection - I am not sure if it is currently not working properly, ie. maybe some parts not implemented with the updated SDFat and/or we are not calling anything to see...
Will try adding code to detect this tomorrow... But I know we would like to have this done automatically without sketch code having to do the checking and...
That is all for now
With this, if you are running on T3.5/3.6 or T4.x - that uses the Record block code. I added a simple Memory FileSystem , which can create exactly one file. Sort of like earlier version of Frank's MemoryFile stuff.
Except this one allocated/reallocates the buffer on the fly when needed.
You can tell the storage system to use it by setting the storage to use to index -2...
But the main reason I added it, was I kept running into cases where for example I have a couple of storage units I add to the MTP list. And lets say the first one was my SD Card adapter, and suppose that the slot is empty. And if the user goes and wants to enumerate the 2nd storage, the system would just fail as it could not create the index file.
This delta detects that the storage file was not created and instead creates the index file on this FS...
Which I think is working pretty well. Note: I left in some debug messages for now, that shows when memory is allocated for this file and when it needs to realloc the memory to grow... An interesting thing is that my current configuration with the record blocks code is keeping a cache of 4 blocks in memory already, and I found for example a SD card of 60+ files, that I still did not actually need to allocate the buffer for this memory file.
I also fixed a few other probable bugs in the MTP code while doing this. When we did a format, the code was not telling the host after it completed to do a reset, but we killed our own cache... Now I have the code after the format completes, send the reset device event to host. Also the reset did not properly clear my high water mark for the block file, so could run into some issues.
There are still some issues that we need to investigate, that we have seen while testing some of this code.
As part of the testing I added the mtp_sd_debug sketch for now... Also it was extended to have 2 SD drives defined.
a) Format of SD cards, does not always properly reset the MTP stuff in some cases. And we see something like:
Which is wrong, but other times it would look correct:
After @mjs513 found the issue with two 64MB SD cards, but would not replicate on my machine where I was running a 32mb or 16 or 8mb, I tried a 128MB SD in the SDIO and I showed the failure state.
Best Guess Issue: Our code in SD.format() has code in it to try to restart the file system with the new setup. And my guess is that this is not working fully for ExFat on SDIO...
b) Card detection - I am not sure if it is currently not working properly, ie. maybe some parts not implemented with the updated SDFat and/or we are not calling anything to see...
Will try adding code to detect this tomorrow... But I know we would like to have this done automatically without sketch code having to do the checking and...
That is all for now