MTP Responder Contribution

Morning all
Just downloaded the library at 727am EST (just for ref) and followed instructions in post #118. Made one change to specify using SDIO as opposed to SDfat-Beta lib. Selected MTP Disk(experimental) + Serial from the drop down and getting this error:
Code:
   #error "You need to select USB Type: 'MTP Disk (Experimental)'"

EDIT:
MTP Disk (Experimental) does not appear in the usb dropdown?
 
Morning all
Just downloaded the library at 727am EST (just for ref) and followed instructions in post #118. Made one change to specify using SDIO as opposed to SDfat-Beta lib. Selected MTP Disk(experimental) + Serial from the drop down and getting this error:
Code:
   #error "You need to select USB Type: 'MTP Disk (Experimental)'"

EDIT:
MTP Disk (Experimental) does not appear in the usb dropdown?

OK, until Paul activates MTP Disk it must be uncommented in boards.txt
Will update Readme (done)
(there should be no MTP Disk(experimental) + Serial; it does not work properly, even if Serial is prepared in usb_desc.h)
 
Yeah - just found that now when I started poking around :) uncommented now getting a couple of other errors:

For SDFatBeta 0 and SDIO 1:
Code:
D:\..\..\Arduino\libraries\MTP\MTP_Storage.cpp:92:12: error: no match for 'operator=' (operand types are 'File {aka File32}' and 'FsFile')
     index_ = SD.open("mtpindex.dat", FILE_WRITE);

for Beta 1 and sdio 0:
Code:
D:\Users\Merli\Documents\Arduino\libraries\MTP/MTP_config.h:8:28: fatal error: SdFat-beta.h: No such file or directory
Think have to go back and read some more posts since BillG's lib uses SDFat.h not SDFat-beta.h.

EDIT: Ok all fixed now compiles for both cases once I reread the readme. Now to find a sd card
 
@WMXZ
Just tried it using loglow's breakout board and works like a charm on Win10x64 machine once I reread everything :) Great job.

UPDATE: copied the 1062RM to the sd card ~30Mb in about a second or two, then deleted with absolutely no issues. Wouldn't open the pdf from the sdcard but if I copied a csv file Excel sees it and opens it no problem.
 
Just tried it with a T3.6. and the built in SD slot, VisualTeensy & current clone of TD-core

- Installed SDFatBeta
- had to rename the sdfat.h to sdfat-beta.h in the SDFat.
- in MTP_config.h I have USE_SDFAT_BETA 1 and USE_SDIO 1
- nothing needed to change in boards.txt

The example compiles and runs, prints the loop messages and the drive appears in the explorer. However, I can't really save anything. Well, I can, but it appears in the explorer only after a reboot of the Teensy. Is this supposed to work with a T3.6 or did you work on T4.0 only?


Edit: BTW: I like your configurations in the makefile, mind if I steal the idea for VisualTeensy?
 
@luni
Took @defragster's approach for SDFat.h. I just made a copy and renamed it SDFat-beta.h otherwise probably won't work if you want to use it other apps.

As for boards.txt, that is probably on me, I was reading down from the top of the thread and incorporate a couple of changes to board.txt from Chris O. then decided that I should look further down the thread just in case.
 
I just made a copy and renamed it SDFat-beta.h otherwise probably won't work if you want to use it other apps.
Thanks, I have my libs local to the project anyway, so that should be no issue. It shows SdFat V2.0.0-beta.7 is this the right one?
 
Thanks, that did the trick! Looks like fun!

Wondering how hard it would be to reorganize, the example or examples to make it more Arduino like... I know a lot of people up here don't like/use Arduino IDE and the like, but over the years I have tried to keep things Arduino compatible.

Plus with @defragsters and @Frank B's stuff, I can always setup to fully edit in sublime text and do the builds there, with it doing the actual Arduino build.

Also as some of you know, on Arduino I am one who really does not like config files that control things like, which IO pins, or which SPI or if I am using built in SD or external SPI..., as it assumes I only have one setup.

i.e. So it would be great if you we could set up some of this to maybe be like some of the SDFat examples, like Sdinfo.ino which has stuff like:
Code:
// SDCARD_SS_PIN is defined for the built-in SD on some boards.
#ifndef SDCARD_SS_PIN
const uint8_t SD_CS_PIN = SS;
#else  // SDCARD_SS_PIN
const uint8_t SD_CS_PIN = SDCARD_SS_PIN;
#endif  // SDCARD_SS_PIN

// Try to select the best SD card configuration.
#if HAS_SDIO_CLASS
#define SD_CONFIG SdioConfig(FIFO_SDIO)
#elif ENABLE_DEDICATED_SPI
#define SD_CONFIG SdSpiConfig(SD_CS_PIN, DEDICATED_SPI, SD_SCK_MHZ(16))
#else  // HAS_SDIO_CLASS
#define SD_CONFIG SdSpiConfig(SD_CS_PIN, SHARED_SPI, SD_SCK_MHZ(16))
#endif  // HAS_SDIO_CLASS

Question is, would it make sense if one or more of us played around with something like that?

I do think the functionality and potential of this library, would be a great addition to the Teensyduino releases. For example I wonder how hard or if it logically makes sense that if we have the ability on T4.1 to have a lot of storage soldered on bottom of board, to turn this into a logical MTP drive.

EDIT: I also see: Using library SdFat at version 2.0.0-beta.7
 
@KurtE
I compiled the whole tests with Arduino IDE (that is the reason why I have an empty ino file, to be able to open sketch from Arduino IDE)
 
I support KurtE's desire to make a version that is more Arduino-like. There is a difference between (1) being able to be compiled in the Arduino IDE and (2) being in the style and typical practices of the Arduino community.

While I was able to get all of this to work on T3.6, getting it more nicely bundled up in the style of the Arduino culture would make it nice and approachable for a lot of folks.
 
@WMXZ - You are right and I built it from the unmodified example. One of these days I may get back to visual teensy.

I guess what I am wondering, is what a typical Arduino user would think, when they go to examples->mtp_t4->mtp_test

And it opens up a blank window, would they notice that there was a second tab and look there for the code?
and then find that they can simply move the contents of main.cpp into mtp-test.ino file.

Obviously maybe the currently empty file, could have a comment block telling the user to look in the other tab. Could even have some of the information in the Readme...

It will also be curious to experiment on how one might use this.
For example can I do some simple logger program, which for example either stores away analog reads to a file or files? Or maybe in a usage case I have, which I only work on when my wells have problems) Where maybe I log when each of the well pumps turn and off, as well as the maybe the pressure pump. And I log this information to an SDCARD.

While this program is running, can it also have MTP running and can I simply plug in my portable PC, and copy the log file(s) from the still running program? Limitations? Can I copy the file if the main code still has that file open for writes?

Again pardon my naivety on this.

But again this looks great.
 
I really do not want to embark in a fundamental discussion.
For small programs code in ino is file (as long you are not using typedefs) No problem for examples to eliminate main.cpp and place code in ino.

My driver is indeed a logging program, where I do not have access to the uSD card. So I use MTP to download the data over cable (here USB)

At the moment when Teensy generates files on uSD card, they do only show up after reboot.
I still must learn how to generate events so Teensy can tell PC to rescan directories.
 
Sure, have also a look into cpp_properties.
Thanks a lot. Hope I didn't start an argument about build systems with my remark...

...on Arduino I am one who really does not like config files that control things ... as it assumes I only have one setup.
I fully agree, I also try to avoid this but sometimes its difficult. I recently stumbled over the preprocessor directive __has_include and did a few experiments with it. Using this you can provide a default config.h in the library and a user defined config in the sketch folder. If the lib finds the config from the sketch it reads it otherwise it reads the default one.
I currently try to implement this in another project, and let you know if it works out as planned...


Edit:
At the moment when Teensy generates files on uSD card, they do only show up after reboot.
It looks like the same happens when the PC generates the file right?
 
Here the worked out config pattern (files attached)

main sketch:

Code:
#include "config.h"

void setup()
{
    while(!Serial);
    Serial.println(myConfigString);
}

void loop(){}

File "config.h"
Code:
#pragma once

#if __has_include ("userConfig.h")
    #include "userConfig.h"
#else
    #include "defaultConfig.h"
#  endif

File defaultConfig.h:
Code:
#pragma once

constexpr const char* myConfigString = "From default config";

// all the configuration stuff....

file userConfig.h
Code:
#pragma once

constexpr const char* myConfigString = "From user config";

// all the configuration stuff....

If it finds the userConfig.h it reads it in, otherwise it reads in the defaultConfig.h.

