This is the second time this has happened to my Tufty 2350.
I just turned it on by pressing reset and got a blank screen. Pressing Home does nothing. Windows explorer shows it as USB Drive, and I get a Please insert disk into USB Drive.
If I put it into USB Disk mode by pressing Reset twice I get the USB Disk Mode screen on the Tufty. Windows explorer shows it as Tufty. If I double Click it, it shows as blank, no folders or files.
The first time this happened I could not get it into boot mode. I had to remove the case and unplug the battery to do a full reset and boot into boot mode. This time it has gone into boot mode and shows RP2350.
So nows the question? Do reflash with the release uf2 or go with the Dev version? @BillyTPilgrim@gadgetoid
EDIT: When ejecting after doing editing etc I always get "An error occurred while ejecting âTUFTYâ
I can only recommend not to edit directly on the device. Edit on your PC and copy the file(s) with the explorer to the âUSBâ-drive once done. The explorer knows that this is a removable device and takes care, but the editor might not.
Iâm making sure to close Thonny, file explorer, etc. Even if I just mount it, then eject I get the same error? It looks like Iâm going to have to edit a copy on the PC anyway, or lose all of what I have done the next time it happens.
EDIT: And this last time it happened I wasnât mounted or editing anything. I was using it last night just fine, Then when I turned it on this morning nothing?
The USB-drive feature is something Pimoroni added to their MicroPython fork. CircuitPython has this since years. I think it will take some iterations until this feature is stable. I also monitor the Adafruit CircuitPython forum. And while it still does happen once in a while that the USB-drive content gets corrupted, it is very seldom by now. I only experienced it once within a few years, and that was probably due to a problem of one of my USB-hubs.
So maybe you try the development release. As I understood, it did fix something.
I have now flashed it with the Dev Release. Iâll see how this goes. Iâm also going to pay attention to how I do things to try and mitigate it happening again.
I always run code on-the-fly on the device while I am developing. I like the instant feedback and quickly change code and re-run to see the result. Using keyboard shortcuts this is literally quite instant to follow the REPL output and adjsut code accordinglyâŚ
Copying source code to an USB drive, unplug and reset (will be done automatically after unplugging the device) to run the code and see the result does significantly intercepts and breaks my workflowâŚ
A few years ago, I wanted this (Adafruit) feature so badly as it also would allow me to quickly change code on-the-go with the ipad, but no more today⌠I could have this using CircuitPython over MicroPython, but I deviced to go with Pimoroni and got comfortable with the old workflow⌠I donât want to give this up nowâŚ
@hel, any chance to get a second flash ROM under the old system to continue developing with Thonny directly connected to the PICO as it was the last couple of years�
What I have done is flash nuked my Tufty 2350, and flashed it with the tufty-v1.0.0-micropython.uf2 firmware-only image. And I had an issue when trying to flash_nuke it. It wouldnât work unless I unplugged the battery. It was the only way I could wipe it clean and ditch the filesystem burden. That being said once I get my code working, Iâll reflash with filesystem and set it up as an app.
As I understand it you should still be able to develop with Thonny if you want, though I think weâve set aspects of the BadgeOS filesystem to be read-only to try and avoid data corruption - is the issue that youâre not able to save changes to the built in files?
I believe thereâs a fix for the accidental flash wiping feature bug (as well as a bunch of other re-configuring) in the development branch, and a new release is close. If youâd like to try it ahead of time, you can download a uf2 from the checks tab of this PR (I think youâll need to be logged in with a Github account to see the download links): Development by Gadgetoid ¡ Pull Request #11 ¡ pimoroni/tufty2350 ¡ GitHub
I was referring to the mount-the-badgers-as-USB-drive thing to copy the code over to it rather than locked filesâŚ
I would like to continue to connect the devices via USB and fire it up in Thonny via serial connection to directly use REPL for debugging and bugfixing my piece of code instantlyâŚwithout unplugging and re-plugging the badger again (aka Adafruit CircuitPython style)âŚ
For my understanding the old fashioned style (as with a few years old Tufty, Badger) is no longer supportedâŚ
The new badger range introduced this external-USB-device-thing on system-level, which completely changes the way we (at least I, maybe others as well) are workingâŚ
The new programming style is a different topic as discussed here. This is also currently a significant change in what we have done the last yearsâŚ
Iâm able to connect to my Tufty 2350 from Thonny whilst itâs not in disk mode (after hitting âstopâ to interrupt what itâs doing and get a repl prompt) and run code on it - is that not working for you?
New release is now official if you want to give that a try too - youâll need to flash the -with-filesystem build to get the updated apps so be sure to back up any important code first.
I think you are missing something. You can just copy code to the device and it will autoload and run. No unplugging and re-plugging with CircuitPython. And a simple CTRL-D in the REPL does the same - this is btw a feature from MicroPython that CircuitPython also uses, they both share the same REPL implementation.
Anyhow: if you do real programming, you wonât have a single file. You will have multiple classes in multiple files and changing your code usually will need multiple files to be changed. And you will be using a professional editor. With Thonny, this is very cumbersome. The âUSB-drive thingâ letâs you just synchronize the edited files without tracking changed files manually.
But I agree: for beginners and single-file programs, Thonny is a valid editor and the new workflow is not as simple.
What we currently see: Pimoroni is merging CP features into MP. One example is the board module with logical names for all pins. That is already in CP for a long time and makes hardware-independent programming a lot easier. The other example is exposing the flash to the host. This is all in the beginning and needs time to settle.
I am not sure if all of this is a good idea, because it is no longer MP and not yet CP. So sharing code with other users that use (vanilla or whatever dialect of MP), will be much harder. As long as you stay in the Pimoroni ecosystem and are not interested in sharing (and reusing other peoples work), you are fine. And as long as you donât need hardware that is not part of Pimoroniâs MP.