Teensyduino File System Integration, including MTP and MSC

Ok challenge accepted - with the latest changes to MTP_Teensy and the SDFat/SD/FS (note beyond beta2) I used MTP_test to create a Program - PSRAM - QSPI (Flash) disk:
View attachment 26177

Tested that all disks are there and working. In other words I can copy a wav file and play it via windows media player. So yes they do work together. I used the original beta board for test

Nice photoshop Mike - post the .hex :)
 
Tim, ok. Looks like the flash died a few minutes ago.. the first time i'm seeing this.
@Michael: Ok... thanks..

Bummer @Frank - maybe some flux and reflow and cleanup? You said it was pre-soldered - so it should be good ... but worth a try.
 
Actually window snipping tool :) haven't used photoshop in years

View attachment 26178

JUST TAUNTING YOU MIKE :)

TauntMTP.png

Indeed - It works as advertised!

Note: that is Win 11 - it asked 'What to do with Teensy' - and I picked 'explore disk'
 
Ok.. new board, new chip, new fun. Works.

(Will take a close look to the other board tomorrow - maybe it's just a problem with soldering)
 
Good Morning all including Paul, mjs513, wwatson ... : (maybe) Probably afternoon by the time I type this ;)
Sorry in advance it probably will be reasonably long.

Now that a lot of the FS only stuff. I was thinking about how best to integrate the MSC functionality into the system and how to then if desired to expose disks or volumes through MTP.

this is integrated and interpreting some previous comments, that were either on forum or email...

@Paul @wwatson @mjs513 - Hopefully I am not too far off and understanding and maybe direction to go.

Currently in the USBHost library there is a class: msController that is a "normal" USBHost object, that is setup to handle when a Storage device like hard disk, or Memory Stick is plugged in. So the normal USB enumeration stuff happens here and for example if your code is setup to include:
Code:
#include "USBHost_t36.h"

USBHost myusb;
USBHub hub1(myusb);
USBHub hub2(myusb);

msController msDrive1(myusb);
msController msDrive2(myusb);
When the first drive is plugged in, then likely the msDrive1 one will bool function will return true... And the code does all of the necessary stuff to talk to the drive at a low level (SCSI)...

Then there is the code in the library UsbMscFat (MSC), which deals with the actual storages on the disk, which I subdivide into two (maybe more) pieces

There is the PFsLib - portion, which is very much like the FsLib in SDFat. The main difference is that PFsLib works with Partitions, so for example the formatting code you pass in a partition number and it only formats that partition. Whereas SDFat format code will format the entire drive as one partition regardless of if the drive was previously setup with partitions.
Will be interesting to see where this code should reside.

Then the rest of the library has to do with then taking the one or more logical Drive objects and using them.
In the mscFS.h file There is the MSCClass which is derived from FS.

The begin method of the MSCClass you pass it in one of the msController objects as well as optionally which partition this object should work with... And from here you have the normal FS capabilities like file open...
So current MTP integration, we do something like define an array of 3 "Drive" objects and lets say 8 of the Volume objects and then we have code we run at loop time, to scan which drives have changed state (connected or removed) and check in the connected state, if this drive has partitions, then we iterate through calling the begin for the next free volume object... If drive went away we check for any volumes that were using that drive and close them...

Another option might be: Sorry if not completely fleshed out:
Suppose we have the sketch setup as:

Code:
USBHost myusb;
USBHub hub1(myusb);
USBHub hub2(myusb);

msController msDrive1(myusb);
msController msDrive2(myusb);

msVolume msVol1(myusb);
msVolume msVol2(myusb);
msVolume msVol3(myusb);
msVolume msVol4(myusb);
msVolume msVol5(myusb);
Each of these drives and volumes at creation time link themselves into lists...
Then when USBHost code detects the new drive, it works like current stuff and finds an unused msController object, and claims it like today. Then potentially this code could in theory, check for MBR and if it has one, it could iterate over the partitions, and if they are types we can handle and we have a free volume object, then volume object would be claimed by that controller object...
And in the end user code can detect if drives or volumes are there by boolean test...

Does this make sense? Should we instead of having to declare Volume object simply have them magically be created? Or should each Controller object have setup lets say 4 such objects...

Then there is the other half of the issue associated with MTP.
So MSC just found a new drive with two partitions. How does MTP get notified of this? Of course this is also similar to how should we handle SD drives which did not have a card in it and we now detected that now there is...

Should the user code call addStorage for all 5 of these volumes at setup time, and have them show up as not valid? Or should the appear when a drive is plugged in...

Lots more to this, but wondering what directions we should aim toward?

Ok know I quoted a the whole post but figured at least get it on the latest page for the response. Think this is pretty much what we were doing with the original call back function for MSC drives in MTP. Where we define the mscControllers and USBHub:
Code:
#include <USB_MSC_MTP.h>
USBHost myusb;
USBHub hub1(myusb);
USBHub hub2(myusb);

// start off with one controller.
msController msDrive[USE_MSC_FAT](myusb);
where USE_MSC_FAT is the number of allowable drives.

then in the checkUSBStatus function (which we put in the loop) it either adds the drives/partitions or removes them automatically. Here is that funciton:
Code:
void USB_MSC_MTP::checkUSBStatus(bool fInit) {

  bool usb_drive_changed_state = false;
  myusb.Task(); // make sure we are up to date.
  if (fInit) {
    // make sure all of the indexes are -1..
    for (int ii = 0; ii < USE_MSC_FAT_VOL; ii++) {
      msc_storage_index[ii] = (uint16_t)-1;
      msc_drive_index[ii] = -1;
    }
    for (int ii = 0; ii < USE_MSC_FAT; ii++)
      msDrive_previous[ii] = false;
  }

  for (int index_usb_drive = 0; index_usb_drive < USE_MSC_FAT;
       index_usb_drive++) {
    msController *pdriver = &msDrive[index_usb_drive];
    if (*pdriver != msDrive_previous[index_usb_drive]) {
      // Drive status changed.
      msDrive_previous[index_usb_drive] = *pdriver;
      usb_drive_changed_state = true; // something changed
      if (*pdriver) {
        Serial.println("USB Drive Inserted");
        mbrDmp(pdriver);

        // Now lets see if we can iterate over all of the possible parititions
        // of this drive
        for (int index_drive_partition = 1; index_drive_partition < 5;
             index_drive_partition++) {
          // lets see if we can find an available msc object to use...
          for (int index_msc = 0; index_msc < USE_MSC_FAT_VOL; index_msc++) {
            if (msc_storage_index[index_msc] == (uint16_t)-1) {
              // lets try to open a partition.
              Serial.printf("  Try Partiton:%d on MSC Index:%d\n",
                            index_drive_partition, index_msc);
              if (msc[index_msc].begin(pdriver, false, index_drive_partition)) {
                Serial.println("    ** SUCCEEDED **");
                // now see if we can get the volume label.
                char volName[20];
                if (msc[index_msc].mscfs.getVolumeLabel(volName,
                                                        sizeof(volName))) {
                  Serial.printf(">> USB partition %d volume ID: %s\n",
                                index_drive_partition, volName);
                  snprintf(nmsc_str[index_msc], sizeof(nmsc_str[index_msc]),
                           "MSC%d-%s", index_usb_drive, volName);
                } else
                  snprintf(nmsc_str[index_msc], sizeof(nmsc_str[index_msc]),
                           "MSC%d-%d", index_usb_drive, index_drive_partition);
                msc_drive_index[index_msc] = index_usb_drive;
                msc_storage_index[index_msc] = storage_.addFilesystem(
                    msc[index_msc], nmsc_str[index_msc], this,
                    (uint32_t)(void *)&msc[index_msc]);
// addFSToStorage(true, index_msc); // do the work to add us to the storage
// list.
#if 0

                elapsedMicros emmicro = 0;
                uint64_t totalSize = msc[index_usb_drive].totalSize();
                uint32_t elapsed_totalSize = emmicro;
                uint64_t usedSize  = msc[index_usb_drive].usedSize();
                Serial.printf("new Storage %d %s %llu(%u) %llu(%u)\n", index_msc, nmsc_str[index_msc], totalSize, elapsed_totalSize, usedSize, (uint32_t)emmicro - elapsed_totalSize);
#endif
                if (!fInit)
                  mtpd_.send_StoreAddedEvent(msc_storage_index[index_msc]);
              }
              break;
            }
          }
        }
      } else {
        // drive went away...
        for (int index_msc = 0; index_msc < USE_MSC_FAT_VOL; index_msc++) {
          // check for any indexes that were in use that were associated with
          // that drive
          // Don't need to check for fInit here as we wont be removing drives
          // during init...
          if (msc_drive_index[index_msc] == index_usb_drive) {
            mtpd_.send_StoreRemovedEvent(msc_storage_index[index_msc]);
            storage_.removeFilesystem(msc_storage_index[index_msc]);
            msc_storage_index[index_msc] = (uint16_t)-1;
            msc_drive_index[index_msc] = -1;
          }
        }
      }
    }
  }

  if (usb_drive_changed_state && !fInit) {
    delay(10); // give some time to handle previous one
    mtpd_.send_DeviceResetEvent();
  }
}
would kind of like to see something like this between USBHost and MTP where its automatic recognition etc. But as you said some how some of PFsLIb will have to be incorporated into FS or USBHost. Think the callback for MSC is in the MTP_Teensy repository on the archived branch.
 
