Searching \ for '[PIC] PIC programmer performance comparison' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programmer
Search entire site for: 'PIC programmer performance comparison'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC programmer performance comparison'
2005\10\04@191956 by olin piclist

face picon face
I've gotten a bit further with the PIC programmer performance chart at
http://www.embedinc.com/picprg/bench.htm.  The same HEX files I used are now
available.  I know some of you already provided some programming times, but
I'd like everything to be done using the same files just to be sure.

Wouter, what is the correct URL for the Wisp628?  Can you test with a real
COM port instead of the USB converter, if that makes a difference in speed?
Jim, I'd be happy to fill in numbers for any of your programmers that are
either publicly available or were previously and have an installed base.
Ken, is your programmer publicly available?  If so, I'd be happy to put up
information on it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\04@205344 by Jinx

face picon face
PS+, using your files

F88, 0 - 0FFF

Previous contents to all 3FFF, 32s P 8s V
All 3FFF to all random, 32s P, 8s V

F452, 0 - 7FFF

Previous contents to all FFFF, 131s P, 20s V
All FFFF to all random, 131s P, 20s V

I can test 877 and 10F later (it'll only dig the PS+'s hole deeper)

2005\10\04@222142 by Jinx

face picon face
PS+

12F675 0 - 3FF

All random to all 3FFF, 16s P, 4s V
All 3FFF to all random, 16s P, 4s V

2005\10\04@231957 by Gaston Gagnon

face
flavicon
face
Olin Lathrop wrote:

>I've gotten a bit further with the PIC programmer performance chart at
>http://www.embedinc.com/picprg/bench.htm.  The same HEX files I used are now
>available.  I know some of you already provided some programming times, but
>I'd like everything to be done using the same files just to be sure.
>
>  
>
I have programmed a 16F88-I/P  with a Tait like LPT type programmer
using PICALL /P16PRO version 0.15alpha dec 2003 software.

16f88_empty.hex takes 6 secondes
16f88.hex takes 7 secondes

Gaston Gagnon


2005\10\05@020411 by Wouter van Ooijen

face picon face
> PS+, using your files
> (snip)

If we want Olins table to mean anything the contributants must include
more details:
- programmer used (hardware and software revision)
- PC used (brand, speed, OS, OS version / patches)
- PC software used (version!)

Wouter van Ooijen

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


2005\10\05@020412 by Wouter van Ooijen

face picon face
> Wouter, what is the correct URL for the Wisp628?

http://www.voti.nl/wisp628

> Can you test with a real
> COM port instead of the USB converter, if that makes a
> difference in speed?

I can't, but someone will surely do. I doubt it will make that much
difference, the PC software tself is rather slow, especially in the
verification. For the 'contest' we'd better throw in Rob Hamerling's
XWisp2.

Wouter van Ooijen

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


2005\10\05@030042 by Chen Xiao Fan

face
flavicon
face
To be honest, I think calling the speed comparison
"performance comparison" and "contest" may be a bit
misleading here even with an apple to apple comparison.

It is good to have some comparison of programming speed
but the speed should not be the deciding factors for
purchasing a programmer.

Programming speed is only a samll part of the programmer
performance. There are a lot of factors affecting the
purchasing (or building) decision: Price, technical
support, host software support (might include OS support),
reliability, ease of use, ease of building, the fame of the
developer, etc. For example, people using Linux can not
use EasyProg/ICD2 unless someone comes out Linux support of
EasyProg/ICD2. People who want to build their programmers
will often choose JDM/Wisp628 because of the simplicity
of building them. People who want to play with dsPICs may
need to choose EasyProg/ICD2 due to their support of dsPICs.
People doing professional work should consider Promate III/
ProProg due to their features and they may not be the
fastest.

I do not have a PS+ but I guess PS+ is quite reliable and
quite easy to use. It should support most of the 12F/16F/18F
(including 18F2550/4550) and other chips with the release
of MPLAB 7.22 scheduled in a few days according to a Microchip
Forum post. There are PS+ clones as well like JUPIC which
will be cheaper.

Regards,
Xiaofan


{Original Message removed}

2005\10\05@032113 by Jinx

face picon face
> If we want Olins table to mean anything the contributants must
> include more details

XP Pro
2.4GHz AMD Athlon
MPLAB 6.40.00.0
PS+ PUM f/w version - 2.4 d/l. pspls41006.hex I think
(still haven't found the PUM download page to check)

2005\10\05@032502 by Jinx

face picon face
> PS+. It should support most of the 12F/16F/18F
> (including 18F2550/4550) and other chips with the release
> of MPLAB 7.22 scheduled in a few days

MPLAB will allow you to code for chips but without the f/w
upgrade for the PUM you can't actually put that code into a
chip. You have to wait for the PUM upgrade to catch up ;-((

2005\10\05@032758 by Wouter van Ooijen

face picon face
> To be honest, I think calling the speed comparison
> "performance comparison" and "contest" may be a bit
> misleading here even with an apple to apple comparison.

You are of course right, but the Olin page can still help: at the very
last it can show that a particular programmer / pic chip / OS is
supported at all (for this purpose the figures could even be reduced to
* in the relevant table positions). But of course it does not indicate
the opposite.

PS note the quotes around contest in my post :)

Wouter van Ooijen

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



2005\10\05@035845 by Chen Xiao Fan

face
flavicon
face
Please refer to the following posts from JasonK of
Microchip. By the way, Microchip Froum is getting
better and better with more and more advanced users
joining the discussions. Lots of super users like
ric/pacer/BobBarr/J_doin/Olin/... are really very
good at PICs and very helpful.

Regards,
Xiaofan

http://forum.microchip.com/tm.asp?m=111109

JasonK
Super Member

Posts: 550
Joined: Nov. 14, 2003
From: Microchip Technology in Arizona, USA
Status: offline

Hi Locky42,

The PIC18F4550 was originally scheduled for PICSTART Plus support
in MPLAB IDE 7.21, but that got delayed to 7.22. Currently, MPLAB
IDE 7.22 is tentatively (barring any last minute problems uncovered
in testing) scheduled to be released to our website sometime next
week (week of Oct 10).

...


{Original Message removed}

2005\10\05@041827 by Jinx

face picon face

> Please refer to the following posts from JasonK of Microchip

AFAIK MPLAB is quite separate from PS+. MPLAB 6.40
supports ds and rf PICs for example (as far as being able to
write and assemble code), but the PS+ does not allow you
to put that code into the chip. Whilst I don't doubt that a new
release of MPLAB will support more chips, without the PUM
f/w being upgraded you can't flash code to an actual device

That's the way it has always been in the past, perhaps things have
changed and a new PUM file is now included with either MPLAB
or MPASM

Even at the PS+ page at Microchip there's no mention at all of
a new, or for that matter even old, PUM file. But MC do like to
hide things all over the place, maybe it's somewhere at their site.
Frankly I'm happy with what I'm using (for now) and can't be
bothered turning their site upside down looking for something I
don't need anyway

2005\10\05@043845 by Chen Xiao Fan

face
flavicon
face
The latest PS+ firmware update is bundled with MPLAB.
For example, my MPLAB 7.10 installation at work PC
(not the latest) has three hex files:
pspls43004.hex and psf31100.hex and pspls42003.hex.

The readme files of MPLAB have all the latest information
regarding chip support of PS+, Promate II, Promate III
and ICD2. You do not need to download the whole
MPLAB to get the readme files. It is a separate zip
archive. MPLAB 6.40 is way too old IMHO.

Regards,
Xiaofan

Release Notes for PICSTART(R) Plus Development Programmer
 MPLAB IDE v7.10
 Software DLL Version       v4.10
 Operating System Version   v4.30.04   (pspls43004.hex)

March 16, 2005
-----------------------------------------------------------------
1. Device Support List
-----------------------------------------------------------------

               Supported in                       Supported in
Device          OS (FW) Version    Device          OS (FW) Version
-------------   ---------------    -------------   ---------------
PIC10F200!      (04.30.00)         PIC16F688       (04.10.00)        
PIC10F202!      (04.30.00)         PIC16F716       (04.10.00)        
PIC10F204!      (04.30.00)         PIC16F72        (02.10.01)        
PIC10F206!      (04.30.00)         PIC16F73        (02.10.01)        
PIC12C508       (02.01.00)         PIC16F737       (04.10.00)        
PIC12C508A      (02.01.00)         PIC16F74        (02.10.01)        
PIC12C509       (02.01.00)         PIC16F747       (04.10.00)        
PIC12C509A      (02.01.00)         PIC16F76        (02.10.01)        
PIC12C671       (02.01.00)         PIC16F767       (04.10.00)        
PIC12C672       (02.01.00)         PIC16F77        (02.10.01)        
PIC12CE518      (02.01.00)         PIC16F777       (04.10.00)        
PIC12CE519      (02.01.00)         PIC16F818!      (03.00.07)        
PIC12CE673      (02.01.00)         PIC16F819!      (03.00.07)        
PIC12CE674      (02.01.00)         PIC16F83        (02.01.00)        
PIC12F508       (04.30.00)         PIC16F84        (02.01.00)        
PIC12F509       (04.30.00)         PIC16F84A       (02.01.00)        
PIC12F629       (03.00.07)         PIC16F87        (04.10.00)        
PIC12F635       (04.20.03)         PIC16F870       (02.01.00)        
PIC12F675       (03.00.07)         PIC16F871       (02.01.00)        
PIC12F683       (04.02.00)         PIC16F872       (02.01.00)        
PIC16C505       (02.01.00)         PIC16F873       (02.01.00)        
PIC16C54        (02.01.00)         PIC16F873A      (03.00.07)        
PIC16C54C       (02.01.00)         PIC16F874       (02.01.00)        
PIC16C55        (02.01.00)         PIC16F874A      (03.00.07)        
PIC16C554       (02.01.00)         PIC16F876       (02.01.00)        
PIC16C558       (02.01.00)         PIC16F876A      (03.00.07)        
PIC16C55A!      (02.01.00)         PIC16F877       (02.01.00)        
PIC16C56        (02.01.00)         PIC16F877A      (03.00.07)        
PIC16C56A       (02.01.00)         PIC16F88        (04.10.00)        
PIC16C57        (02.01.00)         PIC16HV540      (02.01.00)        
PIC16C57C!      (02.01.00)         PIC17C42        (02.01.00)        
PIC16C58A       (02.01.00)         PIC17C42A       (02.01.00)        
PIC16C58B       (02.01.00)         PIC17C43        (02.01.00)        
PIC16C620       (02.01.00)         PIC17C44        (02.01.00)        
PIC16C620A      (02.01.00)         PIC17C752       (02.01.00)        
PIC16C621       (02.01.00)         PIC17C756       (02.01.00)        
PIC16C621A      (02.01.00)         PIC17C756A      (02.01.00)        
PIC16C622       (02.01.00)         PIC17C762       (02.01.00)        
PIC16C622A      (02.01.00)         PIC17C766       (02.01.00)        
PIC16C62A       (02.01.00)         PIC18C242       (02.01.00)        
PIC16C62B       (02.01.00)         PIC18C252       (02.01.00)        
PIC16C63        (02.01.00)         PIC18C442       (02.01.00)        
PIC16C63A       (02.01.00)         PIC18C452       (02.01.00)        
PIC16C642       (02.01.00)         PIC18C658!      (02.01.00)        
PIC16C64A       (02.01.00)         PIC18C858!      (02.01.00)        
PIC16C65A       (02.01.00)         PIC18F1220*!#   (04.10.00)        
PIC16C65B       (02.01.00)         PIC18F1320*!#   (04.10.00)        
PIC16C66        (02.01.00)         PIC18F2220*     (04.02.00)        
PIC16C662       (02.01.00)         PIC18F2320*     (04.02.00)        
PIC16C67        (02.01.00)         PIC18F2331*!    (04.02.00)        
PIC16C71        (02.01.00)         PIC18F2410      (04.30.01)        
PIC16C710       (02.01.00)         PIC18F242       (02.30.01)        
PIC16C711       (02.01.00)         PIC18F2420      (04.30.01)        
PIC16C712       (02.01.00)         PIC18F2431*!    (04.02.00)        
PIC16C715       (02.01.00)         PIC18F2455      (04.30.01)        
PIC16C716       (02.01.00)         PIC18F248       (02.30.01)        
PIC16C717       (02.10.01)         PIC18F2510      (04.30.01)        
PIC16C72        (02.01.00)         PIC18F2515      (04.30.01)        
PIC16C72A       (02.01.00)         PIC18F252       (02.30.01)        
PIC16C73A       (02.01.00)         PIC18F2520      (04.30.01)        
PIC16C73B       (02.01.00)         PIC18F2525      (04.30.01)        
PIC16C745       (02.01.00)         PIC18F258       (02.30.01)        
PIC16C74A       (02.01.00)         PIC18F2585      (04.30.01)        
PIC16C74B       (02.01.00)         PIC18F2610      (04.30.01)        
PIC16C76        (02.01.00)         PIC18F2620      (04.30.01)        
PIC16C765       (02.01.00)         PIC18F2680      (04.30.01)        
PIC16C77        (02.01.00)         PIC18F4220*     (04.02.00)        
PIC16C770       (02.10.01)         PIC18F4320      (04.02.00)        
PIC16C771       (02.10.01)         PIC18F4331      (04.02.00)        
PIC16C773       (02.01.00)         PIC18F4410      (04.30.01)        
PIC16C774       (02.01.00)         PIC18F442       (02.30.01)        
PIC16C781       (02.30.00)         PIC18F4420      (04.30.01)        
PIC16C782       (02.30.00)         PIC18F4431      (04.02.00)        
PIC16C923       (02.01.00)         PIC18F4455      (04.30.01)        
PIC16C924       (02.01.00)         PIC18F448       (02.30.01)        
PIC16C925       (02.01.00)         PIC18F4510      (04.30.01)        
PIC16C926       (02.01.00)         PIC18F4515      (04.30.01)        
PIC16CE623      (02.01.00)         PIC18F452       (02.30.01)        
PIC16CE624      (02.01.00)         PIC18F4520      (04.30.01)        
PIC16CE625      (02.01.00)         PIC18F4525      (04.30.01)        
PIC16F505       (04.30.00)         PIC18F458       (02.30.01)        
PIC16F54        (04.02.00)         PIC18F4585      (04.30.01)        
PIC16F57!       (04.02.00)         PIC18F4610      (04.30.01)        
PIC16F627       (02.10.01)         PIC18F4620      (04.30.01)        
PIC16F627A      (04.10.00)         PIC18F4680      (04.30.01)        
PIC16F628       (02.10.01)         PIC18F6620!     (03.00.07)        
PIC16F628A      (04.10.00)         PIC18F6720!     (03.00.07)        
PIC16F630       (03.00.06)         PIC18F8620!     (03.00.07)        
PIC16F636       (04.12.04)         PIC18F8720!     (03.00.07)        
PIC16F648A      (04.10.00)         rfPIC12C509AF!  (02.01.00)        
PIC16F676       (03.00.06)         rfPIC12C509AG!  (02.01.00)        
PIC16F684       (04.10.00)        

*  Indicates beta-support part(s) in this release.

!  See Sections 8-14 in this readme for information on programming
  these devices.

#  Some revisions of these parts fail to program.

...

{Original Message removed}

2005\10\05@044512 by Alan B. Pearce

face picon face
>AFAIK MPLAB is quite separate from PS+.

Only if you have the older units. If you have the new units with the PUM,
then MPLAB can download an update into the PS+, and hence change the
supported device list "on the fly".

2005\10\05@044941 by Jinx

face picon face
> The latest PS+ firmware update is bundled with MPLAB.
> For example, my MPLAB 7.10 installation at work PC
> (not the latest) has three hex files:
> pspls43004.hex and psf31100.hex and pspls42003.hex.

Well, that's good to know. That would be why there isn't a
separate download page for the PUM now

> MPLAB to get the readme files. It is a separate zip
> archive. MPLAB 6.40 is way too old IMHO.

I'm OK with it. When I'm finished the jobs I'm on I'll probably
install the new one

Tell me, does 7.x save bookmarks ? They were a helpful
introduction with 6.40 but they aren't saved with the project.
If 7.x saves bookmarks maybe I'll upgrade sooner. If it
doesn't, there's no advantage doing so at present

2005\10\05@050532 by Jan-Erik Soderholm

face picon face
Jinx wrote :

> does 7.x save bookmarks ?

Not 7.20...

Jan-Erik.



2005\10\05@052008 by Chen Xiao Fan

face
flavicon
face
What is the use of a bookmark? It is not saved along with
the project/workspace under 7.10.

Regards,
Xiaofan

-----Original Message-----
From: Jinx
Sent: Wednesday, October 05, 2005 4:50 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] PIC programmer performance comparison

I'm OK with it. When I'm finished the jobs I'm on I'll probably
install the new one

Tell me, does 7.x save bookmarks ? They were a helpful
introduction with 6.40 but they aren't saved with the project.
If 7.x saves bookmarks maybe I'll upgrade sooner. If it
doesn't, there's no advantage doing so at present

2005\10\05@053702 by Jinx

face picon face
> > does 7.x save bookmarks ?
>
> Not 7.20...

<disappointed> aw...........

2005\10\05@054201 by Jinx

face picon face

> What is the use of a bookmark? It is not saved along with
> the project/workspace under 7.10.

Use Ctrl K to make a bookmark(s) and Ctrl L to jump to it
(them). Very useful when editing, as useful as Breaks I find,
saves one heck of a lot of scrolling. The PITA is that you have
to re-set them when you re-open a project

2005\10\05@100234 by olin piclist

face picon face
Jinx wrote:
> XP Pro
> 2.4GHz AMD Athlon
> MPLAB 6.40.00.0
> PS+ PUM f/w version - 2.4 d/l. pspls41006.hex I think

Thanks to you and other that have responded.  I have updated the page
http://www.embedinc.com/picprg/bench.htm with the information received so
far.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\05@102654 by olin piclist

face picon face
Wouter van Ooijen wrote:
> I can't, but someone will surely do. I doubt it will make that much
> difference, the PC software tself is rather slow, especially in the
> verification.

I only asked about without USB adapter because that made things slower on my
programmers.  I wouldn't be fair to include extra delay caused by the
adapater and not inherent to the programmer.

You can send me what you've got and I'll make a note of the particulars.
The data can be updated later if better results are available.

> For the 'contest' we'd better throw in Rob Hamerling's XWisp2.

I wasn't thinking of this as a contest.  There are many other reasons to
chose a programmer.  I've noticed that other attributes of various
programmers are usually well described, but speed is not.  Even when it is,
it's not very meaningful without a comparison.  My comparison chart will
never be perfect and can't possibly note all the particulars of each test,
but at least it something.

For example, I wasn't aware that there the ProProg was noticeably slower
than the EasyProg in most cases, but faster in one of the cases.  I was
expecting it to be slightly slower, and was surprised by the results.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\05@102930 by olin piclist

face picon face
Chen Xiao Fan wrote:
> It is good to have some comparison of programming speed
> but the speed should not be the deciding factors for
> purchasing a programmer.

I never said it should be, and you will notice there are no conclusions on
my page about what programmer may be "better".  However speed is one factor,
and comparisons between programmers were previously anecdotal at best.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\05@193553 by Jinx

face picon face
> Thanks to you and other that have responded

Note that the results for 452 are under 252. The upload time
for a PS+ and 252 would be less. Perhaps only a week and
a half

2005\10\05@195918 by olin piclist

face picon face
Jinx wrote:
> Note that the results for 452 are under 252. The upload time
> for a PS+ and 252 would be less. Perhaps only a week and
> a half

I don't follow.  The 18F252 and 18F452 are identical to a programmer.  They
only vary in the number of pins.  I've never seen a difference in
programming time between the two.  Have you measured a difference with the
Picstart+?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\05@203626 by Jinx

face picon face
> The 18F252 and 18F452 are identical to a programmer

You're right, the difference is I/O, not memory size. I was
confusing it with the 16k x42

2005\10\06@004725 by Jim Robertson

flavicon
face

>
>
>
>Jim, I'd be happy to fill in numbers for any of your programmers that are
>either publicly available or were previously and have an installed base.

You know I wouldn't get involved in this without providing my own
list of notes, caveats and tips etc.
I just cannot give this any priority at this time and it would not
make sense to anyway as I am right
in the middle of releasing new firmware that is considerably faster
than previous generations.

Not meaning to be snobby. Like you, I would insist that it is done in
such a way as to be relevant,
I just cannot do it justice right at the moment.



>Ken, is your programmer publicly available?  If so, I'd be happy to put up
>information on it.


Ken is currently not on the PICLIST according to his own words as
posted on the
microchip forum.



-Jim



>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, <http://www.embedinc.com>http://www.embedinc.com
>

2005\10\06@012850 by Chen Xiao Fan

face
flavicon
face
I think Olin may have already read the thread in the
Microchip Forum.

Microchip Forum
http://forum.microchip.com/tm.asp?m=117082
Subject: Open Source PIC Programmer
>From Ken:
"Let me add that another requirement that I feel is mandatory
for a PIC programmer is a variable Vpp supply that is adjusted
programmatically. I think most of us are in agreement that Vdd
should be variable, but I feel that having a programmatically
variable Vpp supply keeps one from "painting oneself into a corner".
It is also necessary to comply with programming specifications
since some of the Vpp max/min windows are fairly narrow compared
with others. I'm not currently subscribed to the PICList, but I
remember making a PICList post (more detailed post) about this
a while back. It still might be in the archives."

Ken is considering a cross-platform GUI programmer
software (using RealBaisc 2005 or similar) for a good
PIC programmer (firmware controlled variable Vdd
and variable Vpp). I think this is an interesting
topic.

I am not so sure about Wisp628 but I think it is not
really controlled as well. PICKit 1/PICkit 2 can
control the Vpp in theory but WH Tan finds the
Vpp waveform is not good enough. Currently PICKit
2 does not support 18F so this is only a future
issue. It can do variable Vdd as well but I think
it is not implemented yet.

MPLAB ICD2 is using an SMPS (boost converter)
to get Vpp and use a digital poti to control the
Vpp. However it does not control target Vdd and that
is why it has problem with Vpp-before-Vdd device and
the reason it is called a prototype programmer.

EasyProg is a production programmer according to
Microchip's definition since it can vary the Vdd
for verification (2-pass varify). However,
EasyProg does not do firmware control of Vpp right
now so Olin is recommending a volatge divider for
some new PIC 18F device.

-----Original Message-----
From: Jim Robertson
Sent: Thursday, October 06, 2005 12:47 PM
To: spam_OUTpiclistTakeThisOuTspammit.edu
Subject: [PIC] PIC programmer performance comparison

>Ken, is your programmer publicly available?  If so, I'd be happy
>to put up information on it.

Ken is currently not on the PICLIST according to his own words as
posted on the
microchip forum.

2005\10\06@025155 by kravnus wolf

picon face
I had to upgrade my PS+ with the PUM. It programs
faster nowadays.

John

--- "Alan B. Pearce" <.....A.B.PearceKILLspamspam@spam@rl.ac.uk> wrote:

> >AFAIK MPLAB is quite separate from PS+.
>
> Only if you have the older units. If you have the
> new units with the PUM,
> then MPLAB can download an update into the PS+, and
> hence change the
> supported device list "on the fly".
>
> --

2005\10\06@200957 by James Newton, Host

face picon face
Olin, hosting the page when you sell a pic programmer is going to lead to
questions of credibility. I personally do not doubt that you will be fair,
but others may.

I would be happy to host the page on piclist.com and moderate the comments,
data, etc... If you think I can be trusted to be fair about it. I don't
(currently) sell a pic programmer.

Since the site is a wiki, you (or anyone) could post data directly to the
page. I would edit it in as appropriate.

This is exactly the sort of thing that piclist.com was designed for.

---
James Newton: PICList webmaster/Admin
jamesnewtonspamKILLspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com




> {Original Message removed}

2005\10\07@072412 by olin piclist

face picon face
James Newton, Host wrote:
> Olin, hosting the page when you sell a pic programmer is going to lead
> to questions of credibility. I personally do not doubt that you will be
> fair, but others may.
>
> I would be happy to host the page on piclist.com and moderate the
> comments, data, etc... If you think I can be trusted to be fair about
> it. I don't (currently) sell a pic programmer.
>
> Since the site is a wiki, you (or anyone) could post data directly to
> the page. I would edit it in as appropriate.
>
> This is exactly the sort of thing that piclist.com was designed for.

OK, go ahead if you want.  I don't have any links to that page from anywhere
else on my site yet anyway.  I typed the HTML in directly, so there is
nothing further to give you other than the page itself.  Just upload it from
http://www.embedinc.com/picprg/bench.htm.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\07@130148 by James Newton, Host

face picon face
Done. You can find it at:
http://www.piclist.com/techref/microchip/devprogspeed.htm

I didn't move the hex file (it still comes from your site) but I will do
that Monday when I am back in the office.

To keep people working on one source, you might want to change your page to
indicate where the piclist.com page is.

Anyone can post comments using the form at the bottom of the page. I'll edit
the comments in.

---
James Newton: PICList webmaster/Admin
.....jamesnewtonKILLspamspam.....piclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com




> {Original Message removed}

2005\10\08@075807 by Jim Robertson

flavicon
face

>
>
>
>Jim, I'd be happy to fill in numbers for any of your programmers that are
>either publicly available or were previously and have an installed base.


Just discovered that the WARP-13 software do not like the hex files
Olin has provided.
The number of entries per line exceeds what I have arbitrarily set as
a maximum. Why
I set an upper limit if sixteen I don't know. There is no good reason
and I cannot see that
Olin's files with thirty-two entries are outside the standard even if
everyone else seems to
be using a maximum of sixteen.

I have corrected this error and the fix up will be in the next
WARP-13 software release.

Also noticed that the hex files for the 18F2520 and 18F452 have too
much data eeprom defined,
probably because the intended data is spread to every other byte like
it would be in a  hex file
for a 12-bit or 14-bit core parts.  The Hex files for the 18F252
however are correct. That  one's
Olin's to fix.


-Jim



>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, <http://www.embedinc.com>http://www.embedinc.com
>

2005\10\08@114902 by Xiaofan Chen

face picon face
Here are some test results for Wisp628 (using "go" command).

Wisp628 1.09 firmware and xwisp2w 1.7.2 on Windows XP SP2 Professional.
AMD64 3000+ (1.8GHz) PC with NForce 3 chipset.

18f252.hex: 63.61 sec
18252_empty.hex: 1.58 sec

E:\Coding\XWISP2172>xwisp2w port 1 go hex\18f252.hex
xwisp2 version 1.7.02 for Windows (Sep 25 2005, Open Watcom C 1.30)
File hex\18f252.hex loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Detected target: 18F252 revision 04 (ID=0404)
Target erased
Transferring image to 18F252 via Wisp628
Transferring program memory...OK!
Verifying program memory......OK!
Transferring ID memory........OK!
Verifying ID memory...........OK!
Transferring data memory......OK!
Verifying data memory.........OK!
Transferring fuses memory.....OK!
Verifying fuses memory........OK!
Write-Verify terminated successfully in 62.23 seconds
Putting target in run mode
xwisp2 terminated successfully in 63.61 seconds

E:\Coding\XWISP2172>xwisp2w port 1 go hex\18f252_empty.hex
xwisp2 version 1.7.02 for Windows (Sep 25 2005, Open Watcom C 1.30)
File hex\18f252_empty.hex loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Detected target: 18F252 revision 04 (ID=0404)
Target erased
Transferring image to 18F252 via Wisp628
Transferring program memory...OK!
Verifying program memory......OK!
Transferring ID memory........OK!
Verifying ID memory...........OK!
Transferring data memory......OK!
Verifying data memory.........OK!
Transferring fuses memory.....OK!
Verifying fuses memory........OK!
Write-Verify terminated successfully in 0.19 seconds
Putting target in run mode
xwisp2 terminated successfully in 1.58 seconds

2005\10\08@134708 by olin piclist

face picon face
Jim Robertson wrote:
> Also noticed that the hex files for the 18F2520 and 18F452 have too
> much data eeprom defined,
> probably because the intended data is spread to every other byte like
> it would be in a  hex file
> for a 12-bit or 14-bit core parts.  The Hex files for the 18F252
> however are correct.

Early on there was some confusion about exactly how the EEPROM data was
supposed to be stored in the HEX file.  This wasn't helped by Microchip
keeping the CODE_PACK directive secret for so long.  Some early versions of
my software assumed EEPROM data was stored in the HEX file at even addresses
only for PIC 18.  This was fixed a while ago and the -D18 command line
option added to interpret HEX files not created with CODE_PACK.  It may be
that the problem HEX files were created a while back, or that PIC_READ
somehow writes out the old format.  I'll check into it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\08@141546 by olin piclist

face picon face
Xiaofan Chen wrote:
> E:\Coding\XWISP2172>xwisp2w port 1 go hex\18f252_empty.hex
>  xwisp2 version 1.7.02 for Windows (Sep 25 2005, Open Watcom C 1.30)
> File hex\18f252_empty.hex loaded and is Intel Hex format conforming
> Programmer Wisp628, firmware version 1.09
> Detected target: 18F252 revision 04 (ID=0404)
> Target erased
> Transferring image to 18F252 via Wisp628
> Transferring program memory...OK!
> Verifying program memory......OK!
> Transferring ID memory........OK!
> Verifying ID memory...........OK!
> Transferring data memory......OK!
> Verifying data memory.........OK!
> Transferring fuses memory.....OK!
> Verifying fuses memory........OK!
> Write-Verify terminated successfully in 0.19 seconds
> Putting target in run mode
> xwisp2 terminated successfully in 1.58 seconds

Does the Wisp628 skip verification of locations programmed to the erased
state?  I know Wouter is good, but reading back an entire 18F252 in 190mS
seems a little too good.  I've updated the page
http://www.embedinc.com/picprg/bench.htm with your information.  For now
I've added a note that the Wisp628 may not verify locations programmed to
the erased state.  I would like this note to be more precise.  Anyone that
knows how it really works, please let me know.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\08@145702 by Denny Esterline

picon face
Using a JDM programmer (Olimex PIC-PG2C) with IC-Prog 1.05C and a "real"
serial port on a 1.3 Ghz Athalon under Win98. (with the chip in the socket
on the programmer, except for the '675- that used jumper wires to a
breadboard with no external circuitry)

16F876A empty - 15 seconds program / 15 seconds verify
16F876A - 20 seconds program / 20 seconds verify
16F88 empty - 13 seconds program / 7 seconds verify
16F88 - 13 seconds program / 10 seconds verify
12F675 empty - 14 seconds program / 4 seconds verify
12F675 - 31 seconds program / 4 seconds verify
(the only '252 I have handy is the LF version - not sure if that would skew
the results or not)
18LF252 empty - 47 seconds program / 27 seconds verify
18LF252 - 49 seconds program / 29 seconds verify


I also wanted to compare against a bootloader. I tried with  bloader /
screamer from Sparkfun but it first tests the hex file for reset vector
compliance. Since the test files were blank and random it would not program
them. For some idea of comparison I tried a program I've been working on.
16F877A - JDM programmer - 21 seconds program / 12 seconds verify
Same file, same chip, bloader / screamer v1.7 from sparkfun, 4Mhz
10 seconds program / no verify

-Denny


2005\10\08@153510 by Rob Hamerling

flavicon
face


Olin Lathrop wrote:

> Does the Wisp628 skip verification of locations programmed to the erased
> state?  I know Wouter is good, but reading back an entire 18F252 in 190mS
> seems a little too good.

Wisp628 verifies only the (non blank) locations of the hex file.
The compare is done by the PC program (XWisp or XWisp2): it reads back
from the target only the non blank parts of the hex file.

Regards, Rob.


--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

2005\10\08@153526 by olin piclist

face picon face
Denny Esterline wrote:
> 16F876A empty - 15 seconds program / 15 seconds verify
> 16F876A - 20 seconds program / 20 seconds verify
> 16F88 empty - 13 seconds program / 7 seconds verify
> 16F88 - 13 seconds program / 10 seconds verify
> 12F675 empty - 14 seconds program / 4 seconds verify
> 12F675 - 31 seconds program / 4 seconds verify
> (the only '252 I have handy is the LF version - not sure if that
> would skew the results or not)
> 18LF252 empty - 47 seconds program / 27 seconds verify
> 18LF252 - 49 seconds program / 29 seconds verify

OK, I've updated the page again at http://www.embedinc.com/picprg/bench.htm.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\08@164439 by Wouter van Ooijen

face picon face
> Does the Wisp628 skip verification of locations programmed to
> the erased state?

Wisp628 does not decide this, it is the host software that decides.

XWisp (but that is not the host SW that the figures refer to!) reads
back only the location that are present in the .hex file. My reasoning
is that when a location is not present in the .hex file you don't care
what is at the corresponding location in the chip.

Wouter van Ooijen

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


2005\10\08@174936 by Denny Esterline

picon face
Looks like I made a typo, my software is revision D. So that should read
IC-Prog 1.05D

Sorry for any inconvenience.

-Denny

{Quote hidden}

skew
> the results or not)
> 18LF252 empty - 47 seconds program / 27 seconds verify
> 18LF252 - 49 seconds program / 29 seconds verify
>
>
> I also wanted to compare against a bootloader. I tried with  bloader /
> screamer from Sparkfun but it first tests the hex file for reset vector
> compliance. Since the test files were blank and random it would not
program
> them. For some idea of comparison I tried a program I've been working on.
> 16F877A - JDM programmer - 21 seconds program / 12 seconds verify
> Same file, same chip, bloader / screamer v1.7 from sparkfun, 4Mhz
> 10 seconds program / no verify
>
> -Denny
>
>
> --

2005\10\08@175150 by olin piclist

face picon face
Rob Hamerling wrote:
> Wisp628 verifies only the (non blank) locations of the hex file.
> The compare is done by the PC program (XWisp or XWisp2): it reads back
> from the target only the non blank parts of the hex file.

Does it do this word by word, or if blocks of 2**N words are blank, or
starting from the last non-blank word to the end, or something else?

I can kindof see the point of not checking from the last non-blank word to
the end, but otherwise this seems dangerous to me since 3FFF could be valid
and important data.  Verification is just as much making sure bits are 1 as
0.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\08@175715 by olin piclist

face picon face
Wouter van Ooijen wrote:
> XWisp (but that is not the host SW that the figures refer to!) reads
> back only the location that are present in the .hex file. My reasoning
> is that when a location is not present in the .hex file you don't care
> what is at the corresponding location in the chip.

I suppose that's reasonable, but my xxx_empty.hex files do specify all
locations, except that they are all specified to be the erased value.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\08@181218 by olin piclist

face picon face
Denny Esterline wrote:
> Looks like I made a typo, my software is revision D. So that should read
> IC-Prog 1.05D

Fixed.  http://www.embedinc.com/picprg/bench.htm.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\08@182355 by Wouter van Ooijen

face picon face
> > XWisp (but that is not the host SW that the figures refer to!) reads
> > back only the location that are present in the .hex file.
> My reasoning
> > is that when a location is not present in the .hex file you
> don't care
> > what is at the corresponding location in the chip.
>
> I suppose that's reasonable, but my xxx_empty.hex files do specify all
> locations, except that they are all specified to be the erased value.