EDIT: Within the lib code you just include config.h. You don't have to know if the user has overridden the default.

The only caveat is that adding a userConfig to an already compiled sketch doesn't trigger a recompile. That means if the user decides to add a userConfig she must trigger a recompile manually (of course only once after the adding). Changing the contents of the configs later will of course not require a manual recompile.
 

Attachments

  • config.zip
    900 bytes · Views: 69
Last edited:
@luni - sounds interesting... Awhile ago, with another project (Robot Hexapod Code), The way I got around this was putting everything in header files, which the main sketch needed to include.

@WMXZ - Understood.
 
@luni - sounds interesting... Awhile ago, with another project (Robot Hexapod Code), The way I got around this was putting everything in header files, which the main sketch needed to include.
Wouldn't that only work if you can guarantee that the config header is ALWAYS included before the library header? Can get quite messy when you have a large lib with a lot of mutually dependent files...
 
At the actual GitHub, there is only a single ino file (removed cpp file) I only had to trick Gcc to compile ino file as it ware c++ file. So I can use and compile from VSCode for development
 
Thanks a lot. Hope I didn't start an argument about build systems with my remark...


I fully agree, I also try to avoid this but sometimes its difficult. I recently stumbled over the preprocessor directive __has_include and did a few experiments with it. Using this you can provide a default config.h in the library and a user defined config in the sketch folder. If the lib finds the config from the sketch it reads it otherwise it reads the default one.
I currently try to implement this in another project, and let you know if it works out as planned...

Funny - discovered that as well and we (@KurtE and me) use it in the font_files so we don't have to keep editing them for which library is active, example:
Code:
#if __has_include(<RA8875.h>)
	#include "RA8875.h"
#elif __has_include(<ILI9488_t3.h>)
	#include "ILI9488_t3.h"
#elif __has_include(<ILI9341_t3n.h>)
	#include "ILI9341_t3n.h"
#elif __has_include(<ILI9341_t3.h>)
	#include "ILI9341_t3.h"
#elif __has_include(<ST7735_t3.h>)
	#include "ST7735_t3.h"
#endif

For the record I just copied the code in main.cpp and pasted into the .ino file so didn't have to worry about it.

Yes I agree we should stick to make it more Arduino like and if people use other compilers like visualmicro, platformio, etc they can adjust it according. In the future Arduino IDEs this may change since they are going something I think it was eclipse based. Don't hold me to that though.

EDIT: @luni - sorry - posted this before I saw your follow on post.
 
Last edited:
@WMXZ Thanks

And sorry for diversion.

@luni
Wouldn't that only work if you can guarantee that the config header is ALWAYS included before the library header? Can get quite messy when you have a large lib with a lot of mutually dependent files...
But yes it was a pain... The main sketch looked like:
Code:
#define DEFINE_HEX_GLOBALS
#if ARDUINO>99
#include <Arduino.h>
#else
#endif
#include <EEPROM.h>
#include <ax12.h>
#include <BioloidEx.h>

#include "Hex_Cfg.h"

#include <Phoenix.h>
#include <Phoenix_Input_Commander.h>
#include <Phoenix_Driver_AX12.h>
#include <Phoenix_Code.h>
Where this example was for a Trossen Robotics Hexapod with Robotis AX12 Servos (which is why that driver was included), using the Trossen Robotics Input commander (XBee) ... There were different headers for different types of servos(AX, Servo library(RC), Lymxotion SSC-32(RC)) and different types of Input controllers (XBee, PS2, RC...)... All controlled in this case by the header file Hex_Cfg.h which had things like Servo IDS, IO pins, ...

Again end of this diversion... Just mentioned as this is an approach which I would NOT like to repeat!
 
To be honest why not just leave the config stuff in the sketch - its pretty much there now the way its done in the SDFat-beta examples.
 
@mjs_513 - bummer you didn't see my post #119 to start where I found the missing pieces - most of which were on the github readme.

As noted I've been watching this thread with interest - but no time to jump in. Now the gang is all here :) This is a very interesting development to access the SD card on the Teensy - with good speed.

Also @mjs_513 - the work we did with uNav and multiple diff users having unique hardware settings of GPS and 9DOF and ports and Teensy 3.5 .vs. 3.6 - the " #if __has_include " would have been nice!

Alternate build ENV that IDE makes merging pieces odd when a sketch needs to be in a folder of sketch name. There was another I mentioned 'at least add a blank.ino' (@luni?) because the IDE includes all other files.

In any case in my posts as presented I noted it works with my SublimeText editor building { it just kicks off IDE from CMD line ) and I also noted it built in the IDE as expected given the files.

I haven't updated to newest yet - but last posts the FOLDER create did immediately show on Windows File Explorer and as noted removing and plugging the Teensy showed those folders again to exist.
 
Been trying to get this working on Linux all day. Getting fed up now.

By fiddling with the udev rules, nautilus now displays 'Teensy MTP Disk' but is unable to access it ("no MTP devices found").

dmesg produces thousands of lines of stuff which I won't post in entirety, but here are some of the most repeated bits (bold text is original).

Code:
[12208.919134] usb 2-6: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[12208.919139] usb 2-6: SerialNumber: 0009519A
[12208.921319] hid-generic 0003:16C0:0478.004C: hidraw4: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:13.2-6/input0
[12209.287730] usb 2-6: USB disconnect, device number 76
[12209.674558] usb 2-6: new high-speed USB device number 77 using ehci-pci
[12209.830973] usb 2-6: [B]config 1 has 1 interface, different from the descriptor's value: 2[/B]
[12209.830979] usb 2-6: [B]config 1 has no interface number 0[/B]
[12209.830988] usb 2-6: [B]Duplicate descriptor for config 1 interface 1 altsetting 0, skipping[/B]
[12209.831466] usb 2-6: New USB device found, idVendor=16c0, idProduct=04d1
[12209.831472] usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[12209.831476] usb 2-6: Product: Teensy MTP Disk
[12209.831480] usb 2-6: Manufacturer: Teensyduino
[12209.831483] usb 2-6: SerialNumber: 6107140
[12209.833318] hid-generic 0003:16C0:04D1.004D: hidraw4: USB HID v1.11 Device [Teensyduino Teensy MTP Disk] on usb-0000:00:13.2-6/input1
[12209.910717] hid-generic 0003:16C0:04D1.004E: hidraw4: USB HID v1.11 Device [Teensyduino Teensy MTP Disk] on usb-0000:00:13.2-6/input1
[12212.544280] usb 2-6: USB disconnect, device number 77
[12216.038563] usb 2-6: new high-speed USB device number 78 using ehci-pci
[12216.194933] usb 2-6: [B]config 1 has 1 interface, different from the descriptor's value: 2[/B]
[12216.194939] usb 2-6: [B]config 1 has no interface number 0[/B]
[12216.194948] usb 2-6: [B]Duplicate descriptor for config 1 interface 1 altsetting 0, skipping[/B]
[12216.195427] usb 2-6: New USB device found, idVendor=16c0, idProduct=04d1
[12216.195433] usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[12216.195437] usb 2-6: Product: Teensy MTP Disk
[12216.195441] usb 2-6: Manufacturer: Teensyduino
[12216.195444] usb 2-6: SerialNumber: 6107140
[12216.197292] hid-generic 0003:16C0:04D1.004F: hidraw4: USB HID v1.11 Device [Teensyduino Teensy MTP Disk] on usb-0000:00:13.2-6/input1
[12216.280102] hid-generic 0003:16C0:04D1.0050: hidraw4: USB HID v1.11 Device [Teensyduino Teensy MTP Disk] on usb-0000:00:13.2-6/input1
[12267.767011] [B][UFW BLOCK] IN=wlx74da38b8fd5c OUT= MAC=01:00:5e:00:00:01:b8:d9:4d:18:58:af:08:00 SRC=192.168.1.254 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2[/B]

Code:
[12677.168553] usb 2-6: USB disconnect, device number 78
[12677.285219] [B][UFW BLOCK] IN=wlx74da38b8fd5c OUT= MAC= SRC=2a00:23c5:3d58:4600:5cd9:655f:e1a2:1692 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=870073 PROTO=UDP SPT=8612 DPT=8612 LEN=24 [/B]
[12677.285236] [B][UFW BLOCK] IN=wlx74da38b8fd5c OUT= MAC= SRC=2a00:23c5:3d58:4600:5cd9:655f:e1a2:1692 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=428448 PROTO=UDP SPT=8612 DPT=8610 LEN=24[/B]

Can anyone see anything obvious?

Thanks. Dinner time.
 
Back
Top