Post by thread:[PIC] Proper way of using INDF in 18F

Hi all This is the proper way of using INDF? Below is my code Address contain the SFR address the higher byte is always reference to $0F W_DATA contain the data to be written MOVLW #0x0F MOVWF FSR0H MOVF ADDRESS,W MOVWF FSR0L MOVF W_DATA,W MOVWF INDF0

> W_DATA contain the data to be written > > MOVLW #0x0F > MOVWF FSR0H > MOVF ADDRESS,W > MOVWF FSR0L > MOVF W_DATA,W > MOVWF INDF0 The 18F has the LFSR instruction too, eg if ADDRESS had the value $10 LFSR FSR0,$0F10 Depending on how complicated you want the code to be you might reference ADDRESS through INDF1 or INDF2, otherwise load FSR bytes indivually Check the manual (18F452 Section 4.12) for related mnemonics, such as POSTINCx, POSTDECx etc. These are very useful for table-type routines And MOVFF cuts one instruction (note that MOVFF has a limited source - target address range of 000 to FFF) MOVFF W_DATA,INDF0 ============================ A macro can be defined so that you could use MOVFW instead of MOVF file,W movfw macro litval movf litval,w endm

Jinx wrote : > And MOVFF cuts one instruction... But not execution time, nor program memory space. IMHO, the only "thing" with MOVFF is that it doesn't trash W (which is good enough, of course :-) ). > (note that MOVFF has a limited > source - target address range of 000 to FFF) In what way is the range 000-FFF "limited" ? Compared with what ? It's actualy *better* then MOVF/MOVWF, since MOVFF can transfer between *any* SFR or GPR no matter what the bank settings are ! (OK, that's the other big "thing" with MOVFF... :-) ) Let's say you have the USART in/out buffers in a separate bank. MOVFF can then manage these two buffers without any banking. But if you want to MOVF or MOVWF to or from W then ? No problem, use MOVFF with WREG as target or source. Still no banking... Having W mapped as the WREG SFR is another big + for the PIC18 architecture when compared with PIC16, IMHO. Any instruction which has 'f' as an operand, can also operate on W directly. Best Regards, Jan-Erik.

> > (note that MOVFF has a limited > > source - target address range of 000 to FFF) > > In what way is the range 000-FFF "limited" ? Well, when you can't go outside a certain range, that's what's known as limited Did I miss a class about an extended range MOVFF ? ????????? > Compared with what ? RETLW ? MOVF ,W ? TBLRD+ ? MOVFW INDFx ?

Agreed on all counts - the 18F architecture is a definite improvement over the earlier PIC instruction sets. Now, if they would just do away with banking completely, I for one would celebrate. RJG {Original Message removed}

On Sun, 6 Mar 2005, Jinx wrote: >> In what way is the range 000-FFF "limited" ? > > Well, when you can't go outside a certain range, that's what's > known as limited > > Did I miss a class about an extended range MOVFF ? The PIC18 architecture has a 12-bit data address space, and MOVFF covers the entire range in both source and destination address, so I'm not sure what you're getting at. >> Compared with what ? > > RETLW ? MOVF ,W ? TBLRD+ ? MOVFW INDFx ? MOVFW INDFx doesn't have more range than MOVFF. TBLRD doesn't access the data address space. -- John W. Temples, III

> > Did I miss a class about an extended range MOVFF ? > > OK. Now I'm lost here... > Why would you need that ? Buggered if I know - why would one ask "In what way is the range 000-FFF "limited" ?" ? A defined range is a limit

>> TBLRD doesn't access the data address space > No, but it address a much wider range than MOVFF But of a different address space. PIC microcontrollers are Harvard architechture. They have two(*) totally disjoint memories -- program memory (2^21 bytes maximum) and data memory (2^12 bytes maximum). TBLRD only accesses locations in the program memory space. MOVFF (and all the other MOVxx instructions) only access locations in the data memory space. > Jeez, what's going on here ? I made a simple true statement > about MOVFF........ MOVFF's 2 operands access the entire range of PIC data memory. Since there are no more _DATA_ (aka RAM) locations, you don't need to have more address bits with its operands. Lee Jones (*) technically, three disjoint memories: program memory, data memory, and stack memory (32 words, 21 bits wide) -- all disjoint & seperate. But stack memory is so specialized I will ignore it for this discussion.

Jinx wrote : > > > Did I miss a class about an extended range MOVFF ? > > > > OK. Now I'm lost here... > > Why would you need that ? > > Buggered if I know - why would one ask "In what way is > the range 000-FFF "limited" ?" ? A defined range is a limit Of course :-). But when you wrote : >> (note that MOVFF has a limited >> source - target address range of 000 to FFF) *I* read that as it was something to watch out for or to concider when using MOVFF (instead of other RAM access methods). I still don't understand what the problem is with this (artificial) limit of the address range of MOVFF. Why did you make a "note" about it at all ? English isn't my first language, but I think that this "note" might lead someone to think that there's a *real* problem... Yes, this have probably lead to far now, but, still, since I'm not concidering me to know the PIC's that well, I always want to know when it look s like I've been misunderstanding something. Best Regards, Jan-Erik.

> I still don't understand what the problem is with this > (artificial) limit of the address range of MOVFF. Why > did you make a "note" about it at all ? As Soon Lee has been asking questions about basic 18F code I assumed, and it appears, he might not be aware of MOVFF and other 16-bit instructions. I've no problem, and AFAIK there is no problem, with the range of MOVFF, it is what it is, and I simply pointed it out to him in passing

Hi all Thanks for all the inputs. I am still using teh 16F instruction set when it come to programming of 18F When to readup a bit on the 18F instruction set seem that there is some new instructions that i have not use before thanks for pointing that out Thanks you all for your responds. Regards Soon Lee {Original Message removed}

Jinx wrote: > Buggered if I know - why would one ask "In what way is > the range 000-FFF "limited" ?" ? A defined range is a limit But in the context of addressing RAM in a PIC 18, it is not a limit since RAM is in a 12 bit address space and 0-FFFh covers the entire range. In the same manner, the GOTO instruction is not limited since it covers the entire program memory address range. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com