Teensyduino File System Integration, including MTP and MSC

@KurtE

Just tried your changes with circuitpython on a T4.0 (where free space showed 0) and your fixes seem to have solved that issue:
Capture.jpg
 
@KurtE, @mjs513 - Got really curious to see if DiskIO would recognize a T4.1 loaded with Circuitpython. Loaded the MM with DiskioMB and plugged in the T4.1 that was loaded with circuitpython through a hub along with a thumb drive.

Result is:
Code:
root@Teensy:/128GEXFAT>ld

Found 2 logical drives.

Logical Drive Information For Attached Drives
Logical Drive #:  4: | Volume Label:   128GEXFAT | valid: 1 | Drive Type: USB
Logical Drive #:  5: | Volume Label:   CIRCUITPY | valid: 1 | Drive Type: USB
2 Logical Drives Found
Default Logical Drive: /128GEXFAT/ (4:)
root@Teensy:/128GEXFAT>ls /CIRCUITPY/ 
Volume Label: CIRCUITPY
Full Path: /CIRCUITPY/
.fseventsd/                               <DIR>
lib/                                      <DIR>
.metadata_never_index                            0    January 01 2098 00:00:00
.Trashes                                         0    January 01 2098 00:00:00
code.py                                         22      March 26 2022 08:05:30
boot_out.txt                                    95      March 24 2022 19:19:12
Free Space: 0
root@Teensy:/128GEXFAT>ls 5:
Volume Label: CIRCUITPY
Full Path: 5:
.fseventsd/                               <DIR>
lib/                                      <DIR>
.metadata_never_index                            0    January 01 2098 00:00:00
.Trashes                                         0    January 01 2098 00:00:00
code.py                                         22      March 26 2022 08:05:30
boot_out.txt                                    95      March 24 2022 19:19:12
Free Space: 0
root@Teensy:/128GEXFAT>cat /CIRCUITPY/code.py
print("Hello World!")
root@Teensy:/128GEXFAT>

Was also able to copy files:)
 
Sounds like you are having some fun as well!

Note: This morning I update my sdfat branch with some fixes.

I allowed it to work on the circuitpy drive, but it only has one FAT and the SDFat code assumed two, and would write the backup fat into what would be data area. So detect
that and don't turn on the output mirror...

I was able to download a new version of the .py file, which so far does not automatically restart it... verified if I unplug and replug in, it does work.

Now to look to see instructions again on how Mu editor gets it to restart
 
I did some more hacking on my sketch:
and if you in the terminal monitor type lines starting with $ the rest of the line is sent to the userial object which in this case is the circuit python serial connection.

I have not yet changed the python file to read this in, but another part of the hack is any remaining $ followed by a character in the line are converted to ctrl+char.

So typing: $$c
will enter into REPL mode.

If after that you type $$d - it will do soft reset to run the new python.

My updated python is nothing special:

Code:
import board
import digitalio
import time

led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT
loop_count = 0

while True:
    led.value = True
    time.sleep(0.2)
    led.value = False
    time.sleep(0.2)
    led.value = True
    time.sleep(0.2)
    led.value = False
    time.sleep(0.2)
    led.value = True
    time.sleep(0.2)
    led.value = False
    time.sleep(0.8)
    loop_count += 1
    if (loop_count & 0x1F) == 0:
        print(loop_count)
The last change went from double blink to triple blink
 
I did some more hacking on my sketch:
and if you in the terminal monitor type lines starting with $ the rest of the line is sent to the userial object which in this case is the circuit python serial connection.

I have not yet changed the python file to read this in, but another part of the hack is any remaining $ followed by a character in the line are converted to ctrl+char.

So typing: $$c
will enter into REPL mode.

If after that you type $$d - it will do soft reset to run the new python.

My updated python is nothing special:

Code:
import board
import digitalio
import time

led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT
loop_count = 0

while True:
    led.value = True
    time.sleep(0.2)
    led.value = False
    time.sleep(0.2)
    led.value = True
    time.sleep(0.2)
    led.value = False
    time.sleep(0.2)
    led.value = True
    time.sleep(0.2)
    led.value = False
    time.sleep(0.8)
    loop_count += 1
    if (loop_count & 0x1F) == 0:
        print(loop_count)
The last change went from double blink to triple blink

I updated MTP_Teensy-fast_start and SdFat-Fat12. I got the same results as you did with $$c and $$d. I am not sure how to edit code.py with the above. Actually I need to finish getting the rest of Circuitpython setup and learn how to use it.

EDIT: Ok I figured it how to load it and it works:)
 
Last edited:
With MTP I could not directly edit the file and update directly... Once of the advantages of MSC, where it is an FS object.

But what I have done is to copy the file down using the MTP (i.e. copy it from mtp window to another window... Then edit that file...
Then drag and drop it back into the MTP window, which will ask if you wish to overwrite... Say yes.
 
With MTP I could not directly edit the file and update directly... Once of the advantages of MSC, where it is an FS object.

But what I have done is to copy the file down using the MTP (i.e. copy it from mtp window to another window... Then edit that file...
Then drag and drop it back into the MTP window, which will ask if you wish to overwrite... Say yes.

Thanks. Time to play... Having fun with this:)
 
And now for something somewhat random (what else is new :D )

Thought with our playing with the Circuit Python plugged in to Teensy USB Host, and wanting REPL setup, what if we had
MTP_DUAL_SERIAL and I could use SerialUSB1 for this...

So I hacked a version up. There was also some other reason to this madness, in that for a long time, I thought it would great if we could setup an easier way to configure the USB Type code to have a Alla Carte mode, like I have mentioned before maybe a: Keyboard+Serial+Mtp... So wondered what unexpected things I would hit...
So far only worried about T4.x as well. don't expect it to issue PR on this...

So I knew I would need to touch usb_desc.h, but sort-of unexpectedly also hit usb.c and yield.cpp as they have code conditional on the USB_ type instead of what I would hope, if the functionality was included...
(Anyway pushed up those changes to new branch mtp_dual_serial...

Also had to change MTP_Teensy: For same reason: #if !defined(USB_MTPDISK) && !defined(USB_MTPDISK_SERIAL) && !defined(USB_MTPDISK_DUAL_SERIAL)

Also needed to update boards.txt or in my case I did it in boards.local.txt
Code:
teensy41.menu.usb.mtpserial=MTP Disk Serial (Experimental)
teensy41.menu.usb.mtpserial.build.usbtype=USB_MTPDISK_SERIAL
teensy41.menu.usb.mtpdserial=MTP Disk Dual Serial (Experimental)
teensy41.menu.usb.mtpdserial.build.usbtype=USB_MTPDISK_DUAL_SERIAL

teensyMM.menu.usb.mtpserial=MTP Disk Serial (Experimental)
teensyMM.menu.usb.mtpserial.build.usbtype=USB_MTPDISK_SERIAL
teensyMM.menu.usb.mtpdserial=MTP Disk Dual Serial (Experimental)
teensyMM.menu.usb.mtpdserial.build.usbtype=USB_MTPDISK_DUAL_SERIAL

teensy40.menu.usb.mtpserial=MTP Disk Serial (Experimental)
teensy40.menu.usb.mtpserial.build.usbtype=USB_MTPDISK_SERIAL
teensy40.menu.usb.mtpdserial=MTP Disk Dual Serial (Experimental)
teensy40.menu.usb.mtpdserial.build.usbtype=USB_MTPDISK_DUAL_SERIAL

teensy36.menu.usb.mtpserial=MTP Disk SERIAL (Experimental)
teensy36.menu.usb.mtpserial.build.usbtype=USB_MTPDISK_SERIAL

teensy35.menu.usb.mtpserial=MTP Disk SERIAL (Experimental)
teensy35.menu.usb.mtpserial.build.usbtype=USB_MTPDISK_SERIAL

teensy31.menu.usb.mtpserial=MTP Disk SERIAL (Experimental)
teensy31.menu.usb.mtpserial.build.usbtype=USB_MTPDISK_SERIAL
Again I did not update t3.x...

Also in my case, I was building it under sublimetext so updated tset... (but that is side story).

Then I updated my test sketch CircuitPythonTest.ino and added:

Code:
  #if defined(USB_MTPDISK_DUAL_SERIAL)
  if (userial && userial.available()) {
    while (userial.available()) SerialUSB1.write(userial.read());
  }
  if (SerialUSB1.available()) {
    for (;;) {
      int ch = SerialUSB1.read();
      if (ch == -1) break;
      if (userial)userial.write(ch);
      //Serial.println(ch, HEX);
    }
  }
  #else
  if (userial && userial.available()) {
    Serial.print("$$USerial:");
    while (userial.available()) Serial.write(userial.read());
  }
  #endif

Again I really wish we did not have to case things like: #if defined(USB_MTPDISK_DUAL_SERIAL)
As maybe I might add another configuration... Like I have been hit in other sketches that wish to use SerialUSB1 and I decide to then
build for Tripple Serial and the code no longer works.

Wish we would instead define something and use more like: #if defined(HAS_USB_SERIALUSB1)
or some such define... Actually wish that for most of the different USB types...

And now in window (putty in my case kitty) hit ctrl-c and break into REPL...
screenshot.jpg

As I mentioned completely random...
 
@KurtE - Saw what you were doing on your GitHub. I was wondering how dual serial worked. I think I understand it's purpose now. I use Minicom in Linux a lot with DiskioMB for testing. Been refreshing my memory with using Python. Which isn't much:) Also learning about Circuitpython.

I'll update and checkout your changes...
 
@KurtE - Updated and made the changes to boards.txt. Got the same results as you did:)
In Linux it came out to '/dev/ttyACM0' and '/dev/ttyACM1'.
 
