Post by thread:[PIC] Problems with RRF on PIC16F684

Hi guys, What seems to be no more than perhaps a simple logical operation seems to defy my logic. Using the following code in a small loop, I don't seem to be getting the desired-output when monitoring the W-Register: [code] START MOVLW 0xFF MOVWF TEMP_VAR MAIN NOP MOVF TEMP_VAR, W RRF TEMP_VAR GOTO MAIN [/code] What I want to happen is this: 11111111 01111111 10111111 11011111 11101111 11110111 etc.... What happens is more like: 11111111 01111111 10000000 11000000 11000001 11100001 11100010 Does anybody have any idea what could be going wrong, because I am really lost. Thanks, Sean.

Sean, I do not use asm any more but my first noticeable thing is that you are not putting rotated value back to TEMP_VAR register try RRF TEMP_VAR,F Andre Abelian Sean Schouten wrote: {Quote hidden}>Hi guys, > >What seems to be no more than perhaps a simple logical operation seems to >defy my logic. > >Using the following code in a small loop, I don't seem to be getting the >desired-output when monitoring the W-Register: > >[code] > >START > > MOVLW 0xFF > MOVWF TEMP_VAR > > >MAIN > > NOP > MOVF TEMP_VAR, W > RRF TEMP_VAR > > GOTO MAIN > >[/code] > > >What I want to happen is this: > >11111111 >01111111 >10111111 >11011111 >11101111 >11110111 > >etc.... > > >What happens is more like: > >11111111 >01111111 >10000000 >11000000 >11000001 >11100001 >11100010 > > >Does anybody have any idea what could be going wrong, because I am really >lost. > >Thanks, > >Sean. > >

Would you have to watch out for the carry? ----- Original Message ----- From: "Sean Schouten" <spam_OUTdev.seantechTakeThisOuTgmail.com> To: "piclist" <.....piclistKILLspam@spam@mit.edu> Sent: Thursday, January 05, 2006 5:00 PM Subject: [PIC] Problems with RRF on PIC16F684 {Quote hidden}> Hi guys, > > What seems to be no more than perhaps a simple logical operation seems to > defy my logic. > > Using the following code in a small loop, I don't seem to be getting the > desired-output when monitoring the W-Register: > > [code] > > START > > MOVLW 0xFF > MOVWF TEMP_VAR > > > MAIN > > NOP > MOVF TEMP_VAR, W > RRF TEMP_VAR > > GOTO MAIN > > [/code] > > > What I want to happen is this: > > 11111111 > 01111111 > 10111111 > 11011111 > 11101111 > 11110111 > > etc.... > > > What happens is more like: > > 11111111 > 01111111 > 10000000 > 11000000 > 11000001 > 11100001 > 11100010 > > > Does anybody have any idea what could be going wrong, because I am really > lost. > > Thanks, > > Sean. > --

Sean Schouten wrote: > Hi guys, > > What seems to be no more than perhaps a simple logical operation seems to > defy my logic. > > Using the following code in a small loop, I don't seem to be getting the > desired-output when monitoring the W-Register: > Is that the complete code? Are you running it on a simulator or do you have output code and are running it on the real thing? How do you define TEMP_VAR? Also, you might want to make sure C is clear before RRF. But that shouldn't cause the result you mention (although, if set, the output would always be 0xFF) -- Hector Martin (hectorKILLspammarcansoft.com) Public Key: http://www.marcansoft.com/hector.asc

> What I want to happen is this: > > 11111111 > 01111111 > 10111111 > 11011111 > 11101111 > 11110111 I tried this in MPLAB movlw 0xff movwf temp_var clrc main nop movf temp_var,w rrf temp_var goto main and do get what you want - a rotating 0. clrc before 'main' guarantees this. If you don't use clrc it's 50:50, depending on the status of C before you start. Effectively you have a 9-bit shift register, and if all bits are 1, they'll stay 1, no matter how many rotates you do I have absolutely no idea how you get this 11111111 01111111 10000000 11000000 11000001 11100001 11100010 Something else is going on. It doesn't appear to be random, but it's not entirely a repeating shift effect either

On January 5, 2006 05:00 pm, Sean Schouten wrote: > Hi guys, > > What seems to be no more than perhaps a simple logical operation > seems to defy my logic. > > Using the following code in a small loop, I don't seem to be getting > the desired-output when monitoring the W-Register: > > [code] > > START > > MOVLW 0xFF > MOVWF TEMP_VAR ;where is TEMP_VAR located? clrc ;clear the carry bit (bcf status,c) {Quote hidden}> MAIN > > ;not needed unless you want to waste time NOP > MOVF TEMP_VAR, W ;just watching, not needed > RRF TEMP_VAR, F ;no guessed destination > > GOTO MAIN > > [/code] > > > What I want to happen is this: > > 11111111 > 01111111 > 10111111 > 11011111 > 11101111 > 11110111 > > etc.... > > > What happens is more like: > > 11111111 > 01111111 ;okay so far... > 10000000 ;if "stepping" find this hard to believe > 11000000 > 11000001 > 11100001 > 11100010 > > > Does anybody have any idea what could be going wrong, because I am > really lost. Where is your TEMP_VAR located? It should not be a special location like a port or anything hardware related, but simply a plain register.

On 1/6/06, Jinx <.....joecolquittKILLspam.....clear.net.nz> wrote: > > > not putting rotated value back to TEMP_VAR register > > try > > > > RRF TEMP_VAR,F > > Ah, I have it like that in my program, seem to have *ovelooked* the , F in the email though. Jinx; I just tried clearing C-bit before running the main-loop. Stil the same problem. I fear that it might be another problem indeed! Hector: I am simulating it in MPLAB, because it doesn't work like I want it to on the real thing. I define TEMP_VAR like so: TEMP_VAR RES 1. Sean.

Sean Schouten wrote: > Hector: I am simulating it in MPLAB, because it doesn't work like I want it > to on the real thing. I define TEMP_VAR like so: TEMP_VAR RES 1. Make sure you've got the right PIC selected, and that it's address is set so something on the general purpose register range. You can temporarily try something like TEMP_VAR EQU 0x30 instead of using RES. (note: the start of GPRs is 0x20 on that PIC, so that should work too) If that works, RES is putting your data somewhere where you don't want it. Check the linker file. You can also paste the .hex file, and I can check it with a disassembler to see if there is something weird in the addresses. -- Hector Martin (EraseMEhectorspam_OUTTakeThisOuTmarcansoft.com) Public Key: http://www.marcansoft.com/hector.asc

What is the location of the TEMP_VAR from the map file? Is it possible that some other code writing over it? John --- Sean Schouten <dev.seantechspam_OUTgmail.com> wrote: {Quote hidden}> On 1/6/06, Jinx <@spam@joecolquittKILLspamclear.net.nz> wrote: > > > > > not putting rotated value back to TEMP_VAR > register > > > try > > > > > > RRF TEMP_VAR,F > > > > Ah, I have it like that in my program, seem to > have *ovelooked* the , F in > the email though. > > Jinx; I just tried clearing C-bit before running the > main-loop. Stil the > same problem. I fear that it might be another > problem indeed! > > Hector: I am simulating it in MPLAB, because it > doesn't work like I want it > to on the real thing. I define TEMP_VAR like so: > TEMP_VAR RES 1. > > Sean. > -

----- Original Message ---- {Quote hidden}>From: Sean Schouten KILLspamdev.seantechKILLspamgmail.com >Hi guys, >What seems to be no more than perhaps a simple logical operation seems to >defy my logic. >Using the following code in a small loop, I don't seem to be getting the >desired-output when monitoring the W-Register: >[code] >START > MOVLW 0xFF > MOVWF TEMP_VAR >MAIN > NOP > MOVF TEMP_VAR, W > RRF TEMP_VAR > GOTO MAIN >[/code] [snip] here is what I tested in the simulator TEMP_VAR EQU 0x20 ;for this code must be gp reg in bank 0 START MOVLW 0xFF MOVWF TEMP_VAR clrc ;clear the carry or there will be not 0 bir rotating around MAIN NOP ;not needed MOVF TEMP_VAR, W ;not needed RRF TEMP_VAR ;going to file as default GOTO MAIN end It works for me Note the remarks at the equ (bank 0 gp reg= 0x20 to 0x7F) the line movf temp_var,w does nothing. Peter van Hoof

From: Sean Schouten RemoveMEdev.seantechTakeThisOuTgmail.com [snip] Hector: I am simulating it in MPLAB, because it doesn't work like I want it to on the real thing. I define TEMP_VAR like so: TEMP_VAR RES 1. [snip] Sean, Be carefull Res only works in relocatable code have to use a linker file etc. I'm sure Olin will be all over me but to attempt to understand assembler absolute code is easyer. Peter van Hoof

BTW, you realise that after 8 shifts, temp_var = 11111111 and the 0 will be in C ? If you want 11111101 11111110 01111111 10111111 without 11111111 in the middle, you'll have use a more complicated loop testing C=0, eg include a skpc or skpnc conditional branch after RRF TEMP_VAR,W if you don't want 11111111 ever to be in TEMP_VAR whilst looping As for your problem, are interrupts on or something ? If TEMP_VAR is being sent to a port (or especially if you're attempting to rotate the port register itself), watch out for r-m-w, and use a shadow register instead

> > Res only works in relocatable code have to use a linker file etc. > I'm sure Olin will be all over me but to attempt to understand assembler > absolute code is easyer. Hmmm, I am missing the linker-file so I guess that that's where I screw up. I need to learn more about relocatable programming and linker-scripts. Anyhow, it's high time for me to say goodnight; I will try the absolute aproach to see if it does work for me tomorrow. Thanks, and I will keep you updated. Sean.

Sean, [code] START MOVLW 0xFF MOVWF TEMP_VAR :You might want to put this here just for insurance clrf status,carry MAIN NOP MOVF TEMP_VAR, W RRF TEMP_VAR GOTO MAIN [/code] RRF TEMP_VAR this will be interpered as RRF TEMP_VAR,F This will operate on the file, not the W. you should use RRF TEMP_VAR,W bill Sean Schouten wrote: {Quote hidden}>Hi guys, > >What seems to be no more than perhaps a simple logical operation seems to >defy my logic. > >Using the following code in a small loop, I don't seem to be getting the >desired-output when monitoring the W-Register: > >[code] > >START > > MOVLW 0xFF > MOVWF TEMP_VAR > > >MAIN > > NOP > MOVF TEMP_VAR, W > RRF TEMP_VAR > > GOTO MAIN > >[/code] > > >What I want to happen is this: > >11111111 >01111111 >10111111 >11011111 >11101111 >11110111 > >etc.... > > >What happens is more like: > >11111111 >01111111 >10000000 >11000000 >11000001 >11100001 >11100010 > > >Does anybody have any idea what could be going wrong, because I am really >lost. > >Thanks, > >Sean. > >

On January 5, 2006 07:27 pm, Sean Schouten wrote: > > Res only works in relocatable code have to use a linker file etc. > > I'm sure Olin will be all over me but to attempt to understand > > assembler absolute code is easyer. Actually, it also works in the older DOS mpasm, so it's not as recent you think. ;-) Other processors may have different terminologies, for example motorola used rmb, so this instruction has been around quite a while now. > Hmmm, I am missing the linker-file so I guess that that's where I > screw up. I need to learn more about relocatable programming and > linker-scripts. Anyhow, it's high time for me to say goodnight; I > will try the absolute aproach to see if it does work for me tomorrow. relocatable programming is a bit harder to learn at 1st, but better in the long run and works fine in MPlab or MPASM. Because you are starting-out, you can cheat by using the 0x20 suggested by someone, but instead of equ, what you do is "org" so that you can use "res", like this: org 0x20 ;"hard-coded" start of ram area TEMP_VAL res 1 ;temporary value 1 location @0x20 TEMP_VAL2 res 1 ;2nd temp val @0x21 TEMP_VAL_BIG res 4 ;this is a large temp val @0x22 TMP_VAL4 res 1 ;another value @0x26 I would suggest compiling the above as part of your code and showing a list file. That should help you get an idea about the res mneumonic. You'll note that if you want to access the large value TEMP_VAL_BIG above, you can access it like this: movf TEMP_VAL_BIG,W movf TEMP_VAL_BIG+1,W movf TEMP_VAL_BIG+2,W movf TEMP_VAL_BIG+3,W

Okay, update! I just switched to using the Special Function Registers window as opposed to the Watch. I just found that you can actually see 'binary' there. Same thing happened as before. I made one discovery: The W-Register (which contains TEMP_VAR data, as you know) roughly seemed to be *following* what the TMR0 register was doing. My conclusion was that there must be something messed-up with my usage of the RES function and thus my memory addressing. I switched to hard coding the address; TEMP_VAR equ 0x020. That works! I am now thinking that using RES does not work without having a linker script? Is that a correct assumption? Can anyone point me to good material (tutorial / real world example) on dynamic code and / or linker scripts? How does the RES directive work when the assembler / linker sees that you have a variable that you must access in two banks? Does it register that variable in both banks or do you still have to pay much attention to bank switching? Sean.

>How does the RES directive work when the assembler / >linker sees that you have a variable that you must >access in two banks? Does it register that variable >in both banks or do you still have to pay much >attention to bank switching? You still have to pay attention to which bank you allocate it to, and to bank switching in your code. However much of this can be automated to a reasonable degree. Have a look at the development environment that Olin has at http://www.embedinc.com/pic/ and download it. Study the module files and macros. The macro functionality is easiest studied by getting the PDF file from Jan-Eriks page, that Olin links to. I am not sure if this file is up to Olins latest release, but much of it is still relevant if not.

