Teensyduino 1.55 Beta #1

Status
Not open for further replies.
LittleFS takes care of the Flush - and is fastest of the bunch - and 400KB a decent size - so can see it being a usable feature in some case.

Perhaps this is what Kurt was alluding too - was doing dishes/making coffee then and thought having a way to do a "LFS_BUF = Heap_Alloc( LFS_BUF_SIZE, TOP );" would be a valid dynamic Alloc - that when first done would always have reason to return the same address, and the HEAP system could remove that from the Free Pool to keep it safe.
 
Other question, completely off topic :)
Currently vtables are in DTCM. As this is more code related - would'nt be ITCM perhaps be a better location? Might not matter much..

Edit: it would have no advantage since the fill level of the ITCM is not predictable.
Forget this post :) - too late here.

Edit: anyone knows what setup::data is ?
 
Frank B said:
what are possible use-cases for littlFS in RAM ?
Click to expand...

I have wondered this too. But everyone seems to be enjoying this journey, so didn't want to spoil it by pointing out the volatile destination.

You are correct. Reality is LittleFS_RAM exists pretty much just for testing LittleFS. It's not actually useful for pretty much any real project. There are a lot of ways you might use RAM. Adding the huge overhead of a copy-on-write filesystem which is meant to give you wear leveling and resilience to power loss during writes is pretty silly for RAM.

But LittleFS_RAM is really convenient for testing the library itself.


As it seems to an issue with the HAB log only, anway - which means it is an issue only if encryption is enabled
Click to expand...

HAB always run at boot, regardless of the security mode. The HAB log (in RAM) is really only useful in non-secure mode, to check whether HAB verified the digital signature, as a final check whether it's safe to forever lock the chip into secure mode. The only program actually using it is indeed LockSecureMode.


- And to have the memory occupied by HAB available if no encryption is enabled.
In no way it is desireable to have that memory blocked for the 99.9999% of users who will not encrypt.
Click to expand...

Indeed that is exactly the reason why I created the special hab_log section in the linker script, so a program needing the HAB log can reserve the memory, but all other programs aren't limited in which memory they can access.

Even for the people who will use encryption (I would disagree they're only 0.00001%) the HAB log is really only needed once. After you've locked security, if there's anything written to the HAB log memory, NXP's ROM won't jump to your code anyway!
 
KurtE said:
@all - @Frank - I personally totally agree with you, that I don't see a very strong usage case on when I would want to use a LittleFS in RAM and expect and prepare for it to work sometimes but not others.

But others may find usage. So for me most of this was for a learning exercise and a way to test some differences for the new lockable T4...

.....
Click to expand...

Know this is late but I kind of agree with you all. Don't really see a good use case to use a LittleFS in RAM. As @KurtE was a fun exercise to find out what happened. The only time I ever used RAM was with PSRAM as an experiment most of the time would use SPI/QSPI NOR or NAND Flash for most applications. Definitely don't want to lock a huge chuck of DMAMEM - use it for a lot better things like Graphics as Kurt mentioned.

Just my 2 cents

EDIT: Looks like my response is a day late and a dollar short.
 
Indeed - having it for testing was faster and cleaner. DMAMEM smaller than PSRAM - - and obviously not tested enough to catch this mostly using T_4.1's w/PSRAM.

The .00001 use case might be along the lines of p#247, the TD 1.54 posted code won't work as advertised. Having a usable template, warm restart able jumping the HAB area, will make it findable, usable.

Even using DMAMEM - expecting DMAMEM to be generally static for an array of data across warm restart can lead to days of issues ... as we've demonstrated.

Not sure the change to malloc(size_t len) for TOP/END would ever get used, but void *LFS_BUF = (void*)(0x2027ff00-LFS_BUF_SIZE); works ...
 
PaulStoffregen said:
Here's a first (very rough) draft of the code security documentation.

https://www.pjrc.com/teensy/td_code_security.html

Almost all the writing is still quick notes needing to be turned into more complete explanations.

At this point, the main question is whether anyone can see any important topics or points I've forgotten to include?
Click to expand...

Think all the main topics are there but from some of my notes - more like posts to remember that I like there was:
1. post #33 to explain what you would see in the log if you are using the hex
2. post #115 - kind of like how you explained the flash regions
3. post #117 - the ehex description was pretty good in this post. Almost same I think as what your have.
4. post #237 on DMAMEM
 
Paul, looks good for first pass.

It mentions all of the T4.xs... I assume that is will be and not currently setup. That is I believe I tried to do a Micromod and the Fuse Write sketch failed...

May want to clarify under protection: Code, strings, variable & array data can not be read or copied.
That is I assume my sketch can still work with strings and variables...

Power consumption/heat: wonder if my first reaction was due to holding a new chip without any IO pins soldered on versus older board with IO pins, which may act some as heat sink...

Integration with non-Arduino. Looks like teensy_secure is there. Need to experiment. Does this require GUI? What about Teensy CLI
Side note: if you go To T4 page and click on the programming link and then the Teensy loader app: https://www.pjrc.com/teensy/loader.html
Does not mention anything about T4.x... and in there if you click on the CLI... https://www.pjrc.com/teensy/loader_cli.html
Will the security app replace the CLI one for integration? (Second off topic note) I have PR in for Micromod...

Questions: Not sure if current stuff is expected behavior. But currently either by hitting reset button in TyCommander or using the teensy_reboot program when I do that on locked T4 and teensy app is running, it will try to reprogram the locked T4.

Memory Wipe & LED Blink Restore - as mentioned on T4.x pages... On my locked boards, holding the button down until you get blink does not reprogram locked T4, instead existing program runs and the program led goes into a double blink sequence.

Programming a T4 that has Key programmed in but not locked, and if you try to program it with wrong key, it will gladly do so, it will reject the ehex and use the hex. However if locked then it will fail with image on tennsy app. Wonder if there needs to explained and/or somewhere output Warning to build like Warning: this board has a security key which was not matched, using non-secure version instead... (I know bad wording)

That is all for now
 
Printed, but not read yet. Saw the pretty first pics/words and first thought:

Code: 
What about :: [B]" Ctrl + Alt + S " :: Export compiled Binary[/B]

If someone going to this trouble they'll want to have the .eHex saved with sources. { Would also make sense to secure the pem.key with sources as well, another issue }

@Paul > ANYHOW :: doing that fails one way in this BETA #1

#1 > .eHex is not copied to the Sketch folder - but the .Hex is placed there. The .eHex is in the %temp%\buildDir

#2 > There is no resulting upload and program at this time. Maybe it isn't supposed to upload it seems - just Verify/Build/Export, no Upload.
Code: 
17:53:59.467 (loader): file changed
17:53:59.484 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_962802\RAM.ino.hex", 97280 bytes
17:53:59.499 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_962802\RAM.ino.ehex", 97280 bytes, 4960 extra
17:53:59.501 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
17:53:59.574 (post_compile 23): Begin, version=1.55-beta1, high-res time
17:53:59.580 (loader): remote connection 1392 opened
17:53:59.582 (post_compile 23): Sending command: comment: Teensyduino 1.55-beta1 - WINDOWS (teensy_post_compile)
17:53:59.582 (loader): remote cmd from 1392: "comment: Teensyduino 1.55-beta1 - WINDOWS (teensy_post_compile)"
17:53:59.583 (loader): remote cmd from 1392: "status"
17:53:59.587 (post_compile 23): Status: 1, 1, 0, 15, 2, 0, C:\Users\Tim\AppData\Local\Temp\arduino_build_962802\, RAM.ino.hex
17:53:59.587 (post_compile 23): Sending command: dir:C:\Users\Tim\AppData\Local\Temp\arduino_build_962802\
17:53:59.587 (loader): remote cmd from 1392: "dir:C:\Users\Tim\AppData\Local\Temp\arduino_build_962802\"
17:53:59.588 (post_compile 23): Sending command: file:RAM.ino.hex
17:53:59.588 (loader): remote cmd from 1392: "file:RAM.ino.hex"
17:53:59.606 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_962802\RAM.ino.hex", 97280 bytes
17:53:59.620 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_962802\RAM.ino.ehex", 97280 bytes, 4960 extra
17:53:59.621 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
17:53:59.630 (loader): remote cmd from 1392: "status"
17:53:59.634 (post_compile 23): Status: 1, 1, 0, 15, 2, 0, C:\Users\Tim\AppData\Local\Temp\arduino_build_962802\, RAM.ino.hex
17:53:59.634 (post_compile 23): Disconnect
17:53:59.658 (loader): remote connection 1392 closed
/CODE]
 
