FS.h - File class goes boom - when virtual functions not overwritten

Status
Not open for further replies.
@All - Once again you guys are on it. Hopefully this next weekend I can get caught up. Starting my vacation this labor day weekend and can't wait to start working with the recent developments. Really curious about MTP and Linux. I have never been able to get this combo working. Only on windows. Probably need to buck up and change one computer to the latest version of Ubuntu for testing:)
 
Quick update, pulled in the last changes and build my simple SD_MTP_Logger version :D
Which is now working at least on the T4.1 with built in SD...

:D
 
Much better now but it still has ambiguity issues when writing single integral types. Looks like a lot of additional write(xxx) overloads are required. Maybe a templated approach might work without all the typing?

Code:
#include "LittleFS.h"

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

    ramFS.begin(1024);

    File f1 = ramFS.open("test1.txt", FILE_WRITE);
    f1.write("1234567890\0");// strips the terminating '\0' so lets add it manually:
    [COLOR="#FF0000"]//f1.write('\0');      // doesn't work, ambiguity between write(char)  write(uint8_t) and write(const char*) can be fixed by adding write(char)
    //f1.write(0);         // doesn't work, ambiguity between write(int)  write(uint8_t) and write(const char*) can be fixed by adding write(int)
    //f1.write(0u);        // doesn't work, ambiguity between write(uint)  write(uint8_t) and write(const char*) can be fixed by adding write(unsigned)
    // and so on
    //f1.write("\0");      // compiles but doesn't work, will strip the 0
    f1.write((uint8_t)0);  // works yay...[/COLOR]
    f1.close();

    char buf[1000];
    f1 = ramFS.open("test1.txt", FILE_READ);
    f1.read(buf, 100);
    f1.close();
    Serial.printf("test1.txt read: %s\n", buf);
}

void loop()
{
}
 
Last edited:
1. If you renamed the new API call isOpen to is_open it would be more compatible to other things, and perhaps less confusing : https://www.cplusplus.com/reference/fstream/fstream/is_open/
There is no such call documented in Arduino so no problem to use is_open instead.
It would be a reason less to call it "Arduino language"

2. Nice to have (not a FS.h issue, but it fits here.. ) :
If you add
Code:
template<class T> inline Print &operator <<(Print &obj, T arg)  // no-cost stream operator as described at http://arduiniana.org/libraries/streaming/
{
 obj.print(arg);
 return obj;
}

somewhere, things like
Code:
dataFile << "Blah"
or
Code:
Serial << "bubu"
work.

And with an additional "cout", a lot of cpp tutorials start working... ;)
 
Last edited:
luni said:
Maybe a templated approach might work without all the typing?

Adding this:
Code:
template<typename T>
bool write(T b){
  static_assert(std::is_trivially_copyable<T>::value,"You can not write this type to File" ); 
  return File::write(&b, sizeof(b));
}
to the File class fixes the ambiguity issues shown in #78 without explicitly declaring functions for all the integral types. (At least it compiles, can't do functional tests at the moment). Derived classes do not need to be changed.

This allows writing everything which can be "memcopied" to a file.
 
Will follow up on probably a new (not yet created thread) about about integrating all of the pieces for the hopefully next next release of Teensyduino with more of the FS Integration stuff like MTP and MSC.
As I earlier mentioned up on the Beta1 thread:

This morning @mjs513 updated the forks/branches that we have been working on to use the File stuff from here... I believe the list includes:

Current setup: Arduino 1.8,15 and this beta:

This update is also including our trying to add in the Date/Time stuff, which I know will be subject to change.

cores: with https://github.com/KurtE/cores/tree/FS_Integration
MTP: https://github.com/KurtE/MTP_t4/tree/FS_Integration
MSC: https://github.com/KurtE/UsbMscFat/tree/FS_Integration
LittleFS: https://github.com/Mjs513/LittleFS/tree/FS_Integration
SD: https://github.com/KurtE/SD/tree/FS_Integration

It builds :D and my simple Example sketch: SD_MTP-logger sketch runs and opens up and shows SD card on the PC...
The dates and times on the SD Card appear to come through and display in details view on the PC explorer window.

However new files created on the SD card are ending up with Bogus Dates and times.

I have a Wrapper class for SD devices that add callback code, such that if you ask for Format on the PC, it will call through our callback to do the formatting. While with this class I added some additional support code, like it will detect if so far on T4.x if SD card is not inserted, but later inserted... I now also have added in the code that SD library code will call back to get the date/time for new file, code based on same code in MTP test sketch... But it is getting bogus data from timelib:

So I added quick test at start of sketch which added:
Code:
  Serial.printf("Date: %u %u %u TIme: %u %u %u\n", year(), month(), day(), hour(), minute(), second());

And it printed out: Date: 1970 1 1 TIme: 0 0 5


So wondering about timelib...

Edit: I think I need to set the sync provider will hack that in
 
Last edited:
still has ambiguity issues when writing single integral types. Looks like a lot of additional write(xxx) overloads are required.

Tested just now. We've had these same File::write(0) ambiguous overloads in 1.54 and 1.53 and probably all earlier versions.

Nearly the same ambiguous overloads errors happen with Arduino Uno too, with the exception being char defaults to unsigned on AVR. But myfile.write(0) doesn't compile on any of Arduino's boards. I tried Uno, Nano, Mega, Due, MKR1000, Nano Every, Portenta, Nano RP2040 Connect. Same ambiguous overload error on all of them.

However, myfile.write(0) does compile on ESP8266 and ESP32. I don't have a SD card wired up to any of those boards to actually test. I looked briefly at their Print.h and Stream.h, but I couldn't see anything they're doing differently. Maybe the xtensa compiler handles this differently?



Adding this:
Code:
template<typename T>
bool write(T b){
  static_assert(std::is_trivially_copyable<T>::value,"You can not write this type to File" ); 
  return File::write(&b, sizeof(b));
}
...
This allows writing everything which can be "memcopied" to a file.

Pretty sure this is *not* the way to go! Here's the Arduino documentation for write()

https://www.arduino.cc/reference/en/language/functions/communication/serial/write/

write(val) is supposed to "send a single byte".
 
Fixed the new file date/times. Needed to setup the sync provider... So I put it into our newer method mtpd.begin()
Which now looks like I can run our simple logger and when we stop it and refresh the folder window on windows it shows up now with good date!
 
write(0) leads to the result as printf("%c",0), so I think this is OK. (Hmm... does printf call this write()?) and at least consistent.

Code:
abcdefghijklmnopqrstuvwxyz{|}~
61 0 0 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f

Code:
#include <MemFile.h>


char testData[31];
MemFS  myfs;


void setup()
{
  File dataFile = myfs.open((char*) &testData, sizeof(testData), FILE_WRITE);
  for (unsigned i = 0; i < sizeof(testData); ++i) testData[i] = 'a' + i;
  if (dataFile)
  {
    while (dataFile.available()) {
      Serial.print((char)dataFile.read());
    }
    Serial.println();
    dataFile.seek(1); //set position to "b"
    dataFile.write(0);
    dataFile.printf("%c", 0);
    dataFile.seek(0);    
    while (dataFile.available()) {
      Serial.printf("%x ",(char)dataFile.read());
    }
    dataFile.close();
  }
}


void loop()
{}
 
However with the "<<" operator addition

dataFile << 0

it prints an asc '0' ( 0x30)

WHich is clear, because this calls Arduino-print, so print(0)
And print(0) prints the asc 0

So, what happens with floats? I guess PI is will be written as 3.14? (2 digits)

Edit: No. (Does not compile.. which is clear... ..lol my mistake :) )
 
Last edited:
Fixed the new file date/times. Needed to setup the sync provider... So I put it into our newer method mtpd.begin()
Which now looks like I can run our simple logger and when we stop it and refresh the folder window on windows it shows up now with good date!

Just finished testing Date/Time when using LittleFS and MSC drives and it is working as well with any additional changes.
 
Will follow up on probably a new (not yet created thread) about about integrating all of the pieces for the hopefully next next release of Teensyduino with more of the FS Integration stuff like MTP and MSC.
As I earlier mentioned up on the Beta1 thread:

This morning @mjs513 updated the forks/branches that we have been working on to use the File stuff from here... I believe the list includes:

Current setup: Arduino 1.8,15 and this beta:

This update is also including our trying to add in the Date/Time stuff, which I know will be subject to change.

cores: with https://github.com/KurtE/cores/tree/FS_Integration
MTP: https://github.com/KurtE/MTP_t4/tree/FS_Integration
MSC: https://github.com/KurtE/UsbMscFat/tree/FS_Integration
LittleFS: https://github.com/Mjs513/LittleFS/tree/FS_Integration
SD: https://github.com/KurtE/SD/tree/FS_Integration

It builds :D and my simple Example sketch: SD_MTP-logger sketch runs and opens up and shows SD card on the PC...
The dates and times on the SD Card appear to come through and display in details view on the PC explorer window.

However new files created on the SD card are ending up with Bogus Dates and times.

I have a Wrapper class for SD devices that add callback code, such that if you ask for Format on the PC, it will call through our callback to do the formatting. While with this class I added some additional support code, like it will detect if so far on T4.x if SD card is not inserted, but later inserted... I now also have added in the code that SD library code will call back to get the date/time for new file, code based on same code in MTP test sketch... But it is getting bogus data from timelib:

So I added quick test at start of sketch which added:
Code:
  Serial.printf("Date: %u %u %u TIme: %u %u %u\n", year(), month(), day(), hour(), minute(), second());

And it printed out: Date: 1970 1 1 TIme: 0 0 5


So wondering about timelib...

Edit: I think I need to set the sync provider will hack that in

I finally have one of my PC's updated to the above libraries using TD1.55B1. I ran all of the UsbMscFat examples with one failure, 'bench.ino'. But that turned out to be a corrupt FAT32 file system on the USB stick I was using. Reformatted it and the bench sketch worked. Tested diskIO sketch's. Everything is still working:)

Have not played with MTP_T4 yet but that's next. On another one of my PC's I have been going through MassStorageDriver.cpp. Using EventResponder it now will will auto initialize a USB drive. EventResponder will call mscInit() when it is claimed by MSC. For testing I eliminated all other calls in UsbMSCFat to mscInit() and it worked. This is better for hot-plugging. It is just something to consider in the future.

Edit: LittleFS is also still working with diskIO. I have been testing with @Paul's T4.1 Breakout Board and Mem Board. At this time just QPINAND on the T4.1.
 
Last edited:
Will follow up on probably a new (not yet created thread) about about integrating all of the pieces for the hopefully next next release of Teensyduino with more of the FS Integration stuff like MTP and MSC.
...
This update is also including our trying to add in the Date/Time stuff, which I know will be subject to change.

cores: with https://github.com/KurtE/cores/tree/FS_Integration
MTP: https://github.com/KurtE/MTP_t4/tree/FS_Integration
MSC: https://github.com/KurtE/UsbMscFat/tree/FS_Integration
LittleFS: https://github.com/Mjs513/LittleFS/tree/FS_Integration
SD: https://github.com/KurtE/SD/tree/FS_Integration

...

Is there an update to this list of 'needed' stuff for use with TD 1.55 beta 2?

Is everything under a 'FS_Integration' branch as indicated above?
 
Is there an update to this list of 'needed' stuff for use with TD 1.55 beta 2?

Is everything under a 'FS_Integration' branch as indicated above?

The list I believe is reasonably up to date. At times hard to say when my fork or @mjs513 fork are more up to date, but we usually keep reasonably in sync.

I should also mention so far have not done any testing/compiling for T3.x as been playing with T4 security stuff...
 
Status
Not open for further replies.
Back
Top