It depends on the chip whether "blank" means all zeroes, or all 0xFFFF. The
old EEPROM chips would always read back 0xFFFF in unprogrammed state, but
this isn't necessarily the case with the flash chips. However, most of them
still do.

However, a verify error with all 0xFFFF generally doesn't mean the chip is
blank, it means there was a connection failure and your programmer was
unable to access the chip correctly. You might want to verify all the
connections. If you're using a serial port programmer without external
power, you might want to check if that serial port is compliant, in the
sense that it outputs sufficiently high voltages/currents for the
programming to take place.

> Rochester, 10 september 2006.
>
> Dear Frank,
>
> It depends on the chip whether "blank" means all zeroes, or all 0xFFFF.
> The
> old EEPROM chips would always read back 0xFFFF in unprogrammed state, but
> this isn't necessarily the case with the flash chips. However, most of
> them
> still do.
>
> However, a verify error with all 0xFFFF generally doesn't mean the chip is
> blank, it means there was a connection failure and your programmer was
> unable to access the chip correctly. You might want to verify all the
> connections.

That is what I did. All the wiring is as it should be, I only left out the
two ground connections....
I corrected that, but still no success.

>If you're using a serial port programmer without external
> power, you might want to check if that serial port is compliant, in the
> sense that it outputs sufficiently high voltages/currents for the
> programming to take place.

That is what I use, a serial port programmer without external power. I tried
to measure the voltage with a simple digital voltmeter, seems to be OK.
What I really need is an oscilloscope to check the serial port.

> Thanks for the correction, makes your earlier remark
> much more understandable.

:-)

> What is, in your opinion, a real programmer?

Any programmer using a "local" processor (for some reason
PIC-programmers usualy uses a PIC-processor :-) ) that handles
all the low-level programming stuff. The programmer then uses
normal serial (or USB for the newest programmers) communication
to the host system (Windows, Linux, whatever).

There are just to many potential problems with the
low-cost/no-parts/JDM/whatever style of programmers...

There are many good programmers "out there", personaly
I've used the Wisp628 from http://www.voti.nl and I've been happy
with that one.

Something that uses the PC interface as it was intended, doesn't not try to
cheat by taking power from data lines, doesn't use non-standard voltages
that "usually" work, nor try to use handshaking lines outside the
communication standard and thereby require a custom driver that is dependent
on the operating system and the specific hardware in the PC.

>
> Something that uses the PC interface as it was intended, doesn't not try
> to
> cheat by taking power from data lines, doesn't use non-standard voltages
> that "usually" work, nor try to use handshaking lines outside the
> communication standard and thereby require a custom driver that is
> dependent
> on the operating system and the specific hardware in the PC.

If the PC was truly "IBM compatible" (at least IBM desktop compatible, not
sure about IBM laptops) all these things shouldn't really be a problem.
However, very few PC are, nowadays. The JDM programmer I had worked well,
although it was slow. I agree that a programmer like the Pickit 2 is a much
better solution. The pickit 2, however, also requires a custom driver that
is dependent on the operating system, I believe.

> If the PC was truly "IBM compatible" (at least IBM desktop compatible, not
> sure about IBM laptops) all these things shouldn't really be a problem.
> However, very few PC are, nowadays. The JDM programmer I had worked well,
> although it was slow. I agree that a programmer like the Pickit 2 is a much
> better solution. The pickit 2, however, also requires a custom driver that
> is dependent on the operating system, I believe.
>

I am not so sure what you mean by "custom driver".

Under Windows, PICkit 2 is using the native built-in HID driver using
Microchip provided PC application.

Under Linux, you can use the built-in useland libusb application to talk
to PICkit 2. using pk2/pyk/piklab. Under Mac OS X, you can use the
built-in HID driver to talk to PICkit 2 with pk2.

IMHO any programmer that uses a PC port in the way it was meant to use,
and derives the Vdd and Vpp in a reliable way. In practice this means:
serial port or USB programmers (I have not seen an ethernet progger
yet), with some intelligence inside.

Wouter van Ooijen schreef:
>> What is, in your opinion, a real programmer?
>>
>
> IMHO any programmer that uses a PC port in the way it was meant to use,
> and derives the Vdd and Vpp in a reliable way. In practice this means:
> serial port or USB programmers (I have not seen an ethernet progger
> yet), with some intelligence inside.
>
> Wouter van Ooijen
OK, you and the Piclist convinced me.
I am going to order a Wisp628

