Searching \ for '[PIC] program upload' 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/devices.htm?key=pic
Search entire site for: 'program upload'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] program upload'
2006\09\10@012533 by Frank Abbing

flavicon
face
I try to program an 18F4520. I use the winpic program. This finds errors
when verifying, it reads back all 0xFFFF.
Is this normal for an unprogrammed chip or is 0x0000 to be expected?

Frank Abbing

2006\09\10@075151 by Maarten Hofman

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

Greetings,
Maarten Hofman.

2006\09\10@080025 by peter green

flavicon
face
FF is normal for a pic that hasn't been programmed, you aren't trying to use
a 452 profile for the 4520 are you?

> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu]On Behalf
> Of Frank Abbing
> Sent: 10 September 2006 06:26
> To: piclistspamKILLspammit.edu
> Subject: [PIC] program upload
>
>
> I try to program an 18F4520. I use the winpic program. This finds errors
> when verifying, it reads back all 0xFFFF.
> Is this normal for an unprogrammed chip or is 0x0000 to be expected?
>
> Frank Abbing
> -

2006\09\10@093734 by Frank Abbing

flavicon
face


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

>
> Greetings,
> Maarten Hofman.
> --

Thank you!

2006\09\10@094148 by Frank Abbing

flavicon
face

----- Original Message -----
From: "peter green" <.....plugwashKILLspamspam.....p10link.net>
To: "Microcontroller discussion list - Public." <EraseMEpiclistspam_OUTspamTakeThisOuTmit.edu>
Sent: Sunday, September 10, 2006 2:00 PM
Subject: RE: [PIC] program upload


> FF is normal for a pic that hasn't been programmed, you aren't trying to
> use
> a 452 profile for the 4520 are you?

No, I am not doing that. Does using the wrong profile mean that nothing
changes in the pic when trying to program it?

Frank Abbing


2006\09\10@155727 by Jan-Erik Soderholm

face picon face
Frank Abbing wrote :

> That is what I use, a serial port programmer
> without external power.

Not that many would regard that as an error in it's own.
The best advice you could get is to get a real programmer.

Jan-Erik.



2006\09\10@161139 by Jan-Erik Soderholm

face picon face
Damn,

It should be "Note that..." not "Not that..."...

I've corrected the text below.

Jan-Erik.

-----Original Message-----
From: piclist-bouncesspamspam_OUTmit.edu [@spam@piclist-bouncesKILLspamspammit.edu]On
Behalf
Of Jan-Erik Soderholm
Sent: den 10 september 2006 21:57
To: KILLspampiclistKILLspamspammit.edu
Subject: RE: [PIC] program upload


Frank Abbing wrote :

> That is what I use, a serial port programmer
> without external power.

Note that many would regard that as an error in it's own.
The best advice you could get is to get a real programmer.

Jan-Erik.



2006\09\10@174819 by Frank Abbing

flavicon
face
Thanks for the correction, makes your earlier remark much more
understandable.
What is, in your opinion, a real programmer?

Frank Abbing

Jan-Erik Soderholm schreef:
> Damn,
>
> It should be "Note that..." not "Not that..."...
>
> I've corrected the text below.
>
> Jan-Erik.
>
> {Original Message removed}

2006\09\10@180343 by Jan-Erik Soderholm

face picon face
Frank Abbing wrote :

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

Jan-Erik.



2006\09\10@180756 by olin piclist

face picon face
Frank Abbing wrote:
> What is, in your opinion, a real programmer?

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.

Check out my offerings at http://www.embedinc.com/products or Wouter's
Wisp628.


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

2006\09\10@181112 by Xiaofan Chen

face picon face
On 9/10/06, Frank Abbing <RemoveMEfrabbTakeThisOuTspamplanet.nl> wrote:
> Thanks for the correction, makes your earlier remark much more
> understandable. What is, in your opinion, a real programmer?
>

Perhaps Wisp628, PICkit 2, EasyProg and others. It is said that
simple programmers which are based on parallel port
(Tait type, EPIC+, etc) are okay as well.

PICkit 2 is supported by Microchip and it does support many PICs
including 18F4520.

2006\09\10@211319 by Maarten Hofman

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

Greetings,
Maarten Hofman.

2006\09\10@215430 by Xiaofan Chen

face picon face
On 9/10/06, Maarten Hofman <spamBeGonecashimorspamBeGonespamgmail.com> wrote:

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

Regards,
Xiaofan

2006\09\11@025439 by Wouter van Ooijen

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

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


2006\09\11@030013 by Wouter van Ooijen

face picon face
> The pickit 2, however, also requires a
> custom driver that
> is dependent on the operating system, I believe.

no, it uses the standard HID driver

Wouter van Ooijen

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


2006\09\11@032334 by Frank Abbing

flavicon
face


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

Frank Abbing

2006\09\11@045652 by Tamas Rudnai

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

Tamas


On 11/09/06, Frank Abbing <TakeThisOuTfrabbEraseMEspamspam_OUTplanet.nl> wrote:
{Quote hidden}

> -

2006\09\11@053827 by Wouter van Ooijen

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


2006\09\11@063911 by Tamas Rudnai

face picon face
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 <RemoveMEwouterspamTakeThisOuTvoti.nl> wrote:
{Quote hidden}

> -

2006\09\11@070211 by Wouter van Ooijen

face picon face
> I think programming can be measured by a stopwatch.

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

Indeed, interesting. But don't forget to factor out things like .hex
file size (some proggers do a small file significantly faster), PC
speed, etc.

Another variable: the pickit2 programming 16F917 code is fast, but
programming the EEPROM is very slow. And the PC software does not
auto-detect whether EEPROm info is present in 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


2006\09\11@083454 by Maarten Hofman

face picon face
>
>
> no, it uses the standard HID driver


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.

Greetings,
Maarten Hofman.

2006\09\11@093226 by Wouter van Ooijen

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

That seems to be a common problem, nobody seems to know realy why this
happens. You might check http://www.voti.nl/pickit2faq/index.html

Wouter van Ooijen

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


2006\09\11@093633 by Howard Winter

face
flavicon
picon face
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


2006\09\11@094806 by peter green

flavicon
face

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


2006\09\11@101835 by Wouter van Ooijen

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

Wouter van Ooijen

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


2006\09\11@110806 by Tamas Rudnai

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

Well, it is not what I meant, it displays PICs in the columns and
programmers in the rows instead :-))))

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

Thanks,
Tamas



On 11/09/06, Howard Winter <HDRWEraseMEspam.....h2org.demon.co.uk> wrote:
{Quote hidden}

> -

2006\09\11@122329 by Howard Winter

face
flavicon
picon face
Tamas,

On Mon, 11 Sep 2006 16:08:02 +0100, Tamas Rudnai wrote:

{Quote hidden}

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


2006\09\11@125415 by Tamas Rudnai

face picon face
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 11/09/06, Howard Winter <EraseMEHDRWspamh2org.demon.co.uk> wrote:
{Quote hidden}

> -

2006\09\11@174326 by olin piclist

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

2006\09\11@181428 by stef mientki

flavicon
face
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"  ;-)

btw, SPAMCOP or some other guard has blocked this list again :-(

Stef

2006\09\11@184212 by Tamas Rudnai

face picon face
On 11/09/06, stef mientki <RemoveMEs.mientkiEraseMEspamEraseMEmailbox.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?

Thanks,
Tamas
PS: Olin, your USB programmer is impressive!

--
unPIC -- The PIC Disassembler
http://unpic.sourceforge.net

2006\09\11@192800 by peter green

flavicon
face

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

2006\09\11@222057 by John Chung

picon face
You can use a toggle pin to measure the speed of the
programming. Stopwatch is not too accurate......
Blinky led can help you time the programming..

John

--- Tamas Rudnai <RemoveMEtamas.rudnaispam_OUTspamKILLspamgmail.com> wrote:

{Quote hidden}

2006\09\11@223837 by John Chung

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

John

--- Wouter van Ooijen <EraseMEwouterspamspamspamBeGonevoti.nl> wrote:

{Quote hidden}

> --

2006\09\12@031535 by Wouter van Ooijen

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

another think to make life diffocult for benchmarkers :)

{Quote hidden}

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.  

I must have confused you proggers with some other product.

Wouter van Ooijen

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


2006\09\12@031535 by Wouter van Ooijen

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

Wouter van Ooijen

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


2006\09\12@064849 by olin piclist

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


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

2006\09\12@065340 by olin piclist

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


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

2006\09\12@074617 by olin piclist

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

2006\09\12@080348 by Wouter van Ooijen

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

I agree :)

But: one more catch for the programmer-benchmarkers....

Wouter van Ooijen

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


2006\09\12@080545 by Tamas Rudnai

face picon face
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 <RemoveMEolin_piclistKILLspamspamembedinc.com> wrote:
{Quote hidden}

> -

2006\09\12@085146 by Maarten Hofman

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

Greetings,
Maarten Hofman.

2006\09\12@110940 by olin piclist

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


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

2006\09\12@115116 by Wouter van Ooijen

face picon face
> > 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?

Wouter van Ooijen

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


2006\09\12@125405 by stef mientki

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

2006\09\12@150854 by olin piclist

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


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

2006\09\12@155239 by olin piclist

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


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

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