Teensyduino File System Integration, including MTP and MSC

Fun Stuff those "directories (111 222 333 )" :)

New version should be out soon - where file content is better serialized, and also for bigger file and deeper dir versions when that trivial case shows as working. Spent a few minutes with 'MakeFiles.ino' and got the 8 byte string blocks sized to 16 bytes to allow inserting File# and Block# into each as they go out.

Glad I started on T_MM with only SD - so the SD can go to a PC for COPY and Verify. Though - that is lots of back and forth ...
 
Actually I think in this case any directory will fail... Especially at root level... More debug output, somtimes does not go boom...

Code:
MTPStorage::copy(20, 4, 0)
** ScanDir called 6 20
  >> 23: 5 0 0 20 0 256 aaa.txt
  >> 24: 5 0 0 20 23 512 bbb.txt
  >> 25: 5 0 0 20 24 768 ccc.txt
MTPStorage::create(4, 0, 1, 222)
    >>(26, /�u Xb! Lj)
    >> After mkdir
OpenFileByIndex failed to open (26):/(� mode: 0
    >> After OpenFileByIndex
MTPStorage::Create /�u Xb! Lj failed to open folder
Create 26 4 0 1 0 0 222
20 -> 26
201136 RESP:2001(RSP:OK)l: 16 T:3e : 1a
As you might notice the 26, ... was creating the full path looks screwed up...
 
Yep I was seeing the same things
Code:
LP:28671 CMD: 101a(COPY_OBJECT)l: 24 T:36 : 16 40001 0
MTPStorage::copy(22, 3, 0)
** ScanDir called 2 22
  >> 23: 1 0 0 22 0 256 aaa.txt
  >> 24: 1 0 0 22 23 512 bbb.txt
  >> 25: 1 0 0 22 24 768 ccc.txt
OpenFileByIndex failed to open (26):/333 mode: 0
MTPStorage::Create /333 failed to open folder
Create 26 3 0 1 0 0 333
CopyFiles 22 -> 26
MTPStorage::copy - From 1: /333/ccc.txt
To   0: /333/ccc.txt
DBG_FAIL: Storage.cpp.937
MTPStorage::copy - From 1: /333/bbb.txt
To   0: /333/bbb.txt
DBG_FAIL: Storage.cpp.937
MTPStorage::copy - From 1: /333/aaa.txt
To   0: /333/aaa.txt
DBG_FAIL: Storage.cpp.937
28681 RESP:2001(RSP:OK)l: 16 T:36 : 1a
LP:28681 CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:37 : 1a dc02 (FORMAT)
with the exception I am not seeing as much garbage as you are showing (this is all with the TMM)
 
Progress on the Copy of directory from one storage to another...

A couple of problems so far:

a) the host may pass us a parent of 0 which means use the root of the storage... Got that.
b) then I was getting garbage names and the like... Turns out that the sketch is using the default (i.e first) store to hold the index list. And in this case on the MMOD that turned out to be the
Program space...
LittleFS_Program lfsProg; // Used to create FS on the Flash memory of the chip
Which we created as: static const uint32_t file_system_size = 1024 * 512;
Size...

Then for some reason the code failed to either write the new records and/or failed to seek back and read the items back in.

When I switched the program to use the built-in SD card it succeeded in creating the destination folder and copy the files over.

So need better way to detect index failure and recovery!

Also with the copy/move commands, the cod may work properly for creating new folders and copy the contents in.
Probably have issues if we do a copy and the destination folder already exists.
What should code do with duplicates and the like...
 
Progress on the Copy of directory from one storage to another...
...
Also with the copy/move commands, the cod may work properly for creating new folders and copy the contents in.
Probably have issues if we do a copy and the destination folder already exists.
What should code do with duplicates and the like...

Progress is Good!

Without a UI to ask about conflicts, assume the user knew what they wanted: Overwrite and replace any duplicates.
 
Moved to the T4.1 just in case with the following config:
Code:
Dump Storage list(11)
store:0 storage:10001 name:RAMindex fs:20006a00
store:1 storage:20001 name:sdio fs:20007054
store:2 storage:30001 name:sd1 fs:20007524
store:3 storage:40001 name:RAM0 fs:20006e5c
store:4 storage:50001 name:RAM1 fs:20006f28
store:5 storage:60001 name:PROGM fs:20006cb8
store:6 storage:70001 name:QSPI fs:20006d84
store:7 storage:80001 name:sflash5 fs:200079f4
store:8 storage:90001 name:sflash6 fs:20007ad0
store:9 storage:a0001 name:WINBOND1G fs:20006ad0
store:10 storage:b0001 name:WINBOND2G fs:20006bc4
In this case the RAMindex is the location of the index file which is PSRAM - 4MB.

So far can copy individual files to the root of any of the other drives without issue. Trying to copy a directory to another fails unless its the RAMindex drive. This also holds true if the index file is on the SD card. I am not having the same luck @KurtE with copying the directories and files.

If I try and copy the files from another drive to the SDIO card like from QSPI to SDIO it causes a reboot but crashreport doesn't show

NOTE: Same thing happened on the Teensy Micromod as well.
 
New serialized content files in folders

Code:
Folders in a ZIP: [ATTACH]26993._xfImport[/ATTACH]
Source for making alternate disk content: [ATTACH]26994._xfImport[/ATTACH]

Files are filled in 16 byte blocks: Like the first "zaaa. 1x F<" or the last "zDDd.3203x2F033<"
> 4 header chars
> a '.'
> 4 digit DEC FILE number
> 'x'
> 5 HEX chars of the block count
> block's end char '<'

If there is a question of corruption the 16 byte groups will match where it was sourced.

Other than the "aaa,bbb,ccc" files from before in folders '111,222,333' , the file names are the number of bytes in the file. The last file block is truncated as needed to meet the file length.
All files are .txt files.
The directories are:
Code:
12/23/2021  05:09 PM    <DIR>          111
12/23/2021  05:09 PM    <DIR>          222
12/23/2021  05:09 PM    <DIR>          333
12/23/2021  05:09 PM    <DIR>          ManyF       // MANY files (1024) in each of 3 directories : '111,222,333' each one byte larger from 400 byte start to 1423 bytes
12/23/2021  05:10 PM    <DIR>          ManyD10   // Dirs D0-D9 are ten deep - each with 5 files of 500 to 2548 bytes
12/23/2021  05:10 PM    <DIR>          ManyD8     // Dirs D0-D7 are eight deep - each with 6 files of 100 to 2100 bytes
12/23/2021  05:10 PM    <DIR>          MoreFD     //  Dirs D0-D3 are four deep - each with 6 files of 125 to 10125 bytes

The last four folders are created with these sketch lines:
Code:
  // EDIT HERE - for more files, Dirs, larger or alternate file sizes
  MakeDataFiles( szStart[1], 1024, 400, 1 );
  MakeDeepDirs( szStart[2], 10, 5, 500, 512 );
  MakeDeepDirs( szStart[3], 8, 6, 100, 400 );
  MakeDeepDirs( szStart[4], 4, 6, 125, 250, 8 ); // LAST PARAM is 'GROW factor' Good for arbitrarily LARGE files
 
Quick update: I am playing with the copy object (directory) stuff and have a wip going on in my mtp_teensy github under a branch debug.

Fixed a couple of bugs, plus working on detecting directory/file already existed and not try to create duplicates.

I think some of it is working better now... Still more testing... Then migrate pieces back in to main...

But may not get much more done today...

Anyway I hope everyone has a nice and safe Christmas

Kurt
 
Quick update: I am playing with the copy object (directory) stuff and have a wip going on in my mtp_teensy github under a branch debug.

Fixed a couple of bugs, plus working on detecting directory/file already existed and not try to create duplicates.

I think some of it is working better now... Still more testing... Then migrate pieces back in to main...

But may not get much more done today...

Anyway I hope everyone has a nice and safe Christmas

Kurt

Just took the latest set of changes for a test run (debug branch) and seems to resolve many problems we were seeing with dups etc. Nice work.
 
Indeed Happy and safe Christmas to all.

I pulled libs after TD 1.56 release and that debug left me with no copies ... but Windows did ask about 'overwriting existing'? Then did nothing?

SerMon list showed files, but Win explorer only showed DIRS.

Got the current WIP: Now I can browse the SD and open files and things look better.

Except the new post #857 data set is "This PC\Teensy\sdio\MoreFD" showing as 'no files' : same for those other new 'TEST" dirs:
Code:
GetObject(29) size: 244

GetObject(29) size: 244
  >>r p:0 l:244
    >>>>w len:256
    >><< Done
66687 RESP:2001(RSP:OK)l: 16 T:9b : 1d
LP:126235 CMD: 1007(GET_OBJECT_HANDLES)l: 24 T:9c : 10001 0 1a
** ScanDir called 0 26
  >> 32: 0 1 0 26 0 0 D0
** ScanDir called 0 26
** ScanDir called 0 26
126243 RESP:2001(RSP:OK)l: 24 T:9c : 10001 0 1a
LP:167644 CMD: 1007(GET_OBJECT_HANDLES)l: 24 T:9d : 10001 0 18
** ScanDir called 0 24
  >> 33: 0 1 0 24 0 0 D0
** ScanDir called 0 24
** ScanDir called 0 24
167652 RESP:2001(RSP:OK)l: 24 T:9d : 10001 0 18
LP:167652 CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:9e : 20 dc02 (FORMAT)
167653 RESP:2001(RSP:OK)l: 20 T:9e : 20 dc02
LP:167653 CMD: 1008(GET_OBJECT_INFO)l: 16 T:9f : 20
167654 RESP:2001(RSP:OK)l: 16 T:9f : 20
LP:213540 CMD: 1007(GET_OBJECT_HANDLES)l: 24 T:a0 : 10001 0 17
** ScanDir called 0 23
  >> 34: 0 1 0 23 0 0 111
  >> 35: 0 1 0 23 34 0 222
  >> 36: 0 1 0 23 35 0 333
** ScanDir called 0 23
** ScanDir called 0 23
213561 RESP:2001(RSP:OK)l: 24 T:a0 : 10001 0 17
 
defragster said:
Indeed Happy and safe Christmas to all.

I pulled libs after TD 1.56 release and that debug left me with no copies ... but Windows did ask about 'overwriting existing'? Then did nothing?

SerMon list showed files, but Win explorer only showed DIRS.

Got the current WIP: Now I can browse the SD and open files and things look better.

Except the new post #857 data set is "This PC\Teensy\sdio\MoreFD" showing as 'no files' : same for those other new 'TEST" dirs:
Happy Christmas and Holidays to you as well.

This is probably going to be a 2 part post. The first is going to be related to the MakeFiles sketch in post #857. Well testing copying files to and from devices and from PC ran into some issues that I am looking at. So decided to test writing the files directly to the SDIO Card and the Win1G/Win512 chip.

1. Writing files to a exFAT formatted SDCard in SDIO worked without an issue all size tests passed.
2. Writing to the Win1G chip had some issues when it was creating the ManyF directory. Basically all the ManyF files resulted in an warning on file size with a >>WRONG<< message: Example:
Code:
Make File:ManyF/111/400.txt	File size=400=0 end: >> WRONG << zaaa.  10x  138<
Make File:ManyF/111/401.txt	File size=401=0 end: >> WRONG << zaaa.  11x  152<
Make File:ManyF/111/402.txt	File size=402=0 end: >> WRONG << zaaa.  12x  16C<
Make File:ManyF/111/403.txt	File size=403=0 end: >> WRONG << zaaa.  13x  186<

All other directories and files were created.
 
Note: I am probably going to rework some of the copy code.

Why memory (stack) hungry, especially with directory copy code...
The function we call in main mtp call: uint32_t MTPStorage::copy(uint32_t handle, uint32_t newStore, uint32_t newParent)
Has two full path names:
Code:
		char oldfilename[MAX_FILENAME_LEN];
		char newfilename[MAX_FILENAME_LEN];
We call of to: bool MTPStorage::CopyFiles(uint32_t handle, uint32_t store, uint32_t newHandle)
Which also has:
Code:
		char oldfilename[MAX_FILENAME_LEN];
		char newfilename[MAX_FILENAME_LEN];
Which if that directory has sub-directories - recursively calls itself again...

Then for each file it calls copy:
Code:
bool MTPStorage::copy(uint32_t store0, char *oldfilename, uint32_t store1, char *newfilename)
{
	const int nbuf = 2048;
	char buffer[nbuf];
	int nd = -1;
That is a lot on the stack...
So I am removing the full path names from the two functions mentioned, going to put then in leaf functions... Can probably reduce to one but will start with two.

Was thinking of having way for copy function to allow it to gain access to the static buffer we have as part of the MTP object and not use stack...
 
That is a lot on the stack...
So I am removing the full path names from the two functions mentioned, going to put then in leaf functions... Can probably reduce to one but will start with two.

Was thinking of having way for copy function to allow it to gain access to the static buffer we have as part of the MTP object and not use stack...
Well that explains quite a bit. Looks like that may the same for MoveDir in storage.
 
Last edited:
KurtE said:
That is a lot on the stack...
So I am removing the full path names from the two functions mentioned, going to put then in leaf functions... Can probably reduce to one but will start with two.

Was thinking of having way for copy function to allow it to gain access to the static buffer we have as part of the MTP object and not use stack...
Well that explains quite a bit. Looks like that may the same for MoveDir in storage.
Forgot to mention that CopyFiles also also 4 Record objects each also has a char name[MAX_FILENAME_LEN];
So trying to reduce those as well
 
Happy Christmas and Holidays to you as well.

This is probably going to be a 2 part post. The first is going to be related to the MakeFiles sketch in post #857. Well testing copying files to and from devices and from PC ran into some issues that I am looking at. So decided to test writing the files directly to the SDIO Card and the Win1G/Win512 chip.

1. Writing files to a exFAT formatted SDCard in SDIO worked without an issue all size tests passed.
2. Writing to the Win1G chip had some issues when it was creating the ManyF directory. Basically all the ManyF files resulted in an warning on file size with a >>WRONG<< message: Example:
Code:
Make File:ManyF/111/400.txt	File size=400=0 end: >> WRONG << zaaa.  10x  138<
Make File:ManyF/111/401.txt	File size=401=0 end: >> WRONG << zaaa.  11x  152<
Make File:ManyF/111/402.txt	File size=402=0 end: >> WRONG << zaaa.  12x  16C<
Make File:ManyF/111/403.txt	File size=403=0 end: >> WRONG << zaaa.  13x  186<

All other directories and files were created.

That 'WRONG' detect/print code was put in because I had a dumb embedded error I had to debug ... glad I left it in!

Again, it was great the SD card was removable for verification - but a real pain when running failed - as I munged one func() for three folders to Many folders - and it was not until I put the SD onto PC and walked the tree to see an error - then having to make another SD card trip back and forth.

Great I posted the source and it works on SD so it could be tested on other media. Hopefully the func()'s and params make sense for customizing size/depth - as is with the series of calls it creates 3203 files in 32 folders with 2.91 MB of data. And only one warning about signed .vs. unsigned compare.

IT"S SNOWING!
 
That 'WRONG' detect/print code was put in because I had a dumb embedded error I had to debug ... glad I left it in!

Again, it was great the SD card was removable for verification - but a real pain when running failed - as I munged one func() for three folders to Many folders - and it was not until I put the SD onto PC and walked the tree to see an error - then having to make another SD card trip back and forth.

Great I posted the source and it works on SD so it could be tested on other media. Hopefully the func()'s and params make sense for customizing size/depth - as is with the series of calls it creates 3203 files in 32 folders with 2.91 MB of data. And only one warning about signed .vs. unsigned compare.

IT"S SNOWING!
Finally snow on Christmas we had a bit of a dusting think it was Wednesday into Thursday morning :)
 
Finally snow on Christmas we had a bit of a dusting think it was Wednesday into Thursday morning :)

... stopped already :( - and not cold enough to lay. COLD coming next week ...

BTW - noted above but " zaaa. 10x 138<"
shows 10 files created and 0x138 sets of 16 bytes written (some truncated for file length) - so max of 4992 bytes written - at that point of failure.
> Obvious reason to fail would be disk space. Could add a .freespace() before and after print. The DIRS and file names could all end up with 64KB blocks of slack/FS overhead.
 
Morning all (at least in my timezone) Playing some more with copy/move code. Also looking at the memory(stack) usage

For copy, I have reduced I think a lot of the stack usage. I now making usage of the Create function we use in SendObject (They send us), which also helps take care of detecting destination already exists. And with the newer stuff I have not posted hopefully when copy directory, both that a directory exists as well as the files under it...

Still more work to do with it, including: still currently using 2K of the stack for reading/writing the file contents... I am thinking to allow it to use the MTP object memory for this.
For T4.x we have a 4K buffer we use for SendObject. Not sure yet for T3.x as there is no such buffer. I might cheat and do a usb_malloc() to get a 64 byte buffer which I free after file copy...

Also the code currently still does not check results of writes, which it should so we might detect we ran out of space...

Now as for MoveObject - A bit more complexity as: the host assumes that the object will retain the same object ID.. i.e. we don't return back the new ID like we do for copy.

Also currently the move code, the top level function has (6 Records each with max path string, and 2 more max path strings on stack... Looking through it now.
 
10 degrees here!! Power loss off and on... Been playing with a POSIX style filesystem based on FS. Had to do some major updates to DIskIOV2 to accommodate stdin, stdout and stderr. I had this working previously with the T3.6, FatFs and newlib. I can now open, close, read and write files on all of FS supported devices available for the T.x using POSIX style file descriptors (FILE *fp). FS device types start at offset 4 and end at offset 33. Offset 3 is free as 0, 1 and 2 are used for stdin, stdout and stderr. I chose modulus 4 for the USB and SD devices as they can have four partitions. The SDIO and SDSPI slot numbers are fixed at 20 and 24 for now as partitioning these devices from what I read is not good but they can be used with 4 partitions.
Still have to setup the rest of newlib and ioctrl functions such as _link, _unlink, _lseek etc... these were working on the T3.6.

Power went out again... Wow, 5th time today. Lasts for 5 seconds then comes back on. (Reset all the clocks again)
Having fun playing with this:)
 
Last edited:
Can't get FILE_WRITE_BEGIN to keep from appending?

Code:
Initializing SD card...initialization done.
Writing to test.txt...done.
test.txt:
testing 1, 2, 3.
testing 1, 2, 3.
testing 1, 2, 3.

Tried this three times with ReadWrite.ino with:
Code:
/*
  SD card read/write
 
 This example shows how to read and write data to and from an SD card file 	
 The circuit:
 * SD card attached to SPI bus as follows:
 ** MOSI - pin 11, pin 7 on Teensy with audio board
 ** MISO - pin 12
 ** CLK - pin 13, pin 14 on Teensy with audio board
 ** CS - pin 4, pin 10 on Teensy with audio board
 
 created   Nov 2010
 by David A. Mellis
 modified 9 Apr 2012
 by Tom Igoe
 
 This example code is in the public domain.
 	 
 */
 
#include <SD.h>
#include <SPI.h>

File myFile;

// change this to match your SD shield or module;
// Arduino Ethernet shield: pin 4
// Adafruit SD shields and modules: pin 10
// Sparkfun SD shield: pin 8
// Teensy audio board: pin 10
// Teensy 3.5 & 3.6 & 4.1 on-board: BUILTIN_SDCARD
// Wiz820+SD board: pin 4
// Teensy 2.0: pin 0
// Teensy++ 2.0: pin 20

[COLOR="#FF0000"]const int chipSelect = 10; Initializes.[/COLOR]
[COLOR="#FF0000"]//const int chipSelect = BUILTIN_SDCARD; FAILS to initialize.[/COLOR]

void setup()
{
 //UNCOMMENT THESE TWO LINES FOR TEENSY AUDIO BOARD:
 //SPI.setMOSI(7);  // Audio shield has MOSI on pin 7
 //SPI.setSCK(14);  // Audio shield has SCK on pin 14
  
 // Open serial communications and wait for port to open:
  Serial.begin(9600);
   while (!Serial) {
    ; // wait for serial port to connect.
  }


  Serial.print("Initializing SD card...");

  if (!SD.begin(chipSelect)) {
    Serial.println("initialization failed!");
    return;
  }
  Serial.println("initialization done.");

  // open the file. 
  myFile = SD.open("test.txt", [COLOR="#FF0000"]FILE_WRITE_BEGIN);[/COLOR]
  
  // if the file opened okay, write to it:
  if (myFile) {
    Serial.print("Writing to test.txt...");
    myFile.println("testing 1, 2, 3.");
	// close the file:
    myFile.close();
    Serial.println("done.");
  } else {
    // if the file didn't open, print an error:
    Serial.println("error opening test.txt");
  }

  
  // re-open the file for reading:
  myFile = SD.open("test.txt");
  if (myFile) {
    Serial.println("test.txt:");
    
    // read from the file until there's nothing else in it:
    while (myFile.available()) {
    	Serial.write(myFile.read());
    }
    // close the file:
    myFile.close();
  } else {
  	// if the file didn't open, print an error:
    Serial.println("error opening test.txt");
  }

[COLOR="#FF0000"]  File root = SD.open("/");
  printDirectory(root, 0); Will not display directory listing.[/COLOR]
 
}

void loop()
{
	// nothing happens after setup
}

void printDirectory(File dir, int numSpaces) {
   while(true) {
     File entry = dir.openNextFile();
     if (! entry) {
       Serial.println("** no more files **");
       break;
     }
     printSpaces(numSpaces);
     Serial.print(entry.name());
     if (entry.isDirectory()) {
       Serial.println("/");
       printDirectory(entry, numSpaces+2);
     } else {
       // files have sizes, directories do not
       unsigned int n = log10(entry.size());
       if (n > 10) n = 10;
       printSpaces(50 - numSpaces - strlen(entry.name()) - n);
       Serial.print("  ");
       Serial.print(entry.size(), DEC);
       DateTimeFields datetime;
       if (entry.getModifyTime(datetime)) {
         printSpaces(4);
         printTime(datetime);
       }
       Serial.println();
     }
     entry.close();
   }
}

void printSpaces(int num) {
  for (int i=0; i < num; i++) {
    Serial.print(" ");
  }
}

void printTime(const DateTimeFields tm) {
  const char *months[12] = {
    "January","February","March","April","May","June",
    "July","August","September","October","November","December"
  };
  if (tm.hour < 10) Serial.print('0');
  Serial.print(tm.hour);
  Serial.print(':');
  if (tm.min < 10) Serial.print('0');
  Serial.print(tm.min);
  Serial.print("  ");
  Serial.print(months[tm.mon]);
  Serial.print(" ");
  Serial.print(tm.mday);
  Serial.print(", ");
  Serial.print(tm.year + 1900);
}

This was with all of the current changes Arduino 1.8.19, TD1.56 and all of Kurt's latest updates. FILE_WRITE_BEGIN will not keep from appending to the file if it exists. Ran into this while mapping POSIX file open flags to FS. Number 2 problem is when I added printDirectory functions to ReadWrite.ino they don't work. They work fine with listfiles.ino. Third problem is I cannot get readwrite.ino to recognize the BUILTIN_SDCARD. It initializes the external SDCARD ok. BUILTIN_SDCARD seems to work with MTP and DiskIOMB.

Maybe I have missed something which is very possible. Can you guy's test this when you have time?
 
Note; the WRITE_BEGIN does not remove previous data...
So after it opens I might do something like: myfile.truncate();

Or sometimes might do this at the end of updating the file...
myfile.truncate(myfile.curPosition());

or something like that
 
Note; the WRITE_BEGIN does not remove previous data...
So after it opens I might do something like: myfile.truncate();

Or sometimes might do this at the end of updating the file...
myfile.truncate(myfile.curPosition());

or something like that

Tried myfile.truncate(myfile.curPosition()); and myfile.truncate(0); without success. When the file is closed it should update the size of data written to the file from the point of the truncated opening of the file. In the case of FILE_WRITE_BEGIN I would think truncate(0) (the default) would start at the beginning of the file and when the file is closed the length of the file should be the size of what was written to the file when closed. It seems like the actual file position is not updated at the closing of the file and therefore the file size is wrong so when you read it back it is the size of the previous write plus the last write. Don't know if that makes sense:)
 
Didn't try that in the MakeFiles.ino - in the event it was re-run on the same media, this was used: if (SD.exists(szPath)) SD.remove(szPath); and myFile = SD.open(szPath, FILE_WRITE);

So that works - but it is the obvious sledgehammer method.

That is repeated three times in MakeFiles, so two of them could be rewritten to use alternate methods to test, if they can be made to work.
 
Sorry late to the party but was sleeping when all this transpired.

Thought FILE_WRTIE_BEGIN was meant to write data from the beginning of the file while FILE_WRITE would append other wise you would need to do what Kurt did.

I ran the readwrite.ino sketch using FILE_WRITE_BEGIN and it seem to be working with the Teensy Micromod. Ran it 3 times as you did along with printing the directory listing (copied from list files):
Code:
Initializing SD card...initialization done.
Writing to test.txt...done.
test.txt:
testing 1, 2, 3.
mtpindex.dat                                        0    14:40  December 27, 2021
111/
  aaa.txt                                         244    09:24  December 25, 2021
  bbb.txt                                         500    09:24  December 25, 2021
  ccc.txt
,,,,
        D3/
          125.txt                                 125    09:25  December 25, 2021
          2125.txt                               2125    09:25  December 25, 2021
          4125.txt                               4125    09:25  December 25, 2021
          6125.txt                               6125    09:25  December 25, 2021
          8125.txt                               8125    09:25  December 25, 2021
          10125.txt                             10125    09:25  December 25, 2021
test.txt                                           18    06:19  December 28, 2021
done!

Ran it on a T4.1 as well with the same results.

Did notice that your printdirectory is different than the version in list files for printtime:
Code:
void printTime(const DateTimeFields tm) {
  const char *months[12] = {
    "January","February","March","April","May","June",
    "July","August","September","October","November","December"
  };
  if (tm.hour < 10) Serial.print('0');
  Serial.print(tm.hour);
  Serial.print(':');
  if (tm.min < 10) Serial.print('0');
  Serial.print(tm.min);
  Serial.print("  ");
[COLOR="#FF0000"]  Serial.print(tm.mon < 12 ? months[tm.mon] : "???");[/COLOR]  Do you have the latest changes to SD - Paul merged all of Kurt's changes in so grab that version.
  Serial.print(" ");
  Serial.print(tm.mday);
  Serial.print(", ");
  Serial.print(tm.year + 1900);
}
 
Thought I would mention that I have been playing with my debug branch of MTP_Teensy: https://github.com/KurtE/MTP_Teensy/tree/debug

With the MoveObject and CopyObject code. There are parts of it that can probably be combined and cleaned up some more but may soon migrate the code back into the main branch:

Found today the copyObject on t3.x did not work as we were not sending back the right size completion packet so it did not have the object id of the new object.

Other things changed include things like:
When we are doing a simple move object on same storage that the rename should handle it, it first tries to rename and only if if is succeeds it then unlinks itself from old parent and link into
new parent. I think this saved by only needing maybe 2 or 3 Record objects instead of 6 or 7...

Also right now I am on T4.x using the large 4k buffer of mtpd object instead of 2k on stack, on t3.x I now do malloc... I was trying the usb_malloc(), but after copy failed I changed to malloc...

I also now use the NewObject method like the SendObject uses to create the folders and directories. This helps handle if there are duplicates...

I also added code to detect a write does not complete the write and error out. I also try to propagate the error up...

Still lots of cases to figure out what could be done. Like if you do a move and 5 files are moved but not 3 others, then should return different return code...

But at least a start...

Anyway if anyone wises to play with it first before I merge back over, that would be great!
 
Back
Top