> Is relocatable ("dynamic") code just as efficient as absolute code? Depends on what you call "efficiency". Here is a short list: 1) Relocatable code, in its basic form, is apt to add additional code for bank switching and page switching. Code will therefore generally be longer and slightly slower. However, most of this can be mostly prevented with good macros, proper grouping and a good linker script. 2) Relocatable code can allow local variables, which, if you don't have a proper design in advance, means that you will be much more flexible in reusing registers. This increases the amount of registers that you would have available. 3) Relocatable code makes it easier for the code writer to reuse code, and can increase development speed considerably (lots of efficiency there). 4) Relocatable code makes it easier to move code from one PICmicro to another PICmicro, which means that if you don't have a proper design in advance, you can easily migrate to something more suitable for your application. 5) Relocatable code is not more difficult to write than absolute code. In the beginning you can use a linker script from Microchip, once you understand the concepts you can use more efficient methods (with no need to rewrite your code). I'm sure others will add more items to this list. In my life so far I have discovered only one application that required absolute code, and that was just a crazy attempt at scraping all the performance I could out of a 16F628A, which is not something I'd recommend to anyone (moving to an 18F would be a much saner solution). Greetings, Maarten Hofman.

Sean Schouten wrote : > My conclusion was that there must be > something messed-up with my usage of the RES function and > thus my memory addressing. I switched > to hard coding the address; TEMP_VAR equ 0x020. That works! Good debugging practice, but not the best long time solution. > I am now thinking that using RES does not work without > having a linker script? Having a linker script = reloc code. No linker script = abs code. And the syntax of the acual code must match. The syntax for RES in the two "modes" are in the MPASM/MPLINK manual. But as they says : "The most common usage for RES is for data storage in relocatable code." > Is that a correct assumption? Can anyone point me to > good material (tutorial / real world example) on dynamic > code and / or linker scripts? The MPASM/MPLINK manual has plenty of examples. > How does the RES directive work when the assembler / linker > sees that you have a variable that you must access in two banks? > Does it register that variable in both banks or do you still have to > pay much attention to bank switching? Check the MPASM/MPLINK manual. It depends on which of UDATA, UDATA_ASC, UDATA_OVR and UDATA_SHR you use. > Is relocatable ("dynamic") code just as efficient as absolute code? The difference is i the source code, the processor sees no difference. Reloc code is often more efficient to write and maintain, thought... Anyway, reloc code isn't much harder to write then abs code, just a little different. Whichever you learn first, will be the your natural selection later on. Jan-Erik.

Alan B. Pearce wrote : > Have a look at the development environment > that Olin has at http://www.embedinc.com/pic/ and download it. > Study the module files and macros. Which could be a bit overkill if you're just about to learn reloc mode from the start. Might be better to learn it from the ground without a second (quite complex) layer in between. > The macro functionality is easiest studied by getting > the PDF file > from Jan-Eriks page, that Olin links to. > I am not sure if this file is up to Olins latest release, It isn't... > but much of it is still relevant if not. The general framework is probably the same, but with added macros and device support. Jan-Erik.

Sean, On Fri, 6 Jan 2006 15:32:44 +0100, Sean Schouten wrote: > > relocatable programming is a bit harder to learn at 1st, but better in > > the long run and works fine in MPlab or MPASM. > > > > Is relocatable ("dynamic") code just as efficient as absolute code? In the PIC world, relocatable code isn't dynamic! Addresses are resolved at Link, rather than Compile, time, so the executable file (*.HEX) uses fixed addresses, and is indistinguishable from code written as absolute in the first place. You're thinking of mainframe-style relocatable code, where the executable code is relocatable, and has its addresses resolved as it's loaded into memory - PICs don't do that! Cheers, Howard Winter St.Albans, England

Sean Schouten wrote: > START > > MOVLW 0xFF > MOVWF TEMP_VAR > > > MAIN > > NOP > MOVF TEMP_VAR, W > RRF TEMP_VAR > > GOTO MAIN You should add BCF STATUS,C and BANKSEL TEMP_VAR right after START. Without the first you might get all 1s, and the lack of the second may well be causing your problem. NEVER FORGET BANKING on PIC 16. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

Sean Schouten wrote: > I just switched to using the Special Function Registers window as > opposed to the Watch. I just found that you can actually see 'binary' > there. Just like in the watch window. You can adjust how the VALUE column is displayed. > Same thing happened as before. I made one discovery: The > W-Register (which contains TEMP_VAR data, as you know) roughly seemed > to be *following* what the TMR0 register was doing. Again, could be lack of attention to the bank setting. > My conclusion was > that there must be something messed-up with my usage of the RES > function and thus my memory addressing. I doubt there is anything wrong with RES, but you do have to consider what bank variables are in. > I switched to hard coding the address; Yecch! Now that you've got it working, learn to do it right and understand why the other case didn't work. > I am now thinking that using RES does not work without having a linker > script? Just like the manual says. However, how did your code ever get built to a HEX file? > Can anyone point me to good > material (tutorial / real world example) on dynamic code and / or > linker scripts? The manual (big surprise). It's called something like MPASM with MPLIB and MPLINK. > How does the RES directive work when the assembler / linker sees > that you have a variable that you must access in two banks? Does it > register that variable in both banks or do you still have to pay much > attention to bank switching? Read the manual before asking such questions. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

Maarten Hofman wrote: > 1) Relocatable code, in its basic form, is apt to add additional code > for bank switching Completely untrue. Bank switching is required when you go back and forth between locations in different banks. This has nothing to do with absolute versus relocatable mode. You generally do assume that anything outside the current module can be in another code page. However, that is only because you have the option of letting the linker place the modules. If you really want to, you can force specific modules to specific pages, then not include PCLATH diddling when you go between modules known to be on the same page. This is no worse than absolute mode where you manually allocate the location of everything. At least with modules on fixed pages in relocatable mode you can still gurantee that no code section crosses a page boundary. There is no way to automatically guarantee that in absolute mode. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

On Jan 6, 2006, at 3:31 PM, Olin Lathrop wrote: >> 1) Relocatable code, in its basic form, is apt to add >> additional code for bank switching > > Completely untrue. Bank switching is required when you go back > and forth between locations in different banks. This has > nothing to do with absolute versus relocatable mode. > My impression is that "relocatable" code is apt to insert bank switching or page switching code in instances where absolute code could have been hand-optimized (with the usual chance of being done wrong, of course) to avoid them because it "knew" that the register or code destination was in the same page. Is that wrong? BillW

William Chops Westfield wrote: > My impression is that "relocatable" code is apt to insert bank > switching or page switching code in instances where absolute > code could have been hand-optimized (with the usual chance of > being done wrong, of course) to avoid them because it "knew" > that the register or code destination was in the same page. > > Is that wrong? Yes. Relocatable mode is mostly a superset of absolute mode. You can nail variables to specific addresses if you want, but you also have the option of only nailing them to a bank and let the linker place it within the bank and also tell you if you tried to put too many variables in that bank. In the system I use, I know at assembly time what bank every variable is in, but not its specific address. If you let variables float anywhere, then yes your code would likely contain more bank switching instructions. But that's not a result of relocatable mode but the fact that you didn't specify banks at assembly time. Relocatable mode does not force you to let variables float. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

> > > > Completely untrue. Bank switching is required when you go back > > and forth between locations in different banks. This has > > nothing to do with absolute versus relocatable mode. > > > My impression is that "relocatable" code is apt to insert bank > switching or page switching code in instances where absolute > code could have been hand-optimized (with the usual chance of > being done wrong, of course) to avoid them because it "knew" > that the register or code destination was in the same page. I'm so glad I don't have to deal with this sort of thing :) No pages, no holes, no problem!

On 1/7/06, Olin Lathrop <spamBeGoneolin_piclistspamBeGoneembedinc.com> wrote: > Yecch! Now that you've got it working, learn to do it right and > understand > why the other case didn't work. > Haha, I still have a lot to learn! Especially when it comes to relocatable code. Lots and lots of manual reading and "trial and error coding" ahead! I am happy that my ultra-simple PWM algorithm works, which means that I am well on the way to 'completing' another piece of code for my first pic-based project. The next step would be to turn whatever code I allready have in to modular code, once I start to grasp the basics of whatever it is I need to know to accomplish such a feat. Sean.

> Maarten Hofman wrote: > > 1) Relocatable code, in its basic form, is apt to add additional code > > for bank switching > > Completely untrue. Bank switching is required when you go back and forth > between locations in different banks. This has nothing to do with absolute > versus relocatable mode. > > You generally do assume that anything outside the current module can be in > another code page. However, that is only because you have the option of > letting the linker place the modules. If you really want to, you can force > specific modules to specific pages, then not include PCLATH diddling when > you go between modules known to be on the same page. With "in its basic form" I meant: while letting the linker decide how to place modules. I agree that if you plan these things better, the result can almost always be the same as absolute code (which I also mentioned in my original Email). I actually like this "basic form" which allows me to worry less about these sort of details. Greetings, Maarten Hofman.