Sub microsecond timing

[hansknec]

I would be pleased to here any comments about the speed of execution of interrupts and C code with or without embedded assembly calls. In particular I would like to trigger on the rising edge of an input TTL and immediately launch an output timing pulse. Can it occur in less than 1 usec? What is the maximum trigger to trigger timing (phase) variation if this is a repeating stable clock event? I'm thinking aloud now, but I'm assuming that there would always be a phase variation of up to 100nsec from pulse to pulse since the incoming trigger could arrive at the beginning of a system clock cycle or near the end of the cycle.

Project: PIC18F1220 at 40MHz. (25nsec per clock pulse, but this is 100nsec system clock right?).
When TTL trigger arrives on an interrupt pin, take another pin high for 250usec, followed by low for 100usec, followed by high for 4.2usec, then low again. The interrupt service routine could then exit and wait for the next interrupt that is expected in about 16msec.

I have searched the forum for microsecond, interrupts, etc, but I can't locate a definitive statement about code execution speed with regard to interrupts. I think the ultimate answer will lead me to programming in assembly and I have very little experience with that.

Thanks, John

[rwyoung]

I'm sure RJ or PCM Programmer will jump in and correct me but I believe the fastest you can get into your ISR is around 30 to 40 instructions using the CCS compiler. That requires writing your own generic handler and using a combination of the FAST and PRIORITY qualifiers. That was a flip and off-hand description of the solution.

You might want to consider NOT using an interrupt if your PIC isn't going to be doing anything except waiting for the edge. Set up a nice tight loop and poll for the edge transition instead.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!

[PCM programmer]

Example of polling the INT_EXT flag (instead of using an isr):
http://www.ccsinfo.com/forum/viewtopic.php?t=27167&start=4

[hansknec]

In my past experience with PicBasic Pro (sorry), assembly interrupts were always faster than a tight loop looking for a change of state. Is this not the case with CCS C compiled code?


In the example given, is this really just as fast as assembly code doing the same task?

[PCM programmer]

The interrupt dispatcher has to save and restore the state of the program.
That will always take longer than just polling a register bit.

[Ttelmah]

[hansknec]

agreed. When I was talking about PBP it was with regard to the ability to have a low phase variation between captured edges. For some reason, polling the pin would give a horrible result.

I understand that this is not polling the pin, but polling a register instead. I need to do some reading to find out why it would be different for speed.

Thanks, John

[Ttelmah]

The advantage of using the interrupt bit, is the ability to 'see' short signals. With the polled loop, the bit has to be present for one 'loop time', if it is not to be missed. The interrupt flag will get set by a signal that is present for just one clock cycle. The jitter will still be worse than with the full 'interrupt' solution.

Best Wishes

[hansknec]

ding! Light just turned on. I forgot about that.

In the mean time I've been reading over a tutorial for assembly. I'm sure it will benifit me in the end for quick bit manipulations.

Thanks, John