As mentioned in the post I linked above, Peter added more files to replace in the SDK. The new ones are gpio.h and float_sci_m33_vfp.S.
I’ll track down where they need to go and will update the documentation on my fork since it’s not really documented anywhere. (I don’t think Peter expects or encourages anyone to build from his repo since he doesn’t make it easy.) But those files should go to roughly the same locations as the other files. Just need to find the matching files in the SDK.
RC24 Working fine. Flash nuke, RC25 flashed. Tried twice, same issue and now back on RC24, working fine.
Symptom, weird one…
Entering such as d$=day$(now) from the command prompt works fine. Yet within a program seems to return a weird bag of spaces and the error something like “error, string expected”
Back on RC24 and within a program ‘Print left$(day$(now),3)’ works fine. No chance on RC25 !
Trying to flash my Pico 2W for hours now with the latest (RC25) and next-to-latest (RC24) .uf2 files – to no avail.
Tried under macOS via Finder and via commandline’s picotool with three different USB cables. No luck.
Tried under Windows 11 with the same three different USB cables just via drag & drop of the .uf2 file in Explorer – no success, either.
Out of ideas other than the Pico 2W has a flaw. Wasn’t able to flash a (general, not PicoCalc-specific) MicroPython firmware, either.
After the flashing attempts when I power cycle the PicoCalc the screen stays blank.
Thank you Madcock! Your updated compile instructions work great. I just made the revision to the RC25 source to get rid of the F2 bug (In the editor, F2 won’t run a program) and it compiled flawlessly.
This might sound like a stupid question, but did you make sure to use Pico 2 W UF2 files? Pico 1 and Pico 1 W UF2 files are not compatible with the Pico 2 and Pico 2 W excepting certain specially-crafted cross-platform UF2 files.
use a flash nuke then try dropping CircuitPython on there instead and just check in MUeditor REPL to make sure its working. this should give you an idea if its the Pico at fault or not.
Thanks, @tabemann, for the watch-out. Yes, I did use the Pico 2W .uf2 file.
There seems to be another problem, more on the hardware side, I’m afraid, because I’m apparently not able to flash any .uf2 file to my Pico 2W.
A flash nuke is a special UF2 file that, when loaded, erases all the flash on your RP2040 (e.g. Pico) or RP2350 (e.g. Pico 2 W) board. You can find a universal (will work on both the RP2040 and RP2350) UF2 file for a flash nuke at https://datasheets.raspberrypi.com/soft/flash_nuke.uf2.
yup, tabemann nailed it, and yes when your MCU flash is errased, your computer will see it as a USB storage device, open that and the drag the CircuitPython UF2 file for your MCU into that open folder. a few seconds later it will no longer be seen as a storage device (this is a good thing!). then have a look in device manager on windows for a new Com port that opened, that should be your pico, unplug and see if it vanishes, if it does, plug it back in and take a look at the com port number.
Open Mu Editor (its free to download), and that Should pick up your Pico board. IF this works then youll know that there`s nothing wrong with your Pico or flash, or even your lead and USB port.
Re-nuke the flash again, and follow the same steps again with your Picocalc firmware. if it fails, get rid of that UF2 file and re-download it again, maybe it got messed up somewhere along the way?
Hope that helps a bit
Edited to add: if you already have stuff on your pico, unplug, hold down the BOOT button and plug it back in, then you can drop your flash nuke UF2 into that drive folder.
Also, I missed that fix regardinf F2 in the editor from a few days ago, but a new release is here. Looks like there is another thing recently posted on TheBackShed that might be fixed soon as well.
Yeah, I was a little suprised that no-one on the forum had posted anything about the MM.TOPIC$ issue already since it seems like the code change that introduced the problems happened pretty early into the .02 code “branch”. Since the source repo doesn’t do anything remotely resembling versioning I don’t know when the issue actually started.
I gave fixing it a go, but my c experience is way too limited, and that seemed like a poor choice of code to improve that understanding with.
But hey, the attempt, and the efforts to make sure that the issue was not being caused by the PicoCalc modifications (Clockwork’s or yours) has left me with a working build environment on my Mac that I can easily switch between vanilla pico-sdk and the customized one for PicoMite. So I’m sure I’ll be dangerous in no time.
I get the feeling very few active posters on TheBackShed use WebMite features (i.e. internet connectivity with their Pico) at all, so I’m guessing that’s why it wasn’t tested and caught. And I wonder if the limited wireless connectivity features of WebMite may drive away potential users who end up opting for something else instead.
To be fair, I haven’t really had the time to dig into Webmite features myself and play around with what is possible. The functions seem useful, but also rather limited. I was also sad to see that no bluetooth functionality exists at all. MicroPython seems far more flexible and feature-rich for wireless communication on the Pico than MMBasic, but it also feels close enough to C/C++ in terms of complexity that I’d almost rather just go the Arduino route and use its C++ instead. Would be nice if one day MMBasic allowed for simple server/client BLE communication to be able to talk to the vast number of IoT devices out there (and say, get a temperature reading from a sensor device), but I’m not counting on that happening any time soon.
On the plus side, there are a growing number of ways to develop stuff on (and for) the PicoCalc, each with their own benefits and drawbacks.
Sadly I think you’re correct about both the lack of TheBackShed user count of WebMite and the reason.
I was more than a little disappointed at the lack of bluetooth. Though the initial draw to the PicoCalc was a mixture of it’s out of the box limitations and that those limitations might encourage me to do more than just plan projects (now that my 50 year old ADHD ass is finally medicated).
I was more disappointed when I learned that the origin repo for the out of the box firmware was setup in any way to be hostile to contribution (lack of branching, tags, etc). Even the Posted release of WebMite 6.00.01 doesn’t work properly on a Pico 2 W (after setting OPTION WIFI the radio doesn’t seem to even try to connect to anything). I wonder if at some point just hard forking from the origin code wouldn’t be in order?
He’s pushed out RC26, though the zip file doesn’t have source in it. There are changes on the repo, and some of them do make small changes around the MM.TOPIC$ but I haven’t tried building from the recent pull, but the binary works on a bare Pico 2 W with MM.TOPIC$ working.
To follow-up, I mirrored the changes he made to configuration.h and Functions.c from the recent pull I did of his repo into my last pull of yours, and the newly compiled firmware has MM.TOPIC$. I know it wasn’t the only thing he fixed, but it does look like his repo (at least as of about an hour ago) is “up to date”. I think the CHAIN command got some love as it wasn’t working either.
