Wouter van Ooijen wrote:
> Note that in some cases a programmer can't even verify which chip it
> is programming: for instance the 16C84 and 16F84 do not contain a
> device ID.

And it appears all the 12 bit core devices don't have an ID.  At least the
few I've looked at don't.

> And there are some PIC types that have the same device ID
> as another PIC type

I made the assumption when I first started creating programmers that all
PICs would have a unique ID.  It seemed to be the case, and that after all
is the point of having a chip ID.  However, I later discovered that some 18F
parts have the same ID as some 16F parts.  The assumption of a single unique
ID was in several places in my software, so this took some work to address.
I dealt with this by making IDs only valid within namespaces, and each PIC
family got a different namespace.  As part of the algorithm to read the ID,
you have to know what PIC family you are talking to, so this still gives
each PIC a unique ID in the end.  So far I've got separate namespaces for
the 16 family (14 bit core), 18 family (16 bit core), and 30 family (24 bit
core).  Each of these require completely different algorithms to read the
chip ID, so there is no ambiguity.

Do you know of overlapping IDs within a family?  That would be really bad.
One of the features I like is to hook the programmer up to any PIC and it
tells you which PIC it is, as long as it has a chip ID.  So far this works
for all the PICs I've supported.

> Note that a Wisp628 does not do much in this aspect. It is the PC
> software that does the intelligent decisions. For XWisp that is: if
> you specify a chip on the command line, and that chip has an ID, and
> that ID is not found (using the reading method appropriate for the
> specified chip), then the programming is aborted with an error. Or if
> you don't specify a chip, and it can't read an ID that it recognises
> (it will try both 16F and 18F reading) the programming is also
> aborted with an error.

Yup, my software works the same way.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist