MTP Responder Contribution

@WMXZ - Thanks - understood - But I mention that as you mentioned you experimented with event stuff there, and so I am playing with try to see if I can get any events stuff at all responding on T4.1...

So just trying to see what you had and go from there.

Thanks again.
 
Afternoon all (or time in your area...)

I have been sort of hacking in USB2 and MTP libraries to see if I can get any hint of events...

Not sure what all I am missing... But some of the stuff I have been playing with:
USB2 library (USB1 object). Specifically usb1_mtp

Updated the configure:
Code:
void usb_mtp_configure(void)
{
	digitalWriteFast(33, HIGH);

	printf("usb_mtp_configure\n");
	memset(tx_transfer, 0, sizeof(tx_transfer));
	memset(rx_transfer, 0, sizeof(rx_transfer));
	memset(rx_event_transfer, 0, sizeof(rx_event_transfer));
	//memset(tx_event_transfer, 0, sizeof(tx_event_transfer));
	tx_head = 0;
	rx_head = 0;
	rx_tail = 0;
	usb_config_tx(MTP_TX_ENDPOINT, MTP_TX_SIZE, 0, tx_event);
	usb_config_rx(MTP_RX_ENDPOINT, MTP_RX_SIZE, 0, rx_event);

	// Not sure if you do two calls here for this type? .
	usb_config_rx(MTP_EVENT_ENDPOINT, MTP_EVENT_SIZE, 0, rx_event_event);
	//usb_config_tx(MTP_EVENT_ENDPOINT, MTP_EVENT_SIZE, 0, tx_event_event);

	//usb_config_rx(MTP_RX_ENDPOINT, MTP_RX_SIZE, 0, NULL); // why does this not work?
	int i;
	for (i = 0; i < RX_NUM; i++) rx_queue_transfer(i);
	digitalWriteFast(33, LOW);

	// Lets do eents
	usb_prepare_transfer(rx_event_transfer + 0, rx_event_buffer, MTP_EVENT_SIZE, MTP_EVENT_ENDPOINT);
	usb_receive(MTP_EVENT_ENDPOINT, rx_event_transfer + 0);

}
Note This is in my multiple RX transfer branch.

I added the eventsend/receive functions from USB2 part although modified to get rid of the 2... And have an RX event
I wanted to add Serial.print statements out of event to see if I got anything, but this is a .c file so added a .cpp file with .c linkage functions to do some printing.
Was not sure if calling the usb_serial... write like functions would work in this case.
If anyone is interested in the WIP this is up at: https://github.com/KurtE/USB2/tree/WIP_USB1_multi_transfers

Now back in MTP project Wondered about the different debug messages plus what all of the darn messages at start off like 1002 what is this...
So I hacked it up and put in a list of textual names for the ones that I have seen so now the output looks more like:

Code:
Setup done
1002 16 1 0: 1 dc01 205d385b - MTP_OPERATION_OPEN_SESSION
2001 16 3 0: 1 dc01 205d385b - MTP_RESPONSE_OK
1001 12 1 1: 2 dc07 703 - MTP_OPERATION_GET_DEVICE_INFO
2001 12 3 1: 0 dc07 703 - MTP_RESPONSE_OK
1014 16 1 2: d402 0 62203428 - MTP_OPERATION_GET_DEVICE_PROP_DESC
2001 16 3 2: d402 0 62203428 - MTP_RESPONSE_OK
1004 12 1 3: 1 dc0b 73656c75 - MTP_OPERATION_GET_STORAGE_IDS
2001 12 3 3: 1 dc0b 73656c75 - MTP_RESPONSE_OK
1005 16 1 4: 1 dc41 53525454 - MTP_OPERATION_GET_STORAGE_INFO
2001 16 3 4: 1 dc41 53525454 - MTP_RESPONSE_OK
1005 16 1 5: 2 dc44 20223636 - MTP_OPERATION_GET_STORAGE_INFO
2001 16 3 5: 2 dc44 20223636 - MTP_RESPONSE_OK
1005 16 1 6: 3 dc03 49465f4d - MTP_OPERATION_GET_STORAGE_INFO
2001 16 3 6: 3 dc03 49465f4d - MTP_RESPONSE_OK
1005 16 1 7: 4 96126100 20201000 - MTP_OPERATION_GET_STORAGE_INFO
2001 16 3 7: 4 96126100 20201000 - MTP_RESPONSE_OK
1005 16 1 8: 5 dc01 205d385b - MTP_OPERATION_GET_STORAGE_INFO
2001 16 3 8: 5 dc01 205d385b - MTP_RESPONSE_OK
9801 16 1 9: 3000 dc07 703 - MTP_OPERATION_GET_OBJECT_PROPS_SUPPORTED
2001 16 3 9: 3000 dc07 703 - MTP_RESPONSE_OK
9801 16 1 10: 3001 0 62203428 - MTP_OPERATION_GET_OBJECT_PROPS_SUPPORTED
2001 16 3 10: 3001 0 62203428 - MTP_RESPONSE_OK
1007 24 1 11: 2 0 ffffffff - MTP_OPERATION_GET_OBJECT_HANDLES
2001 24 3 11: 2 0 ffffffff - MTP_RESPONSE_OK
9803 20 1 12: b dc02 53525454 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 12: b dc02 53525454 - MTP_RESPONSE_OK
9802 20 1 13: dc03 3000 20223636 - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 13: dc03 3000 20223636 - MTP_RESPONSE_OK
9803 20 1 14: b dc03 49465f4d - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 14: b dc03 49465f4d - MTP_RESPONSE_OK
9802 20 1 15: dc04 3000 20201000 - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 15: dc04 3000 20201000 - MTP_RESPONSE_OK
9803 20 1 16: b dc04 205d385b - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 16: b dc04 205d385b - MTP_RESPONSE_OK
1008 16 1 17: b dc07 703 - MTP_OPERATION_GET_OBJECT_INFO
2001 16 3 17: b dc07 703 - MTP_RESPONSE_OK
9802 20 1 18: dc01 3000 62203428 - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 18: dc01 3000 62203428 - MTP_RESPONSE_OK
9803 20 1 19: b dc01 ffffffff - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 19: b dc01 ffffffff - MTP_RESPONSE_OK
9802 20 1 20: dc07 3000 53525454 - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 20: dc07 3000 53525454 - MTP_RESPONSE_OK
9803 20 1 21: b dc07 20223636 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 21: b dc07 20223636 - MTP_RESPONSE_OK
9802 20 1 22: dc41 3000 49465f4d - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 22: dc41 3000 49465f4d - MTP_RESPONSE_OK
9803 20 1 23: b dc41 20201000 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 23: b dc41 20201000 - MTP_RESPONSE_OK
9802 20 1 24: dc44 3000 205d385b - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 24: dc44 3000 205d385b - MTP_RESPONSE_OK
9803 20 1 25: b dc44 703 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 25: b dc44 703 - MTP_RESPONSE_OK
9803 20 1 26: a dc02 62203428 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 26: a dc02 62203428 - MTP_RESPONSE_OK
9803 20 1 27: a dc03 ffffffff - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 27: a dc03 ffffffff - MTP_RESPONSE_OK
9803 20 1 28: a dc04 53525454 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 28: a dc04 53525454 - MTP_RESPONSE_OK
1008 16 1 29: a dc07 20223636 - MTP_OPERATION_GET_OBJECT_INFO
2001 16 3 29: a dc07 20223636 - MTP_RESPONSE_OK
9803 20 1 30: a dc01 49465f4d - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 30: a dc01 49465f4d - MTP_RESPONSE_OK
9803 20 1 31: a dc07 20201000 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 31: a dc07 20201000 - MTP_RESPONSE_OK
9803 20 1 32: a dc41 205d385b - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 32: a dc41 205d385b - MTP_RESPONSE_OK
9803 20 1 33: a dc44 703 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 33: a dc44 703 - MTP_RESPONSE_OK
9803 20 1 34: 9 dc02 62203428 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 34: 9 dc02 62203428 - MTP_RESPONSE_OK
9803 20 1 35: 9 dc03 ffffffff - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 35: 9 dc03 ffffffff - MTP_RESPONSE_OK
9803 20 1 36: 9 dc04 53525454 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 36: 9 dc04 53525454 - MTP_RESPONSE_OK
1008 16 1 37: 9 dc07 20223636 - MTP_OPERATION_GET_OBJECT_INFO
2001 16 3 37: 9 dc07 20223636 - MTP_RESPONSE_OK
9803 20 1 38: 9 dc01 49465f4d - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 38: 9 dc01 49465f4d - MTP_RESPONSE_OK
9803 20 1 39: 9 dc07 20201000 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 39: 9 dc07 20201000 - MTP_RESPONSE_OK
9803 20 1 40: 9 dc41 205d385b - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 40: 9 dc41 205d385b - MTP_RESPONSE_OK
9803 20 1 41: 9 dc44 703 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 41: 9 dc44 703 - MTP_RESPONSE_OK
9803 20 1 42: 8 dc02 62203428 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 42: 8 dc02 62203428 - MTP_RESPONSE_OK
9803 20 1 43: 8 dc03 ffffffff - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 43: 8 dc03 ffffffff - MTP_RESPONSE_OK
9803 20 1 44: 8 dc04 53525454 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 44: 8 dc04 53525454 - MTP_RESPONSE_OK
1008 16 1 45: 8 dc07 20223636 - MTP_OPERATION_GET_OBJECT_INFO
2001 16 3 45: 8 dc07 20223636 - MTP_RESPONSE_OK
9803 20 1 46: 8 dc01 49465f4d - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 46: 8 dc01 49465f4d - MTP_RESPONSE_OK
9803 20 1 47: 8 dc07 20201000 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 47: 8 dc07 20201000 - MTP_RESPONSE_OK
9803 20 1 48: 8 dc41 205d385b - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 48: 8 dc41 205d385b - MTP_RESPONSE_OK
9803 20 1 49: 8 dc44 703 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 49: 8 dc44 703 - MTP_RESPONSE_OK
9803 20 1 50: 7 dc02 62203428 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 50: 7 dc02 62203428 - MTP_RESPONSE_OK
9803 20 1 51: 7 dc03 ffffffff - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 51: 7 dc03 ffffffff - MTP_RESPONSE_OK
9803 20 1 52: 7 dc04 53525454 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 52: 7 dc04 53525454 - MTP_RESPONSE_OK
1008 16 1 53: 7 dc07 20223636 - MTP_OPERATION_GET_OBJECT_INFO
2001 16 3 53: 7 dc07 20223636 - MTP_RESPONSE_OK
9803 20 1 54: 7 dc01 49465f4d - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 54: 7 dc01 49465f4d - MTP_RESPONSE_OK
9803 20 1 55: 7 dc07 20201000 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 55: 7 dc07 20201000 - MTP_RESPONSE_OK
9803 20 1 56: 7 dc41 205d385b - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 56: 7 dc41 205d385b - MTP_RESPONSE_OK
9803 20 1 57: 7 dc44 703 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 57: 7 dc44 703 - MTP_RESPONSE_OK
9803 20 1 58: 6 dc02 62203428 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 58: 6 dc02 62203428 - MTP_RESPONSE_OK
9803 20 1 59: 6 dc03 ffffffff - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 59: 6 dc03 ffffffff - MTP_RESPONSE_OK
9803 20 1 60: 6 dc04 53525454 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 60: 6 dc04 53525454 - MTP_RESPONSE_OK
1008 16 1 61: 6 dc07 20223636 - MTP_OPERATION_GET_OBJECT_INFO
2001 16 3 61: 6 dc07 20223636 - MTP_RESPONSE_OK
9803 20 1 62: 6 dc01 49465f4d - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 62: 6 dc01 49465f4d - MTP_RESPONSE_OK
9803 20 1 63: 6 dc07 20201000 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 63: 6 dc07 20201000 - MTP_RESPONSE_OK
9803 20 1 64: 6 dc41 205d385b - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 64: 6 dc41 205d385b - MTP_RESPONSE_OK
9803 20 1 65: 6 dc44 703 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 65: 6 dc44 703 - MTP_RESPONSE_OK
9803 20 1 66: 5 dc02 62203428 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 66: 5 dc02 62203428 - MTP_RESPONSE_OK
9802 20 1 67: dc03 3001 ffffffff - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 67: dc03 3001 ffffffff - MTP_RESPONSE_OK
9803 20 1 68: 5 dc03 53525454 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 68: 5 dc03 53525454 - MTP_RESPONSE_OK
9802 20 1 69: dc04 3001 20223636 - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 69: dc04 3001 20223636 - MTP_RESPONSE_OK
9803 20 1 70: 5 dc04 49465f4d - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 70: 5 dc04 49465f4d - MTP_RESPONSE_OK
1008 16 1 71: 5 dc07 20201000 - MTP_OPERATION_GET_OBJECT_INFO
2001 16 3 71: 5 dc07 20201000 - MTP_RESPONSE_OK
9802 20 1 72: dc01 3001 205d385b - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 72: dc01 3001 205d385b - MTP_RESPONSE_OK
9803 20 1 73: 5 dc01 703 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 73: 5 dc01 703 - MTP_RESPONSE_OK
9802 20 1 74: dc07 3001 62203428 - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 74: dc07 3001 62203428 - MTP_RESPONSE_OK
9803 20 1 75: 5 dc07 ffffffff - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 75: 5 dc07 ffffffff - MTP_RESPONSE_OK
9802 20 1 76: dc41 3001 53525454 - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 76: dc41 3001 53525454 - MTP_RESPONSE_OK
9803 20 1 77: 5 dc41 20223636 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 77: 5 dc41 20223636 - MTP_RESPONSE_OK
9802 20 1 78: dc44 3001 49465f4d - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 78: dc44 3001 49465f4d - MTP_RESPONSE_OK
9803 20 1 79: 5 dc44 20201000 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 79: 5 dc44 20201000 - MTP_RESPONSE_OK
100c 20 1 80: 2 ffffffff 205d385b - MTP_OPERATION_SEND_OBJECT_INFO
SCR: OV7670_MB.zip
2001 24 3 80: 2 ffffffff c - MTP_RESPONSE_OK
100d 12 1 81: dc07 3001 62203428 - MTP_OPERATION_SEND_OBJECT
100d 9506 2 81: 4034b50 14 83750008 - MTP_OPERATION_SEND_OBJECT
a 8994 500 0 12 500 0
a 8482 1012 0 0 512 0
a 7970 1524 0 0 512 0
a 7458 2036 0 0 512 0
a 6946 2548 0 0 512 0
a 6434 3060 0 0 512 0
a 5922 3572 0 0 512 0
a 5410 4084 0 0 512 0
a 4898 4596 0 0 512 0
a 4386 5108 0 0 512 0
a 3874 5620 0 0 512 0
a 3362 6132 0 0 512 0
a 2850 6644 0 0 512 0
a 2338 7156 0 0 512 0
a 1826 7668 0 0 512 0
a 1314 8180 0 0 512 0
a 1302 8192 500 0 12 0
  SW: 8192!
b 802 500 500 0 12 8
a 290 1012 0 0 512 0
a 0 1302 0 0 290 0
len 1302
  SW: 1302!
SCL - startSCL - complete
2001 12 3 81: dc07 0 2000 - MTP_RESPONSE_OK
9803 20 1 82: c dc02 185ad36b - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 82: c dc02 185ad36b - MTP_RESPONSE_OK
9803 20 1 83: c dc01 c44e8419 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 83: c dc01 c44e8419 - MTP_RESPONSE_OK
9803 20 1 84: c dc07 74fc40de - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 84: c dc07 74fc40de - MTP_RESPONSE_OK
9802 20 1 85: dc0b 3000 520319c7 - MTP_OPERATION_GET_OBJECT_PROP_DESC
2001 20 3 85: dc0b 3000 520319c7 - MTP_RESPONSE_OK
9803 20 1 86: c dc0b ed6f1ef7 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 86: c dc0b ed6f1ef7 - MTP_RESPONSE_OK
9803 20 1 87: c dc41 5266bf99 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 87: c dc41 5266bf99 - MTP_RESPONSE_OK
9803 20 1 88: c dc44 848d00ec - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 88: c dc44 848d00ec - MTP_RESPONSE_OK
9803 20 1 89: c dc03 2000 - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 89: c dc03 2000 - MTP_RESPONSE_OK
9803 20 1 90: c dc04 185ad36b - MTP_OPERATION_GET_OBJECT_PROP_VALUE
2001 20 3 90: c dc04 185ad36b - MTP_RESPONSE_OK
1008 16 1 91: c dc01 c44e8419 - MTP_OPERATION_GET_OBJECT_INFO
2001 16 3 91: c dc01 c44e8419 - MTP_RESPONSE_OK
1005 16 1 92: 2 dc07 74fc40de - MTP_OPERATION_GET_STORAGE_INFO
2001 16 3 92: 2 dc07 74fc40de - MTP_RESPONSE_OK
This also included the debug stuff for copying a file to storate. I believe this one I sent to the QSPI SDCard.

Sorry I know it is gratuitous, and it is probably busted in the T3.x portion as I first converted to function, but then it relies on variables in the function it is called from...
But I just personally find it easier to look through this and get a more of an idea of what messages are what.

Events: Then I remember reading in pdf about needing to tell host which events it wants... So I created a list:
Code:
 const uint16_t mtpEventList[] =
  {
    MTP_EVENT_UNDEFINED                         ,//0x4000
    MTP_EVENT_CANCEL_TRANSACTION                ,//0x4001
    MTP_EVENT_OBJECT_ADDED                      ,//0x4002
    MTP_EVENT_OBJECT_REMOVED                    ,//0x4003
    MTP_EVENT_STORE_ADDED                       ,//0x4004
    MTP_EVENT_STORE_REMOVED                     ,//0x4005
    MTP_EVENT_DEVICE_PROP_CHANGED               ,//0x4006
    MTP_EVENT_OBJECT_INFO_CHANGED               ,//0x4007
    MTP_EVENT_DEVICE_INFO_CHANGED               ,//0x4008
    MTP_EVENT_REQUEST_OBJECT_TRANSFER           ,//0x4009
    MTP_EVENT_STORE_FULL                        ,//0x400A
    MTP_EVENT_DEVICE_RESET                      ,//0x400B
    MTP_EVENT_STORAGE_INFO_CHANGED              ,//0x400C
    MTP_EVENT_CAPTURE_COMPLETE                  ,//0x400D
    MTP_EVENT_UNREPORTED_STATUS                 ,//0x400E
    MTP_EVENT_OBJECT_PROP_CHANGED               ,//0xC801
    MTP_EVENT_OBJECT_PROP_DESC_CHANGED          ,//0xC802  
    MTP_EVENT_OBJECT_REFERENCES_CHANGED         //0xC803
  };
  
  const int mtpEventListNum = sizeof(mtpEventList)/sizeof(mtpEventList[0]);
And then updated the WriteDescriptor to change from saying 0 events to instead say:
Code:
    write32(mtpEventListNum);       // Events (array of uint16)
    for(int ii=0; ii<mtpEventListNum;ii++) write16(mtpEventList[ii]);
Still not seeing anything, but will continue to play, I put this up at: https://github.com/KurtE/MTP_t4/tree/WIP_Events

But again not sure if anything of this will work or not..

Back to playing... Actually right now play Frisbee with the dogs ;)
 
What is the feasibility of adding virtual files to MTP? For example, "memory", which would provide read access to all memory in the teensy?
 
@KurtE

Very cool on adding the text names to the debug statements. Kept having to cross reference the numbers to the case statement in the MTP.cpp. Thank you.

Good catch on the event list. Would be great if you could get it working.

Spent the day playing with the W25N01G SPI code. Making some progress - think I know what the problem is to get it completely working but getting cross eyed. Then need to see if I can get in in LittleFS.
 
What is the feasibility of adding virtual files to MTP? For example, "memory", which would provide read access to all memory in the teensy?

It should be possible to create a library which provides a "filesystem" to do this. The code would look similar to SD.h, except instead of calling the SdFat functions to actually access the SD card, you would just read the memory. You'd need to hard-code some sort of response in the functions to manipulate folders. You'd probably also hard-code the open() function to only succeed on "/" and "memory.bin". In your class derived from File, you'd probably store a boolean to know whether the file is "/" or "memory.bin", and in the case of the root folder you'd need to hard-code a response from openNextFile() and the other stuff meant for reading directories.

