Forum Rule: Always post complete source code & details to reproduce any issue!
Page 19 of 26 FirstFirst ... 9 17 18 19 20 21 ... LastLast
Results 451 to 475 of 633

Thread: MTP Responder Contribution

  1. #451
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,201
    @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.

  2. #452
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,201
    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/W...ulti_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

  3. #453
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    832
    What is the feasibility of adding virtual files to MTP? For example, "memory", which would provide read access to all memory in the teensy?

  4. #454
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,112
    @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.

  5. #455
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,463
    Quote Originally Posted by jonr View Post
    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.

  6. #456
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,999
    Quote Originally Posted by KurtE View Post
    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

  7. #457
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,112
    Poking around on the web for MTP events came across a repsository: uMTP-Responder. its designed for linux but may give you all a few ideas.

  8. #458
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,999
    Quote Originally Posted by mjs513 View Post
    Poking around on the web for MTP events came across a repsository: uMTP-Responder. its designed for linux but may give you all a few ideas.
    I used that a lot
    also cmtp-responder

    but no luck so far

  9. #459
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,112
    Quote Originally Posted by WMXZ View Post
    I used that a lot
    also cmtp-responder

    but no luck so far
    Great - see the cmtp responder also has a bunch on events. Didn't dig into so not sure if its both ways.

  10. #460
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,999
    Quote Originally Posted by mjs513 View Post
    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.

  11. #461
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,112
    Quote Originally Posted by WMXZ View Post
    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.

  12. #462
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,201
    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?

  13. #463
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,999
    Quote Originally Posted by KurtE View Post

    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

  14. #464
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,999
    Quote Originally Posted by KurtE View Post
    the IN Interrupt is actually us doing outputs...
    Yes, everything should be seen from the PC standpoint of view (not responder)

  15. #465
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,999
    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

  16. #466
    Senior Member Davidelvig's Avatar
    Join Date
    Aug 2015
    Location
    Wisconsin
    Posts
    307
    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.

  17. #467
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,201
    @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 ...

  18. #468
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,201
    As suggested by Paul... To continue on the MTP thread:
    Quote Originally Posted by WMXZ View Post
    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.

  19. #469
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,999
    Quote Originally Posted by KurtE View Post
    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

  20. #470
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,201
    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.

  21. #471
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,999
    Quote Originally Posted by KurtE View Post
    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)

  22. #472
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,201
    Quote Originally Posted by WMXZ View Post
    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.

  23. #473
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,999
    Quote Originally Posted by KurtE View Post
    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

  24. #474
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,201
    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 ....

  25. #475
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,999
    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)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •