A series of random and irregular jottings, documenting matters of interest (to me) in the sphere of amateur radio and beyond.

Sunday, 18 March 2012

MICROCHIP disappointments

I have spent the last seven days frustrated by failures of MICROCHIP PIC devices.

I don't mean "failures" in the sense of heat and smoke. I don't mean "failures" in the sense of faulty logical operation (we didn't get that far). I mean "failures" in the sense of not doing what the manufacturer says it can do.

Before we start complaining, let's be clear - I am a fan of PICs. I have been using them since the 90s. As readers of this blog will know, I've used them in lots of radio-related projects (such as the multi-mode beacon) and more recently in the virtual organ. I've also used them "at work" and in real-world projects, most recently the MTCLogic controller. I am a fan and - perhaps - being a fan makes it all the more disappointing when things go bad...

It started with a 16F628A. I had found some old code on the 'net and, since it was written for the 628A, I thought I'd run it in that device. So I got a sample, only to be frustrated by it.

I found that I was completely unable to program the device using either my ICD2 or my PICKit2. [Incidentally, the claim that PICKit2 DOES support the 16F628A is made here (where it does remind users that debug is impossible without an additional component)]. Most of the time, I got a failure on verification at a very low address, suggesting that no programming had happened at all. Occasionally, a few locations verified before failure. Once (in an afternoon trying to debug the issue) I got a successful programming.

Not good enough!

I could program the device in my PICStart Plus - but I have grown used to in-circuit serial programming and wanted to use it here. Besides, MICROCHIP and all their documentation and code (I'm using MPLAB 8.7) CLAIM that this is possible.

A quick look on the internet persuaded me that I'm not the only person who has fallen foul of this discrepancy between marketing claim and experienced engineering reality, so I gave up and ordered a more modern 18-pin device - the 16F88.

On delivery I found that the 16F88 was up for being programmed with either ICD2 or PICKit2. Great! Until I tried something else which is CLAIMED to be possible - using debug mode on the 16F88 with the PICKit2...

Once again, this doesn't work - most frequently in the following failure mode...

(occasionally I could get past that point, but the subsequent debug operation did not work). I looked on the 'net and - you guessed it - this is a known problem.

I didn't want to have to change device again, so I tried debugging with the ICD2. That works.

I don't mind failure per se. I do mind when somebody claims that it is possible to... when it simply is NOT possible to. I don't care if it once worked for somebody. All I care is that it did not work for me and has wasted my valuable time.

Time which is far too valuable to waste posing questions like "why change the name of timer 0's interrupt enable flag from the simple "T0IF" (12F675) to the wasteful, redundant "TMR0IF" (16F88)". I suppose I should be happy and contented by the fact that the 16F88 does manage to do (most of) what is claimed for it.

No comments:

Post a Comment

Vi suggerisco...

About Me

Engineer, who grew up in the age when hobbyists used a soldering iron (rather than a mouse) to mess with computers. Came late in life to amateur radio, where he operates the station m0xpd, conducts pointless experiments, and plays with words and ideas.