Currently I am using a demo board from Velleman as a programmer, and that is
connected to the PC via 'traditional' serial line, however, my laptop just
doesn't have any of this. I mean the laptop has a serial device, but no
connector placed into the equipment. So I have to use docking station that
have the connector, but that is suffering from contact error, so sometimes
it works, sometimes does not. That's the main reason I decided to change to
'untraditional' serial line -- USB. Also as Wouter pointed out to me real
USB programmers are faster (that are not using USB to serial converter IC,
but a real USB enabled microcontroller), and I hope I will not facing to any
problems some people reported here.

> Also as Wouter pointed
> out to me real
> USB programmers are faster (that are not using USB to serial
> converter IC,
> but a real USB enabled microcontroller), and I hope I will
> not facing to any
> problems some people reported here.

I think real USB proggers *can* be faster. At least the pickit1 is much
slower than a wisp628 + converter. I don't have good data available to
say more.

Note that benchmarking proggers is as difficult as benchmarking CPUs and
other things. For instance, I recall that Olins proggers have build-in
primitives for most PICs they support, but use more slow pin-wiggling
commands for a few other chips. Wisp628 uses build-in primitives for all
chips it supports, but it supports less chips and these primitives are
slower than Olins, but faster than Olins pin-wiggling. So which one is
fastest? (I think the answer is: in most cases Olin's). As always, YMMV!

I think programming can be measured by a stopwatch. But who has the time to
measure all the chips (on which chip what programmer performs better). It
might be an interesting project though to create a table on wiki for example
and put experiences by contributors, like I have this and that programmer
and measured the following times on those chips... The rows would be the
chips while the columns the programmers.

Other interesting would be the reliability measurement (and I have no idea
how to do that in a proper way). I suppose some programmer could leave out
the verification completely for gain speed, however, that will be
highlighted in the reliability table... some other production programmer
verifies more than one times in different voltages as far as I know?

>
> > Also as Wouter pointed
> > out to me real
> > USB programmers are faster (that are not using USB to serial
> > converter IC,
> > but a real USB enabled microcontroller), and I hope I will
> > not facing to any
> > problems some people reported here.
>
> I think real USB proggers *can* be faster. At least the pickit1 is much
> slower than a wisp628 + converter. I don't have good data available to
> say more.
>
> Note that benchmarking proggers is as difficult as benchmarking CPUs and
> other things. For instance, I recall that Olins proggers have build-in
> primitives for most PICs they support, but use more slow pin-wiggling
> commands for a few other chips. Wisp628 uses build-in primitives for all
> chips it supports, but it supports less chips and these primitives are
> slower than Olins, but faster than Olins pin-wiggling. So which one is
> fastest? (I think the answer is: in most cases Olin's). As always, YMMV!
>
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: http://www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>
>

Better: for proggers with a command-line interface you can use dos
comamnds.

> But who
> has the time to
> measure all the chips (on which chip what programmer performs
> better). It
> might be an interesting project though to create a table on
> wiki for example
> and put experiences by contributors, like I have this and
> that programmer
> and measured the following times on those chips...

Good to know. I always assumed it was something custom, as it seems to
frequently fail and to require a complete disconnect and reconnect (both on
Windows 98 and on Windows XP. Haven't had problems on Windows 2000) unlike
my mouse and my keyboard. But it is now clear I was wrong in my assumption.

> Good to know. I always assumed it was something custom, as it seems to
> frequently fail and to require a complete disconnect and
> reconnect (both on
> Windows 98 and on Windows XP. Haven't had problems on Windows
> 2000) unlike
> my mouse and my keyboard.

> I think programming can be measured by a stopwatch. But who has the time to
> measure all the chips (on which chip what programmer performs better).

*Someone* has! :-)

> It
> might be an interesting project though to create a table on wiki for example
> and put experiences by contributors, like I have this and that programmer
> and measured the following times on those chips... The rows would be the
> chips while the columns the programmers.

It has been done - it was started by Olin, then James took it under PICLIST's wing, and here it is as it currently stands:

> Under Windows, PICkit 2 is using the native built-in HID driver using
> Microchip provided PC application.
personally i'm not at all convinced that making your pic programmer identify
as a human interface device is using the port as it was intended.

> > Under Windows, PICkit 2 is using the native built-in HID
> driver using
> > Microchip provided PC application.
>
> personally i'm not at all convinced that making your pic
> programmer identify
> as a human interface device is using the port as it was intended.

:)

At least at the lower protocol levels the USB port is used as it is
meant to be used. As for (mis?) use of the HID device: I think this is a
result of the lack of a simple 'no driver' device.

>> It
>> might be an interesting project though to create a table on wiki for
example
>> and put experiences by contributors, like I have this and that programmer
>> and measured the following times on those chips... The rows would be the
>> chips while the columns the programmers.

>
> Tamas,
>
> On Mon, 11 Sep 2006 11:39:10 +0100, Tamas Rudnai wrote:
>
> > I think programming can be measured by a stopwatch. But who has the time
> to
> > measure all the chips (on which chip what programmer performs better).
>
> *Someone* has! :-)
>
> > It
> > might be an interesting project though to create a table on wiki for
> example
> > and put experiences by contributors, like I have this and that
> programmer
> > and measured the following times on those chips... The rows would be the
> > chips while the columns the programmers.
>
> It has been done - it was started by Olin, then James took it under
> PICLIST's wing, and here it is as it currently stands:
>
> http://www.piclist.com/techref/microchip/devprogspeed.htm
>
> It's not very comprehensive, but it's waiting for more people to do more
> tests and submit the results.
>
> I keep meaning to test a PICkit2, but haven't had time yet...
>
> Cheers,
>
>
> Howard Winter
> St.Albans, England
>
>

> >> It
> >> might be an interesting project though to create a table on wiki for
> example
> >> and put experiences by contributors, like I have this and that programmer
> >> and measured the following times on those chips... The rows would be the
> >> chips while the columns the programmers.
>
> > It has been done - it was started by Olin, then James took it under
> PICLIST's wing,
> > and here it is as it currently stands:
> > www.piclist.com/techref/microchip/devprogspeed.htm
>
> Well, it is not what I meant, it displays PICs in the columns and
> programmers in the rows instead :-))))

Ah, you need to get one of those screens that rotates... :-)

> But seriously, invented wheel again, and if I will have some time going to
> contribute.

I did a quick set of tests on the PICkit2 with a 12F675 - hopefully James will add that to the table. Ah, and I see Mark Rages has also done PICkit2
tests, but using Pyk software instead of the Microchip stuff that comes with it. Time for a bit of an update, James? :-)

Well well, another dimension to the table: which software used for
programming :-) I can test the programming with that Velleman stuff (a kind
of Belgian chocolate :-) ), but for that one I have not got the original
programmer they provide with, so I am using WinPic instead.

>
> Tamas,
>
> On Mon, 11 Sep 2006 16:08:02 +0100, Tamas Rudnai wrote:
>
> > >> It
> > >> might be an interesting project though to create a table on wiki for
> > example
> > >> and put experiences by contributors, like I have this and that
> programmer
> > >> and measured the following times on those chips... The rows would be
> the
> > >> chips while the columns the programmers.
> >
> > > It has been done - it was started by Olin, then James took it under
> > PICLIST's wing,
> > > and here it is as it currently stands:
> > > www.piclist.com/techref/microchip/devprogspeed.htm
> >
> > Well, it is not what I meant, it displays PICs in the columns and
> > programmers in the rows instead :-))))
>
> Ah, you need to get one of those screens that rotates... :-)
>
> > But seriously, invented wheel again, and if I will have some time going
> to
> > contribute.
>
> I did a quick set of tests on the PICkit2 with a 12F675 - hopefully James
> will add that to the table. Ah, and I see Mark Rages has also done PICkit2
> tests, but using Pyk software instead of the Microchip stuff that comes
> with it. Time for a bit of an update, James? :-)
>
> Cheers,
>
>
> Howard Winter
> St.Albans, England
>
>

The real bottleneck seems to be writing and reading from the PIC, not
transferring the data between the host and the programmer. My USB
programmer does go a little faster for writing when the USB is used instead
of the serial port, but only by a small amount. As PICs get faster, this
amount may get larger. For old chips like a 16F877, you can't get around it
taking 8mS/word. This is many times slower than a 115.2Kbaud RS-232 link.

My USB programmer is currently significantly slower during readback when
using the USB. That's because the protocol was designed for RS-232 where
there is no latency to send back data. With USB there can be significant
latency, compared to 115.2Kbaud. For readback my protocol sends a request,
gets a little data, sends another request, gets a little more data, etc. I
am adding new commands that allow requesting large chunks of data so the
turnaround latency overhead will be minimal. When that is done, I expect
USB to be a little faster all around than RS-232 for the same programmer.
I'll publish full benchmarks when I get there but to give you some idea,
here are the results of some test I ran with the USBProg using RS-232:

