Thread: How to implement ISRs in C ?

Your question is short and sweet, but unfortunately not quite so for the answer. Unfortunately, you also haven't given enough information to actually give a complete answer.

The handling of ISR (Interrupt Service Requests) is dependant on the architecture of the processor. Most processors have a vector table to indicate which IRQ go to what interrupt handler. In all architectures I'm aware of, you can't [without support from the compiler] write interrupt handlers directly in C, but you can write a small "wrapper" that does the necessary steps to get a sane context for the C code to run in, and after the C-code has been run, restore the original context of the system.

Most of that wrapper deals with saving and restoring registers that the ABI (C environment) "lets" the C functions destroy. For example, in x86, eax, ecx and edx are commonly "scratchpad" registers - so a function call is allowed to "destroy" those values. But an ISR happens at "any" time in the code, and of course, these registers may hold some useful data that is needed after the ISR returns.

On some processors, there are more things to deal with. 29K for example, the ISR setup is a matter of a dozen or so instructions just to allow C code to run.

On some processors, the vector table isn't a "table of adresses", but rather a set of fixed addresses that the processor jumps to, at for example 16 byte offsets, so you have some short sequence of instructions that jump off to somewhere else.

In summary, a lot of what you need to do in an ISR can be done in C, but you need some amount of "setup" and "teardown" code to make the C code run correctly and correctly restore the state of "before the ISR".

--
Mats

Well, the example would be dependant on the architecture of the processor.

In x86, the wrapping code would look something like this:

Code:

wrap_irq:
               push eax
               push ecx
               push edx
               mov  eax, [esp+16]    // Get irq number
               push eax
               call   isrtable[eax * 4]
               add  esp, 4
               pop  edx
               pop  ecx
               pop  eax
               iret

This probably doesn't tell you much more than before, but it's quite hard to explain these things without a LOT of writing and a good amount of feedback from the other party.

--
Mats

You're also strongly constrained by what the OS will allow you to do.

Handling interrupts in your average consumer OS is a privileged task handled by drivers, not normal user code.

If you are writing code in a normal application in Windows or Linux, you will never EVER write code that even knows about interrupts in a direct way. The programmer will possibly know that when reading the disk, network packets are sent or received, or as time passes, interrupts are generated by the hardware - but the correlation between those interrupts and the actual code in the application using files or network services, will be so remote that it's just like knowing that a spark-plug fires in the engine when you are driving a car - it is sort of useful to understand that this happens, but you don't NEED to know it to understand what's going on.

If, on the other hand, you are working in an embedded system, or working on drivers in Windows or Linux, you may well deal with interrupts. If a potential employer is asking this sort of question, it's likely that they ask because it's relevant to the task you are to do. On the other hand, I was asked "How much water flows through the tames at London bridge" on an interview, and no, it wasn't for a job with the "Thames River Control".

--
Mats

[rant]I personally HATE the term "Embedded C" - it means nothing, but it's a good term for someone who also knows little, to make the difference between C programming in an embedded world [this means something] and C programming in a desktop or server environment [for example].

We don't say "Server C" or "Desktop C", right?
[/rant]

Embedded programming often involves lower level programming, such as device control functionality and direct access to hardware components. But the language C is no different here than it is in Windows - after all, Windows also allows you to access devices at the driver level - it may not be entirely trivial to create a driver, but that's a slightly different matter. Of course, Windows [and Linux] also takes control of Interrupts, DMA and any other low-level functionality "for you" - so even driver programmers don't need to worry about wrapper code and such things - you just tell Windows that "When the interrupt for my device happens, please call the function My_ISR()" when you register for an interrupt.

--
Mats

Embedded C covers all sorts of things from mobile phones, microwaves, DVD players, cameras, spacecraft etc etc.

If it has an OS at all, it will likely be an RTOS.

More often than not, you'll be dealing with physical addresses rather than virtual memory, so if it doesn't fit, there's no swap file to bail you out. There's usually a lot less of it about as well, maybe only a few MB at most.

The processors are slower than your modern desktop machines by at least an order of magnitude. Some care is therefore required in choosing the best approach to do something.

Debugging an embedded target can be a real challenge as it is easy to trash the entire machine and have no clue whatsoever as to what happened. Even the most severe bugs on your desktop user programs are easily trapped by either the debugger or the OS.