KurtE said:
Paul, looks good for first pass.

It mentions all of the T4.xs... I assume that is will be and not currently setup. That is I believe I tried to do a Micromod and the Fuse Write sketch failed...

May want to clarify under protection: Code, strings, variable & array data can not be read or copied.
That is I assume my sketch can still work with strings and variables...

Power consumption/heat: wonder if my first reaction was due to holding a new chip without any IO pins soldered on versus older board with IO pins, which may act some as heat sink...

Integration with non-Arduino. Looks like teensy_secure is there. Need to experiment. Does this require GUI? What about Teensy CLI
Side note: if you go To T4 page and click on the programming link and then the Teensy loader app: https://www.pjrc.com/teensy/loader.html
Does not mention anything about T4.x... and in there if you click on the CLI... https://www.pjrc.com/teensy/loader_cli.html
Will the security app replace the CLI one for integration? (Second off topic note) I have PR in for Micromod...

Questions: Not sure if current stuff is expected behavior. But currently either by hitting reset button in TyCommander or using the teensy_reboot program when I do that on locked T4 and teensy app is running, it will try to reprogram the locked T4.

Memory Wipe & LED Blink Restore - as mentioned on T4.x pages... On my locked boards, holding the button down until you get blink does not reprogram locked T4, instead existing program runs and the program led goes into a double blink sequence.

Programming a T4 that has Key programmed in but not locked, and if you try to program it with wrong key, it will gladly do so, it will reject the ehex and use the hex. However if locked then it will fail with image on tennsy app. Wonder if there needs to explained and/or somewhere output Warning to build like Warning: this board has a security key which was not matched, using non-secure version instead... (I know bad wording)

That is all for now
Click to expand...

Thanks @KurtE - forget about the 15s restore on a locked T4 and FuseWrite didn’t work on the beta Tom board.
 
Doc looks good - made quite simple from IDE interface - lots of embedded details.

mjs513 said:
Thanks @KurtE - forget about the 15s restore on a locked T4 and FuseWrite didn’t work on the beta Tom board.
Click to expand...

Is Tom board ... SFun Tmmod? Didn't try one of those for anything. Are any Tmmod units part of the 'June 2021' windows ... or are they SFun controlled? Don't recall when they arrived ...

Indeed - when locked the 15sec Restore can't work - still unclear if it can do any of the other restore cleanup ... suppose not with bootloader no longer in JTAG control.

Nit spare t in the text: under loader utility ... 'can not longer function'

A shame the Public Key Hash is so long - would be good to archive the pem.key with that for secure source records. Since the Teensy Loader provides that it would allow positive association is copied to Sketch Folder with Ctrl+Alt+S as:
pem.85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942.key in some fashion
 
Put Updated RAM - Using Hardcoded DMAMEM *ptr above HAB work area, that starts short of CrashReport Area :: github.com/Defragster/T4LockBeta/tree/main/RAM
-> Has Updated DirVerify for Byte checking
-> Should this be a PR for TD 1.55 Beta?

>> Update for DirectoryVerify() is a change in functions.ino that would drop into all Integrity Sketches

Looking at PROG and a version with SD xfer included. It's up there too - but hardcoded for setup xfer doesn't work to save to SD that is blank on start - it would need a command to write before reprogram to read back to be usable. I had DirVerify show failures once - not sure what would have done that - it hasn't shown up again in testing. I may need to check that writing to pen file that exists starts truncated.

@Mike - have you seen the new Beta T4 in the Beta breakout with POGO's to SD work? Mine wouldn't for some reason - reseated a couple times ??? - so I had to move to a T_4.1 for testing. I did see indeed the DirVerify reads "S"mall as well as "B"ig file - they are both just filled with the ascii digit # throughout, They are written with a filled 2K buffer to speedier test.
 
Is Tom board ... SFun Tmmod? Didn't try one of those for anything. Are any Tmmod units part of the 'June 2021' windows ... or are they SFun controlled? Don't recall when they arrived ...
Click to expand...
Yes that was suppose to be Teens MicroMod. I also just tested it with that production TMM I got from sparkfun and it failed as well on FuseWrite:

Using the same key as I did for the T4 I ran the fuseWrite Sketch and it failed. I forgot to copy the output so ran it again:

Code: 
Writing public key hash
public key hash is good :-)
Decryption key was previously written & locked
Error: Key can not be used

Testing Bus Encryption Engine
Error: ciphertext decryption did not match plaintext!
  plain:  E8 04 44 69
  cipher: D1 A8 E6 CB
  dcrypt: D1 A8 E6 CB

Error: JTAG can not be disabled

Error: Secure mode can not be set
Not sure but it looks like it wrote the fuses but cant use it.
 
defragster said:
Put.......

@Mike - have you seen the new Beta T4 in the Beta breakout with POGO's to SD work? Mine wouldn't for some reason - reseated a couple times ??? - so I had to move to a T_4.1 for testing. I did see indeed the DirVerify reads "S"mall as well as "B"ig file - they are both just filled with the ascii digit # throughout, They are written with a filled 2K buffer to speedier test.
Click to expand...

Sorry Tim I am not using the Beta T4 breakout - couldn't find my ribbon cable connectors so am using my home spun breakout which doesn't use the SD Card.
 
Morning all, so far I have not done anything with the SD or USB connections on the Beta boards. As I did not want to risk soldering those pins yet...
It has not felt like a priority to me as, in theory nothing should be different here versus normal T4.x...

I tried MMOD as well including one of the new ones after they shipped. Same type errors as @mjs513. Have new T4 at my PMB in town which I will probably pick up tomorrow. If I were to want to work with the extra bottom pins, I would probably look through my chaos of stuff in my office for where I may still have some 4236 like castellated boards to break out all of the bottom pins. But again I killed one T4 with a short doing this so...
 
Edit: When I ordered the new T4 from PJRC, I thought about also ordering T4.1, but Paul's posting here said new T4s... And has not mentioned anything about T4.1s and as MMOD had not worked yet, I figured maybe his code is currently specific to the T4 (size of flash)...

Side note: I also ordered one of the new ili9341 3.2" displays to see if I guessed correctly the mounting holes for my screwed up MMOD breakout board
 
KurtE said:
Morning all, so far I have not done anything with the SD or USB connections on the Beta boards. As I did not want to risk soldering those pins yet...
It has not felt like a priority to me as, in theory nothing should be different here versus normal T4.x...

I tried MMOD as well including one of the new ones after they shipped. Same type errors as @mjs513. Have new T4 at my PMB in town which I will probably pick up tomorrow. If I were to want to work with the extra bottom pins, I would probably look through my chaos of stuff in my office for where I may still have some 4236 like castellated boards to break out all of the bottom pins. But again I killed one T4 with a short doing this so...
Click to expand...

Since I put it in my breakout board I did try UBSHost and didn't have a problem connecting a BT joystick.
 
-Wundef shows warnings in wiring.h
Code: 
#if __cplusplus >= 201103L && defined(__STRICT_ANSI__)
on several places. No surprising, as it gets included by c files only.

