Truncated match.
PICList
Thread
'Pic 16C554 and Interrupts'
1999\04\09@082907
by
tmariner
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
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_OUTclydeTakeThisOuT
htsoft.com | Phone Fax
WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885
PGP: finger .....clydeKILLspam
@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
|
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.techer
KILLspamvmdesign.com |
| URL: http://www.vmdesign.com |
+----------------------------------------------------+
1999\04\09@094916
by
Byron A Jeff
>
> 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
|
>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 <.....dwaynerKILLspam
.....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
|
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}> 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:
EraseMEclydespam_OUT
TakeThisOuThtsoft.com | Phone Fax
> WWW:
http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885
> PGP: finger
clyde
spam_OUThtsoft.com | AUS: +61 7 3355 8333 +61 7
> 3355 8334
> --------------------------------------------------------------
> -------------
> HI-TECH C: compiling the real world.
>
1999\04\11@212223
by
Steve Ridley
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...