• State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 21 subscribers
  • Views 1729 views
  • Users 0 members are here
2025 survey

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.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

INT0 used as triggering

Fabio Vivaldini

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

Parents
  • 0 in reply to Fabio Vivaldini

    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.

Reply
  • 0 in reply to Fabio Vivaldini

    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.

Children