I recently started playing with MSP430's. They are fun devices and I think there are lots of possibilities with those. I have no real experience with other uC's so I can't say anything about others or compare. Having said that, here are some very basic impressions:
TI's example code is often confusing and over-engineered. It is much better to find advice on blogs and forums instead.
The community has some great individuals that will produce great examples and tutorials. Unfortunately, it is very far removed from places like GitHub. Almost all code is shared directly in the forums at 43oh.com.
There are a couple of big projects surrounding MSP430's. Energia is, from what I understand, an Arduino-like IDE which lets you program at a much higher level, but at the cost of some performance. When you only have 512 bytes of RAM, it may or may not be an issue. Another one is BSP430 which is a lower level set of libraries. It promises much higher level abstractions at the cost of small performance penalties. I found the tutorials to be rather terse, but I may need to give it more time.
Outside of those big projects, there is lots of duplication of effort. It is typical to see 3-5 different implementations of bit-banging UART drivers that are all slightly different. I am no exception, as I started writing my own little set of libraries for dealing with various peripherals.
Lastly, a lot of the tutorials out there either use the register names directly (P2IE, P1SEL, etc) or provide really poorly named abstractions (cal_adc_15t30). Most of my time working with it so far has been spent on naming functions something like gpio_get_val(), uart_puts(), etc.
P.S.: Physical hardware buttons are terrible devices. Debouncing them is a must and most implementations in the wild are incorrect. [1] is a good read.
The problem with the raw register names is that they're not even consistent between compilers/libraries. However, they're usually the best route to go form an efficiency standpoint.
I think the core argument of the blog post is to use a voltage regulator with a low quiescent current. It doesn't really matter what uC you're using since it's only turned on every few seconds with the watchdog timer, however if you used common voltage regulators like the 7805, lm317, or lm1117, you'll use up the battery in short order.
The best thing is to NOT use a voltage regulator at all. The MSP430 line will happily run down to sub-1.8V levels, which means a pair of AA/AAA alkalines could power your project in time spans well exceeding the shelf life of your batteries (5-7 years, and this was an application coupled to a 802.15.4 radio).
For more performance oomph, there are Cortex-M3 parts which exceed or meet the efficiency of the MSP430 line, such as the Energy Micro EFM32.
I can highly recommend both MSP430 Launchpad and the STM32L discovery boards. Small investment if you want to look at something beyond the Arduino. I'd probably go with M3 cores at this point but the MSP430 has a lot of history and is maybe a bit easier to program because it feels more cohesive than the combination of ARM core with vendor peripherals.
If you want to extract the most out of your batteries, wouldn't you use a boosting reg so can extract every last bit? I think for most projects, the uC uses far less power than the auxiliary components around it, like a LED. If you boost the voltage you can use higher logic levels. There are many examples boosting a "dead" 0.5V AA battery to 3V at a lower current.
If you use a buck regulator, you could use starting voltages beyond the chip's max voltage limit and burn the power past a typical dead cell's voltage levels -- start with a 12V battery using 1.8V logic and burn the battery down to 2V -- probably around 98% used.
I think you'll find that most projects out there use a voltage regulator because you can use up "more" of the battery this way.
Boosting regulators are common, but there are efficiency tradeoffs, since: a) boosting regulators consume energy, b) boosting regulators with a sleep mode (so you're not spinning the wheels 24/7) don't start up immediately.
Two 0.9V alkaline cells can still power most microcontrollers, especially in sleep mode, and red LEDs will still light. If you really need higher voltage, than the boost is the way to go.
I previously worked off of an MSP430-turned-EFM32 product which had a MCU+radio lifetime of 5-7 years on 4-AA cells (two paralleled). Most switcher solutions we looked at wouldn't have netted a measurable increase in runtime due to the much higher sleep currents in those units compared to even the MCU.
A big reason most hobby boards use LDO regulators is that buck-boost topologies are comparatively complex. PCB layout is critical and protections are more complicated.
You'll have a really bad time if you try to build a buck-boost switcher in a breadboard and won't have a clue why its not working. On the other hand you can throw an LDO into a breadboard with a couple caps and be pretty confident it'll just work.
You are absolutely right: Once you get the uC power consumption down with sleeping, others components use the majority of the power and determine battery life for the most part.
The fruit power source made me wonder: Has anyone made a device that is powered by a growing plant? Plant-derived power could be much more robust than traditional solar cells. A solar cell fails if it gets dirty or broken, but a plant will just grow new leaves and branches.
Ever since these small devices have been in production, I've always wondered about their potential use in clandestine installations. Obviously things like the Shiva Plug are almost capable of hiding in plain site, so long as there's a plug near by.
I've also wondered if there are clamp-on induction taps that can be clamped to power lines (say, above the tiles in a corporate bathroom powering the lights) and drive low-power devices like a small Arduino.
This 9V hack is really cool for sensors and the like, but it wouldn't power a full OS with wireless AP ability for very long.
Powered by an external radio beam. Transmits by modifying that same beam and reflecting it back. No internal power source. No active transmission. Weighs 1.1 ounce and was built in 1945
This is a wonderful little piece of information. Thank you.
I had the crazy idea a while back about stuffing a micro-controller, temp+humidity sensor, piezo speaker into my guitar case to let me know if the Humidity got out-of-band but I couldn't see how to get this to run for more than a few days with out having a gian5t battery pack or having to plug it in to the wall.
Excellent writeup. Thanks. Are you planing on covering
the "What else can you do?" stuff in more detail in another
post? If not, then adding a few more details/links in that
part would be an idea for improving something that's already
great.
I have a dark corner near the entrance door and I made a battery-run light (2 LEDs - to light up the key hole) with very simple logic: when you press the button, it lights up for 2 minutes, then blinks for another 2 minutes; then blinks faster for another minute; then goes dark.
The button is wired to "reset" pin of an attiny45, the LEDs are connected to two pins of the chip, and the code, predictably, ends with a low-power sleep instruction.
Two 2100mAh AA-sized accumulators provide the power.
I "launched" it into use about 4 months ago (I forgot the exact date), still did not have to recharge.
Unhelpful when you are putting in the keys - better strobed full-light than dim - the latter sounds cool but is impractical. The human vision is much more effective at flash-like lighting than at a constant near-zero one. At least, mine and my cohabitants :-)
Try it IRL and then tell me your opinion, I'm curious to know your opinion.
Power savings as well as signalling where we are in the cycle. One interval is 1:3 the other minute 1:4. Feel free to press the button to reset to the beginning of the cycle if you feel it is not enough.
exactly. This is to say "soon it will be dark, press the reset if you are sure you need a lot more time and just hurry up if you do not". Most of the time it really is no-op though.
I'd love to see a pre-packaged low power optimized Arduino. This would open up a ton of possibilities that I daydream about. I don't want to solder chips myself, though.
I'm not sure if that makes sense. I think you'll find that most of the time when you do a project, the microcontroller is the component that uses the least amount of power compared with your other parts.
It does, for certain use cases (see the guitar case humidity monitor mentioned above). In the RAMPS stack for the 3d printer I'm building where the heated elements and stepper motors burn up proportionally more power, it wouldn't make sense.
This would be a specialty flavor of the arduino, not a change for the standard.
A good option when you only need to monitor a few signals is to use an xbee series 2 module, that will also wirelessly transfer the data to a central server. It can run attached to an Arduino, but also stand-alone. "Building Wireless Sensor Networks", by Robert Faludi, is a very readable introduction.
Cool starter project! You could solve this problem in a couple of different ways.
The most obvious would be running the circuit off of the fridge power supply directly. I'm not sure how comfortable you would be with re-wiring your fridge though. The potential to start a fire is probably relatively small, but it still exists.
Another option would be running a small heater around the battery itself. It shouldn't take very much power to keep a 9v warm enough for minimal losses in a fridge. (http://www.bipowerusa.com/products/bipower-bl9v-u.pdf)
I've pondered having the device use the fridge bulb plug for power. But that's only designed to be powered when the door is open. So we can use batteries or capacitors, which is back to problem #1. Or we can tape the door switch to be always-on, but I'm concerned about the power drain.
Ultimately, this device would influence refrigerator manufacturers to include this technology in their base models. I'm tired of fiddling with dials to try and figure out if my fridge is at 2C or 5C or -1C. (38F or 42F or 30F). I want fridges to know what their internal temperature is, and what we think it should be.
I'm thinking more about ensuring wide adoption through low-cost and low-intrusiveness. Modifying my fridge would make a good Hackaday post, but not such a good Kickstarter project.
(Maybe even a fridge/freezer with a barcode scanner and multiple compartments -- give it a database table of appropriate temperature ranges for different foods and let it set the temp in each compartment automatically. It could keep your ice cream from melting and prevent your lettuce from freezing? How about sectional temperature controls, like in car cabins?)
True, but if someone is going for low cost off the shelf 9 volt batteries it could be a temporary solution. Plus they would learn how to build an electrical heater, which is a useful skill to have for lots of applications.
I'd consider finding a ribbon cable to run into the fridge for the thermocouple in the fridge. If you find a nice thin one you can avoid having the uC and power inside the fridge eliminating most of those problems. Though this would be a less aesthetically pleasing method. As for your broken arduinos it's possible to program them again most likely with something like the USBtinyisp, at least if you haven't fried the uC itself.
I've thought of several variations on this idea. The most feasible was to have all of the electronics contained inside a plastic box, and this would stick to the side of the fridge with magnets. I'd run a tiny 3-wire cable to the temp sensor, which would sit inside the fridge. It's not the most elegant solution, which is what I'm chasing.
I'll look into reprogramming them, but assuming the Arduino prototyping board is ok, I'm only replacing the ~$5 ATMega processors.
