Registry Or Configuration Record - Years Old Problem and Solution

 Microcontrollers are generally dedicated to a certain purpose, so while they're really flexible devices these days, you can find numerous different (often conflicting) choices for how you may need the equipment to work. You might think that this setup is done in pc software, but what if you would like the electronics to do something a particular way from ab muscles start? Remember that Microchip PIC products may "boot" in a subject of milliseconds, there wants to be a way you telling the hardware how to behave before it starting up. This information addresses how to truly get your microcontroller based task working the way you expect when it begins up.

Enter config portions, or, as they was once named, config fuses. Back the days when microcontrollers were program-once products, you truly did blow a blend to be able to program them. Nowadays, most micros have flash memory which can be programmed tens of thousands of occasions, but you can find however one-time-programmable (OTP) products about.

Whatever the case, there's a number of "config words" that determine how the micro will act from the get-go. Let's look at some of these choices (we'll pick the PIC18F2620 as an example) and then see just how to plan them. Sourceboost offers you all the config strings in a ready-to-use structure for including in your project. The structure gets the config bits suffixed with the exact same name while the config word in order to ensure that the proper pieces are getting in the best word. Of course, your config phrases will soon be various if you're employing a various microcontroller, but you must learn enough here to place you in the right direction.

In the 18F2620, the config portions are located in display, but at a higher storage location. They're located at 0x300001 and upwards. For old causes because of the way memory was once fixed on PIC microcontrollers, config words are numbered with each quantity having a "high" and "low" byte.

CONFIG1L doesn't exist on the 18F2620. If it did, it would live at 0x300000 location.

CONFIG1H contains portions that specify oscillator options. Usually, in Embedded Ventures jobs we use and try external crystals which give more correct and trusted results. That does consume two hooks nevertheless, and occasionally these can be much more important compared to rate at that the processor is running. The additional crystal oscillator is known as the HS oscillator (if you're performing the normal point of trying to run the micro as fast since it will go). In the 18F2620, you can also help the PLL element which will give you a four-times pace boost. From openbullet configs are also choices to enable the fail-safe time monitor (that turns to the internal oscillator if the additional one fail, and a choice to enable the switching between different oscillator sources.

We generally suggest that you use an additional crystal, and turn fully off any oscillator changing / failover modes. In prototyping, it is essential to have trusted, repeatable effects (mostly to help you reduce the axes of error). It's possible to arrange the 18F2620 to start up utilising the inner oscillator (which goes at 8Mhz, or 32Mhz with the PLL enabled) and then switch to the outside one (we work with a 10Mhz gem with PLL permitted giving you 40Mhz). That offers you quicker startup from interrupts in rest method or on bootup, if that's essential, however for prototyping, that is typically maybe not necessary.

Our advised config line for CONFIG1H:

#pragma DATA _CONFIG1H, _OSC_HSPLL_1H & _IESO_OFF_1H & _FCMEN_OFF_1H

CONFIG2L handles brown-out reset and the energy up timer. Brown Out Reset (or BOR) is the capability for the microcontroller to reset itself if the offer voltage comes below a specified threshold. It'll remain in reset state until the offer extends back over the threshold. This may mean some battery saving (at least, when the battery is smooth beyond a certain stage, it'll end draining power as quickly) - but when this occurs there's no performance available anyway. The energy on timer waits on initial power-on for the offer to move above the BOR voltage tolerance, then weighs about for still another 65ms before kicking points down for real. This can help ensure that the power supply is regular before wanting to accomplish any code.

We've seen some pretty volatile results from the 18F2620 when screening some LED show panels. We believed the program was crashing or resetting the micro when in reality, what was occurring was the BOR had been tripped as more LEDs were illuminated and the ability offer dropped. As such, unless you've got a real importance of it, we recommend changing it off. Making the ability source to stay before beginning the firmware, is typically a good idea (you're not likely going to spot the 65ms it takes).

#pragma DATA _CONFIG2L, _BOREN_OFF_2L & _BORV_2_2L & _PWRT_ON_2L

CONFIG2H gives you controls for the watchdog timer. This can be a timer that resets the PIC in a quantity of time (you may generally establish just how long that may be). It may be great plan to reset your PIC if you're doing something from that you simply may never retrieve - while ideally you're written sufficient signal that this can not occur! Alternately, the watchdog timer can also take the PIC out of sleep mode. This means you can prepare for the PIC to go to sleep for a certain amount of time (if nothing else happens). For prototyping, we suggest changing the watchdog timer off. If you do allow it, be sure you reset the watchdog timer often or - well, you can guess what'll happen.

#pragma DATA _CONFIG2H, _WDT_OFF_2H & _WDTPS_128_2H

CONFIG3H has an accumulation arrangement items. You can choose for the RE3 green to be accessible (as insight only) or for that flag to be MCLR (which resets the micro when taken low). For prototyping, to be able to reset the micro by pressing a switch is simpler than taking the energy out.

The LPT1OSC touch allows the choice of a "high power" function or perhaps a "reduced energy mode" ;.The lower power method is more painful and sensitive in high noise environments. Therefore if battery usage is vital, you will need to create your signal carefully. For prototyping, of course, we would recommend leaving that in high power mode.

PBABEN, lets you establish if PORTB hooks 0 - 4 must awaken as analog feedback hooks or electronic hooks upon reset. Needless to say you can modify this in pc software in the ADCON1 enroll at any time.

The CCP element is a Catch / Compare / PWM element and your final CONFIG3H bit enables the "steering" of this result to be on either RC1 or RB3. This is handy to manage to modify in the event that you need another performance available on one of these pins (RB3 can also be analogue input 9 and RC1 could be Timer 1 oscillator input). Alternatively, your PCB layout may be simpler if you might move that result to one or the other. For prototyping, typically this doesn't matter either way.

#pragma DATA _CONFIG3H, _CCP2MX_PORTC_3H & _PBADEN_OFF_3H & _MCLRE_ON_3H

CONFIG4L includes some fascinating options and shows really obviously how essential it is to manage to configure the PIC before startup.

The DEBUG touch enables hardware debugging. You can stage through code, set breakpoints and etc - when you have your software collection correctly and this touch cleared. Hardware debugging also needs the distinctive utilization of RB6 and RB7 (also used for ICSP programming). In most integrity, we realize that successive production is usually ample to get insects, though you can debug a lot of PICs with only a PicKit2.

XINST allows for the 18F extended instruction set mode. This isn't employed by Sourceboost and in the event that you move it on in error (regardless of the compiler you're using) you will have some very unpredictable results. Among our readers spent days trying to find that which was inappropriate with his rule only to realize the XINST touch was set.

LVP provides you with the capacity to plan the PIC applying ICSP without requiring the "higher" Vpp voltage. There's a get however - you'll need to commit the RB5 green (PGM) to as an signal if you're in development method or not. Provided the PicKit2 creates the proper voltage anyway, there doesn't seem to be lots of price in changing that on for prototyping purposes.

Eventually, the STVREN gives the choice of having the PIC reset if the bunch overflowed or underflowed. If, as an example, you contact a lot of nested functions, it will allow the PIC to reset. After reset, you can examine why the PIC reset and record a fault. We suggest leaving that on - if your PIC boots in the center of doing something, you are able to reasonably assume that you've consumed the stack place (possible when you're deep in a stacked condition and then an disrupt occurs).