[throwaway81523]

Yeah, it is pretty weird. TLDR: the BFree board is an energy harvesting gizmp connected to an MSP430 microcontroller with nonvolatile (FRAM) memory. It saves energy in a capacitor until the MSP430 app decides there is enough to power up an Adafruit Metro board (ARM Cortex M0) running circuit python. That board then runs for a few seconds til the energy runs out, saving its state in the MSP430 FRAM now and then. When power is later restored, it reloads state from the last checkpoint. The 430 itself may also get powered on and off, not sure.

All cute, but might as well leave the Cortex M0 out of the picture completely, or else connect some SPI FRAM to it (available from adafruit) and skip the MSP430?

The MSP430 is underappreciated partly because no one cares about 16 bits any more, but the FRAM parts are very cool, and the MSP430 itself is quite nice as a Forth host. So if you want that energy harvesting thing with an interactive interpreter environment for some reason, just run e.g. Camelforth on the MSP430. Otherwise, you can also program the 430 in C using msp-gcc.

This whole harvesting thing is kind of weird on a board that big. Digital wristwatches from the 1980s could run for 10 years on a coin cell, solar cells can provide useful power even under indoor lighting, etc.

There's an ACM-walled paper here: https://dl.acm.org/doi/abs/10.1145/3432191

It's not clear from the visible abstract where the harvested power comes from.

Edit: in one of the photos the board is shown with a solar cell.

[Chris2048]

Doesn't the ESP32 have something like this: a second low-power cpu (Ultra Low Power coprocessor) that can wake up the main processor periodically, and then turn it off for simple operations, such as timed sleeps or waiting for input (aka interrupts). Not sure how (volatile) memory is managed though, or is maintaining it is power-intensive.

[throwaway81523]

The ULP coprocessor still uses a small amount of power, as does its few KB of NVRAM. The idea of the intermittently powered FRAM thing is that it can be powered down completely, then start up again and continue from a checkpoint. I haven't read the paywalled article, but it looks to me like the main contribution in the project was hacking circuit python to transparently checkpoint itself every so often, so that it can restart when power is restored.

I don't really understand why they used the second (msp430) microprocessor, instead of add-on FRAM like this: https://www.adafruit.com/product/1895

It also seems to me that micropython is great for some things, but in this particular deployment it is increasing the hardware cost and complexity quite a bit.

[Chris2048]

Yep. I think for limited resources, micro-py is the wrong approach. That it is interpreted aside; I had a lua-based interpreter crash because the stack/heap in a nested routine (ie lots of nested fn calls) managed to fill up available memory.

[jhgb]

Sounds almost like an ideal use case for Oberon to me - perhaps with remoting the UI or something like that. Chances are that a full environment would still be smaller than this micro-py thingy, whatever that is.