Searching \ for 'Pic 16C554 and Interrupts' 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: 'Pic 16C554 and Interrupts'.

Truncated match.
PICList Thread
'Pic 16C554 and Interrupts'
1999\04\09@082907 by tmariner

flavicon
face
Ran across a problem with interrupts in the Pic 16C554.

There is only data ram on page 0 and one wants to access values on ram page
1 such as TRISB, etc. The problem is that the published interrupt context
save routines (and the ones we have been using for 1000 years) presume that
the W register can be saved on the bank which is currently in the STATUS
register. If page 1 of ram is current then the W register gets restored with
the value which has been "stored" in phantom ram -- which is a 0. Not real
funny when one is trying to set an input value on a TRIS register!

Anyone have a workaround context save routine? (Or a directive telling me
not to have interrupts on when I am in page 1 of the 554?)

Tom

1999\04\09@085433 by Clyde Smith-Stubbs

flavicon
face
On Fri, Apr 09, 1999 at 08:27:05AM -0400, tmariner wrote:
> Ran across a problem with interrupts in the Pic 16C554.
>
> There is only data ram on page 0 and one wants to access values on ram page
> 1 such as TRISB, etc. The problem is that the published interrupt context

Tom, why not just use the compiler to generate interrupt save code??? Here's
what you would get:

int_entry:
       btfsc   3,5
       goto    l30001
       movwf   saved_w
       movf    3,w
       goto    l30002
l30001
       bcf     3,5
       movwf   saved_w
       movf    3,w
       iorlw   32
l30002
       movwf   saved_status

Regards, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: spam_OUTclydeTakeThisOuTspamhtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger .....clydeKILLspamspam@spam@htsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

1999\04\09@091054 by Philippe

flavicon
face
At 08:27 09/04/99 -0400, you wrote:
>Ran across a problem with interrupts in the Pic 16C554.
>
>There is only data ram on page 0 and one wants to access values on ram page
>1 such as TRISB, etc. The problem is that the published interrupt context
>save routines (and the ones we have been using for 1000 years) presume that
>the W register can be saved on the bank which is currently in the STATUS
>register. If page 1 of ram is current then the W register gets restored with
>the value which has been "stored" in phantom ram -- which is a 0. Not real
>funny when one is trying to set an input value on a TRIS register!
>
>Anyone have a workaround context save routine? (Or a directive telling me
>not to have interrupts on when I am in page 1 of the 554?)

Nothing to do with 554,556 and 558, the only way is simply to avoid interrupt
when you are in PAGE 1, or if you are only trying to configure TRIS register,
use TRIS instruction instead of page switching.
With 558 it may be possible to save page, as there is RAM from $A0 to $BF.
Remember 558 is going to end of life and it is now better to use PIC16C622A
for mass-production.

Regards,
       Philippe.

 +----------------------------------------------------+
 |  Virtual Micro Design                              |
 |                                                    |
 | Have you tryed the fastest PIC Simulator ?         |
 | UMPS at: http://www.vmdesign.com                   |
 |                                                    |
 | Phone: ++33 559.438.458   Fax: ++33 559.438.401    |
 |                                                    |
 | E-Mail: p.techerspamKILLspamvmdesign.com                      |
 | URL:    http://www.vmdesign.com                    |
 +----------------------------------------------------+

1999\04\09@094916 by Byron A Jeff

face picon face
>
> Ran across a problem with interrupts in the Pic 16C554.
>
> There is only data ram on page 0 and one wants to access values on ram page
> 1 such as TRISB, etc. The problem is that the published interrupt context
> save routines (and the ones we have been using for 1000 years) presume that
> the W register can be saved on the bank which is currently in the STATUS
> register. If page 1 of ram is current then the W register gets restored with
> the value which has been "stored" in phantom ram -- which is a 0. Not real
> funny when one is trying to set an input value on a TRIS register!

Two or three things immediately pop to my head:

1) If it is in fact the TRIS registers that you are trying to access
specifically, then the TRIS instruction can easily be used. It won't switch
the page RAM to set TRIS.

2) You know when you're going to access something in page 1. Simply turn off
interrupts before you do a page 1 access.

3) Use FSR/INDF to access page 1. Sine the FSR is 8 bits it can access both
banks directly (actually indirectly via INDF ;-) without having to set RP0.

>
> Anyone have a workaround context save routine? (Or a directive telling me
> not to have interrupts on when I am in page 1 of the 554?)

The context save isn't really the problem. The lack of real RAM in page one
is. Nothing is going to help if you get an interrupt while on page 1 because
you have 0 bytes of RAM to retain anything about the current state. So the
best solution is to make sure that an interrupt while on page one never
occurs. The three techniques above address the problem from that standpoint.

BAJ

1999\04\09@110850 by Dwayne Reid

flavicon
face
>Ran across a problem with interrupts in the Pic 16C554.
>
>There is only data ram on page 0 and one wants to access values on ram
>page 1 such as TRISB, etc. The problem is that the published interrupt
>context save routines (and the ones we have been using for 1000 years)
>presume that the W register can be saved on the bank which is currently >in
the STATUS register.

My standard routines work with most, but NOT all PICs.  First, I define
W_SAVE at the lowest common address to all RAM pages.  You need to do this
because your gonna save W in the RAM page you were in when the ISR was
invoked.  For the 16c7x series, this is at address 0x020.  I then define
W_SAVE1 (and W_SAVE2, W_SAVE3 if necessary) at the same address in each
bank.  You will never use those defined locations in your code - they are
merely 'place holders' so that subsequent RAM allocation doesn't tromp on
them.  Also note that I use fixed equates for those addresses - you can use
CBANK for the rest of RAM allocation but not for those (you HAVE to know
where they are!).  S_SAVE, P_SAVE, F_SAVE are all on RAM page 0.  Only the
various W_SAVEs need to be on each RAM page.

I use 'clrf status' for those PICs that have more than 2 pages - its a
single instruction to clear all the RP bits.  Its already been saved by that
point so it doesn't matter what we do to it anyways.


  ORG         04H
;save W, STATUS, PCLATH, FSR
   movwf       W_SAVE          ;save w (could be on any ram page)
   movfw       STATUS          ;status reg now trashed - good copy in W
   clrf        STATUS          ;ensure ram page 0
   movwf       S_SAVE          ;good copy of status register in Page 0
   movfw       PCLATH          ;remember to also save FSR if necessary
   movwf       P_SAVE
   clrf        PCLATH          ;ensure ROM page 0

Do your ISR stuff here.  If your ISR is short and you know PCLATH always
points to the lowest area of ROM or you don't have any 'goto' instructions,
you can dump the save PCLATH stuff.  The code this was snipped from needed
it . . .

When finished with the ISR, just restore everything . . .

;restore W, STATUS, PCLATH, FSR
   movfw       P_SAVE
   movwf       PCLATH
   movfw       S_SAVE          ;saved status into W
   movwf       STATUS          ;restore status, original ram page
   swapf       W_SAVE,F        ;SWAPF does not affect status reg
   swapf       W_SAVE,W        ;restore W
   RETFIE

Like I said, this will NOT work on some of the more exotic parts.  But it
should work on the 55x parts (do check it carefully - I've not yet used that
family).

To fix your existing code, all you probably need to do is reserve the W_SAVE
locations on the other RAM pages and add the 'clrf status' just before you
save it.  Its that easy!

dwayne


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

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

1999\04\09@114835 by tmariner

flavicon
face
Hey Clyde,

I should have figured that you had already thought of the problem and
included it in your compiler? Thankfully, the production part is the F84,
but your tip is appreciated if I get locked into the 554.

Also, when am I going to learn that with a sufficiently efficient C
compiler, the need for ASM goes away. (Hey, habits die hard!)

Tom

{Quote hidden}

1999\04\11@212223 by Steve Ridley

flavicon
face
Is it true that the PIC16C558 is nearing the end of its life ? If so is the
16C622 the best alternative ?

Steve

{Original Message removed}

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