The syntax is Mm.Info(Platform)
No word Option in there.
Right you are, doing it from memory.
Tom
Worked fine for me too, thx !
I’ve got the Platform option defined now. (Hard-coded with the rest of the options that already were for PicoCalc.)
The official Clockwork sources for their PicoMite port hard-code all options, which looks to be different from how all other PicoMite platforms were handled. I’m guessing everyone using other platforms makes sure to define the platform in their code if they want it to run on a speciifc device? I think it does make sense to have the options built in for PicoCalc though, at least for things like hooking up the display, keyboard, SD, etc. since the device would be useless on boot if they didn’t function. That said, I think the way it’s handled right now could be better. Without changing the original hard-coded block in FileIO.c (except to add platform), I went ahead and copied the settings over to where all the other platforms are defined in MM_Misc.c, even though it’s not really necessary right now for the PicoCalc. So in theory, defining the Platform should pull all that in, including the pin assignments for everything, etc.
While I was messing with options, I also added a default Colourcode option to be 1, since that’s something everyone was having to set manually, and it makes sense to fully use the color screen of the PicoCalc in the editor by default.
I’m just building the different versions now and I’ll post an updated release with this change.
You are certainly dedicated to the PicoCalc. It’s much appreciated!
For other PicoMite devices you usually perform a one-off connection via the serial port and issue a bunch of OPTION
commands to configure for any other hardware. Several common configurations are baked in and can be configured with a single command, e.g. OPTION RESET "Game*Mite"
.
Tom
That explains the code I saw. I’d say there are more than several.
I went ahead and added the PicoCalc options in there too for consistency, but I should probably just comment them out or remove them since they don’t really serve a purpose at the moment. I might try later to see if I could force that reset code to trigger in the other startup PicoCalc code that’s in FileIO.c. If so, then that might be a decent compromise since it would keep most of the PicoCalc platform code with the other platform code. I only did it in this build as a reminder to myself.
I am still getting “I2C Keyboard not found, OPTION KEYBOARD disabled” on the Pimoroni Pico 2 Plus.
I don’t have a Pimoroni to test with so can’t really help there. I thought it needed custom builds targeting it, or can it just use the same Pico2 builds? Hopefully some others are using it with PicoMite – main mentions i’ve seen regarding the Pimoroni have been folks using it for MicroPython.
Might also be worth using the tool to completely erase flash that was mentioned elsewhere on the forums. (That timing bug should be fixed now.)
Working well here so far on a new Pico2, thanks Madcock !!
I tried the updated release WebMite_WEBRP2350_V6.00.02RC17_a.uf2, but when I copied it over to the Pico 2W (without the PicoCalc, which has not arrived yet,) I could not remote into it with “screen /dev/ttyACM0.” Screen opens, but it just gives me a blank screen, no “>” prompt. I have used this screen command dozens of times with other PicoMites and always get the prompt, but not with this .uf2. I did try using CTRL-C to break in, but nothing.
Do I need to wait until I get my PicoCalcs? I had thought that, with the PicoCalc firmware, I could still remote in over the USB serial interface.
Doesn’t the PicoCalc version use the USB 3.0 on the PicoCalc board and disable the Pico’s USB serial interface?
That would explain it - thanks. I will just have to wait for my PicoCalcs to arrive.
Yes. I had tried the earlier, official firmware from Clockwork before I received my device and it also had this issue.
It does bring up an interesting point though. I wonder if there’s a good way to check if the PicoCalc hardware is connected and NOT switch to using the other USB port if the hardware doesn’t exist? That way a standalone Pico might still be able to run disconnected. I’ll have to take a look at that USB code and see if there might be a “nice” way to check if the module is not connected to anything.
most reliable way I’ve found is to check for keyboard/stm32 on the i2c bus…
Any chance of doing an RC18 batch kind sir ?. Hopefully this gets easier as time goes on…
The current official version of the code on github is still RC17. So until that gets updated it would be impossible for anyone to do it. Just because a new version is mentioned on TheBackShed and binaries for other platforms are posted there doesn’t mean the code is available.
I recommend checking github before asking, because that will save us all from having to write useless posts back and forth on here every time Peter releases something on TheBackShed and doesn’t update the sources. I do appreciate a heads up if there’s an update that is actually available though. But impossible requests are, well, impossible.
Catching up on TheBackShed posts it looks like Peter is still fixing bugs in RC18 and releasing updates anyway, which is probably why he hasn’t updated the source. On a separate note, to anyone who is active both on this forum and on TheBackShed, I’m not sure it’s wise to mention the PicoCalc over there anyway, as it seems to be a sensitive topic. (And the keyboard mapping of DEL was an issue in the original, official release on PicoCalc. The error that I introduced accidentally was different: the i2c timing which caused the keyboard disconnect.) Anyhow, probably not a good idea to be bugging Peter about anything PicoCalc related.
Thanks for the heads up, any idea re the weird editor behaviour when escaping without changes ?. Not sure but seems this may have been introduced with your rc17…
Did you compare with guu’s original version? I’m pretty sure the editor behavior is the same there. And that’s because it seems to be the way it works in PicoMite in general (not just on PicoCalc), requiring not only the letter “Y” (or something else) to be pressed but ESC (not ENTER) to be pressed afterward for it to be accepted. I agree it’s strange if it’s intended to work that way.
I spent some time trying to get it to accept just the single “Y” keypress the other day, and the input handling on that is very weird. Short of hacking around in the input buffer itself, there didn’t seem to be a clean way to get the behavior that I would have expected.
The picocalc is increasing the userbase of mmbasic users very significantly. Why would that not be super good for the mmbasic community in the Shed? I am registered there too and just ordered a cmm2 after learning about its existence due to the picocalc forum