Implementing an ISR Bottom half or a routine immediately after ISR

Hi Subin,

if you need an RTOS for your application, take a look at http://www.ti.com/tool/sysbios - there is a free (BSD license) RTOS available from TI. Maybe that helps.

Apart from that, if you need the method called immediately and it is too long for the ISR itself it may become tricky I think. If it has too long runtime before the next interrupt arrives you will have a problem anyways. On the other side if instant reaction is not necessary, you could set a flag and use a timer to call your function on a regular interval. But if the method is rather long and interrupts appear while it is running and there is much other work to do you also may run in trouble. 

Hi Jan,

Thank you for the reply. I guess the time between two interrupts would be fine for the routine. I can not perform it in the handler anyway. An RTOS is not my option now. I don't have to run it in regular intervals. The main loop checks for the flag currently and calls the function. But this needs to be happening immediately after the ISR for best results. This is just an optimization.

Subin P Thomas said:

So I am looking for something with which I can execute a function immediately after the USB ISR return

Th epurpose of an interrupt is to interrupt current code execution as if it never happened. Executign something right after an ISR is normally not possible. But there are tricks.

Th eusual way is to set a flag in a global variable (must be declared volatile) and in main() you check for it.
Anothe rway (if you only have one event) is to enter low-power-mode in main when enabling interrupts. Teh ISR then ends LPM when the event occurs, main continues,knowing that it was waked by the event. This has, however, some pitfalls: main must be a LPM again before the IST is triggered next time (must be fast enpugh or has to disable interrupts until ready) or the implicit 'knowledge' won't work anymore.

The third way is to manually trigger a totally unrelated interrupt. E.g. set up a timer CCR unit for capture itnerrupt and manually change the input source form VCC to GND (or v.v.) triggering the timer interrupt. This way, as soon as you exit the original ISR, the timer ISR is called. This makes only sense, if this second ISR is 1) completely reentrant, that means it may be interrupted by itself, and 2) nested interrupts are enabled, that means, the second ISR enables interrupts while it is stil running (after reaching the point form which on it is reentrant).
This is necessary, so the first ISR may be called again even if the second is not done yet. Else the situation would be the same as if everything would be done in the first ISR.

However, if checking the flag in main will not meet your timing requirements, you should think of ways to do everything in the ISR and do it fast enough. because a secondary ISR has its own few latency cycles which are porbably more than the main checking loop requires.

You may even make the first ISR reentrant and enable nested interrupts, while doing everything inside this ISR. It mus tbe reentrant then, of course.

Ot you don't use ISRs at all and wait fo rthe event in main with a checking loop. THis might be faster than the ISR latency. (of course main cannot do anything else then).
Sometimes ISRs aren't the fastest way to do things. They are only if the CPU can sleep until an interrupt occurs, or if main is doing something else in the meantime.

It might be neccessary to rewrite part of the USB stack for best results. Microcontroller programming is not using convenient library function, but rather program things for exactly this application for best performance.

Hi Jens-Michael Gross,

Thank you very much for the pointers. There are a lot to experiment with. :) It is working fine now. The routine involve memcpy and memcmp and they doesn't seem to be happening properly when done from the registered event handler of the USB stack. The whole thing gets weird if I try to do it in the handler. The current setup works fine and I was thinking of some optimization that would let me learn something new. I will try the second interrupt method and will see how good I can make it.

Subin P Thomas said:

memcpy and memcmp and they doesn't seem to be happening properly when done from the registered event handler of the USB stack.

Any variable you alter inside this handler (or any other ISR) needs to be declared volatile, or its change may remain undetected by the main code. (a side effect of compiler code optimization).