BFree – A battery-free prototyping platform with CircuitPython for Adafruit | Hacker News Reader

BFree – A battery-free prototyping platform with CircuitPython for Adafruit

github.com

44 pointserwinmatijsen12 comments

An entire microcontroller dedicated to storing the state of a different microcontroller. Crazy.

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.

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.

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.

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.

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.

Like the dedicated bootloader mcus.

This does look like a great project for in-the-field devices. Especially in literal fields where power is hard to come by.

But I see no mention of atomic operations, which would be critical in such a device. Even the trivial action of associating a timestamp with a sensor measurement would require an atomic method.

Sure, one could take the timestamp before and after a method runs and reject it if the stamps surpass some delta. But then this is no longer a "your code doesn't know about it" solution, as they advertise.

The use case is a low-power device that does not use batteries but can store energy, and runs at a low and potentially-unknown duty cycle, either has no actuators, or has actuators that have a stable latching state and where the actuator remaining latched does not present a safety or operational problem.

I think that describes the use case, but besides a simple datalogger, I'm not coming up with examples of where this would be useful.

> Especially in literal fields where power is hard to come by.

Is it really? A square centimeter of a photovoltaic surface should provide you with at least a milliwatt of power on average. Thas's not to be scoffed at IMO.

The device might see that milliwatt for two minutes twice a week during winter in some locations. Planning in the field devices means planning for the worst case scenarios, not the common scenarios.

A square centimeter is a very small surface, though. Scaling it up for the worst case is hardly a problem. The board in the picture has dozens of square centimeters on its own, so wherever that board can be used, clearly a much larger PV area can be used as well.

Reply on news.ycombinator.com