Microcontrollers are generally focused on a specific function, so while they're very variable products today, you will find numerous different (often conflicting) choices for how you may want the electronics to work. You may think that setting is completed in application, but what if you prefer the electronics to behave a particular way from the start? Keeping in mind that Microchip PIC devices can "boot" in a subject of milliseconds, there wants to be always a way you telling the equipment how to behave in advance of it starting up. This short article covers how to get your microcontroller based task functioning the way you assume when it starts up.
Enter config parts, or, because they was previously called, config fuses. Back in the times when microcontrollers were program-once devices, you truly did blow a fuse in order to program them. Today, most micros have display memory that can be set thousands of occasions, but you can find still one-time-programmable (OTP) units about.
Whatever the case, there's a bunch of "config words" that establish how the micro will behave from the get-go. Let's search at many of these alternatives (we'll select the PIC18F2620 as an example) and then see how exactly to program them. Sourceboost gives you most of the config strings in a ready-to-use format for including in your project. The format has got the config parts suffixed with exactly the same name while the config word so you can make certain that the proper bits are getting in the proper word. Of course, your config words will be different if you're using a different microcontroller, but you must learn enough here to position you in the proper direction.
In the 18F2620, the config bits are stored in display, but at a high storage location. They're stored at 0x300001 and upwards. For famous causes because of the way memory once was organized on PIC microcontrollers, config phrases are numbered with each number having a "high" and "low" byte.
CONFIG1L doesn't exist on the 18F2620. If it did, it would stay at 0x300000 location.
CONFIG1H contains parts that establish oscillator options. Usually, in Stuck Journeys projects we try and use external crystals which give more appropriate and reliable results. This does burn up two pins nevertheless, and often these can become more important compared to pace at that the chip is running. The outside crystal oscillator is referred to as the HS oscillator (if you're performing the conventional issue of seeking to operate the micro as rapidly since it can go). In the 18F2620, you can also permit the PLL module which will provide you with a four-times rate boost. From CONFIG1H may also be possibilities to enable the fail-safe time check (that buttons to the interior oscillator if the external one crash, and an alternative to enable the converting between various oscillator sources.
We generally suggest that you utilize an additional crystal, and turn fully off any oscillator changing / failover modes. In prototyping, it is very important to own reliable, repeatable benefits (mostly so you can reduce steadily the axes of error). It's possible to change the 18F2620 to launch using the internal oscillator (which goes at 8Mhz, or 32Mhz with the PLL enabled) and then change to the outside one (we use a 10Mhz gem with PLL permitted giving you 40Mhz). That gives you quicker start-up from stops in sleep method or on bootup, if that's crucial, however for prototyping, this is generally not necessary.
Our advised config sequence for CONFIG1H:
#pragma DATA _CONFIG1H, _OSC_HSPLL_1H & _IESO_OFF_1H & _FCMEN_OFF_1H
openbullet config 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 given threshold. It will stay static in reset state before the offer goes back within the threshold. This will suggest some battery preserving (at least, once the battery is smooth beyond a specific stage, it'll stop wearing power as quickly) - but at that time there's number performance available anyway. The power on timer waits on initial power-on for the present to move above the BOR voltage limit, then weighs around for yet another 65ms before stopping things down for real. This assists guarantee that the power is steady before wanting to accomplish any code.
We have seen some very unstable effects from the 18F2620 when screening some LED show panels. We thought the software was piling or resetting the micro when actually, what was happening was the BOR was being tripped as more LEDs were lit and the energy offer dropped. As such, unless you've got a real dependence on it, we recommend changing it off. Causing the energy source to stay before starting the firmware, is typically recommended (you're probably not going to spot the 65ms it takes).
#pragma DATA _CONFIG2L, _BOREN_OFF_2L & _BORV_2_2L & _PWRT_ON_2L
CONFIG2H offers you adjustments for the watchdog timer. This can be a timer that resets the PIC in a certain amount of time (you can extensively specify the length of time that may be). It might be excellent plan to reset your PIC if you're doing anything from that you might never recover - while hopefully you're published adequate rule that this can't happen! Alternately, the watchdog timer can also pull the PIC out of sleep mode. This means you are able to prepare for the PIC to fall asleep for a certain amount of time (if nothing otherwise happens). For prototyping, we suggest converting the watchdog timer off. If you do allow it, make sure you reset the watchdog timer regularly or - well, you are able to guess what'll happen.
#pragma DATA _CONFIG2H, _WDT_OFF_2H & _WDTPS_128_2H
CONFIG3H has a collection of configuration items. You can select for the RE3 green to be available (as insight only) and for that pin to be MCLR (which resets the micro when taken low). For prototyping, being able to reset the micro by demanding a key is simpler than dragging the ability out.
The LPT1OSC touch offers the option of a "large power" function or even a "reduced power mode" ;.The low power method is more sensitive and painful in high noise environments. So if battery consumption is very important, you need to design your signal carefully. For prototyping, obviously, we'd suggest making this in high energy mode.
PBABEN, enables you to specify if PORTB pins 0 - 4 should wake up as analog input pins or electronic pins upon reset. Of course you are able to modify this in computer software in the ADCON1 enroll at any time.
The CCP element is really a Record / Assess / PWM element and a final CONFIG3H bit enables the "steering" of the output to be on possibly RC1 or RB3. That is convenient to manage to change if you involve another functionality on one of these simple pins (RB3 is also analogue feedback 9 and RC1 could be Timer 1 oscillator input). Alternately, your PCB format could be easier if you might move that production to 1 or the other. For prototyping, typically that doesn't subject sometimes way.
#pragma DATA _CONFIG3H, _CCP2MX_PORTC_3H & _PBADEN_OFF_3H & _MCLRE_ON_3H
CONFIG4L includes some intriguing possibilities and reveals very clearly how crucial it's to have the ability to configure the PIC before startup.
The DEBUG bit enables hardware debugging. You are able to step through code, set breakpoints and etc - when you yourself have your application collection effectively and that bit cleared. Equipment debugging also involves the special use of RB6 and RB7 (also used for ICSP programming). In most integrity, we see that serial result is generally adequate to get bugs, while you are able to debug a lot of PICs with merely a PicKit2.
XINST allows for the 18F extensive training set mode. That isn't used by Sourceboost and in the event that you switch it on by mistake (regardless of the compiler you're using) you will see some pretty volatile results. One of our visitors used times trying to find what was wrong with his rule and then know the XINST touch was set.
LVP gives you the capability to program the PIC using ICSP without requiring the "higher" Vpp voltage. There is a catch however - you'll need to dedicate the RB5 green (PGM) to becoming an sign if you should be in development mode or not. Given the PicKit2 generates the best voltage anyway, there doesn't seem to be lots of price in switching that on for prototyping purposes.
Finally, the STVREN provides the option of experiencing the PIC reset if the stack overflowed or underflowed. If, for example, you contact a lot of stacked operates, it allows the PIC to reset. Once reset, you are able to examine why the PIC reset and record a fault. We recommend making this on - if your PIC boots in the midst of doing anything, you can fairly think that you've utilized the bunch place (possible when you're heavy in a nested situation and then an disrupt occurs).
No comments:
Post a Comment