My next project is to be a hackable, wearable LED toy. I’m designing it to be self-contained, with a lithium cell, charging circuit, and boost regulator all on the same board. To that end, I figured the easiest pathway to follow to make it easily hackable would be to use an ATMega32U4 MCU, and have it present over USB in the same way the Arduino Leonardo does.
Since I’d already measured the average power usage of the prototype at around 100mA, I figured I’d start with the power system.
Panacea denied
This kills the cell.
I began my search looking for an all-in-one solution which could charge the battery, provide boost regulation to 5V for the LEDs, and provide an undervoltage lockout during discharge. While the lithium cell I’ve chosen in the interim has a protection PCB built-in (as will any future cell), said protection circuits are designed solely to save the battery from catastrophic failure modes — swelling, leaking, bursting into flames — but not from any mistreatment which will “only” shorten its cycle life by a large factor. And unless there’s something I’ve grossly misunderstood about protection circuits, I figure having a second UVLO can only add to the safety margin.
It would seem there are a few power management ICs on the market which will handle charging, 5V boost conversion and UVLO, but after reading a few datasheets, it became apparent that these are designed specifically for smartphones that use 3.3V internally, and only provide 5V over a USB-OTG port. And because of the restrictiveness of USB-OTG (in that there is only one port to get power both in and out of a USB-OTG device), they’re designed to run either the boost converter or the battery charger, but not both — and require a pin to be pulled low in order to fire up the boost converter.
Now, that might not seem like a big problem, since it’s not like the LEDs on the front need to be running while the device is charging (although that would look pretty neat). However, the ATMega32U4 needs to be powered up in order to be programmed, so if the charger is going to fire up while there is bus power coming in through USB, it can’t shut off the 5V booster powering the MCU, which these PMICs do by design.
As a sidenote, I feel like this could be solved by changing the power switch for a DPDT switch, but I don’t really feel like going back through yet more PMIC datasheets now that I’ve selected components around and captured schematics for individual boost and charge circuits. Regardless of this, I’m going to try my darndest to have the LEDs glow dimly while the battery is charging.
I ended up going with Microchip’s MCP73831 for charging, and Texas Instruments’ TPS61202 for the boost converter. If you noticed that these resemble the chips SparkFun use for their PowerCell charger/booster board, that’s because they are identical (except that the PowerCell uses the TPS61200 to get a selectable 5V/3.3V output). While I could have copied SparkFun’s schematic wholesale, I opted to follow the design procedure so that I understood what I was doing. Using the instructions on the TPS6120x datasheet was straightforward enough, but being able to compare my schematic to not one but two completed circuits was immensely helpful.
Apple pies
“If you wish to make an Arduino from scratch, you must first listen to metal” – Carl Sagan (paraphrased)
From previous experience with ATMega328p-based boards (Arduino Uno and variants) I figure I’ll have to flash a bootloader onto the chip via ICSP, which I have broken out onto a header in my circuit; once this is done it ought to be programmable via USB.
I had initially considered doing away with an external oscillator crystal, and just using the internal 8MHz RC oscillator on the ATMega32U4. However, this comes with its own set of complications. From what I’ve read so far, the Caterina bootloader that the Leonardo uses is built for running at 16MHz, and the USB communication depends on this being set correctly. So instead of flashing the pre-built Caterina-Leonardo.hex file provided by Arduino, I’d have to compile Caterina with F_CPU=8000000 and flash that.
Then, this means creating an Arduino “board” definition which includes the compiled bootloader and a bunch of other stuff, which is getting heavy for what will (at least initially) be a small-run device. On top of that, Matt Mets of Blinkenlabs (who make this nifty thing) informs me that the RC oscillator isn’t all that stable in the first place, and doesn’t recommend it when USB communication is needed.
Conclusion: Not worth it, just use a crystal.
More details to follow…