Software interrupt

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

On a ATxMega is software interrupt possible

by calling (call) the label of an existing interrupt

routine, like:

    cli

    call intlabel

    ;returns here

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

Yes but the int code will end with RETI which may not be what you want.

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

You mean the intflag?

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

I in SREG.
.
Because the ISR handler will already end RETI it will return but it will also enable I again.
.
What you can do is put the common code into a separate function the call that from both ISR and mainline.
.
If you do have code that has to be called from both it may be suggesting poor program design.

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

If the call returns after the call location

setting the intflag is the same as SEI?

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

Almost, yes.

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

RETI in Xmega doesn't modify I flag in SREG. This is because there are three interrupt priorities in Xmega, so interrupts are handled in different way than in ATtiny/ATmega. I don't know how Xmega will act when you run the code from the first post, but it will be not as for ATtiny/ATmega.

 

Edit: I have found information about PMIC.STATUS register. It contains HILVLEX, MEDLVLEX and LOLVEX flags that indicate that interrupt handler of interrupt of corresponding priority is executing. They are indicated as read-only.

Last Edited: Wed. Oct 25, 2017 - 03:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, missed the fact this was in Xmega forum - oops blush

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

As I recall, the Xmega has no software interrupts.  I guess you could get an otherwise unused I/O device to generate an interrupt.  I am curious about why you want this interrupt.

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

How about using PinChange interrupt and toggle a spare port pin. That will work with Mega/Tiny that have pcint.

 

Jim

 

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

The datasheet states RETI restores PMIC

as it was before the interrupt occured.

Restore from what?

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

I guess one of HILVLEX, MEDLVLEX and LOLVEX bits in the PMIC.STATUS register is set on interrupt procedure enter and the same bit is cleared on RETI. When one of these flags is set, all interrupts of the same or lower priority are blocked. This is how I think it works.

Last Edited: Wed. Oct 25, 2017 - 10:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Reading this the bits are set on int and cleared with RETI.

A CALL will not set any, so how does RETI know which one to clear.

 

Bit 2 – HILVLEX: High-level Interrupt Executing
This flag is set when a high-level interrupt is executing or when the interrupt handler has been interrupted by an
NMI. The flag will be cleared when returning (RETI) from the interrupt handler.
 Bit 1 – MEDLVLEX: Medium-level Interrupt Executing
This flag is set when a medium-level interrupt is executing or when the interrupt handler has been interrupted by
an interrupt from higher level or an NMI. The flag will be cleared when returning (RETI) from the interrupt handler.
 Bit 0 – LOLVLEX: Low-level Interrupt Executing
This flag is set when a low-level interrupt is executing or when the interrupt handler has been interrupted by an
interrupt from higher level or an NMI. The flag will be cleared when returning (RETI) from the interrupt handler.

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

GBaars wrote:

A CALL will not set any, so how does RETI know which one to clear.

I don't know, but I guess it uses simple algorithm like:

if NMIEX is set // this is the flag indicating that NMI handler is running
    clear NMIEX
else if HILVLEX is set
    clear HILVLEX
else if MEDLVLEX is set
    clear MEDLVLEX
else
    clear LOLVLEX

 

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

Some of the peripherals have interrupts that can be triggered by software. You have to be a little bit creative, but some of the interrupt bits are writable or you can just do something like configure a timer to trigger on the next clock cycle.

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

If that is the case, a CALL doesn't

set any flags, RETI won't clear or clear

whatever. So just a CALL may work

no need for software interrupts with

I/O pins or whatever.