Ok.. new board, new chip, new fun. Works.

(Will take a close look to the other board tomorrow - maybe it's just a problem with soldering)

Reflowing has helped at least three PSRAM users - interesting if it helps here.

NOTE from before - was this and backwards WRT "M" and "Q": pjrc.com/store/ic_mkl02_t4.html
Code:
Supported Chips
...
An IMXRT microcontroller and flash memory chip must be paired with this MKL02 to form a working system. No programming or other setup is needed on these other chips. Blank chips sold by distributors are used.

IMXRT1062DV*6B or IMXRT1062DV*6A (NXP)
W25Q16JV*IM (Winbond)
W25Q64JV*IM (Winbond)
IMXRT1062 chips with extended temperature range are likely to work, but have not been tested.

Winbond flash memory chips with a "Q" at the end of their part number do not work. Only the "M" parts are supported.
 
Reflowing has helped at least three PSRAM users - interesting if it helps here.

NOTE from before - was this and backwards WRT "M" and "Q": pjrc.com/store/ic_mkl02_t4.html
Code:
Supported Chips
...
An IMXRT microcontroller and flash memory chip must be paired with this MKL02 to form a working system. No programming or other setup is needed on these other chips. Blank chips sold by distributors are used.

IMXRT1062DV*6B or IMXRT1062DV*6A (NXP)
W25Q16JV*IM (Winbond)
W25Q64JV*IM (Winbond)
IMXRT1062 chips with extended temperature range are likely to work, but have not been tested.

Winbond flash memory chips with a "Q" at the end of their part number do not work. Only the "M" parts are supported.

have to double check that "Q" think I tested with some like the 256 and 512 Q chips - have to double check since its been a while and have to find all my chips. Some may be on boards
 
have to double check that "Q" think I tested with some like the 256 and 512 Q chips - have to double check since its been a while and have to find all my chips. Some may be on boards

Should have made clear - that is LINK/text to bootloader chips - for base Teensy PCB boot flash - not add on QSPI ...
 
@KurtE - Post #275, This is kind of what I was testing with diskIO. Not totatly compatble with LittleFS. mostly because diskIO did not conform to FS integration YET:)
 
@KurtE - Post #275, This is kind of what I was testing with diskIO. Not totatly compatble with LittleFS. mostly because diskIO did not conform to FS integration YET:)

Again DiskIO looks like some very interesting stuff, that I would like to play with more. I can imagine both LittleFs and SD could be a challenge, if the desire to automatically detect different storage areas, without the something in the sketch describing where/what the storages are. Like SD on MicroMod - It does define a SDIO setup, but only I believe 1 of their breakout boards use it, the others use simple SPI...

I think what I am suggesting from my impression of what Paul described earlier, was the desire to repackage some of the MSC and USBHost code supporting MSC along with the run time code @mjs513 mentioned back in post #308.
That is to treat the MSCController class like it was a HidParser like object(), and treat the MSCClass objects sort of like HID objects. Probably derived from both FS and some other interface like: USBFSObject...

So again your code could setup to simply define lets say 2 MSController objects and maybe 4 MSCClass (or maybe call it something like MSCVolume...
When these are defined, their constructors will add them to lists of objects...

The main differences in functionality is simply how this Volume objects startup and shutdown. Today this is all done by application code, that is today we have code, that needs to be called by application in their loop method,
Which we loop through all of the objects finding out if they are now valid and were not valid the last time we checked.

If we find a drive like that we then try to check to see which of the partitions are valid (1-4), and if we find one we check our list of "Volume" objects we have for one not in use, and then we call it's begin method, with a pointer to the Controller object and which partition we found... We then do additional stuff for MTP, but is different issue.

Instead the idea is that maybe the claim method of the MSController object, would in the case of when it is going to claim the new USB drive, it would then itself read in the MBR and find which partitions are valid, and it would then find a free Volume object and call it's logical begin method, ...

And likewise on MSCControler object disconnect method it would iterate over the up to 4 volumes that could be using it and call their logical end method...

Does this make sense?

There is still a second half to this, which is how does MTP find out about which volumes have been added or removed. We also have a similar issue with how do we detect if SD Cards are inserted or removed?
We do have the new method on FS:
virtual bool mediaPresent() {
return true;
}

But it is the age of question who is going to call this and process it? It would be nice if there was some sorts of notification systems, like:
File System changed, or List of FS changed, or with USBHost list of active devices changed or Hid devices changed.... But that is probably another long post dedicated to some of these issues.

Kurt
 
@KurtE - I think I see what you are talking about and where it's headed. As far as detecting if an MSC device has been connected or disconnected there are to entries in the msDriveInfo struct. msDriveInfo.connected and msDriveInfo.initialized. When a drive is plugged in claim() will set msDriveInfo.connected = true and msDriveInfo.initialized = false. Then when mscInit() is called and the drive is successfully initialized it sets msDriveInfo.initialized = true. If the drive is unplugged the disconnect() callback will set these two to false. The checkConnectedInitialized() function is used to check for this:
Code:
// Check if drive is connected and Initialized.
uint8_t msController::checkConnectedInitialized(void) {
	uint8_t msResult = MS_CBW_PASS;
#ifdef DBGprint
	print("checkConnectedInitialized()");
#endif
	if(!msDriveInfo.connected) {
		return MS_NO_MEDIA_ERR;
	}
	if(!msDriveInfo.initialized) {
		msResult = mscInit();
		if(msResult != MS_CBW_PASS) return MS_UNIT_NOT_READY; // Not Initialized
	}
	return MS_CBW_PASS;
}

Right now I call this before doing any single access to the drive.
Just before upgrading to Ubuntu 20.04 I had claim() calling mscInit() using eventResponder. I lost that version during the upgrade but it was not that hard to set up.
There are probably more efficient ways to do this:)

Warren
 
Resoldered the faulty board with NOR flash.

My theory is that when I took it out of the cold cellar, it warmed up and the chip lost contact.
I have re-soldered - works now.
 
@KurtE - I think I see what you are talking about and where it's headed. As far as detecting if an MSC device has been connected or disconnected there are to entries in the msDriveInfo struct. msDriveInfo.connected and msDriveInfo.initialized. When a drive is plugged in claim() will set msDriveInfo.connected = true and msDriveInfo.initialized = false. Then when mscInit() is called and the drive is successfully initialized it sets msDriveInfo.initialized = true. If the drive is unplugged the disconnect() callback will set these two to false. The checkConnectedInitialized() function is used to check for this:
Code:
// Check if drive is connected and Initialized.
uint8_t msController::checkConnectedInitialized(void) {
	uint8_t msResult = MS_CBW_PASS;
#ifdef DBGprint
	print("checkConnectedInitialized()");
#endif
	if(!msDriveInfo.connected) {
		return MS_NO_MEDIA_ERR;
	}
	if(!msDriveInfo.initialized) {
		msResult = mscInit();
		if(msResult != MS_CBW_PASS) return MS_UNIT_NOT_READY; // Not Initialized
	}
	return MS_CBW_PASS;
}

Right now I call this before doing any single access to the drive.
Just before upgrading to Ubuntu 20.04 I had claim() calling mscInit() using eventResponder. I lost that version during the upgrade but it was not that hard to set up.
There are probably more efficient ways to do this:)