I can only say what XWisp does, which is *not* the PC program used to
get the figures that were posted.

One could argue that a small program will (with the tools I know) result
in a small .hex file, so xxx_empty.hex would not be a very relevant test
case.

Wouter van Ooijen

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


2005\10\08@182358 by Wouter van Ooijen

face picon face
> Does it do this word by word, or if blocks of 2**N words are blank, or
> starting from the last non-blank word to the end, or something else?

Rob will probably answer for his software.

For XWisp it is not the 3FFF value but the presence of an address in the
.hex file. If it is there, it will be checked, 0x3FFF or not. If it is
not there, it will not be checked.

OTOH, and I can see a weakness there, when a chip is read and the result
is written to a .hex file, 0x3FFF words (this of course depends on the
PIC core) are *not* written to the .hex file.

Wouter van Ooijen

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


2005\10\09@041434 by Rob Hamerling

flavicon
face

> Rob Hamerling wrote:
>> Wisp628 verifies only the (non blank) locations of the hex file.
>> The compare is done by the PC program (XWisp or XWisp2): it reads back
>> from the target only the non blank parts of the hex file.

Olin Lathrop wrote:
> Does it do this word by word, or if blocks of 2**N words are blank, or
> starting from the last non-blank word to the end, or something else?

XWisp2 assumes that all words which are not addressed in the hex file
are erased in the target. Verify of program memory is performed by
Xwisp2 in blocks of 4 words from begin to end. Blocks with all words
0x3FFF are not read back from the target, thus not really verified (even
blocks which are explicitly set in the hex file to all 0x3FFF).

Regards, Rob,

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

2005\10\09@110121 by olin piclist

face picon face
Rob Hamerling wrote:
> XWisp2 assumes that all words which are not addressed in the hex file
> are erased in the target. Verify of program memory is performed by
> Xwisp2 in blocks of 4 words from begin to end. Blocks with all words
> 0x3FFF are not read back from the target, thus not really verified
> (even blocks which are explicitly set in the hex file to all 0x3FFF).

That explains the very fast times for the xxx_empty HEX file.  However, I
think this is not a good idea.  Wouter's method of verifying whatever
locations were specified in the HEX file is more reasonable.  If a address
is listed in the HEX file, then I think the software must assume that the
value there is significant, whether it happens to be the erased value or
not.  While a bunch of successive ADDLW h'FF' instructions aren't likely,
successive values of 3FFFh could be valid table entries.  Verification is
just as much to catch erase failures as it is to catch write failures.  In
fact the few times I've seen genuine verification failures, I seem to
remember that most of them were 0s that should have been 1s.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\30@100753 by olin piclist

face picon face
James Newton wrote back on 7 October 2004:
> Done. You can find it at:
> http://www.piclist.com/techref/microchip/devprogspeed.htm
>
> I didn't move the hex file (it still comes from your site) but I will do
> that Monday when I am back in the office.
>
> To keep people working on one source, you might want to change your page
to
> indicate where the piclist.com page is.
>
> Anyone can post comments using the form at the bottom of the page. I'll
edit
> the comments in.

