You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 16, 2023. It is now read-only.
Even without a drag/dropable file, making a list of 'files' that have been sent over serial that could be 'downloaded' or opened in Excel would be great.
The text was updated successfully, but these errors were encountered:
I know that's the best outcome, but we don't have a good way to make that possible, and the testing so far shows that there'd be a huge amount of flakyness in that approach (and inconsistency, because it's very hard to make clear that you can't just write files to this 'drive' too), so the 'read to serial' is what we're left with.
Should we consider renaming parts of the 'filesystem' package and functions to make more sense given they don't show up on the DAPLink drive? Should we call it 'internal filesystem' or something?
The datalogging and serial dumping feature enables a lot of good classroom activities and I think it helps to smooth the process for people if we do something friendly now there's driver-free export over serial.
Inside the 'fileystem' module there's a 'read data to serial' block
This blocks doesn't interact very well with the W10 app's serial data viewer.
It would be great if use of this block could trigger a 'file' object inside the serial viewer, that could be dragged back onto the filesystem.
Here's an example program:
https://makecode.microbit.org/35902-71245-24007-20291
Even without a drag/dropable file, making a list of 'files' that have been sent over serial that could be 'downloaded' or opened in Excel would be great.
The text was updated successfully, but these errors were encountered: