Searching \ for '[PIC]: 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: 'Interrupts'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Interrupts'
2001\06\12@045204 by Joe Hill (Slough)

flavicon
face
To all,
Please can you help, I have a 10ms interrupt that decrements CHIMECT  inside
the ISR. I also have a Timer 0 interrupt which is used to send out data to a
DAC. While the  CHIMECT  reg decrements every 10ms inside the ISR. The Timer
0 interrupt is somehow enabled, i.e. data is output to the DAC, which I
don't want to happen until CHIMECT = 0. I am overlooking something simple.
Can you help?

I have a problem with a

chdly


       bsf     STATUS, RP0     ; select bank 1
       bcf     INTCON,T0IE     ;
       bcf     INTCON,T0IF     ;

       movlw   d'50'           ; load value into chime count - 50
       movwf   CHIMECT


       bsf     STATUS, RP0     ; select bank 1
       bsf     PIE1,TMR1IE     ; enable timer 1 interrupt

       bcf     STATUS, RP0     ; select bank 0

chdlylp
       movf    CHIMECT,0       ; move survct into w to check for zero flag
       btfss   STATUS,Z
       goto    chdlylp

       bsf     STATUS, RP0     ; select bank 1
       bcf     PIE1,TMR1IE     ; disable timer 1 interrupt
       bcf     STATUS, RP0     ; select bank 0
       call    playchime       ; if not set then call chime routine

Regards,

Joseph Hill (new to Pic's!)
R&D Engineer
Avalon Communications
Tyco Engineering Services



***************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
***************************************************************

--
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\06\12@052723 by Vasile Surducan

flavicon
face
Hi,
Probably you can do it without any interrupt, chimect ( which probably
you'll decrement in main because is not in the isr ) may be
decremented by checking ( after tmr0 and prescaler have been initialized
corectly ) every low to high transition of t0if, after that, t0if must be
reset and chimet can be decremented  ( only if required time gave by
prescaler and tmr0 value is not enough) In your case, 10ms don't need
external counter.

So, set tmr0 and prescaler for 10mS rollover and check intcon_t0if.
When it happens send data to dac.
I hope you'll understood my slough english...
Vasile

On Tue, 12 Jun 2001, Joe Hill (Slough) wrote:

{Quote hidden}

--
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\06\12@082636 by Ian Rozowsky

flavicon
face
I'm not certain which part you're using, but you preload CHIMECT with 50
while poiting to Bank 1, and check it later for zero while pointing to Bank
0. This could possibly be your problem.

> chdly
>
>
>         bsf     STATUS, RP0     ; select bank 1
>         bcf     INTCON,T0IE     ;
>         bcf     INTCON,T0IF     ;
>         movlw   d'50'           ; load value into chime count - 50
>         movwf   CHIMECT
****BANK 1 SELECTED HERE
>
>
>         bsf     STATUS, RP0     ; select bank 1
>         bsf     PIE1,TMR1IE     ; enable timer 1 interrupt
>
>         bcf     STATUS, RP0     ; select bank 0
>
> chdlylp
>         movf    CHIMECT,0       ; move survct into w to check for zero
flag        ****BANK 0 SELECTED HERE
>         btfss   STATUS,Z
>         goto    chdlylp
>
>         bsf     STATUS, RP0     ; select bank 1
>         bcf     PIE1,TMR1IE     ; disable timer 1 interrupt
>         bcf     STATUS, RP0     ; select bank 0
>         call    playchime       ; if not set then call chime routine

Ian Rozowsky
Engineering Manager
Centurion Systems
P.O. Box 506
Cramerview 2060
South Africa
Tel   : +27-11-462-4499
Fax   : +27-11-704-3412
e-mail: spam_OUTrozTakeThisOuTspamcentsys.co.za
web: http://www.centsys.co.za

--
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\06\12@090652 by Olin Lathrop

face picon face
> Please can you help, I have a 10ms interrupt that decrements CHIMECT
inside
> the ISR. I also have a Timer 0 interrupt which is used to send out data to
a
> DAC. While the  CHIMECT  reg decrements every 10ms inside the ISR. The
Timer
> 0 interrupt is somehow enabled, i.e. data is output to the DAC, which I
> don't want to happen until CHIMECT = 0. I am overlooking something simple.
> Can you help?
>
> I have a problem with a

Your problem description is rather unclear, at least to me.  This doesn't
look like ISR code below.

> chdly
>
>
>         bsf     STATUS, RP0     ; select bank 1

... or bank 3 if RP1 is set.

>         bcf     INTCON,T0IE     ;
>         bcf     INTCON,T0IF     ;
>
>         movlw   d'50'           ; load value into chime count - 50
>         movwf   CHIMECT
>
>
>         bsf     STATUS, RP0     ; select bank 1

You already did this above.

>         bsf     PIE1,TMR1IE     ; enable timer 1 interrupt

Do you also have peripheral interrupts enabled in INTCON?

>         bcf     STATUS, RP0     ; select bank 0

... or bank 2 if RP1 is set.

> chdlylp
>         movf    CHIMECT,0       ; move survct into w to check for zero
flag

Use the constants F and W to indicate the target, that's what they are for.
I don't remember off the top of my head which one is which, so I can't say
if this is right.

If all you want to do is set Z, then you don't need to move the value into
W, although that will work.

>         btfss   STATUS,Z
>         goto    chdlylp
>
>         bsf     STATUS, RP0     ; select bank 1
>         bcf     PIE1,TMR1IE     ; disable timer 1 interrupt
>         bcf     STATUS, RP0     ; select bank 0
>         call    playchime       ; if not set then call chime routine

So what exactly goes wrong here?  Where?  What are the symptoms?  What do
you find when simulating this?


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.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\06\12@093247 by Joe Hill (Slough)

flavicon
face
Thanks for your help!

We have discovered that although timer0 was disabled from interrupting, the
interrupt flag would always be set every time it rolled over from ff to 00.
The ISR routine although trying to determine which interrupt had generated
the service call, would always have Timer0's interrupt flag set, even when
Timer1 was where the Interrupt was generated from. Is there a way of totally
disabling Timer0 ?




{Original Message removed}

2001\06\12@094743 by Bob Ammerman

picon face
Just have your interupt code check for both T0IE and T0IF being set.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

----- Original Message -----
From: "Joe Hill (Slough)" <JHHillspamKILLspamTYCOINT.COM>
To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
Sent: Tuesday, June 12, 2001 9:30 AM
Subject: Re: [PIC]: Interrupts


> Thanks for your help!
>
> We have discovered that although timer0 was disabled from interrupting,
the
> interrupt flag would always be set every time it rolled over from ff to
00.
> The ISR routine although trying to determine which interrupt had generated
> the service call, would always have Timer0's interrupt flag set, even when
> Timer1 was where the Interrupt was generated from. Is there a way of
totally
> disabling Timer0 ?
>
>
>
>
> {Original Message removed}

2001\06\12@125314 by Olin Lathrop

face picon face
> We have discovered that although timer0 was disabled from interrupting,
the
> interrupt flag would always be set every time it rolled over from ff to
00.
> The ISR routine although trying to determine which interrupt had generated
> the service call, would always have Timer0's interrupt flag set, even when
> Timer1 was where the Interrupt was generated from. Is there a way of
totally
> disabling Timer0 ?

It would be better to fix the checking in the interrupt routine.  It could
AND the enable and flag bits, or it could check for timer 0 interrupt last.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, EraseMEolinspam_OUTspamTakeThisOuTembedinc.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



'[PIC]: Interrupts'
2002\05\28@115121 by Howard Simpson
flavicon
face
Hi all
I've been looking at the thread re context saving during interrupts.
I must say I haven't had trouble, but I'm always looking out for it, and
I'm starting to fool around with program memory paging, which is sure to
create a problem somewhere.

What intrigues me is: (simplified)
InterruptRoutine
       Disable gie
       Save w          (in usual way)
       Save status     (in ususl way)
       Save pclath     (in usual way)
.
. set off a case of dynamite, or whatever, here.
.
       Restore w       (in usual way)
       Restore pclath  (in usual way)??????????
       Restore status  (in usual way)
       Enable gie      (in usual way)
       Retfie
Heres's my problem with this at ??????????:
The above routine is in page 0.  The program was doing something in page
1 when the int was incurred.  The program jumps to 04, where the above
routine is, or called from. Done correctly, that's OK.

The routine does it's thing.

Then we restore pclath!  BEFORE we restore status, enable gie, and
return!
       Won't restoring pclath take us back to page 1, away from the next line
(restore status, enable gie, retfie)?
       Restore status and the other two lines are in page 0 where the
interrupt routine is, not in page 1!
       I think it works OK, but why?  We hafta get back to page 1 to resume
after the int, that's for sure, but it seems to me that we've gone back
before the int routine was finished.  I thought that the int incursion
pushed the lower byte of the program counter, and popped it at retfie,
and that's why we had to look after the upper bits ourselves, thru
pclath.
       (Olin's stuff will handle this itself, but I like to be masochistic,
and KNOW how it works the long way, before I take the shorcuts)

Regards Howard

--
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


2002\05\28@123632 by =?iso-8859-1?Q?F=E1bio_Pereira?=

flavicon
face
Hello Howard,

   First of all, remember that the CALL instruction pushes the entire PC
(PCH+PCL) to the stack, and a RETURN type instruction will pop this PC from
the stack when execuded.
   That makes useless to modify PCLACH before a RETURN (RETFIE or RETLW)
instruction, because the 13 bit PC will be completely poped from the stack.
   Note that the CALL instruction uses an 11 bit operand to specify the
target address, this sometimes implies that one will have to manually change
the PCLATH register to be able to call an subrotine out of the 2048 words
range.
   The need for saving PCLATH reg isn't related to the return address, but
to the context itself. Remember that all SFR's changed in the ISR code AND
in the main code, will eventually need to be saved in the beggining of the
ISR and restored at the end of it. This is what happens to the PCLATH in
most cases.
   Finally, remember that writing to the PCLATH register DOESN'T
imediatelly changes the PC value. The value of the PCLATH will be used only
when there is a write operation to the PC register (like an ADDWF PCL,F,
CALL xxxx, etc.).

   Good luck,

   Fabio

{Quote hidden}

line
> (restore status, enable gie, retfie)?
>         Restore status and the other two lines are in page 0 where the
> interrupt routine is, not in page 1!
>         I think it works OK, but why?  We hafta get back to page 1 to
resume
> after the int, that's for sure, but it seems to me that we've gone back
> before the int routine was finished.  I thought that the int incursion
> pushed the lower byte of the program counter, and popped it at retfie,
> and that's why we had to look after the upper bits ourselves, thru
> pclath.
>         (Olin's stuff will handle this itself, but I like to be
masochistic,
{Quote hidden}

--
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


2002\05\28@124047 by Carlos Ojea

flavicon
face
>InterruptRoutine
>        Disable gie
>        Save w          (in usual way)
>        Save status     (in ususl way)
>        Save pclath     (in usual way)


>        Won't restoring pclath take us back to page 1, away from the next
line
>(restore status, enable gie, retfie)?


I am working with a 18C452 so I dont know much about program memory
paging...
But you are saving pclath inside your interrupt routine (page 0),  so I dont
understand why restoring pclath at the end of your interrupt routine will
take you back to page 1.

--
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


2002\05\28@124928 by Olin Lathrop

face picon face
> InterruptRoutine
>         Disable gie
>         Save w          (in usual way)
>         Save status     (in ususl way)
>         Save pclath     (in usual way)
> .
> . set off a case of dynamite, or whatever, here.
> .
>         Restore w       (in usual way)
>         Restore pclath  (in usual way)??????????
>         Restore status  (in usual way)

Actually W must be restored last because W is used in restoring PCLATH and
STATUS.  Note that you might also need to save/restore FSR if the interrupt
routine does any indirect addressing.

{Quote hidden}

line
> (restore status, enable gie, retfie)?

No.  Setting PCLATH by itself has no effect on the program counter.  PCLATH
is not the high byte of the program counter, but the data that will be
loaded into the high bits as part of some instructions.  These PICs use a 13
bit address, and PCLATH supplies the upper 5 bits when PCL is manipulated
directly.  PCLATH supplies the upper 2 bits of the target address of a GOTO
or CALL because these instructions contain only the low 11 bits of the
target address.  PCLATH has no effect on RETURN and RETFIE instructions
because these pop the full 13 bit return address off the stack.

>         (Olin's stuff will handle this itself, but I like to be
masochistic,
> and KNOW how it works the long way, before I take the shorcuts)

My stuff handles PCLATH for you when jumping or calling between modules.
However nothing is hidden in the interrupt routine.  All the gory details
are easily visible in QQQ_INTR.ASPIC at http://www.embedinc.com/pic/.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, 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


2002\05\28@125144 by Drew Vassallo

picon face
>What intrigues me is: (simplified)
>InterruptRoutine
>         Disable gie

This is not needed at all.  Note that the PIC automagically disables any
further interrupts by clearing the GIE bit before it vectors to ORG 0x004.
The RETFIE instruction sets the bit.

>Heres's my problem with this at ??????????:
>         Won't restoring pclath take us back to page 1, away from the next
>line
>(restore status, enable gie, retfie)?

It "will", but only if you are using instructions that require the PCLATH to
be updated, such as GOTO, CALL, or otherwise by adjusting the PCL directly.
I'm not sure if the RETURN or RETFIE instruction adjusts PCLATH, but I'm
inclined to say that it doesn't, so that could cause problems too.
Actually, I don't think any instruction in the 12 or 14-bit core chips
actually adjust the PCLATH, so any instruction that redefines the PCL
register will cause problems unless PCLATH is properly assigned.

The reason that it works in your ISR is that you aren't using any of these
instructions after you restore the PCLATH.  I'm sure others will have more
detailed explanations, but this is just my short interpretation.

--Andrew

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

--
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


2002\05\28@143528 by Dwayne Reid

flavicon
face
At 01:55 AM 5/29/02 +1000, Howard Simpson wrote:
>Hi all
>I've been looking at the thread re context saving during interrupts.
>I must say I haven't had trouble, but I'm always looking out for it, and
>I'm starting to fool around with program memory paging, which is sure to
>create a problem somewhere.
>
>What intrigues me is: (simplified)
>InterruptRoutine
>         Disable gie

Don't need to disable _GIE - its already done by the interrupt hardware

>         Save w          (in usual way)
>         Save status     (in ususl way)
>         Save pclath     (in usual way)

Now you would normally point PCLATH to the location of your ISR code.  I
keep my ISR code located close to the interrupt vector (look-up tables come
first, then ISR code) so I usually just clear PCLATH.  Note that there is
no sense in saving PCLATH if you don't change it.

{Quote hidden}

First - you do not need to save PCLATH if and *only* if you do not have any
jumps or goto's or change PCL in any way.  You see, PCLATH is used ONLY if
the PC counter is changed as a result of any instruction: goto or addwf
PCL,F or movwf PCL.  Since many people save context and then do a "goto
ISR", you need to save PCLATH.  But if you have NO goto's and no computed
goto's (look-up tables and the like) in your ISR code, PCLATH does not need
to get altered and therefore does not need to get saved.

As you have probably read both in the data sheets and here on the PICLIST,
PCLATH contains the upper address bits that are placed into the program
counter when it is changed.  Note the careful distinction: PCLATH is NOT
the upper byte of the PC.  It contains the bits that are placed into the
upper byte of the PC if the PC is changed as the result of an instruction -
a jump or a look-up table.

Note also that only the upper bits of the PC that are not contained in the
instruction are taken from PCLATH.  If you are doing a table read, bits 8
and up of the PC come from PCLATH because the result of an ADD is only 8
bits: 7..0.  That means that bits 8 and up come from PCLATH.

On the other hand, a GOTO has space for 11 bits of address within the
instruction.  If you are working with a PIC with less than 2K of code
space, your ISR routine does not need to alter PCLATH and therefore does
not need to save it.

But now the gotcha comes: if your PIC has more than 2K of code space *and*
you have an interrupt *and* your interrupt routine alters the program
counter (goto or look-up table), *THEN* you need to make sure that PCLATH
points to the ROM page where your ISR code is located and that means you
have to save PCLATH as part of your ISR context save.

Whew!

Now you should be able to see why restoring PCLATH at the beginning of the
context restore is safe and OK.  There are no goto's in the short space
between restoring PCLATH and exiting the ISR via retfie and therefore,
PCLATH is not being read.

dwayne

--
Dwayne Reid   <dwaynerspamspam_OUTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
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


2002\05\28@161058 by Drew Vassallo

picon face
>But if you have NO goto's and no computed
>goto's (look-up tables and the like) in your ISR code, PCLATH does not need
>to get altered and therefore does not need to get saved.

This is true, but can be dangerous if you want to add to your code at a
later date and forget about PCLATH, thinking to yourself "I've already got
my context saving taken care of."  You might be better off saving everything
properly from the start.



_________________________________________________________________
Join the world s largest e-mail service with MSN Hotmail.
http://www.hotmail.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


2002\05\28@162502 by Bob Ammerman

picon face
> What intrigues me is: (simplified)
> InterruptRoutine
>         Disable gie

You do not disable GIE. The PIC does that automatically when entering the
interrupt routine.

>         Save w          (in usual way)
>         Save status     (in ususl way)
>         Save pclath     (in usual way)

You need to set PCLATH to a known value here if you are going to use any
CALLs or GOTOs

>  set off a case of dynamite, or whatever, here.

>         Restore w       (in usual way)
>         Restore pclath  (in usual way)??????????
>         Restore status  (in usual way)
>         Enable gie      (in usual way)

You do not reenable GIE. That happens as part of the RETFIE instruction.

>         Retfie
> Heres's my problem with this at ??????????:

> The above routine is in page 0.  The program was doing something in page
> 1 when the int was incurred.  The program jumps to 04, where the above
> routine is, or called from. Done correctly, that's OK.

Except we don't have any idea what is in PCLATH!

> The routine does it's thing.
>
> Then we restore pclath!  BEFORE we restore status, enable gie, and
> return!
>         Won't restoring pclath take us back to page 1, away from the next
line
> (restore status, enable gie, retfie)?

No, the value in PCLATH is only used when we do a CALL or GOTO.

>         Restore status and the other two lines are in page 0 where the
> interrupt routine is, not in page 1!
>         I think it works OK, but why?  We hafta get back to page 1 to
resume
> after the int, that's for sure, but it seems to me that we've gone back
> before the int routine was finished.  I thought that the int incursion
> pushed the lower byte of the program counter, and popped it at retfie,
> and that's why we had to look after the upper bits ourselves, thru
> pclath.

No, the interrupt saves the _entire_ program counter and restores it.

Here is a summary of _every_ time the PIC hardware refers to PCLATH without
an explicit reference to it in your instruction:

1: When do a local computed goto (often a table lookup) by doing something
like ADDWF PCL,F. In this case PCLATH provides bits 8 and up of the address.

2: When doing a CALL or GOTO. In this case PCLATH provides bits 11 and up of
the address.

And THAT IS ALL. At no other time does the hardware refer to PCLATH. In
particular it does NOT change PCLATH when:

1: Doing a CALL or GOTO to another page.

2: Executing a RETURN or RETLW instruction.

3: Taking or returning from an interrupt.

4: Incrementing PCL from 0xFF to 0x00

5: Incrementing the PC across a 2K page boundary.

Bob Ammerman
RAm Systems

--
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


2002\05\28@164838 by Bob Ammerman

picon face
> >But if you have NO goto's and no computed
> >goto's (look-up tables and the like) in your ISR code, PCLATH does not
need
> >to get altered and therefore does not need to get saved.
>
> This is true, but can be dangerous if you want to add to your code at a
> later date and forget about PCLATH, thinking to yourself "I've already got
> my context saving taken care of."  You might be better off saving
everything
> properly from the start.
>

Also, NO CALLS.

And I have found this useful in a couple of applcations where every cycle is
critical. And of course it is pretty easy for a GOTO to sneak its way into
your ISR.

Bob Ammerman
RAm Systems

--
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


2002\05\28@171250 by Olin Lathrop

face picon face
> Now you would normally point PCLATH to the location of your ISR code.  I
> keep my ISR code located close to the interrupt vector (look-up tables
come
> first, then ISR code) so I usually just clear PCLATH.  Note that there is
> no sense in saving PCLATH if you don't change it.

True, but note that you need to change PCLATH to the interrupt code page if
you do any GOTOs or CALLs in the interrupt routine.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, 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


2002\05\28@204826 by Dwayne Reid

flavicon
face
I must not have been clear enough - something that happens all too often.

Olin states: "note that you need to change PCLATH to the interrupt code
page if you do any GOTOs or CALLs in the interrupt routine."

Now look at the first line that Olin quoted below where I state:  "Now you
would normally point PCLATH to the location of your ISR code."  In other
words, isn't that what I just said?

The 3rd sentence Olin quoted below is where I thought something was
obvious: if you don't change PCLATH, you don't need to save it.  This was
my oblique attempt at humor - obviously, it didn't work.

dwayne

At 05:11 PM 5/28/02 -0400, Olin Lathrop wrote:
> > Now you would normally point PCLATH to the location of your ISR code.  I
> > keep my ISR code located close to the interrupt vector (look-up tables
>come
> > first, then ISR code) so I usually just clear PCLATH.  Note that there is
> > no sense in saving PCLATH if you don't change it.
>
>True, but note that you need to change PCLATH to the interrupt code page if
>you do any GOTOs or CALLs in the interrupt routine.


--
Dwayne Reid   <@spam@dwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
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


2002\05\29@052728 by Howard Simpson

flavicon
face
Carlos Ojea wrote:
>
> >InterruptRoutine
> >        Disable gie
> >        Save w          (in usual way)
> >        Save status     (in ususl way)
> >        Save pclath     (in usual way)
>
> >        Won't restoring pclath take us back to page 1, away from the next
> line
> >(restore status, enable gie, retfie)?
>
> I am working with a 18C452 so I dont know much about program memory
> paging...
> But you are saving pclath inside your interrupt routine (page 0),  so I dont
> understand why restoring pclath at the end of your interrupt routine will
> take you back to page 1.
>
> --
Hmmm.  That's a valid point!
H
> 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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@053354 by Howard Simpson

flavicon
face
Howard Simpson wrote:
>
> Hi all
> I've been looking at the thread re context saving during interrupts.
> I must say I haven't had trouble, but I'm always looking out for it, and
> I'm starting to fool around with program memory paging, which is sure to
> create a problem somewhere.

Thanks very much to all who replied with really good explanations and
food for further thought.  With these 876's and 877's, I don't think
there's a day goes past that I don't either learn something new, or find
something new that I don't understand.
>
> --
> 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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@061414 by Howard Simpson

flavicon
face
I have studified all the replies, and I think the following to be
correct.
Fact1:  Don't have to disable/enable gie. (I got that as old advice some
time back, and have just continued with it)
Fact2:  Setting a page in PCLATH doesn't immediately take the program
counter to the page.  That only happens when a program jump (call, goto,
etc)is initiated.
Fact3:  There's no harm in saving everything, in case there are changes
in the program later on which may or may not require it.
Fact4:  Restore W last, as movf's before the retfie change it too.
Fact5:  My example showed the ISR directly between the saves and
restores.  If there was a goto, or call, which was outside the ISR, and
involved page changes, then PCLATH would need to be saved.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@085903 by Bob Ammerman

picon face
----- Original Message -----
From: "Howard Simpson" <KILLspambrahKILLspamspamAUSTARNET.COM.AU>
To: <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU>
Sent: Wednesday, May 29, 2002 6:16 AM
Subject: Re: [PIC]: Interrupts


> I have studified all the replies, and I think the following to be
> correct.
> Fact1:  Don't have to disable/enable gie. (I got that as old advice some
> time back, and have just continued with it)

Actually, disabling and particularly enabling GIE in the interrupt handler
is just plain DANGEROUS. Bad things happen if an interrupt occurs between
the BSF GIE and RETFIE instruction. Also, remember that any interrupt that
occurs during the interrupt handler will be waiting and ready to interrupt
as soon as GIE is set.

> Fact2:  Setting a page in PCLATH doesn't immediately take the program
> counter to the page.  That only happens when a program jump (call, goto,
> etc)is initiated.

Yes!

> Fact3:  There's no harm in saving everything, in case there are changes
> in the program later on which may or may not require it.

Sure, the only harm is performance.

> Fact4:  Restore W last, as movf's before the retfie change it too.

Yep.

> Fact5:  My example showed the ISR directly between the saves and
> restores.  If there was a goto, or call, which was outside the ISR, and
> involved page changes, then PCLATH would need to be saved.

Not only saved and restored, but set to the page of the ISR (can you say
CLRF PCLATH?). And this needs to be done if there are ANY GOTO's or CALL's
in the ISR code, even if they are to another location in the ISR.

The only exception to this is if your program always ensures that high order
5 bits of PCLATH are always clear when an interrupt happens. This can be
ensured if your mainline code lives entirely in the first 2K of code space,
or if interrupts are disabled by mainline code whenver PCLATH is set outside
the first 2K code space (perhaps to access large tables in the upper 6K).

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@113412 by =?iso-8859-1?Q?F=E1bio_Pereira?=

flavicon
face
> Fact1:  Don't have to disable/enable gie. (I got that as old advice some
> time back, and have just continued with it)

ok

> Fact2:  Setting a page in PCLATH doesn't immediately take the program
> counter to the page.  That only happens when a program jump (call, goto,
> etc)is initiated.

ok. Just remember that any operation with the PCL as target will make the PC
to be loaded with the PCL and PCLATH contents. The portion of PCLATH used
vary with any kind of operation.

> Fact3:  There's no harm in saving everything, in case there are changes
> in the program later on which may or may not require it.

sure. Only uses more RAM than necessary ...

> Fact4:  Restore W last, as movf's before the retfie change it too.
NO. Remember that the MOVF instruction will change the Z flag. If the MOVF
instruction is the last one before the RETFIE, chances are that the Z flag
will be diferent from the calling of the ISR to it's return. Use the SWAPF
instruction instead. It doesn't affect the Z flag.

> Fact5:  My example showed the ISR directly between the saves and
> restores.  If there was a goto, or call, which was outside the ISR, and
> involved page changes, then PCLATH would need to be saved.

ok Just remember that a call from an ISR is not a good option ...

Regards,

Fabio

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@125523 by Drew Vassallo

picon face
>ok Just remember that a call from an ISR is not a good option ...

If you're going to make this statement, you'd better explain why it's "not a
good option."  I've been doing it for years without difficulty and it seems
to be just as good an "option" as anything else.

--Andrew

_________________________________________________________________
Join the world s largest e-mail service with MSN Hotmail.
http://www.hotmail.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@131810 by Bob Blick

face picon face
> >ok Just remember that a call from an ISR is not a good option ...
>
> If you're going to make this statement, you'd better explain why it's "not a
> good option."  I've been doing it for years without difficulty and it seems
> to be just as good an "option" as anything else.

I agree with Drew, there's nothing inherently wrong with calling from the
ISR. Just don't call functions your main loop might be simultaneously
using :)

Cheers,

Bob

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@141152 by Bob Ammerman

picon face
> > >ok Just remember that a call from an ISR is not a good option ...
> >
> > If you're going to make this statement, you'd better explain why it's
"not a
> > good option."  I've been doing it for years without difficulty and it
seems
> > to be just as good an "option" as anything else.
>
> I agree with Drew, there's nothing inherently wrong with calling from the
> ISR. Just don't call functions your main loop might be simultaneously
> using :)

Actually there is nothing wrong with doing this either, as long as the
function is reentrant.

Perhaps the biggest issue in CALLing within an ISR is that you use up
additional stack levels, which are often a tight constraint on a design.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@141809 by Drew Vassallo

picon face
>I agree with Drew, there's nothing inherently wrong with calling from the
>ISR. Just don't call functions your main loop might be simultaneously
>using :)

Well, you CAN do that, too.  But unless you can afford to have counters
overwritten or otherwise adjusted by the ISR, you'll have to use some sort
of flags to indicate from where you're calling the routine.

I do this on a non-time sensitive LED display application.  I display a
certain value continually through a routine, but also display a DIFFERENT
value using the same routine called from the ISR.  I just use a flag to
indicate which value I want to display, then return when finished.  The
extra time lost in resetting the loop counters upon returning from the ISR
is undetectable to the naked eye anyway.

--Andrew

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@145128 by Tal (Zapta)

flavicon
face
>
> Perhaps the biggest issue in CALLing within an ISR is that you use up
> additional stack levels, which are often a tight constraint on a design.
>
> Bob Ammerman
> RAm Systems

Especially with very limited stack size architectures such as PIC ;-)

Tal

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@150426 by =?iso-8859-1?Q?F=E1bio_Pereira?=

flavicon
face
hehe

that's only a point of view ...
This is just an alert for those who are initiating with PIC programming ...
There are many issues that the programmer needs to address or prevent while
calling functions from an ISR.
I did not said it's WRONG, but that's not a good "option". It means that
there are ways to do it without the need to call a function from the ISR,
like setting a flag that the main program will clear and process out of the
ISR. This IN MY OPINION is a more elegant approach and easier to debug too.

Again I would like to remember that this practice can result in strange
behaviors/errors in the program, if done incorrectly. That's why I said it
wasn't a good "option". But if one is confident of what he is doing, of
course that will be no problem of doing that.

> If you're going to make this statement, you'd better explain why it's "not
a
> good option."  I've been doing it for years without difficulty and it
seems
> to be just as good an "option" as anything else.
>
> --Andrew

I just tried to use few words, that's my point of view. I'm happy there are
other points too !  ;-)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@170930 by Olin Lathrop

face picon face
> > Fact4:  Restore W last, as movf's before the retfie change it too.
> NO. Remember that the MOVF instruction will change the Z flag. If the MOVF
> instruction is the last one before the RETFIE, chances are that the Z flag
> will be diferent from the calling of the ISR to it's return. Use the SWAPF
> instruction instead. It doesn't affect the Z flag.

These statements require some clarification.  You need to restore W last
because restoring anything else requires using W.  However, some
instructions modify bits in STATUS, so these can't be used after STATUS has
been restored.  SWAPF is an instruction that can load data into W without
modifying status, so it can be handy for use in restoring W, which must be
done after STATUS is already restored.

See QQQ_INTR.ASPIC at http://www.embedinc.com/pic/ for a template interrupt
module that contains code for all the save/restore operations.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@171904 by Olin Lathrop

face picon face
> > >ok Just remember that a call from an ISR is not a good option ...
> >
> > If you're going to make this statement, you'd better explain why it's
"not a
> > good option."  I've been doing it for years without difficulty and it
seems
> > to be just as good an "option" as anything else.
>
> I agree with Drew, there's nothing inherently wrong with calling from the
> ISR. Just don't call functions your main loop might be simultaneously
> using :)

Even that is not inherently wrong.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\29@172752 by M. Adam Davis

flavicon
face
There are three main reasons one might not want to initiate a call from
an ISR:

1. Interrupts are (should be) disabled for the duration of the ISR -
otherwise you may interrupt your own interrupt, causing stack overflows
(which the processor does NOT catch or warn you of) and you will end up
delaying interrupt handling for other pending interrupts.

2. If you already are inside several nested calls then the interrupt
itself uses another stack position, and any call you make after that
uses another.  If that function is only used inside the interrupt, then
there's really no reason to make it into its own function (use a macro
if you want to seperate it), if other functions depend on it then you
may find yourself modifying it later - maybe making it call another
function.  In short, when you do this you must have a really good grasp
of how deep your stack is, and how deep your calls could possibly get.

3. Many people consider it bad programming practise (ie, the interrupt
is for time critical tasks and should only be disabled for the briefest
time to service the pending interrupt(s)) and when you go into other
processor architectures such a practice may bite you.  Others reading
your code may have a difficult time modifying it as normal changes (to a
display routine, for instance) may abnormally affect your interrupt routine.

That being said, the PIC is an exceptionally small processor with only
so much speed and code space.  It is not untolerably difficult to track
the stack usage, and many times you'll find yourself using functions
inside interrupts simply to aid in program understanding and component
reusablility.  The third problem above can be alleviated (if not
eliminated) with good coding/commenting practises.  Start each function
with a  description, list of inputs/outputs, ranges of inputs/outputs,
what happens when it is given something it can't handle, and a list of
dependancies.  Be sure to clearly describe if the interrupt routine
calls it.

You can eliminate function calling from interrupts by using inline code,
macros, or flags.

A case where a function call is appropiate is display refresh.  The
refresh must start at even intervals or flickering will be perceived
even at moderately high frequencies.

I know that _you_ know all this, Andrew, but you did ask  ;-)

-Adam

Drew Vassallo wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\30@113713 by Mircea Chiriciuc

flavicon
face
> I did not said it's WRONG, but that's not a good "option". It means that
> there are ways to do it without the need to call a function from the ISR,
> like setting a flag that the main program will clear and process out of
the
> ISR. This IN MY OPINION is a more elegant approach and easier to debug
too.

I totally agree with Fabio. The "soft flags" option as I call it is very
good for getting interrupted a very short period of time in time critical
aplications, and also a "known" period of time.


Mircea Chiriciuc
EMCO INVEST

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2002\05\31@015937 by Vasile Surducan

flavicon
face
Sorry for english speackers, thats is intraductible !


Sasha draga,
Tocmai am transpirat abundent setand astfel de flag-uri in ISR si
testandu-le in main program, dupa care resetandu-le in main program.
Daca main'ul are peste 1k de instructiuni si le baleiezi pe toate ciclic,
durata pina la (re)citirea flagului poate sa fie mai mare decat succedarea
evenimentului ce solicita intreruperi. Totul e OK pana intalnesti
evenimente ce trebuie tratate in intreruperi
la intervale mici de timp, eu m-am blocat cu metoda asta la 100mS,
interval generat prin internal RTC sincronizat cu eveniment de retea (
20mS ) . E drept ca am lucrat in Jal cu foarte putin asm si mainul era un
mamut.
Cred ca pentru eveniment repetat sub 100uS, e mult
mai bine sa apelezi rutina in cauza din ISR ( mai ales la 4MHz ).
Desigur ca o rutina de tratare a intreruperii cu peste 100 de instructiuni
o sa te dea peste cap...


cele bune, Vasile


On Thu, 30 May 2002, Mircea Chiriciuc wrote:

{Quote hidden}

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


2002\05\31@021456 by Scott Dattalo

face
flavicon
face
On Fri, 31 May 2002, Vasile Surducan wrote:

> Sorry for english speackers, thats is intraductible !
>
>
> Sasha draga,
> Tocmai am transpirat abundent setand astfel de flag-uri in ISR si
> testandu-le in main program, dupa care resetandu-le in main program.
> Daca main'ul are peste 1k de instructiuni si le baleiezi pe toate ciclic,
> durata pina la (re)citirea flagului poate sa fie mai mare decat succedarea
> evenimentului ce solicita intreruperi. Totul e OK pana intalnesti
> evenimente ce trebuie tratate in intreruperi
> la intervale mici de timp, eu m-am blocat cu metoda asta la 100mS,
> interval generat prin internal RTC sincronizat cu eveniment de retea (
> 20mS ) . E drept ca am lucrat in Jal cu foarte putin asm si mainul era un
> mamut.
> Cred ca pentru eveniment repetat sub 100uS, e mult
> mai bine sa apelezi rutina in cauza din ISR ( mai ales la 4MHz ).
> Desigur ca o rutina de tratare a intreruperii cu peste 100 de instructiuni
> o sa te dea peste cap...


I can optimize this to 12 words that'll mean the same thing.

Scott
PS. Hint I already gave the solution.

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


2002\05\31@022315 by Vasile Surducan

flavicon
face
Ok Scott, it's perfect true !
Maybe only Nikolai can do it the same...

best regards, Vasile

P.S. I think the asking guy and myself we are living in the same town...



On Thu, 30 May 2002, Scott Dattalo wrote:

{Quote hidden}

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


2002\05\31@073131 by Bob Ammerman

picon face
----- Original Message -----
From: "Scott Dattalo" <RemoveMEscottspam_OUTspamKILLspamDATTALO.COM>
To: <RemoveMEPICLISTTakeThisOuTspamspamMITVMA.MIT.EDU>
Sent: Friday, May 31, 2002 2:13 AM
Subject: Re: [PIC]: Interrupts


> On Fri, 31 May 2002, Vasile Surducan wrote:
>
> > Sorry for english speackers, thats is intraductible !
> >
> >
> > Sasha draga,
> > Tocmai am transpirat abundent setand astfel de flag-uri in ISR si
> > testandu-le in main program, dupa care resetandu-le in main program.
> > Daca main'ul are peste 1k de instructiuni si le baleiezi pe toate
ciclic,
> > durata pina la (re)citirea flagului poate sa fie mai mare decat
succedarea
> > evenimentului ce solicita intreruperi. Totul e OK pana intalnesti
> > evenimente ce trebuie tratate in intreruperi
> > la intervale mici de timp, eu m-am blocat cu metoda asta la 100mS,
> > interval generat prin internal RTC sincronizat cu eveniment de retea (
> > 20mS ) . E drept ca am lucrat in Jal cu foarte putin asm si mainul era
un
> > mamut.
> > Cred ca pentru eveniment repetat sub 100uS, e mult
> > mai bine sa apelezi rutina in cauza din ISR ( mai ales la 4MHz ).
> > Desigur ca o rutina de tratare a intreruperii cu peste 100 de
instructiuni
> > o sa te dea peste cap...
>
>
> I can optimize this to 12 words that'll mean the same thing.
>
> Scott
> PS. Hint I already gave the solution.

ROTFLl...

btw:

I can also tweak it to twelve words that keep the meaning.


Bob Ammerman
RAm Systems


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

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



'[PIC]: Interrupts'
2003\09\26@160330 by David Dunn
flavicon
face
I'm at wits end here, for some reason my ISR doesn't seem to be working. I'm monitoring '_TENTHS' in the main
program loop and it's not incrementing.  Have I missed something obvious ?  What kinds of things would keep the
TIMER0 interrupt from running ?

Thanks for any ideas.


DLD

--------------------------------------------------------------------------------------------------------------


wsave           var     BYTE    $020 SYSTEM
wsave1  var     BYTE    $0a0 SYSTEM
wsave2  var     BYTE    $120 SYSTEM
wsave3  var     BYTE    $1a0 SYSTEM
ssave           var     BYTE    BANK0 SYSTEM
psave           var     BYTE    BANK0 SYSTEM

GOTO AFTERINT                              'Jump past interrupt handler

DEFINE INTHAND isr

asm

isr                             ; int handler begins here

   ;bsf     portb,7

   btfsc   INTCON,1            ; test if external interrupt (portb.0) occurred
   goto    portbint            ; jump over to (portb.0) int handler. otherwise, just fall thru to TIMER0 handler

timer0int

   movlw       0x9e                        ;reload timer with (256 - (1)200) + 2 (3a for .1, 9e for .05)
   movwf       TMR0
   incf        _TENTHS                 ;increase TENTHS value
   bcf         INTCON,2                    ;clear tmr0 interrupt flag
   goto    exitisr

portbint

   movf    TMR1H,W            ;read value on timer1
   movwf   _TMR1HI            ;store it in some variable
   movf    TMR1L,W
   movwf   _TMR1LO

   clrf    TMR1L              ;load timer1 with zero again
   clrf    TMR1H

   bcf         INTCON,1                    ;clear rb0 interrupt flag

exitisr
                               ;restorecode follows here
       movf    psave,w
       movwf   PCLATH
       swapf   ssave,w
       movwf   STATUS
       swapf   wsave,f
       swapf   wsave,w

retfie

endasm

AFTERINT:

   ' set up timer0
   TMR0        = 0
   INTCON      = %00000000
   OPTION_REG  = %11000111
   INTCON      = %10100000

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@161010 by Robert Monsen

picon face
When do you save pclath, etc? You have to save them on entry to the isr or
they will change in your mainloop.




{Original Message removed}

2003\09\26@164237 by

picon face
What language/tool ?
What PIC type ?
What is this "GOTO" and "DEFINE" ? Doesn't look as MPASM !?
What is "asm" and "endasm" ?
Why is only the retfie instruction starting in pos 1 ?
Why restore w, status and pclath if you don't save them ?

Jan-Erik



{Original Message removed}

2003\09\26@165108 by Olin Lathrop

face picon face
> wsave           var     BYTE    $020 SYSTEM
> wsave1  var     BYTE    $0a0 SYSTEM
> wsave2  var     BYTE    $120 SYSTEM
> wsave3  var     BYTE    $1a0 SYSTEM
> ssave           var     BYTE    BANK0 SYSTEM
> psave           var     BYTE    BANK0 SYSTEM
>
> GOTO AFTERINT                              'Jump past interrupt handler
>
> DEFINE INTHAND isr
>
> asm
>
> isr                             ; int handler begins here

Your obviously not using MPASM, since this syntax looks strange.  MPASM is
the official PIC assembler.  If you want help from others, I suggest you
recode this in standard PIC assembly language and ask again.  I'm not
going to waste time guessing what your oddball assembler might be doing.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@172223 by David Dunn

flavicon
face
that part isn't assembler. it's picbasic. i only require help on the assembler part, as that's what the ISR is done
in.

thank you.

dld


On Fri, 26 Sep 2003 16:51:04 -0400, Olin Lathrop wrote:

{Quote hidden}

David Dunn
Digital Racing Products

daveSTOPspamspamspam_OUTdigitalracingproducts.com
http://www.digitalracingproducts.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@172433 by David Dunn

flavicon
face
pic is 16f877. goto / define are picbasic. asm / endasm lets you do inline assembly with picbasic. i'm not sure
what you mean by "starting in position 1" with respect to the retfie instruction.  i've been told that the compiler
automatically saves w/status/pclath on pics over 2k, and inspection of the resulting assembler code confirms this
so i only need to restore them.

thanks !

DLD

On Fri, 26 Sep 2003 22:41:28 +0200, Jan-Erik Soderholm XA (TN/PAC) wrote:

{Quote hidden}

>{Original Message removed}

2003\09\26@172549 by David Dunn

flavicon
face
i'm told that with picbasic on parts over 2k, it's not necessary to save them, it's done automatically. only need
the restore code.

thanks !


dld

On Fri, 26 Sep 2003 13:08:38 -0700, Robert Monsen wrote:

>When do you save pclath, etc? You have to save them on entry to the isr or
>they will change in your mainloop.
>
>
>
>
>{Original Message removed}

2003\09\26@173417 by David Dunn

flavicon
face
aha .. might be getting somewhere. i figured out what you mean by RETFIE in position one. i moved it and program
quit working all together, but that's progress. i think i'm heading in right direction :)

thanks jan-erik


dld

On Fri, 26 Sep 2003 22:41:28 +0200, Jan-Erik Soderholm XA (TN/PAC) wrote:

{Quote hidden}

>{Original Message removed}

2003\09\26@173836 by

picon face
David Dunn wrote :

> goto / define are picbasic.

And we should had guessed that ? :-)

> asm / endasm lets you do inline assembly with picbasic.

OK.

> i'm not sure what you mean by "starting in position 1" with
> respect to the retfie instruction.

MPASM doesn't "like" instructions in pos 1. I don't know
about picbasic.

> i've been told that the compiler automatically saves
> w/status/pclath on pics over 2k, and inspection of the
> resulting assembler code confirms this so i only need to restore them.

Since I don't know picbasic, I hadn't answered in the first place
if I'd known that you used that.

(Now, just getting your second reply to my post, it might have had
some value after all :-) )

Good luck !

Jan-Erik.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@175120 by Olin Lathrop

face picon face
> that part isn't assembler. it's picbasic. i only require help on the
> assembler part, as that's what the ISR is done in.

<rant> Don't you just love it when someone has busted code and is asking
for help, but insists on telling you exactly where the problem is, as if
they know what they are doing. </rant>

The details are very important, especially in an ISR.  Ditch the silly
Basic compiler, or at least write the interrupt module in MPASM.  Then we
can see *exactly* what it's doing (including the parts you don't think are
important but may well be where the problem is).


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@175325 by David Dunn

flavicon
face
just some feedback for you jan-erik .. looks like RETFIE out of alignment was the problem :)

thanks a bunch; i've been chasing this damn problem for a couple days now !



dld

On Fri, 26 Sep 2003 23:38:24 +0200, Jan-Erik Soderholm XA (TN/PAC) wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@175948 by David Dunn

flavicon
face
i do appreciate the help of the group.

amazing how fast it is .. the picbasic message list takes hours and days to cycle posts.

perhaps it's a testament to jan-erik's amazing PIC abilities that he was able to fix my problem given what i posted
initially ?


:)



dld

On Fri, 26 Sep 2003 17:51:34 -0400, Olin Lathrop wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@180151 by

picon face
David Dunn wrote:

> just some feedback for you jan-erik .. looks like RETFIE out of alignment was the problem :)
> thanks a bunch; i've been chasing this damn problem for a couple days now !

Fine ! Glad you found it !

But note, this was *only* guessing and luck from my part,
there wasn't much in your first post to be able to
point at this with any certainty.

Jan-Erik.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@180812 by Ian Bell

flavicon
face
On Friday 26 Sep 2003 10:23 pm, you wrote:
> pic is 16f877. goto / define are picbasic. asm / endasm lets you do inline
> assembly with picbasic. i'm not sure what you mean by "starting in position
> 1" with respect to the retfie instruction.  i've been told that the
> compiler automatically saves w/status/pclath on pics over 2k, and
> inspection of the resulting assembler code confirms this so i only need to
> restore them.

It is not something simple like having to add an underscore to a variable name
when refering to it in assembler but not when in the high level language?

Ian

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@180814 by David Dunn

flavicon
face
i wouldn't call it luck at all. it appears to me as though you took the time to go thru what was there, pointed out
some things that needed looking at, and hit the mark.

i'll try and be a little more specific and MPASM-relevant in the future.


dld

On Sat, 27 Sep 2003 00:00:22 +0200, Jan-Erik Soderholm XA (TN/PAC) wrote:

{Quote hidden}

David Dunn
Digital Racing Products

