61370Re: [beam] Re: miller solar engine + arduino?
- Jun 24, 2014thanks for the feedback- definitely will give some of this a try. Yes, the LED concept was a simple one chosen for that reason - the primary focus is on getting something very low power working over months at a time, but concerns over sketch space specifically are around planned additional functionality. The random blink pattern and LED choices are quite simple, but also had built in some pulse rate receiving/detection and interactive responses that will require further code expansion on the same piece of hardware. However to your point maybe the sketch size will not be an issue even then.thanks again!On Tue, Jun 24, 2014 at 11:15 AM, Martin McKee martinjaymckee@... [beam] <email@example.com> wrote:(*) The code that is used to control sleep on the Arduino is found in the "avr/sleep.h" header file. It isn't a library. Strictly, that's not important. But, the point is that it really just provides a handful of macros with assembly code bodies and, as a result, it ads very little code to the program. The reason that the macros exist, however, is that the AVR requires some processes relating to sleep to happen very quickly ( <= 4 clock cycles ) and doing it with assembler ensures that that will always be the case.Two things. One, as mentioned, it is possible to get extremely low power dissipation with the AVR microcontroller inside the Arduino. What can be an issue, however, are things like quiescent current of the regulators on the Arduino board and external circuitry ( voltage dividers, pullup/downs, etc. ). Building truly low power systems with an Arduino is possible, but it does take some work -- the trick is finding just where power is being used. The other thing to keep in mind is that generating a PWM signal for some LEDs should be an exceptionally simple job. Even with "Serial.print" debug statements, and a complex blink pattern, if the program is getting anywhere near 50% of the code space, you are doing something seriously wrong. And, in the end, software responds well to the same sort of approach as does hardware -- give it a try, and see what happens. It only takes a little time ( and there's even less chance to break something than when you have a soldering iron in hand ). Fifteen minutes trying a quick example would demonstrate that the sleep code would add almost nothing to the program space required ( * ). Don't be afraid to give it a go! What's the worst that can happen? it doesn't work?Martin Jay McKeeOn Tue, Jun 24, 2014 at 4:20 AM, rlnansel@... [beam] <firstname.lastname@example.org> wrote:It’s possible creative combination of an SE with MCU programming techniques could yield better overall performance than possible with either technique alone. In particular, it would be worthwhile using an SE to provide a wake-up interrupt to the MCU. With absolutely everything powered down, the MCU itself would draw very little current; under half a microamp is possible, depending on the supply voltage your board uses and what pullup/pulldown resistors are present.The key here is for the SE not to switch any power to speak of. It monitors the collected charge then wakes the MCU from power-down mode. The MCU then controls application of power to the rest of your system. While doing it’s bit twiddling it also monitors the charge left in the capacitor, so with suitable programming you can decide exactly how long to draw power from the cap or how low a cap voltage to allow before you stop drawing power. Once the MCU has done all it’s bit twiddling for the LEDs it executes the SLEEP instruction to start the cycle over again.-Bobby
- << Previous post in topic Next post in topic >>