Post by thread:[PIC]: Context saving in ISRs

Ok, so I'm switching from the 16C71 to the 16C715. No big deal. The major hangup is that I can't ignore Bank switching anymore, since the bank 0 RAM isn't mapped in bank 1. Again, no biggie. BUT... Is it my imagination, or is this poor information from Microchip: (from the 16C71x datasheet, including C71 and C715) EXAMPLE 8-1: SAVING STATUS AND W REGISTERS IN RAM MOVWF W_TEMP ;Copy W to TEMP register, could be bank one or zero SWAPF STATUS,W ;Swap status to be saved into W MOVWF STATUS_TEMP ;Save status to bank zero STATUS_TEMP register : :(ISR) : SWAPF STATUS_TEMP,W ;Swap STATUS_TEMP register into W ;(sets bank to original state) MOVWF STATUS ;Move W into STATUS register SWAPF W_TEMP,F ;Swap W_TEMP SWAPF W_TEMP,W ;Swap W_TEMP into W I believe this is where my program is taking a dump. The first line, "could be in bank 1 or zero" is totally wrong. The W_TEMP variable *MUST* by in *BOTH* banks 0 and 1, to allow for either case when an interrupt is serviced. Am I going crazy, or is this not true? The datasheet says NOTHING MORE about how to perform context saving. Note that when the variables are restored, the original Bank is selected prior to restoring W, which is fine, *IF* you have W_TEMP available in both banks. Please slap me into reality if I'm wrong here. --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Drew Vassallo <.....snurpleKILLspam@spam@HOTMAIL.COM> writes: > (from the 16C71x datasheet, including C71 and C715) > EXAMPLE 8-1: SAVING STATUS AND W REGISTERS IN RAM > MOVWF W_TEMP ;Copy W to TEMP register, could be bank one or zero [...] > I believe this is where my program is taking a dump. The first line, "could > be in bank 1 or zero" is totally wrong. The W_TEMP variable *MUST* by in > *BOTH* banks 0 and 1, to allow for either case when an interrupt is > serviced. Yes. W_TEMP variable must be defined in the same locations in both banks. What they meant by the comment was that on any given interrupt, W might be stored in either bank zero or bank one, depending on the bank that was selected when the interrupt occurred. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

Drew Vassallo wrote: {Quote hidden}> > Ok, so I'm switching from the 16C71 to the 16C715. No big deal. The major > hangup is that I can't ignore Bank switching anymore, since the bank 0 RAM > isn't mapped in bank 1. Again, no biggie. BUT... > > Is it my imagination, or is this poor information from Microchip: > > (from the 16C71x datasheet, including C71 and C715) > > EXAMPLE 8-1: SAVING STATUS AND W REGISTERS IN RAM > > MOVWF W_TEMP ;Copy W to TEMP register, could be bank one or zero > SWAPF STATUS,W ;Swap status to be saved into W > MOVWF STATUS_TEMP ;Save status to bank zero STATUS_TEMP register > : > :(ISR) > : > SWAPF STATUS_TEMP,W ;Swap STATUS_TEMP register into W > ;(sets bank to original state) > MOVWF STATUS ;Move W into STATUS register > SWAPF W_TEMP,F ;Swap W_TEMP > SWAPF W_TEMP,W ;Swap W_TEMP into W > > I believe this is where my program is taking a dump. The first line, "could > be in bank 1 or zero" is totally wrong. The W_TEMP variable *MUST* by in > *BOTH* banks 0 and 1, to allow for either case when an interrupt is > serviced. > > Am I going crazy, or is this not true? The datasheet says NOTHING MORE > about how to perform context saving. Note that when the variables are > restored, the original Bank is selected prior to restoring W, which is fine, > *IF* you have W_TEMP available in both banks. > > Please slap me into reality if I'm wrong here. It would assume that you have a RAM register available in both banks for temp W storage in the same bank address. Example W_Temp equ 20h ; ram page 0 storage W_Temp for ram page 1 storage will occupy address 0xA0. It doesn't need to be defined, but it's purpose should be noted in the source. At the time of the IRQ the ram page bit value could be 0 or 1, so the W reg data could be stored in either 0x20 or 0xA0 - not both. When the ISR exits, the status register RP0 bit has been restored before the W_Temp register is accessed, so the correct Wreg data will be fetched from either 0x20 or 0xA0. Perhaps to verify it for yourself, write a small test routine that alters the RP0 bit after a delay loop and use the simulator and a watch window to see what happens when a TMR0 IRQ occurs. -- Best regards Tony mICros http://www.bubblesoftonline.com .....salesKILLspam.....bubblesoftonline.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Drew, The register location from 0Ch thru 2Fh are shadowed as 8Ch-AFh. 8Ch-AFh don't actually exist. When/If you try to access those locations you really access 0Ch-2Fh. So as long as your save areas are in the range of 0Ch-2Fh you will be OK. It wont matter which bank is selected when your ISR is called. Be sure to put it back in the correct bank though before exiting back to main level. ;-) Michael Brown Instant Net Solutions http://www.KillerPCs.net "In the land of the blind, he who has one eye is king" {Original Message removed}

> Drew, > The register location from 0Ch thru 2Fh are shadowed as 8Ch-AFh. 8Ch-AFh > don't actually exist. When/If you try to access those locations you really > access 0Ch-2Fh. So as long as your save areas are in the range of 0Ch-2Fh > you will be OK. It wont matter which bank is selected when your ISR is > called. Be sure to put it back in the correct bank though before exiting > back to main level. ;-) Oops don't pay any attention. I downloaded the data sheet and looked at the wrong memory map. Silly me looked at the first one I came across and that was for the 710 and 71 sorry. :-( After looking at the 715's map, I can hardly believe it. They don't appear to have any memory mapped to both banks, what a bummer. I guess you'll have to save the stuff into whichever bank is selected then check to see which bank you are in, so you know where to reload from. Looking at the map, it seems kinda strange that the second bank is smaller than the first. Only 32 bytes it looks like. I wonder why? Sorry for the bad info michael -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

Well, yeah, I tested out some variations on how I might try to get this thing to work, but really the only one that did work is the one that I "expected" to. :) In order to correctly perform context saving in chips like this (i.e. bank 0 not mapped in bank 1), you have to have the "temp" variabl locations *free* in bank 1, and locate them in bank 0 (or vice-versa). My problem was that I started using the RAM locations in Bank 1 right at the first available location, which was the same as my context-saving variable w_temp. This is a no-no. Anyways, it's all fixed. Just thought I'd bring it up in case anyone else had problems like this. These are the obscure sort of problems that you can't ferret out by pouring over your code day after day. That's what really bugs me :) It's a *conceptual* thing that varies from chip to chip (at least in the 16C71x series). --Andrew --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email @spam@listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

> MOVWF W_TEMP ;Copy W to TEMP register, could be bank one or zero The same location within all banks needs to be reserved for W_TEMP. Only one will be used per interrupt, but they all need to be available so that it works regardless of the bank setting when the interrupt occurrs. > SWAPF STATUS,W ;Swap status to be saved into W I do a CLRF STATUS here. That is a simple way to guarantee known banks. The next instruction assumes bank 0 is set, so this is a bug without at least setting the bank bit(s). > MOVWF STATUS_TEMP ;Save status to bank zero STATUS_TEMP register > : > :(ISR) > : Again, there should be a CLRF STATUS here or some other means to guarantee direct bank 0 is selected. > SWAPF STATUS_TEMP,W ;Swap STATUS_TEMP register into W > ;(sets bank to original state) > MOVWF STATUS ;Move W into STATUS register > SWAPF W_TEMP,F ;Swap W_TEMP > SWAPF W_TEMP,W ;Swap W_TEMP into W Take a look at QQQ_INTR.ASPIC at http://www.embedinc.com/pic for an example interrupt routine. That version assumes the architecture where the last 16 locations in each bank are aliases of each other. When that is not the case, W_SAVE needs to be allocated at the same relative location within each bank. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, KILLspamolinKILLspamembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

Hi Drew, I don't think anybody else has answered this question. You are correct "W_TEMP", should be at the same offset for both Banks 0 and 1. Not only this, but "STATUS_TEMP" should ALSO be at the same offset for both Banks 0 and 1. If you just wanted to have one "STATUS_TEMP", you could use the code: org 4 int movwf W_TEMP ; "W_TEMP" in Banks 0 and 1 movf STATUS, w bcf STATUS, RP0 ; Set to Bank 0 movwf STATUS_TEMP ; "STATUS_TEMP" in Bank 0 : movf STATUS_TEMP, w ; Restore "STATUS" movwf STATUS swapf W_TEMP, f ; Restore "w" without swapf W_TEMP, w ; affecting STATUS retfie Good luck with this, myke {Original Message removed}

>If you just wanted to have one "STATUS_TEMP", you could use the code: > > org 4 >int > movwf W_TEMP ; "W_TEMP" in Banks 0 and 1 > movf STATUS, w > bcf STATUS, RP0 ; Set to Bank 0 > movwf STATUS_TEMP ; "STATUS_TEMP" in Bank 0 Thanks for the info. everyone.. I actually fixed the problem right after I sent out the e-mail. It just seemed like something that should be brought up anyways. Myke, this is fine for my purposes, and any chips that have only 2 banks like the 16C71x series, but it won't work for chips with 3 or more RAM banks, for obvious reasons. I typically use the same method Olin indicated: using "clrf STATUS" to select Bank 0 after saving off the original STATUS file. --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

> org 4 >int > movwf W_TEMP ; "W_TEMP" in Banks 0 and 1 > movf STATUS, w > bcf STATUS, RP0 ; Set to Bank 0 > movwf STATUS_TEMP ; "STATUS_TEMP" in Bank 0 > > : > > movf STATUS_TEMP, w ; Restore "STATUS" > movwf STATUS > swapf W_TEMP, f ; Restore "w" without > swapf W_TEMP, w ; affecting STATUS > retfie Ouch, Myke. I just realized that this is wrong. You can't use "movf STATUS, W" because it can (and will) change the Zero bit and affect the initial STATUS value. To move it into a temp location without affecting the original STATUS register, you have to use "swapf STATUS, W" and "movwf status_temp". Then to restore it, you just "swapf status_temp, W" and then use "movwf STATUS". --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

> > org 4 > >int > > movwf W_TEMP ; "W_TEMP" in Banks 0 and 1 > > movf STATUS, w > > bcf STATUS, RP0 ; Set to Bank 0 > > movwf STATUS_TEMP ; "STATUS_TEMP" in Bank 0 > > > > : > > > > movf STATUS_TEMP, w ; Restore "STATUS" > > movwf STATUS > > swapf W_TEMP, f ; Restore "w" without > > swapf W_TEMP, w ; affecting STATUS > > retfie > > Ouch, Myke. I just realized that this is wrong. > > You can't use "movf STATUS, W" because it can (and will) change the Zero bit > and affect the initial STATUS value. To move it into a temp location > without affecting the original STATUS register, you have to use "swapf > STATUS, W" and "movwf status_temp". Then to restore it, you just "swapf > status_temp, W" and then use "movwf STATUS". Yeah, I think you _can_ use movf STATUS,W because the value it moves to W is the value BEFORE the Z bit gets tweaked. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

Not to disbelieve you Bob but just did a test with the help of my Mathias, typed in the following: bsf STATUS,Z ;Set zero bit movf STATUS,W ;Move STATUS into W register movwf STATUS ;Move W back into STATUS register bcf STATUS,Z ;Clear zero bit movf STATUS,W ;Move STATUS into W register movwf STATUS ;Move W back into STATUS register What I saw was the following: STATUS = 1A, W = xx bsf STATUS,Z ;Set zero bit STATUS = 1E, W = xx movf STATUS,W ;Move STATUS into W register STATUS = 1A, W = 1E movwf STATUS ;Move W back into STATUS register STATUS = 1E, W = 1E bcf STATUS,Z ;Clear zero bit STATUS = 1A, W = 1E movf STATUS,W ;Move STATUS into W register STATUS = 1A, W = 1A movwf STATUS ;Move W back into STATUS register STATUS = 1A, W = 1A Back to the drawing board. Bob Ammerman wrote: {Quote hidden}> > > org 4 > > >int > > > movwf W_TEMP ; "W_TEMP" in Banks 0 and 1 > > > movf STATUS, w > > > bcf STATUS, RP0 ; Set to Bank 0 > > > movwf STATUS_TEMP ; "STATUS_TEMP" in Bank 0 > > > > > > : > > > > > > movf STATUS_TEMP, w ; Restore "STATUS" > > > movwf STATUS > > > swapf W_TEMP, f ; Restore "w" without > > > swapf W_TEMP, w ; affecting STATUS > > > retfie > > > > Ouch, Myke. I just realized that this is wrong. > > > > You can't use "movf STATUS, W" because it can (and will) change the Zero > bit > > and affect the initial STATUS value. To move it into a temp location > > without affecting the original STATUS register, you have to use "swapf > > STATUS, W" and "movwf status_temp". Then to restore it, you just "swapf > > status_temp, W" and then use "movwf STATUS". > > Yeah, I think you _can_ use movf STATUS,W because the value it moves to W is > the value BEFORE the Z bit gets tweaked. > > Bob Ammerman > RAm Systems > (contract development of high performance, high function, low-level > software) > > -- > http://www.piclist.com hint: To leave the PICList > piclist-unsubscribe-requestEraseME.....mitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestmitvma.mit.edu

Damm, I should have know about the swapf. No wonder I've been having my own seperate problems for the last week. This came at a great time. Thanks for correcting your mistake, it just fixed my own. Drew Vassallo wrote: {Quote hidden}> > org 4 > >int > > movwf W_TEMP ; "W_TEMP" in Banks 0 and 1 > > movf STATUS, w > > bcf STATUS, RP0 ; Set to Bank 0 > > movwf STATUS_TEMP ; "STATUS_TEMP" in Bank 0 > > > > : > > > > movf STATUS_TEMP, w ; Restore "STATUS" > > movwf STATUS > > swapf W_TEMP, f ; Restore "w" without > > swapf W_TEMP, w ; affecting STATUS > > retfie > > Ouch, Myke. I just realized that this is wrong. > > You can't use "movf STATUS, W" because it can (and will) change the Zero bit > and affect the initial STATUS value. To move it into a temp location > without affecting the original STATUS register, you have to use "swapf > STATUS, W" and "movwf status_temp". Then to restore it, you just "swapf > status_temp, W" and then use "movwf STATUS". > > --Andrew > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > -- > http://www.piclist.com hint: To leave the PICList > RemoveMEpiclist-unsubscribe-requestEraseMEEraseMEmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestspam_OUTKILLspammitvma.mit.edu

Mark Newland wrote: > > Yeah, I think you _can_ use movf STATUS,W because the value it moves to W is > > the value BEFORE the Z bit gets tweaked. > > What I saw was the following: > > STATUS = 1A, W = xx > bsf STATUS,Z ;Set zero bit > STATUS = 1E, W = xx > movf STATUS,W ;Move STATUS into W register > STATUS = 1A, W = 1E Isn't that just what Bob mentioned?? The original STATUS value is preserved in W and thus can be restored later on. -- Best regards Tony mICros http://www.bubblesoftonline.com RemoveMEsalesTakeThisOuTspambubblesoftonline.com -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu

The key word was his third word. He said "I think", not "I KNOW". Based on that word, it cast SOME doubt in my mind as to the accuracy of his statement. I even said that I didn't "disbelieve" him but if I go around in life believing EVERYTHING I am told without testing it's accuracy, then I would be a sucker for sure. Tony Nixon wrote: {Quote hidden}> Mark Newland wrote: > > > > Yeah, I think you _can_ use movf STATUS,W because the value it moves to W is > > > the value BEFORE the Z bit gets tweaked. > > > > > What I saw was the following: > > > > STATUS = 1A, W = xx > > bsf STATUS,Z ;Set zero bit > > STATUS = 1E, W = xx > > movf STATUS,W ;Move STATUS into W register > > STATUS = 1A, W = 1E > > Isn't that just what Bob mentioned?? > > The original STATUS value is preserved in W and thus can be restored > later on. > > -- > Best regards > > Tony > > mICros > http://www.bubblesoftonline.com > RemoveMEsalesKILLspambubblesoftonline.com > > -- > http://www.piclist.com hint: To leave the PICList > piclist-unsubscribe-requestSTOPspamspam_OUTmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestSTOPspamEraseMEmitvma.mit.edu

> > > movf STATUS_TEMP, w ; Restore "STATUS" > > > movwf STATUS > > > swapf W_TEMP, f ; Restore "w" without > > > swapf W_TEMP, w ; affecting STATUS > > > retfie >Yeah, I think you _can_ use movf STATUS,W because the value it moves to W >is >the value BEFORE the Z bit gets tweaked. Good point. In retrospect, perhaps I was confusing the STATUS saving with the W saving, for which swapf is definitely needed. Either way seems to work, I guess. --Andrew _________________________________________________________________ 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

Bob Ammerman wrote: > > Yeah, I think you _can_ use movf STATUS,W because the value it > > moves to W is the value BEFORE the Z bit gets tweaked. and Mark Newland <KILLspamPICLISTspamBeGonemitvma.mit.edu> replied: {Quote hidden}> Not to disbelieve you Bob but just did a test with the help of my > Mathias, typed in the following: > > bsf STATUS,Z ;Set zero bit > movf STATUS,W ;Move STATUS into W register > movwf STATUS ;Move W back into STATUS register > bcf STATUS,Z ;Clear zero bit > movf STATUS,W ;Move STATUS into W register > movwf STATUS ;Move W back into STATUS register > > What I saw was the following: > > STATUS = 1A, W = xx > bsf STATUS,Z ;Set zero bit > STATUS = 1E, W = xx Ok, that worked. BSF sets the Z bit. > movf STATUS,W ;Move STATUS into W register > STATUS = 1A, W = 1E That worked, too. W holds the state of the STATUS register before the movf clears the Z flag, and the Z flag gets cleared as a result of the movf. > movwf STATUS ;Move W back into STATUS register > STATUS = 1E, W = 1E That worked, too. W is correctly copied to STATUS, W is unchanged, and movwf doesn't affect the Z flag. > bcf STATUS,Z ;Clear zero bit > STATUS = 1A, W = 1E Works again. The Z flag is cleared and W is unchanged. > movf STATUS,W ;Move STATUS into W register > STATUS = 1A, W = 1A Again, this works. W holds the state of the STATUIS register, and the Z flag is still clear, since 1A is non-zero. > movwf STATUS ;Move W back into STATUS register > STATUS = 1A, W = 1A Works. W is correctly copied to STATUS. > Back to the drawing board. Why, when this works so well? -Andy === Andrew Warren --- EraseMEaiwEraseMEcypress.com === IPD Systems Engineering, CYSD === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Andrew Warren wrote: > Bob Ammerman wrote: > > > > Yeah, I think you _can_ use movf STATUS,W because the value it > > > moves to W is the value BEFORE the Z bit gets tweaked. > > and Mark Newland <@spam@PICLIST@spam@spam_OUTmitvma.mit.edu> replied: > > > [test results snipped] > > Works. W is correctly copied to STATUS. > > > Back to the drawing board. > > Why, when this works so well? > > -Andy (commenting to myself and my code) DAMN FU#E(&$% INTERRUPT ROUTINE!!!! Not so much asking for help but commenting on my problem. My multi-function 50 page program is working just PERFECT when RB0 is stable. However, when I turn on the frequency generator to simulate engine RPM's, it gives intermittent errors at various portions of the program. I know that the interrupt routine is being called just fine when I get a transition on RB0 but I must not be saving or restoring something correctly. Hence, my original thought of proper interrupt coding is correct on saving and restoring the STATUS register and it's back to the drawing board to figure out what is truly wrong. The test was just one of many in the troubleshooting process. Next I will only enable the interrupt routine for one section of the program at a time to see if it truly is a common problem to the interrupt routine. I will then turn off the freq. generator and force an interrupt at various portions of the program and watch the interrupt routine one line at a time to see how it reacts (I.E. is it a memory banking problem or a program paging problem?). I mention this only to encourage newbies that debugging step by step, line by line is sometimes the easiest way to truly find out what is going on so you can solve your problem. It may be a pain in the butt, but sometimes it must be done. P.S. I will not be afraid to ask for help ONLY after I have given up trying to solve it myself. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Hello PIC.ers, YAG (Yet Another Gotcha) Some kind soul solved this for me a while back & all my multibank 16f877 projects - with 4 ram banks each - now incorporate this setup. The cblock 0x71 .. ensures that int. service context save is done on fregs that are common to all the banks. 0x70 should not be used if you want to debug with the ICD. ;bank0 general purpose register definitions NB. for 16f84 this starts @ ;0x0C, for 16f877 or 16c74 it's 0x20 cblock 0x20 m_porta ;mirror of port a m_portb ;mirror of port b . . yada yada da.. . . zzzzzzzz ;just a marker reg., don't over-reach ;freg 0x070 in bank0 if using ICD endc if zzzzzzzz >= 0X070 messg "BANK 0 IS FULL !!" endif cblock 0x71 ;highest 16 bytes common across all banks save_s ;allowing isr context save no matter the bank save_w ; 0x70 is NOT used. Reserved for the ICD. tempW pclath_save endc ;bank1 fregisters cblock 0xA0 ;bank1 fregs start at 0xA0 lcd_obuff lcd_template_index . yada yada da.. >Date: Mon, 25 Jun 2001 13:52:46 -0400 >From: myke predko <spamBeGonemykeKILLspamPASSPORT.CA> >Subject: Re: [PIC]: Context saving in ISRs > >Hi Drew, >I don't think anybody else has answered this question. >You are correct "W_TEMP", should be at the same offset for both Banks 0 and 1. > >Not only this, but "STATUS_TEMP" should ALSO be at the same offset for both >Banks 0 and 1. > best regards, John JOTD "If you have spots before your eyes, shouldn't you see a doctor? " "No, only spots." e-mail from the desk of John Sanderson, JS Controls. Snailmail: PO Box 1887, Boksburg 1460, Rep. of South Africa. Tel/fax: Johannesburg 893 4154 Cellphone no: 082 741 6275 email: .....jsandspam_OUTpixie.co.za Manufacturer & purveyor of laboratory force testing apparatus, and related products and services. -- 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