Sounds good. Right now we are playing with code for MicroPython (I know even than 0 about).
But we have it downloading a sketch using the userial off of currently off of PGM, but will thinking of making it a little more fun
and expand on it, like if we drag and drop file in that is an update for our current python sketch, then detect date change and automatically try to update it...

again just experimenting
 
This afternoon I went back to working on my file manager. I realized I had boxed myself into a corner with the way I was allocating memory for directory entries. I all came to light when I was using qsort() to sort the filenames for each of the two panels.

This is the panel struct:
Code:
typedef struct panels panels_t;
struct panels {
	char	 **fname = NULL;
	uint32_t *size = NULL;
	bool	 *attr = NULL;
	bool	 *tag = NULL;
	int entries;
	uint16_t index;
	uint16_t offset;
	uint8_t	 curDrvNum = 4;
	char     *drv;
	char 	 *path;
	bool	 tagFlag = false;
};

And this is the function that allocates memory for each directory entry found:
Code:
int allocDirMem(panels_t *panel) {
	int i = 0;
	File dEntry;
#ifdef sortDirectories
	char buf[256];
#endif
	if(panel->entries != 0) {
		panelFree(panel);
	}
	panel->entries = getDirEntryCnt(panel->path);
	if(panel->entries < 0) return -1;
	dioIM.openDir(panel->path);     // Open the directory
	panel->fname = (char **)malloc(panel->entries*sizeof(char *)); // array of string pointers
	panel->size = (uint32_t *)malloc(panel->entries * sizeof(uint32_t));
	panel->attr = (bool *)malloc(panel->entries * sizeof(bool));
	panel->tag = (bool *)malloc(panel->entries * sizeof(bool));
	for(i = 0; i <= panel->entries; i++) {
		if(i == 0) {
			panel->fname = (char **)realloc(panel->fname,(i+1)*sizeof(char *));
			panel->size = (uint32_t *)realloc(panel->size,(i+1)*sizeof(uint32_t));
			panel->attr = (bool *)realloc(panel->attr,(i+1)*sizeof(bool));
			panel->tag = (bool *)realloc(panel->tag,(i+1)*sizeof(bool));
			if(panel->path[0] == '\0')
				panel->fname[0] = strdup("~");
			else
				panel->fname[0] = strdup("/..");
			panel->size[0] = 0;
			panel->attr[0] = 0;
			panel->tag[0] = false;
		} else {
			panel->fname = (char **)realloc(panel->fname,(i+1)*sizeof(char *));
			panel->size = (uint32_t *)realloc(panel->size,(i+1)*sizeof(uint32_t));
			panel->attr = (bool *)realloc(panel->attr,(i+1)*sizeof(bool));
			panel->tag = (bool *)realloc(panel->tag,(i+1)*sizeof(bool));
			dioIM.readDir(&dEntry, nameBuf); // Read a directory item.
			sprintf(STMP, "/%s", dEntry.name()); // Add foward slash.
			panel->fname[i] = strdup(STMP);
#ifndef sortDirectories
			panel->size[i] = dEntry.size();
			panel->attr[i] = dEntry.isDirectory();
#endif
			panel->tag[i] = false;
		}
	}
	dioIM.closeDir(&dEntry);
	// Sort directory and read in file sizes and attribute.
#ifdef sortDirectories
	if(panel->entries > 0)
		qsort(panel->fname+1, panel->entries, sizeof(char *), fnameCmp);    
	for(i = 1; i <= panel->entries; i++) {
		sprintf(buf,"%s%s%s",panel->drv,panel->path,panel->fname[i]);
		if(!dioIM.open(&dEntry, buf, FILE_READ))
			printf("Failed to open %s\n",panel->fname[i]);
		panel->size[i] = dEntry.size();
		panel->attr[i] = dEntry.isDirectory();
		dioIM.close(&dEntry);
	}
#endif
	return 0;
}

