Question about new ISR() macro

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

I was reading in NEWS-1-libc.txt that SIGNAL()
is being replaced by ISR() and I gather that the names
you use for interrupt routines should change to a new form.

Quote:
- A new ISR() macro has been added, and is now the preferred
way to introduce an interrupt service routine. It is
equivalent to the old SIGNAL() macro, which might become
deprecated in a future version.

So what would I need to rename this interrupt routine to
to make it adhere to the new and better form?

It is a timer1, output compare routine for atmega168

SIGNAL(SIG_OUTPUT_COMPARE1A) //this code runs 10,000/sec
{

tickcount++;
if (tickcount == 1000)//this hits every 10th/second
  {
    tickcount = 0;
    PORTD = ~PORTD; //this code runs 10/second for a flash rate of 5/second
  }
} 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gwen! The name change stems from a lengthy discussion on the pros and cons of using the word SIGNAL. (Many noobs seems to use INTERRUPT rather than SIGNAL, when the latter probably is what they want, and this was blamed on the choice of the words INTERRUPT and SIGNAL.) The end (?) result of this discussion is that the SIGNAL macro will get a identical twin called ISR (and eventually SIGNAL will be killed but not now) so You should be fine with

ISR(SIG_OUTPUT_COMPARE1A) //this code runs 10,000/sec

You do not need to change this in existing code just yet as

Quote:
the [...] SIGNAL() macro, [...] might become deprecated in a future version.

Key words in this quote are might and future.

When writing new code ISR would be the preferred selection as soon as we Mere Mortals install the new avr-libc (most of us will do this when we get our hands on the new WinAVR that is "in the pipe" will be released, I reckon).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Hi Johan :)

That compiles OK...but, the renamed timer code

ISR(SIG_OUTPUT_COMPARE1A) //this code runs 10,000/sec

Never runs! at least the ISR code never hits in the simulator
(I set the timer to hit 1,000,000/sec so I could simulate it faster)
renaming it back to signal results in the code being hit
every time the interrupt hits. ???

I installed the newest libc so I'm running the latest library code.

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

This is odd....very odd

If I set

OCR1AH = 0x00;

and use the ISR name the interrupt fails to work

However if I use the SIGNAL name the interrupt DOES work.

But get this...it is OCR1AH being set to 0 that makes the difference
if I set OCR1AH to 0x01 then BOTH forms work fine
ISR() and SIGNAL() both work if OCR1AH is not zero
but only SIGNAL works if it is zero ??????????????

here is my test code re-written for fast simulation in AVRstudio

//timer1-13.c for atmega168
//LEDs on PORTD connected to Gnd

#include 
#include 
#include 
#include 

volatile unsigned int tickcount;
 
int main( void)
{
sei(); //enable interrupts
DDRD = 0xFF; //PORTD set as output
PORTD = 0xFF;//turn off LEDs
TCNT1 = 0;
OCR1AH = 0x00; //output compare High and Low bytes
OCR1AL = 0x01; //0x0001 gives very fast timer hits for testing in simulator
TCCR1A = 0x00; //timer counter control register
//TCCR1B clear on compare-prescaler set to 0
TCCR1B = (0 << WGM13)|(1 << WGM12)|(0 << CS12)|(0 << CS11)|(1 << CS10);
TIMSK1 |= ( 1 << OCIE1A); //Timer1 Output Compare Enable
TIFR1  = (1 << OCF1A); //Timer1 Output compare A match flag
while(1);
}

//toggles PORTD as test
ISR(SIG_OUTPUT_COMPARE1A) 
{
tickcount++;
if (tickcount == 5)//this hits every 5th time the interrupt hits
  {
    tickcount = 0;
    PORTD = ~PORTD; //toggle the LEDs
  }
} 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think this may be some kind of strange
bug with the simulator...sometimes the
thing works..sometimes not...guess I will
have to actually put the code into a 168
and see what actually happens.

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

Ok.. Only this form works when loaded into a real mega168

SIGNAL(SIG_OUTPUT_COMPARE1A) //this code runs 10,000/sec

this does not

ISR(SIG_OUTPUT_COMPARE1A) //this code runs 10,000/sec

Are you sure that's the correct use of the ISR form?
Guess I better stick with SIGNAL for now.

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

Gwen, can you find the #define for the new ISR macro? I would assume it would be in signal.h or similar - check there to see what the difference between it and the SIGNAL macro is. Also, check the resulting HEX to see where the compare ISR jump is leading to. I'd do it myself, but i'm waiting for the next WinAVR instead of doing it manually...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Hi abcminiuser :)

I can't find the macro def of isr() in the new signal.h..
No wonder my code was acting goofy in the simulator!
I suppose whenever the interrupt was hitting it was jumping
in at the default spot where the call to the handler routine
was supposed to be ...

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

Nice that you're trying to stay tuned, but: did you remember that the
NEWS file you're quoting was straight from CVS? There's no released
version yet that deploys the new scheme. As this constitutes an API
change, this will become avr-libc 1.4.0. We're close to a release for
this version, we're only trying to catch up with all patches that have
been submitted in the past, to see whether they could still be
integrated before that new release.

Basically, we abandoned the word "signal" completely, as most people
find it much more natural to speak about interrupts, interrupt
vectors, and interrupt service routines.

So in the new scheme, it would look like:

#include 
#include 
#include 

ISR(TIMER1_COMPA_vect)
{
  tickcount++;
  if (tickcount == 5)
  {
    tickcount = 0;
    PORTD = ~PORTD;
  }
}

Note that there's no anymore, everything related to
interrupts will be in . You might also note that the
new vector names are 1) close to the datasheet and XML file's name, as
well as 2) similar to IAR's names (in many cases, where IAR sticks to
the XML names).

Of course, as Johan already mentioned, there'll be some amount of
backwards compatibility. will remain for a while, but
just tell you (by #warning) that it is obsolete. The old vector names
will be kept for compatibility for quite some time as well, but we
encourage anyone for new projects to start the new names.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

So there will still be two macros, one named ISR() and one named INTERRUPT()? Sounds similarly confusing to SIGNAL() and INTERRUPT(). :)

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

jimbotko wrote:
So there will still be two macros, one named ISR() and one named INTERRUPT()? Sounds similarly confusing to SIGNAL() and INTERRUPT(). :)

Well, the long term intention, as has been told earlier in this thread, is that SIGNAL will someday be replaced by ISR.

If this replacement would take place when the new avr-libc is released, and with no overlap, this would create big problems for the existing code mass.

Instead the ISR() macro is introduced now, and SIGNAL() will be phased out over time. This starts with the SIGNAL() macro being officially deprecated (ie. marked as "not more to be used, and going out soon") and then being removed from avr-libc.

This gives ample time to replace SIGNAL() with ISR() in the existing code mass.

(A similar process was used when direct register access was introduced (ie. things like PORTx = expression), making the CBI() and SBI() macros superfluous, and thus they where deprecated for several years and finally was removed from avr-libc a year ago or so.)

Also, "confusing" ISR() and SIGAL() is not quite similar to confusing SIGNAL() and INTERRUPT(). ISR() and SIGNAL() expands to exactly the same thing - we are talking about a pure name change primarily for pedagogical reasons. In contrast, there is a real difference in the semantics of SIGNAL() and INTERRUPT().

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

INTERRUPT() is gone.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

JohanEkdahl wrote:
jimbotko wrote:
So there will still be two macros, one named ISR() and one named INTERRUPT()? Sounds similarly confusing to SIGNAL() and INTERRUPT(). :)

Well, the long term intention, as has been told earlier in this thread, is that SIGNAL will someday be replaced by ISR.

If this replacement would take place when the new avr-libc is released, and with no overlap, this would create big problems for the existing code mass.

Instead the ISR() macro is introduced now, and SIGNAL() will be phased out over time. This starts with the SIGNAL() macro being officially deprecated (ie. marked as "not more to be used, and going out soon") and then being removed from avr-libc.

This gives ample time to replace SIGNAL() with ISR() in the existing code mass.

(A similar process was used when direct register access was introduced (ie. things like PORTx = expression), making the CBI() and SBI() macros superfluous, and thus they where deprecated for several years and finally was removed from avr-libc a year ago or so.)

Also, "confusing" ISR() and SIGAL() is not quite similar to confusing SIGNAL() and INTERRUPT(). ISR() and SIGNAL() expands to exactly the same thing - we are talking about a pure name change primarily for pedagogical reasons. In contrast, there is a real difference in the semantics of SIGNAL() and INTERRUPT().

I think you missed my point entirely. The issue as far as I can tell is that SIGNAL() and INTERRUPT() were unclear in their differences. So now ISR() is being introduced to eventually replace SIGNAL() completely. Okay, that's fine. So eventually we will be left with ISR() and INTERRUPT(). How is the difference between ISR() and INTERRUP() any less confusing than it was between SIGNAL() and INTERRUPT()? ISR() clearly stands for Interrupt Service Routine, which sounds pretty similar to INTERRUPT().

How about this: ISR() and ISR_INTERRUPTABLE() (or ISR_NONINTERRUPTABLE, or whatever, you get my point)

dl8dtl wrote:
INTERRUPT() is gone.

Oh, well in that case nevermind. :) So what is the macro to use for an interruptable interrupt? (or is it suggested to just manually turn interrupts on now?)

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

JohanEkdahl wrote:

When writing new code ISR would be the preferred selection as soon as we Mere Mortals install the new avr-libc (most of us will do this when we get our hands on the new WinAVR that is "in the pipe" will be released, I reckon).

(Hello! This is Eric Weddington. This may seem strange, but I'm visiting Jörg Wunsch and I'm writing this from his keyboard (which is difficult for me btw, because of the layout))

Ok,ok,ok! Yes, a WinAVR release is one of my priorities. Hopefully after I get back to the States I'll have a chance to get it done.

Eric Weddington (via Jörg Wunsch's keyboard)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

So what is the macro to use for an interruptable interrupt? (or is it suggested to just manually turn interrupts on now?)

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

> So what is the macro to use for an interruptable interrupt?

No macro anymore. Those 10 people in the world who really need to
enable interrupts right in the prologue of the ISR are expected to use
__attribute__((interrupt)) manually for the declaration.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.