Just use an RP2350 – you won’t regret it.
3 Likes
my Pico 2W is shipping rn, cause I will need one to test my OS.
It’s not what you would expect. As a Python user, you’ll have a lot of standard libraries, such as argparse, configparser, datetime, logging, and others which won’t exist.
The performance is not terrible, compared to normal Python usage. Things are just stripped down and require a bit of fiddling. That said, it’s constantly improving. I got the latest and even things like f'hello {world}' work.
The bigger differences between good MicroPython code and typical code run with CPython is that one should avoid allocation at all costs in MicroPython as MicroPython, due to having to execute with constrained memory resources without paging, and due to not using a compacting garbage collector, is very vulnerable to memory fragmentation. There have been instances of people’s MicroPython projects mysteriously failing after weeks of operation, as memory over time became fragmented until MicroPython simply could not allocate memory any more, even if there was enough free space in total left.
As a result, many MicroPython API’s are designed with write-to-bytearray usage in mind for this specific reason. This way you can allocate buffers once up front, and reuse them repeatedly rather than allocating new buffers each time you want to populate a buffer. This is idiomatic MicroPython usage, and differs stylistically with much code written for CPython.
Dynamic allocation is a problem for any embedded code, not just micropython. If you need your project to run long term, static allocation at startup is pretty much mandatory.
Of course, it’s far less of an issue on the PicoCalc, mostly it’s for applications where the unit is deployed into the field and left unattended for months or years.
For most code in zeptoforth I avoid this problem by allocating memory in a FIFO manner ─ I essentially treat memory space for each task as a stack, thereby preventing fragmentation. The main exception to this is task allocation, as tasks cannot be freed in zeptoforth ─ my solution in this case is task pools, where a fixed number of tasks are created at one time, and the memory for each task is retired and then reused without actually allocating more memory for them.
This issue with memory allocation sounds just like the one that hit me when I first started working on a library for games development. Without realising it, I used malloc/free casually and caused massive spikes at runtime due to memory fragmentation as the game ran. Once memory was allocated up front during initialisation, the game ran more smoothly.
2 Likes
has anyone tried one of the micropython ports with UF2 loader? zenodante’s picocalc_micropython_withfilesystem_pico.uf2 only gets to loading 1500/7219 and then throws ERR: Bad UF2 file
i have not yet tried a pico2 or pico2w
As far as I know, none of the MicroPython ports works with the UF2 loader.
I am using the pico 2w version from the Picocalc GitHub repo with the pico2 UF2 loader. It works, but I have not tested it beyond loading it and testing “help()”.
The problem with the existing pico2 builds is that even if it boots, any attempt to write to it’s internal flash filesystem will corrupt some chunk of itself, either filesystem or actual code. I’ve got patches for that, but I haven’t yet figured out how to replicate the existing compound builds.
I did see the corruption issue.