> Wouter van Ooijen wrote:
> > > For my Wisp628 programmers I use 16F628, 16F628A or 
> 16F648A, whichever I
> > have at hand, using the same .hex file. Of course I prefer 
> the 16F628A,
> > which is the cheapest of the three
> 
> You lost me there, Wouter.  You mean the Wisp628, when programming a 
> chip, doesn't check the device ID against the device the hex file was 
> assembled for?

It can't, the .hex file does not contain an identification of the chip
it was assembled/compiled for. This is a pity, uChip should at least
propose a standard way to do this. But given the sad fact that a some
programmers/programming-software and software authors still don't seem
to know that fuses information should be included in the .hex file I
doubt such a standard would be widely accepted.

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 there are some PIC types that have the same device ID as another
PIC type

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.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist