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

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

Expand Messages
  • Martin McKee
    Jun 27, 2014
    • 0 Attachment
      Even when looking at the AtTiny, I stand behind the feeling that you will not be running into code constraints.  I built a rocket launch controller in 8K that had continuity check, camera control, a whole bunch of error checking, an external launch detect trigger, and was written in a bloated, object-oriented manner.  I could have easily fit it in 6k, and with work 4k would probably have been reasonable.  It all comes down to doing the work to shrink it.  Unfortunately, Arduino sketches are not the best way to get it small -- but it's a good start to get functionality quickly.  I hope you are looking to the AtTiny85 or newer tiny's, they are much more power frugal than the older models and have more features.

      Sounds like a great project!  Have fun.

      Martin Jay McKee


      On Fri, Jun 27, 2014 at 6:39 AM, Charles Eubanks cweubanks@... [beam] <beam@yahoogroups.com> wrote:
       

      thanks again for the feedback- I wanted to create something that was more interactive (responds to flashlight signals)  than just blinky for a ki.  Also taking into account a BEAM aesthetic using sunflower seed shells as the "bug" back with a green SMD LED which is a dead ringer for a firefly.  Trying to put the little BEAM I know to good use 

      AND I forgot to mention the key constraint actually and the whole reason for not putting 100% the code in arduino and instead thinking maybe MSE as a trigger/power supply.  I was  hoping to port this to an Attiny chip which has only 8k memory:


      my sketch is already at 4k not fully baked and it might still work but that was the concern about adding any external code into it... however, I will try the pure arduino approach first and add the sleep functions to see what the code adds up to.




      On Tue, Jun 24, 2014 at 12:39 PM, Martin McKee martinjaymckee@... [beam] <beam@yahoogroups.com> wrote:
       

      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