MTP Responder Contribution

Surprise:
compiled with option smallest code and got it working with speed of 600 MHz.
makes little sense to me, except optimization is removing some weird coding (side effects).

Good is that having it working, one could investigate code differences and nail down bug.

Ok that's weird but that its working is good at 600Mhz. But need to figure out the bug - unfortunately wouldn't really know where to start. Have to get to beta test thread and check. Know there was some interesting things at that point.
 
Another Update
suspecting that USB transfer status is not stable at high CPU speeds
I activated alternative code in
file: usb.c
function: usb_transfer_status
changed #if 0 to #if 1

program compiled again with faster and up 600 Mhz and MTP responds correctly

@Paul: would it be wise to keep this always activated ?
 
Was actually looking at usb.c this morning as well and didn't see that. I was focusing on whether there was a need to implement buffers for rx and tx. Also noticed if I remember on USB transfers it disable interrupts for USB1 and wasn't sure if that you impact MTP so just left it since I never played with implementation of USB before.
 
would someone with a fully working setup mind zipping their arduino install and library folder for me to try please?
 
would someone with a fully working setup mind zipping their arduino install and library folder for me to try please?

These are the only three libraries you need:
View attachment USB2-master.zip
View attachment MTP_t4-master.zip

Cant upload sdfat lib but just download the latest SDFat-beta library. Heres my config file:
View attachment SdFatConfig.h

That's all you really need. Basically I just redownloaded all the three libs and edit the sdfat config file per instructions. No changes to usb_desc for sermu
 
thanks, sadly that didnt work, however, i realised i did not have the 10ms delay with the mtpd.loop().
When i put in that delay it works for all but copying too.

As an aside, i cannot get .exists() to function with sdFs, the file always returns as false, any ideas?
 
thanks, sadly that didnt work, however, i realised i did not have the 10ms delay with the mtpd.loop().
When i put in that delay it works for all but copying too.

As an aside, i cannot get .exists() to function with sdFs, the file always returns as false, any ideas?

There is NO delay(10) . (it was for a while for testing only and it does not slow down the transfer)
Advice: please follow procedure indicated by mjs513
if seremu does not work, please follow the instructions to activate MTP_DISK_SERIAL. that is what I'm using
 
You misunderstand. I am not talking about serial or serum.
I mean that for mtp mass storage, if I do not have the 10ms delay, the teensy freezes when I try access MTP drives.
 
You misunderstand. I am not talking about serial or serum.
I mean that for mtp mass storage, if I do not have the 10ms delay, the teensy freezes when I try access MTP drives.

OK, let me be clear.
There are only 2 versions MTP+SEREMU and MTP+SERIAL, both are based on usb1_mtp.c for MTP and usb.c for SEREMU or SERIAL
There is no MTP alone.
As you can see from this thread usb.c needs to be modified for higher speeds to wait for busy status to be cleared. (post #277)
Have you done that?
If it is still blocking, then you should reduce clock.
BUT note, here it is working with MCU speed of 600 MHz
 
Hey @WMXZ, sorry I think there was crossed wires on our communication.
I understand that it needs modification for higher speeds, I was only reporting my personal experience whilst experimenting.
 
Hey @WMXZ, sorry I think there was crossed wires on our communication.
I understand that it needs modification for higher speeds, I was only reporting my personal experience whilst experimenting.
You are getting strange results. Make sure you make the change in usb.c for high speed as you said. Second try it with the MTP_test sketch first before experimenting. If it works with that then it has be something you are doing while experimenting. If you post your test sketch I can give it a try and see if it freezes my teensy. Also I am using the usb_desc as installed by Teensyduino. So if you made any changes to those files you may be running into an issue
 
Another Update
suspecting that USB transfer status is not stable at high CPU speeds
I activated alternative code in
file: usb.c
function: usb_transfer_status
changed #if 0 to #if 1

program compiled again with faster and up 600 Mhz and MTP responds correctly

@Paul: would it be wise to keep this always activated ?

After implementing this change, everything works properly on MTP disk, even with overclocking to 1ghz
 
Yep. Glad you got it working. That change is mandatory otherwise you are stuck with a max of 450Mhz
 
@WMXZ
I'm going through storage.cpp with the good intention to see if I can get it work with SPIFFS on the external Flash. Doing it function by function but running into some things I need some help with understanding.

I got up to the ScanDir function and trying to understand what it's doing. It looks like its being called from StartGetObjectHandles which I would have thought should be returning the file handle? But guess what's confusing me is that you opening and writing records from the functions? Guess I really don't know what i am doing at this point :)

EDIT: Also whats the purpose of parent-child? Is that the equivalent of directory-file?
 
@mjs513,
To be honest, the overall structure of the MTP - storage philosophy was created by the original author.
AFAIK,
there was a basic design criteria: to keep a directory structure a linked records on disk and not in memory.
and to scan directory only on demand. It turned out that Windows scans directories only shallow, while some Linux MTP hosts make a deep scan.
-Anyhow, parent-child-sibling structure form a linked list that correspond to the directory tree.
Each record contain relevant information on file for fast and consistent access to data.

I guess, you have the MTP documentation at hand.

At a point I wanted to implement my own tree-structure, but stopped as I needed quickly something that works.
 
@WMXZ
Began to start sorting things out. But do you have a link for the MTP document.

There are 2 things with SPIFFS - no sub-directories allowed and second I can get the all the file info with a simple list dir command. So guess I got my work cut out for me :)
 
Thanks think I will turn it on to see what its doing and maybe add some more debugging. Also am looking at original implementation in the post #1 just for reference.

Well another time consuming project :)
 
@WMXZ
Just thought I would give you all a bit of an update on this. I have to rework the Storage piece for SPIFFs and am at the point where I can see the files that I created on the FLASH using MTPResponder. Still have work to do on copying and pasting files but most of that is my implementation. Also had to create a couple of additional functions for the SPIFFS calls But just to show you that it can be done here is a screen shot of the SPIFFS directory on the FLASH chip:

Capture.PNG

Hopefully another few days and will have something that works better.
 
Integrating MTP Responder into Data Logger application

I have taken the first steps toward integrating the MTP responder into my generic data logger application. One thing that was apparent early on was that having the data logger and the MTP responder each having their own instance of the SDFat file system was a BAD IDEA. You can imagine that having one instance modifying things like FAT sectors or directory entries while the other may have cached the entries was going to be an issue at some point.

To avoid this potential can of worms, I modified the Storage_init() function in Storage.cpp to accept a pointer to an initialized file system. If the pointer is NULL, the function does sd.begin() as before. The rest of Storage.cpp was modified to use the pointer to the file system. For example:

sd.remove("mtpindex.dat";

becomes:
sdptr->remove("mtpindex.dat");

Thanks to all those who have contributed to the MTP responder, particularly Hubbe and WMXZ, whose code and comments have helped tremendously.

I'm still working out how to keep the data logger code and the MTP responder from stepping on each other's toes, but I'm very encouraged that I can now upload large files from the T4.1 to my PC at about 12MB/second.

I will probably hold off on posting any updates to the generic data logger thread until I better understand all the steps I went through to get to this point. In particular, I had to modify the boards.txt and usb_desc.h files to add the MTP Disk (Experimental) + Serial usb menu entry to enable the responder while retaining Serial output. At this point, I have to use the button press to get code uploaded, as I don't have the HID device enabled. I'm hoping that some of these issues will disappear in a future version of Teensyduino.
 
I have taken the first steps toward integrating the MTP responder into my generic data logger application.

My interest in MTP was exactly this, to be able to offload data from a data logger.
My approach was to either run the logger or the MTP responder
This was easily done by calling mtpd.loop() only when data logger is stopped.
To refresh the MTP responder an unmount/mount cycle was executed on a Linux host (on windows same could be done with device manager)
On every mount the MTP responder deleted/invalidated the mtpindex.dat file.

The way I did it may be done better, but I was struggling with
Code:
  void MTPStorage_SD::OpenIndex() 
  { if(index_) return; // only once
    …
    index_.open((char*)"mtpindex.dat", FILE_WRITE);
    ….
  }

if index_ is a file structure, how can it be zero, so that open is called?

Anyhow,
I use MTP on a T3.6 data logger for over two years now.
 
Back
Top