# Software interrupt vs function

After about 3 years of working with MCUs still I don't know what's the use of Software interrupts? I have done several jobs with STM32 and I have never used the software interrupts. Indeed this is a big question to me:

Why when we can use a simple function to do a task, should we use a software interrupt? What are the differences between a software interrupt and a function?

Every time you like, you can call a function (that you have written for your job). There ought to be some benefits to using a software interrupt instead of a simple function. I'm not sure but I think there is a benefit for software interrupts: you can assign a priority for a software interrupt, then you can give a higher priority to the software interrupt to avoid the hardware interrupt breaking your task.

• I think the main purpose for using interrupts is that you can carry on doing other important tasks while that is waiting for something else to happen, and when the timings aren't always going to be constant. Also I think it is a bit quicker than polling in most instances. – MrPhooky Apr 14 '15 at 12:39
• @MrPhooky That's Hardware interrupts you're talking about. The OP is talking about Software interrupts. – brhans Apr 15 '15 at 14:56

The main difference between a function and a software interrupt is what is known as context.

• A function runs within the context of your main program.
• An interrupt runs within the context of the interrupt handler.

On a simple system this may be no real difference, and software interrupts may simply be used as a convenient way of providing library routines hard coded in ROM - you don't need to know the address of every routine, only the ID code and the main entry point. This makes your code more portable.

However, on more complex systems the software interrupt may run in a completely different environment, known as the kernel context. Normally your application would run in a protected user context which has limited access to resources. Only when running in the kernel context can you perform the more complicated tasks - indeed some systems even limit which instructions can be executed, so you need a mechanism to trigger code in the kernel context - and for that an interrupt is used.

• Also, interrupts can arbitrarily halt a program's progress so the system can do something else (e.g. hardware interrupts). Your programs do not need to take this into account, because, from your program's point of view, the state of the function is unchanged from when the interrupt occurred. On older systems, this is how TSR (Terminate/Stay Resident) programs simulated multitasking, by hooking off the timer/clock interrupt. Even without IOPL levels, there was a benefit to, say, keeping the system clock up to date. – phyrfox Apr 14 '15 at 15:46
• Maybe also note that those "software interrupts" are also referred to as "synchronous interrupts", because the application code knows exactly when and why such an interrupt occurs, as opposed to "asynchronous interrupts" which may, from the point of view of the application, basically happen at any time in an unsolicited manner. – JimmyB Apr 14 '15 at 16:41
• @HannoBinder: I think the OP is talking about posting interrupt requests to the Cortex-M3 vectored interrupt controller; if code for a high-priority interrupt posts a lower-priority one, the request will be deferred until some later time when all higher-priority interrupts have finished. – supercat Apr 14 '15 at 22:42

Software interrupts may be used to finish off an interrupt task at a lower priority. Timing critical code is often given a high interrupt priority to avoid too much latency. Once the timing critical part is finished, there may be additional tasks that may be too timing critical for the main loop, but are not so critical as to hold-up other high-priority interrupts. Triggering a lower-priority software interrupt can accomplish this.

For example, suppose you have multiple stepper motors each with their own timer. The timer interrupts are given a high-priority to minimize step jitter. The most timing critical task may be as simple as setting or clearing a step pulse or advancing the phase outputs. There may be additional functionality required such as calculation of acceleration ramps, sensor processing, etc. Since this needs to be processed every step, it may not be appropriate to process this from main() as the main loop timing may be too long. These additional tasks may be processed by a lower-priority software interrupt so as not to increase the latency of the other high-priority stepper channels.

What are the difference between a software interrupt and a function?

A function gets called immediately from wherever it is called and does not change current interrupt priority level if called from a interrupt. A software interrupt is an interrupt trigger that will cause that interrupt to be called when it's priority comes up. If a function call were inserted at the end of a high-priority interrupt, the function would be contained within that high-priority. By triggering the lower-priority software interrupt and then returning from the high-priority interrupt, the functionality gets called at the new (lower) priority.

• Another common pattern may be to have a 100KHz interrupt to handle timing-critical stuff, and also need a 1kHz timer tick, but not have two separate timers available. It doesn't take a while lot of overhead for a 100kHz interrupt routine to say if ((timer_count--) & 0x80000000) SET_TICK_INTERRUPT_FLAG(); else timer_count = temp-1; The other interrupt can then do its thing and with interrupts briefly disabled add 100 to timer_count; even if the 1kHz routine takes over 10us to execute it won't interfere the 100kHz one. – supercat Apr 14 '15 at 16:38
• In a similar way, I've used software interrupts in simple systems (without a full RTOS) as a pseudo-scheduler, where hardware requirements are handled by the ISRs, but callback functions and other lengthy tasks that are performed in response to changes in he hardware state are delegated to the software interrupt. – Evil Dog Pie Apr 15 '15 at 7:46
• You've basically described a variation of "bottom half". Do you have any reference for this being also termed "software interrupt"? It's quite a different meaning from Majenko's answer, and the question is tagged ARM - the architecture actually has the SWI (software interrupt) instruction. – domen Apr 15 '15 at 8:55
• @domen I'm not sure what sort of reference you need. It is termed "software interrupt" because that is what is used to achieve it. In the context of ARM, the OP specifically referenced the STM32 and provided a link to the RM0008 reference manual. This is not a ARM core reference manual. The only "software interrupt" covered in RM0008 is the EXTI_SWIER (software interrupt event register) which may be used to generate software interrupts whether or not the actual hardware pins are used for interrupts. I have not personally used the SWI (SWC) instruction. – Tut Apr 15 '15 at 10:44
• Thanks! It might be good to include some of this information in the answer, to make it clear which "software interrupt" is it. – domen Apr 15 '15 at 11:00

To expand a bit on Majenko's answer, software interrupts are used to implement operating systems, particularly the system call interface. This means that applications don't need to be linked with the operating system to make function calls, and the context switch allows the OS to limit access to the hardware and take advantage of things like protected memory.

If you're not using an OS and you control all of the code on the MCU, you probably don't need to use software interrupts. (Although as Tut mentioned, they can have other uses.)

The Linux and MS-DOS system call interfaces on x86 use software interrupts, so I'll link to those as an example.

• And in many cases where the os uses soft interrupts, they are wrapped in functions to make life simpler. – hildred Apr 14 '15 at 15:40
• I still program things (brand new too) for DOS, and am very familiar with the int 21 handlers. Almost everything I need I/O wise is handled with the DOS ISR. – R Drast Apr 14 '15 at 16:56
• Do note that the page cited for Linux is from 1993-1996. – user Apr 15 '15 at 12:42
• I replaced the link with a more up-to-date one. – Adam Haun Apr 15 '15 at 13:29