pin-change interrupts on ATtiny for beginners

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I had a fair bit of trouble getting a hardware interrupt on a pin change for an ATtiny45 working, so I thought I'd post the code I used in hopes someone else might find it useful. I think this is about the simplest possible example of using interrupts. The specific hardware implementation has a pull-up resistor and a switch that drops that line to ground, going through a hardware debounce circuit (because I don't believe in software debouncing) attached to portb bit 1, and two led's connected to portb bits 3 and 4; the one attached to bit 3 (pin 2) is a heartbeat while the other turns on every time the switch is closed.
It's not sophisticated, but maybe it'll save some other new-to-AVR person an hour or so of digging through examples written for other AVR families.

#include 
#include 
#include 
#include 

ISR(PCINT0_vect)	     // interrupt service routine
{			     // called when PCINT0 changes state
   PORTB = (PORTB ^ 0x16);   // toggle red led, portb bit 5, pin 3
   return;
}

void SystemInit(void)
{
	PCMSK |= (1<<PCINT1);	// pin change mask: listen to portb bit 2
	GIMSK |= (1<<PCIE);	// enable PCINT interrupt 
	sei();			// enable all interrupts
}

int main(void)
{
   	DDRB = 0b00011001;  	// portb bits 0,3,4 output; 1,2 in
	SystemInit();

   while(1)
   {
   		PORTB = (PORTB ^ 0x08);  //toggle green led, portb bit 4, pin 2
		_delay_ms(200);
	}
} 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
because I don't believe in software debouncing
Then you probably don't fully understand all the issues then.

PORTB = (PORTB ^ 0x08); //toggle green led, portb
Will this line execute atomically? Does the compiler emit a pin toggle if the hardware supports it or a read/modify/write of PORTB whilst the isr is also playing around with PORTB?

PORTB = (PORTB ^ 0x16; this line flips bits 1,2 and 4 which doesn't quite line up with the comment.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
going through a hardware debounce circuit

Quote:
it'll save some other new-to-AVR person an hour or so of digging through examples

If they are new to AVR, they are probably new to electronics. It would have been prudent to add a reference to "hardware debounce circuit", lest the new-to-AVR person spend another 20 or 30 hours pulling their hair out to overcome the debouncing.

What is philosophically wrong with software debounce?

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
What is philosophically wrong with software debounce?

Judging by the comments in the code, the OP has probably been drinking too much Duckhams.

This could have been an excellent example of a simple Tiny45 program (if he had described the hardware accurately and it matched the comments)

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm a hardware guy. Software debounce takes up code space and I don't trust it because it's hard for me to accurately predict what it will do, while I know how my hardware works. Pretty much I do this:
http://www.labbookpages.co.uk/el...
Using mostly 0603 components and a schmitt trigger in a SOT323 package it takes up less than a 6mm x 6mm space on the board; usually I can fit the whole works in between the pins of a DIP on the bottom side of the board. Then I don't have to worry about it.