This sort of virtual filesystem will need to return false or error conditions for many things. How well MTP handles those errors is a good question.
 
Events: Then I remember reading in pdf about needing to tell host which events it wants... So I created a list:
Code:
 const uint16_t mtpEventList[] =
  {
    MTP_EVENT_UNDEFINED                         ,//0x4000
    MTP_EVENT_CANCEL_TRANSACTION                ,//0x4001
    MTP_EVENT_OBJECT_ADDED                      ,//0x4002
    MTP_EVENT_OBJECT_REMOVED                    ,//0x4003
    MTP_EVENT_STORE_ADDED                       ,//0x4004
    MTP_EVENT_STORE_REMOVED                     ,//0x4005
    MTP_EVENT_DEVICE_PROP_CHANGED               ,//0x4006
    MTP_EVENT_OBJECT_INFO_CHANGED               ,//0x4007
    MTP_EVENT_DEVICE_INFO_CHANGED               ,//0x4008
    MTP_EVENT_REQUEST_OBJECT_TRANSFER           ,//0x4009
    MTP_EVENT_STORE_FULL                        ,//0x400A
    MTP_EVENT_DEVICE_RESET                      ,//0x400B
    MTP_EVENT_STORAGE_INFO_CHANGED              ,//0x400C
    MTP_EVENT_CAPTURE_COMPLETE                  ,//0x400D
    MTP_EVENT_UNREPORTED_STATUS                 ,//0x400E
    MTP_EVENT_OBJECT_PROP_CHANGED               ,//0xC801
    MTP_EVENT_OBJECT_PROP_DESC_CHANGED          ,//0xC802  
    MTP_EVENT_OBJECT_REFERENCES_CHANGED         //0xC803
  };
  
  const int mtpEventListNum = sizeof(mtpEventList)/sizeof(mtpEventList[0]);
And then updated the WriteDescriptor to change from saying 0 events to instead say:
Code:
    write32(mtpEventListNum);       // Events (array of uint16)
    for(int ii=0; ii<mtpEventListNum;ii++) write16(mtpEventList[ii]);
Still not seeing anything, but will continue to play, I put this up at: https://github.com/KurtE/MTP_t4/tree/WIP_Events

But again not sure if anything of this will work or not..

This is what I did and do again
Only commented all but object/store added, object/store removed reset non of the created any reaction from PC.
Specs say there is no acknowledge to events, and other part needs not to react.
Not knowing, how PC is MTP server is programmed, it gets difficult to know if events are arrived at PC.
My event callback is called.
Only difference is I wanted to send events to PC so I configured TX event
Have now to check if usb_desc.c needs modification
 
Great - see the cmtp responder also has a bunch on events. Didn't dig into so not sure if its both ways.

There are sendEvents
but my hunch is our problems relate more to usb.c and how to configure mtp_usb.
There are some pieces in usb.c that I do not understand (esp. sb_prepare_transfer)
But as Paul says, one needs to know usb protocol better, and I'm the learning by screwing it up' type of guy, so studying the USB protocol is hard.
 
There are sendEvents
but my hunch is our problems relate more to usb.c and how to configure mtp_usb.
There are some pieces in usb.c that I do not understand (esp. sb_prepare_transfer)
But as Paul says, one needs to know usb protocol better, and I'm the learning by screwing it up' type of guy, so studying the USB protocol is hard.

Probably you are right. USB protocol I stayed away from. I do think functions changes in usb.c for T4 from the T3. But never got into it. BTW. I am the same trial and error.
 
Trial and error? I don't do that, I do error, error, error, trial, error ... ;)

I think I have that third Endpoint backwards right now. That is I am so used to being on the other end (USB Host), so the IN Interrupt is actually us doing outputs...

So will change the pipe direction, remove the pending RX setup...

Now question is, is there some way with our local FS to get notifications of a file changed or created?

That is can we have our test program create a new file after so much time and then detect that and try to send out a notification of file changed/created.

Also out of curiosity I have my T4.1 setup to do the MTP DISK Serial... setup and each time I build or the like, it says it can not find the comm port, I then select the same com port number and finally it is usually happy enough to continue. But then every N times, Arduino IDE no longer wants to work so need to close it down and reopen...
Are others similar?
 
Also out of curiosity I have my T4.1 setup to do the MTP DISK Serial... setup and each time I build or the like, it says it can not find the comm port, I then select the same com port number and finally it is usually happy enough to continue. But then every N times, Arduino IDE no longer wants to work so need to close it down and reopen...
Are others similar?
My setup is VScode with makefile (simular to VisualTeensy)
I use always MTP-serial
For terminal I use either Putty or ArduinoMonitor
Before uploading I have to close terminal, otherwise I have to press button.
This is most likely due to the way MTP-Serial is setup.
it comes as Everything.

at the moment we use
Code:
  #define VENDOR_ID             0x16C0
  #define PRODUCT_ID		        0x0476 //fake an include everything device
  #define RAWHID_USAGE_PAGE	0xFFAB  // recommended: 0xFF00 to 0xFFFF
  #define RAWHID_USAGE		0x0200  // recommended: 0x0100 to 0xFFFF
  #define DEVICE_CLASS		0xEF
  #define DEVICE_SUBCLASS	0x02
  #define DEVICE_PROTOCOL	0x01
the Seremu version is using
Code:
  #define VENDOR_ID		0x16C0
  #define PRODUCT_ID		0x04D1

@Paul: maybe you could define a own PID for mpt-serial

Once that is done, I can make a PR to get it included in cores
Also Pauls needs to update teensy.exe and TD to recognize the new device
 
Not sure if it may become useful I played around with non-File_Explorer acess to MTP and come up with following basic windows powershell script

Code:
#inspired by
#https://blog.daiyanyingyu.uk/2018/03/20/powershell-mtp/
#
# usage: ./MTPdir -Path "Teensy/sdio/dir0/dir1/dir2"
#
#
param([string]$Path)

$pathParts = @( $Path.Split('/'))

$shell = new-object -com Shell.Application

# 17 (0x11) = ssfDRIVES from the ShellSpecialFolderConstants (https://msdn.microsoft.com/en-us/library/windows/desktop/bb774096(v=vs.85).aspx)
# => "My Computer" — the virtual folder that contains everything on the local computer: storage devices, printers, and Control Panel.
# This folder can also contain mapped network drives.

$shellItem = $shell.NameSpace(17).self

$C1 = $shellItem
foreach ($dir in $pathParts)
{
	$C1 =  @($C1.GetFolder.Items()| where { $_.Name -match $dir })
}
echo @($C1.GetFolder.Items()).name
name the file MTPdir.ps1 and execute from Windows powershell

I use it recursively to walk down the directory list
e.g.
./MTPdir -Path "Teensy" gives the list of the different storages
./MTPdir -Path "Teensy/RAM1" gives the root-level files and folders of RAM1
etc.etc.

If someone with better scripting skills improves this basic script, please let us know
 
I'm excited about the possibility of this MTP Responder.
I see in as an (Experimental) USB option now.
Is it likely that this will be usable simultaneously with other USB types ? I use USB MIDI.
 
@all - I have been doing some hacking and not sure if any of these changes are making an effect, although I am seeing now when I write a file to an SD Card that if I go back up to top object it is showing a reduced number of storage left... But maybe that was working before.

Anyway I updated the two forks/branches I mentioned back in #452.

What my hacks are doing is In the MTP loop code that every 250ms I send out an event for one of the top level FS.s...


Code:
#if 1
      // this is a test and only a test.
      
      if (emLastStorageInfoChange > 250) {
          if (storage_->get_FSCount()) {
            last_storageInfoChanged_id++;
            if (last_storageInfoChanged_id > storage_->get_FSCount()) last_storageInfoChanged_id = 1; 
            MTPEvent event;
            event.len = 16;
            event.event_type = MTP_CONTAINER_TYPE_EVENT; // 4
            event.event_code = MTP_EVENT_STORAGE_INFO_CHANGED;   // 6
            event.session_id = sessionID_; // 8
            event.handle = last_storageInfoChanged_id;    // 12
            printf("EV: %d %x %x %x %x\n", event.len, event.event_type, 
                event.event_code, event.session_id, event.handle);
            usb_mtp_eventSend(&event, 100);
            emLastStorageInfoChange = 0;
          }
      }
