AVR-Chat

Hi all,
I am trying to make my first assembler program that handles interrupts. On
PB[6:0] I have som leds and on PA[7:6] i have two buttons. The leds goes
on with a logic one from the port and the buttons is in tri-state when not
pushed and goes to logic zero when pushed.
I just trying to get a binary counter to show up on the leds when i am
pushing the buttons but nothing happens.
Does anyone know what could be wrong?
Regards, Manne

Here is the code:

.include "tn26def.inc"

; Interrupt service vectors

.org $0000
        rjmp Reset
.org IOPINSaddr
        rjmp IntPins

; define registers
.def TIME=r16
.def TEMP=r17

; define constants
.equ PORTB_IO=$7f       ; pb[6:0] = output
.equ PORTA_IO=$00       ; pa[7:0] = input

Reset:
        ldi     TEMP, RAMEND    ; set stack pointer to RAMEND
        out     SP, TEMP        ; (SP is one byte on attiny26)

        ldi TEMP, PORTB_IO
        out DDRB, TEMP
        ldi TEMP, $00           ; all lights off
        out PORTB, TEMP

        ldi TEMP, PORTA_IO
        out DDRA, TEMP
        ldi TEMP, (1<<PA3) + (1<<PA6) + (1<<PA7)                ; enable
pullup resistors
        out PORTA, TEMP


        ; set up interrupts

        ldi TEMP, (1<<PCIE1)
        out GIMSK, TEMP ; enable individual interrupt PCIE1 ( PB[7:4],
PA[7:6], PA3 )
        ldi TIME, $00   ; start from 0

        sei

loop:
        rjmp loop


IntPins:
        inc TIME
        out PORTB, TIME
        reti

Manne -

There is a big problem that everyone runs into when trying
to sense switches with an interrupt. It is called "switch
bounce". It happens fairly slowly compared to the speed of
the micro. You get MANY interrupts every time the switch
opens or closes. 

There are several ways to deal with this. One is to "poll"
(that is, read) the port pin regularly (maybe once every
1ms or so). Make a little "debounce" counter in software
and a bit to remember the LAST state read. Every time you
make a poll, compare the current state to the last state.
If it is the same, count 1. If not the same, put the new
state into the last-state bit.  When the debounce counter
reaches some convenient value (say 4 or 8), then the switch
state is "stable" and you then do what ever else needs to
be done (like increment your LED counter.

Jim


On Sat, 17 Feb 2007 00:37:04 +0100 (CET)
 "Manne Tallmarken" <mannet@kth.se> wrote:
> Hi all,
> I am trying to make my first assembler program that
> handles interrupts. On
> PB[6:0] I have som leds and on PA[7:6] i have two
> buttons. The leds goes
> on with a logic one from the port and the buttons is in
> tri-state when not
> pushed and goes to logic zero when pushed.
> I just trying to get a binary counter to show up on the
> leds when i am
> pushing the buttons but nothing happens.
> Does anyone know what could be wrong?
> Regards, Manne
> 
> Here is the code:
> 
> .include "tn26def.inc"
> 
> ; Interrupt service vectors
> 
> .org $0000
>         rjmp Reset
> .org IOPINSaddr
>         rjmp IntPins
> 
> ; define registers
> .def TIME=r16
> .def TEMP=r17
> 
> ; define constants
> .equ PORTB_IO=$7f       ; pb[6:0] = output
> .equ PORTA_IO=$00       ; pa[7:0] = input
> 
> Reset:
>         ldi     TEMP, RAMEND    ; set stack pointer to
> RAMEND
>         out     SP, TEMP        ; (SP is one byte on
> attiny26)
> 
>         ldi TEMP, PORTB_IO
>         out DDRB, TEMP
>         ldi TEMP, $00           ; all lights off
>         out PORTB, TEMP
> 
>         ldi TEMP, PORTA_IO
>         out DDRA, TEMP
>         ldi TEMP, (1<<PA3) + (1<<PA6) + (1<<PA7)
>                ; enable
> pullup resistors
>         out PORTA, TEMP
> 
> 
>         ; set up interrupts
> 
>         ldi TEMP, (1<<PCIE1)
>         out GIMSK, TEMP ; enable individual interrupt
> PCIE1 ( PB[7:4],
> PA[7:6], PA3 )
>         ldi TIME, $00   ; start from 0
> 
>         sei
> 
> loop:
>         rjmp loop
> 
> 
> IntPins:
>         inc TIME
>         out PORTB, TIME
>         reti
> 
> 

---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

That, and I'd strongly advise a fleshed out interrupt vector table.
They can all be RETIs, or they can be a short bit of code that turns off
that interrupt (what I use for all unimplemented ISRs)  or a "halt and catch
fire", but I would never do what you did there.

Imagine the total wierdness if another int is accidentally enabled, and the
ISR fires, jumping somewhere into the middle of your code...  ICK.


[Non-text portions of this message have been removed]

A couple of years ago I ran into this with an 8051, and my solution
was to simply wait for 20ms. 

The initial button press would cause the interrupt routine to
activate. The micro would then wait for 20ms (doing other stuff in the
meantime of course!), and re-check the interrupt at the end. If the
interrupt was in the same state, then it was a legitimate button press
(and not induced noise/etc), and therefore the program should act
accordingly. Remember as well that when the button is released the
noise will be present as well, something that bit me on the posterior
before I took it into account. (Ouch! That took a little while to
find...."why the !@#$%^&@$^% isn't this $!%^%$@^ working?!?!?".)

You may also wish to consider some IC solutions out there, I think
(from a hazy memory) that Maxim/Dallas have a keypad decoder chip that
debounces and decodes the keypress for you, making life a heap easier.

Good luck.

Adam.

--- In AVR-Chat@yahoogroups.com, "Jim Wagner" <jim_d_wagner@...> wrote:

>
> Manne -
> 
> There is a big problem that everyone runs into when trying
> to sense switches with an interrupt. It is called "switch
> bounce". It happens fairly slowly compared to the speed of
> the micro. You get MANY interrupts every time the switch
> opens or closes. 
> 
> There are several ways to deal with this. One is to "poll"
> (that is, read) the port pin regularly (maybe once every
> 1ms or so). Make a little "debounce" counter in software
> and a bit to remember the LAST state read. Every time you
> make a poll, compare the current state to the last state.
> If it is the same, count 1. If not the same, put the new
> state into the last-state bit.  When the debounce counter
> reaches some convenient value (say 4 or 8), then the switch
> state is "stable" and you then do what ever else needs to
> be done (like increment your LED counter.
> 
> Jim
> 
> 
> On Sat, 17 Feb 2007 00:37:04 +0100 (CET)
>  "Manne Tallmarken" <mannet@...> wrote:
> > Hi all,
> > I am trying to make my first assembler program that
> > handles interrupts. On
> > PB[6:0] I have som leds and on PA[7:6] i have two
> > buttons. The leds goes
> > on with a logic one from the port and the buttons is in
> > tri-state when not
> > pushed and goes to logic zero when pushed.
> > I just trying to get a binary counter to show up on the
> > leds when i am
> > pushing the buttons but nothing happens.
> > Does anyone know what could be wrong?
> > Regards, Manne
> > 
> > Here is the code:
> > 
> > .include "tn26def.inc"
> > 
> > ; Interrupt service vectors
> > 
> > .org $0000
> >         rjmp Reset
> > .org IOPINSaddr
> >         rjmp IntPins
> > 
> > ; define registers
> > .def TIME=r16
> > .def TEMP=r17
> > 
> > ; define constants
> > .equ PORTB_IO=$7f       ; pb[6:0] = output
> > .equ PORTA_IO=$00       ; pa[7:0] = input
> > 
> > Reset:
> >         ldi     TEMP, RAMEND    ; set stack pointer to
> > RAMEND
> >         out     SP, TEMP        ; (SP is one byte on
> > attiny26)
> > 
> >         ldi TEMP, PORTB_IO
> >         out DDRB, TEMP
> >         ldi TEMP, $00           ; all lights off
> >         out PORTB, TEMP
> > 
> >         ldi TEMP, PORTA_IO
> >         out DDRA, TEMP
> >         ldi TEMP, (1<<PA3) + (1<<PA6) + (1<<PA7)
> >                ; enable
> > pullup resistors
> >         out PORTA, TEMP
> > 
> > 
> >         ; set up interrupts
> > 
> >         ldi TEMP, (1<<PCIE1)
> >         out GIMSK, TEMP ; enable individual interrupt
> > PCIE1 ( PB[7:4],
> > PA[7:6], PA3 )
> >         ldi TIME, $00   ; start from 0
> > 
> >         sei
> > 
> > loop:
> >         rjmp loop
> > 
> > 
> > IntPins:
> >         inc TIME
> >         out PORTB, TIME
> >         reti
> > 
> > 
> 
> ---------------------------------------------------------------
> The Think Different Store
> http://www.thinkdifferentstore.com/
> For All Your Mac Gear
> ---------------------------------------------------------------
>

Motorola, now ON Semiconductor, also has/had the MC14490 for switch 
debouncing.  However, at 5 bucks a piece the last time I bought any for 
a control board I haven't taken the trouble to re design, it's much more 
cost effective to write a few lines of code to do the same job in new 
designs.


REB


Adam wrote:

>A couple of years ago I ran into this with an 8051, and my solution
>was to simply wait for 20ms. 
>
>The initial button press would cause the interrupt routine to
>activate. The micro would then wait for 20ms (doing other stuff in the
>meantime of course!), and re-check the interrupt at the end. If the
>interrupt was in the same state, then it was a legitimate button press
>(and not induced noise/etc), and therefore the program should act
>accordingly. Remember as well that when the button is released the
>noise will be present as well, something that bit me on the posterior
>before I took it into account. (Ouch! That took a little while to
>find...."why the !@#$%^&@$^% isn't this $!%^%$@^ working?!?!?".)
>
>You may also wish to consider some IC solutions out there, I think
>(from a hazy memory) that Maxim/Dallas have a keypad decoder chip that
>debounces and decodes the keypress for you, making life a heap easier.
>
>Good luck.
>
>Adam.
>
>--- In AVR-Chat@yahoogroups.com, "Jim Wagner" <jim_d_wagner@...> wrote:
>  
>
>>Manne -
>>
>>There is a big problem that everyone runs into when trying
>>to sense switches with an interrupt. It is called "switch
>>bounce". It happens fairly slowly compared to the speed of
>>the micro. You get MANY interrupts every time the switch
>>opens or closes. 
>>
>>There are several ways to deal with this. One is to "poll"
>>(that is, read) the port pin regularly (maybe once every
>>1ms or so). Make a little "debounce" counter in software
>>and a bit to remember the LAST state read. Every time you
>>make a poll, compare the current state to the last state.
>>If it is the same, count 1. If not the same, put the new
>>state into the last-state bit.  When the debounce counter
>>reaches some convenient value (say 4 or 8), then the switch
>>state is "stable" and you then do what ever else needs to
>>be done (like increment your LED counter.
>>
>>Jim
>>
>>
>>On Sat, 17 Feb 2007 00:37:04 +0100 (CET)
>> "Manne Tallmarken" <mannet@...> wrote:
>>    
>>
>>>Hi all,
>>>I am trying to make my first assembler program that
>>>handles interrupts. On
>>>PB[6:0] I have som leds and on PA[7:6] i have two
>>>buttons. The leds goes
>>>on with a logic one from the port and the buttons is in
>>>tri-state when not
>>>pushed and goes to logic zero when pushed.
>>>I just trying to get a binary counter to show up on the
>>>leds when i am
>>>pushing the buttons but nothing happens.
>>>Does anyone know what could be wrong?
>>>Regards, Manne
>>>
>>>Here is the code:
>>>
>>>.include "tn26def.inc"
>>>


[Non-text portions of this message have been removed]

I am amazed that this type of IC exists.
I was writing key debounce software in 1984.

www.ckp-railways/pcbcad21.htm


"Roy E. Burrage" <RBurrage@bellsouth.net> wrote:                                  Motorola, now ON Semiconductor, also has/had the MC14490 for switch 
 debouncing.  However, at 5 bucks a piece the last time I bought any for 
 a control board I haven't taken the trouble to re design, it's much more 
 cost effective to write a few lines of code to do the same job in new 
 designs.
 
 REB
 
 Adam wrote:
 
 >A couple of years ago I ran into this with an 8051, and my solution
 >was to simply wait for 20ms. 
 >
 >The initial button press would cause the interrupt routine to
 >activate. The micro would then wait for 20ms (doing other stuff in the
 >meantime of course!), and re-check the interrupt at the end. If the
 >interrupt was in the same state, then it was a legitimate button press
 >(and not induced noise/etc), and therefore the program should act
 >accordingly. Remember as well that when the button is released the
 >noise will be present as well, something that bit me on the posterior
 >before I took it into account. (Ouch! That took a little while to
 >find...."why the !@#$%^&@$^% isn't this $!%^%$@^ working?!?!?".)
 >
 >You may also wish to consider some IC solutions out there, I think
 >(from a hazy memory) that Maxim/Dallas have a keypad decoder chip that
 >debounces and decodes the keypress for you, making life a heap easier.
 >
 >Good luck.
 >
 >Adam.
 >
 >--- In AVR-Chat@yahoogroups.com, "Jim Wagner" <jim_d_wagner@...> wrote:
 >  
 >
 >>Manne -
 >>
 >>There is a big problem that everyone runs into when trying
 >>to sense switches with an interrupt. It is called "switch
 >>bounce". It happens fairly slowly compared to the speed of
 >>the micro. You get MANY interrupts every time the switch
 >>opens or closes. 
 >>
 >>There are several ways to deal with this. One is to "poll"
 >>(that is, read) the port pin regularly (maybe once every
 >>1ms or so). Make a little "debounce" counter in software
 >>and a bit to remember the LAST state read. Every time you
 >>make a poll, compare the current state to the last state.
 >>If it is the same, count 1. If not the same, put the new
 >>state into the last-state bit.  When the debounce counter
 >>reaches some convenient value (say 4 or 8), then the switch
 >>state is "stable" and you then do what ever else needs to
 >>be done (like increment your LED counter.
 >>
 >>Jim
 >>
 >>
 >>On Sat, 17 Feb 2007 00:37:04 +0100 (CET)
 >> "Manne Tallmarken" <mannet@...> wrote:
 >>    
 >>
 >>>Hi all,
 >>>I am trying to make my first assembler program that
 >>>handles interrupts. On
 >>>PB[6:0] I have som leds and on PA[7:6] i have two
 >>>buttons. The leds goes
 >>>on with a logic one from the port and the buttons is in
 >>>tri-state when not
 >>>pushed and goes to logic zero when pushed.
 >>>I just trying to get a binary counter to show up on the
 >>>leds when i am
 >>>pushing the buttons but nothing happens.
 >>>Does anyone know what could be wrong?
 >>>Regards, Manne
 >>>
 >>>Here is the code:
 >>>
 >>>.include "tn26def.inc"
 >>>
 
 [Non-text portions of this message have been removed]
 
 
     
                       

 		
---------------------------------
 What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship.

[Non-text portions of this message have been removed]

On 2/19/07, np np <harrabylad@yahoo.co.uk> wrote:
>
> I am amazed that this type of IC exists.
> I was writing key debounce software in 1984.


Seems there's no shortage of expensive solutions to inexpensive problems. :)


[Non-text portions of this message have been removed]

Some designs were implemented way before that.  This one is from 1976, 
when the MC14490 was a buck and a half and there were no 
microcontrollers to speak of...at least not economically available.  
When 1 customer orders 25 boards every 3rd year or so, and has about 5 
repairs a year, it isn't worth even reworking the artwork for the board 
to save 4 bucks.  When the chips become obsolete we may have to do 
something different.  In business, we have to make these kinds of 
decisions about old designs...I believe they call them "mature" designs 
these days.

New designs is another story.  An 8 pin Tiny controller for less than a 
buck has about done away with many of the 555 timer applications.


REB


np np wrote:

>I am amazed that this type of IC exists.
>I was writing key debounce software in 1984.
>
>www.ckp-railways/pcbcad21.htm
>
>
>"Roy E. Burrage" <RBurrage@bellsouth.net> wrote:                                  Motorola, now ON Semiconductor, also has/had the MC14490 for switch 
> debouncing.  However, at 5 bucks a piece the last time I bought any for 
> a control board I haven't taken the trouble to re design, it's much more 
> cost effective to write a few lines of code to do the same job in new 
> designs.
> 
> REB
> 
> Adam wrote:
> 
> >A couple of years ago I ran into this with an 8051, and my solution
> >was to simply wait for 20ms. 
> >
> >The initial button press would cause the interrupt routine to
> >activate. The micro would then wait for 20ms (doing other stuff in the
> >meantime of course!), and re-check the interrupt at the end. If the
> >interrupt was in the same state, then it was a legitimate button press
> >(and not induced noise/etc), and therefore the program should act
> >accordingly. Remember as well that when the button is released the
> >noise will be present as well, something that bit me on the posterior
> >before I took it into account. (Ouch! That took a little while to
> >find...."why the !@#$%^&@$^% isn't this $!%^%$@^ working?!?!?".)
> >
> >You may also wish to consider some IC solutions out there, I think
> >(from a hazy memory) that Maxim/Dallas have a keypad decoder chip that
> >debounces and decodes the keypress for you, making life a heap easier.
> >
> >Good luck.
> >
> >Adam.
>  
>


[Non-text portions of this message have been removed]

>
>
> New designs is another story.  An 8 pin Tiny controller for less than a
> buck has about done away with many of the 555 timer applications.


Yup.

I've seen "courtesy tone" circuits for bare-bones repeater controllers, with
a 556, but I've implemented a pretty much full-featured repeater controller
on a tiny-15. No crystal, just the T15 and a few discretes.


[Non-text portions of this message have been removed]

At last, i have found the problem! It was actually very simple to fix, the
problem was that the adc was enabled by default on the same pins so the
code:
ldi TEMP, (1<<ACD)
out ACSR, TEMP
did the trick.
I wonder why this solves the problem, shouldn't the adc be disabled by
default?
Anyway, this is explained at page 64 in the pdf for attiny26.
Thanks to everyone.

regards, Manne

> A couple of years ago I ran into this with an 8051, and my solution
> was to simply wait for 20ms.
>
> The initial button press would cause the interrupt routine to
> activate. The micro would then wait for 20ms (doing other stuff in the
> meantime of course!), and re-check the interrupt at the end. If the
> interrupt was in the same state, then it was a legitimate button press
> (and not induced noise/etc), and therefore the program should act
> accordingly. Remember as well that when the button is released the
> noise will be present as well, something that bit me on the posterior
> before I took it into account. (Ouch! That took a little while to
> find...."why the !@#$%^&@$^% isn't this $!%^%$@^ working?!?!?".)
>
> You may also wish to consider some IC solutions out there, I think
> (from a hazy memory) that Maxim/Dallas have a keypad decoder chip that
> debounces and decodes the keypress for you, making life a heap easier.
>
> Good luck.
>
> Adam.
>
> --- In AVR-Chat@yahoogroups.com, "Jim Wagner" <jim_d_wagner@...> wrote:
>>
>> Manne -
>>
>> There is a big problem that everyone runs into when trying
>> to sense switches with an interrupt. It is called "switch
>> bounce". It happens fairly slowly compared to the speed of
>> the micro. You get MANY interrupts every time the switch
>> opens or closes.
>>
>> There are several ways to deal with this. One is to "poll"
>> (that is, read) the port pin regularly (maybe once every
>> 1ms or so). Make a little "debounce" counter in software
>> and a bit to remember the LAST state read. Every time you
>> make a poll, compare the current state to the last state.
>> If it is the same, count 1. If not the same, put the new
>> state into the last-state bit.  When the debounce counter
>> reaches some convenient value (say 4 or 8), then the switch
>> state is "stable" and you then do what ever else needs to
>> be done (like increment your LED counter.
>>
>> Jim
>>
>>
>> On Sat, 17 Feb 2007 00:37:04 +0100 (CET)
>>  "Manne Tallmarken" <mannet@...> wrote:
>> > Hi all,
>> > I am trying to make my first assembler program that
>> > handles interrupts. On
>> > PB[6:0] I have som leds and on PA[7:6] i have two
>> > buttons. The leds goes
>> > on with a logic one from the port and the buttons is in
>> > tri-state when not
>> > pushed and goes to logic zero when pushed.
>> > I just trying to get a binary counter to show up on the
>> > leds when i am
>> > pushing the buttons but nothing happens.
>> > Does anyone know what could be wrong?
>> > Regards, Manne
>> >
>> > Here is the code:
>> >
>> > .include "tn26def.inc"
>> >
>> > ; Interrupt service vectors
>> >
>> > .org $0000
>> >         rjmp Reset
>> > .org IOPINSaddr
>> >         rjmp IntPins
>> >
>> > ; define registers
>> > .def TIME=r16
>> > .def TEMP=r17
>> >
>> > ; define constants
>> > .equ PORTB_IO=$7f       ; pb[6:0] = output
>> > .equ PORTA_IO=$00       ; pa[7:0] = input
>> >
>> > Reset:
>> >         ldi     TEMP, RAMEND    ; set stack pointer to
>> > RAMEND
>> >         out     SP, TEMP        ; (SP is one byte on
>> > attiny26)
>> >
>> >         ldi TEMP, PORTB_IO
>> >         out DDRB, TEMP
>> >         ldi TEMP, $00           ; all lights off
>> >         out PORTB, TEMP
>> >
>> >         ldi TEMP, PORTA_IO
>> >         out DDRA, TEMP
>> >         ldi TEMP, (1<<PA3) + (1<<PA6) + (1<<PA7)
>> >                ; enable
>> > pullup resistors
>> >         out PORTA, TEMP
>> >
>> >
>> >         ; set up interrupts
>> >
>> >         ldi TEMP, (1<<PCIE1)
>> >         out GIMSK, TEMP ; enable individual interrupt
>> > PCIE1 ( PB[7:4],
>> > PA[7:6], PA3 )
>> >         ldi TIME, $00   ; start from 0
>> >
>> >         sei
>> >
>> > loop:
>> >         rjmp loop
>> >
>> >
>> > IntPins:
>> >         inc TIME
>> >         out PORTB, TIME
>> >         reti
>> >
>> >
>>
>> ---------------------------------------------------------------
>> The Think Different Store
>> http://www.thinkdifferentstore.com/
>> For All Your Mac Gear
>> ---------------------------------------------------------------
>>
>
>
>