Searching \ for '[PIC]: F877 UART in ISR' 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/devices.htm?key=877
Search entire site for: 'F877 UART in ISR'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: F877 UART in ISR'
2001\07\05@001314 by Greg Hartung

picon face
Resend with proper header:

  I have moved a call of a PUTCHAR routine from the main code to within the
ISR and now it scrambles data.  I am polling TXSTA:TXMT to wait to send the
next character.  Any ideas?  Thanks!

UART_SendChar
       bsf     STATUS,RP0
       btfss   TXSTA,1
        goto   UART_SendChar
       bcf     STATUS,RP0
       movfw   UART_Tx
       movwf   TXREG
       return

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\07\05@082738 by Olin Lathrop

face picon face
>    I have moved a call of a PUTCHAR routine from the main code to within
the
> ISR and now it scrambles data.  I am polling TXSTA:TXMT to wait to send
the
> next character.  Any ideas?  Thanks!

First, this uses an additional stack location in the interrupt, which is
therefore not useable in the rest of the code.  I try to avoid calls as much
as possible in the interrupt routine.

> UART_SendChar
>         bsf     STATUS,RP0
>         btfss   TXSTA,1
>          goto   UART_SendChar
>         bcf     STATUS,RP0
>         movfw   UART_Tx
>         movwf   TXREG
>         return

USE COMMENTS!  I see a bug and possibly a misconception, which you probably
would have seen too if you forced yourself to describe the intent of each
line.  Good comments don't waste time, they save time.  If you don't care
about your code enough to document it, then why should I bother with it?


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2001\07\05@111634 by Hartung, Greg

flavicon
face
UART_SendChar
       bsf     STATUS,RP0              ; switch to bank 1
       btfss   TXSTA,1                 ; check TXMT flag and loop if
        goto   UART_SendChar           ; still not done sending the last character
       bcf     STATUS,RP0              ; switch back to bank 0
       movfw   UART_Tx                 ; put transmit value
       movwf   TXREG                   ; in transfer register
       return                          ; return from UART_SendChar


{Original Message removed}

2001\07\05@125818 by Hartung, Greg

flavicon
face
  Sorry, Olin, I meant TRMT, not TXMT.  Anyway, I don't see any bugs.
Should I be disabling TXEN and reenabling after loading TXREG?
  What's wrong with using the stack with calls from within an ISR?
  Thanks for the help!

{Original Message removed}

2001\07\05@161320 by Olin Lathrop

face picon face
> UART_SendChar
>         bsf     STATUS,RP0              ; switch to bank 1

This only switches to either bank 1 or 3.  If you were previosly in banks 2
or 3 then this won't work.

>         btfss   TXSTA,1                 ; check TXMT flag and loop if

Use the mnemonics in the include file instead of hard coded bit numbers.  It
makes your code more readable, reduces that chance of getting the bit number
wrong, and saves everyone else time looking it up to make sure you did get
the bit number right.

>          goto   UART_SendChar           ; still not done sending the last
character

Why do you want to wait until the last character is sent to send the next
one?  Do you really need to make sure the previous character has gone out or
are you just trying to make sure the UART is ready to receive the next
character?  If so, you should be checking the TXIF bit in PIR1.

>         bcf     STATUS,RP0              ; switch back to bank 0

Or bank 2, depending on RP1.

>         movfw   UART_Tx                 ; put transmit value
>         movwf   TXREG                   ; in transfer register
>         return                          ; return from UART_SendChar

Overall, I really don't like calling this routine from the interrupt
handler.  First, it effectively reduces the available call stack size, at
least for any code that runs with interrupts enabled.  Second, this is such
simple logic that it would only take a few instructions to do in line.  I
would make a macro out of it if I wanted to use this code once in the
subroutine and once in the interrupt routine.  Third and most importantly,
doing a busy wait in an interrupt routine is usually a very bad thing.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2001\07\05@161326 by Olin Lathrop

face picon face
>    Sorry, Olin, I meant TRMT, not TXMT.

Even more reason to use the mnemonics instead of fixed bit numbers.
Actually I didn't even catch that.  I was thinking TRMT.

> Anyway, I don't see any bugs.

See my other post.

> Should I be disabling TXEN and reenabling after loading TXREG?

No.

