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..

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 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 :)

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, 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

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

FWIW, it works correctly in a recent WinAVR (20071221).

Mike

>
> 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

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.