Searching \ for 'Simultaneous Interrupts' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'Simultaneous Interrupts'.

Truncated match.
PICList Thread
'Simultaneous Interrupts'
2000\04\09@101251 by Jim Dossey

flavicon
face
How are simultaneous interrupts handled in the 16C74A?  For example,
should I check all of the interrupt flags when I receive an interrupt,
or can I stop after finding the first flag that is set?  Can several
interrupt flags be set on 1 interrupt?

If this is covered somewhere else, just point me in the right
direction.  I couldn't find a clear answer to this question in the PIC
manuals.

Thanks,
Jim Dossey

2000\04\09@134709 by David VanHorn

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 10:09 AM 4/9/00 -0400, Jim Dossey wrote:
>How are simultaneous interrupts handled in the 16C74A?  For example,
>should I check all of the interrupt flags when I receive an interrupt,
>or can I stop after finding the first flag that is set?  Can several
>interrupt flags be set on 1 interrupt?

This is how you set your interrupt priorities.
The highest priority flag is checked first, and so on.
It's possible for more than one flag to be set.


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBOPDb7IFlGDz1l6VWEQKsrgCeNNlM5ST2WPTpKiVEj2Hp0SK9zkEAoOb8
pmogyc4tEyzgkDaLYKkXk9EU
=pcQb
-----END PGP SIGNATURE-----

2000\04\09@210243 by PDRUNEN

picon face
In a message dated 4/9/00 9:12:48 AM Central Daylight Time, spam_OUTjfdTakeThisOuTspamMERCURY.NET
writes:

<<  For example,
should I check all of the interrupt flags when I receive an interrupt,
or can I stop after finding the first flag that is set?  Can several
interrupt flags be set on 1 interrupt?
 >>

Personally, I check all flags and do something, either just clear the flag or
act on it.  A flag can get set even if the IE bit associated is not set.

Paul

2000\04\10@112152 by M. Adam Davis

flavicon
face
Each interrupt sets its own flag.  If the intcon, pir/pie, etc registers are set
right, then certian interrupts will set the global interrupt, which then
branches to your interrupt routine.  It is not the peripheral which interrupted
the processor, but the global interupt, which is triggered by another interrupt.

This means that you can have every interrupt triggered on the PIC, or have them
triggered while you are sevricing an interrupt, etc.

This is why the global interupt is turned off when your interrupt routine is
called, we don't want an endless loop.

You can handle interrupts a few ways:

Let's say two interrupts are triggered at the same time.  The uC drops you into
the interrupt routine.

You check the interrupt flags according to a certian priority, and take care of
a process when you run into a flag.

At this point you can do three things:
Exit the interrupt routine, assuming only one flag was set
Continue to check the remaining interrupt flags
Jump (not call) to the beginning of the interrupt routine to start checking for
flags again, and only exit when all flags are clear (basicly looping through the
routine until no more interrupts are happening).

If you exit the routine without checking other flags, and there are other flags
set, your uC will be interrupted immediately after your RETFIE (which sets the
global interrupt flag again).

You will not lose an interrupt.

-Adam

Jim Dossey wrote:
{Quote hidden}

2000\04\10@115849 by Thomas McGahee

flavicon
face
Actually, if you are going to use a GOTO in an attempt
to process a second interrupt flag, then you do not want the
GOTO to jump to the beginning of the interrupt handler,
but to the section of the interrupt handler right
AFTER the beginning section that saves w and the flags.
(And if you did NOT properly save w and the flags,
then you can expect some really strange behavior!)

inthandler
         save w and status using usual convoluted method
int2
         determine which interrupt flag(s) was set
         vector to routine to be handled.
         if NO flag set, GOTO INTDONE
routine1
         do something
         clear intflag associated with routine1
         goto INT2
routine2
         do something
         clear intflag associated with routine2
         goto INT2
routine3
         do something
         clear intflag associated with routine3
         goto INT2
intdone
         restore w and status using usual convoluted method
         RETFIE

{Original Message removed}

2000\04\10@125314 by Quitt, Walter

flavicon
face
So that interrupts don't take too long,
I service the highest one first, clear the interrupt flag and iret.
That way only 1 (one) service is performed per interrupt.
This is done so time critical (timer) interrupts are not held off.
Basically, I want to minimize the time spent in any interrupt event.
Get in and get out as fast as you can.

My technique works for me, your milage may vary,
Walt...

{Original Message removed}

2000\04\10@144718 by M. Adam Davis

flavicon
face
I thought about that, but my understanding is that it would take longer to do:

retfie
pop off stack, try to jump to last location
interrupt is seen
jump to interrupt handler.

if there are two interrupts pending, than it would take to simply jump back to
the top if the global interupt flag is till set after clearing it?

-Ada,

"Quitt, Walter" wrote:
{Quote hidden}

> {Original Message removed}

2000\04\10@160802 by Quitt, Walter

flavicon
face
Sure, if the interrupt servicing is SHORT.
If long, like mine, then I want to get back to other stuff ASAP.

Now, say, your interrupt source gives lotsa interrupts in a short time.
You "may" never return to your main code.
I've seen this, before.  Really, though, what happens is your
main line code does not get enough time and you seem to lose
system response in the non interrupt code.

The true question is: how much interrupt introduced latency are you
wiiling to accept?

In a "well behaved" system, you may well go back and see if any
other interupts are pending, before the ISR releases control.
It, most likely, won't make any difference.

But, what if you have lotsa interrupts?  Say a couple of timers
(asynchronous of each other and not a harmonic,) serial comms,
SPI, external digital or discrete interupt sources.  Oh ya, and
you have another interrupt source.  This is a real world example,
BTW, running on a 17C756.  The second interrupt routine is Timer0.
In this setup, I simply give up control after the highest priority
interrupt is serviced.  I don't waste time looking for other
interrupts, I get in and out quick.  Quick is like 6 instuctions.
That's a context switch, if you need to view it like that.
"I" find this approach very KISS.   And hence very stable.
I do not want to accept the (random?) latency introduced
by all the different combinations.  Sure, you can compute
the maximum time if all ints happened, but that is almost
a poor example of the longest latency.  That's because, it
will never happen that all happen at the same time.  Am I
making sense?

Basically, I want the interrupts to not take too long and
allow the main code to execute frequently.  This sorta splits
the available time so that all get the service they need.
This seems to maintain good system response.

Hope this clears it up a bit.

-W
{Original Message removed}

2000\04\10@170646 by Scott Dattalo

face
flavicon
face
On Mon, 10 Apr 2000, Quitt, Walter wrote:

> Sure, if the interrupt servicing is SHORT.

One little trick I and  others use to speed up the ISR is this:


       btfsc   intcon,peie
        btfss  pir1,rcif
         goto  check_next_int_in_list

If the interrupt is not enabled, then it can't be the source. So the first BTF
will skip the second and the next possible interrupt source is checked. If the
interrupt is enabled but the interrupt flag is cleared, then this interrupt
isn't the source.

Here's an example of the usart receive interrupt routine that's part of
usart-14.asm in gpsim's CVS repository:




       org     4
       ;; Interrupt
       ;;
       movwf   w_temp
       swapf   status,w
       movwf   status_temp

       bcf     status,rp0

       btfsc   intcon,peie
        btfss  pir1,rcif
         goto  int_done

;;;
       movf    fsr,w
       movwf   fsr_temp
       incf    rx_ptr,w
       andlw   0x0f
       movwf   rx_ptr
       addlw   rx_buffer
       movwf   fsr
       movf    rcreg,w
       movwf   indf
       movf    fsr_temp,w
       movwf   fsr

int_done:
       swapf   status_temp,w
       movwf   status
       swapf   w_temp,f
       swapf   w_temp,w
       retfie


In this case there's only one source that is checked (and if the 'goto int_done'
instruction is executed, there's a bug!). I could've removed the check for the
rx interrupt since it is the only possible source. However, if i were to add a
tx interrupt routine as well then I'd need the check.

Also, notice that the received data is copied to a buffer. This is another
useful technique to reduce the time spent in the interrupt routine. In other
words, the data that is received is not immediately processed, instead it's
copied to a (circular in this case) buffer.

Scott

2000\04\10@174214 by Quitt, Walter

flavicon
face
YUP!  You're absolutely right.  Common tricks
that (oldtimers) don't even mention, because
it is second nature (well almost.)

The first trick of not testing interrupts that
couldn't be can also be done with a mask which
would allow checking of several at once with
the xor instruction.  If one is found that
can not be: that's an exception that needs to
be handled with the traditional: "unexpected
interrupt encountered" error.

The second of moving an rx char into a buffer for
post processing is the a true "oldie but gooddie."
This one falls into the: "get in and out quickly"
mantra.

In short, an ISR needs to be quick and be able to
handle unexpected events in a meaningful way.

-W
{Original Message removed}

2000\04\11@085822 by Alok Dubey

flavicon
face
isnt there any bit that can be cleared to mask all interrupts?
Alok

{Quote hidden}

2000\04\11@092537 by Thomas C. Sefranek

face picon face
Alok Dubey wrote:

> isnt there any bit that can be cleared to mask all interrupts?

INTCON:GIE

>
> Alok
>

--
 *
 |  __O    Thomas C. Sefranek  KILLspamtcsKILLspamspamcmcorp.com
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41, 448.625 MHz

ARRL Instructor, Technical Specialist, VE Contact.
hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

2000\04\11@093800 by Alok Dubey

flavicon
face
thnx.. funny i dont even wrk on PICs..
alok


{Quote hidden}

2000\04\11@183314 by paulb

flavicon
face
Quitt, Walter wrote:

> Sure, if the interrupt servicing is SHORT.
> If long, like mine, then I want to get back to other stuff ASAP.

   I can see your point.  In fact, the method of interrupt handling can
and, probably should be, mixed.  It is reasonable to assume that
interrupts fall into approximately two categories; short, fast and
frequent ones, and long, slow and infrequent ones.

 By "mixed", I mean that your algorithm would be on entry, to check for
the fast, important interrupt first (of course this is what you always
do anyway).  If it is the source, then you service it and *exit*.

 If however, it is a slower interrupt, then you service that interrupt
and, because it is likely that *another* interrupt has occurred during
this time, you then loop back to the initial check for the fast
interrupt and either service that quickly and exit, or re-check for all
other interrupts, including the slow one just serviced.

 The general proposition being, fast interrupts exit, slow ones loop
back.

 If the slow interrupt is particularly slow, you may even wish to poll
for the fast interrupt regularly within that code, and service it as a
subroutine.  In which case you exit at the end anyway.

> Basically, I want the interrupts to not take too long and allow the
> main code to execute frequently.

 Of course, but this objective is achieved both by minimising entry
latency, and avoiding premature return-from-interrupt where a
particularly high probability exists that an interrupt is pending.
--
 Cheers,
       Paul B.

2000\04\16@083232 by Kieran Miller

flavicon
face
> This is why the global interupt is turned off when your interrupt routine is
> called, we don't want an endless loop.

Is this done in software or hardware?

Kieran

2000\04\16@090016 by Rob Zero

picon face
Software. Its done by writing to your option register.

Rob

----- Original Message -----
From: Kieran Miller <RemoveMEkiermillspamTakeThisOuTDTN.NTL.COM>
To: <PICLISTEraseMEspam.....MITVMA.MIT.EDU>
Sent: Sunday, April 16, 2000 7:03 AM
Subject: Re: Simultaneous Interrupts


> > This is why the global interupt is turned off when your interrupt
routine is
> > called, we don't want an endless loop.
>
> Is this done in software or hardware?
>
> Kieran
>

2000\04\16@092704 by Alan B Pearce

face picon face
> > This is why the global interupt is turned off when your interrupt
routine is
> > called, we don't want an endless loop.
>
> Is this done in software or hardware?

It is done by the PIC hardware when it goes into the interrupt routine.
You have to turn it on after you your initialisation code, but can turn it off
in software if you have a critical piece of code you do not want to interrupt.

Check the documentation on your PIC Chip for the INTCON register.

2000\04\16@093117 by Tom Handley

picon face
  Kieran, the GIE Bit is `Cleared' by `Hardware' when an interrupt occurs.
Depending on the interrupt, you need to `Clear' the interrupt `Flag' in
`Software'. When you exit the interrupt via "RETFIE", the `Hardware'
enables GIE.

  It sounds like you are not working with a data book/sheet. Get either
and ignore the Table of Contents, rather look at the Index for reference to
the details of interrupts. For some reason, Microchip's Table of Context in
their data books is fairly `useless' yet their Index is fairly `useful'...

  - Tom

At 01:03 PM 4/16/00 +0100, Kieran Miller wrote:
>> This is why the global interupt is turned off when your interrupt
routine is
>> called, we don't want an endless loop.
>
>Is this done in software or hardware?
>
>Kieran


------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

2000\04\16@093120 by Scott Dattalo

face
flavicon
face
On Sun, 16 Apr 2000, Rob Zero wrote:

> Software. Its done by writing to your option register.
>
> Rob

Rob,

It's actually hardware. When an interrupt occurs, the GIE bit in the option
register is cleared automatically by hardware. If it weren't, then an infinite
loop would occur everytime an interrupt happened. That's bad. Now if you wish to
inhibit interrupts, then of course you can clear GIE with software.

When the interrupt routine processing is completed, then control is returned via
an RETFIE. This a return instruction that will re-enable interrupts by setting
GIE.

Scott
{Quote hidden}

2000\04\16@104532 by Rob Zero

picon face
----- Original Message -----
From: Alan B Pearce <RemoveMEA.B.Pearcespam_OUTspamKILLspamRL.AC.UK>
To: <RemoveMEPICLISTTakeThisOuTspamspamMITVMA.MIT.EDU>
Sent: Sunday, April 16, 2000 8:24 AM
Subject: Re: Simultaneous Interrupts


> > > This is why the global interupt is turned off when your interrupt
> routine is
> > > called, we don't want an endless loop.
> >
> > Is this done in software or hardware?
>
> It is done by the PIC hardware when it goes into the interrupt routine.
> You have to turn it on after you your initialisation code, but can turn it
off
> in software if you have a critical piece of code you do not want to
interrupt.
>
> Check the documentation on your PIC Chip for the INTCON register.


Oops.. Yes, this is right.. Sorry for the misinformation! I hadnt had my
morning coffee yet! ;)

Rob

2000\04\16@105236 by Rob Zero

picon face
BTW, I have a question. Is it possible to run multiple pieces of code at the
same time? I guess this would be called multi-thread, and would need some
sort of low level OS to prioritize the code modules and the interrupts.

I guess what Im saying is, Int RA0, and you get an interrupt on RB0, you run
the block of code that corresponds to RA0 interrupt, then, BEFORE you get
through with processing the code, you get another interrupt on RB1, is there
any routines that could interleave the processing of the two blocks of code
so it seems that they continue simultaneously?

I realize this is probably just asking for memory overwrites and such, but
has anyone tried anything like this?

Rob

{Original Message removed}

2000\04\16@105443 by Rob Zero

picon face
----- Original Message -----
From: Scott Dattalo <EraseMEscottspamspamspamBeGoneDATTALO.COM>
To: <RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Sunday, April 16, 2000 8:30 AM
Subject: Re: Simultaneous Interrupts


> On Sun, 16 Apr 2000, Rob Zero wrote:
>
> > Software. Its done by writing to your option register.
> >
> > Rob
>
> Rob,
>
> It's actually hardware. When an interrupt occurs, the GIE bit in the
option
> register is cleared automatically by hardware. If it weren't, then an
infinite
> loop would occur everytime an interrupt happened. That's bad. Now if you
wish to
> inhibit interrupts, then of course you can clear GIE with software.

Okay, this is how I have been told to do it is to inhibit further interrupts
until the code processing routine for the first interrupt is completed, then
when you loop back to the main routine you re-enable interrupts and begin
processing again.. I guess its easier to follow them this way, but perhaps
it isnt the *best* way either..
Easier to debug anyhow! ;)

Thanks!

Rob

2000\04\16@130440 by Dan Michaels

flavicon
face
Rob wrote:
>BTW, I have a question. Is it possible to run multiple pieces of code at the
>same time? I guess this would be called multi-thread, and would need some
>sort of low level OS to prioritize the code modules and the interrupts.
>

This has probably been dealt with in the past, but does anyone have
a "really simple" multitasker for PIC?

Requiring, say, 256 code bytes and 32 ram bytes, limited to 6 tasks
or so. Minimal wizzbangs, basic stuff.

2000\04\16@132548 by Andrew E. Kalman

picon face
Re:
>This has probably been dealt with in the past, but does anyone have
>a "really simple" multitasker for PIC?
>
>Requiring, say, 256 code bytes and 32 ram bytes, limited to 6 tasks
>or so. Minimal wizzbangs, basic stuff.

In C or Assembly? If in C, which compiler are you using?


______________________________________
 Andrew E. Kalman, Ph.D.   aekSTOPspamspamspam_OUTnetcom.com

2000\04\16@135321 by Dan Michaels

flavicon
face
Andrew wrote:
>Re:
>>This has probably been dealt with in the past, but does anyone have
>>a "really simple" multitasker for PIC?
>>
>>Requiring, say, 256 code bytes and 32 ram bytes, limited to 6 tasks
>>or so. Minimal wizzbangs, basic stuff.
>
>In C or Assembly? If in C, which compiler are you using?
>__________________________________
>  Andrew E. Kalman, Ph.D.   spamBeGoneaekSTOPspamspamEraseMEnetcom.com
>

Assembly.

2000\04\16@140152 by Rob Zero

picon face
I could probably read either fairly easy, personally.
But, perhaps for the sake of the list, asm would be better.

Rob

{Original Message removed}

2000\04\16@182224 by Andrew E. Kalman

picon face
Re:

>I could probably read either fairly easy, personally.
>But, perhaps for the sake of the list, asm would be better.

and
>>>This has probably been dealt with in the past, but does anyone have
>>>a "really simple" multitasker for PIC?
>>>
>>>Requiring, say, 256 code bytes and 32 ram bytes, limited to 6 tasks
>>>or so. Minimal wizzbangs, basic stuff.
>>
>>In C or Assembly? If in C, which compiler are you using?
>Assembly.


The multitasker I have in mind is written in C ...  on a PIC16, it requires
318 instructions, and 6 tasks would require 24 bytes of RAM. Some extra RAM
is required for function parameters, etc. -- that's very compiler-specific.

It's a cooperative, _priority-based_ multitasker, and does not require
interrupts.


______________________________________
 Andrew E. Kalman, Ph.D.   KILLspamaekspamBeGonespamnetcom.com

2000\04\16@184925 by paulb

flavicon
face
Scott Dattalo wrote:

> It's actually hardware. When an interrupt occurs, the GIE bit in the
> option register is cleared automatically by hardware. If it weren't,
> then an infinite loop would occur everytime an interrupt happened.

 So this is how it is in virtually every (micro) processor which
supports interrupts.  It really can't be any other way.  Whilst you are
in the service routine, you are protected from further interrupts and
can choose to look at one interrupt at a time or service others, as
recently discussed.

 On a chip such as the PIC with no context saving facility, trying to
permit an interrupt service routine to be interrupted itself is a bit
foolish and in particular, misguided.  The latter firstly because you
should be aiming by design to keep interrupts short so there is no
*need* to interrupt them; a longer procedure should generally be done in
mainline code by means of a flag.

 And if you really *do* need to consider another interrupt source in
mid-interrupt, then it can be conveniently polled and serviced as a
subroutine, so that the context at that point is stable.

> When the interrupt routine processing is completed, then control is
> returned via an RETFIE.  This a return instruction that will re-enable
> interrupts by setting GIE.

 Since the PIC has no context save, that is *all* the RETFIE does.
Consequently, it can be used in a novel manner; if your initialisation
is performed in a subroutine, using a RETFIE instead of a RETLW will
enable GIE for you as the last step - almost certainly what you would
want.
--
 Cheers,
       Paul B.

2000\04\17@111624 by jamesnewton

face picon face
techref.massmind.org/microchip/swstmt
or
techref.massming.org/techref/default.asp?url=microchip/swstmt
for the non-js'ers

---
James Newton EraseMEjamesnewtonspamEraseMEgeocities.com 1-619-652-0593
http://techref.massmind.org NEW! FINALLY A REAL NAME!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)


{Original Message removed}

2000\04\17@114943 by Dan Michaels

flavicon
face
>
>The multitasker I have in mind is written in C ...  on a PIC16, it requires
>318 instructions, and 6 tasks would require 24 bytes of RAM. Some extra RAM
>is required for function parameters, etc. -- that's very compiler-specific.
>
>It's a cooperative, _priority-based_ multitasker, and does not require
>interrupts.
>______________________________________
>  Andrew E. Kalman, Ph.D.   @spam@aek@spam@spamspam_OUTnetcom.com
>

Any more info available? Links? etc?

2000\04\17@121223 by Andrew E. Kalman
picon face
>>
>>The multitasker I have in mind is written in C ...  on a PIC16, it requires
>>318 instructions, and 6 tasks would require 24 bytes of RAM. Some extra RAM
>>is required for function parameters, etc. -- that's very compiler-specific.
>>
>>It's a cooperative, _priority-based_ multitasker, and does not require
>>interrupts.
>>______________________________________
>>  Andrew E. Kalman, Ph.D.   spamBeGoneaekspamKILLspamnetcom.com
>>
>
>Any more info available? Links? etc?

Check out http://www.pumpkininc.com for now ... with the release of
Hi-Tech's PICC Lite we're looking at releasing a freeware version for the
'F84 parts, too.



______________________________________
 Andrew E. Kalman, Ph.D.   .....aekspam_OUTspamnetcom.com

2000\04\17@121643 by Don Hyde

flavicon
face
A PIC multithread OS can be done if the individual threads are not allowed
to do any call's and return's.  For each thread, you need to store the same
stuff that the interrupts save (w, status, PCLATH, etc.)  Since most PIC's
have no way of reading the stack (except for the 18Cxxx), there is no way
for the OS to save the call/return history of individual tasks.  This
limitation makes PIC multitasking, well..., pretty much useless.

Much the same end effect can often be accomplished by writing code that
implements multiple state machines, in which case you may be able to get by
with as little as one byte of state per machine.  You might even manage to
implement something resembling preemptibility.

> {Original Message removed}

2000\04\17@132618 by Quitt, Walter

flavicon
face
It's processor specific.

In the 17s:
"When an interrupt is reponded to, the GLINTD bit is automatically
set to disable any further interrupts,"

In 16C5X:
The OPTION reg does not disable global interrupts.
In fact, I can't find mention of global interrupts
in the Data Sheet book.  You can only turn Timer0
ints on and off.

In the 16C71X:
The GIE (Glable Interrupt Enable) bit is handled by the INTCON reg.
"When an interrupt is responded to, the GIE  bit is cleared to
disable any further interrupt, "

That's three somewhat different examples.
So in the 17s and some 16s it is done in Hardware.

Walt...

{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...