Forums

Using ISR() Macro in AVR-GCC

Started by Vivek B February 22, 2008
Hi folks,

My code is handling both timer0 interrupt and SPI interrupt. And I
don't want to loose any of the SPI interrupts and hence thought of
making the timer0 ISR to work in NOBLOCK mode. But when i use

ISR(TIMER0_COMP_vect, ISR_NOBLOCK)
{
/* Code */
}

the compiler gives an error: "macro "ISR" passed 2 arguments, but
takes just 1"

where it works fine for

ISR(TIMER0_COMP_vect)
{
/* Code */
}

-----------------------!!!!!!!!----------------------

Right now I am implementing the code as follows

ISR(TIMER0_COMP_vect)
{
sei();
/* Code */
}

But I would like to use the first one. Isn't the first implementation
suppose to work??

Anyone has any guess why it is not working...

Thank you ..

Vivek.
> > But I would like to use the first one. Isn't the first implementation > suppose to work?? > > Anyone has any guess why it is not working... > > Thank you ..
You probably have to update the gcc compiler
FWIW, it works correctly in a recent WinAVR (20071221).

Mike
Vivek B wrote:
> > My code is handling both timer0 interrupt and SPI interrupt. And > I don't want to loose any of the SPI interrupts and hence thought > of making the timer0 ISR to work in NOBLOCK mode. But when i use >
... snip ...
> > Anyone has any guess why it is not working...
Just think about it for a while. An interrupt can occur at ANY time. It transfers control to some preknown code location. What could possibly supply it any parameter values? It would appear your system transfers to a location that identifies the actual interrupt occuring, and then calls your code with that id as a parameter. But that is a feature of the primary ISR service routine, before it fans out to your routine. You have to modify the calling code to supply additional parameters. The supplied code is probably handling such things as disabling further interrupts, reenabling them on service exit, etc. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com
On Feb 22, 12:41=A0pm, CBFalconer <cbfalco...@yahoo.com> wrote:
> Vivek B wrote: > > > My code is handling both timer0 interrupt and SPI interrupt. And > > I don't want to loose any of the SPI interrupts and hence thought > > of making the timer0 ISR to work in NOBLOCK mode. But when i use > > ... snip ... > > > Anyone has any guess why it is not working... > > Just think about it for a while. =A0An interrupt can occur at ANY > time. =A0It transfers control to some preknown code location. =A0What > could possibly supply it any parameter values? > > It would appear your system transfers to a location that identifies > the actual interrupt occuring, and then calls your code with that > id as a parameter. =A0But that is a feature of the primary ISR > service routine, before it fans out to your routine. =A0You have to > modify the calling code to supply additional parameters. =A0The > supplied code is probably handling such things as disabling further > interrupts, reenabling them on service exit, etc.
It's not a parameter in the C sense, but a compiler directive. Without the ISR_NOBLOCK directive the entry code to the INT routine starts e.g. like this: push r1 push r0 in r0, 0x3f ; 63 push r0 eor r1, r1 etc... With the ISR_NOBLOCK directive it looks like this: sei /* re-enables INTS right away */ push r1 push r0 in r0, 0x3f ; 63 push r0 eor r1, r1 etc... Mike
CBFalconer wrote:
> Vivek B wrote: >> My code is handling both timer0 interrupt and SPI interrupt. And >> I don't want to loose any of the SPI interrupts and hence thought >> of making the timer0 ISR to work in NOBLOCK mode. But when i use >> > ... snip ... >> Anyone has any guess why it is not working... > > Just think about it for a while. An interrupt can occur at ANY > time. It transfers control to some preknown code location. What > could possibly supply it any parameter values? > > It would appear your system transfers to a location that identifies > the actual interrupt occuring, and then calls your code with that > id as a parameter. But that is a feature of the primary ISR > service routine, before it fans out to your routine. You have to > modify the calling code to supply additional parameters. The > supplied code is probably handling such things as disabling further > interrupts, reenabling them on service exit, etc. >
The "ISR(TIMER0_COMP_vect, ISR_NOBLOCK)" is not a function definition of itself, and the "TIMER0_COMP_vect" and "ISR_NOBLOCK" are not parameters. These are all macros, designed to declare an appropriate ISR function with the right vector number, and with the right function attributes. It certainly happens that people try to write ISRs with parameters without understanding what is really going on, but that's not the case here. The most likely cause of the problem is that the OP is using an older version of the compiler and/or library (with avr-gcc, the header with the ISR macros is part of the avr-libc library) but taking example code from the current on-line documentation, which obviously refers to the latest version of the tools.
On Feb 22, 4:34 pm, "MisterE" <vo...@sometwher.world> wrote:
> > But I would like to use the first one. Isn't the first implementation > > suppose to work?? > > > Anyone has any guess why it is not working... > > > Thank you .. > > You probably have to update the gcc compiler
I thought so.. Thank you :)
On Feb 23, 1:51 am, Mike Silva <snarflem...@yahoo.com> wrote:
> On Feb 22, 12:41 pm, CBFalconer <cbfalco...@yahoo.com> wrote: > > > > > Vivek B wrote: > > > > My code is handling both timer0 interrupt and SPI interrupt. And > > > I don't want to loose any of the SPI interrupts and hence thought > > > of making the timer0ISRto work in NOBLOCK mode. But when i use > > > ... snip ... > > > > Anyone has any guess why it is not working... > > > Just think about it for a while. An interrupt can occur at ANY > > time. It transfers control to some preknown code location. What > > could possibly supply it any parameter values? > > > It would appear your system transfers to a location that identifies > > the actual interrupt occuring, and then calls your code with that > > id as a parameter. But that is a feature of the primaryISR > > service routine, before it fans out to your routine. You have to > > modify the calling code to supply additional parameters. The > > supplied code is probably handling such things as disabling further > > interrupts, reenabling them on service exit, etc. > > It's not a parameter in the C sense, but a compiler directive. > > Without the ISR_NOBLOCK directive the entry code to the INT routine > starts e.g. like this: > > push r1 > push r0 > in r0, 0x3f ; 63 > push r0 > eor r1, r1 > etc... > > With the ISR_NOBLOCK directive it looks like this: > > sei /* re-enables INTS right away */ > push r1 > push r0 > in r0, 0x3f ; 63 > push r0 > eor r1, r1 > etc... > > Mike
Yes.. I know.. See that the sei mnemonic is used before the stack operations, which makes it more efficient than the second implementation i specified - the reason why I want this to be used... Anyways, updating the complier should fix the problem. Thank you Mike.. :)
On Feb 23, 9:07 pm, David Brown
<david.br...@hesbynett.removethisbit.no> wrote:
> CBFalconer wrote: > > Vivek B wrote: > >> My code is handling both timer0 interrupt and SPI interrupt. And > >> I don't want to loose any of the SPI interrupts and hence thought > >> of making the timer0ISRto work in NOBLOCK mode. But when i use > > > ... snip ... > >> Anyone has any guess why it is not working... > > > Just think about it for a while. An interrupt can occur at ANY > > time. It transfers control to some preknown code location. What > > could possibly supply it any parameter values? > > > It would appear your system transfers to a location that identifies > > the actual interrupt occuring, and then calls your code with that > > id as a parameter. But that is a feature of the primaryISR > > service routine, before it fans out to your routine. You have to > > modify the calling code to supply additional parameters. The > > supplied code is probably handling such things as disabling further > > interrupts, reenabling them on service exit, etc. > > The "ISR(TIMER0_COMP_vect, ISR_NOBLOCK)" is not a function definition of > itself, and the "TIMER0_COMP_vect" and "ISR_NOBLOCK" are not parameters. > These are all macros, designed to declare an appropriateISRfunction > with the right vector number, and with the right function attributes. > > It certainly happens that people try to write ISRs with parameters > without understanding what is really going on, but that's not the case > here. The most likely cause of the problem is that the OP is using an > older version of the compiler and/or library (with avr-gcc, the header > with theISRmacros is part of the avr-libc library) but taking example > code from the current on-line documentation, which obviously refers to > the latest version of the tools.
YES!!! Thats it.. The library is new.. I checked the maro implementation of ISR, it do handles attributes :)... It should be the compiler. Thank you David, for dropping by..