Post by thread:[PIC] FSR translation to PIC18F4520

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.

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

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_OUTmchTakeThisOuTnb.net> wrote: {Quote hidden}> 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. >

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}> 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 :) > > > > > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2676 - Release Date: 02/08/10 14:35:00 >

Maybe I just need to change it to "INCF FSR0L,1"??? Joe M. Dario Greggio wrote: {Quote hidden}> 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 :) > > > > > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2676 - Release Date: 02/08/10 14:35:00 >

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}> 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 <.....mchKILLspam@spam@nb.net> wrote: >> 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. >> --

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 <mchKILLspamnb.net> wrote: {Quote hidden}> 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: >> 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 <.....mchKILLspam.....nb.net> wrote: >>> 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. >>> --

> 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

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

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

> 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

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

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

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}>> ;**********************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 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}>> 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 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.