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

Truncated match.
PICList Thread
'Interrupt inside an interrupt?'
1998\03\12@123839 by James & Ili

flavicon
face
Greetings,
       I'm in the middle of trying to make some code to do RS232 reception
and have a question. My idea is to have an interrupt on the start
bit, then load the timer with some value and wait for it to time out
and generate another interrupt at which time I can check the data
line again to get the bit in. Then reset the timer with another
value.. etc... Is it possible to have one interrupt more or less
inside another interrupt? If so is there anything special that needs
to be done?
       Thanks for your time!
James

1998\03\12@130610 by Stevenson, Brad

flavicon
face
I don't think you can do this on a PIC because there is only one
interrupt vector. You could do this on a Motorola (for example), but
even then, I wouldn't recomend it. Getting interrupted from an interrupt
can cause all kinds of problems (stack, endless loops, memory
corruption, etc). Recursive interrupt functions are a nightmare.

Having said that, in your application, maybe you could start the
interrupt the way you suggest, then load your timer, and poll the timer
status flag to see if it has expired.

Brad Stevenson, CET
The DPL Group - Telecom Techniques
506-635-1055 or 1-800-561-8880
http://www.dpl.ca

> {Original Message removed}

1998\03\12@131614 by Marco DI LEO

flavicon
face
James & Ili wrote:
> My idea is to have an interrupt on the start
> bit, then load the timer with some value and wait for it to time out
> and generate another interrupt at which time I can check the data
> line again to get the bit in. Then reset the timer with another
> value.. etc... Is it possible to have one interrupt more or less
> inside another interrupt? If so is there anything special that needs
> to be done?

Strange... I am taking the same approach for the same problem...
I don't think that you have to worry about an interrupt inside an
interrupt.
Just try to do this:
1. set the interrupt on the start bit and wait (do your main task)
2. when you receive the interrupt on pin change disable it, set the
timer interrupt to expire in the middle of the first bit and return to
your main
3. when the timer expire, sample the bit value, set the timer interrupt
for the next bit and, again, return from interrupt
4. repeat step 3 for each bit you expect
5. goto step 1

As you can see you don't have an int in a int but just a sequence of
interrupt one after the other.

Good luck
  Marco

----
Marco DI LEO                  email: spam_OUTm.dileoTakeThisOuTspamsistinf.it
Sistemi Informativi S.p.A.    tel:   +39 6 50292 300
V. Elio Vittorini, 129        fax:   +39 6 5015991
I-00144 Roma
Italy

1998\03\12@134220 by Danjel McGougan

flavicon
face
> Greetings,
>         I'm in the middle of trying to make some code to do RS232 reception
> and have a question. My idea is to have an interrupt on the start
> bit, then load the timer with some value and wait for it to time out
> and generate another interrupt at which time I can check the data
> line again to get the bit in. Then reset the timer with another
> value.. etc... Is it possible to have one interrupt more or less
> inside another interrupt? If so is there anything special that needs
> to be done?
>         Thanks for your time!
> James
>

The normal way to do interrupt driven RS232 reception is to have a
periodical interrupt running at 2 or 3 times the baud rate. The
interrupt samples the RX line and as soon as the start bit is
detected the interrupt changes the period to 1.25 resp. 4/3 of the
baud period. The interrupt can now sample the first databit and
change the period to the baud rate, and sample the rest of the
databits. After the last databit is sampled, change back to 2 or 3
times the baud rate and wait for the next databit.

Regards,
Danjel McGougan.

1998\03\12@150148 by DREITEK

picon face
In a message dated 98-03-12 13:18:02 EST, you write:

You certainly can do this on a PIC!  At the start of the interupt routine you
simply check the INTCON reg to see what generated the interupt and jump
accordingly.

Then Motorolla parts have different kinds of interupts, thus the different
vectors.  One vector for an IRQ and another for the NMI another for SWI etc.
It still won't tell you what device generated the interupt, You have to resort
to polling the devices inside the interupt routine.

Dave Duley

<<
I don't think you can do this on a PIC because there is only one
interrupt vector. You could do this on a Motorola (for example), but
even then, I wouldn't recomend it. Getting interrupted from an interrupt
can cause all kinds of problems (stack, endless loops, memory
corruption, etc). Recursive interrupt functions are a nightmare.

