How to Write ISR function for Hardware and Software Interrupt

Question

Till now I used Vendor(Controller Vendor) ISR for handling the Interrupt. But I want to know how to write the ISR. I know about the Vector Table. Will take one simple example for GPIO Interrupt for Port 0. which is having the vector table P0INT_VECTOR(according to datasheet).

1. Now can any one tell me, how to write a ISR function for this.

I have seen the vendor example, 
 #pragma vector = P0INT_VECTOR
 __interrupt void p0_ISR(void) 
 {
 /*Some statement*/
 }

why it is #pragma, and how the function defined as p0_ISR, can we change the function name. What will be the impact of changing the name

I am not used the Software Interrupt much, but I know some basic, it will be used via INT commands.

2. How to write Software ISR.

• David: Could you tell us what processor you are talking about?
• user2732944: @David I am talking about simple 8051 controller, I just told as an example
• old_timer: you should try this question at stack overflow.

Answer 1

Pragmas are a standardized way of providing 'extra' information to your compiler, however the meaning is not defined outside the context of that particular compiler. So you need to consult the manual for the compiler to find out exactly what is going on. In this case it tells the compiler to populate the interrupt vector table entry 13 (P0INT_VECTOR is a constant defined in a header file) to point to the below routine.

__interrupt is a keyword extension that causes the compiler to emit code to do appropriate context save and restore for an interrupt. Again, see the compiler manual.

p0_ISR is an arbitrary name with no specific meaning to the compiler.

You would write an ISR for a software interrupt the same as any other interrupt, if SWI was supported by the '51 hardware (I don't think it is)- look up the name of the constant for the vector table.

All this stuff is very compiler- and processor-dependent so generalizations are not so useful. If you understand assembly programming for a particular processor you know what information you have to slip to the compiler for it to be able to emit correct code.

If the processor supports SWI, actually invoking a SWI might involve a keyword extension or you might have to dip into inline assembly etc.

Answer 2

as already answered, pragmas and __interrupt, etc are all very compiler specific and basically dont necessarily port. So if you want to leave the sandbox then you may have to take over completely which implies assembly (which itself doesnt necessarily port from one assembler to another but you have more control).

In general you need to look at the documentation on the processor, in your case it is probably a known address where the hardware looks for the address to the handler. The chip docs should have the instruction set and how to return from an interrupt, possibly a specific instruction. A simple way to manage it is to do what the pragmas would need to do but with a wrapper, the handler address could be to your assembly code, your assembly code saves enough state so it can sorta safely call a C function, that could be a normal C function from a language/pragma perspective (meaning dont add any), but dont do things in that function you cant do in an interrupt handler. Then on return from the C function, clean up state and use the proper interrupt return instruction.

Beyond that at some point obviously you need to setup the peripheral to cause an interrupt. In the interrupt handler in general but some chips you can shortcut this, you need to figure out who caused the interrupt, which is architecture or chip or both specific. Handle that interrupt, then sometimes you need to loop in the interrupt handler to make sure there are no more pending interrupts or interrupts that came in during the handling of the initial interrupt. And at some point you need to clear the state, often this happens in more than one place but is chip/archtecture specific. Often you want to start the farthest away at the peripheral and clear your way toward the processor avoiding generating a second/multiple false interrupts.

if you have a debug interface, ideally a uart that you can print stuff out to see things, and if your hardware/logic supports polling in addition to actually causing interrupts, IMO the best way to start is to cause an interrupt at the peripheral end of the chip but dont enable the interrupt on the processor end of the chip (one end you enable the creation the other end you disable the listening for sender vs receiver) then poll the processor/receiver end of that interrupt to see it assert, to then investigate the other status registers to see if you can programmatically determine that it was that peripheral, see what happens on the processor end when the peripheral is asked to clear the interrupt, does it clear all the way through or are there more layers (or was it an edge triggered pulse to start with). I pull out a lot less hair this way getting an interrupt/chip/system figured out.

and when I say peripheral and processor that could be on the same chip or the peripheral could be on a different chip, doesnt matter from a big picture perspective. depending on the architecture, chips, etc there may be multiple or several layers of interrupt enables in some interrupt tree to get from the peripheral to the processor, thus the polling for both the setting of the interrupt and the clearing. THEN you get into actually having an interrupt hander, proper saving of state (dont forget flags) restoring state and return instruction(s).

• old_timer: if you still have access to the toolchain that accepted the pragma and interrupt and generated working code then you should disassemble that code to see what the compiler generated (compared to a similar function that doesnt have those pragmas or other adjectives). and basically "just do that".