Post by thread:[PIC] 16F to 18F

Once you've gone to 18F you'll find it hard to go back to 16F - much nicer chips. Main gotchas : Don’t need paging for the majority of programming Don’t try the "goto $-1" command - it doenst work just use labels and go to them RLF replaced by RLCF RRF replaced by RRCF Table lookups are different And a fair few more but I'd much rather go for the 18F over the 16F now :) Dom -----Original Message----- From: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu] On Behalf Of Peter Onion Sent: 18 July 2005 10:56 To: Microcontroller discussion list - Public. Subject: Re: [PIC] 16F to 18F On Mon, 2005-07-18 at 14:09 +1200, Jinx wrote: > http://ww1.microchip.com/downloads/en/AppNotes/00716a.pdf I'de been looking for something like that as well, so thanks for posting the link. Peter

I've been using 18F in all but the most cost sensitive applications. Most code just moves over. A couple more things to watch: 1. In goto tables (state machine, etc.), use the bra instruction instead of goto (it's shorter). Also, since instructions start on even addresses, you need to do a RLNCF before adding to PCL. 2. The incf instruction does different things to status flags, so watch out! As I recall, the 18F incf affects more status flags, and some existing 16F code counts on those flags not being affected. As stated by others, the 18F is much easier to work with! Harold {Quote hidden}> Once you've gone to 18F you'll find it hard to go back to 16F - much nicer > chips. > > Main gotchas : > > Don’t need paging for the majority of programming > Don’t try the "goto $-1" command - it doenst work just use labels and go > to > them > RLF replaced by RLCF > RRF replaced by RRCF > Table lookups are different > > And a fair few more but I'd much rather go for the 18F over the 16F now :) > > Dom -- FCC Rules Updated Daily at http://www.hallikainen.co

> On Mon, 2005-07-18 at 15:48 +0100, Dominic Stratten wrote: > >> Don¢t try the "goto $-1" command - it doenst work just use labels and go >> to >> them > >>From what I've read it just needs to be "goto $-2" on an 18F ? > > Peter > That works as long as the previous instruction was a single word instruction. Some are not. It's nice to just use labels and let the assembler figure it out. Harold -- FCC Rules Updated Daily at http://www.hallikainen.co

> >> Don¢t try the "goto $-1" command - it doenst work just use > >> labels and go to them > > > >>From what I've read it just needs to be "goto $-2" on an 18F ? > > > > That works as long as the previous instruction was a single word > instruction. Some are not. It's nice to just use labels and let the > assembler figure it out. Is there anytime when you are *forced* to use the $-construct ? Regards, Jan- Erik.

Jan-Erik Soderholm wrote: > Is there > anytime when you are *forced* > to use the $-construct ? I don't think so. I can't think of a case. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

This is a great thread...I just made the jump from 16F to 18F chips. Keep the info comming. Milosz K. ----- Original Message ----- From: "Olin Lathrop" <olin_piclistKILLspamembedinc.com> > Jan-Erik Soderholm wrote: > > Is there > > anytime when you are *forced* > > to use the $-construct ? > > I don't think so. I can't think of a case.

On Sunday 17 July 2005 09:32 pm, Jinx scribbled: > > Thanks. What did you do to find this? If I search for "migrating", it > > does not come up > > Funny, that's exactly what I put into the search (under "Site map" text) > on the home page. It appears in the Application Notes group on the > results page, 13th up from bottom of page Still have the screen up, and realized that I had actually typed "migration", not "migrating". Kerapp! Cheers, -Neil.

I ported my code (F872 to F242), which required some time/thought since I had some "interesting" pieces of code in there. Most everything works now, except that I have a problem with EEPROM code. It's not reading defaults that are programmed at startup. But if anything is written to EE during code execution, it reads that back fine. Is the location still 0x2100? Or is there something else I need to do here? I'm still going thru the manuals, but need a break from that. Cheers, -Neil. On Tuesday 19 July 2005 06:00 am, Milosz Kardasinski scribbled: {Quote hidden}> This is a great thread...I just made the jump from 16F to 18F chips. > Keep the info comming. > > Milosz K. > > ----- Original Message ----- > From: "Olin Lathrop" <.....olin_piclistKILLspam.....embedinc.com> > > > Jan-Erik Soderholm wrote: > > > Is there > > > anytime when you are *forced* > > > to use the $-construct ? > > > > I don't think so. I can't think of a case.

True. 0xF00000 did work, and I also had to change the "DE" to "DW" to make it work w/o any other code changes. Cheers, -Neil On Tuesday 19 July 2005 01:22 pm, Michael Rigby-Jones scribbled: > Neil, > > EEPROM location is not 2100h as that is a valid program memory address on > the 18F parts! Of the top of my head I think it's address F00000h that is > used to embed EEPROM data into the hex file. > > Regards > > Mike > > >{Original Message removed}

On Tuesday 19 July 2005 04:12 pm, Jinx scribbled: > > Still have the screen up, and realized that I had actually typed > > "migration", > > > not "migrating". Kerapp! > > You could be excused for missing the document. "Migrating Designs > from PIC16C74A/74B to PIC18C442" doesn't exactly scream 16F > to 18F does it ? I didn't know what to expect before downloading it Not exactly, but I'm sure it would've seemed worth looking into. There was a bunch of 16C to 16C and 16C to 16F migration docs though. Cheers, -Neil.

James is busy for the next little while with work, so I'll answer. Or rather, I'll think up something that sounds plausible. I'm pretty sure we can't just mirror it, there will be copyright problems. Linking is a good idea though. Any thoughts on where it should go on the site? If the page doesn't have an editor, you can add it yourself I think. Hope that's a bit of a help! Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams On 7/19/05, Jinx <EraseMEjoecolquittspam_OUTTakeThisOuTclear.net.nz> wrote: > As it seems to have attracted some interest, would be worthwhile > linking to or mirroring on the Piclist site. James ? > > http://ww1.microchip.com/downloads/en/AppNotes/00716a.pdf (368kB)

Hi I spent awhile battling with the conversion to 18F. Below is some code to read a block of onboard EE into ram. I'm not going to format the text, but it does work fine. Hopefully it's of help. Regards Roland By the way; b0 equ 0x00 ;ram bank 0 It was easier to read this way. At 12:57 PM 19/07/2005 -0500, you wrote: {Quote hidden}>I ported my code (F872 to F242), which required some time/thought since I had >some "interesting" pieces of code in there. Most everything works now, >except that I have a problem with EEPROM code. It's not reading defaults >that are programmed at startup. But if anything is written to EE during code >execution, it reads that back fine. Is the location still 0x2100? Or is >there something else I need to do here? I'm still going thru the manuals, >but need a break from that. > >Cheers, >-Neil. > > copyin ;copy EE values into ram, block copy movlw 0x01 movwf FSR0H,b0 ;in bank1 movlw 0x00 ;start at 0100 movwf eread,b0 clrf epos,b0 egain movf epos,w,b0 movwf EEADR,b0 bcf EECON1,EEPGD,b0 bcf EECON1,CFGS,b0 ;big fuckup, was missing 17/3/5 bsf EECON1,RD,b0 movf EEDATA,w,b0 movwf egot,b0 movf eread,w,b0 movwf FSR0L,b0 movlw 0x01 movwf FSR0H,b0 ;in bank1 ;copied from above; 14/3/5 movf egot,w,b0 movwf INDF0,b0 incf epos,f,b0 incf eread,f,b0 movf eread,w,b0 xorlw 0x28 ;end at position 27, incl stata at 27 containing smoke(7) flag btfss _Z,b0 ;done the block move bra egain ;modified end position, 30 to 27, on 9/3/5 Regards Roland Jollivet

My EE read problem was due to the address for the defaults. Now solved. Porting wasn't really a battle on my end, but this code (from memory) stopped me for a couple minutes... OW_PORT EQU PORTB ; One-wire I/O port OW_PIN EQU D'7' ; One-wire I/O pin # ... OW_SetLo: bcf STATUS,RP0 ; Bank 0 bcf OW_PORT,OW_PIN ; Set low first bsf STATUS,RP0 ; Bank 1 bcf OW_PORT,OW_PIN ; Will actually tris the pin as o/p since in bank 1 OW_SetLoDone: return The idea was that if I changed port/pin later, I would not have to change multiple definitions. But with the 18F, the PORT and TRIS values were not in the same offset in different banks (as with the 16F), so simply removing the bank-selection statements changed the meaning of everything. Cheers, -Neil. On Wednesday 20 July 2005 02:02 am, Roland scribbled: > Hi > > I spent awhile battling with the conversion to 18F. Below is some code to > read a block of onboard EE into ram. I'm not going to format the text, but > it does work fine. Hopefully it's of help. > > Regards > Roland

I have a set of macros I use for bank selects on 16F chips. When I moved some of the code over to 18F, I just made the macros empty. Harold {Quote hidden}> My EE read problem was due to the address for the defaults. Now solved. > > Porting wasn't really a battle on my end, but this code (from memory) > stopped > me for a couple minutes... > OW_PORT EQU PORTB ; One-wire I/O port > OW_PIN EQU D'7' ; One-wire I/O pin # > ... > OW_SetLo: > bcf STATUS,RP0 ; Bank 0 > bcf OW_PORT,OW_PIN ; Set low first > bsf STATUS,RP0 ; Bank 1 > bcf OW_PORT,OW_PIN ; Will actually tris the pin as o/p since in bank 1 > OW_SetLoDone: > return > > The idea was that if I changed port/pin later, I would not have to change > multiple definitions. But with the 18F, the PORT and TRIS values were not > in > the same offset in different banks (as with the 16F), so simply removing > the > bank-selection statements changed the meaning of everything. > > Cheers, > -Neil. -- FCC Rules Updated Daily at http://www.hallikainen.com

PicDude wrote: {Quote hidden}>My EE read problem was due to the address for the defaults. Now solved. > >Porting wasn't really a battle on my end, but this code (from memory) stopped >me for a couple minutes... > OW_PORT EQU PORTB ; One-wire I/O port > OW_PIN EQU D'7' ; One-wire I/O pin # > ... >OW_SetLo: > bcf STATUS,RP0 ; Bank 0 > bcf OW_PORT,OW_PIN ; Set low first > bsf STATUS,RP0 ; Bank 1 > bcf OW_PORT,OW_PIN ; Will actually tris the pin as o/p since in bank 1 > You are using a"trick" to get access to a clearly defined register. "tricks" have a way of biting you in the ass. Clearly, a properly designed code line: BCF TRISB, OW_PIN ; Will actually WORK in either PIC. Use comments to explain what "OW_PORT" does for you, and stick with the Microchip definitions of the registers. (It makes the code MUCH clearer for debugging.) Take what you like, listen to the rest... Tom {Quote hidden}>OW_SetLoDone: > return > >The idea was that if I changed port/pin later, I would not have to change >multiple definitions. But with the 18F, the PORT and TRIS values were not in >the same offset in different banks (as with the 16F), so simply removing the >bank-selection statements changed the meaning of everything. > >Cheers, >-Neil. > > > >On Wednesday 20 July 2005 02:02 am, Roland scribbled: > > >>Hi >> >>I spent awhile battling with the conversion to 18F. Below is some code to >>read a block of onboard EE into ram. I'm not going to format the text, but >>it does work fine. Hopefully it's of help. >> >>Regards >>Roland >> >> > > > >

>From what I've read it just needs to be "goto $-2" on an 18F ? My rules in dealing with the goto $... when porting from PIC16 to PIC18. 1) 'goto' will be replace with 'bra' 2) The address count is doubled up goto $-2 will work well if you have doubled up the address count. Anyway it you have goto $+something, simply double up the address count will catch you! Goto is 2-word instruction in PIC18. Best regards, WH Tan

WH Tan wrote : > My rules in dealing with the goto $... when porting from PIC16 to > PIC18. > > 1) 'goto' will be replace with 'bra' > 2) The address count is doubled up > > goto $-2 will work well if you have doubled up the address count. > Anyway it you have goto $+something, simply double up the address > count will catch you! Goto is 2-word instruction in PIC18. > Note that there are (at least) three different 2-word instructions in the PIC18, not just GOTO. You have to watch out if you are just simply "counting lines"... I'd write your rule 1) above like this : 1) 'goto $' will be replaced with 'bra/goto <label>' Jan-Erik.

> watch out if you are just simply "counting lines"... Not really. Actually I always counting in word :) Yes I agree with you. Anyway if the target address is really close to the place where the jump takes place, and if the source file has plenty of goto $... statements to amend. I believe my eyes are 'scanning' faster then my finggers can type :) Not to mention it I have several source files to go. Best regards, WH Tan

Repost due to plenty of grammer mistake... > watch out if you are just simply "counting lines"... Not really. Actually I always counting in words :) Yes I agree with you. Anyway if the target address is really close to the place where the jump takes place, and if the source file has plenty of goto $... statements to amend. I believe my eyes are 'scanning' faster than my finggers can type :) Not to mention if I have several source files to go. Best regards, WH Tan

This reminds me of my early programming of the Motorola MC6802. I didn't have a computer (and, thus, did not have an assembler), so I hand coded everything in hex. Relative branches used an 8 bit signed offset, so I got real familiar with counting forwards and backwards in hex... Harold {Quote hidden}> Repost due to plenty of grammer mistake... > >> watch out if you are just simply "counting lines"... > > Not really. Actually I always counting in words :) > > Yes I agree with you. Anyway if the target address is really close to > the place where the jump takes place, and if the source file has > plenty of goto $... statements to amend. I believe my eyes are > 'scanning' faster than my finggers can type :) Not to mention if I > have several source files to go. > > Best regards, > WH Tan -- FCC Rules Updated Daily at http://www.hallikainen.com