This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Using interrupts not implemented as Software interrupts?

We know that a Cortex-M0 or any other Cortex-M may have fewer interruptions implemented the architecture defined in the standard, so we can not use interrupts implemented as software interrupts by manipulating the registers SETENA / ClrEnable and SetPend / ClrPend.

For example, being the interrupt # 5 (Exception # 21) not implemented at the hardware level, this could be used as an interrupt / exception of software?

Parents
  • I think this is really a cool feature.

    -I immediately thought of a context-switcher which is normally switched by a timer-interrupt, but can also be switched by a SVCall.

    Whether or not it's a good idea to do so, I do not know. A timer could of course also be triggered by the SVCall setting a pending-bit.

    ...Setting the pending bit has an advantage over a few other solutions:

    You won't get any race-conditions; eg. your context-switcher will not be invoked while it's about to switch, since the interrupt's priority will guard against that.

    In addition, tail-chaining will be utilized.

Reply
  • I think this is really a cool feature.

    -I immediately thought of a context-switcher which is normally switched by a timer-interrupt, but can also be switched by a SVCall.

    Whether or not it's a good idea to do so, I do not know. A timer could of course also be triggered by the SVCall setting a pending-bit.

    ...Setting the pending bit has an advantage over a few other solutions:

    You won't get any race-conditions; eg. your context-switcher will not be invoked while it's about to switch, since the interrupt's priority will guard against that.

    In addition, tail-chaining will be utilized.

Children