Having said that, in your application, maybe you could start the
interrupt the way you suggest, then load your timer, and poll the timer
status flag to see if it has expired.

Brad Stevenson, CET
The DPL Group - Telecom Techniques
506-635-1055 or 1-800-561-8880
http://www.dpl.ca >>

1998\03\12@152155 by Stevenson, Brad

flavicon
face
{Quote hidden}

1998\03\12@165615 by Danjel McGougan

flavicon
face
> From:          DREITEK <.....DREITEKKILLspamspam@spam@AOL.COM>
> In a message dated 98-03-12 13:18:02 EST, you write:
>
> You certainly can do this on a PIC!  At the start of the interupt routine you
> simply check the INTCON reg to see what generated the interupt and jump
> accordingly.
>
> Then Motorolla parts have different kinds of interupts, thus the different
> vectors.  One vector for an IRQ and another for the NMI another for SWI etc.
> It still won't tell you what device generated the interupt, You have to resort
> to polling the devices inside the interupt routine.
>
> Dave Duley
>

The difference between Motorola (at least the 68000-series) and PIC
is that a Motorola processor has different priorities on the
interrupts. One interrupt can interrupt another so to speak. On a PIC
only one interrupt at a time is allowed to execute. If an interrupt
is triggered when the PIC is already in the interrupt service routine
the PIC waits for the retfie instruction before this interrupt is
processed. There is a way around this of you enable the global
interrupt bit at the beginning of the ISR, but this leads to code
that is very hard to debug and there can be effects which are hard to
predict.

Danjel McGougan

1998\03\12@184853 by Harold Hallikainen

picon face
On Thu, 12 Mar 1998 13:47:06 -0400 "Stevenson, Brad" <STEVENSBspamKILLspamDPL.CA>
writes:
>I don't think you can do this on a PIC because there is only one
>interrupt vector. You could do this on a Motorola (for example), but
>even then, I wouldn't recomend it. Getting interrupted from an
>interrupt
>can cause all kinds of problems (stack, endless loops, memory
>corruption, etc). Recursive interrupt functions are a nightmare.


       I agree that interrupts interrupting interrupts should be
discouraged.  I don't think there's a problem with the single vector
though.  When an interrupt is generated, you just poll the various
devices that are capable of generating the interrupt, then go deal with
it.  The multiple vector interrupt mechanisms just save you from having
to do the polling.  I recall a trick of using a binary encoder that is
"dropped on the bus" when the interrupt vector address is called on
single interrupt processors.  The encoder then provided a number that the
processor "thought" was the interrupt vector, so it jumped to it.  At
that address was a JMP instruction to the ISR.
       Seems to me that the real problem with nested interrupts on the
PIC is lack of stack space for return adddresses and the lack of stack
access for data.  You have to save registers when the interrupt is called
(if the interrupt uses those registers).  With the PIC, these are
typically stored in fixed RAM locations.  A second interrupt would
overwrite the first entries, messing up the return from the first
interrupt.
       My early programming was on the 6800 or 6802 (in fact, I spent
the morning modifying 6802 code to deal with year 2000).  It had two
interrupts: IRQ and NMI.  Both pushed all registers on the stack.  It was
interesting to me when the 6809 came out.  It had a "fast IRQ" that, as I
recall, pushed only the flags and the return address.  It was up to the
user to push anything else on the stack.  Always seemed to me that the
number of cycles necessary to get the push instruction and actually do
the push for even a couple registers would be more than just
automatically pushing them all.  Never ended up doing any 6809 stuff
though.
       So... yes, you can do nested interrupts on the PIC by enabling
the GIE flag inside the ISR.  But...  it's gonna be rough!

Harold



_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\03\12@185513 by James & Ili

flavicon
face
Danjel,
       This sounds like a great solution.
       If I understand you, then you would use the timer to generate the
interrupt
and just change the value that's loaded in the timer depending on the
mode you're in
i.e. at 9600 baud
Wait for start bit mode. clear timer ( set to 256 counts)
check pin when timer overflows and triggers interrupt

Sample signal mode. set timer to 152
check pin when timer overflows
I will try to implement it now.

       Thanks a bunch !!!
P.S. Is there anything I need to do when I put a value into the
timer? I know I need to
clear the interrupt flag before exiting the ISR.

On Thursday, March 12, 1998 1:28 PM, Danjel McGougan
[SMTP:.....danmc458KILLspamspam.....STUDENT.LIU.SE] wrote:
{Quote hidden}

1998\03\12@185516 by James & Ili

flavicon
face
Marco,
       Did you read the post by Danjel ? It looks like a simpler way to go.
James

On Thursday, March 12, 1998 11:52 AM, Marco DI LEO
[SMTP:EraseMEm.dileospam_OUTspamTakeThisOuTSISTINF.IT] wrote:
{Quote hidden}

1998\03\12@202547 by Justin Crooks

flavicon
face
An interrupt simply clears INTCON,GIE.  If you code in PIC assembler, you
could try setting the bit inside the interrupt.  Then another interrupt
could be generated, but it would just go back to your interrupt vector.
Setting a flag to keep track of "interrupt depth" and branching to
appropriate interrupt routine might theoretically work, but I think it
would be poor practice.  I like Marco's general idea better.

----------
> From: James & Ili <@spam@jandiKILLspamspamMPSI.NET>
> To: KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
> Subject: Re: Interrupt inside an interrupt?
> Date: Thursday, March 12, 1998 4:26 PM
>
> Marco,
>         Did you read the post by Danjel ? It looks like a simpler way to
go.
{Quote hidden}

1998\03\12@203208 by DREITEK

picon face
In a message dated 98-03-12 17:01:32 EST, you write:

<<
The difference between Motorola (at least the 68000-series) and PIC
is that a Motorola processor has different priorities on the
interrupts. One interrupt can interrupt another so to speak. On a PIC
only one interrupt at a time is allowed to execute. If an interrupt
is triggered when the PIC is already in the interrupt service routine
the PIC waits for the retfie instruction before this interrupt is
processed. There is a way around this of you enable the global
interrupt bit at the beginning of the ISR, but this leads to code
that is very hard to debug and there can be effects which are hard to
predict.

Danjel McGougan >>

Perhaps so, but the question was weather it could be done, not if it should be
done!!

Dave Duley

1998\03\12@205521 by Mike Keitz

picon face
On Thu, 12 Mar 1998 17:24:33 -0600 James & Ili <TakeThisOuTjandiEraseMEspamspam_OUTMPSI.NET> writes:
>Danjel,
>        This sounds like a great solution.
>        If I understand you, then you would use the timer to generate
>the
>interrupt
>and just change the value that's loaded in the timer depending on the
>mode you're in
>i.e. at 9600 baud
>Wait for start bit mode. clear timer ( set to 256 counts)
>check pin when timer overflows and triggers interrupt
>
>Sample signal mode. set timer to 152
>check pin when timer overflows
>I will try to implement it now.
>
>        Thanks a bunch !!!
>P.S. Is there anything I need to do when I put a value into the
>timer?

Remember the timer counts *up*, so the value you write should be 256-N
where N is the number of counts you want before the next interrupt.  You
need to be sure the TOIF flag is clear after writing the timer and before
enabling the timer interrupt.  Also, writing the timer stops it for 2 PIC
instruction cycles and resets the prescaler (if enabled).  For
consistent, exact timing, always write the timer at the same point in
(same number of cycles into) the ISR.

Putting a debug feature into your ISR that pulses a pin right after a
sample of the data line is taken can be very helpful.  Observed on a dual
trace scope, the sample pulses should occur very near the center of the
incoming data bits.


_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\03\13@034021 by Marco DI LEO

flavicon
face
James & Ili wrote:
>
> Marco,
>         Did you read the post by Danjel ? It looks like a simpler way to go.
> James

It appear to be the same approach except for the start bit detection.

The Danjel method detect the start bit "[using] a periodical interrupt
running at 2 or 3 times the baud rate" in witch you "samples the RX
line".
I just try to detect the start bit using an interrupt on the start bit
edge.
The rest of both methods is essentially the same.

There are pros and cons in both approaches:
Danjel method pros: you can use any pin as RX line because you sample it
using a bit test instruction. cons: if there is no traffic on the line
you still have 3 int per bit time interrupting you main task.
My method pros: your main task is only interrupted when a transmission
occur. If transmission are rare you can save lot of compute power. cons:
you have to use specific pin for the RX line. On the 16C84 you can
choose between the RB0/INT and RA4/T0CK1. Use the latter setting the
counter to external clock, no prescaler and preload it to 0xFF. At the
the first edge the counter roll to 0x00 thus generating an int. The
RB0/INT method is easier but the RA4/T0CK1 saves you an interrupt source
because you only use the timer/counter for bit timing/start bit
detection, having the RB0/INT free for other purposes.

The choice of the method used to detect the start bit depends completely
on your application and on the timing of your main task.

Marco

----
Marco DI LEO                  email: RemoveMEm.dileospamTakeThisOuTsistinf.it
Sistemi Informativi S.p.A.    tel:   +39 6 50292 300
V. Elio Vittorini, 129        fax:   +39 6 5015991
I-00144 Roma
Italy

1998\03\13@132231 by James & Ili

flavicon
face
Marco,
       I can see the advantages of your method, that was my original idea.
Use interrupts to detect incoming pulse then switch to timer overflow
interrupts to sample data stream. My problem is I would be tied to a
special pin and the configuration that I am using won't allow that.
So I used Danjel's method. I wrapped it up last night about midnight.
Good news is it works great, bad news is it takes up lots of
processor cycles. Fortunately in this application I have plenty to
spare. The PIC is only taking data in,  and sending it to a DAC via
I2C protocol. I think it would be pretty easy to modify the code to
work either way.
       James

On Friday, March 13, 1998 2:39 AM, Marco DI LEO
[SMTP:m.dileoEraseMEspam.....SISTINF.IT] wrote:
{Quote hidden}

1998\03\13@184143 by john pearson

flavicon
face
At 11:39 AM 3/12/98 -0600, you wrote:
>Greetings,
>        I'm in the middle of trying to make some code to do RS232 reception
>and have a question. My idea is to have an interrupt on the start
>bit, then load the timer with some value and wait for it to time out
>and generate another interrupt at which time I can check the data
>line again to get the bit in. Then reset the timer with another
>value.. etc... Is it possible to have one interrupt more or less
>inside another interrupt? If so is there anything special that needs
>to be done?
>        Thanks for your time!
>James
>
>

James:

Do yourself a favor: use interupts only as a last resort. They can be real
tricky sometimes.

1998\03\13@184811 by DREITEK

picon face
In a message dated 98-03-13 18:42:55 EST, you write:

<<
James:

Do yourself a favor: use interupts only as a last resort. They can be real
tricky sometimes.

 >>
Hello!
I would disagree with this statement.  If used properly interupts can simplify
code remarkably.

Dave Duley

1998\03\13@195236 by Eric Naus

picon face
Hi All,

I've tried to follow this thread and it looks like he's trying to use an
interrupt routine
to read serial information. I might be wrong??

I've used a similar interrupt routine to read in 5 bytes of info to control
7 Rc-servos.

If you're interested it's located at my homepage:

http://webhome.idirect.com/~bine

Look under Robot Project heading.

Just adding my 2 cents worth.

Bye for now

Eric

1998\03\13@235755 by paulb

flavicon
face
Danjel McGougan wrote:

> The normal way to do interrupt driven RS232 reception is to have a
> periodical interrupt running at 2 or 3 times the baud rate.

> The interrupt samples the RX line and as soon as the start bit is
> detected the interrupt changes the period to 1.25 or 4/3 respectively,
> of the baud period.

 Not quite right!  For 3X sampling, it stays at three times, for 2X it
changes to four times the bit-rate until it has verified the *start*
bit, then swaps to the actual bit-rate for the data bits *and stop*.

 This sets the sample time within the middle third (or half) of each
data bit, and suppresses false starts.  Note that when a false start is
found, or a stop is received, it is ready to sample again 1/3 or ¸ bit
time later, so a false start will not cause a true start to be missed,
and a too-high bit-rate causing short stop bits can be tolerated.

 If you were really picky, you could use an interrupt-on-change to
