Yeah, the backlight command was already hooked up to some code from guu’s original PicoCalc version, and that’s what I spent some time messing with. It’s definitely being run, but I don’t think it ever worked. When I realized others were pretty much using identical code to change the keyboard backlight as well as the display backlight, I figured the best thing would be to do that in PicoMite as well, and have the added benefit of simplifying things.
I also found out that we should be able to query for the current backlight value (both keyboard and display), as other firmware are doing that. So I’ll probably add an MM.INFO() command (well, two separate ones) to get those two values.
An open question is whether PicoMite for PicoCalc should automatically save a default backlight value if one doesn’t already exist in flash options, and then read from flash and restore that value on the next bootup (or otherwise use the default). I think it should probably do that for both the keyboard and display backlights. Currently, I just have a backlight command for the keyboard set in my autosave code that gets run on boot to restore it every time. But it might be nicer to just have it “remember”. And it would only be storing two 8bit INT values for that info.
All good work. I have a Pimoroni Pico 2 plus that I could help test with. Is there an existing library for RP2350B or is it more complicated than that?
I just took a look at the pinout diagram and even though the Pimoroni has different pin numbers on the board itself, the GPIO pins seem to match up perfectly with the Pico2, and there doesn’t seem to be any difference there.
While I don’t have one to test with, since the pins are the same, it might just work? At the very least, I don’t think it would damage anything if you tried it with the Pico2 build of PicoMite. I didn’t see any indication that the Pimoroni has WiFi though, so the Webmite build probably isn’t useful on it.
What I’m honestly not sure about is what will happen with regard to the 16MB of flash and the 8MB of PSRAM. My guess is that it will work, but you’ll only have access to 4MB of flash instead of the full 16MB the Pimoroni offers. This is something that would need to be adjusted in the PicoMite mainline code. I’m kind of afraid to mess around in the flash configuration there, since there’s a lot of stuff dependent on it, and it’s likely to break things if it’s not done by someone who really undersatnds it well. I don’t know how receptive the dev (Peter) would be on TheBackShed to adding support for the Pimoroni to PicoMite, but it might be worth asking there. It’s really something that should be added to the mainline code anyway, since it’s not something PicoCalc dependent, and others using PicoMite could use that hardware too.
As for PSRAM, it might be possible to access that using the build in BASIC commands. I’m not sure if anyone has successfully done that with the PSRAM that’s built into the PicoCalc, but it might be easier to get those commands to work with the Pimoroni since the PSRAM is directly on the module and not a separate/extra thing like it is on the PicoCalc board. I just looked in the manual, and a Pimoroni board is mentioned. So definitely check that and try what is suggested – it might just work. Odd that it doesn’t seem the extra flash is supported already though. Maybe there are multiple Pimoroni boards? All the more reason to ask if Peter would consider supporting it.
EDIT:
Weirdly, there’s only one mention of the Pimoroni board in the official PicoMite git repo, and it’s in the CMakeLists.txt file. But it doesn’t seem to actually do anything. It can be defined, but then never gets used. So maybe there was some intention to add support but it never got done?
As I understand it, the CS pin for the PSRAM on the PicoCalc board is 20. PicoMite only supports PSRAM on pins 0, 8, 19, or 47. I have tried setting OPTION PSRAM PIN 20 and it will not take the command. The question then becomes, can you alter the code to make pin 20 an option for the PSRAM?
Thanks for that info! I’ll add that to the list of things to look at. Unless the pin is being used for something else, then it should be possible. It’s strange that it’s restricted to just those specific pins, but maybe it has to do with the expectation that VGA/HDMI or USB keyboard hardware would need to be accessible in PicoMite, and we don’t have to worry about that or support it for the PicoCalc build. If it turns out this is the reason and other pins could be freed up for the PicoCalc build as well, then I’ll add them in too.
For what it’s worth, wide enough kapton tape works too, to hold the screen down. (I didn’t have any good electrical tape.) That said, since I got my repalcement screen I haven’t swapped out the module again. But I’m less afraid to swap modules again. The screen won’t shift with it taped down. Ultimately I think I’d like to have two devices – one for Pico2W and one for Lyra, but realistically with the tariff craziness that may not end for a while, I might be swapping things around at some point.
Depending on how much older those builds were, the keyboard error might have still been a thing for everyone. It persisted for a while, even after I thought I had fixed it, but it shouldn’t be a problem now. And the mainline display code changes along with some extra cleanup for PicoCalc should mean the current version is more reliable in general, and faster for display updates. Seems like the Pimoroni is the same in terms of of the Pico processor, so I doubt that would require any code changes. The PSRAM and larger flash seemed to be the only difference. (I hope!)
The PicoMite firmware fully supports the RP2350B. It automatically configures itself for the extra pins. In addition, it automatically configures the amount of flash memory.
True PSRAM which shares the QMI/QSPI bus with flash and is memory mapped can only be configured on pins 0, 8, 19, or 47. This is a limitation of the RP2350B H/W. The PSRAM on the picocalc is not on the QMI/QSPI bus and is not supported by MMbasic. The Pimoroni boards which have PSRAM can be used by MMBasic as-is. Just set the PSRAM pin to GP47. Be aware that the Pimoroni boards with PSRAM do not overclock particularly well and 378MHz may not work.
I’ll be trying this soon hopefully with the Pimoroni pico plus 2W. Also hoping the larger package of the rp2350b will lend itself to slightly cooler running and maybe a (larger) heatsink one day
Happily running a Pi pico2 at 360Mhz currently,
doesn’t exceed ~40c. Will be interesting how the Pimoroni 2350b performs…
The PicoMite firmware does not support the Pimoroni pico plus 2W only the non-wireless version.
The Pimoroni pico plus 2W will probably just behave as a standard Pico2-W
Ill be trying a Pimoroni Pico plus 2W soon… Larger 2350B processor so possibly different thermals due to the larger surface area. Will possibly try a heatsink too.
Just dropped in my Pico2 Plus and I2C Keyboard not found.
Seems to be a hardware issue as the umac emulator also does not pick up the keyboard. Either it could be 2350B specific compiling needed or my board is malfunctioning.
I would say just get a Pimoroni Pico Plus 2 or Pico Plus 2 W, which have built-in PSRAM – they really aren’t that much more expensive, all things considered, and using them will be much easier and probably less error-prone than doing a hardware mod to wire up the PicoCalc’s PSRAM.
I’m not sure what I can do or test for that, as I don’t own a Pico2 Plus. The PicoMite manual doesn’t mention it much, beyond the PSRAM, and this one part about using it with HDMI. That’s not relevant for the PicoCalc, but maybe the warning about overclocking is relevant and might be causing your issue?
Probably the best way to find out more would be to ask on TheBackShed, probably in a new thread here (I didn’t search for relevant threads though, so there may already be discussion on there that would be worth checking!) Since it’s mentioned in the manual, and @picouser confirmed above that it should work, that probably means someone is at least using the module over there. It probably won’t be using the same display, and it definitely won’t be using the same keyboard, but if there are any tricks to getting it to work at all even with just a serial connection that might be useful to know.
Looking at the official firmware releases for both 6.00.01 and the 6.00.02 RCs it doesn’t appear that there are special builds for the Pimoroni. So I’m guessing anyone who has one must have used the regular RP2350 build. If so, then I’m not sure why the same build, modified for the PicoCalc hardware wouldn’t work on the Pimoroni. The pinout seems to be the same, but maybe it’s somehow incompatible with what the PicoCalc board is doing with the same pins.
You mentioned uMac having a similar issue. It might also be interesting to see if the MicroPython, uLisp, or other folks doing stuff with the PicoCalc have used a Pimoroni Pico2 and got it working. If no one has managed to get it working with the PicoCalc hardware, then that would not bode well. But maybe someone actually has that module and is trying to get it to work, or has managed to get it to work, and that would be useful information that could be adapted.
So, I actually merged the code and built it late last night, but didn’t have time to really test it and decided to do a sort of silent release and then post once I was more confident it was working.
Looks like Peter cleaned up a number of things and fixed some bugs. It seemed to work well when I got around to trying my release. I didn’t have the display backlight stuff ready, but I’m planning to get that done this week. As mentioned on the release, guu last posted a merged SD_Boot bootloader and PicoMite build (for Pico only, not Pico2). I have mixed feelings about that, as I’d kind of prefer to have PicoMite/Webmite and all the other options (MicroPython, uLisp, etc.) as separate “apps” that the trimmed down bootloader could load at startup. Combining PicoMite into the loader is cool, but it means that not only is the usual amount of flash taken up by the PicoMite firmware, but also some extra space is taken up by the bootloader, and also the “first stage” bootloader that checks if the SD is inserted. With only the simple bootloader as firmware, we’d have all the usual space taken up by the PicoMite firmware free to do with as we pleased (minus the usual storage for saved options). Plus, this sounds like a potential nightmare situation to try to keep the bootloader and PicoMite in sync, as the bootloader itself is still a work in progress, and one of the features they are investigating would make this combined loader unnecessary anyway. So personally I think that lighter weight option might be better. I’m going to take some time this week and see if I can get the merged and the standalone loader working for new PicoMite builds on the Pico2.
