The key to making TIMESQUARE practical was to trim the power-down current as much as possible. Certainly, the running current is important too, but the power-down state is where the watch will spend most of its time by far. There may be idle times when it’s left in a drawer for days or weeks…maybe even months, though we hope not…and it has only a single coin cell to draw from. As you can imagine, considerable effort was spent testing and measuring sleep modes and disabling every possible peripheral to reduce the idle current.
One of the more power-hungry peripherals on the ATmega 328P is the brown-out detect circuit, which senses a low voltage condition and calls an interrupt function, the brown-out reset (BOR) handler. This feature is used in products for such things as storing state information in EEPROM before gracefully shutting down. The BOR circuit is enabled by default on the Arduino…and this is very important.
Certain Atmel chips…the 328P among them…can disable the brownout circuit in software (rather than configuration fuses), potentially saving many microamps of current. If you’re programming a “raw” chip via the ISP header, that’s fantastic…if you need to save every last bit of power, and if you don’t need the brownout detection, have at it. But if you’re using a bootloader-based programming system like Arduino, disabling BOR can have disastrous results!
As the supply voltage dips below the brownout threshold, without BOR the chip will start to behave erratically, and may spontaneously jump to any random memory location. And if that code eventually leads into any bootloader function that erases or writes a flash page, the application — or much worse, the bootloader itself — can become corrupted, leaving no easy way to re-flash the watch.
This is NOT the unlikely one-in-a-million change you might think! First, the watch WILL repeatedly brown out any time the battery runs low. Second, keep in mind that it doesn’t have to jump exactly to the start of a block-erasing function, just to any code that may eventually lead there. The odds of this happening during an unprotected brownout seem to be about 1 percent…the phenomenon has been observed in the wild with other projects and even while developing this code…it’s a real thing! So BOR is left enabled to provide a proper safety net. If you’re programming for an Arduino bootloader-based board, you should too.
Really, resist the allure of the nano-amps, DO NOT go blindly adding BOR-disabling code to your project, you'll regret it later. Just don't. Okay? Don't. Thanks.
One of the more power-hungry peripherals on the ATmega 328P is the brown-out detect circuit, which senses a low voltage condition and calls an interrupt function, the brown-out reset (BOR) handler. This feature is used in products for such things as storing state information in EEPROM before gracefully shutting down. The BOR circuit is enabled by default on the Arduino…and this is very important.
Certain Atmel chips…the 328P among them…can disable the brownout circuit in software (rather than configuration fuses), potentially saving many microamps of current. If you’re programming a “raw” chip via the ISP header, that’s fantastic…if you need to save every last bit of power, and if you don’t need the brownout detection, have at it. But if you’re using a bootloader-based programming system like Arduino, disabling BOR can have disastrous results!
As the supply voltage dips below the brownout threshold, without BOR the chip will start to behave erratically, and may spontaneously jump to any random memory location. And if that code eventually leads into any bootloader function that erases or writes a flash page, the application — or much worse, the bootloader itself — can become corrupted, leaving no easy way to re-flash the watch.
This is NOT the unlikely one-in-a-million change you might think! First, the watch WILL repeatedly brown out any time the battery runs low. Second, keep in mind that it doesn’t have to jump exactly to the start of a block-erasing function, just to any code that may eventually lead there. The odds of this happening during an unprotected brownout seem to be about 1 percent…the phenomenon has been observed in the wild with other projects and even while developing this code…it’s a real thing! So BOR is left enabled to provide a proper safety net. If you’re programming for an Arduino bootloader-based board, you should too.
Really, resist the allure of the nano-amps, DO NOT go blindly adding BOR-disabling code to your project, you'll regret it later. Just don't. Okay? Don't. Thanks.