#endif

I updated the usb2 code (usb1) to have the event endpoint be output instead of input...
Again not sure if it is working at all. Sometimes I get the TX callback to be called.

Again: experiment, fail ... ;)
 
As suggested by Paul... To continue on the MTP thread:
On the PC side of MTP, you are limited with what you can do "directly" with the file, because file is not on PC but on Teensy. Consider the File Explorer a window into Teensy.

What can you do on PC: create a directory, delete and rename files, down and upload files, move and copy files, for the moment that is all. If you open say a text file with notepad, for example, the file will be first copied to PC and opened read only. Editing file is not enabled. Maybe it can be done, asthere is a MTP extension called begin/end_edit_object, but this is not activated.

Otherwise it is the PC that is in control on what Teensy allows to do, and that leads to 2nd scenario, where Teensy does something, how can MTP initiator know? he cannot. That is where events come into play. Teensy (MTP-responder) should only respond to PC, but be can send asynchronous events tell PC that something has changed. But AFAIK, a PC (MTP-initiator) can ignore all events. So either we know what PC does or we have to write own MTP initiator.

Would it be possible to use USB-Host to write a hybrid USB sniffer that passes USB packets from external device to PC, and observe USB traffic (especially events) to from PC. And simply try different commercial products (cameras, phones etc) to see what they are doing?

You are right that within MTP we can probably capture most file change events that happened on the PC. I am going to modify my current notifications that run every .25 seconds to only run if there have been any changes made on the PC or at least any messages sent from the PC...

On the Teensy side, on my experiment branches I am thinking of adding some simple hack that can be called by the code, maybe something like:
mtpd.FSChanged(FS *pdf=nullptr, const char *path=nullptr);

Where then example code could maybe create a new file, and call of to this and see if we can make the file show up and the higher level FS show differences in free storage...

Again not sure if this would work, but... Maybe later this gets extended where maybe FS class has an ability to define a callback or event or... Which then does this.
 
On the Teensy side, on my experiment branches I am thinking of adding some simple hack that can be called by the code, maybe something like:
mtpd.FSChanged(FS *pdf=nullptr, const char *path=nullptr);

Where then example code could maybe create a new file, and call of to this and see if we can make the file show up and the higher level FS show differences in free storage...

Again not sure if this would work, but... Maybe later this gets extended where maybe FS class has an ability to define a callback or event or... Which then does this.
Yes, that was the original idea, but if there is now way to notify PC on changes on Teensy,.... (Or we get events running...)
If we can get at least ONE (1) event running then we are a step further.

I have some experimental code in usb1 and in MTP to be called from main, but no joy, so I disabled the MTP part
 
As I mentioned, in my current branch I am seeing updates to free space on the different storages. So maybe some success. Will try extending.
 
As I mentioned, in my current branch I am seeing updates to free space on the different storages. So maybe some success. Will try extending.

Edit: My observation on MTPEvent is wrong (it is the same, only transactionId is now called sessionId)
 
Edit: My observation on MTPEvent is wrong (it is the same, only transactionId is now called sessionId)
If you looked at my branch, I noticed it was passing session ID, so I was now storing the ID that was passed to it in the Start Session message and using that to pass back in the event structure.
 
If you looked at my branch, I noticed it was passing session ID, so I was now storing the ID that was passed to it in the Start Session message and using that to pass back in the event structure.

I realized that,
However, MTP_EVENT_STORAGE_INFO_CHANGED is a bad test case, as cmd 0x1005 (GetStorageInfo) is called automatically every time delete/copy PC2Teensy is called.

Also on RAM (were I can easily see difference), copy2Teensy shows up, but delete does not change disk free size
 
Yep - Was seeing some of the same yesterday. I was also testing with 1MB sd card.
That was sort of why I said maybe sort of .... ;)
 
I'm chasing a Bug , copying from pc 2 teensy 0x1005 is called with correct storage id, if deleting file 0x1005 is called wit wrong storage number (storage -1)
 
Back
Top