Wouter van Ooijen wrote:
> I think real USB proggers *can* be faster.

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:

      PIC   Sec full   Sec empty
  -------   --------   ---------
   16F876       51.8        15.6
   18F252       23.1        14.9
  18F2520       16.4        10.0
  30F4012       46.5        33.1
  30F3013       25.4        17.8

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.


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