[MakeLV] Tweaking ED was: How Exciting!

[Mark]

On Friday 05 November 2010 09:24:02 Josiah Ritchie wrote:
> On Thu, Nov 4, 2010 at 8:25 PM, Mark <mstanley at technologist.com> wrote:
> > ------- Non-blocking Debounce ----------------------------
> >
> > //  A static variable retains its value between calls.
> > static unsigned long delay_timer = 0;
> >
> > if ( (millis() - delay_timer) > 50)  //  For best results try different
> > values. {
> >        if (leftEar.isPressed()) earCondition = 1;
> >        if (rightEar.isPressed()) earCondition = 2;
> >        if (rightEar.isPressed() && leftEar.isPressed()) earCondition = 0;
> >        delay_timer = millis();
> > }
> > ------------------------------------------------------------------
>

> I hadn't even considered doing it in software. Do I gain any benefits
> by doing this instead of in hardware?

That depends on your needs but it will reduce your parts count over a hardware 
solution.  Also, as the buttons/switches age you will be able to adjust the 
software.  If you were using hardware you would have to buy new parts.

> I'm hesitant to slow down the loop as I really like the most immediate
> feedback I can get, but 50ms isn't a big deal. 

It's about a one to one trade-off.  By using a non-blocking timer your code will 
not run any slower and may actually show a small speedup.  However, if by 'loop' 
you mean the delay between button presses I'd suggest you try a really small 
number and slowly increase it until the buttons are smooth but still fast. 

I just chose 50mS based on other buttons I've used and the fact that it will allow 
for a button to pressed 20 times per second.  How many times can you press a 
button in one second?  ;)  Might make a great game.

> My impression is that ideally this would be in hardware, just because of the
> performance question. In any case, this is a good change for the current
> version of the hardware.

Actually, if you have the clock cycles and program space the ideal solution is a 
software one.  It costs less and can be adjusted depending on how much a 
particular button may bounce.  Besides, when you begin to dig deeper into the 
electronics I think you will find that hardware basically adds delays just like the 
software does.

> Attached as a PNG since Eagle exports to that and not PDF. My Eagle
> (and schematics skills for that matter) has a lot of potential
> mistakes, so check it out with that in the back of your mind.

No worries.  The schematic is the language of electronics no matter the skill 
level of the author.  

After looking at it I would be inclined to say the pots should work without 
problem even if they are all at max.  I have an idea but if you could describe the 
problem a little more it would be a big help.

-Mark Stanley