interrupts

Many thanks for those who help me! (:

I got a problem here...

If i were to use 3 types of interrupts(external interrupt0, timer0 and timer1) in one single program, how should i go about writing the codes in the program?

Parents
  • Well, it's good enough for the PCI bus on a PC.
    OH, come on. do not make "PC technology" a qualifier.

    A polling loop would just adjust its loop frequency. A interrupt-driven solution will completely starve low-prio interrupts. Don't assume that all interrupts produce received data, or ticks, and that a lower service frequency means a failure. A lower polling frequency of a temperature sensor need not break the application.
    and as I said in my previous post: "ISR reading it is cheap (2 lines) you can skip processing it if you need to. This, coming to think of it makes the reading an ISR and the processing polled. Anyhow, I would consider it an error if something, whether significant or not, was occasionally skipped.

    2) we must also try to make our code self-repairing. ... were perfect, we would not need any watchdog timers...
    well a watchdog tries, in effect make a 'self repair" regardless of polled or ISR

    An ISR is written to handle the conditions it has been specified to handle. That is not the same as being required to handle all possible events a device may be able to generate. If I don't turn on a FIFO for a serial device, there is no need for the ISR to know about FIFO events. However, a problem that results in the serial device issuing a FIFO event to an ISR that doesn't know about it may result in the device generating an infinite number of FIFO interrupts.
    I have no idea what this means, there is no '51 with a FIFO.

    It is a programming error to not service any events I have enabled.
    which is MUCH MORE likely to happen with polling than with an ISR

    3) It normally takes less code for a polled solution to gracefully continue with limited capabilities in case of a hradware error.
    Now you are talking PC again. an embedded syatem has no purpose "continuing with limited capabilities"

    Interruptifobia? No! Just a question of selecting tools. My current ARM project has 16 out of 28 possible interrupt sources covered by interrupt handlers, so I can't be too scared of interrupts
    I would not suspect you as a sufferer, but many exist.

    The polling loop will continue to do the "batch" jobs. A fully interrupted solution will permanently stop batch jobs if any interrupt source jams.
    Again you are talking PC again. an embedded syatem has no purpose "continuing with limited capabilities"

    Always remember: There is no use to have an ISR never miss to detect the reception of a serial character, if the "main loop" is jammed and can't process the data in the receive buffers. Such a unit is dead. If the problem is because of a broken hw device, it doesn't matter if the unit has a watchdog. After the reboot it will just deadlock again.
    AH, now you realize we are talking embedded

    Per, I see from your statements that you are "talking PC (alike)" and I am "talking embedded". This is two totally different worlds.

    I know of no true embedded system where there is ANY point in "continuing woth limited capabilities" if you want to give some non-exotic examples, I'd like to see them.

    Erik

Reply
  • Well, it's good enough for the PCI bus on a PC.
    OH, come on. do not make "PC technology" a qualifier.

    A polling loop would just adjust its loop frequency. A interrupt-driven solution will completely starve low-prio interrupts. Don't assume that all interrupts produce received data, or ticks, and that a lower service frequency means a failure. A lower polling frequency of a temperature sensor need not break the application.
    and as I said in my previous post: "ISR reading it is cheap (2 lines) you can skip processing it if you need to. This, coming to think of it makes the reading an ISR and the processing polled. Anyhow, I would consider it an error if something, whether significant or not, was occasionally skipped.

    2) we must also try to make our code self-repairing. ... were perfect, we would not need any watchdog timers...
    well a watchdog tries, in effect make a 'self repair" regardless of polled or ISR

    An ISR is written to handle the conditions it has been specified to handle. That is not the same as being required to handle all possible events a device may be able to generate. If I don't turn on a FIFO for a serial device, there is no need for the ISR to know about FIFO events. However, a problem that results in the serial device issuing a FIFO event to an ISR that doesn't know about it may result in the device generating an infinite number of FIFO interrupts.
    I have no idea what this means, there is no '51 with a FIFO.

    It is a programming error to not service any events I have enabled.
    which is MUCH MORE likely to happen with polling than with an ISR

    3) It normally takes less code for a polled solution to gracefully continue with limited capabilities in case of a hradware error.
    Now you are talking PC again. an embedded syatem has no purpose "continuing with limited capabilities"

    Interruptifobia? No! Just a question of selecting tools. My current ARM project has 16 out of 28 possible interrupt sources covered by interrupt handlers, so I can't be too scared of interrupts
    I would not suspect you as a sufferer, but many exist.

    The polling loop will continue to do the "batch" jobs. A fully interrupted solution will permanently stop batch jobs if any interrupt source jams.
    Again you are talking PC again. an embedded syatem has no purpose "continuing with limited capabilities"

    Always remember: There is no use to have an ISR never miss to detect the reception of a serial character, if the "main loop" is jammed and can't process the data in the receive buffers. Such a unit is dead. If the problem is because of a broken hw device, it doesn't matter if the unit has a watchdog. After the reboot it will just deadlock again.
    AH, now you realize we are talking embedded

    Per, I see from your statements that you are "talking PC (alike)" and I am "talking embedded". This is two totally different worlds.

    I know of no true embedded system where there is ANY point in "continuing woth limited capabilities" if you want to give some non-exotic examples, I'd like to see them.

    Erik

Children
More questions in this forum