Searching \ for '[PIC] FSR translation to PIC18F4520' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=18F
Search entire site for: 'FSR translation to PIC18F4520'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] FSR translation to PIC18F4520'
2010\02\08@185655 by MCH

flavicon
face
A week or so ago, I asked for some ASM code and stated I could translate
it to my current device. Someone commented that "ASM code was ASM code"
(paraphrased) and there was no need to translate.

Well, I need some help with the "unnecessary" translation.

Here is the command in ASM for a PIC16F877A:
       INCF FSR,F

I think this translates to:
       ADDFSR        0,H'1'

But, I'm getting an error code of:
Warning[207] C:\(file).ASM 667 : Found label after column 1. (ADDFSR)

There is only a tab before the ADDFSR - just as the other lines of code.

Can anyone help me with this translation? Oh, and would I need to use
H'2' since this is an 18F to increase to the next address pointer? I
remember having to 'double' most of my relative addresses.

I'm working on something other than my fan, for which I still am trying
to determine the best solution.

Joe M.

2010\02\08@191033 by Dario Greggio

face picon face
MCH ha scritto:
> A week or so ago, I asked for some ASM code and stated I could translate
> it to my current device. Someone commented that "ASM code was ASM code"
> (paraphrased) and there was no need to translate.
>
> Well, I need some help with the "unnecessary" translation.
>
> Here is the command in ASM for a PIC16F877A:
>        INCF FSR,F
>
> I think this translates to:
>        ADDFSR        0,H'1'

sorry, totally wrong :)

INCF does exist in PIC18 , you only need to add a 3rd parameter which is
ACCESS/BANKED


> But, I'm getting an error code of:
> Warning[207] C:\(file).ASM 667 : Found label after column 1. (ADDFSR)
>
> There is only a tab before the ADDFSR - just as the other lines of code.

yep, IMO ADDFSR is not a PIC18 mnemonic, but I should check :)

> Can anyone help me with this translation? Oh, and would I need to use
> H'2' since this is an 18F to increase to the next address pointer? I
> remember having to 'double' most of my relative addresses.

totally off-road :)




--

Ciao, Dario
--
Cyberdyne

2010\02\08@191753 by Tamas Rudnai

face picon face
I think you need to switch on the extended instruction set to have
ADDFSR instruction.

Tamas


On Mon, Feb 8, 2010 at 11:56 PM, MCH <spam_OUTmchTakeThisOuTspamnb.net> wrote:
{Quote hidden}

>

2010\02\08@191928 by MCH

flavicon
face
INCF exists, but it does not like the FSR location.

Also, ADDFSR came right out of the docs for the chip, and the MPLAB says
it's valid (it turns color to a command when entered).

Joe M.

Dario Greggio wrote:
{Quote hidden}

2010\02\08@192010 by MCH
flavicon
face
Maybe I just need to change it to "INCF FSR0L,1"???

Joe M.

Dario Greggio wrote:
{Quote hidden}

2010\02\08@192605 by Dario Greggio

face picon face
MCH ha scritto:
> INCF exists, but it does not like the FSR location.
>
> Also, ADDFSR came right out of the docs for the chip, and the MPLAB says
> it's valid (it turns color to a command when entered).


yeah, as for ADDFSR I guess that Tamas is correct.
As for INDF... ah well, it may want a FSRn register (0..1..2) and L/H
too i.e. FSR0L, FSR1H

--

Ciao, Dario
--
Cyberdyne

2010\02\08@192628 by Marcel Birthelmer

picon face
What about just MOVF POSTINCn, F (move the value of INDFn to itself
(do nothing) and then increment the pointer in FSRn) ? That way you
don't have to have an extra instruction to increment FSRnH if FSRnL
rolls over.
But INCF FSRnL should definitely work, also. INCF FSRn will not (at
least not as you expect, because FSRn is just a constant for use with
the LFSR instruction, I believe.

2010\02\08@192801 by Dario Greggio

face picon face
MCH ha scritto:
> Maybe I just need to change it to "INCF FSR0L,1"???


yep (see other mail)
and do remember the access/banked thing (though implicit in this case)

--

Ciao, Dario
--
Cyberdyne

2010\02\08@193431 by MCH

flavicon
face
Ahhh! I didn't know I had to do that, but it is in the extended
instruction set part of the docs.

How do I turn it on?

Although, I may just try the "INCF FSR0L,1" instead.

Joe M.

Tamas Rudnai wrote:
{Quote hidden}

>> --

2010\02\08@195541 by Marcel Birthelmer

picon face
Joe,
I don't think you want the extended instruction set - I think it
includes some not-so-intuitive changes to how the instructions work.
There are enough other ways to increment the FSR pointer without going
to those extremes.

On Tue, Feb 9, 2010 at 1:34 AM, MCH <mchspamKILLspamnb.net> wrote:
{Quote hidden}

>>> --

2010\02\08@203945 by ivp

face picon face

> Maybe I just need to change it to "INCF FSR0L,1"???

>From memory that won't increment FSR0H when FSR0L = 255 + 1

wbr

2010\02\08@205247 by ivp

face picon face

> INCF FSR,F

POSTINC0

You'd load FSR0 with LFSR FSR0,location

When you access, via INDF0, the location that FSR0 is pointing to,
FSR0 will increment to location + 1

eg MOVF POSTINC0,W

= 16F, 8-bit  MOVF INDF,W    INCF FSR

18F have 16-bit FSRs

and eg a routine to clear 3 banks of RAM, limited by FSR0H = 1
or, IOW, location = 256

clr_ram  lfsr    fsr0,0x000 ;load FSRs
        lfsr    fsr1,0x100
        lfsr    fsr2,0x200

clear    clrf    postinc0   ;clear pointed-at locations
        clrf    postinc1
        clrf    postinc2
        btfss   fsr0h,0    ;loop until FSR0L rolls over and increments H
        bra     clear

wbr

2010\02\08@205330 by MCH

flavicon
face
I don't really need it to. I just need FSR0 to go from B0 to B6 while it
reads 7 consecutive bytes from the clock (DS1302) and stores them in the
B0-B6 addresses.

I found that the low bytes don't use the 'L', so it's just FSR0 and
FSR0H. But...

Now I'm really lost.

       MOVLW        TIME_RX_ADD
       MOVWF        FSR0

If I step through the debugger, TIME_RX_ADD (B0) is being loaded into W,
but on the next step W is not being saved to FSR0. It's acting like it's
locked or something.

I say 'not saving' since I'm looking at the file registers and it's not
changing when it executes that command. Again, I can see W changing in
the file register window, but not FSR0.

Joe M.

ivp wrote:
>> Maybe I just need to change it to "INCF FSR0L,1"???
>
>>From memory that won't increment FSR0H when FSR0L = 255 + 1
>
> wbr

2010\02\08@220230 by Bob Ammerman

picon face

> What about just MOVF POSTINCn, F (move the value of INDFn to itself
> (do nothing) and then increment the pointer in FSRn) ? That way you
> don't have to have an extra instruction to increment FSRnH if FSRnL
> rolls over.

This is a great idea, as long as you know the FSR is pointing to GPR space.
If it is pointing at an FSR (at least some of them) bad things can happen
(tm).

-- Bob Ammerman
RAm Systems

2010\02\08@223122 by MCH

flavicon
face
I'm just not getting this. Either my time is not being written, my clock
is not running, or the time is not being read. (and there is no way to
tell which it is)

Here is the PIC16 code that is supposed to work. Can anyone translate it
to PIC18 ASM code? I've tried several times - even to the point of
forgetting the loop and just making X read cycles, and everything is 0.

The ADD(ress) variables both start at H'B0' and the time variables run
to H'B6'.

I know the RRFs get changed to RRCFs.

Or, as an alternative, does anyone have working ASM code for the DS1302
clock?

Joe M.

--------------------- start of code snippet --------------

;**********************read time program*************************
; GET_TIME
; usage: recept 7 bytes time data, sudden mode read
; INPUT:NONE
; OUTPUT:save the 7 bytes into TIME_RX_ADD's 7 registers
;*********************************************************
;input parameter: none
;output parameter:20H--26H's 7 RAMs
GET_TIME
 MOVLW B'10111111'                ;multi bytes read mode
 MOVWF TIME_TX
 BSF RST
 CALL TIME_WRITE_1
 MOVLW TIME_RX_ADD                ;save bytes
 MOVWF FSR
 MOVLW D'7'                       ;read 7 bytes continuously
 MOVWF COUNT2
TR2
 CALL TIME_READ_1
 MOVF TIME_RX,W
 MOVWF INDF
 INCF FSR,F
 DECFSZ COUNT2,F
 GOTO TR2
 BCF RST
 RETURN

;**********************write a byte program*****************
; TIME_WRITE_1
; usage: send one byte only.
; used for control word etc.
;************************************************
;input parameter£ºTIME_TX
;output parameter£ºnone
TIME_WRITE_1
 MOVLW D'8'                      ;8 bits
 MOVWF COUNT1
TLOP
 BCF I_O                         ;the initial is low
 BCF SCLK
 BTFSC TIME_TX,0
 BSF I_O
 RRF TIME_TX,F
 BSF SCLK                        ;rise-edge to send data
 DECFSZ COUNT1,F
 GOTO TLOP
 BCF SCLK                        ;recover
 RETURN

;******************read one byte program*********************
; TIME_READ_1
; usage: read 1302 only one byte.
; schedule: receiving data when the falling edge comes, low byte first.
; according the I/o's high and low to select the shift right with or
without carry.
;***********************************************
; INPUT:NONE
; OUTPUT:TIME_RX

TIME_READ_1
 BANK1
 BSF TRISB,4 ;                    I_O set to input
 BANK0
 MOVLW D'8'
 MOVWF COUNT1                     ;read 8 bits.
TR1
 BCF SCLK                         ;read when falling edge
 BCF STATUS,C
 BTFSC I_O
 BSF STATUS,C
 RRF TIME_RX,F
 BSF SCLK                         ;recover high
 DECFSZ COUNT1,F
 GOTO TR1
 BANK1
 BCF TRISB,4                       ;I_O recover to output
 BANK0
 BCF SCLK
 RETURN
 NOP

--------------------- end of code snippet --------------
ivp wrote:
>> Maybe I just need to change it to "INCF FSR0L,1"???
>
>>From memory that won't increment FSR0H when FSR0L = 255 + 1
>
> wbr

2010\02\08@224151 by ivp

face picon face
> I found that the low bytes don't use the 'L', so it's just FSR0 and
> FSR0H. But...
>
> Now I'm really lost.
>
> MOVLW TIME_RX_ADD
> MOVWF FSR0
>
> If I step through the debugger, TIME_RX_ADD (B0) is being loaded into
> W, but on the next step W is not being saved to FSR0. It's acting like
> it's
> locked or something.

That's when you have to specify FSR0L, not FSR0

wbr

2010\02\08@230322 by ivp

face picon face
>  MOVLW TIME_RX_ADD                ;save bytes
> MOVWF FSR

As mentioned, specify FSR0L

>  MOVF TIME_RX,W
>  MOVWF INDF
>  INCF FSR,F

MOVFF  TIME_RX,POSTINC0

>;**********************write a byte program*****************
>; TIME_WRITE_1
<snip>
>
>  BSF I_O
>  RRF TIME_TX,F

Carry is indeterminate before that RRF

CLRC
RRCF TIME_RX   (,F is not necessary)

or use RRNCF

>  BSF STATUS,C
>  RRF TIME_RX,F

SETC
RRCF TIME_RX

Sometimes pseudo-mnemonics such as CLRC and SETC are not in the
include file. In that case make a couple of small macros and put them in
a group, say, after the CONFIG statements

clrc     macro
        bcf     status,0
        endm

setc     macro
        bsf     status,0
        endm

wbr

2010\02\08@234011 by MCH

flavicon
face
Yep. That solved part of it. It's called FSR0 in MPLAB, but you have to
write it as FSR0L.

Joe M.

ivp wrote:
{Quote hidden}

2010\02\08@234752 by MCH

flavicon
face
I haven't fully gone through the below text, but here is what seems to
be working for my set routine (B0-B6 are written with values 'earlier'
in the program):

-------------------
SET_TIME                                ;write 7 byte time data
       MOVLW        B'10111110'                ;multi bytes write mode.
       MOVWF        TIME_TX
       BSF        CLKRST
       CALL        TIME_WRITE
       CLRF        FSR0H
       MOVLW        TIME_TX_ADD                ;the start address of send data
       MOVWF        FSR0L
       MOVLW        D'8'                        ;send 8 bytes at the same time.
       MOVWF        CLKCOUNT2
TW1
       MOVFF        INDF0,TIME_TX
       CALL        TIME_WRITE
       INCF        FSR0L,1
       DECFSZ        CLKCOUNT2,1
       GOTO        TW1
       BCF        CLKRST

       RETURN
-------------------
TIME_WRITE
       MOVLW        D'8'                        ;8 bits
       MOVWF        CLKCOUNT1
TLOP
       BCF        CLKIO                        ;the initial is low
       BCF        CLKCLK
       BTFSC        TIME_TX,0
       BSF        CLKIO
       RRCF        TIME_TX,1
       BSF        CLKCLK                        ;rise-edge to send data
       DECFSZ        CLKCOUNT1,1
       GOTO        TLOP
       BCF        CLKCLK                        ;recover
       RETURN
----------------------

But, when I read the 1302, I get mostly 0s with the occasional 1 second
(yes, I've removed the breakpoints and let it run a while).

When it writes, all the values seem to be transferred to TIME_TX OK and
I can see it 'scroll' right as the RRCFs are processed.

Also note the shortcut of "MOVFF INDF0,TIME_TX" which seems to work
fine, as the value is being correctly transferred. FSR0L is incrementing
correctly now as well.

I'll go through your suggestions, too.

Joe M.

ivp wrote:
{Quote hidden}

2010\02\08@235925 by MCH

flavicon
face
Threaded...

ivp wrote:
>>  MOVF TIME_RX,W
>>  MOVWF INDF
>>  INCF FSR,F
>
> MOVFF  TIME_RX,POSTINC0

I'll change to use POSTINC0 rather than INDF0.

After that change, I'm still reading all zeros.

I have the 1302 datasheet printed out as well as my code. Time to make
sure they 'agree'.

BTW, I did check the hardware connections, and all the ports are set
correctly and wired correctly to the 1302.

{Quote hidden}

The carry bit does not matter, as only the 8 bits in the byte are
evaluated as they RR and reach bit 0.

{Quote hidden}

Again, I don't think the carry flag would matter, as only the 8 bits of
the byte are transferred to the B0-B6 location.

Joe M.

2010\02\09@002507 by ivp

face picon face
> The carry bit does not matter, as only the 8 bits in the byte are
> evaluated as they RR and reach bit 0.

OK, I had the wrong impression of what the s/w was doing. It still
doesn't hurt to appreciate as you're writing what the effects are of
instructions like rotates. Sometimes even the smallest incorrect
assumption can cause havoc and many hours of head-scratching

wbr

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