spamBeGonedaveSTOPspamspamEraseMEdigitalracingproducts.com
http://www.digitalracingproducts.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@180816 by

picon face
David Dunn wrote :

> i do appreciate the help of the group.
>
> amazing how fast it is .. the picbasic message list takes hours and
> days to cycle posts.
>
> perhaps it's a testament to jan-erik's amazing PIC abilities that he
> was able to fix my problem given what i posted initially ?


Whow !

I'll better print that, frame it, and put it
up on the wall !!

And isn't it amazing what a couple of Friday beers
can do to your "PIC abilities" ??

:-)

Jan-Erik.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@182234 by

picon face
David Dunn wrote:

> i'll try and be a little more [...] MPASM-relevant in the future.

Can't see why, if you don't use MPASM. (Or maybe picbasic calls
MPASM for the final build, I don't know...)

And, besides, if it had been clear that you used picbasic
from the beginning, I probably hadn't answerd at all :-)

Still, I *do* think that specifying the envorinment and tools *is*
a good thing.

Jan-Erik.

PS. David, I don't know if it's my mail tool, but all your posts
displays with the first letter in each sentence in lower case.
Most other posts displays them in upper case. Strange... :-)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@183128 by David Dunn

flavicon
face
On Sat, 27 Sep 2003 00:22:19 +0200, Jan-Erik Soderholm XA (TN/PAC) wrote:

that's just a result of me being lazy. i tend to worry less about punctuation when i'm frustrated with a PIC problem.
your mail reader is fine. perhaps it makes my posts difficult to read ?

I've never had a complaint before, but I shall endeavor to correct the evil of my ways in the future.  AT LEAST IT
ISN'T ALL CAPS ! IS THERE ANYTHING WORSE THAN PEOPLE WHO POST ALL CAPS ? MAYBE MY no caps habit IS AN OVERREACTION TO
ALL CAPS HATRED.

:)

dld



>PS. David, I don't know if it's my mail tool, but all your posts
>displays with the first letter in each sentence in lower case.
>Most other posts displays them in upper case. Strange... :-)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@183130 by spacecat

flavicon
face
Why is it a silly compiler ?
----- Original Message -----
From: "Olin Lathrop" <KILLspamolin_piclistspamBeGonespamEMBEDINC.COM>
To: <EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU>
Sent: Friday, September 26, 2003 10:51 PM
Subject: Re: [PIC]: Interrupts


{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@190731 by David Dunn

flavicon
face
for the record, i *LOVE* pic basic pro. it's wonderfull being able to do 95% of your stuff in uber-simple basic,
and just do the have-to's with inline assembly. i get stuff done about 100x faster than i think i ever could in all
assembler.

dld

On Fri, 26 Sep 2003 23:02:00 +0100, spacecat wrote:

>Why is it a silly compiler ?
>{Original Message removed}

2003\09\26@193435 by Olin Lathrop

face picon face
spacecat wrote:
> Why is it a silly compiler ?

It's a compiler, it's Basic.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\26@194100 by Bob Ammerman

picon face
I don't think it is assembler, I think it is JAL.

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Olin Lathrop" <@spam@olin_piclist@spam@spamspam_OUTEMBEDINC.COM>
To: <spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Friday, September 26, 2003 4:51 PM
Subject: Re: [PIC]: Interrupts


{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\27@005455 by Wouter van Ooijen

face picon face
> I don't think it is assembler, I think it is JAL.

good heavens NO, this is definitely not Jal. Jal is a free-format
language like all modern stuff since Algol. It does not care about line
endings except in a few cases (end-of-line comments, inside a literal).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspam_OUTspammitvma.mit.edu with SET PICList DIGEST in the body

2003\09\27@032711 by spacecat

flavicon
face
Your argument speaks much more about you than about PICBASIC. Thanks for
your input.
A lot of people use Visual BASIC, is that so silly ? Or is it that they just
want a tool to make life easier and to get the job done faster.

I'll just go back to my DIY, and hammer this nail in with my head  ;o)


{Original Message removed}

2003\09\27@060853 by Ian Bell

flavicon
face
On Saturday 27 Sep 2003 8:28 am, you wrote:
> Your argument speaks much more about you than about PICBASIC. Thanks for
> your input.
> A lot of people use Visual BASIC, is that so silly ? Or is it that they
> just want a tool to make life easier and to get the job done faster.

I suspect  his comments were aimed more at your choice of tool.

>
> I'll just go back to my DIY, and hammer this nail in with my head  ;o)
>

To use your own analagy, some might say you are trying to hit this nail with a
stick of celery ;-)

Ian

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistserv.....spamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\09\29@064054 by Alan B. Pearce

face picon face
>i do appreciate the help of the group.
>
>amazing how fast it is .. the picbasic message list
>takes hours and days to cycle posts.
>
>perhaps it's a testament to jan-erik's amazing PIC abilities
>that he was able to fix my problem given what i posted
>initially ?

Or maybe he just had the time on his hands to spend some time looking at the
problem. Olin has a valid point, in that he (and a considerable number of
others on the list) are doing such programming work to put the food on the
table. They are not obligated to look at code posted here when people ask
for help, but are prepared to find a little time in their busy worklife to
do so if the original poster has put the effort in and told them all the
bits they need. In your particular case if your original post had said that
the interrupt save code was done by PICBasic then you would have had a lot
less negative vibes fed back.

Jan-Erik unfortunately used a different term in saying "position 1" when
most of the rest of us would have used the term "column 1" which may have
helped you quicker, but you evidently managed to sort that out, and now have
working code. This is not necessarily an "amazing PIC ability" but something
that he saw as a potential problem, as it is a basic way that assemblers
distinguish between labels (which always start in column 1 AFAIK) and
op-codes. Certainly your code did not seem to be trying to branch to a label
of "retfie", and as it is an op-code, there was a very good chance that was
the problem. I would suggest you look carefully at how your code is
formatted (the way it appears in my mono-spaced font suggests it was written
in a proportional spaced font which hides such errors) as this goes a long
way to helping avoid this exact problem in the future.

Your appreciation of the groups help is noted. This is not meant as a "rant
and rave" at a new poster who has done something "wrong". Just a pointer to
help you get a better, and possibly even faster, response next time.

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

2003\09\29@074042 by

picon face
Alan B. Pearce wrote:
> >perhaps it's a testament to jan-erik's amazing PIC abilities
> >that he was able to fix my problem given what i posted
> >initially ?

> Or maybe he just had the time on his hands to spend some time looking at the
> problem. This is not necessarily an "amazing PIC ability"...


Thanks Alan !!
Sure feels nice beeing back with both feets on the ground now !
:-) :-)

Jan-Erik.
PS.
I fully agree with your post, b.t.w...

--
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 2003 , 2004 only
- Today
- New search...