It wasn't compiling after I synced to the latest changes, so I put those #if lines back in.
If it's causing you trouble now, I could just install MemoryHexDump here as a short-term solution. But for the long-term goal of bringing MTP_Teensy into the core library (hopefully for 1.57), we can't have it depend on including any other libraries.
Not a problem, I meant to do that... But is again more of a generic question, is there any way to do this Automatically in Arduino? More or less asking is there a way to say open this file if you can else please don't error out...
And yes I know the above probably would work with PlatformIO or other setups where you define the list of directories to include in the build...
This needs to be done inside LittleFS. It can't go into MTP_Storage, because MTP_Storage doesn't "know" these filesystem-specific limitations.
Sounds like maybe FS.h, the FS object should have some way to query the underlying fs for limitations or configuration information like this:
Like:
Max file name length
Max path length
Sector size
Cluster size
...
If this matters, we could also check for OpenSession in the timer.
Agreed, I've never seen Windows transmit CloseSession. We would also need to look at the something like usb_configuration.
CloseSession does get sent by Android File Transfer on MacOS.
So far I've not spent much time looking at what Linux actually does.
Note: the IntervalTimer does handle the OpenSession...
As for Mac sending CloseSession, how? yes maybe if I close their MTP app, or use something like eject... But if I unplug the usb cable...
Not sure if best to discuss some of it here or email... Will start here.
The IntervalTimer code here I added at the time as what I consider a big kludge to lessen some of the startup issues we were/are seeing, which include:
a) if we don't respond quick enough to some of the early message, all USB is toast... Not just the mtp part
b) SEREMU was not working most of the time, still loses the first about 5 seconds of the sketch startup outputs to Serial
c) Serial (USB) - while (!Serial) ; // would hang for ever... So hacks were added like while (!Serial && !Serial.available()) ; and the user had to enter something to get it to continue.
I have kludged around b) in some sketches by using a memory stream to try to capture all/most of the mtp output messages and when we finally get SEREMU, I dump the output from the memory stream to Serial... total kludge.
As for long term, I personally believe having the MTP startup code depending on the IntervalTimer is far from Ideal (sucks). Again example, with the image display sketch or many/most of the data capture programs, I could imagine that it could be running for several days or longer without the user ever plugging in the USB cable. So do you want that timer to run 20 times a second doing nothing... What about interrupting time critical tasks, or wanting to run in low power mode...
At least with current stuff, this sketch does not completely hang:
Code:
void setup()
{
while (!Serial) ;
Serial.begin(115200);
}
uint32_t loop_counter = 0;
void loop() {
Serial.printf("%u %u\n", loop_counter++, millis());
delay(250);
}
But again there is a long delay
Where is if build for Serial, first line output: 0 532
Keyboard+Mouse+Joystick: 0 584
So to me, it would be great if we can somehow without user code involved be able to be like all of the other USB types and quickly satisfy whatever requests from the host that we need to to get the startup time, in
the same ballpark as the other USB Types.
Actually, running this stuff from interrupts makes me nervous. For now, I want to leave it as-is and focus on more important things. Long-term, I'm hoping to find a way to run this timer stuff and the loop function from yield() or MillisTimer() or something similar. And eventually I want more places in the core library to call yield(), like when the bool operator for Serial is about to return false, or when Serial.available() is about to return zero.
This actually scares me, as now there is assumption that the above operations are quick, I am calling these to see if there is some other tasks, I might need to handle and now the system could go off and do lots of stuff that could significantly change timings.
But right now, the absolute top priority is that we finally have reliable GetObject & SendObject. Some things in the code still concern me, like creating / opening the file inside SendObjectInfo, rather than SendObject.
Turning GetObject & SendObject into a state machine, so we don't stay in loop() for long times, is also pretty important.
SendObjectInfo - creating the file... To me that is the whole purpose of this message, it is supposed to give us enough information for us to check things like:
Is this object name valid for that storage, do we have enough space available, can I write to this device... If we pass these tests than we need to return to the host the new object ID... Yes we could could guess, and be wrong, like the SD card is write only, or the filename length exceeds what the store handles... But not sure what this gains us.
As for state machine and the like, Not sure how much we gain right now, if most of our time is spent maybe waiting for LittleFS to do a write, unless that can be done asynchronously....
Probably enough for this message.