detect the start bit, and use timer interrupts thereafter.  This is
obviously what James originally intended, but there is absolutely no
requirement for nested interrupts here.

 The timer is pre-loaded and its IRQ is cleared so that it *cannot*
interrupt again for a pre-set interval, much more than enough to ensure
that the current interrupt service completes.  Next, the timer IRQ is
enabled; superfluous if the current interrupt is a time-out of course,
and then the IRQ routine exits.

 When however the stop bit has been checked, the timer IRQ can be
disabled in favour of the interrupt-on-change.  If the latter trips
immediately (during the current interrupt service), then its interrupt
will follow the interrupt return.  Due care has to be taken as has been
discussed before, with interrupt-on-change functions, so perhaps I
should have spoken about the RB0/INT pin instead.

 The reason for using an interrupt to detect the initial start bit is
simply efficiency; no data = no interrupts at all.  OTOH, a continuous
3X bitrate interrupt polling the port for start bits is simpler to code,
and suits continuous *or multiple* data streams.

 If the latter, there is in fact no alteration of the timer increment
for which a suitable crystal is usually chosen.  Data (and stop) bits
are read each three interrupts using a counter, but alternate data
streams may be sampled on different interrupts.  Note previous
references in the PICLIST to "vertical counters" for this purpose; four
or eight ports may be serviced very efficiently.

 Well *that's* my say!

 Cheers,
       Paul B.

1998\03\14@085313 by n/a

flavicon
face
DREITEK wrote:
>
> In a message dated 98-03-13 18:42:55 EST, you write:
>
> <<
>  James:
>
>  Do yourself a favor: use interupts only as a last resort. They can be real
>  tricky sometimes.
>
> >>

> Hello!
> I would disagree with this statement.  If used properly interupts can simplify
> code remarkably.

It really depends on how you view things, I too like using interrupts. I
had
considered polling a pain. But I've learned when they're useful and when
they're
a pain. The RS232 example is a border line case, but I think that if the
interrupts come too fast for interrupt driven code, what chance do they
have
with polled code? There is a place for each.

BTW I live in an interrupt driven world and ... excuse me a minute...

;-}

--
Neil Cherry     http://home.att.net/~ncherry    EraseMEncherryspamworldnet.att.net

1998\03\14@111106 by john pearson

flavicon
face
At 08:43 AM 3/14/98 -0500, you wrote:
>DREITEK wrote:
>>
>> In a message dated 98-03-13 18:42:55 EST, you write:
>>
>> <<
>>  James:
>>
>>  Do yourself a favor: use interupts only as a last resort. They can be real
>>  tricky sometimes.
>>
>> >>
>
>> Hello!
>> I would disagree with this statement.  If used properly interupts can
simplify
{Quote hidden}

I would like to make a small wager. I bet that James and Ilis' first
"working" iteration will not involve interupts. It won't be "simple" code,
or "compact" code. But it will "work".
Any takers?
John

1998\03\14@112340 by Morgan Olsson

picon face
At 18:47 1998-03-13 EST, you wrote:
>In a message dated 98-03-13 18:42:55 EST, you write:
>
><<
> James:
>
> Do yourself a favor: use interupts only as a last resort. They can be real
> tricky sometimes.
>
>  >>
>Hello!
>I would disagree with this statement.  If used properly interupts can
simplify
>code remarkably.
>
>Dave Duley
>
Right: *base* your programs on interrupts to make life easier.
/Morgan
/  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
\  RemoveMEmrtspam_OUTspamKILLspaminame.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /

1998\03\15@183227 by Ron Kreymborg

flavicon
face
Microchip Application Note AN555 gives the code and a detailed account of
interfacing RS232 to a 16CXX chip using the RA4/T0CKI method suggested
below; ie preload 0xFF to detect start, check in initial interrrupt that
start was not noise, then reprogram the timer to interrupt at half or
quarter bit times to decode the byte.

Ron

On Fri, 13 Mar 1998, Marco DI LEO wrote:

{Quote hidden}

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ron Kreymborg                   Computer Systems Manager
Monash University               CRC for Southern Hemisphere Meteorology
Wellington Road
Clayton, VIC 3168               Phone     : 061-3-9905-9671
Australia                       Fax       : 061-3-9905-9689
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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