Searching \ for '[PIC] Problems with RRF on PIC16F684' 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/devices.htm?key=16F
Search entire site for: 'Problems with RRF on PIC16F684'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Problems with RRF on PIC16F684'
2006\01\05@200054 by Sean Schouten

face picon face
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.

2006\01\05@201344 by Andre Abelian

flavicon
face
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}

2006\01\05@201954 by Mike Hagen

flavicon
face
Would you have to watch out for the carry?

----- Original Message -----
From: "Sean Schouten" <spam_OUTdev.seantechTakeThisOuTspamgmail.com>
To: "piclist" <.....piclistKILLspamspam@spam@mit.edu>
Sent: Thursday, January 05, 2006 5:00 PM
Subject: [PIC] Problems with RRF on PIC16F684


{Quote hidden}

> --

2006\01\05@202515 by Hector Martin

flavicon
face
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 (hectorspamKILLspammarcansoft.com)
Public Key: http://www.marcansoft.com/hector.asc

2006\01\05@204755 by Jinx

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

2006\01\05@205542 by Jinx

face picon face
> not putting rotated value back to TEMP_VAR register
> try
>
> RRF            TEMP_VAR,F

The default is ,F, so RRF TEMP_VAR = RRF TEMP_VAR,F

If compiling RRF TEMP_VAR with MPLAB you'll get

Message[305] : Using default destination of 1 (file).

unless you turn that off with

errorlevel -305

2006\01\05@211100 by Jose Da Silva

flavicon
face
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}

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.

2006\01\05@212414 by Sean Schouten

face picon face
On 1/6/06, Jinx <.....joecolquittKILLspamspam.....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.

2006\01\05@215138 by Hector Martin

flavicon
face
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_OUTspamTakeThisOuTmarcansoft.com)
Public Key: http://www.marcansoft.com/hector.asc

2006\01\05@220748 by kravnus wolf

picon face
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.seantechspamspam_OUTgmail.com> wrote:

{Quote hidden}

> -

2006\01\05@220820 by Peter van Hoof

face picon face


----- Original Message ----
{Quote hidden}

[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


2006\01\05@221659 by Peter van Hoof

face picon face

From: Sean Schouten RemoveMEdev.seantechTakeThisOuTspamgmail.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

2006\01\05@222039 by Jinx

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

2006\01\05@222745 by Sean Schouten

face picon face
>
> 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.

2006\01\06@002654 by William Jacobs

flavicon
face
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}

2006\01\06@024038 by Jose Da Silva

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

2006\01\06@071030 by Bill & Pookie

picon face

He who trusts the "default" would buy a goat from a gypsy.  Old German
proverb.

Pookie

{Original Message removed}

2006\01\06@092951 by Sean Schouten

face picon face
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.

2006\01\06@093245 by Sean Schouten

face picon face
>
> 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?


Sean.

2006\01\06@094912 by Alan B. Pearce

face picon face
>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.

2006\01\06@095124 by Alan B. Pearce

face picon face
>> 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?

Can be.

2006\01\06@095326 by Maarten Hofman

face picon face
> 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.

2006\01\06@095758 by Jan-Erik Soderholm

face picon face
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.



2006\01\06@100259 by Jan-Erik Soderholm

face picon face
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.



2006\01\06@110233 by Howard Winter

face
flavicon
picon face
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


2006\01\06@181934 by olin piclist

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

2006\01\06@182418 by olin piclist

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

2006\01\06@183124 by olin piclist

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

2006\01\06@194410 by William Chops Westfield

face picon face

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

2006\01\06@195509 by olin piclist

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

2006\01\06@200054 by David VanHorn

picon face
>
>
> > 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!

2006\01\06@205925 by Sean Schouten

face picon face
On 1/7/06, Olin Lathrop <spamBeGoneolin_piclistspamBeGonespamembedinc.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.

2006\01\09@082959 by Maarten Hofman

face picon face
> 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.

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