[MakeLV] Tweaking ED was: How Exciting!

[Josiah Ritchie]

On Fri, Nov 5, 2010 at 7:28 PM, Mark <mstanley at technologist.com> wrote:
> 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:
>
>> 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.

You make a great point here. The loss may be entirely unnoticeable,
will be more flexible and hardware debounce may inhibit speed anyway.
I guess I'll have to add this change to the top of my list for testing
next time I pull ED out of the attic.

>> 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.

I'm pulling this from several month old memory archives so the data is
a bit suspect. When the sliders are all set towards the same side and
the pots (eyes) are all turned all the way down, the LEDs stop
lighting, the buzzer stops making noise and even the power light on
the Arduino goes out. It ceases to respond in any way until I reduce
the positions on the sliders. If I twist the pots to high, the sliders
cause this at a reduced position, meaning if I place them all at maybe
1/2 then I'll get the same sort of activity. It also is a bit more
sensitive when powered by USB versus a 9V and the computer(mac) will
complain about over voltage protection or something like that. That
leads to why I'm wondering if it is pulling more power at those
settings. I haven't tested it against different programs to see if I
can cause it with a simplified program or anything like that so I
suppose it could be software related, but this seems unlikely to me.

Things haven't even started yet and I'm already appreciating this
group. Thanks Mark!

JSR/