Teensyduino File System Integration, including MTP and MSC

I did notice with TyCommander that if I left it open when I recompliled the sketched from dual to MTP the second serial Teensy showed Gray - but if I let it sit long enough the second teensy would disappear - so maybe it was a matter to timing on Tycom update - did notice there is an option in the drop down for a application reset that you might have to use. But it doesn't seem to be a Teensy issue but a TyCommander usage pattern.

I ran the sketches on the locked T_MM, unlocked T_MM and the T4.1 without a problem.

Mike, did you get the latest TyComm published yesterday?
 
Paul (and others),

Simple question on examples code... Again not assuming the what was the ..._spitftbmp sketch that extended to use MTP and optionally also can do jpeg and png files...
We are currently using the ILI9341_t3n library for this, which does not ship with Teensyduino. The comments at the top show you how where you can get it. Alternatively could use the ILI9341_t3 library.

It does compile with it, But not all of the functionality works correctly. So far specific to the writeRect function. The _t3n library code handles offsetting and clipping of the passed in rectangle to the bounds of a clip rectangle, with the default clip rectangle being the whole screen. I can see a few possible approaches to resolve this:

a) punt - and continue to use _t3n
b) Update the sketch to do all of the clipping of the data itself.
c) Change to use different display like ST7735/89 or ILI9488, which all probably have this clipping support.
d) Migrate some/most/all of the ili9341_t3n library functionality into _t3 - back in January of 2017 I issued a PR and closed it in 2019...

I tend toward a) but we could do part of d)...

Suggestions.
 
Paul (and others),

Simple question on examples code... Again not assuming the what was the ..._spitftbmp sketch that extended to use MTP and optionally also can do jpeg and png files...
We are currently using the ILI9341_t3n library for this, which does not ship with Teensyduino. The comments at the top show you how where you can get it. Alternatively could use the ILI9341_t3 library.

It does compile with it, But not all of the functionality works correctly. So far specific to the writeRect function. The _t3n library code handles offsetting and clipping of the passed in rectangle to the bounds of a clip rectangle, with the default clip rectangle being the whole screen. I can see a few possible approaches to resolve this:

a) punt - and continue to use _t3n
b) Update the sketch to do all of the clipping of the data itself.
c) Change to use different display like ST7735/89 or ILI9488, which all probably have this clipping support.
d) Migrate some/most/all of the ili9341_t3n library functionality into _t3 - back in January of 2017 I issued a PR and closed it in 2019...

I tend toward a) but we could do part of d)...

Suggestions.

May not be popular but I would say punt. The JPEG and PNG libraries are already now standard libraries.
 
Been sort of goofing off today ;) sort of experimenting.

Wondered ways to remove need to call mtp.begin()...

First/current approach or hack :lol:

Added some code to core: usb_mtp.h/c

Code:
static uint8_t usb_mtp_first_rx = 1; 
void usb_mtp_first_rx_cb() __attribute__((weak));
void usb_mtp_first_rx_cb(void) {};


static void rx_event(transfer_t *t)
{
	int i = t->callback_param;
	//printf("rx event i=%d\n", i);
	// received a packet with data
	if (usb_mtp_first_rx) {
		usb_mtp_first_rx = 0;
		usb_mtp_first_rx_cb();
	}
	uint32_t head = rx_head;
	if (++head > RX_NUM) head = 0;
	rx_list[head] = i;
	// remember how many bytes were actually sent by host...
	int len = rx_packet_size - ((t->status >> 16) & 0x7FFF);
	rx_list_transfer_len[head] = len;
	rx_head = head;
}
So on first message that we receive on MTP will call a function and I provided a default weak one... Later does not need to be if code bundled correctly...
I pushed this up into my mtp_serial branch which also has possible start for MTP+Serial.

then in MTP.teensy, I put a version of this function which calls MTP.begin(); automagically

Then was playing with starting up the MTP stuff quickly... So again wondered if the sketches add their storages quickly, before the MTP code ask for storage list, we were part way there. But they returned we are busy when
asked for GetStorageInfo, so I let this be processed.

Then in a few of the sketches, I rearranged things like don't wait on Serial, before we add our storage list... And it may be just me, but I think it does now come up pretty quick :D
These changes are in the branch fast_start.
 

Just had a chance to try this. First I updated to latest set MTP_Teensy changes then update usb_mtp.h and usb_mtp.c from your cores branch.

Ran the example_2_simple_t41_qspi sketch and MTP connected faster than I have ever seen it as well as serial. So decided to give it a bit more of a stress test using my version of the MTP_test_integrity sketch that has provisions for 6 devices. MTP came up very quickly with the qspi/RAM/PROGM/SDIO/NAND/NOR and MSC in explorer and I mean faster than if I plugged anything into the PC or at least seems that way !!!!!!!!!

Think this is a keeper.
 
Not sure what I missed? Running on T_4.1:

> boards.local.txt - lost again on dumping folder :( - Teensyduino-File-System-Integration-including-MTP-and-MSC
--> Cool same as prior string in TSET USB choice 'o'
--> I see build with: -DUSB_MTPDISK_SERIAL
> KE.git Cores:mtp_serial
> KE.git MTP_Teensy:fast_start
--
> remove in setup(): //MTP.begin();

When Power Off/On it comes up and runs MakeFiles with delayed Serial, NO Teensy MTP device?, sketch is running and prints Verify results
 
Hello World or shall I say hi all.. ;)
Post#1078
d) Migrate some/most/all of the ili9341_t3n library functionality into _t3 - back in January of 2017 I issued a PR and closed it in 2019...
I personally would vote for (d) xd:rolleyes:
@KurtE all my ILI9341 TFT projects are based on your library, no screen flickering with the buffer I love it.
 
Last edited:
RE p#1084

> Build in IDE and use T_SerMon - Port shows as "//fake an include everything device" - I see why so the USB_Desc is getting used: {'T','e','e','n','s','y',' ','M','T','P',' ','D','i','s','k','/','S','e','r','i','a','l'}

But it starts and Restarts with nothing showing on the SerMon before Restart - so crashing ...

... missing piece not yet found ... MTP not running here ...
 
<EDIT>: Seems the SD card is no longer reliable. Alternating that one and another, this one kept hanging on Read for Verify - or other?
>> Switch back to PLAIN SERIAL - not trying MTP ... Zzzzz's

I pulled that SD card to the PC and it had drastic corruption.

a blank 'unnamed' folder on the root when clicked repeated the root ... over and over clicking into it.
> this folder could not be deleted.

The only thing that showed in Admin dos box that might have been it was "[]"

This disk was a copy of the AUDIO_Tutorial with PDF and sample files before, the PDF had a bad name?
Doing a 'dir' had some form of 'illegal command' in file list before the PDF with odd chars showing?
Went away when *.pdf was deleted.

Had to FORMAT the 32GB card to get it back - then the code runs again, but still no MTP
 
Last edited:
Defragster - I did all of my testing with simply mtp disk (not serial) yesterday. The code can still optionally call mtp.begin() first call wins...
Not sure if it makes difference, Maybe I screwed up something with trying to make Ubuntu happy with MTP+serial...

let me know if just mtp (and seremu) works for you
 
Kurt - will give that a look. Made good headway on fileVerify() in MakeFiles - after distractions and that bad (?) SD card causing hangs

Something odd with USB here ... indeed it builds MTP EXP Sermu and presents the drive usably - but NO T_4.1 on TyComm ?

<EDIT> DOH/Opps :: IDE was open and it stole the T_4.1
 
Last edited:
Kurt - will give that a look. Made good headway on fileVerify() in MakeFiles - after distractions and that bad (?) SD card causing hangs

Something odd with USB here ... indeed it builds MTP EXP Sermu and presents the drive usably - but NO T_4.1 on TyComm ?

