Loading ...
Sorry, an error occurred while loading the content.

61371Re: [beam] Re: miller solar engine + arduino?

Expand Messages
  • Martin McKee
    Jun 24, 2014
    • 0 Attachment
      Sounds like an interesting project!  In my experience, code usage has -- almost -- more to do with the implementation than with the functionality.  Creative rearrangement of code can do wonders in making it fit.  But, remember this axiom, "Premature optimization is the root of all evil."  If something doesn't fit, it can likely be fixed.  But, if it does fit, and it works, who cares if it is bigger than it needs to be.  If it ain't broke, don't fix it.  And, really, it's surprising how much functionality can be fit into the 32k of a standard Arduino.

      Martin Jay McKee


      On Tue, Jun 24, 2014 at 10:14 AM, Charles Eubanks cweubanks@... [beam] <beam@yahoogroups.com> wrote:
       

      thanks 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] <beam@yahoogroups.com> wrote:
       

      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 McKee

      (*) 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.


      On Tue, Jun 24, 2014 at 4:20 AM, rlnansel@... [beam] <beam@yahoogroups.com> 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




    • Show all 12 messages in this topic