And finally the compare function:
Code:
// qsort struct compare function (directory fname field only) */ 
int fnameCmp(const void *a, const void *b) 
{ 
	char * ppc1 = *(char **)a;
	char * ppc2 = *(char **)b;
  return strcmp(ppc1, ppc2);
}

With the way I have the panels struct set up I can only sort 'fname' fields which leads to the file size and file attributes being incorrect. I can't sort by struct. only by fname. The work around was this:
Code:
	for(i = 1; i <= panel->entries; i++) {
		sprintf(buf,"%s%s%s",panel->drv,panel->path,panel->fname[i]);
		if(!dioIM.open(&dEntry, buf, FILE_READ))
			printf("Failed to open %s\n",panel->fname[i]);
		panel->size[i] = dEntry.size();
		panel->attr[i] = dEntry.isDirectory();
		dioIM.close(&dEntry);
	}
Which between all of it creates a noticeable slowdown when switching panels with a large amount of directory entries.
So I think I will have to have a separate file info structure. Something that is just the fname, size and attributes fields that should be separate from panel info anyway as there are only two instances of panels.
This will mean a huge re-write:( Another large distraction...

Any input or ideas are very welcome.
 
Sounds like you will be busy! The memory management can be a real Pain...

With MTP the file list was simply a logical array of fixed length structures where each entry had everything including large name buffer, which was a waste or memory. Is/was stored on FS, where you could seek to the item by simply multiply the item number by size and then read in... I played with a few different approaches, like have each item variable length and maybe keep list of indexes to locations... Later changed to a chunks approach, where I pack each chunk with several file items where the names stored at end of chunk, left a certain amount of free space in each so that could handle some amount of renaming files within chunk. This did cut down number of reads/writes
But not sure if that would help in your case or not.

Good luck.
 
Thanks for the response Kurt. When I originally started FM about 3-4 years ago the memory allocation is what took the longest to setup. I was constantly finding memory leaks. I eventually with a lot of web searching and hair pulling came up with what I have now. It seems to work ok except for sorting the directories. I will check out what you did in MTP before I paint myself into another corner with it:) It's just something to experiment with and learn more about C++.
 
Hi Kurt,
could you provide some installation instructions for using the MTP_teensy from github. I tried to just create a directory in arduino/hardware/teensy/avr/libraries/MTP and paste all the files in MTP
however when I tried to run your example program ( examples--> simplified examples -->example_3_simple_SD) I run into this error:

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp: In member function 'void MTP_class::loop()':
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp:244:26: error: 'usb_mtp_status' was not declared in this scope
if (return_code && usb_mtp_status == 0x01) {

I am using a windows 10 system and Teensy 4.1 and arduino IDE
this error happens during code compilation itself
any help would be great
Thanks
 
What I do, is to use github...

That is I use git clone... But other methods would be to download zip file and then have Arduino install the zip file... Which is more or less like what you mentioned.

Note: The MTP_Teensy code as well as other stuff is in a state of Flux as: @Paul brought into SDFat updates from the main SDFat, which caused some compile issues.
I know that for the Beta1 code, some of us did update some of the examples.

Note I just compiled it for Teensy MicroMod using IDE 1.8.19 and the new Teensyduino beta release. Note: I am using private copies of many of the libraries, but they should be in sync with what was
in the beta.
Code:
Memory Usage on Teensy MicroMod:
  FLASH: code:83252, data:14412, headers:8828   free for files:16408580
   RAM1: variables:16544, code:81544, padding:16760   free for local variables:409440
   RAM2: variables:28800  free for malloc/new:495488
Multiple libraries were found for "SD.h"
 Used: C:\Users\kurte\Documents\Arduino\libraries\SD
 Not used: C:\arduino-1.8.19\libraries\SD
 Not used: C:\arduino-1.8.19\hardware\teensy\avr\libraries\SD
Multiple libraries were found for "SdFat.h"
 Used: C:\Users\kurte\Documents\Arduino\libraries\SdFat
 Not used: C:\arduino-1.8.19\hardware\teensy\avr\libraries\SdFat
Using library SD at version 2.0.0 in folder: C:\Users\kurte\Documents\Arduino\libraries\SD 
Using library SdFat at version 2.1.2 in folder: C:\Users\kurte\Documents\Arduino\libraries\SdFat 
Using library SPI at version 1.0 in folder: C:\arduino-1.8.19\hardware\teensy\avr\libraries\SPI 
Using library MTP_Teensy at version 1.0.0 in folder: C:\Users\kurte\Documents\Arduino\libraries\MTP_Teensy
What you should check is at the end you should get some summary like this... Although again this one completed.
But look at what SD and SDFat directories it is building with and make sure they are the Teensy versions.
 
Code:
Arduino: 1.8.16 (Windows 10), TD: 1.56, Board: "Teensy 4.1, MTP Disk (Experimental), 600 MHz, Faster, US English"


C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp: In member function 'void MTP_class::loop()':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp:244:26: error: 'usb_mtp_status' was not declared in this scope

       if (return_code && usb_mtp_status == 0x01) {

                          ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp:269:7: error: 'usb_mtp_status' was not declared in this scope

   if (usb_mtp_status != 0x01) {

       ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp: In member function 'uint32_t MTP_class::GetObject(MTP_class::MTPContainer&)':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp:569:9: error: 'usb_mtp_status' was not declared in this scope

     if (usb_mtp_status != 0x01) {

         ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp: In member function 'uint32_t MTP_class::GetPartialObject(MTP_class::MTPContainer&)':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp:609:9: error: 'usb_mtp_status' was not declared in this scope

     if (usb_mtp_status != 0x01) {

         ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp: In member function 'bool MTP_class::receive_bulk(uint32_t)':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp:1561:7: error: 'usb_mtp_status' was not declared in this scope

   if (usb_mtp_status != 0x01) return false;

       ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp: In member function 'int MTP_class::transmit_bulk()':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp:1591:7: error: 'usb_mtp_status' was not declared in this scope

   if (usb_mtp_status == 0x01) {

       ^

Multiple libraries were found for "SD.h"

 Used: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SD

 Not used: C:\Program Files (x86)\Arduino\libraries\SD

Using library SD at version 2.0.0 in folder: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SD 

Using library SdFat at version 2.1.0 in folder: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SdFat 

Using library SPI at version 1.0 in folder: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SPI 

Using library MTP_Teensy-main at version 1.0.0 in folder: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main 

Error compiling for board Teensy 4.1.
Thanks for the reply, yeah it looks like SD and SDFat used are the Teensy versions
 
Code:
Arduino: 1.8.16 (Windows 10), TD: 1.56, Board: "Teensy 4.1, MTP Disk (Experimental), 600 MHz, Faster, US English"

...

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp: In member function 'void MTP_class::loop()':


C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp:244:26: error: 'usb_mtp_status' was not declared in this scope

       if (return_code && usb_mtp_status == 0x01) {

                          ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MTP_Teensy-main\src\MTP_Teensy.cpp:269:7: error: 'usb_mtp_status' was not declared in this scope

   if (usb_mtp_status != 0x01) {

       ^
Thanks for the reply, yeah it looks like SD and SDFat used are the Teensy versions

I would double check that you have a matching header file with the .cpp.

Actually now looking at it, the variable usb_mtp_status should be defined within usb_mtp.h
On my build 1.8.19 with ....\hardware\teensy\avr\cores\teensy4\usb_mtp.h

again this is assuming that you are building with either USB type set MTP DISK or if modifiecations made MTP + Serial
 
Yeah I do have the MTP_Teensy.h header file
I am using USB type as MTP disk when compiling
I tried installing the latest IDE(1.8.19) but still get the same error
I tried another example(MTP_logger) from the MTP_teensy library and get a different error
Code:
C:\Users\maher\OneDrive\Documents\Arduino\libraries\MTP_Teensy-main\examples\mtp-logger\mtp-logger.ino: In function 'void loop()':
C:\Users\maher\OneDrive\Documents\Arduino\libraries\MTP_Teensy-main\examples\mtp-logger\mtp-logger.ino:149:5: error: 'mtpd' was not declared in this scope
     mtpd.loop();
     ^

is there any additional installation step(copying files into core or something) other than just downloading the zip folder
 
AFAICS, usb_mtp_status is only introduced in latest beta.
At least, on my production system TD 1.56 it is not there
 
I tried installing the latest IDE(1.8.19) but still get the same error
...
is there any additional installation step(copying files into core or something) other than just downloading the zip folder

You need at least Teensyduino 1.57-beta1. In Arduino, click Help > About to check.

Get 1.57-beta1 here:
https://forum.pjrc.com/threads/70196-Teensyduino-1-57-Beta-1

All this new stuff in MTP_Teensy came after Teensyduino 1.56, so if you have 1.56 installed you'll get errors like usb_mtp_status undefined.
 
Thanks Paul, I updated to Teensyduino 1.57-beta1 and now able to compile the examples without the usb_mtp_status error.
sorry to ask a stupid question, with the example_3_simple_SD will I be able to access the Teensy SD card from my PC and download files to my PC
My Teensy hasn't arrived yet so unable to load the program and test
Thanks again
 
Maybe not a stupid question. Seems we're not actually saying clearly 1.57-beta1 is required.

@Kurt - Could you edit msg #1 to say 1.57-beta1 is needed and link to that announcement thread with the download links?

Might also be good to mention it in the README.md file on github.

We could also do something like this in the code....

Code:
#if TEENSYDUINO < 157
#error "Teensyduino 1.57-beta is required, get it at https://forum.pjrc.com/threads/70196"
#endif
 
Hi Paul and all,

Quick updates - I did put a quick note in first message. Will update the main branch as well to direct others to get the beta releases.

Sorry I have been distracted working on the USBHost MSC support. I have been extending the Beta1 code and integrate in more of the functionality .

I am currently working in a new Branch: https://github.com/KurtE/USBHost_t36/tree/fs_integration_part2

Warning this is a WIP and many things in it are likely to change. Paul, I have your previous notes and need to compare some of the stuff here with what was mentioned.

But we do have more pieces put into place, like extended partitions and a first pass at having the Drive code enumerate the partitions and allow the USBFilesystem object the ability to claim them or not.

I added in an extended version of the DriveInfo sketch called DriveInfoAll, where I defined 2 drives and 8 file system objects

Some of the changes done so far include:

a) USBFilesystem objects are now derived from class USBFSBase. and more ore less just have the functions in it for claimPartition/releasePartition

Note: the USBFilesystem object now have an init() function which will add them to a list...


b) So far I have left in the manual way to allocate specific filesystem object (plus added end) to release it, Although I know there are a few things here, if I am going to leave it. There is also now an end() method which frees up the underlying data. (Need to add code to check if it is already in use if not and succeed, remove from free list... And likewise if end() called return it.

c) First pass at having the USBDrive object to enumerate all of it's partitions and asks each free USBFileSystem object (actually USBFSBase object) if they would like to claim the drive. Currently this method is called: startFilesystems() (we already had begin() to make sure the drive was ready), Note: this function actually uses the findPartition method, which was extended slightly to return additional information.

For each partitions it finds it will ask each of the Free File System objects in the list if they would like to claim the partition. the code then removes that FS object from free list and adds it to list of ones associated with that drive. When that drive goes away, it will release each of those objects and put them back into free list.

d) I added pdrive->filesystemsStarted() as a way to see if a drive object has been started or not. Why supposed after you run through and see the list of fileystems and the like, you unplug that disk and plug in a new one... Needed a way to detect this as, have one pass you know that DISK1 is a valid disk and then the next pass DISK1 is still valid but it is not the same one...

e) The GPT enumeration is slightly different in that the enumerator with DISK does not check if it likes the GUID, instead it passes it off to the partition claim code and let them decide if they understand it... So should allow other implementations to to work.

Still lots more to go and consider.

1) Like: should the functionality of enumeration code happen in the background when a new drive is detected?

2) Are there better ways to detect when the drive list and/or file system list changes? Right now we manually walk lists. But should there instead be some form of something changed flag you could query for? Or notification/callbacks? If so what? eventResponder? If so on what

For example: if the user plugs in a new disk with 3 partitions, my code may want to add those to MTP list? Who is responsible for detecting this...

3) Still wonder if we should convert this library to a new standard library where code is in src directory? Turn on option to have it create an archive file. This way I believe that only those source files that contain something your sketch uses, will be pulled in.

Probably enough rambling for this post.
 
Back
Top