Hello to everyone. This is my Code:
void FIQ_Handler(void) __irq { T1CLRI = 0x55; // T1CLRI is an 8-bit register. // Writing any value to this register clears the Timer1 interrupt. GP4SET = 0x00040000; // P4.2 to "1" to see interupt-start on oszilloscope GP4CLR = 0x00040000; // P4.2 to "0" to see interrupt-ready on oszilloscope }
This code is execute 200000 times per second (timer-interrupt) On Oszilloscope i see a Time_jitter of about 200ns. There is a 120ns wide posetive Impulse every 5us. But the starting point jitters about 200ns. How can i reduce this Jitter? My uC is a ADuC7126
Avoid other interrupts and anything that disables interrupts for a while.
The timers can normally generate pin changes with very low jitter. But you can normally not have an ISR execute with very low jitter.
Exactly what problem do you need to solve, that makes you want to have interrupts at this speed and requires them to start with low jitter?
> Exactly what problem do you need to solve, that makes you want to have interrupts at this > speed and requires them to start with low jitter?
It is a PID-Regulator for use in scientific labs. To have a high versatility and not to be worse than the replaced analog unit i guess the Timer-interrupt-rate should be 200k or at least 100k. I will use the fast interrupt FIQ. There is no other intrrupt source in the system. The main loop at this time is only while(1){} I make this pulses only for debugging purposes. There are needle-pulses with an repitition-rate of 200k (5us) on the oszilloscope. The sweep rate of the oszilloscop is 1us/div. Triggering on the first needle pulse, the second needle-pulse is not stable. It jitters about 200ns. The uC runs with 32768*1275=41.779200MHz So the jitter is about 8 cycles.
Even if you get this to work, your ISR must be lighting fast (<= 5ns). How many instructions can be executed in this period? Not much. You are probably suffering from severe interrupt latency. I would say: faster clock, other chip, perhaps not an embedded processor at all (Pentium...?) if you need to run considerable code.
> Even if you get this to work, your ISR must be lighting fast (<= 5ns).
No, only 5us (1/200k) this is only speed of sound ;-)
Maybe polling in conjunction with a high accuracy hardware timer will do better...?
The "best" way to reduce interrupt jitter is to sleep the processor. When the core isn't spending time to process instructions, you will get a more consistent reaction when the interrupt finally happens.
This obviously means that all work needs to be done in the interrupt. Or that a main loop needs to do a very small amount of work whenever the ISR ends, so the main loop then has time to go to sleep again before the next interrupt wakes it up again.
But in this case, you are either running your algorithm at a too high frequency for the required regulation task, or you are using a way too slow processor.
Remember that even if you do manage with zero jitter, you still have the trouble of writing constant-time code in that ISR, so that every compuation in the ISR consumes an exact number of clock ticks, resulting in a fixed delay betweeen ISR activation and new control signal being output.
Constant-time algorithms are wery hard to write, and are very much processor-dependant. A division instruction can consume different number of clock cycles depending on value of divisor and dividend. And you can be hurt by cache effects too, so even table lookups can give varying access times.
With a faster processor, a couple of clock cycles extra will represent a smaller jitter.
Just so we know - exactly what is the frequency of the process signal you need to control?