We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Dear collegues,
I'm trying to use the INT0 interrupt as trigger system. Basically I have in input a square wave having the low level of 8 msecs and I would like to have on the output a square wave having 10 msec or more. The basically idea is to use INT0 to detect the high to low edge and synchronize on this edge the output. The output lenght is set by the timer4 counting msecs.
So, basically I do the following:
Enable interrupt INT0 (tried both edge or level triggering IT0/IT1)
Set TIMER4 to call interrupt every msec (tis works perfectly already)
Seems working but:
If I use edge triggering, the INT0 seems called by both the hi/lo and lo/hi transition of the input signal...
If I use level triggering, the INT0 takes fake callings during all period the input signal say at low level...
I'm getting crazy... anybody could give an advice? The processor is a Silabs C8051F125.
Thanks in advance for the suggestions.
Bye Fabio
Thanks Andrew,
but it doesn't answer to my problem, or maybe I do not understand completely.
I tried to use edge trigger, but for some reason the INT0 call teh interrupt routine also on the low to high input changes, not only high to low as it should do.
I though to an hardware problem, but the input signal is perfectly clean (generated by a NE555, then transformed in RS422 format, then transformed in the TTL format and then input on pin P1.3 correctly conneted to internal INT0. Thanks. Fabio
chip? - clock? - C/asm?
Erik
The SiLabs chips have a lot more options than the basic, old, original Intel 8051.
Does it, perhaps, have an option to trigger on both edges...?
Processor Silabs C8051F125
Using Keil uVision2
I checked into the processor datasheet but it doesn't tell anything about double INT0 detection... It only say that INT0 and INT1 happens on the hi to lo transition of the signal applied to the pin (if the edge triggering is selected.
Noisy input signal should cause INT0 intervention, but stil on the high to low transition.
Here the problem is that sometimes the LOW to HIGH transition is generating an interrupt...
But a noisy input signal means that both when you think you are changing from low-to-high and when you think you are changing from high-to-low, you may generate a burst of multiple changes of the pin state. So you may get the correct interrupt condition even when you think you shouldn't.
ok!
Anyway I got another way.
I turned on the timer 3 at sufficient speed running and then I check the pin state monitoring in polling. Get also better result givint TIMER3 the most high priority.
Seems the system now is ok. The lenght stability is not perfect, but the fluctuation is only few usecs over a lenght of 10 or more msecs.
Thanks everybody.
F.
So you have a high-speed timer generating interrupts at much higher frequency than the input signal now?
There are other methods possible.
1) Just a freerunning timer without interrupts. Capture timer when you get the interrupt. Check time since last interrupt - ignore interrupt if still in deadband. In your case about 75% of the expected period.
This can still produce lots of CPU load if the signal noise/bounce produces a large number of interrupts. But it gives good latency, since your ISR is waiting for the interrupt to happen and isn't limited by any polling frequency.
2) Turn off external interupt, and start a single-shot timer with interrupt to reactivate the external interrupt after debounce time - or in your case after about 75% of the period.
This has the advantage that you have a fixed CPU load even if you have a huge amount of bounces when input signal toggles. And it isn't limited by the a slow poll frequency.
Fabio,
You might benefit from this about 'edge triggered' interrupts. It doesn't explain your issue, but you should be aware of it when dealing with C51 interrupts:
http://www.keil.com/forum/11969/
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA