Also I think if you are using the programmer for developing (so that
program-reporogram cycles with only small changes between) then it might be
possible to do a binary difference between the last HEX and the new one and
send only the area that changed. For that maybe you can store a version info
in the ID locations and check only that one shortly before programming (if
version or ID differs program in a traditional manner).

Tamas


On 12/09/06, Olin Lathrop <olin_piclist@embedinc.com> wrote:
>
> Wouter van Ooijen wrote:
> > Olin, for the 'empty' case, do you read back all program memory? IIRC my
> > proggers read only the addresses that where present in the .hex file.
>
> Yes, that is why the Wisp628 measured significantly faster than my
> programmers for the empty cases.  Actually I think that is a legitimate
> optimization.  You could interpret no data in the HEX file as meaning
> "don't
> care" as apposed to assuming the erased state, in which case there is no
> point checking the result.  My programming software does not include such
> optimization.  It makes the conservative assumption that unspecified
> values
> are intended to be the erased value and checks them all twice.  Maybe a
> command line switch some day would be appropriate.
>
>
> ******************************************************************
> 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
>



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