MTP Responder Contribution

[WMXZ]

found bug
in MTP.cpp around line 353

        case MTP_PROPERTY_STORAGE_ID:         //0xDC01:
          write32(store+1);

[KurtE]

@WMXZ - Good morning (or time in you area )

Wondering what the state of things are with MTP and Cores, and LittleFS...

That is I am currently running with everything I believe synced up.

Do we still need the MTP Serial setup for type? I tried with just MTP exerimental and I am now seeing the messages on TyCommander and for example if I run your example sketch I can hit the Y command and have it format the storage.

But nothing is showing up on windows. However if I let it sit for a few minutes, it will says something like now setting up MTP ... disk and completed...

It shows up something in settings:


But not in the explorer window:


Looking at your readme file looks like you have some powershell scripts. May have to learn more about power shell. They don't want to run in normal window saying they are unsigned...

Also any more luck recently with notifications?

Thanks

Kurt

[WMXZ]

@KurtE
(FYI I'm in Europe)

Just compiled and run on T4.1 the test example using Seremu (after changing the configuration from T3.2 +AudioCard to my system)
MTP is showing up on FileExplorer

On situation with cores, the actual core for T4 has now usb_mtp and will be available in next TD (beta) release.
until then , one needs usb2 library

On MTP_Serial, this will need Paul to allocate a PID (at the moment we are cheating using PID of everything) and then I can test and issue PR
(PID must be assigned by Paul, as Teensy uploading and Serial Monitor must be aware or PID to avoid button press)

meanwhile to use MTP_serial, one needs to copy the usb_desc.h components to cores.
to use MTP_serial from Arduino IDE, one has to copy the lines in boards.txt to get an entry into Tools/USB type menu

On powershell, is that not standard on Win10?

BTW, I never have seen something like your first screenshot
Correction: I never used system setting to go to device manage (now I sow this also)

[KurtE]

@WMXZ - Thanks,

Yes it was working before as you mentioned.

However I am running with the latest core sources and with it, it no longer wants to show up in the explorer.

That is on my install of Arduino 1.8.13 using cmd and renamed the cores that was installed to cores_release
and created a symbolic link: mklink cores d:\github\cores so if you look at my directory you see:

11/26/2020  06:42 AM    <DIR>          .
11/26/2020  06:42 AM    <DIR>          ..
11/20/2020  06:09 AM            82,370 boards.txt
11/05/2020  07:03 AM    <SYMLINKD>     cores [d:\GitHub\cores]
11/01/2020  08:33 AM    <DIR>          cores_release
11/19/2020  03:59 PM            10,885 keywords.txt
11/19/2020  03:59 PM    <DIR>          libraries
11/26/2020  06:42 AM             6,878 platform.txt
11/26/2020  06:42 AM             6,263 platform.txt.notyqt
               4 File(s)        106,396 bytes
               5 Dir(s)  736,613,765,120 bytes free

C:\arduino-1.8.13\hardware\teensy\avr>

That way I keep up to date and when I make changes it easier for me to then quickly create a new branch and issue a Pull Request back to Paul...

As for Powershell, again have not used it much... I more used to the old cmd shell... But if I try to run the scripts.

PS D:\GitHub\MTP_t4\scripts>
PS D:\GitHub\MTP_t4\scripts> .\MTPreset.ps1
.\MTPreset.ps1 : File D:\GitHub\MTP_t4\scripts\MTPreset.ps1 cannot be loaded. The file
D:\GitHub\MTP_t4\scripts\MTPreset.ps1 is not digitally signed. You cannot run this script on the current system. For
more information about running scripts and setting execution policy, see about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .\MTPreset.ps1
+ ~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess
PS D:\GitHub\MTP_t4\scripts>

Looks like by default scripts are not allowed to run by default on Window 10 client machines...

[WMXZ]

Looks like by default scripts are not allowed to run by default on Window 10 client machines...

the reset script needs to run in Admin mode,
OK, om my win10, I'm alone and so script can relaunch itself as admin, maybe there are some system settings also. I have to remember.
On cores, will try again download latest cores now

[WMXZ]

@KurtE
downloaded cores, copied contents of modification files into the different desc.h files, compiles mtp_test and it worked, without and with LittleFS
(I'm using Makefile and have NO usb2 in my path)

edit:
Test was working with MTP_Serial
But for MTP_Seremu and Arduino I have difficulties

edit:
I got MTP back with MTP_Seremu, after commenting "while(!Serial); ", but no printout

[KurtE]

I am pretty sure it has to do with things like:

  #if !__has_include("usb_mtp.h")
    #include "usb1_mtp.h"
  #endif

The problem is that having an INO file include usb_mtp will not pass this through to libraries. I got hit with earlier with TeensyTimer library stuff. Also when playing around with one of our display libraries. Could hack it to have the file at some other bogus library, but that is not a great way...

For example I removed my link to USB2 library and the MTP test program no longer compiles.

I tried hacking the MTP and the MTP Spiffs library to do something like:

#undef USB_DESC_LIST_DEFINE
#include "usb_desc.h"

#if defined(__IMXRT1062__)
  // following only while usb_mtp is not included in cores
  #if __has_include("usb_mtp.h") || defined(_USE_USB_MTP_H_)
    #include "usb_mtp.h"
  #else
    #include "usb1_mtp.h"
  #endif
#endif

And hacked usb_dev.h to add:
//BUGBUG: See if force of USB_MTP
#define _USE_USB_MTP_H_


It builds, but I am still not seeing the device.

[WMXZ]

here is my screenDump
only while(!Serial) is commented out

[KurtE]

Note: I am still not having any luck. Will try again.

You might want to double check how it is building and the like.

For example IF I remove the USB2 library the Arduino build will fail as it can not find the usb1_mtp.h file as that has_included will not have been successful.

Also maybe you have other local changes? And how is your Teensy plugged in? i.e. is it running high speed (480) or not 12...

Again just trying to understand the differences. Will also try to sync everything else up again.
But I think I have (core, MTP_t4, MTPspiffs_t41, LittleFS synced)... I just synced SD again, not sure what else.

Thanks

[WMXZ]

But I think I have (core, MTP_t4, MTPspiffs_t41, LittleFS synced)... I just synced SD again, not sure what else.

Thanks

I don't know what MTPspiffs_t41 is, if it is another port of MTP then you should eliminate one (MTP_t4 or MTPspiffs_t41)
Not sure how Arduino searches the libraries.

if cores/Teensye for has usb_mtp.h included then my example code should not call usb1_mtl.h

[mjs513]

I don't know what MTPspiffs_t41 is, if it is another port of MTP then you should eliminate one (MTP_t4 or MTPspiffs_t41)
Not sure how Arduino searches the libraries.

if cores/Teensye for has usb_mtp.h included then my example code should not call usb1_mtl.h

As a FYI MTPspiffs_t41 is standalone so there should be no conflict with MTP_T4. Does still use usb1_mtp.h . It is only to be used if you implemented SPIFFS on the Flash chip.

[WMXZ]

Does still use usb1_mtp.h .

So this explains @KurtE's problems.

[KurtE]

In the recent stuff I am using the mtp-test out of MTP library.... But it does start off with:

  #include "MTPspiffs.h"
  #include "usb1_mtp.h"

  MTPStorage_SPIFFS storage;
  MTPD       mtpd(&storage);

Which if you remove USB2 project does not compile...

So again neither the mtp_t4 nor the MTPSpiffs will compile without USB2 in the library folder.

SO I hacked usb_dev.h or some such thing to define _USE_USB_MTP_H_

I then hacked MTP.cpp file:

 #if __has_include("usb_mtp.h") || defined(_USE_USB_MTP_H_)

As the has_include will not work for something included by .ino only if some other library included it...


I then modified MTPSpifs an

#if defined(__IMXRT1062__)
  // following only while usb_mtp is not included in cores
  #if __has_include("usb_mtp.h") || defined(_USE_USB_MTP_H_)
    #include "usb_mtp.h"
  #else
    #include "usb1_mtp.h"
  #endif
#endif

So it builds without USB2 ... But not luck... Will try again this morning, right now finishing some other morning tasks.

EDIT: Likewise I changed the header file name in first line of INO....

[WMXZ]

So,
the question was how cores is developing to support MTP.
The actual cores contains USB_MTP.h/c that is replacing usb1_mtp from USB2 library.
AFAICT, the mtp_test.ino example handles interim both cases (using cores USB_MTP if available or USB2's usb1_mtp). As soon as new TD is distributed, usb1_mtp is not needed anymore.

[KurtE]

Thanks, that is what I assumed and tried to convert what files were included but still not seeing on PC...

[WMXZ]

As I got access to different NAND chips, I augmented the MTP-test example to visualize the different FS supported filesystems.

[KurtE]

- I synced up again and now can get the Arduino build to run.

And see files.

Note: I had to edit for some configuration issues....

Suggestions on the test sketch...
I try to avoid forever loops...
like:

while(!Serial);

Prefer ones like:

while(!Serial && (millis() < 5000));

As I plug the board into a linux or Windows or ... machine forget I have to setup debug terminal.... And nothing happens.

Also wondering if it should completely hang if for example my CS pins for storage don't match yours. Likewise if it is going to fail maybe more information like:

      { if(!spifs[ii].begin(lfs_cs[ii])) { Serial.printf("No SPIFlash storage(%d:%d)\n", ii, lfs_cs[ii]); while(1);}

It showed me it was looking at CS pin 4...

But wondering if it would recover if that area code was setup like:

    #if USE_LFS_SPI==1
    for(int ii=0; ii<nfs_spi;ii++)
    {
      if(!spifs[ii].begin(lfs_cs[ii])) { 
         Serial.printf("No SPIFlash storage(%d:%d) - skipping \n", ii, lfs_cs[ii]); 
      } else {
         storage.addFilesystem(spifs[ii], lfs_spi_str[ii]);
         uint64_t totalSize = spifs[ii].totalSize();
         uint64_t usedSize  = spifs[ii].usedSize();
         Serial.printf("Storage %d %d %s ",ii,lfs_cs[ii],lfs_spi_str[ii]); Serial.print(totalSize); Serial.print(" "); Serial.println(usedSize);
      }
    }
    #endif

May have to try it... If it does work, would you like a Pull Request?

Also may want to see why the emulated serial does not work...

[Po Ting]

hadn't following for a while,

Suggestions on the test sketch...
I try to avoid forever loops...

I did this before with T3.6, an external button interrupt was used to break flag.
it should break after a button is clicked and a mtpd.loop() is returned
I never know if that was healthy to the SD, no problem to me so far

     while (globaltime < 3000) { // elapsed millis globaltime
      mtpd.loop(); 
      while (connection) { // a boolean flag inserted in mtp.h after establishing connection
        mtpd.loop();
        if (f_Break) {
          break;
        }
      }
      if (f_Break) {
        break;
      }
    }

[WMXZ]

@KurtE
the example is only meant to to have a test case for me and others and at the same time to give an example on how it could be used.

So, all what you say is fine, but IMHO it is an exercise to the user to adapt the examples to own configuration, OS and programming style.
e.g. I remove from all examples the millis()<xxxx clause, because I always want the program to wait on terminal while programming. For my production runs, I disable anyway the wait(!Serial); statement

[KurtE]

@KurtE
the example is only meant to to have a test case for me and others and at the same time to give an example on how it could be used.

So, all what you say is fine, but IMHO it is an exercise to the user to adapt the examples to own configuration, OS and programming style.
e.g. I remove from all examples the millis()<xxxx clause, because I always want the program to wait on terminal while programming. For my production runs, I disable anyway the wait(!Serial); statement

I hear you, but I find when it is hopefully MTP is pulled into the Teensyduino release, in those cases I personally prefer that some examples have a bit more user recovery built in. And maybe have an useful example that for something like T4.x have a simple example that automatically has some standard drives, like SDCard, QSPI flash and just works for some of the default ones, showing up those that exist...

Note, I believe I have a version of the code working with MTP Disk and SEREMU.

I put the changes up in a new branch of core: https://github.com/KurtE/cores/tree/MTP_SEREMU

Simply the Interface numbers in usb_desc.h need to match the order of which the interface descriptors are output in usb_desc.c.
And in this case the SEREMU is output before MTP_DISK is EMU is 0 and MTP_DISK is 1.

If it works for you as well, I could do PR or you can...

Kurt

[WMXZ]

Note, I believe I have a version of the code working with MTP Disk and SEREMU.

Simply the Interface numbers in usb_desc.h need to match the order of which the interface descriptors are output in usb_desc.c.
And in this case the SEREMU is output before MTP_DISK is EMU is 0 and MTP_DISK is 1.

a quick test did not work for me
(difficult to understand, why this would matter)
will try tomorrow morning again

[defragster]

Congrats on finding the list mis-order for function @KurtE <edit - crosspost > ... at least for your use case

As far as samples - simple samples are awesome when they work. But if it isn't something all users have on the same fixed pins it is nice to have the options called out - even if just comments!

For Example: I got a Prop Shield where the AMP burns hot years back - never got dealt with - thought I saw a loose solder shard between the ("TINY") AMP pins and knocked it loose. So I opened a Talkie Example - then another or two - ( I spent a lot of time with Talkie giving it an ASYNC QUE for sounds - and with Beta Prop Shield ) and looking at the sample that said PROP I had no idea what pins were what - final sketch uploaded though and seemed to work ... at least enough to feel the AMP too hot to touch still - but never did get sound. Would have had to resort to reading code - like does it use A21 or A22 DAC on T_3.6 ... @mjs513 did that sample and as labeled for PROP it did the right thing - though not hearing anything with another Prop LC ... speaker still quiet after a few minutes - reading code, alternate speaker , ... so not sure what I'm missing ...

@mjs513 - with TD1.54b5 ... Maybe Talkie on T_3.6 is broken ?

[KurtE]

a quick test did not work for me
(difficult to understand, why this would matter)
will try tomorrow morning again

Note: I edited the example to check !Serial which takes awhile, otherwise your stuff maybe was output before you ever got a chance to get it.

Not sure about T3.x? Does MTP_t4 work with T3.x?

[mjs513]

Congrats on finding the list mis-order for function @KurtE <edit - crosspost > ... at least for your use case

As far as samples - simple samples are awesome when they work. But if it isn't something all users have on the same fixed pins it is nice to have the options called out - even if just comments!

For Example: I got a Prop Shield where the AMP burns hot years back - never got dealt with - thought I saw a loose solder shard between the ("TINY") AMP pins and knocked it loose. So I opened a Talkie Example - then another or two - ( I spent a lot of time with Talkie giving it an ASYNC QUE for sounds - and with Beta Prop Shield ) and looking at the sample that said PROP I had no idea what pins were what - final sketch uploaded though and seemed to work ... at least enough to feel the AMP too hot to touch still - but never did get sound. Would have had to resort to reading code - like does it use A21 or A22 DAC on T_3.6 ... @mjs513 did that sample and as labeled for PROP it did the right thing - though not hearing anything with another Prop LC ... speaker still quiet after a few minutes - reading code, alternate speaker , ... so not sure what I'm missing ...

@mjs513 - with TD1.54b5 ... Maybe Talkie on T_3.6 is broken ?

Haven't played with Talkie for a long while. Funny you mentioned Prop LC - just got one in the mail yesterday haven't soldered it up yet. Will put it on the do list. The latest version of Talkie I have has the example for TomsDiner:

void setup() {
  
  //voice.beginPWM(9);      // specify PWM pin to be used
  voice.beginPropShield();  // use if a propshield is attached using for talkie
  delay(10);
  voice.say(spDINER);
}

Did you set it up this way. There is no example for prop. Will give it a try as soon as I can.

[WMXZ]

@KurtE
AFAICT, I found the issue with Seremu
it has nothing to do with interface order

but, in previous TD installations there is

operator bool() { return usb_configuration; }

while in latest TD (after 26-Nov-2020) we have

operator bool() { return usb_configuration && usb_seremu_online; }

usb_seremu_online is set to 1 in usb.c on feature request other than reset.
Maybe it does not work as expected

This is valid for T3 and T4

Solution? depends on your programming paradigm
As I always want to wait for terminal to be ready, my solution is

  #if defined(USB_MTPDISK_SERIAL) 
    while(!Serial); // comment if you do not want to wait for terminal
  #else
    while(!Serial.available()); // comment if you do not want to wait for terminal ( otherwise press any key to continue)
  #endif

Note
the following code

    Serial.println("MTP_test");
    Serial.println(usb_configuration);
    Serial.println(usb_seremu_online);

generates

MTP_test
1
0

demonstrating that the relevant snippet in usb.c is not working as expected.