These times include doing a bulk erase, programming, and a readback pass at
each of the Vdd limits for that chip.

> Note that benchmarking proggers is as difficult as benchmarking CPUs
> and other things. For instance, I recall that Olins proggers have
> build-in primitives for most PICs they support, but use more slow
> pin-wiggling commands for a few other chips. Wisp628 uses build-in
> primitives for all chips it supports, but it supports less chips and
> these primitives are slower than Olins, but faster than Olins
> pin-wiggling. So which one is fastest? (I think the answer is: in
> most cases Olin's). As always, YMMV!

Actually my programmers have built in algorithms for reading and writing to
all the supported PICs. The low level pin wiggling commands are only used
for very simple things that take a small fraction of the time no matter how
you do them. This mostly means performing the bulk erase. Even then the
host issues higher level pin wiggling commands that tell the controller in
the programmer to send a bunch of bits at once.

Since the bottleneck is not communications but actual programming,
especially when a fast bus like USB is available, I designed the USB
programmer with much faster (and therefore more complicated) output drivers
than my previous programmers. Both PGC and PGC are actively driven high and
low with a controlled impedence of about 150 ohms. This allows decreasing
the wait time between edges, which has a large impact on readback speed.
Some newer PICs program so fast now that this also has a significant impact
on programming speed in some cases.

Of course everything comes at a price. The PGC and PGD output drivers of
the USBProg each have 5 transistors, 8 resistors, and 5 capacitors. These
are all cheap parts, but it does take some board space. In return I get
200nS switching with 150ohm ouptut impedence, variable high side output
voltage although driven from 0-5 PIC output, ability to go to high impedence
for readback, and ability to withstand a short to anywhere from 0V to 6V
indefinitely without damage.

Tamas Rudnai wrote:
> I think programming can be measured by a stopwatch. But who has the time to
> measure all the chips (on which chip what programmer performs better). It
> might be an interesting project though to create a table on wiki for example
> and put experiences by contributors, like I have this and that programmer
> and measured the following times on those chips... The rows would be the
> chips while the columns the programmers.
>
> Other interesting would be the reliability measurement (and I have no idea
> how to do that in a proper way). I suppose some programmer could leave out
> the verification completely for gain speed, however, that will be
> highlighted in the reliability table... some other production programmer
> verifies more than one times in different voltages as far as I know?
>
> Tamas
>
>
If you want to the fastest, you should use a bootloader.
I can even think of a programmer, that put's in a bootloader first,
and then let the bootloader program the rest.
But what the hell are a few seconds, compared to writing the program ?
Ok it has it's value in "trial-and-error-programming" ;-)

On 11/09/06, stef mientki <RemoveMEs.mientkiEraseMEEraseMEmailbox.kun.nl> wrote:
>
> If you want to the fastest, you should use a bootloader.
> I can even think of a programmer, that put's in a bootloader first,
> and then let the bootloader program the rest.
> But what the hell are a few seconds, compared to writing the program ?
> Ok it has it's value in "trial-and-error-programming" ;-)

...and if you program more than one chip (like at some point I would like to
do 100) In the table mentioned earlier indicates, that for example Picstart+
is a very slow programmer, it takes 20s for programming a 12F675: 100*20s=
33.3min while EasyProg needs only 13.6s, that's 100*13.6s = 22.6 -- true,
not much you can save, but bigger the chip the longer it takes to program.

Anyway, why a bootloader performs better than ICSP?

Another completely stupid question: how could you program several PICs
parallel?

> Anyway, why a bootloader performs better than ICSP?
My guess is it should not be significantly different if ICSP is done well
but it would be very hard to do ICSP at full tilt without using programmable
logic in the programmer to implement the serial protocol (a pic can bit bang
it but even at 48mhz it can't do it at anything like full tilt), i suspect
many programmers are also quite conservative on the array cooldown delays.

> Another completely stupid question: how could you program several PICs
> parallel?
best way would probablly be to use a pic in the programmer and switch a
whole port at once for the PGD lines, verification could again be performed
by checking the whole byte at once (e.g. anything other than all zeros or
all ones must be an error).

> I think programming can be measured by a stopwatch.
> But who has the time to
> measure all the chips (on which chip what programmer
> performs better). It
> might be an interesting project though to create a
> table on wiki for example
> and put experiences by contributors, like I have
> this and that programmer
> and measured the following times on those chips...
> The rows would be the
> chips while the columns the programmers.
>
> Other interesting would be the reliability
> measurement (and I have no idea
> how to do that in a proper way). I suppose some
> programmer could leave out
> the verification completely for gain speed, however,
> that will be
> highlighted in the reliability table... some other
> production programmer
> verifies more than one times in different voltages
> as far as I know?
>
> Tamas
>
>
> On 11/09/06, Wouter van Ooijen <RemoveMEwouterTakeThisOuTspamvoti.nl>
> wrote:
> >
> > > Also as Wouter pointed
> > > out to me real
> > > USB programmers are faster (that are not using
> USB to serial
> > > converter IC,
> > > but a real USB enabled microcontroller), and I
> hope I will
> > > not facing to any
> > > problems some people reported here.
> >
> > I think real USB proggers *can* be faster. At
> least the pickit1 is much
> > slower than a wisp628 + converter. I don't have
> good data available to
> > say more.
> >
> > Note that benchmarking proggers is as difficult as
> benchmarking CPUs and
> > other things. For instance, I recall that Olins
> proggers have build-in
> > primitives for most PICs they support, but use
> more slow pin-wiggling
> > commands for a few other chips. Wisp628 uses
> build-in primitives for all
> > chips it supports, but it supports less chips and
> these primitives are
> > slower than Olins, but faster than Olins
> pin-wiggling. So which one is
> > fastest? (I think the answer is: in most cases
> Olin's). As always, YMMV!
> >
> > Wouter van Ooijen
> >
> > -- -------------------------------------------
> > Van Ooijen Technische Informatica: http://www.voti.nl
> > consultancy, development, PICmicro products
> > docent Hogeschool van Utrecht: http://www.voti.nl/hvu
> >
> >
> > --

For one thing a real MCU programmer works out the box
and can WORK with almost ALL varieties of hardware. My
first PIC programmer was with ELCHEAPO. Did not work
when I build it. I believe it was the voltage from the
parallel that cause the INVALID programming voltage.
Almost gave up on MCU entirely. Bought PICStart +
which cost me plenty*Was not aware of Wouter and Olin
during that time*. Now I own 2 programmers....... ICD2
is the one I use currently.

> The real bottleneck seems to be writing and reading from the PIC, not
> transferring the data between the host and the programmer.

Depends on the PIC you use. The oldest FLASH chips (16F84A, 16F628,
16F877, etc) used IIRC a 10 ms/word time. The latest chips use 1 ms to
write a block (IIRC 8 or 16 words?) to *each memory bank* (can be up to
8 or 16?).

> My USB programmer is currently significantly slower during
> readback when
> using the USB. That's because the protocol was designed for
> RS-232 where
> there is no latency to send back data.

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.

> Actually my programmers have built in algorithms for reading
> and writing to all the supported PICs.
> The low level pin wiggling commands are only used
> for very simple things that take a small fraction of the time
> no matter how you do them. This mostly means performing the bulk
erase.

> Another completely stupid question: how could you program several PICs
> parallel?

For *programming* (in the narrow sense) you could probably just wire the
target chips in parallel, provided that your progger has enough muscle
to drive them all. The readback (verification) is 'a bit' more
complicated!

The real answer is of course: use a gang programmer, which is
essentially a programmer with multiple independent target connectors.

stef mientki wrote:
> If you want to the fastest, you should use a bootloader.

I don't see anything inherently slower about ICSP than a bootloader. In
either case the data must be sent from the PC and the PIC's non-volatile
memory written to. In most cases the actual write time will dominate. On
some of the newer chips with large write buffers, the ICSP clocking time
could be more significant and probably less than the instructions a
bootloader must execute, but probably not by much.

Tamas Rudnai wrote:
> Another completely stupid question: how could you program several PICs
> parallel?

Short answer: You can't.

Long answer: Proper programming requires some readback, which must be done
individually. I guess in theory you could assume all the chips out there
were identical, program them write-only once, then switch to separate
readbacks. I don't know of anyone that actually does that.

If you care about this then you must be programming a lot of PICs. In that
case use multiple programmers.

> PS: Olin, your USB programmer is impressive!

Thanks. Now if I could only get the first production run units in my hand
..

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.

> > 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.

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).

>
> 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

>
> For one thing a real MCU programmer works out the box
> and can WORK with almost ALL varieties of hardware. My
> first PIC programmer was with ELCHEAPO. Did not work
> when I build it. I believe it was the voltage from the
> parallel that cause the INVALID programming voltage.
> Almost gave up on MCU entirely. Bought PICStart +
> which cost me plenty*Was not aware of Wouter and Olin
> during that time*. Now I own 2 programmers....... ICD2
> is the one I use currently.

The El Cheapo actually went through many versions. The latest version that
uses an inverter that fixes all logic levels works should work with all
parallel ports (although some BIOS compatibility settings might be required
if your port has fancy DMA access and such). The problem with the latest
version of the El Cheapo is no really its hardware interface, but the fact
that it doesn't have the necessary capabilities to program modern PICmicros.
I have tried various software packages, but the 16F628A and 16F877A can not
be programmed with it (and forget about the 18F series). The only reasonably
interesting current PICmicro that you can program with it is the 16F88, and
even that doesn't always go well. Of course, if you are interested in doing
OTP PICmicros, the El Cheapo is excellent, because of its very solid power
supply.

Tamas Rudnai wrote:
> 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).

That would require a bunch of code for that special case, and then there'd
always be the problem of getting it wrong. Getting the wrong previous
version or whatever just once will probably negate any savings in
programming time over the life of that development.

My current code always does a bulk erase first, then subsequent code counts
on starting with a blank chip. I wouldn't really want to change all that to
put in the partial update logic.

> > 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.

some problems:

- some PICs can program an individual code word, others first require an
erase of a block of code words, so even when only one word changes the
whole word must be reprogrammed

- changes that might seem small (at the C level) like adding a line
'i++' or changing 'i += 1' to 'i += 2' will likely add an extra assembly
statement, which causes all subsequent asm statements to shift. This
will likely cause differences in code page set instructions, causing
even more changes.

end conclusion: maybe maybe worth the effort for some very specific
cases, but definitely not worth the effort for the general case.

But something else: As I understand you can read a (code?) checksum
froms a PIC, even when it is read-protected. Do any programmers that for
verification, instead of reading the whole code space? Alternatively,
are there programmers that read the code space but calculate a checksum
locally and send that to the PC?

Olin Lathrop wrote:
> stef mientki wrote:
>
>> If you want to the fastest, you should use a bootloader.
>>
>
> I don't see anything inherently slower about ICSP than a bootloader.
With external programming you need a minimum amount of time according to
the specs,
with internal write the timing is done in the PIC, which I expect to be
smaller ??
Stef

Wouter van Ooijen wrote:
> But something else: As I understand you can read a (code?) checksum
> froms a PIC, even when it is read-protected.

I have never heard of that. Some implementations may write a checksum to
the user ID locations, which can be read with code protection enabled, but
that wouldn't be checking anything except those locations.

> Alternatively, are there programmers that read the code space but
> calculate a checksum locally and send that to the PC?

I don't know, mine don't. My host software receives a dump of the whole
target PIC memory via the programmer, then compares all bits to their
desired value according to the HEX file.

stef mientki wrote:
> With external programming you need a minimum amount of time according
> to the specs,
> with internal write the timing is done in the PIC, which I expect to
> be smaller ??

Sometimes the "self-timed write" mode is slower than the externally timed
write mode. This is probably due to process variations that force the
internal timer to produce the minimum guaranteed write time accross all
variations. External timing can be based on the controllers oscillator
crystal, which needs to slop to guarantee the minimum value.

Of course there are isues with that too. For example all my programmers
divide the crystal oscillator down into much slower clock ticks. The
EasyProg and ProProg use 200uS ticks, and the USBProg 83uS ticks. Since the
ticks are asynchronous to the programming code, the software first has to
round up to the number of whole tick intervals required to guarantee the
minimum wait time, then add 1 elapsed tick to count to guarantee that number
of intervals. For example, a 1.1mS wait requires 6 whole 200uS tick
intervals, so the firmware is told to wait for 7 ticks to elapse. That will
cause the wait to be from 1.2mS to 1.4mS with 1.3mS being the average. With
its shorter tick interval, the USBProg has less of this slop overhead. It
would be instructed to wait for 15 ticks to elapse to wait 1.1mS, which
would average to 1.2mS.