AT90S2313 | AT90S8515 | ATMega | ATmega128 | ECL | FETS | IAR | Keyboard | LCD | STK50 | TMOS | UART

I just got the STK500 and the butterfly. Any tips or tricks to start
next? I am still waiting for the two books on the AVR to come in the
mail to learn more about them. Thanks.


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

I haven't used a Butterfly yet, but one word of advice - make sure your
fuse bits are set correctly. They are not set by the hex file you load
into the AVR, like some other programmers do. They are set with AVR Studio
in a separate window. I went round and round with that when I first
started trying to program AVR's with the STK500. Once I realized what
was happening, it was easy.

So, for the Butterfly, I'm sure it comes with directions. Follow the
directions for the Butterfly and the STK500 and hopefully things won't be
too difficult.

Zack

On Sat, 13 Jan 2007, Brian wrote:

> I just got the STK500 and the butterfly. Any tips or tricks to start
> next? I am still waiting for the two books on the AVR to come in the
> mail to learn more about them. Thanks.


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

Hey Brian,

I am kinda like on the same stage as you are. I just got my home-built
programmer ready for atmega32. I am using PonyProg for programming it. Tell
me one thing, which books are you getting? Can you send me the titles etc.

Besides, what made you come to AVR?
Regards,

Rakesh.

On 1/13/07, Brian wrote:
>
> I just got the STK500 and the butterfly. Any tips or tricks to start
> next? I am still waiting for the two books on the AVR to come in the
> mail to learn more about them. Thanks.
>
>
>

--
Rakesh.
http://gopchandani.wordpress.com
[Non-text portions of this message have been removed]


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

I just got the books today. They are Programming and
Customizing the AVR Microcontroller and AVR An
Introductory Course. I just did a search in the groups
for AVR to try to find an active group to learn about
the AVR and get some tricks. Once I learn and program
some I may be able to share some of my projects with
everybody else.

Brian
--- Rakesh Kumar wrote:

> Hey Brian,
>
> I am kinda like on the same stage as you are. I just
> got my home-built
> programmer ready for atmega32. I am using PonyProg
> for programming it. Tell
> me one thing, which books are you getting? Can you
> send me the titles etc.
>
> Besides, what made you come to AVR?
> Regards,
>
> Rakesh.
>
> On 1/13/07, Brian wrote:
> >
> > I just got the STK500 and the butterfly. Any
> tips or tricks to start
> > next? I am still waiting for the two books on the
> AVR to come in the
> > mail to learn more about them. Thanks.
> >
> >
> > --
> Rakesh.
> http://gopchandani.wordpress.com
> [Non-text portions of this message have been
> removed]

____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121



(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

--- In a...@yahoogroups.com, "Brian" wrote:
>
> I just got the STK500 and the butterfly. Any tips or tricks to start
> next? I am still waiting for the two books on the AVR to come in the
> mail to learn more about them. Thanks.
>

When learning AVR with the butterfly, maybe Smiley's book "C
PROGRAMMING FOR MICROCONTROLLERS" (can be obtained as PDF in no time
at: http://www.smileymicros.com/) might be a good investment.

HTH, Stefan


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

--- In a...@yahoogroups.com, "Stefan Wimmer" wrote:
>
> --- In a...@yahoogroups.com, "Brian" wrote:
> >
> > I just got the STK500 and the butterfly. Any tips or tricks to
start
> > next? I am still waiting for the two books on the AVR to come in
the
> > mail to learn more about them. Thanks.
> > When learning AVR with the butterfly, maybe Smiley's book "C
> PROGRAMMING FOR MICROCONTROLLERS" (can be obtained as PDF in no time
> at: http://www.smileymicros.com/) might be a good investment.
>
> HTH, Stefan
>
C programming seems easier. but when compilied would the file size be
the same or smaller than programming using the instruction set for the
controller? Would the C complier add extra stuff that could be
shortened by using the instruction set?

Not knowing how big 1K of memory really is (not 1024) but how many
instructions/lines of code can be used with an 8 bit controller? This
would help in the future on deciding which chip to use.

Off to reading more of my books.

Thanks,
Brian


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

I have not done a lot of programming with C as I prefer assembler. But
some the programs I did with C, I also did in assmebler. The assembler
programs generally came out smaller because of redundundancies in the
C-compiled program.

You also learn little tricks in assembler to shortcut things that I don't
think C can do.

Zack

On Sun, 14 Jan 2007, Brian wrote:

>
> C programming seems easier. but when compilied would the file size be
> the same or smaller than programming using the instruction set for the
> controller? Would the C complier add extra stuff that could be
> shortened by using the instruction set?
>
> Not knowing how big 1K of memory really is (not 1024) but how many
> instructions/lines of code can be used with an 8 bit controller? This
> would help in the future on deciding which chip to use.
>
> Off to reading more of my books.
>
> Thanks,
> Brian


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

On Jan 14, 2007, at 12:38 PM, Brian wrote:

> C programming seems easier. but when compilied would the file size be
> the same or smaller than programming using the instruction set for the
> controller? Would the C complier add extra stuff that could be
> shortened by using the instruction set?

In theory you could write exactly the same code in assembler as the
compiler generated.

In practice one writes smaller code in assembler than the compiler
when the project is small. When projects get larger C starts winning
as its easier to reuse sections of code, and to abstract modules so
that one can forget about other things and concentrate on the
immediate item.

An important thing to consider is ease of maintainability of your
code in the future. Is very hard to write assembly that another can
understand. Is almost as hard for one to write assembly today that
you can still understand in 2 years.

Its very possible to write C that another can not understand. But it
is easier to write C that another can understand than assembly.

> Not knowing how big 1K of memory really is (not 1024) but how many
> instructions/lines of code can be used with an 8 bit controller? This
> would help in the future on deciding which chip to use.

14k was enough in avr-gcc for a robust application interfacing an
electric power meter and cutoff relay to a cellphone. It supported
scheduled events such as "report meter reading every month".
Monitored peak consumption, power outages. Could automatically report
these events, or not. Configuration was via ASCII Modbus on serial
port. Forgot how many thousand lines of code, probably 3500. No
longer have access to that project so I can't say for sure.

--
David Kelly N4HHE, d...@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

Yes indeed it is a known fact that GCC compiler generated hex files are
comparatively larger. Besides, they are not optimized code versions. It
provides you simplicity with all the extra code generated by the compiler's
rather generic coding/building mechanism.
Rakesh.

On 1/15/07, Zack Widup wrote:
> I have not done a lot of programming with C as I prefer assembler. But
> some the programs I did with C, I also did in assmebler. The assembler
> programs generally came out smaller because of redundundancies in the
> C-compiled program.
>
> You also learn little tricks in assembler to shortcut things that I don't
> think C can do.
>
> Zack
>
> On Sun, 14 Jan 2007, Brian wrote:
>
> >
> > C programming seems easier. but when compilied would the file size be
> > the same or smaller than programming using the instruction set for the
> > controller? Would the C complier add extra stuff that could be
> > shortened by using the instruction set?
> >
> > Not knowing how big 1K of memory really is (not 1024) but how many
> > instructions/lines of code can be used with an 8 bit controller? This
> > would help in the future on deciding which chip to use.
> >
> > Off to reading more of my books.
> >
> > Thanks,
> > Brian
> >
> >
>

--
Rakesh.
http://gopchandani.wordpress.com
[Non-text portions of this message have been removed]


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

On Mon, Jan 15, 2007 at 11:52:37AM +0500, Rakesh Kumar wrote:
> Yes indeed it is a known fact that GCC compiler generated hex files
> are comparatively larger. Besides, they are not optimized code
> versions. It provides you simplicity with all the extra code generated
> by the compiler's rather generic coding/building mechanism.

Sounds like one who hasn't actually tried avr-gcc.

Avr-gcc optimizes very well. It writes very good nearly optimal code for
the stack and register model it follows. About the only way one can beat
avr-gcc is by taking shortcuts in register allocation and calling
convention. And in doing so one generates delicate code which is easy to
break.

What Rakesh says is very true if one were talking about Microchip's C
compiler for the PIC-16 about 6 years ago when I last looked.

--
David Kelly N4HHE, d...@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.



(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

Yes I may be wrong. I have just started working with AVR-GCC and the
comments I made was extrapolation of what I knew about compilers from a
Computer Architecture course at college.

Thanks for correction David.
Rakesh.

On 1/15/07, David Kelly wrote:
>
> On Mon, Jan 15, 2007 at 11:52:37AM +0500, Rakesh Kumar wrote:
> > Yes indeed it is a known fact that GCC compiler generated hex files
> > are comparatively larger. Besides, they are not optimized code
> > versions. It provides you simplicity with all the extra code generated
> > by the compiler's rather generic coding/building mechanism.
>
> Sounds like one who hasn't actually tried avr-gcc.
>
> Avr-gcc optimizes very well. It writes very good nearly optimal code for
> the stack and register model it follows. About the only way one can beat
> avr-gcc is by taking shortcuts in register allocation and calling
> convention. And in doing so one generates delicate code which is easy to
> break.
>
> What Rakesh says is very true if one were talking about Microchip's C
> compiler for the PIC-16 about 6 years ago when I last looked.
>
> --
> David Kelly N4HHE, d...@HiWAAY.net
> ========================================================================
> Whom computers would destroy, they must first drive mad.
>
>

--
Rakesh.
http://gopchandani.wordpress.com



(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

On Mon, Jan 15, 2007 at 11:14:10PM +0500, Rakesh Kumar wrote:
> Yes I may be wrong. I have just started working with AVR-GCC and the
> comments I made was extrapolation of what I knew about compilers from
> a Computer Architecture course at college.
>
> Thanks for correction David.

Thanks for taking it in the spirit it was intended.

Yes, you can turn off avr-gcc's optimizations but simply running it -O
generates very good reliable code that isn't terribly scrambled when it
comes to source code debugging. I don't recall that -O2 was much
different.

If you want optimized-until-your-nose-bleeds try CodeWarrior C for the
HC12 family. Totally reorders and often hopscotches thru large switch
structures.

--
David Kelly N4HHE, d...@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.



(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

So would it be safe to say that I should program in assembler to
learn the AVR and then switch to C or just start with C?
--- In a...@yahoogroups.com, David Kelly wrote:
> On Jan 14, 2007, at 12:38 PM, Brian wrote:
>
> > C programming seems easier. but when compilied would the file
size be
> > the same or smaller than programming using the instruction set
for the
> > controller? Would the C complier add extra stuff that could be
> > shortened by using the instruction set?
>
> In theory you could write exactly the same code in assembler as
the
> compiler generated.
>
> In practice one writes smaller code in assembler than the
compiler
> when the project is small. When projects get larger C starts
winning
> as its easier to reuse sections of code, and to abstract modules
so
> that one can forget about other things and concentrate on the
> immediate item.
>
> An important thing to consider is ease of maintainability of your
> code in the future. Is very hard to write assembly that another
can
> understand. Is almost as hard for one to write assembly today
that
> you can still understand in 2 years.
>
> Its very possible to write C that another can not understand. But
it
> is easier to write C that another can understand than assembly.
>
> > Not knowing how big 1K of memory really is (not 1024) but how
many
> > instructions/lines of code can be used with an 8 bit controller?
This
> > would help in the future on deciding which chip to use.
>
> 14k was enough in avr-gcc for a robust application interfacing an
> electric power meter and cutoff relay to a cellphone. It
supported
> scheduled events such as "report meter reading every month".
> Monitored peak consumption, power outages. Could automatically
report
> these events, or not. Configuration was via ASCII Modbus on
serial
> port. Forgot how many thousand lines of code, probably 3500. No
> longer have access to that project so I can't say for sure.
>
> --
> David Kelly N4HHE, dkelly@...
>
=====================================================================
===
> Whom computers would destroy, they must first drive mad.
>



(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

My personal view FWIW - I like to learn in assembler first because I learn
to "think" like the particular microcontroller I'm using. That way, I know
all the nuances of the device.

C is a great thing but the subtleties of the microcontroller just pass you
by.

Zack

On Wed, 17 Jan 2007, Brian wrote:

> So would it be safe to say that I should program in assembler to
> learn the AVR and then switch to C or just start with C?
> --- In a...@yahoogroups.com, David Kelly wrote:
> >
> >
> > On Jan 14, 2007, at 12:38 PM, Brian wrote:
> >
> > > C programming seems easier. but when compilied would the file
> size be
> > > the same or smaller than programming using the instruction set
> for the
> > > controller? Would the C complier add extra stuff that could be
> > > shortened by using the instruction set?
> >
> > In theory you could write exactly the same code in assembler as
> the
> > compiler generated.
> >
> > In practice one writes smaller code in assembler than the
> compiler
> > when the project is small. When projects get larger C starts
> winning
> > as its easier to reuse sections of code, and to abstract modules
> so
> > that one can forget about other things and concentrate on the
> > immediate item.
> >
> > An important thing to consider is ease of maintainability of your
> > code in the future. Is very hard to write assembly that another
> can
> > understand. Is almost as hard for one to write assembly today
> that
> > you can still understand in 2 years.
> >
> > Its very possible to write C that another can not understand. But
> it
> > is easier to write C that another can understand than assembly.
> >
> > > Not knowing how big 1K of memory really is (not 1024) but how
> many
> > > instructions/lines of code can be used with an 8 bit controller?
> This
> > > would help in the future on deciding which chip to use.
> >
> > 14k was enough in avr-gcc for a robust application interfacing an
> > electric power meter and cutoff relay to a cellphone. It
> supported
> > scheduled events such as "report meter reading every month".
> > Monitored peak consumption, power outages. Could automatically
> report
> > these events, or not. Configuration was via ASCII Modbus on
> serial
> > port. Forgot how many thousand lines of code, probably 3500. No
> > longer have access to that project so I can't say for sure.
> >
> > --
> > David Kelly N4HHE, dkelly@...
> >
> =====================================================================
> ===
> > Whom computers would destroy, they must first drive mad.
>



(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

On Jan 16, 2007, at 10:33 PM, Zack Widup wrote:

> My personal view FWIW - I like to learn in assembler first because
> I learn
> to "think" like the particular microcontroller I'm using. That way,
> I know
> all the nuances of the device.
>
> C is a great thing but the subtleties of the microcontroller just
> pass you
> by.

Yes, and no.

What do you gain by getting down and intimate with the CPU
instruction set?

In partial answer to my own question, it is good that one be familiar
with assembly and capable of completing a project in pure assembly.
Good assembly programmers write better C than those who come from the
Visual-C camp.

What does one gain if a procedure can be made 10% smaller or 10%
faster? Who is to say for sure the C code won't be faster or smaller
than hand assembly? The guys who coded avr-gcc know the subtleties of
the AVR extremely well. You could learn a lot looking at the
generated code.

Only if there was some good reason that a project was restricted to
the very small AVRs would I use assembly. Having said that, should
point out that my usual Makefile generates disassembly listings every
time I build because I look, often, to see that code I wrote got
interpreted the way I expected.

As for subtleties, the AVRs lack of (I believe) add with carry could
drive one nuts. Has subtract with carry, so one must negate constants
and subtract to effect an add. Macro time! Something I have been
thankful avr-gcc handles for me.

--
David Kelly N4HHE, d...@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

Well just a thought while all this discussion is going on, can you suggest
me any material (tutorials/books) on avr-gcc which present
application-oriented approach towards learning avr-gcc.

Like, what if I want to put a temperature sensor with my atmega32? Or What
if I want to communicate with PCs serial port. The material I have come
across so far takes a rather winding approach instead of being to the point.
I know the importance of learning the architecture first but let's just say
due to time constraints I'd like to learn it with application with a
sacrifice of maybe a little depth of content.

Thanks.

Rakesh.

On 1/17/07, David Kelly wrote:
> On Jan 16, 2007, at 10:33 PM, Zack Widup wrote:
>
> > My personal view FWIW - I like to learn in assembler first because
> > I learn
> > to "think" like the particular microcontroller I'm using. That way,
> > I know
> > all the nuances of the device.
> >
> > C is a great thing but the subtleties of the microcontroller just
> > pass you
> > by.
>
> Yes, and no.
>
> What do you gain by getting down and intimate with the CPU
> instruction set?
>
> In partial answer to my own question, it is good that one be familiar
> with assembly and capable of completing a project in pure assembly.
> Good assembly programmers write better C than those who come from the
> Visual-C camp.
>
> What does one gain if a procedure can be made 10% smaller or 10%
> faster? Who is to say for sure the C code won't be faster or smaller
> than hand assembly? The guys who coded avr-gcc know the subtleties of
> the AVR extremely well. You could learn a lot looking at the
> generated code.
>
> Only if there was some good reason that a project was restricted to
> the very small AVRs would I use assembly. Having said that, should
> point out that my usual Makefile generates disassembly listings every
> time I build because I look, often, to see that code I wrote got
> interpreted the way I expected.
>
> As for subtleties, the AVRs lack of (I believe) add with carry could
> drive one nuts. Has subtract with carry, so one must negate constants
> and subtract to effect an add. Macro time! Something I have been
> thankful avr-gcc handles for me.
>
> --
> David Kelly N4HHE, d...@HiWAAY.net
> ========================================================================
> Whom computers would destroy, they must first drive mad.
>
>
>

--
Rakesh.
http://gopchandani.wordpress.com
[Non-text portions of this message have been removed]


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

I don't know if I stand to gain or lose anything by knowing each
microcontroller in detail. It just makes it more fun for me personally.

Yes, I wish they had an add with carry directive. I've usually just
manipulated the carry bits myself to achieve that. Same result, I guess.

BTW (on another topic) everyone on this list is moderated when they first
sign up. When I have time, I try to remove the moderated status when I
become convinced that someone isn't a spammer. That makes it easier on us
moderators - less work in approving messages. David, I changed your
status to "unmoderated" along with a few others today.

Zack

On Tue, 16 Jan 2007, David Kelly wrote:

>
> On Jan 16, 2007, at 10:33 PM, Zack Widup wrote:
>
> > My personal view FWIW - I like to learn in assembler first because
> > I learn
> > to "think" like the particular microcontroller I'm using. That way,
> > I know
> > all the nuances of the device.
> >
> > C is a great thing but the subtleties of the microcontroller just
> > pass you
> > by.
>
> Yes, and no.
>
> What do you gain by getting down and intimate with the CPU
> instruction set?
>
> In partial answer to my own question, it is good that one be familiar
> with assembly and capable of completing a project in pure assembly.
> Good assembly programmers write better C than those who come from the
> Visual-C camp.
>
> What does one gain if a procedure can be made 10% smaller or 10%
> faster? Who is to say for sure the C code won't be faster or smaller
> than hand assembly? The guys who coded avr-gcc know the subtleties of
> the AVR extremely well. You could learn a lot looking at the
> generated code.
>
> Only if there was some good reason that a project was restricted to
> the very small AVRs would I use assembly. Having said that, should
> point out that my usual Makefile generates disassembly listings every
> time I build because I look, often, to see that code I wrote got
> interpreted the way I expected.
>
> As for subtleties, the AVRs lack of (I believe) add with carry could
> drive one nuts. Has subtract with carry, so one must negate constants
> and subtract to effect an add. Macro time! Something I have been
> thankful avr-gcc handles for me.
>
> --
> David Kelly N4HHE, d...@HiWAAY.net
> ========================================================================


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

On Wed, Jan 17, 2007 at 12:07:32PM -0600, Zack Widup wrote:
>
> I don't know if I stand to gain or lose anything by knowing each
> microcontroller in detail. It just makes it more fun for me
> personally.

Its good to have fun but sometimes one has to earn a living.

> Yes, I wish they had an add with carry directive. I've usually just
> manipulated the carry bits myself to achieve that. Same result, I
> guess.

There is an example of where avr-gcc can teach some of the AVR nuances.
Negate one input and subtract with carry. Net effect is an add. See a
lot of sbc #0xff where adc #0x01 would apply. And no, the compiler is
smart enough to use inc when that is appropriate. My examples are rather
simplified.

If in assembly you were using add-without-carry and manually applying
tests for the carry condition, then avr-gcc was writing tighter code.

--
David Kelly N4HHE, d...@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.



(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

On Wed, Jan 17, 2007 at 06:58:47PM +0500, Rakesh Kumar wrote:
> Well just a thought while all this discussion is going on, can you suggest
> me any material (tutorials/books) on avr-gcc which present
> application-oriented approach towards learning avr-gcc.

http://www.avrfreaks.net/ specializes in that sort of thing.

> Like, what if I want to put a temperature sensor with my atmega32? Or
> What if I want to communicate with PCs serial port. The material I
> have come across so far takes a rather winding approach instead of
> being to the point. I know the importance of learning the
> architecture first but let's just say due to time constraints I'd like
> to learn it with application with a sacrifice of maybe a little depth
> of content.

The C compiler takes care of a lot of CPU specific things for you such
as stack setup and placing your interrupt routine addresses in the
dispatch table.

Atmel's Butterfly comes with a reference application which includes
temperature sensor and crude serial routines. There is at least one
version of the code available ported to avr-gcc for you to study. The
Butterfly module is all of $20 from DigiKey and other sources if you do
not already have hardware to play with.

--
David Kelly N4HHE, d...@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.



(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

I have installed WINAVR. Next question is what is the best way to
debounce a switch? If a delay is used, what is the best time to use?
--- In a...@yahoogroups.com, "Brian" wrote:
>
> I just got the STK500 and the butterfly. Any tips or tricks to start
> next? I am still waiting for the two books on the AVR to come in the
> mail to learn more about them. Thanks.
>



(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

On Thu, Jan 18, 2007 at 04:00:01AM -0000, Brian wrote:
> I have installed WINAVR. Next question is what is the best way to
> debounce a switch? If a delay is used, what is the best time to use?

There is no single best way. The worst way is to sample once and accept
it at face value.

All the other ways depend a lot on your coding style and available
resources.

You could poll it in your main loop. When you see a leading edge copy
the contents of a timer. Subsequent passes if the value is still good
compare the timer's current value to the saved value. Consider the input
debounced when sufficient time has passed.

A possibly Good Enough solution would be to poll the input inside a
regular tick counter real-time interrupt. Say you have a routing ticking
off every 10 ms you might accept the switch input if it is in the same
state 3 samples in a row.

You could do the above with hardware assist. Put the switch on an input
capture pin. Set interrupt level for the next expected edge. In interrupt
set a timer to fire after the desired debounce interval. Meanwhile
change the polarity of the input interrupt edge and cancel the timer if
this event occurs before the timer expires. When the other edge finally
occurs repeat the process to debounce the switch change to the other
state.

--
David Kelly N4HHE, d...@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.



(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )

At 09:49 AM 1/18/2007 -0600, David Kelly wrote:
>On Thu, Jan 18, 2007 at 04:00:01AM -0000, Brian wrote:
> > I have installed WINAVR. Next question is what is the best way to
> > debounce a switch? If a delay is used, what is the best time to use?
>
>There is no single best way. The worst way is to sample once and accept
>it at face value.

A slightly contrary view :) Sometimes not debouncing is the best
way. There are a number of systems where the switch bounces don't effect
behaviour significantly (another smaller set that don't bounce) and switch
debouncing introduces extra code and phase issues. The first thing to do
is to determine if you actually need to debounce.

There is no question though, if you are uncertain it is usually better to
debounce.

Robert

http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."


(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )