Picocalc architecture

PicoCalc
1

I’m a newbie to this. I’m trying to understand the structure - the different “personalities” are from the different images available on the SD.

What is the operating system/software/bootloader that loads the selected images?

I’m envisioning that Clockworks has a BIOS that loads software images. Does that BIOS have any more capabilities than loading images?

Can I communicate with the PicoCalc (as opposed to the internal Pi) via the top USB connector?

What can I configure for everything on the PicoCalc, as opposed to having to configure on each boot image.

Is there any way to enlarge the text so I don’t have to use a magnifying glass?

2

picocalc is just a case for some microcontrollers like:

https://www.raspberrypi.com/products/raspberry-pi-pico/
https://www.raspberrypi.com/products/raspberry-pi-pico-2/

and some others

picocalc doesn’t have bios by itself, microcontroller inside load it’s firmware.

3

There’s an STM32 that handles the power, keyboard and backlights that’s controlled over I2C - this has a firmware that’s called various things, either “keyboard firmware”, “bios” or “southbridge”. It has no control over the main microcontroller and isn’t involved in loading applications at all.

On the pico that’s plugged into the picocalc, it can have literally anything on it. It will generally only be programmed with one thing at a time - there’s no “operating system” beyond what an application includes in itself.

That said, it’s possible to put a bootloader on there to allow reprogramming the flash with a new application without plugging into a PC, and there are a few options that are (currently) all different forks of an original project called SD-Boot.

SD-Boot works but it takes up a fair amount of flash space, and it requires every application to be recompiled with a custom linker script - you can’t just load the .uf2 you would have flashed directly to the pico. If you can’t compile your own apps, you’re basically stuck with the ones that already have .bin versions available (and it’s unlikely people will release any more, for reasons I’ll get to.)

ClockworkPi bundles a version of SD-Boot that they call “multibooter” which is practically the same, except the linker script is slightly (and incompatibly) different, and it’s merged with a version of PicoMite (although that gets overwritten the first time you load anything else.)

Neither of these supports the Pico 2.

I’ve released an improved bootloader called uf2loader, which is SD-Boot but it works with standard .uf2 files, supports the Pico 2, and only takes up a tiny amount of flash space while having the same interface. You can just build an application without having to worry about custom linker scripts and incompatible versions - this is why most people releasing apps for the PicoCalc are unlikely to make .bin versions, as they’re now obsolete.

There’s a minor snag with using uf2loader, though - some applications are currently incompatible because they do their own thing with flash. So you’ll have issues with PicoMite, micropython and zeptoforth. I’ve already fixed PicoMite but it has yet to get an updated release from the maintainer. The others are a work in progress.

7 Likes
4

Does flashing and debugging an application using the debug probe overwrite the uf2loader? How can that be prevented?

5

Yes, it does overwrite the bootloader - the debugger has no intrinsic understanding of the partitioning.

The simplest answer is simply not to worry about it and just flash the bootloader back afterwards. (Though this helps if you have the bootloader elf and can do it with the debugger - so you would want to build uf2loader yourself).

A more sophisticated route is to script gdb to update the address translation registers before loading. I’ve not done this (yet) and there are bound to be some niggling details, but it is actually something uf2loader does itself when loading a new application from the menu.