At 09:54 PM 6/25/01 -0400, Drew Vassallo wrote: >> org 4 >>int >> movwf W_TEMP ; "W_TEMP" in Banks 0 and 1 >> movf STATUS, w > >Ouch, Myke. I just realized that this is wrong. > >You can't use "movf STATUS, W" because it can (and will) change the Zero bit >and affect the initial STATUS value. Actually, the above works just fine. What happens is that the original value contained in STATUS gets moved to W. Only after it is in W does STATUS get updated, by which time you don't care anymore because you have a good copy sitting there in W. My normal sequence is: (14 bit core devices) movwf W_SAVE ;save W on whatever page we happen to be in movfw STATUS ;good copy of status in W, status reg now trashed clrf STATUS ;now select ram page 0 movwf S_SAVE ;save status Exiting the ISR is just the reverse: movfw S_SAVE ;get save copy of status movwf STATUS ;status now restored, including current ram page swapf W_SAVE,F ;pre-swap saved copy of W swapf W_SAVE,W ;swap saved copy again, now putting it into W Again, note that you have to reserve W_SAVE on each ram page, at the same offset as page 0. I use W_SAVE1, W_SAVE2, W_SAVE3 to avoid assembler errrors. dwayne Dwayne Reid <TakeThisOuTdwayner.....TakeThisOuTplanet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 17 years of Engineering Innovation (1984 - 2001) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 PICList is archived three different ways. See http://www.piclist.com/#archives for details.