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

BFree – A battery-free prototyping platform with CircuitPython for Adafruit(github.com)

44 points by erwinmatijsen 4 years ago | 12 comments

bobsmooth 4 years ago |

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.

Chris2048 4 years ago | | |

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.

Brian_K_White 4 years ago | |

Like the dedicated bootloader mcus.

dotancohen 4 years ago |

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.

HeyLaughingBoy 4 years ago | |

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.

jhgb 4 years ago | |

> 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.

dotancohen 4 years ago | | |

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.