If you are in the market for a PIC microcontroller programmer, you may want to consider a model with an In-Circuit Debugger (ICD). [Rajendra] put together a great tutorial on using an ICD when debugging PIC firmware, which makes a pretty convincing argument for owning one.
In his tutorial, he happens to be using a MikroElektronika PICflash2, but he says that there are plenty of other ICDs out there if you are not keen on this particular model. The PICflash2 not only acts as an ICD, but as the name suggests it works as an ICSP as well.
[Rajendra] walks us through a short debugging session using some simple code that reads data from an LM34DZ temperature sensor, displaying the results on an LCD screen. While he isn’t actually hunting for bugs, he does show how easy it is to step through the PIC’s code one statement at a time, evaluating variables and registers along the way.
[Rajendra] does point out that using an ICD does occupy a few I/O pins while running, limiting your resources just a bit. We think that being able to debug code as it runs is pretty reasonable tradeoff if you don’t necessarily need each and every pin available for use.
13 thoughts on “Making The Case For In-circuit Debugging Tools”
For the price of that programmer/debugger I’d be extremely cautious. The PicKit3 (which is Microchip’s current low-end offering) is much more likely to be supported in MPlabX (the new Microchip IDE). Also, the PicKit3 is half the price.
However, that said, debugging on the Pic is a godsend. Nice tutorial.
When I was moving from AVR into PIC, I read on a lot of websites advising against the PicKit3 claiming the older PicKit2 was better.
The newer model was more available and I have not had any problems with it. For the price it works amazingly.
I think I would rather stab myself in the eye than try to use a PIC without it.
MikroElektronika is a great company with a really easy to use compiler. They are recognized by Microchip directly as a quality option. Yes it is a little more expensive, but having checked them out it is a good option.
As for debugging. Not using a debugger makes trouble shooting code a complete pain in the but. For the longest time I refused to utilize my debuggers. Then I decided to and realized how hard i was making my own life. It can save you hours of time. Its worth the investment of time and money.
Easy24-33 v6 Development System – a general purpose development system for low pin count PIC24 MCUs and dsPIC DSCs.
Use coupon code TPXM9L7
LV-32MX v6 Development System – a full-featured development system for 32-bit PIC32 MCU applications.
Use coupon code TPZM9K6
opps thats at http://www.microchipdirect.com
Indeed, The ablility to debug your code on the target hardware is massively useful, and is the main reason why I never got on with the Ardiuno.
I picked up a chinese PicKit2 clone on ebay for $20 a few years ago, and wouldnt develop in the PIC without it.
I used a knockoff ICD2 when I started learning microcontrollers. Stepping through the code line by line was amazingly useful..
Until I was working on a project with a heating element that normally operated for a 1/4 second :S
That’s pretty funny. A debugger certainly isn’t without it’s risks…
Yeah, I am working on a very timing-critical system, and the best I can do in many cases is essentially use a “trace port” in the form of spare GPIOs that get toggled when certain things happen. That plus a saleae Logic gets me where I need to go when my serial-port debugging doesn’t cut it. An ICD would be useful in inspecting the state of things during non-timing-critical sections, but my serial debugging is just about as effective.
I’ve actually planned ahead on the design I’m working on now, with an entire 8-bit port plus a spare “clock” line available. If absolutely have to, I can hook up an FT245 or FT2232 to that, and have the ability to bang debug bytes out over that at up to ~10MB/sec (32MHz chip: write byte[++], toggle clock, toggle clock, repeat). If I switch to a slightly bigger chip I can even use the memory ports to do the same thing with even higher trace rates.
Good to see the PIC getting a little attention! I have a PICkit3. The ability to easily debug either in the simulator or the real hardware is wonderful.
hah, as usua had is reading my mind , i bought a pickit 3 a few days ago and have made a semi compete breakout board for my 16f1937.
but i’ sti strugging to get the pic to compety talk to the chip
are you powering the chip?
“The PICflash2 not only acts as an ICD, but as the name suggests it works as an ICSP as well.”
you make it sound like there is a single ICD that dont work as ICSP
Please be kind and respectful to help make the comments section excellent. (Comment Policy)