|
DOes anyone now how to write an IRQ handler that will just stop until a switch is released? |
|
|
|
In a message dated 11/12/03 12:15:52 PM Eastern Standard Time, writes: DOes anyone now how to write an IRQ handler that will just stop until a switch is released? ==================================================== Sounds like a job for the computer science concept of a 'loop'. Some folks might tell you that you dont want to put loops in your interrupt handler... just set a flag in the int handler... poll the flag in the main loop..... [Non-text portions of this message have been removed] |
|
|
|
Here it is, the complete program (for E series): REGS equ $1000 OPTION equ REGS+$39 IRQE. equ %00100000 org $F800 Start lds #$FF ldx #REGS bclr [OPTION,x,IRQE. ;low-level recognition LoopForever wait bra LoopForever IRQ_Handler rti org $FFF2 dw IRQ_Handler org $FFFE dw Start Just tie your switch to the /IRQ line. Don't forget the pullup. Hope I didn't just do your homework! ----- Original Message ----- From: "gompertm" <> To: < > DOes anyone now how to write an IRQ handler that will just stop until > a switch is released? |
|
On Thu, 2003-11-13 at 04:35, wrote: > Sounds like a job for the computer science concept of a 'loop'. Some folks > might tell you that you dont want to put loops in your interrupt handler... just > set a flag in the int handler... poll the flag in the main loop..... That's part of the answer. The other part is that - as always - the question isn't actually properly asked, because the question makes a presumption which is itself incorrect. In a message dated 11/12/03 12:15:52 PM Eastern Standard Time, > writes: > DOes anyone now how to write an IRQ handler that will just stop until > a switch is released? The problems here are: 1} IRQs are unsuitable for monitoring switches. Switches are very "dirty" little beasties - you may innocently imagine that you turn on the switch, and your room light goes on. Such is not the case. From the *microprosessor's* point of view, what actually happened was that the switch was off, then it was rapidly switched between on and off between ten and a hundred times for slightly varying durations (of milliseconds or fractions, each), and on the last occasion it happened to stay on. If then, you attach a switch to the IRQ line, the processor has to deal with - interpret - dozens or hundreds of actions each time the switch is actuated, whether on or off. What IRQs *are* suitable for, is monitoring important events generated by digital logic - such as synchronising pulses. But in fact, you already have a timer available in the processor, which you can use to arrange regular intervals - such as every hundredth of a second - at which you can poll the switch and implement a "debounce" algorithm, so that when the switch changes state and maintains that state for say, six hundredths of a second, it is *then* considered to have been actuated. 2} If monitoring this switch is the *only* thing you wanted the processor to do - you almost certainly wouldn't be using a microprocessor. If the switch's primary function is to start up all the tasks of the microprocessor, then (no, you don't just put the switch in the power line but ... ) what you are looking for is the "sleep" function of the processor, i.e., the switch is in the IRQ line, the processor executes its "hibernate" sequence, when the switch is pressed, the processor wakes up, polls the switch a short time to make sure it is actually pressed, in which case it then executes its main function and in either case, it then polls the switch to determine its release before returning to the "sleep" or "hibernate" mode. If the switch is but one of many things you need the processor to do, then it should be polled regularly, either by a timer interrupt as described, or by the main polling (process sharing) cycle. 3} As the processor does not provide for monitoring o the IRQ line as such, if you deem the switch *really* important, you may elect to have it sensed by both the IRQ line and an I/O line connected together. It can be ignored until it causes an IRQ, then debounced as necessary, monitored by polling the I/O line. I can't quite figure whether this is the same question as Tony's program - which appears to be just a skeleton you would have to adapt in some detail - proposes to answer, but I too certainly "Hope I didn't just do your homework!" If this does not make good sense, next step is to explain what you *actually* need to do? -- Cheers, Paul B. |
|
|
|
Yes I am a student ,No I already built my own program, I was asking for your help to gain a understanding of what mine did. I just put a delay loop in the interupt handler. This will allow the switch to stop the execution of the system until it is released. The main question that I was wondering was whether i even wrote the interput correctly or not. I mostly need help how to lock the irq line to a section of code. The switch itself comes in through an 8255 PPI so it should not have a bouncing problem. This makes the irq line come to the MCU in a controlled fashion. --- In , "Paul B. Webster" <paulb@m...> wrote: > On Thu, 2003-11-13 at 04:35, BobGardner@a... wrote: > > > Sounds like a job for the computer science concept of a 'loop'. Some folks > > might tell you that you dont want to put loops in your interrupt handler... just > > set a flag in the int handler... poll the flag in the main loop..... > > That's part of the answer. The other part is that - as always - the > question isn't actually properly asked, because the question makes a > presumption which is itself incorrect. > > In a message dated 11/12/03 12:15:52 PM Eastern Standard Time, > > gompertm@y... writes: > > DOes anyone now how to write an IRQ handler that will just stop until > > a switch is released? > > The problems here are: > > 1} IRQs are unsuitable for monitoring switches. Switches are very "dirty" > little beasties - you may innocently imagine that you turn on the switch, > and your room light goes on. Such is not the case. From the > *microprosessor's* point of view, what actually happened was that the > switch was off, then it was rapidly switched between on and off between > ten and a hundred times for slightly varying durations (of milliseconds > or fractions, each), and on the last occasion it happened to stay on. > > If then, you attach a switch to the IRQ line, the processor has to > deal with - interpret - dozens or hundreds of actions each time the > switch is actuated, whether on or off. > > What IRQs *are* suitable for, is monitoring important events generated > by digital logic - such as synchronising pulses. But in fact, you > already have a timer available in the processor, which you can use to > arrange regular intervals - such as every hundredth of a second - at > which you can poll the switch and implement a "debounce" algorithm, so > that when the switch changes state and maintains that state for say, six > hundredths of a second, it is *then* considered to have been actuated. > > 2} If monitoring this switch is the *only* thing you wanted the > processor to do - you almost certainly wouldn't be using a > microprocessor. If the switch's primary function is to start up all the > tasks of the microprocessor, then (no, you don't just put the switch in > the power line but ... ) what you are looking for is the "sleep" > function of the processor, i.e., the switch is in the IRQ line, the > processor executes its "hibernate" sequence, when the switch is pressed, > the processor wakes up, polls the switch a short time to make sure it is > actually pressed, in which case it then executes its main function and > in either case, it then polls the switch to determine its release before > returning to the "sleep" or "hibernate" mode. > > If the switch is but one of many things you need the processor to do, > then it should be polled regularly, either by a timer interrupt as > described, or by the main polling (process sharing) cycle. > > 3} As the processor does not provide for monitoring o the IRQ line as > such, if you deem the switch *really* important, you may elect to have > it sensed by both the IRQ line and an I/O line connected together. It > can be ignored until it causes an IRQ, then debounced as necessary, > monitored by polling the I/O line. > > I can't quite figure whether this is the same question as Tony's > program - which appears to be just a skeleton you would have to adapt in > some detail - proposes to answer, but I too certainly "Hope I didn't > just do your homework!" > > If this does not make good sense, next step is to explain what you > *actually* need to do? > -- > Cheers, > Paul B. |