Hi Tim
Was just going to post that after reformatting my SD card that I was abusing last night I re-ran your MakeFiles 2203 sketch using MTP_Serial and it work fine - was up and running before I could event open serial monitor.
 
Hi Tim
Was just going to post that after reformatting my SD card that I was abusing last night I re-ran your MakeFiles 2203 sketch using MTP_Serial and it work fine - was up and running before I could event open serial monitor.

Great. MakeFiles_v2204 coming along with Verify - cleaning up the verbose DIR output not needed. Just stuck on verify of LAST "block" set that is indeterminate length with padding bytes to meet spec length.

Using SEREMU my startup is showing about 2.5 secs now instead of 5 secs.

Still unclear why p#1084 steps didn't give a working: -DUSB_MTPDISK_SERIAL

Teensy Time still short here with other tasks needing attention.

I need to do a PC to PC write on the suspect SD card to see if it repros what happens when using T_4.1 to write - then I can toss/FLAG it. Weird thing is it is a hanging fail not anything graceful with T_4.1 access? And on return PC as noted corruption was odd including 'D0' folder showing as also '_D0' ??? And Error even on the Dos Box 'DIR' mid output might indicate even the PC has 'unhandled' access issues. Maybe it needs a proper SD_Formatter run?
 
@All - Have not been able to keep up with all of the changes. I just lost my step son Tuesday morning and need to catch up with the latest changes to MTP. Need a distraction:( I have a general idea of the changes but need to know what libraries to update from whom. Seems like @Kurte's have changed the most. Sounds like Teensy_MTP is coming of age.

Thanks...
 
@wwatson - sorry to hear about your step son.

LittleFS was updated to to change the names of the getPN and also the implementation of some of them to .cpp instead of .h file. This helped with the issue your mentioned about linking.

Yes I have some experimental branches that @defragster mentioned in #1084 that appear to help startup faster and the like. Not sure yet if the approaches will be what we really use...
 
@wwatson - sorry to hear about your step son.

LittleFS was updated to to change the names of the getPN and also the implementation of some of them to .cpp instead of .h file. This helped with the issue your mentioned about linking.

Yes I have some experimental branches that @defragster mentioned in #1084 that appear to help startup faster and the like. Not sure yet if the approaches will be what we really use...

Thanks Kurt, Always follow you guy's lead...
 
@wwatson - sorry to hear about the loss. Good luck finding a worthy distraction.

... as far as Post #1084 ... writing this and seeing the code something really obvious came to mind!

AHA! DOH! and YAY!

MakeFiles.ino of course was altered to run MTP or Seremu ... with a handy #ifdef to build properly in either case with code like this - still there on the the .begin():
Code:
#ifdef USB_MTPDISK
  MTP.begin();
#endif

So the failing SD card distracted at the perfect time - making it seem like the code change was causing the issues ... not merely excluding the MTP code ...
The rest changed like this ...
Code:
#if defined(USB_MTPDISK) [B][U]|| defined(USB_MTPDISK_SERIAL) [/U][/B] 
  MTP.loop();  //This is mandatory to be placed in the loop code.
#endif

Here Tycomm still taking a couple of seconds to show - same with either MTP above:
Code:
Serial online : 2354

No other delay() or Serial.begin() and shortened the: while (!Serial && millis() < 400 );
 
@wwatson - really sorry about your loss. Been through that so I know what you are going through. Any distraction helps.

and yes the changes to MTP are really bringing it into its own. Still getting distractions but its fun.
 
@all - As still waiting for some questions/issues/options and the like...

Been screwing off with our MTP_ILI9341_picture_view maybe example sketch:

Some of the fun things added:

a) Can use either ili9341_t3n or ili9341_t3. If the _t3n header file is included it will use it else it will use the other. if used it will use frame buffer.

b) if using _t3 it has it's own method for writeRect which does the clipping before it calls the tft.writeRect. Note: if parts of the writerect goes out of the frame, it breaks up the writerect into a writerect per y...
There is some debug code in place that when turned on, will show the rectangles involved.

c) if you hit enter in debug terminal, it will stop after displaying next image, hitting enter again will startup up. However if the first char it receives waiting for you enter something is 'd' it will toggle the debug state.

d) I added initializing the touch screen. So far it does not do anything except, if you have it pressed, it will display images as fast as possible (no delays)

e) today I added also looking for a specific file: PictureViewOptions.ini in the root directory of the SD, it has a really really simple ini type parse function for things like: debug=0
The code looks for it at startup, and also each pass through the list of files. When it processes it on openNextFile it will check to see if the modify date changed. If so it will process the file again...
So you can edit the settings on the PC save them and then drag the new copy to the MTP window and then it will update to new settings... Sort of fun.

I will be playing with a few more options, but pushed up the current stuff in my fast_start branch.
 
@all - As still waiting for some questions/issues/options and the like...

Been screwing off with our MTP_ILI9341_picture_view maybe example sketch:

Some of the fun things added:
...
I will be playing with a few more options, but pushed up the current stuff in my fast_start branch.

Awesome you are productively amused - and finding good functionality to use and work with!

I can say the times I've gotten to build after clearing up my #ifdef - the edited CORES with USB_MTPDISK_SERIAL is working well. Online time under 2.5 seconds with TyComm. Updated the print test rate and TyComm is onlineas:
Code:
Serial online : 1786

Just closed TyComm and opened T_SerMon.

Closing T_sermon and reopening gives this - much faster that SEREMU:
Code:
[B][COLOR="#FF0000"]ERROR: loop received command with 65535 bytes[/COLOR][/B]
[B]Serial online : 756[/B]
Serial online : 857

But it never re-uses OPEN T_sermon? Always have to close it after build and restart it and the IDE Console shows this:
Code:
C:\T_Drive\arduino-1.8.19\hardware\teensy/../tools/teensy_post_compile -file=MakeFiles.ino -path=R:\Temp\arduino_build_716257 -tools=C:\T_Drive\arduino-1.8.19\hardware\teensy/../tools -board=TEENSY41 -reboot -port=usb:0/140000/0/6/2 -portlabel=hid#vid_16c0&pid_0478 Bootloader -portprotocol=Teensy 
Unable to open COM8
Unable to open COM8

Of course - timing SerMon start when it can't reuse an open T_sermon ruins the test ...
 
@all - while working with the picture viewer skethch for PNG's, JPG's and BMP's noticed there also was an animated GIF library. So created a version of the ILI9341 picture viewer to just do Animated Gifs.

What libraries will you need to download as they are not part of the TD installer:
@KurtE - ILI9341_t3n: https://github.com/KurtE/ILI9341_t3n
@bitbang - AnimatedGIF: https://github.com/bitbank2/AnimatedGIF

2 Sketches were added to the Examples folder
MTP_ILI9341_AnimatedGifs - plays all animatedGIFs
MTP_ILI9341_AnimatedGifs_Audio - plays animatedGIFs + plays a wav file specified in loop. Sketch folder also contains a GIF folder for all GIFs + the .wav file. Copy this to the SD Card you are using. There definitely seems to be some conflicts with using audio and all the SD access that is needed.

The AnimatedGIF_Audio example was also updated with some the features @KurtE incorporated into the ILI9341 sketch:
c) if you hit enter in debug terminal, it will stop after displaying next image, hitting enter again will startup up. However if the first char it receives waiting for you enter something is 'd' it will toggle the debug state.

e) today I added also looking for a specific file: PictureViewOptions.ini in the root directory of the SD, it has a really really simple ini type parse function for things like: debug=0
The code looks for it at startup, and also each pass through the list of files. When it processes it on openNextFile it will check to see if the modify date changed. If so it will process the file again...
So you can edit the settings on the PC save them and then drag the new copy to the MTP window and then it will update to new settings... Sort of fun.
 
Back
Top