PIC Configuaration bit settings

[dave1803]

I'm about to try and program a PIC16F88 using a genuine PICKIT 2 or 3, I have access to either.  This is the first time I have tried to use a programmer. I have downloaded the .hex and .asm file from Silicon Chip Magazine to  complete a kit relating to one of their articles. I see the configuration bits are set up in the .asm file. 

I will be using the stand alone software, trying to avoid MPLAB certainly at this first step, so am I correct to assume that the set up of the configuration bits in the hex file means I don't have to do anything else other than download the hex file and program the IC?

Any other pitfalls? (I've seen Dave Jones' video on the PICKIT3 !). Sorry to have to ask such a basic question but I can't seem to find the answer anywhere?

Thanks

David

[Ian.M]

Your understanding is basically correct.

The PICkit 2 and 3 GUI standalone software loads the CONFIG memory space from the hex file, so (unlike some third party programmers)  you should *NEVER* need to manually set the CONFIG.  You *can* override CONFIG bits once the hex file is loaded, before programming, but the interface to do so is particularly dumb so one should not even contemplate doing so if its possible to re-build from the source.  If you do need to edit CONFIG bits in the hex file for an older PIC, its far easier under MPLAB 8 which has a CONFIG dialog with device specific named fields and descriptive options.  You cannot directly edit CONFIG bits at all under MPLAB X, although there is a wizard to let you select CONFIG options and generate sourcecode for them.

The CLI utilities PK2CMD and PK3CMD *ONLY* load CONFIG bits from the hex file, as they don't have any editing capability.

CAUTION: The standalone PICkit 3 GUI utility loads PICkit 2 emulation firmware into the programmer.  It will *NOT* be recognised by MPLAB (8 or X) until you either revert to MPLAB mode within the utility, or connect the programmer to USB, with no target connected, while holding down the programmer's button, which forces bootloader mode so MPLAB can correctly identify it and reinstall MPLAB compatible firmware.

There are a few other programming pitfalls, some of which are unique to 18 pin PICs, but you are most unlikely to encounter them if you are programming a blank PIC16F88.  They mostly occur when attempting to reprogram a PIC in-circuit, with ill-considered prior firmware that conflicts with ICSP programming mode entry, and target power requirements greater than the few tens of mA the programmer can supply, so 'Vpp first' entry mode cannot be used.

[NivagSwerdna]

Read the manual and press the button when appropriate and all should be OK

[dave1803]

Ian, thank you so much for your detailed answer confirming my assumptions and the warning about the way the PICkit3 software can cause issues when using MPLAB.  I think I may use the PICkit2 GUI standalone software and avoid trying any in circuit programming until I have a bit more experience or need to program a PIC not supported by the PICkit2.   

Nivag, thanks for the reassurance.

David

[Ian.M]

ICSP is great, saving a significant amount of time in the build-burn-test development cycle + saving a lot of wear and tear on the PIC' pins.  Its also the only viable method of doing development on SMD PICs.   The same physical interface also permits in-circuit debugging of debug-capable PICs.  If you are working on your own projects I strongly recommend it.

ICSP reprogramming problems start when you disable external /MCLR in the CONFIG, + a set of other clock source, and I/O and peripheral configuration choices that can cause bus conflicts on the ICSP pins.  If you strictly avoid disabling /MCLR,  (simply keep it high with a 10K pullup resistor), you wont run into any ICSP reprogramming problems, short of ill-considered external circuits driving the ICSP I/O pins harder than the programmer (and PIC) can overcome during  ICSP.  Giving up a single input only pin is a small price to pay for easy development.

Unfortunately Silicon Chip (and the UK magazine (Everyday) Practical Electronics, which frequently share projects with Silicon Chip), have a tendency to cram as much as possible into a PIC16F88, without considering ICSP, when from a hobbyist/developer viewpoint a larger PIC in the same core family with more I/O pins would have been a better choice (e.g. PIC16F886), allowing the ICSP pins to be dedicated to programming and debugging.

[dave1803]

That is an interesting point about the use of the PIC16F88 instead of a larger device.

It may be for a mixture of historical and commercial considerations. Projects from Silicon Chip Magazine, many of which were later republished in EPE (now Practical Electronics in the UK) frequently made only the hex files available or sold a pre-programmed PIC - although many of the asm files appear to have been released as free issue a few years later.

If you look at an old program such as the programmable ignition the PIC 16F88 was possibly appropriate at the time, even though it seems only just about large enough to handle the code. I have noted that some of the programming “components” appear to have been repeated in later projects such as the digital tachometer and high energy ignition. From my very limited knowledge it seems this would have been beneficial for the programmer, John Clarke, to retain the PIC16F88 as he must have put in considerable effort to develop the aforementioned program.

It’s possible that these magazines have missed a trick by not encouraging readers to make software changes to some of the projects. That brings about its own problems, but also possible benefits by setting up an effective support forum in what appears to be a struggling electronics hobby market as evinced by the demise of Dick Smith in Australia and Maplin in the UK.
 
I have noted your comments about the benefits of ICSP and keeping the pins dedicated to programming and debugging. Thank you once again.

David