AVR-Chat

Hello

I using a Mega48, coded in ASM. I have debounced switches on PD2 (INT0) and
PD3 (INT1).

In my code, I'm enabling both INT1 and INT0 on a rising edge, and enabling
the global int flag, using something like this:

I have the pins and ports defined in a separate inc file

.cseg
.org 0x00
	rjmp RESET
	rjmp EXT_INT0
	rjmp EXT_INT1
      rjmp ERR_01				// PCINT0 ; PCINT0 Handler
// .... rest of isr vectors all point to same address as above


RESET:
INITIALIZE_AVR:
	ldi temp, high(RAMEND)
	out SPH, temp
	ldi temp, low(RAMEND)
	out SPL, temp

	// set pins for stepper/5804 as outputs
	sbi StepDDR, EnablePin
	sbi StepDDR, DirPin
	sbi StepDDR, StepPin

	// set the err LED pin as output
	sbi ErrDDR, ErrPin

	cbi SwitchDDR, E_SwPin
	cbi SwitchDDR, FootSwPin
	cbi SwitchDDR, SensorPin

	// set default values for pins
	StepDown  // these are macros
	StepLow
	EnableOff
	ErrPinOff

	// set up ext ints 0 & 1
	// EICRA has the bits to set the levels of the ints
	// we want both INT0 & INT1 to trigger on the rising edge
	// for INT0, rising edge, ISC01,ISC00 = 11
	// for INT1, rising edge, ISC11_ISC10 = 11
	ldi temp, 0b00001111
	sts EICRA, temp
	// enable INT0 & INT1 => EIMSK - INT0=bit 0, INT1=bit 1
	ldi temp, 0b00000011
	out EIMSK, temp
	sei
// end INIT


MAIN:		// inf loop
	NOP
	rjmp MAIN

EXT_INT1:
	// control stepper in here - up/ down stroke
	//
	// at end of this routine I set the INT1 flag  - this way,
	// even if the button was accidently pressed twice, it will
	// only execute one stroke at a time, and ignores any more
	// button presses until the ISR is completed
	sbi EIFR, INT1
// end EXT_INT1


EXT_INT0:
	// emergency sw was pressed
	// blink the emrgency LED
// end EXT_INT0


 -- now my question is, how can I get the INT0 switch to IMMEDIATELY
interrupt any code that is running, and go to the EXT_INT0 label and begin
execution the code there? Right now, what's happening is the INT0 waits
until the INT1 routine returns back to MAIN before it jumps to the ISR,
which could be too late....

Randy

At 01:52 PM 20/07/2007, you wrote:
>  how can I get the INT0 switch to IMMEDIATELY
>interrupt any code that is running, and go to the EXT_INT0 label and begin
>execution the code there? Right now, what's happening is the INT0 waits
>until the INT1 routine returns back to MAIN before it jumps to the ISR,
>which could be too late....

If INT1 routine or ANY OTHER interrupts routine is running
then nothing else can stop that routine UNLESS you reenable
interrupts within the INT1 routine which is VERY DANGEROUS
unless you handle it properly.

You can get INT1 (and INT0) to simply set a flag and exit and
then you handle their service in the main loop, this way if another
int happens it can be serviced suspending the current service.

STILL IT CAN GET VERY MESSY unless handled properly.

By the way I hope you have RETIs in your interrupts routines.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19/07/2007 6:10 PM

--- In AVR-Chat@yahoogroups.com, John Samperi <samperi@...> wrote:
>
> 
> If INT1 routine or ANY OTHER interrupts routine is running
> then nothing else can stop that routine UNLESS you reenable
> interrupts within the INT1 routine which is VERY DANGEROUS
> unless you handle it properly.
> 
> You can get INT1 (and INT0) to simply set a flag and exit and
> then you handle their service in the main loop, this way if another
> int happens it can be serviced suspending the current service.
> 
> STILL IT CAN GET VERY MESSY unless handled properly.
> 
> By the way I hope you have RETIs in your interrupts routines.
> 
> Regards
> 
> John Samperi
> 

John
Thanks for responding.

How does the AVR do this internally - is the mcu is executing it's 
own form of "CLI"? Or is it just turning off the Enable flags for 
INT0 and INT1?

In my case, what I'm doing is making a PCB drill, and a debounced 
footswitch is attached to INT1. That kicks off a single drill cycle 
that runs a slide up and down using a stepper. At the end of the INT1 
ISR, I'm hitting the EIFR register to clear the INT1 flag. This 
prevents a second cycle unless the first cycle has ended, in case I 
accidently press the footswitch again in the middle of the cycle. 

The INT0 switch is a KILL / Emergency switch, so it's response MUST 
be immediate - in case I'm about to drill my finger, etc. A pc of 
broken .025" carbide in my finger is not my idea of fun.

I like your idea of jumping right back out of the ISR's, and having a 
master routine handle all of the switches. I'll have to see if that 
will work in my code.

I can see how it could get messy, but in my case, when the KILL 
switch is executed, I want it to jump to the INT0 ISR, and stay in 
there in an endless loop until I reset the CPU. I have an error LED 
that flashes in the INT0 ISR.

Randy

--- In AVR-Chat@yahoogroups.com, "bytheriverkwai" <rll_groups@...> 
wrote:
> How does the AVR do this internally - is the mcu is executing it's 
> own form of "CLI"? Or is it just turning off the Enable flags for 
> INT0 and INT1?

The AVR operates as described in the respective datasheet.  For 
example, for the mega32 it says on page 12:

"When an interrupt occurs, the Global Interrupt Enable I-bit is 
cleared and all interrupts are disabled."

The datasheet goes on to describe how you can re-enable interrupts 
to implement nested interrupts if desired.

The datasheets are chock full of such useful information.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

Randy,

If your switch is a KILL/ESTOP switching function, if memory serves 
correctly, it must be a mechanical type according to most electrical 
codes...and conservative design practice.  We don't need to depend on 
any electronic component, with its indefinite or undefined life 
expectancy, to protect life or limb.

At the very least you might think about putting a NO, held or operated 
closed, contact in series with the contactor that powers the motor.  You 
can add another contact to your controller to indicate a fault and take 
the control logic to some predetermined state so you don't have to 
restart the whole process when your pinkie is out of the way.


REB



bytheriverkwai wrote:

>--- In AVR-Chat@yahoogroups.com, John Samperi <samperi@...> wrote:
>  
>
>>If INT1 routine or ANY OTHER interrupts routine is running
>>then nothing else can stop that routine UNLESS you reenable
>>interrupts within the INT1 routine which is VERY DANGEROUS
>>unless you handle it properly.
>>
>>You can get INT1 (and INT0) to simply set a flag and exit and
>>then you handle their service in the main loop, this way if another
>>int happens it can be serviced suspending the current service.
>>
>>STILL IT CAN GET VERY MESSY unless handled properly.
>>
>>By the way I hope you have RETIs in your interrupts routines.
>>
>>Regards
>>
>>John Samperi
>>
>>    
>>
>
>John
>Thanks for responding.
>
>How does the AVR do this internally - is the mcu is executing it's 
>own form of "CLI"? Or is it just turning off the Enable flags for 
>INT0 and INT1?
>
>In my case, what I'm doing is making a PCB drill, and a debounced 
>footswitch is attached to INT1. That kicks off a single drill cycle 
>that runs a slide up and down using a stepper. At the end of the INT1 
>ISR, I'm hitting the EIFR register to clear the INT1 flag. This 
>prevents a second cycle unless the first cycle has ended, in case I 
>accidently press the footswitch again in the middle of the cycle. 
>
>The INT0 switch is a KILL / Emergency switch, so it's response MUST 
>be immediate - in case I'm about to drill my finger, etc. A pc of 
>broken .025" carbide in my finger is not my idea of fun.
>
>I like your idea of jumping right back out of the ISR's, and having a 
>master routine handle all of the switches. I'll have to see if that 
>will work in my code.
>
>I can see how it could get messy, but in my case, when the KILL 
>switch is executed, I want it to jump to the INT0 ISR, and stay in 
>there in an endless loop until I reset the CPU. I have an error LED 
>that flashes in the INT0 ISR.
>
>Randy
>
>
>
> 
>Yahoo! Groups Links
>
>
>
>
>
>  
>


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