>    What's wrong with using the stack with calls from within an ISR?

It's not inherently wrong, but it could be a lurking gotcha.  Your main code
has a certain call tree, which hopefully requires some finite maximum number
of stack locations.  If interrupts are enabled everywhere, then the stack
location used by the interrupt routine must be left available at all times.
If the interrupt routine calls other subroutines, then ALL these additional
call stack locations must be left available whenever interrupts are enabled.
If your interrupt routine calls one subroutine, then it uses 2 call stack
locations.  Your processor (16F877) 8 stack locations, so your main code can
now use no more than 6.  If that's not a problem, then it's OK.  But you
should be aware of the cost of calling subroutines during an interrupt every
time you do it.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\07\05@183948 by Hartung, Greg

flavicon
face
  Well, the nature of my app is that everything is scheduled, so the main
routine is just loop:goto loop.  I should only have to worry about nested or
recursive calls that might exceed the stack depth, right?  8 certainly isn't
much to work with, I agree with that!  Fortunately, my ISR just checks the
time vs. each thing that might need to be done and calls them if there's a
match, one at a time.  I pretty much invented my own scheduling routine.
Couldn't find zippo on the subject @ Microchip.  Suggestions eagerly
accepted.

{Original Message removed}

2001\07\06@090604 by Olin Lathrop

face picon face
>    Well, the nature of my app is that everything is scheduled, so the main
> routine is just loop:goto loop.
> ...
> I pretty much invented my own scheduling routine.
> Couldn't find zippo on the subject @ Microchip.  Suggestions eagerly
> accepted.

I like to use a different approach.  The interrupt routine handles anything
that is time-critical.  The main code handles the less time critical tasks
by running in a loop looking for any of a list of things that need service.
Quite often the interrupt routine handles some immediate issue, then sets a
flag for the main routine to handle the rest of the issue when it gets
around to it.  For example, the interrupt routine might service the UART
receive condition and put the incoming byte into a FIFO.  Them main code
looks for the FIFO being non-empty and handles an input byte when there is
one.  Meanwhile more byte can come in from the UART and the interrupt is
free to service other high priority issues.

For an example, see HAL_MAIN.ASPIC at http://www.embedinc.com/pic/hal.htm.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, KILLspamolinKILLspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\06@115034 by Jeff DeMaagd

flavicon
face
----- Original Message -----
From: Olin Lathrop <RemoveMEolin_piclistTakeThisOuTspamEMBEDINC.COM>


> >    Well, the nature of my app is that everything is scheduled, so the
main
> > routine is just loop:goto loop.
> > ...
> > I pretty much invented my own scheduling routine.
> > Couldn't find zippo on the subject @ Microchip.  Suggestions eagerly
> > accepted.
>
> I like to use a different approach.  The interrupt routine handles
anything
> that is time-critical.  The main code handles the less time critical tasks
> by running in a loop looking for any of a list of things that need
service.
> Quite often the interrupt routine handles some immediate issue, then sets
a
[....]
> For an example, see HAL_MAIN.ASPIC at http://www.embedinc.com/pic/hal.htm.

I have a different concern in the general topic.  I am writing a chip where
there may be as many as four interrupt sources and I am concerned that I
might overflow the hardware stack when I have a few nested subroutines in
the ISR and in the main program.  I am seeing an 8 level stack to be a big
potential limitation particularly if I am in a nested subroutine when an
interrupt gets called and I can see the potential of a different interrupt
happening when I'm in the middle of handling one of the other interrupt
sources.  I want to make solid code so I can't just hope that any particular
interrupt is unimportant.  So is there a way to extend the hardware PC stack
into software or should I resort to sneaky tactics to reduce nested loops?

I am almost to the point of using two chips, I was going to eventually for
scaling to larger projects but for the short term I had hoped to only use
one for the small projects.

Jeff

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\06@180627 by Olin Lathrop

face picon face
> I am seeing an 8 level stack to be a big
> potential limitation ...
> and I can see the potential of a different interrupt
> happening when I'm in the middle of handling one of the other interrupt
> sources.

Interrupts are not nested on the 16 series PICs.  An interrupt uses exactly
one stack location unless you deliberately call a subroutine.

> So is there a way to extend the hardware PC stack
> into software

No.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spamBeGoneolinspamBeGonespamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\06@184656 by Bob Barr

picon face
Olin Lathrop wrote:
>
>Interrupts are not nested on the 16 series PICs.  An interrupt uses exactly
>one stack location unless you deliberately call a subroutine.
>

I've never considered nesting interrupts on a PIC but wouldn't it be
possible (though perhaps not advisable) to nest interrupts by re-enabling
GIE during the execution of the original interrupt code?

(At a minimum, I'd expect that this approach would require a bit of careful
coding to save/restore W and STATUS uniquely for each level of nesting.
There may be some other complications that don't immediately come to mind.)

Is there anything in the Microchip docs that would preclude doing this? If
so, I haven't seen it. Have I missed something simple here?


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\07@090554 by Olin Lathrop

face picon face
> I've never considered nesting interrupts on a PIC but wouldn't it be
> possible (though perhaps not advisable) to nest interrupts by re-enabling
> GIE during the execution of the original interrupt code?
>
> (At a minimum, I'd expect that this approach would require a bit of
careful
> coding to save/restore W and STATUS uniquely for each level of nesting.
> There may be some other complications that don't immediately come to
mind.)

I see no reason you can't do this, although as you said you have to be extra
careful about all the save/restore issues.  My short answer of "interrupts
aren't nested" was because the original post was worried about using extra
stack locations if an interrupt condition should occur while another was
being serviced.  By the way, the 18 series PICs have two interrupt priority
levels.  A high priority interrupt can occur while a low priority interrupt
is being serviced.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, TakeThisOuTolinEraseMEspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\07@105458 by Jeff DeMaagd

flavicon
face
----- Original Message -----
From: Olin Lathrop <RemoveMEolin_piclistspamTakeThisOuTEMBEDINC.COM>


> > I've never considered nesting interrupts on a PIC but wouldn't it be
> > possible (though perhaps not advisable) to nest interrupts by
re-enabling
> > GIE during the execution of the original interrupt code?
> >
> > (At a minimum, I'd expect that this approach would require a bit of
> careful
> > coding to save/restore W and STATUS uniquely for each level of nesting.
> > There may be some other complications that don't immediately come to
> mind.)
>
> I see no reason you can't do this, although as you said you have to be
extra
> careful about all the save/restore issues.  My short answer of "interrupts
> aren't nested" was because the original post was worried about using extra
> stack locations if an interrupt condition should occur while another was
> being serviced.

I know that you can't have an interrupt of one kind be triggered until the
interrupt flag of that kind is still raised, which is cleared at the end of
the ISR.  My interrupt routines aren't big but my concern is that I will
have a fairly unsteady stream of inputs on portb that might change while I'm
handling timer0, and I don't think I can take the chance of missing a single
state change which can happen at any instant and be replaced at any instant.
I have set up a method to handle the save/restore states.  I will have to do
macros or something to cut down on my subroutine calls just to be safe on
the hardware stack, which was only big concern, it appears everything else
can be handled with proper coding.

Jeff

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\07@110330 by Bob Barr

picon face
Olin Lathrop wrote:

>
>I see no reason you can't do this, although as you said you have to be
>extra
>careful about all the save/restore issues.  My short answer of "interrupts
>aren't nested" was because the original post was worried about using extra
>stack locations if an interrupt condition should occur while another was
>being serviced.

Thanks for the clarification. I *thought* that might be the case but wanted
to be sure.

>By the way, the 18 series PICs have two interrupt priority
>levels.  A high priority interrupt can occur while a low priority interrupt
>is being serviced.
>

Fantastic. That could sure take a lot of the worry out of interrupt
programming.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\16@190519 by Hartung, Greg

flavicon
face
I didn't even know it had a buffer.  No mention in the datasheet of how big
it is, tho.  Just one character?




> UART_SendChar
>         bsf     STATUS,RP0              ; switch to bank 1
>         btfss   TXSTA,1                 ; check TXMT flag and loop if
>          goto   UART_SendChar           ; still not done sending the last
character

Why do you want to wait until the last character is sent to send the next
one?  Do you really need to make sure the previous character has gone out or
are you just trying to make sure the UART is ready to receive the next
character?  If so, you should be checking the TXIF bit in PIR1.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


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