| Microcontrollers tend to be dedicated to a particular | | | | module and a final CONFIG3H bit allows the "steering" |
| purpose, so while they're very flexible devices these | | | | of this output to be on either RC1 or RB3. This is |
| days, there are a number of different (often conflicting) | | | | handy to be able to change if you require the other |
| options for how you might want the hardware to | | | | functionality available on one of these pins (RB3 is also |
| work. You might think that this configuration is done in | | | | analogue input 9 and RC1 can be Timer 1 oscillator |
| software, but what if you want the hardware to act a | | | | input). Alternatively, your PCB layout might be easier if |
| certain way from the very start? Keeping in mind that | | | | you could move this output to one or the other. For |
| Microchip PIC devices can "boot" in a matter of | | | | prototyping, generally this doesn't matter either way. |
| milliseconds, there needs to be a way you telling the | | | | #pragma DATA _CONFIG3H, |
| hardware how to behave in advance of it starting up. | | | | _CCP2MX_PORTC_3H & _PBADEN_OFF_3H & |
| This article covers how to get your microcontroller | | | | _MCLRE_ON_3H |
| based project working the way you expect when it | | | | CONFIG4L contains some interesting options and |
| starts up. | | | | shows very clearly how important it is to be able to |
| Enter config bits, or, as they used to be called, config | | | | configure the PIC before startup. |
| fuses. Back in the days when microcontrollers were | | | | The DEBUG bit allows hardware debugging. You can |
| program-once devices, you really did blow a fuse in | | | | step through code, set breakpoints and so on - if you |
| order to program them. Today, most micros have | | | | have your software set correctly and this bit cleared. |
| flash memory that can be programmed tens of | | | | Hardware debugging also requires the exclusive use |
| thousands of times, but there are still | | | | of RB6 and RB7 (also used for ICSP programming). In |
| one-time-programmable (OTP) devices about. | | | | all honesty, we find that serial output is generally |
| In any case, there's a bunch of "config words" that | | | | sufficient to find bugs, although you can debug a lot of |
| define how the micro is going to behave from the | | | | PICs with merely a PicKit2. |
| get-go. Let's look at some of these options (we'll | | | | XINST allows for the 18F extended instruction set |
| choose the PIC18F2620 as an example) and then see | | | | mode. This isn't used by Sourceboost and if you |
| how to program them. Sourceboost gives you all the | | | | switch it on by mistake (regardless of the compiler |
| config strings in a ready-to-use format for including in | | | | you're using) there will be some pretty unpredictable |
| your project. The format has the config bits suffixed | | | | results. One of our readers spent days trying to find |
| with the same name as the config word so you can | | | | what was wrong with his code only to realise the |
| ensure that the right bits are going in the right word. Of | | | | XINST bit was set. |
| course, your config words will be different if you're | | | | LVP gives you the ability to program the PIC using |
| using a different microcontroller, but you should learn | | | | ICSP without requiring the "higher" Vpp voltage. There |
| enough here to point you in the right direction. | | | | is a catch however - you need to dedicate the RB5 |
| In the 18F2620, the config bits are stored in flash, but at | | | | pin (PGM) to being an indicator if you are in |
| a high memory location. They're stored at 0x300001 | | | | programming mode or not. Given the PicKit2 |
| and upwards. For historical reasons due to the way | | | | generates the right voltage anyway, there doesn't |
| memory was previously arranged on PIC | | | | seem to be a lot of value in switching this on for |
| microcontrollers, config words are numbered with each | | | | prototyping purposes. |
| number having a "high" and "low" byte. | | | | Finally, the STVREN gives the option of having the PIC |
| CONFIG1L doesn't exist on the 18F2620. If it did, it | | | | reset if the stack overflowed or underflowed. If, for |
| would live at 0x300000 location. | | | | example, you call too many nested functions, it would |
| CONFIG1H contains bits that specify oscillator options. | | | | allow the PIC to reset. Once reset, you can examine |
| Generally, in Embedded Adventures projects we try | | | | why the PIC reset and report a fault. We recommend |
| and use external crystals which give more accurate | | | | leaving this on - if your PIC boots in the middle of doing |
| and reliable results. This does use up two pins | | | | something, you can reasonably assume that you've |
| however, and sometimes these can be more | | | | used up the stack space (possible when you're deep |
| important than the speed at which the chip is running. | | | | in a nested situation and then an interrupt occurs). |
| The external crystal oscillator is referred to as the HS | | | | #pragma DATA _CONFIG4L, _STVREN_ON_4L & |
| oscillator (if you're doing the typical thing of trying to run | | | | _LVP_OFF_4L & _DEBUG_OFF_4L & |
| the micro as fast as it will go). In the 18F2620, you can | | | | _XINST_OFF_4L |
| also enable the PLL module which will give you a | | | | CONFIG5L gives the option of specifying if any one of |
| four-times speed boost. From CONFIG1H are also | | | | four contiguous blocks of memory are protected from |
| options to enable the fail-safe clock monitor (that | | | | any attempts by the PIC to change (ie write) the flash |
| switches to the internal oscillator should the external | | | | memory values. |
| one fail, and an option to enable the switching between | | | | #pragma DATA _CONFIG5L, _CP0_OFF_5L & |
| different oscillator sources. | | | | _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L |
| We generally recommend that you use an external | | | | CONFIG5H givest the option of protecting the block of |
| crystal, and turn off any oscillator switching / failover | | | | memory starting at 0x0000 to 0x7fff) - used by some |
| modes. In prototyping, it is important to have reliable, | | | | bootloaders, as well as a bit to allow the protection of |
| repeatable results (mostly so you can reduce the | | | | EEPROM memory. The PicPack bootloader, |
| axes of error). It is possible to configure the 18F2620 | | | | "Boostbloader", resides in upper memory, meaning that |
| to start up using the internal oscillator (which runs at | | | | while it is slightly less robust than a locked-down, |
| 8Mhz, or 32Mhz with the PLL enabled) and then switch | | | | physically protected bootloader, it doesn't require the |
| to the external one (we use a 10Mhz crystal with PLL | | | | "double jump" for interrupts that bootloaders located in |
| enabled giving you 40Mhz). That gives you faster | | | | lower memory do. We may provide this as an option |
| startup from interrupts in sleep mode or on bootup, if | | | | in the future. |
| that's important, however for prototyping, this is | | | | #pragma DATA _CONFIG5H, _CPB_OFF_5H & |
| generally not necessary. | | | | _CPD_OFF_5H |
| Our recommended config string for CONFIG1H: | | | | CONFIG6L allows the protection of memory blocks |
| #pragma DATA _CONFIG1H, _OSC_HSPLL_1H & | | | | being write protected. |
| _IESO_OFF_1H & _FCMEN_OFF_1H | | | | #pragma DATA _CONFIG6L, _WRT0_OFF_6L & |
| CONFIG2L handles brown-out reset and the power up | | | | _WRT1_OFF_6L & _WRT2_OFF_6L & |
| timer. Brown Out Reset (or BOR) is the ability for the | | | | _WRT3_OFF_6L |
| microcontroller to reset itself if the supply voltage falls | | | | CONFIG6H, CONFIG7L and CONFIG7H give more |
| below a specified threshold. It will remain in reset state | | | | granular protection, allowing blocks of memory to be |
| until the supply goes back over the threshold. This can | | | | protected from when the code being executed is not |
| mean some battery saving (at least, once the battery | | | | in the same block. We could, for example, make a |
| is flat beyond a certain level, it'll stop draining power as | | | | bootloader that was "secret" and unable to be ready |
| quickly) - but at that point there's no functionality | | | | by any other code. |
| available anyway. The power on timer waits on initial | | | | #pragma DATA _CONFIG6H, _WRTC_OFF_6H & |
| power-on for the supply to go above the BOR voltage | | | | _WRTB_OFF_6H & _WRTD_OFF_6H |
| threshold, then hangs around for another 65ms before | | | | #pragma DATA _CONFIG7L, _EBTR0_OFF_7L & |
| kicking things off for real. This can help ensure that | | | | _EBTR1_OFF_7L & _EBTR2_OFF_7L & |
| your power supply is steady before trying to execute | | | | _EBTR3_OFF_7L |
| any code. | | | | #pragma DATA _CONFIG7H, _EBTRB_OFF_7H |
| We have seen some pretty unpredictable results from | | | | While strictly speaking they're not config words, the |
| the 18F2620 when testing some LED display panels. | | | | DEVID words allow code to determine which model of |
| We thought the software was crashing or resetting | | | | the chip is running and which hardware revision. This is |
| the micro when in fact, what was happening was the | | | | important when there are bugs in the hardware that |
| BOR was being tripped as more LEDs were lit and | | | | are fixed over different revision levels and code needs |
| the power supply dropped. As such, unless you've got | | | | to execute differently based on the result. |
| a real need for it, we recommend switching it off. | | | | Making configs |
| Leaving the power supply to settle before starting the | | | | You've probably worked out by now that the |
| firmware, is generally a good idea (you're probably not | | | | Sourceboost compiler's config defines are cleverly |
| going to notice the 65ms it takes). | | | | conceived so that you can simply & together the |
| #pragma DATA _CONFIG2L, _BOREN_OFF_2L & | | | | appropriate options; this means you don't need to work |
| _BORV_2_2L & _PWRT_ON_2L | | | | out exactly which bit positions do what. The #pragma |
| CONFIG2H gives you settings for the watchdog timer. | | | | DATA gives you the ability to shove a byte in a |
| This is a timer that resets the PIC in a certain amount | | | | particular location (in our case, into a config word slot). |
| of time (you can broadly specify how long that might | | | | Other PICs |
| be). It might be good plan to reset your PIC if you're | | | | Here's the config we use with the PIC16F88: |
| doing something from which you might never recover - | | | | #pragma DATA _CONFIG, _CP_OFF & |
| although hopefully you're written good enough code | | | | _CCP1_RB0 & _DEBUG_OFF & |
| that this cannot happen! Alternatively, the watchdog | | | | _WRT_PROTECT_OFF & _CPD_OFF & |
| timer can also pull the PIC out of sleep mode. This | | | | _LVP_OFF & _PWRTE_OFF & _WDT_OFF & |
| means you can arrange for the PIC to go to sleep for | | | | _PWRTE_ON & _BODEN_OFF &_MCLR_ON & |
| a certain amount of time (if nothing else happens). For | | | | _INTRC_IO |
| prototyping, we recommend switching the watchdog | | | | Yep, that's right, it's just one word long. Some of these |
| timer off. If you do enable it, make sure you reset the | | | | options will probably be familiar to you already. |
| watchdog timer regularly or - well, you can guess what | | | | Troubleshooting |
| will happen. | | | | If your chip is not behaving and you want to work out |
| #pragma DATA _CONFIG2H, _WDT_OFF_2H & | | | | if you've made a mistake in your config bits, and handy |
| _WDTPS_128_2H | | | | hint is to use Microsoft's MPLAB IDE to import the.hex |
| CONFIG3H has a collection of configuration items. You | | | | file you've created by clicking on Menu | Import... then |
| can choose for the RE3 pin to be available (as input | | | | Configure | Configuration Bits... Here's the screen you'll |
| only) or for that pin to be MCLR (which resets the | | | | find when importing the PIC18F2620 BoostBloader. |
| micro when pulled low). For prototyping, being able to | | | | You can even change the config bits if you want, then |
| reset the micro by pressing a button is easier than | | | | export again as a.hex file, although keep in mind this |
| pulling the power out. | | | | doesn't change your source code itself. |
| The LPT1OSC bit gives the option of a "high power" | | | | What you've probably realised here is that the |
| mode or a "low power mode". The low power mode | | | | bootloader definitely has config bits embedded in |
| is more sensitive in high noise environments. So if | | | | the.hex file. Our usual PicPack programs don't - since |
| battery usage is very important, you need to design | | | | we assume you're running with a bootloader already |
| your circuit carefully. For prototyping, of course, we | | | | installed. If you do want to program directly with ICSP, |
| would recommend leaving this in high power mode. | | | | of course you'll need to use config bits to make your |
| PBABEN, allows you to specify if PORTB pins 0 - 4 | | | | PIC run the way you intend. Check out the configbits.h |
| should wake up as analog input pins or digital pins upon | | | | file used by Boostbloader - we're starting to build up a |
| reset. Of course you can change this in software in | | | | library of handy config bits including some configuration |
| the ADCON1 register at any time. | | | | options to turn common things on or off (these you |
| The CCP module is a Capture / Compare / PWM | | | | naturally place in the config.h file in your project). |