Warren
Right now I am sort of playing with the code and experimenting of moving most of the code into USBHost.

@Paul - I am experimenting with moving all of the USBHost code into src directory, which has sub-directories. Why... A few reasons, incluiding that is the standard library layout. But also it allows me to move code into the sub-directories and still have it build.

So right now I have sub-directories of PFSLib and MSC.

I am right now playing with two objects: the msController, and msFilesystem host objects, with beginning example sketch, including something like:
Code:
// Add USBHost objectsUsbFs
USBHost myusb;
USBHub hub1(myusb);

// MSC objects.
msController drive1(myusb);
msController drive2(myusb);
msFilesystem msFS1(myusb);
msFilesystem msFS2(myusb);
msFilesystem msFS3(myusb);
msFilesystem msFS4(myusb);
msFilesystem msFS5(myusb);
These FS based objects will add themselves to a linked list that the msController objects will know about and will be derived both by FS as well as some interface again that the controllers will talk. Still working on this. Will have most of the things the HID one has like the bool operator, ability to get the vendor, product information... Plus the code controller will call like claim, and release... Again all of the glue and pieces are not there yet, but thought I would mention it as to get feedback... I have a WIP branch of FS_Integration_MSC, the test sketch (in MTP_Teensy project) USB_MTP-logger is also WIP ... but using it so far to see if things compile...

Again nothing done yet.

Resoldered the faulty board with NOR flash.

My theory is that when I took it out of the cold cellar, it warmed up and the chip lost contact.
I have re-soldered - works now.

Glad its now working.
I second that. I have had a few cases like that. Sometimes as I maybe had not fully cleaned the flux from the joints...
 
@KurtE - Downloaded your latest USBHost_t36 (FS_Integration_MSC) branch, SD and SdFat. After studying the code for a while I decided to play with USB_MTP-logger for testing. IT WORKS:)

What I changed in USB_MTP-logger.ino:
Code:
[COLOR="#FF0000"]FS *mscDisk = &msFS1;[/COLOR]


void setup() {

  // Open serial communications and wait for port to open:
  Serial.begin(115200);
  while (!Serial && millis() < 5000) {
    // wait for serial port to connect.
  }
  Serial.print(CrashReport);
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  delay(3000);

  myusb.begin();

  Serial.print("Initializing MSC Drives ...");
  
  mtpd.begin();
  Serial.println("\nInitializing USB MSC drives...");
[COLOR="#FF0000"]
if(!msFS1.begin(&drive1,true,1)) Serial.println("Failed...");
drive1.mscInit();   
storage.addFilesystem(*mscDisk, (const char *)"USB",(void *)"", 0);
[/COLOR]
  Serial.println("MSC and MTP initialized.");

  menu();
}

