Sign in

username:

password:



Not a member?

Search m68hc11



Search tips

Subscribe to m68hc11



m68hc11 by Keywords

27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ


Ads

Discussion Groups

See Also

DSPFPGAElectronics

Discussion Groups | | Interuppts

Interuppts - gompertm - Nov 12 12:08:00 2003

DOes anyone now how to write an IRQ handler that will just stop until
a switch is released?





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )


Re: Interuppts - Author Unknown - Nov 12 12:35:00 2003

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]





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Re: Interuppts - Tony Papadimitriou - Nov 13 4:35:00 2003

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?




(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Re: Interuppts - Paul B. Webster - Nov 13 7:54:00 2003

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.





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Re: Interuppts - gompertm - Nov 14 16:30:00 2003

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.




(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )