Post by thread:[PIC] PIC18 for the clueless

OK, I'm reviewing some documentation for the 18F2620. I'm going to try and avoid printing 412 pages of documentation, so for the time being I'll refer to the pdf datasheet as needed. I created a new project in MPLAB, and am going to begin using the MPASM tool suite. I've copied the template file for the 18F2620 and renamed it simply, "blinky" as a basis to begin my project. One thing I immediately see that appears different from the 16F series is how the configuration bits are defined ;Configuration bits ;Microchip has changed the format for defining the configuration bits, please ;see the .inc file for futher details on notation. Below are a few examples. (I don't know where to find this 'inc' file mentioned) ; Oscillator Selection: CONFIG OSC = LP ;LP (OK, I can see this means 'low-powered crystal'. ) So far, so good. On the pull down menu, however, under 'configure, configuration bits' there is a check box to either set the bits in code (default, it seems) or to select from the individual fields. I'm new enough at this to not know what needs to be set (ie _MCLRE_ON & _CP_OFF & _WDT_OFF) as I might have done with a 16F84. If I am understanding these functions, it appears I would set them the same way as I did previously, and if the default condition is correct, no further action needs to be done. I might assume that setting the bits in code is preferred over the pull down configuration to allow you as well as anyone else to see what is configured. Bear with me here... I'm trying this out on paper before ever plugging anything into the breadboard. I want to light a single LED on RB0 of the 18F2620. list p=18F2620 #include <p18F2620.inc> CONFIG OSC=LP ;I'll use a 20MHz crystal at OSC1 & OSC2 start CLRF PORTB ;initialize port B MOVLW b'11111110' ;configure RB0 as output MOVWF TRISB MOVLW b'00000001' ;set RB0 high MOVWF TRISB goto $ As Olin suggests, I came up with this by quickly looking at sections of the datasheet. Much extensive study is obviously required. My next step should be to see if this compiles - IT DOESN'T. I receive errors such as: Executable code and data must be defined in an appropriate section. I'll need to learn what that means. At any rate, if someone can let me know if I'm on the right track to start. Thanks. Joe

On Sun, Jan 4, 2009 at 7:16 PM, Joseph Bento <spam_OUTjosephTakeThisOuTkirtland.com> wrote: {Quote hidden}> OK, I'm reviewing some documentation for the 18F2620. I'm going to > try and avoid printing 412 pages of documentation, so for the time > being I'll refer to the pdf datasheet as needed. > > I created a new project in MPLAB, and am going to begin using the > MPASM tool suite. I've copied the template file for the 18F2620 and > renamed it simply, "blinky" as a basis to begin my project. > > One thing I immediately see that appears different from the 16F series > is how the configuration bits are defined > > ;Configuration bits > ;Microchip has changed the format for defining the configuration bits, > please > ;see the .inc file for futher details on notation. Below are a few > examples. > > (I don't know where to find this 'inc' file mentioned) > > ; Oscillator Selection: > CONFIG OSC = LP ;LP > > (OK, I can see this means 'low-powered crystal'. ) > > So far, so good. On the pull down menu, however, under 'configure, > configuration bits' there is a check box to either set the bits in > code (default, it seems) or to select from the individual fields. I'm > new enough at this to not know what needs to be set (ie _MCLRE_ON & > _CP_OFF & _WDT_OFF) as I might have done with a 16F84. If I am > understanding these functions, it appears I would set them the same > way as I did previously, and if the default condition is correct, no > further action needs to be done. I might assume that setting the bits > in code is preferred over the pull down configuration to allow you as > well as anyone else to see what is configured. > > Bear with me here... I'm trying this out on paper before ever > plugging anything into the breadboard. > > I want to light a single LED on RB0 of the 18F2620. > > list p=18F2620 > #include <p18F2620.inc> > > CONFIG OSC=LP ;I'll use a 20MHz crystal at OSC1 & OSC2 > > > start > CLRF PORTB ;initialize port B > MOVLW b'11111110' ;configure RB0 as output > MOVWF TRISB > MOVLW b'00000001' ;set RB0 high > MOVWF TRISB > > goto $ > > > As Olin suggests, I came up with this by quickly looking at sections > of the datasheet. Much extensive study is obviously required. My > next step should be to see if this compiles - IT DOESN'T. I receive > errors such as: Executable code and data must be defined in an > appropriate section. I'll need to learn what that means. > > At any rate, if someone can let me know if I'm on the right track to > start. > > Thanks. > > Joe > I also have a bunch of 18F2620 that I haven't even touched yet. Also have two C compilers for them. I am as interested as you are in these things. Try this: list p=18F2620 #include <p18F2620.inc> CONFIG OSC=LP ;I'll use a 20MHz crystal at OSC1 & OSC2 start code CLRF PORTB ;initialize port B MOVLW b'11111110' ;configure RB0 as output MOVWF TRISB MOVLW b'00000001' ;set RB0 high MOVWF TRISB goto $ -- solarwind

Dear Clueless ;-) >;see the .inc file for futher details on notation. Below are a few > examples. > (I don't know where to find this 'inc' file mentioned) .inc files should be in the MPASM folder, probably Program Files/Microchip/MPASM Suite > CONFIG OSC=LP ;I'll use a 20MHz crystal at OSC1 & OSC2 CONFIG OSC = HS then {Quote hidden}> start > CLRF PORTB ;initialize port B > MOVLW b'11111110' ;configure RB0 as output > MOVWF TRISB > MOVLW b'00000001' ;set RB0 high > MOVWF TRISB > > goto $ > MOVLW b'11111110' ;configure RB0 as output > MOVWF TRISB Having all those floating inputs would probably cause problems in practice. If you're looking at experimenting with just one pin then CLRF TRISB to set them all as outputs The other problem with that code is > MOVLW b'00000001' ;set RB0 high > MOVWF TRISB doesn't set the output high. You should be working on LATB. Note that 18F have two registers per port. PORT is the input, LAT is the output > Executable code and data must be defined in an appropriate section (152) When generating a linkable object file, all executable code and data declarations must be placed within appropriate sections Not an error I've had. Does the MPLAB explanation help ?

Jinx wrote: {Quote hidden}> Dear Clueless ;-) > > >> ;see the .inc file for futher details on notation. Below are a few >> examples. >> (I don't know where to find this 'inc' file mentioned) >> > > .inc files should be in the MPASM folder, probably > > Program Files/Microchip/MPASM Suite > > >> CONFIG OSC=LP ;I'll use a 20MHz crystal at OSC1 & OSC2 >> > > CONFIG OSC = HS then > > >> start >> CLRF PORTB ;initialize port B >> MOVLW b'11111110' ;configure RB0 as output >> MOVWF TRISB >> MOVLW b'00000001' ;set RB0 high >> MOVWF TRISB >> >> goto $ >> > > >> MOVLW b'11111110' ;configure RB0 as output >> MOVWF TRISB >> > > Having all those floating inputs would probably cause problems in > practice. If you're looking at experimenting with just one pin then > CLRF TRISB to set them all as outputs > > The other problem with that code is > > >> MOVLW b'00000001' ;set RB0 high >> MOVWF TRISB >> > > doesn't set the output high. You should be working on LATB. Note > that 18F have two registers per port. PORT is the input, LAT is the > output > > >> Executable code and data must be defined in an appropriate section >> > > (152) When generating a linkable object file, all executable code and > data declarations must be placed within appropriate sections > > Not an error I've had. Does the MPLAB explanation help ? > > Assuming you have MP:AB installed in the default location on your computer, take a look at this file: C:\Program Files\Microchip\MPASM Suite\Template\Code\18F2620TEMP.ASM. It will give you a starting point for the structure your code needs to follow. You will see that there is a reset vector (ORG 0x0000) and then (GOTO MAIN). When the PIC resets, it goes there then is sent to main (at the bottom of the template where you actual code will be. Hope this helps! -- Regards, Stephen D. Barnes ========================================================= = Banking establishments are more dangerous than standing armies. = = Thomas Jefferson <http://www.brainyquote.com/quotes/quotes/t/thomasjeff101899.html> = =========================================================

Joseph Bento wrote: > So far, so good. On the pull down menu, however, under 'configure, > configuration bits' there is a check box to either set the bits in > code (default, it seems) or to select from the individual fields. Never ever set the configuration bits from this menu. Always specify them in the code else they may not end up in the HEX file. Use the configuration bits menu to verify that the source code is setting the bits as you intended. > I'm > new enough at this to not know what needs to be set (ie _MCLRE_ON & > _CP_OFF & _WDT_OFF) as I might have done with a 16F84. There is no shortcut with the config bits. You have to go thru the manual and decide which way you want every one of them. In general, leave the MCLR pin in its MCLR role, for starters you can use the internal oscillator to get the first LED blinking, always disable PGM, keep the watchdog off, and don't turn on any of the code or read or write protection. > CONFIG OSC=LP ;I'll use a 20MHz crystal at OSC1 & OSC2 For 20MHz you will need HS mode. LP is "low power", which uses a weaker drive that won't work at 20MHz. If you're going to be sticking to the 18F for a while, get a handful of 10MHz crystals. That way you can run the PIC at its maximum speed of 40MHz using the 4x PLL mode. > start > CLRF PORTB ;initialize port B > MOVLW b'11111110' ;configure RB0 as output > MOVWF TRISB > MOVLW b'00000001' ;set RB0 high > MOVWF TRISB Labels start in column 1 and opcodes in column 2 or greater. Also, there are various analog peripherals multiplexed on many of the pins. In general, every pin that could be analog wakes up that way. You should probably just disable the A/D (and comparator ?) up front, then turn it on in a module for that purpose later if you are using it. Just clearing TRIS isn't necessarily enough to make a pin a usable output. > I receive > errors such as: Executable code and data must be defined in an > appropriate section. I'll need to learn what that means. You need to read about the various assembler directives in the MPASM/MPLIB/MPLINK manual. In this case you are missing a CODE directive, but you need to read that manual anyway because there are a lot more directives you will bump into. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Olin Lathrop wrote: > Never ever set the configuration bits from this menu. Always specify them > in the code else they may not end up in the HEX file. Use the configuration > bits menu to verify that the source code is setting the bits as you > intended. > That's good to know! I might assume you would want them in the code so that you (and others) know what was done at some future date. {Quote hidden}>> I'm >> new enough at this to not know what needs to be set (ie _MCLRE_ON & >> _CP_OFF & _WDT_OFF) as I might have done with a 16F84. >> > > There is no shortcut with the config bits. You have to go thru the manual > and decide which way you want every one of them. In general, leave the MCLR > pin in its MCLR role, for starters you can use the internal oscillator to > get the first LED blinking, always disable PGM, keep the watchdog off, and > don't turn on any of the code or read or write protection. > I'm certainly not against reading the datasheet. I do want to understand what the settings are for and how they might apply for what I'm trying to do - even if it's as simple as lighting an LED. I think it might be in my best interest to sacrifice an ink cartridge and print out all 400+ pages at least for my first 18F chip. >> CONFIG OSC=LP ;I'll use a 20MHz crystal at OSC1 & OSC2 >> > > For 20MHz you will need HS mode. LP is "low power", which uses a weaker > drive that won't work at 20MHz. > I overlooked that setting despite looking at the datasheet. :-) I see I can also choose the internal oscillator, which is probably adequate for lighting and flashing LEDs. Once I get a basic program working, I think I'll want to play around with various configurations to see if it affects the operation as my interpretation of the datasheet. > If you're going to be sticking to the 18F for a while, get a handful of > 10MHz crystals. That way you can run the PIC at its maximum speed of 40MHz > using the 4x PLL mode. > That's another mode I'll still need to read about. {Quote hidden}>> start >> CLRF PORTB ;initialize port B >> > > Labels start in column 1 and opcodes in column 2 or greater. > > Also, there are various analog peripherals multiplexed on many of the pins. > In general, every pin that could be analog wakes up that way. You should > probably just disable the A/D (and comparator ?) up front, then turn it on > in a module for that purpose later if you are using it. Just clearing TRIS > isn't necessarily enough to make a pin a usable output. > > To my credit, I did have the example in columns as you suggest. I think the plain text format of my post may have removed any tabs. Part of the problem I see as a beginner is not knowing about all the various modes of operation, such as A/D, comparator, etc. While I certainly agree that the datasheet is an indispensable reference, at 400 pages it's hard to know what all needs to be done, especially when starting out. Such and such a mode is possible, but is it necessary to enable / disable / don't care for what I'm trying to do? Such questions are probably answered, but I need to know such capabilities exist in the first place. {Quote hidden}>> I receive >> errors such as: Executable code and data must be defined in an >> appropriate section. I'll need to learn what that means. >> > > You need to read about the various assembler directives in the > MPASM/MPLIB/MPLINK manual. In this case you are missing a CODE directive, > but you need to read that manual anyway because there are a lot more > directives you will bump into. > > Now that is something I'll look at! I know in my failed example, I used binary in the code. I'm sure that could just as easily be expressed in hex, though I find the binary easier at a glance to see which setting is affected. Thank you for the help and suggestions. Joe

Joe Bento wrote: > To my credit, I did have the example in columns as you suggest. I > think > the plain text format of my post may have removed any tabs. Never put tabs in code, at least not whenever it leaves your system. You have no idea how other people's tab stops are set. As you saw, some systems can even stomp out, or appear to stomp out tabs altogether. I your editor can't substitute spaces for tabs, you can use my ASPIC_FIX program. It not only gets rid of all tabs but also lines up opcodes, operands, and comments nicely into columns. > Part of the problem I see as a beginner is not knowing about all the > various modes of operation, such as A/D, comparator, etc. While I > certainly agree that the datasheet is an indispensable reference, at > 400 pages it's hard to know what all needs to be done, especially when > starting out. Such and such a mode is possible, but is it necessary > to enable / disable / don't care for what I'm trying to do? Such > questions > are probably answered, but I need to know such capabilities exist in > the first place. After you turn off any analog peripherals, you really can ignore peripherals you aren't using. Just add a little boiler plate code that turns off the A/D and comparator if the chip has one. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joseph Bento wrote: {Quote hidden}> One thing I immediately see that appears different from the 16F series > is how the configuration bits are defined > > ;Configuration bits > ;Microchip has changed the format for defining the configuration bits, > please > ;see the .inc file for futher details on notation. Below are a few > examples. > > (I don't know where to find this 'inc' file mentioned) > > ; Oscillator Selection: > CONFIG OSC = LP ;LP > > (OK, I can see this means 'low-powered crystal'. ) > > So far, so good. On the pull down menu, however, under 'configure, > configuration bits' there is a check box to either set the bits in > code (default, it seems) or to select from the individual fields. I'm > new enough at this to not know what needs to be set (ie _MCLRE_ON & > _CP_OFF & _WDT_OFF) as I might have done with a 16F84. If I am > understanding these functions, it appears I would set them the same > way as I did previously, and if the default condition is correct, no > further action needs to be done. I might assume that setting the bits > in code is preferred over the pull down configuration to allow you as > well as anyone else to see what is configured. > An invaluable resource for developing with the 18F series is the "PIC18 Configuration Settings Addendum" document, DS51537E. It lists all of the configuration options for each chip and the parameters each can take. Although it is for C18, I'm 99% certain the assembler definitions are the same. http://ww1.microchip.com/downloads/en/devicedoc/C18_Config_Settings_51537e.pdf - -- Brendan Gillatt | GPG Key: 0xBF6A0D94 brendan {a} brendangillatt (dot) co (dot) uk http://www.brendangillatt.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFJYnOwuv4tpb9qDZQRAu85AJ93CpjC9BA2L4yuuldWVfiN9d5JTQCfQup7 dDC3PJWMfmZa0EpMlWZhv0c= =E8LP -----END PGP SIGNATURE-----

Joe Bento wrote: > Olin Lathrop wrote: >> Never ever set the configuration bits from this menu. Always specify them >> in the code else they may not end up in the HEX file. Use the configuration >> bits menu to verify that the source code is setting the bits as you >> intended. >> > That's good to know! I might assume you would want them in the code so > that you (and others) know what was done at some future date. It's becuse it's better to have them in the source code. Including for yourself. The fact that it also helps when posting code to forums when asking for help, is just an positive side effect... :-) > I think > it might be in my best interest to sacrifice an ink cartridge and print > out all 400+ pages at least for my first 18F chip. That was what I did with my first datasheet (well, using a laser toner cartridge...). Then, after that, I knew what to look for so now I mainly print specific chapters if needed. > I see > I can also choose the internal oscillator, which is probably adequate > for lighting and flashing LEDs. Yes, in very many cases the INTOSC works just OK. >> using the 4x PLL mode. >> > That's another mode I'll still need to read about. > Note also, that many of the newer/newest PIC18's can use the 4xPLL together with the 8 Mhz INTOSC for an effective speed of 32 MHz without any external crystal.

"Joe Bento" wrote: > I'm certainly not against reading the datasheet. I do want to > understand what the settings are for and how they might apply for what > I'm trying to do - even if it's as simple as lighting an LED. I think > it might be in my best interest to sacrifice an ink cartridge and print > out all 400+ pages at least for my first 18F chip. I have several 2" binders with datasheets that I printed out over the years, and unfortunately I can't say that they've seen much use. You can't take a 2" binder to the gym, or comfortably read it in the bathtub. What seems to work for me is: 1. A second monitor. This way, I can have both MPLAB and the datasheet open at the same time, without the need to switch b/w the windows. 2. Printing the sections selectively. If you want to know how to set up the oscillator, print out just that section. Then print out and read the chapter on A/D. I usually put the sections in small-ish 3-ring binder, and after a while end up with the material I refer to most. Just my 2 kopeck. Vitaliy

{Quote hidden}> > I have several 2" binders with datasheets that I printed out over the > years, > and unfortunately I can't say that they've seen much use. You can't > take a > 2" binder to the gym, or comfortably read it in the bathtub. > > What seems to work for me is: > > 1. A second monitor. This way, I can have both MPLAB and the datasheet > open > at the same time, without the need to switch b/w the windows. > > 2. Printing the sections selectively. If you want to know how to set up > the > oscillator, print out just that section. Then print out and read the > chapter > on A/D. I usually put the sections in small-ish 3-ring binder, and > after a > while end up with the material I refer to most. > I'm the opposite; I need my treeware. I typically print the pdf's two-up, double-sided. (Which is why I insist on having a duplexing laser printer at home.) At least this way, the 400 page document only uses 100 sheets of paper.

> Do you have a 2nd monitor? Steve Ciarcia of Circuit Cellar recently > said in > his column that a second monitor helped him cut down on paper. I have a > 20" > turned in portrait orientation for a side monitor, it's actually > slightly > larger than a sheet of paper and is perfect for viewing documents. > > Don't get me wrong, I love paper -- but sometimes the electronic > version is > superior. You can't Ctrl-F or Ctrl-C the paper version. > Yup. I have two 24" monitors. (I'd like one or two more, but the budget and the wife won't allow it.) And I do, of course, use the second monitor for reference docs while I do my coding on the first monitor. There are just times and places that I really prefer the paper copy. I guess old habits just die hard.

Joe Bento wrote: > Matthew Mucker wrote: > >> I'm the opposite; I need my treeware. >> >> I typically print the pdf's two-up, double-sided. (Which is why I insist on >> having a duplexing laser printer at home.) At least this way, the 400 page >> document only uses 100 sheets of paper. > > Well I printed the 18F2620 manual last evening. I set the print > quality just one click up from draft, which results in a perfectly > readable, slightly less than crisp black text from my Cannon inkjet. > Used only half of an ink cartridge for 410 pages - 205 double-sided. (I > don't think I'd ever buy a printer that couldn't handle duplex printing.) > > Now we'll have to see about putting this manual to good use. :-) > > Joe > I never print out the "Electrical Specificaton" (about 1/3 of the last part of the datasheet). Those are not *that* interesting or importent when doing normal home/hobby projects.

"Matthew Mucker" <matthewKILLspammucker.net> wrote in message news:006e01c9702c$77f9a090$67ece1b0$@net... >> >> FinePrint <http://www.fineprint.com/> helps with printing 2/4/8-up, >> double sided and booklets with programs and printers that don't support >> it. (No affiliation other than being a user.) >> >> Gerhard > > Adobe reader supports n-up printing directly in the Print dialog. Which is great, but if you want printing on both sides, it's a lot easier if you have a printer which can do this automatically. Having to take your print-out of one side of a document out of the printer and properly re-insert it into the printer to make prints on the other side, in the right orientation, is beyond the ability of some printer users to do reliably. This is partly because the paper path can vary from printer to printer making the solution to this problem dependant on the printer model. At home, the paper path in our Epson inkjet and our HP inkjet are different (the HP has a U-turn for the paper which the Epson does not). It's a lot easier for me to do double sided print outs at work where both the HP laser printer and the Xerox laser printer/copier have duplex printing built into the machine and the printer drivers. Jeff -- "Many things that were acceptable in 1958 are no longer acceptable today. My own standards have changed too." -- Freeman Dyson