The USB drive showed up in Ubuntu as an MTP drive. I was able copy, delete files with the file manager. File sizes were shown and looked right.

Tycomm output:
Code:
Menu Options:
	1 - List USB Drives (Step 1)
	2 - Select USB Drive for Logging (Step 2)
	l - List files on disk
	e - Erase files on disk
	s - Start Logging data (Restarting logger will append records to existing log)
	x - Stop Logging data
	d - Dump Log
	h - Menu


 Space Used = 431808512
Filesystem Size = 15455567872
Music/
  armaged.wav                         56862764
  ThePaperboysMolinos.wav             35638654
  ThePaperboysMolinosI'veJustSeenaFace.wav  36380570
  StatusQuoWhateverYouWant.wav        60148386
  YoureLazyJimmyBarnesJoeBonamassa.wav  102878370
  DeffLepardAnimal.wav                43025216
SDTEST1.WAV                           16787550
SDTEST2.WAV                           16425698
SDTEST3.WAV                           13617358
SDTEST4.WAV                           17173152
32MEGfile.dat                         32768512
mtpindex.dat                          0

I only setup 1 USB drive to test with. I know this is just the beginning of development on it but it's cool to see working so far.
 
Good to hear.

So far that is mostly all of your stuff moved around. Does not have the glue in that one, to hopefully activate a partition once the drive is there.

I have code now that I am testing, but it is going boom.. Maybe where the glue is, so investigating.
 
Good to hear.

So far that is mostly all of your stuff moved around. Does not have the glue in that one, to hopefully activate a partition once the drive is there.

I have code now that I am testing, but it is going boom.. Maybe where the glue is, so investigating.

Checking further I noticed a couple of things I was doing wrong. Fixed those and it still worked. Right now I am playing with two partitions on a flash drive. They are working.
I tried two USB flash drives setting up one of them for two partitions and the other for one partition. One problem I see is you don't know which device will be claimed first. If MSC claims the drive1 with two partitions first and I have setup that drive for one partition one partition is left out. I have found that I can reset the Teensy or power cycle it and it is very unpredictable which device will show up first.

Anyway I am enjoying this:)

EDIT: I really hate when things go BOOM:)
 
Last edited:
I just pushed up changes to the USBHost branch and the MTP_Teensy.

Where my code that says maybe up to two drives and 5 file systems,...

The code is now setup and after the drive is claimed, it sets flag and then uses the Task() method (called from mtpd.Task().
And then does the enumeration. It did not like this on the claim code...

With that The single partition drive I plugged in was claimed :D

The sketch code is pretty stupid with this:
Created three arrays:
Code:
msFilesystem *pmsFS[] = {&msFS1, &msFS2, &msFS3, &msFS4, &msFS5};
bool pmsFS_added_to_mtp[] = {false, false, false, false, false};
const char * pmsFS_display_name[] = {"msFS1", "msFS2", "msFS3", "msFS4", "msFS5"};

And the loop code:
Code:
    bool storage_changed = false;
    for (uint8_t i = 0; i < (sizeof(pmsFS)/sizeof(pmsFS[0])); i++) {
      if (*pmsFS[i] && !pmsFS_added_to_mtp[i]) {
        storage.addFilesystem(*pmsFS[i], pmsFS_display_name[i]);
        pmsFS_added_to_mtp[i] = true;
        storage_changed = true;
      }
      // will add next part here..
    }
    if (storage_changed) mtpd.send_DeviceResetEvent();
And it was detected and added to list :D

screenshot.jpg

So progress there... Did not put in code to remove it from the MTP list yet...
 
I just pushed up changes to the USBHost branch and the MTP_Teensy.

Where my code that says maybe up to two drives and 5 file systems,...

The code is now setup and after the drive is claimed, it sets flag and then uses the Task() method (called from mtpd.Task().
And then does the enumeration. It did not like this on the claim code...

With that The single partition drive I plugged in was claimed :D

The sketch code is pretty stupid with this:
Created three arrays:
Code:
msFilesystem *pmsFS[] = {&msFS1, &msFS2, &msFS3, &msFS4, &msFS5};
bool pmsFS_added_to_mtp[] = {false, false, false, false, false};
const char * pmsFS_display_name[] = {"msFS1", "msFS2", "msFS3", "msFS4", "msFS5"};

And the loop code:
Code:
    bool storage_changed = false;
    for (uint8_t i = 0; i < (sizeof(pmsFS)/sizeof(pmsFS[0])); i++) {
      if (*pmsFS[i] && !pmsFS_added_to_mtp[i]) {
        storage.addFilesystem(*pmsFS[i], pmsFS_display_name[i]);
        pmsFS_added_to_mtp[i] = true;
        storage_changed = true;
      }
      // will add next part here..
    }
    if (storage_changed) mtpd.send_DeviceResetEvent();
And it was detected and added to list :D

View attachment 26192

So progress there... Did not put in code to remove it from the MTP list yet...

Will update and test...
 
I just pushed up changes to the USBHost branch and the MTP_Teensy.

Where my code that says maybe up to two drives and 5 file systems,...

The code is now setup and after the drive is claimed, it sets flag and then uses the Task() method (called from mtpd.Task().
And then does the enumeration. It did not like this on the claim code...

With that The single partition drive I plugged in was claimed :D

The sketch code is pretty stupid with this:
....
And it was detected and added to list :D

View attachment 26192

So progress there... Did not put in code to remove it from the MTP list yet...

Looks like it working - have 3 drives attached - 1 has 2 partitions and all are accessible and writable:
Capture.PNG

Also by accident I attached a SSD by itself and it worked as well :)

Only one issue I see that I guess at some point we need to talk about that came to mind. Since I couldn't tell which drive was which, is that the drive name should be updated, like before, the volume name or a way to show the partition number for the drive.

But it does work. Had to try format out of curiousity
 
@Paul, @wwatson @mjs513 and all...

Would be nice to get rid of that code, that runs in loop, to say did something change...

If I were doing this just for me, I would tend to create a new Callback class that register with this FS object, that has different methods, that the FS object would call in some conditions, in this case starting off with
This FS object has been claimed (or is now valid) and likewise the FS went away...

Alternative to this would be allowing one or more eventResponder objects to be registered with the object.

Example with the new msFileSystem object I am playing with, it might be nice to have a method to add an event object, up to N with this object.

Maybe nice to also have the ability to pass in one on the constructor...
And/Or the has one built in, and some method to gain access to it and set the call back function and how...

But suppose we start off with something like:

Code:
EventResponder erFS1
msFilesystem msFS1(myusb, erFS1 );
...
void mtp_msc_er(EventResponderRef er) {
    switch (er.getStatus()) {
        case MSFS_STATUS_CONNECTED: // something defined and set by the FS
            // grab the FS from the context 
            // Maybe ask FS for Volume Label to create MTP Storage name.
            mtpd.addFileSystem(<the fs>, < the desired label>
            // maybe signal MTP that something changed
            break.
        case MSFS_STATUS_DISCONNECT: 
      ... 


...
void setup() {
...
erFS1.setContext((void*)&msFS1);
erFS1.attach(&mtb_msc_er);
Does this make sense? Is this the route for callbacks we wish to go?

If so, I wish we had a version of the constructor for the EventResponder where we can define most everything up front...
Something like: EventResponder erFS1(&mtb_msc_er, EventResponder::EventTypeYield, (void*)msFS1);
Maybe with other optional maybe the context comes before Event Type which defaults to yield...

Anyway sorry slight sidetracked, but would be nice to be able to setup something quick and dirty like this, and have these take care of adding/removing FS to MTP, and maybe extended to if possible to say some files have changed or ...

Probably enough rambling for this round
 
Back
Top