On Apr 15, 2012, at 7:58 PM, Pete Turnbull wrote:
Then someone
mentioned doing it with an Arduino or something of that
ilk. But, on investigating, the uP solution would have drawn enough
power to significantly impair battery life as compared to my circuit.
Apparently my first reaction was the righter answer. :)
I wanted a slave flash trigger which would be compact, and smart enough to work for
ordinary flashes (from an SLR with a conventional flashgun) or for a compact (which has a
pre-flash that can't be disabled). My design used a small PIC, a phototransistor, a
few resistors, a small thyristor, and a CR2032 lithium cell. It's turned on and off
by a momentary pushbutton, or can be made to go to sleep or wake up by the PIC's
internal timer. It runs for months on a single CR2032, because the current draw is very
low. So a properly-designed uP solution needn't be a problem.
Yes, but an Arduino is seldom part of that solution space for the
low-power domain. Great for tooling around, yes, but you need to be
rather careful in doing low-power design.
I did a PIR sensor for a wildlife camera motion detector complete with
ambient temperature sensing (for the PIR delta temperature), light
sensing (to enable an external flash) and picture rate throttling on
the smallest MSP430 (2K program space, 128 byte SRAM) and it ran under
10 uA average. I did in C because other people would have to maintain
it; I probably could have cut down the size more if I used assembler.
I don't want to think about what the execution time (and thus the
current consumption) would have been for an interpreted language.
Forth, though, might have been a good solution space there. That's
what I'm using for our new line of wireless sensor nodes (at least for
the on-board peripheral board drivers; can you tell I miss Open
Firmware?). Compact representation, reasonable execution time, what's
the problem? (answer: The AVR is a terrible platform for a Forth
interpreter, but at least that's not our only CPU architecture)
- Dave