Q: Is that a problem? Or is that wanted? (i'd check for c++, then...)
 
Just ran a quick Graphics test on the Locked T4 using the ILI9341_t3n library which uses a bunch of PROGMEM and DMAMEM memory and works with the tested exampled. Has the following characteristics on compile:
Code: 
Memory Usage on Teensy 4.0:
  FLASH: code:82720, data:21156, headers:8760   free for files:1918980
   RAM1: variables:168640, code:61688, padding:3848   free for local variables:290112
   RAM2: variables:12384  free for malloc/new:511904
Also dump some data from @Frank B's T4_Power_Button (not sure I am using the latest) but:
Code: 
OpenGL Test!
FLASH: 112640  5.54% of 1984kB (1918976 Bytes free) FLASHMEM, PROGMEM
ITCM:   61688 94.13% of   64kB (   3848 Bytes free) (RAM1) FASTRUN
OCRAM:
   524288 Bytes (512 kB)
-   12384 Bytes (12 kB) DMAMEM
-   80016 Bytes (78 kB) Heap
   431888 Bytes heap free (421 kB), 92400 Bytes OCRAM in use (90 kB).
DTCM:
   458752 Bytes (448 kB)
-  168640 Bytes (164 kB) global variables
-    1300 Bytes (1 kB) max. stack so far
=========
   288812 Bytes free (282 kB), 169940 Bytes in use (165 kB).
 
mjs513 said:
Sorry Tim I am not using the Beta T4 breakout - couldn't find my ribbon cable connectors so am using my home spun breakout which doesn't use the SD Card.
Click to expand...

I pulled out the one with POGO pins ALL UNDER? ... no cable on that one. I know it can be finicky with POGO alignment - but seems it worked? Hoped to find it to work as an easy no risk/solder test platform for various sketches - and plug in Audio Rev B.

Hoping not to find any differences - just the ability to run wider range of sketches for size and function variation and fun.

Kurt - I have 1 or 2 of the FRDM 4236 boards as well - I did one okay, and easier than the TallDog - but a bit less complete. I have the 2nd TallDog board out ... counted the parts to solder and there are lots so an hour (?) soldering smd pads for pins and parts and then the through hole pins/headers ... didn't want to risk or commit to that sooner than needed.
 
With my two beta boards, I already have pins soldered on both. If I had not done that I could have simply used the Hyperbolic Labs T4 Ultimate board that uses spring loaded nibs for all of the pins. But I did not think about trying that until today
 
KurtE said:
With my two beta boards, I already have pins soldered on both. If I had not done that I could have simply used the Hyperbolic Labs T4 Ultimate board that uses spring loaded nibs for all of the pins. But I did not think about trying that until today
Click to expand...

I have one of those and still a bare Beta T4L But That gave mixed results when tried before ...

Kurt with it side pinned - it should pressinto the POGO T4 Beta breakout to see id SD works ?
 
@defragster - Not sure where my early T4 beta board is right now :eek:

@Paul and all - With these new T4.Xs boards with larger Flash chips and the like, and now with this beta with T4s being able to preserve the upper part of the flash, and also my assumption that this will also be true for T4.1 and MicroMod? One usage that I see that could be very nice usage is the ability to have a quick and dirty File system like LittleFs up there (or even in RAM) and using MTP to be able to transfer data to and from a PC...

So for the fun of it, @mjs513 and myself did a quick and dirty updated version of the new simple logging program, that also sets up MTP.

The sketch:
Code: 
/*
  LittleFS  datalogger

  This example shows how to log data from three analog sensors
  to an storage device such as a FLASH.

  This example code is in the public domain.
*/
#include <LittleFS.h>
#include <MTP.h>
#if defined(__IMXRT1062__)
// following only as long usb_mtp is not included in cores
#if !__has_include("usb_mtp.h")
#include "usb1_mtp.h"
#endif
#if defined(ARDUINO_TEENSY40) && defined(BUILTIN_SDCARD) // needed untin not corrected in SD.h
#undef BUILTIN_SDCARD
#endif
#else
#ifndef BUILTIN_SDCARD
#define BUILTIN_SDCARD 254
#endif
void usb_mtp_configure(void) {}
#endif

#if USE_EVENTS==1
extern "C" int usb_init_events(void);
#else
int usb_init_events(void) {}
#endif

// LittleFS supports creating file systems (FS) in multiple memory types.  Depending on the
// memory type you want to use you would uncomment one of the following constructors

LittleFS_Program myfs;  // Used to create FS on QSPI NAND flash chips located on the bottom of the T4.1 such as the W25N01G. for the full list of supported NAND flash see  https://github.com/PaulStoffregen/LittleFS#nand-flash

File dataFile;  // Specifes that dataFile is of File type

int record_count = 0;
bool write_data = false;
static const uint32_t file_system_size = 1024 * 512;

// Add in MTPD objects
MTPStorage_SD storage;
MTPD       mtpd(&storage);


void setup()
{

  // Open serial communications and wait for port to open:
  Serial.begin(115200);
  while (!Serial) {
    // wait for serial port to connect.
  }
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);

  Serial.print("Initializing LittleFS ...");

  // see if the Flash is present and can be initialized:
  if (!myfs.begin(file_system_size)) {
    Serial.printf("Error starting %s\n", "QSPI FLASH");
    while (1) {
      // Error, so don't do anything more - stay stuck here
    }
  }

#if USE_EVENTS==1
  usb_init_events();
#endif
#if !__has_include("usb_mtp.h")
  usb_mtp_configure();
#endif

  storage.addFilesystem(myfs, "Program");


  Serial.println("LittleFS initialized.");

  menu();

}

void loop()
{
  if ( Serial.available() ) {
    char rr;
    rr = Serial.read();
    switch (rr) {
      case 'l': listFiles(); break;
      case 'e': eraseFiles(); break;
      case 's':
        {
          Serial.println("\nLogging Data!!!");
          write_data = true;   // sets flag to continue to write data until new command is received
          // opens a file or creates a file if not present,  FILE_WRITE will append data to
          // to the file created.
          dataFile = myfs.open("datalog.txt", FILE_WRITE);
          logData();
        }
        break;
      case 'x': stopLogging(); break;

      case 'd': dumpLog(); break;
      case '\r':
      case '\n':
      case 'h': menu(); break;
    }
    while (Serial.read() != -1) ; // remove rest of characters.
  }
  else mtpd.loop();

  if (write_data) logData();
}

void logData()
{
  // make a string for assembling the data to log:
  String dataString = "";

  // read three sensors and append to the string:
  for (int analogPin = 0; analogPin < 3; analogPin++) {
    int sensor = analogRead(analogPin);
    dataString += String(sensor);
    if (analogPin < 2) {
      dataString += ",";
    }
  }

  // if the file is available, write to it:
  if (dataFile) {
    dataFile.println(dataString);
    // print to the serial port too:
    Serial.println(dataString);
    record_count += 1;
  } else {
    // if the file isn't open, pop up an error:
    Serial.println("error opening datalog.txt");
  }
  delay(100); // run at a reasonable not-too-fast speed for testing
}

void stopLogging()
{
  Serial.println("\nStopped Logging Data!!!");
  write_data = false;
  // Closes the data file.
  dataFile.close();
  Serial.printf("Records written = %d\n", record_count);
  mtpd.send_DeviceResetEvent();
}


void dumpLog()
{
  Serial.println("\nDumping Log!!!");
  // open the file.
  dataFile = myfs.open("datalog.txt");

  // if the file is available, write to it:
  if (dataFile) {
    while (dataFile.available()) {
      Serial.write(dataFile.read());
    }
    dataFile.close();
  }
  // if the file isn't open, pop up an error:
  else {
    Serial.println("error opening datalog.txt");
  }
}

void menu()
{
  Serial.println();
  Serial.println("Menu Options:");
  Serial.println("\tl - List files on disk");
  Serial.println("\te - Erase files on disk");
  Serial.println("\ts - Start Logging data (Restarting logger will append records to existing log)");
  Serial.println("\tx - Stop Logging data");
  Serial.println("\td - Dump Log");
  Serial.println("\th - Menu");
  Serial.println();
}

void listFiles()
{
  Serial.print("\n Space Used = ");
  Serial.println(myfs.usedSize());
  Serial.print("Filesystem Size = ");
  Serial.println(myfs.totalSize());

  printDirectory(myfs);
}

void eraseFiles()
{
  myfs.quickFormat();  // performs a quick format of the created di
  Serial.println("\nFiles erased !");
  mtpd.send_DeviceResetEvent();
}

void printDirectory(FS &fs) {
  Serial.println("Directory\n---------");
  printDirectory(fs.open("/"), 0);
  Serial.println();
}

void printDirectory(File dir, int numSpaces) {
  while (true) {
    File entry = dir.openNextFile();
    if (! entry) {
      //Serial.println("** no more files **");
      break;
    }
    printSpaces(numSpaces);
    Serial.print(entry.name());
    if (entry.isDirectory()) {
      Serial.println("/");
      printDirectory(entry, numSpaces + 2);
    } else {
      // files have sizes, directories do not
      printSpaces(36 - numSpaces - strlen(entry.name()));
      Serial.print("  ");
      Serial.println(entry.size(), DEC);
    }
    entry.close();
  }
}

void printSpaces(int num) {
  for (int i = 0; i < num; i++) {
    Serial.print(" ");
  }
}

Note: I am using a slightly updated version of the MTP library for this, in which I merged in my earlier fixes for sending events both for T3.x as well as T4.x... So far I have only tried this sketch on locked T4.

https://github.com/kurte/MTP_t4/tree/Minimal_changes

Note: You need to build sketch to include MTP as a USB type.


So far I was able to have the sketch create new files and delete files and the doing a refresh on Window 10 (F5) the files were properly updated...


Lots more fun extensions are possible to this, including maybe enhancing FS to support create/modify dates. My previous version has this, and worked so far with SD FS... Not implemented yet in LittleFS but there were places on Web where it has been done. ... Was also previously integrated with MSC as well.

But first off wondering if this is something interesting and then how far we should take it.
 
Status
Not open for further replies.
Back
Top