For some reason I never saw this message.  I noticed it just now looking
around in the PIClist archives.  I did wonder what happened, but figured you
got busy or something.

I have added more information since you uploaded the page, so you probably
want to do it again, http://www.embedinc.com/picprg/bench.htm.  I'll then
change the page to be just a note pointing to the URL above.  Sorry about
that.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\10\30@121653 by James Newton, Host

face picon face
Done.

Please note that ANYONE can add a comment to the bottom of that page, but
only the page editor (me, or David Cary) can change the table.

---
James.



> {Original Message removed}


'[PIC] PIC programmer performance comparison'
2006\04\08@055609 by Rob Hamerling
face picon face

Xwisp2 users,

Follow-up of a conversation of about half a year ago...

> Rob Hamerling wrote:
>> XWisp2 assumes that all words which are not addressed in the hex file
>> are erased in the target. Verify of program memory is performed by
>> Xwisp2 in blocks of 4 words from begin to end. Blocks with all words
>> 0x3FFF are not read back from the target, thus not really verified
>> (even blocks which are explicitly set in the hex file to all 0x3FFF).

Olin Lathrop wrote:

{Quote hidden}

I finally took some time to improve the verify behaviour of Xwisp2. In
version 1.9.0, released today, I introduced the 'full' command option.
When specified all memory locations are verified, also the locations not
in the hex file.  It may not be very 'intelligent', but it ensures the
target contains the full (and nothing but the) contents of the hex file.

Xwisp2 can be found at http://www.robh.nl/ (pointer in left margin).

Regards, Rob.



--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

2006\04\08@141505 by Vasile Surducan

face picon face
On 10/5/05, Chen Xiao Fan <EraseMExiaofanspam_OUTspamTakeThisOuTsg.pepperl-fuchs.com> wrote:
> Please refer to the following posts from JasonK of
> Microchip. By the way, Microchip Froum is getting
> better and better with more and more advanced users
> joining the discussions. Lots of super users


Without any offence, I've taken a fast look.
Do you think the answers to this topic was the best indeed ?

http://forum.microchip.com/tm.aspx?m=146105


greetings,
Vasile

2006\04\08@142135 by Bob Axtell

face picon face
Vasile Surducan wrote:

{Quote hidden}

flipping the wires? I think that was a joke...?

--Bob

--
Note: To protect our network,
attachments must be sent to
@spam@attachKILLspamspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\04\08@175036 by Bob Barr

flavicon
face
On Sat, 08 Apr 2006 11:21:36 -0700, Bob Axtell wrote:


>>
>>Without any offence, I've taken a fast look.
>>Do you think the answers to this topic was the best indeed ?
>>
>>http://forum.microchip.com/tm.aspx?m=146105
>>
>>
>>greetings,
>>Vasile
>>
>>  
>>
>flipping the wires? I think that was a joke...?
>

I don't think so. The previous response from the OP indicated that the
external signal was floating wrt the DSP.


Regards, Bob

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...