Searching \ for '[PIC]:16F873 programming' 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=programming
Search entire site for: '16F873 programming'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:16F873 programming'
2000\12\14@164535 by Tony Nixon

flavicon
picon face
"M. Adam Davis" wrote:
>
> It is theoretically possible to program the full 8K of an f877 in under 20
> seconds including fuses and verify.  (This from my own calculations based
> on the programming data sheet awhile ago.)  The main bottleneck in the
> system is the speed of the serial port, and the fact that each program
> word is generally sent using two 8bit bytes.  Your 4K part should take
> less than 10 seconds in a very fast programmer.
>
> 4K takes 8K to transmit to the programmer, at the usual 9600bps you get
> about 960 bytes/sec, 8192 bytes / (960 bytes/sec) = 8.5 seconds for
> program, and possibly another 8.5 (or more) for verify, depending on how
> your programmer implements verify.  (My picstart does verify very quickly
> - I doubt each word is checked.  Chances are a long CRC is performed by
> the picstart, sent to the computer and the computer compares it with its
> own crc...)
>
> I suggest that if you need speed, develop your own programmer, or find a
> faster one.  I can almost gurantee either road would be cheaper than
> building/buying a gang programmer.

I don't understand - under 20 seconds.

send 1 word @ 9600 baud 8N1 (2 bytes @ 10 bits each)

= 20 bits X 104uS = 2.08mS

X 8192 = 17 seconds.

Not counting transfer protocols etc. and Windows delays.

2mS (from memory) minimum programming time for F series (5mS probably)

2mS X 8182 = 16 seconds

Should be 33 secs rock bottom and that doesn't include serial shifting
to and from the device.

I wouldn't trust this zero tolerance for an ICSP device.

>
> -Adam
>
> Steven Chaplin wrote:
> >
> > Has anyone made a ganged programmer for a 16F873 ?  I have an application
> > where I need to program 4 or 8 devices in circuit.  After some tests each
> > device takes roughly 40 seconds to program, this is too long and thus my
> > reason for multiple simultaneous programming.

I'm thinking of designing a kit for one after I finish the PicPocket,
which is all done bar the shouting and now I'm deciding which is the
best way to release it.

The driver PIC will not be code protected because it makes for easy
upgrades, but I'm a bit coy about the source code release. (Lots of
work) The schematic etc will be available.

I've just got to do a help file and I'm about to commit to a small PCB
run.

--
Best regards

Tony

mICro's
http://www.picnpoke.com
spam_OUTsalesTakeThisOuTspampicnpoke.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\14@173122 by Olin Lathrop

face picon face
> I don't understand - under 20 seconds.
>
> send 1 word @ 9600 baud 8N1 (2 bytes @ 10 bits each)
>
> = 20 bits X 104uS = 2.08mS
>
> X 8192 = 17 seconds.
>
> Not counting transfer protocols etc. and Windows delays.
>
> 2mS (from memory) minimum programming time for F series (5mS probably)
>
> 2mS X 8182 = 16 seconds
>
> Should be 33 secs rock bottom and that doesn't include serial shifting
> to and from the device.

I don't see why the sending and programming need to happen serially.  A
smart programmer could start programming a byte as soon as it received it.
Also, the baud rate doesn't need to be 9600 even if it is for current
implementations.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\14@173947 by Tony Nixon

flavicon
picon face
Olin Lathrop wrote:

> I don't see why the sending and programming need to happen serially.  A
> smart programmer could start programming a byte as soon as it received it.
> Also, the baud rate doesn't need to be 9600 even if it is for current
> implementations.

I just tried two methods.

16F877
19200 BAUD
WIN 95
5mS programming

Receive 8 words to a buffer - Program/Verify - request another 8 Words.

75 seconds

Receive Word - Program/Verify while receiving next word

65 seconds

--
Best regards

Tony

mICro's
http://www.picnpoke.com
salesspamKILLspampicnpoke.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\14@210400 by Olin Lathrop

face picon face
> I just tried two methods.
>
> 16F877
> 19200 BAUD
> WIN 95
> 5mS programming
>
> Receive 8 words to a buffer - Program/Verify - request another 8 Words.
>
> 75 seconds
>
> Receive Word - Program/Verify while receiving next word
>
> 65 seconds

I guess this means that whatever hardware/software you did this test on
wastes a lot of time.  The Picstart Plus sure takes a lot longer than 20
seconds also.

I was actually envisioning a smart system where the host sends the data at a
rate that at least exceeds the program rate.  This is received and put into
a buffer at the same time those bytes already received are being programmed.
This sort of overlapping sounds pretty trivial.  This brings up the question
why it apparently isn't being done that way.  Are the existing
implementations just really dumb or am I just really dumb?


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspamspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\14@212339 by Tony Nixon

flavicon
picon face
Olin Lathrop wrote:
{Quote hidden}

It's probably got a bit to do with Windows allocating time for the TX/RX
requests.

--
Best regards

Tony

mICro's
http://www.picnpoke.com
EraseMEsalesspam_OUTspamTakeThisOuTpicnpoke.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\15@090821 by Olin Lathrop

face picon face
> > I was actually envisioning a smart system where the host sends the data
at a
> > rate that at least exceeds the program rate.  This is received and put
into
> > a buffer at the same time those bytes already received are being
programmed.
> > This sort of overlapping sounds pretty trivial.  This brings up the
question
> > why it apparently isn't being done that way.  Are the existing
> > implementations just really dumb or am I just really dumb?
>
> It's probably got a bit to do with Windows allocating time for the TX/RX
> requests.

I've done a lot of different PIC projects that communicate to Windows
machines via RS-232.  I have never seen the Windows machine have a problem
keeping up at 115.2Kbaud.  NT does occasionally go to lunch for 100 to 250
mS at a time even when nothing else is running, but this is rare enough not
to effect average speed over 20 seconds.  Also, the Windows machines have
sizeable software buffers which keep on ticking even while NT goes to lunch.

The only problem I've ever had with a Windows serial port is that it takes a
surprisingly long time to obey XOFF.  In one project I sent XOFF when there
was room for 4 more incoming bytes, and the buffer got overrun anyway.  It
seems that the PC could send up to 8 more bytes, so now I send XOFF when
there are only 16 bytes left in the buffer.  This seems to work fine.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\15@092422 by Martin Schaefer

flavicon
face
By what you are writing I assume that the 4 or 8 devices have the same code
to be programmed. Than you dont have to download the code from the PC to the
programmer every time. The ProMate programmer works this way: You download
one time and then you programm the PICS one after another. The time ProMate
needs for an PIC16F873 is about 15 sec with all checking ... If your code is
smaller than 4K the programming is faster.

Martin

> {Original Message removed}

2000\12\15@222436 by Bob Ammerman

picon face
> The only problem I've ever had with a Windows serial port is that it takes
a
> surprisingly long time to obey XOFF.  In one project I sent XOFF when
there
> was room for 4 more incoming bytes, and the buffer got overrun anyway.  It
> seems that the PC could send up to 8 more bytes, so now I send XOFF when
> there are only 16 bytes left in the buffer.  This seems to work fine.

You have been lucky. Depending on the UART chip used XOFF response can get
obscenely high on Windows.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\16@051940 by Bill Westfield

face picon face
>> The only problem I've ever had with a Windows serial port is that it
>> takes a surprisingly long time to obey XOFF.  In one project I sent
>> XOFF when there was room for 4 more incoming bytes, and the buffer got
>> overrun anyway.  It seems that the PC could send up to 8 more bytes...
>
> You have been lucky. Depending on the UART chip used XOFF response can
> get obscenely high on Windows.

None of the PC uarts support SW flow control in the UART hardware itself,
and as far as I know there's no way to "pause" the transmission of those
uarts either, so the fastest you can stop tranmission may still allow up to
a full UART transmit FIFO worth of data to get out...

OTOH, XOFF based flow control has been subject to transmission delays and
the like for AGES, and I don't think anyone expects it to act very quickly.
IIRC, our code sends an xoff when the input buffer gets half full (and the
input buffer is nominally 2000 bytes... :-)

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\16@144721 by Olin Lathrop

face picon face
> You have been lucky. Depending on the UART chip used XOFF response can get
> obscenely high on Windows.

Any idea how high it gets?


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, KILLspamolinKILLspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\16@214440 by Bob Ammerman

picon face
> > You have been lucky. Depending on the UART chip used XOFF response can
get
> > obscenely high on Windows.

> Any idea how high it gets?

No, but I do know of some implementations with 128+ character transmit
FIFO's.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\17@150153 by schaplin

flavicon
face
That is true, I have a panel with 4 boards on it, all circuits identical, I
need the 4 boards programmed simultaneously so that the program time is kept
to a minimum.  I will have to make a 'device' which I can download the
program to from the PC so that this 'device' will then program my 4 boards
simultaneously

{Original Message removed}

2000\12\18@110117 by M. Adam Davis

flavicon
face
The FIFOs are getting larger and larger all the time.  The newest UARTs
that go past 250kbps require large buffers - windows (and other
non-realtime systems) can't keep up with them as a 16byte fifo would need
to be filled every 40uS @ 250kbps.

Software flow control (xon/xoff) isn't the best solution if you have to
stop a serial stream unless your host program disables or defines the size
of the fifo.  You simply can't count on just a 16 byte buffer anymore
(well, you can probably count on about 80-90% of the systems having just a
16 byte, and chances are system builders will skip the faster uarts and go
straight to USB, so it may never really be a problem for more than 20% of
your customers...).  Either define the largest packet your controller can
receive before the host system has to wait for a response, use hardware
flow control (which stops the flow after the fifo), or accept and process
data at the speed of the input stream...

-Adam

Bob Ammerman wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\18@201320 by Bob Ammerman

picon face
----- Original Message -----
From: M. Adam Davis <RemoveMEadavisspamTakeThisOuTUBASICS.COM>
To: <PICLISTEraseMEspam.....MITVMA.MIT.EDU>
Sent: Monday, December 18, 2000 11:02 AM
Subject: Re: [PIC]:16F873 programming


{Quote hidden}

WARNING: Not even hardware flow control will stop the characters in the FIFO
in most systems. Certainly 16550 and derivative UARTS do _not_ handle
hardware flow control internally: Dropping CTS causes an interrupt which the
device driver handles to determine the flow control state. This is no
different that software flow control.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\18@205936 by David VanHorn

flavicon
face
>WARNING: Not even hardware flow control will stop the characters in the FIFO
>in most systems. Certainly 16550 and derivative UARTS do _not_ handle
>hardware flow control internally: Dropping CTS causes an interrupt which the
>device driver handles to determine the flow control state. This is no
>different that software flow control.

If I hear you right, then after I assert HW flow control, the uart may
still stream bytes at me?

Sounds like a good case for setting the uart TX fifo to "1".

Also sounds like a broken implementation, setting a new low standard.

(Like Rockwell modem chips that REQUIRE a V.22BIS answer tone in 212A mode!)

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\19@072241 by Bob Ammerman

picon face
----- Original Message -----
From: David VanHorn <EraseMEdvanhornspamCEDAR.NET>
To: <RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU>
Sent: Monday, December 18, 2000 8:56 PM
Subject: Re: [PIC]:16F873 programming


> >WARNING: Not even hardware flow control will stop the characters in the
FIFO
> >in most systems. Certainly 16550 and derivative UARTS do _not_ handle
> >hardware flow control internally: Dropping CTS causes an interrupt which
the
> >device driver handles to determine the flow control state. This is no
> >different that software flow control.
>
> If I hear you right, then after I assert HW flow control, the uart may
> still stream bytes at me?

Yes, you read me right, except  "s/may/will/".

I assure you that this is the way these chips work ... I developed the
serial port driver for a multi-user DOS clone many years ago and had to deal
with this issue.

> Sounds like a good case for setting the uart TX fifo to "1".

Or, in some systems, lying to the system about the kind of UART chip.

> Also sounds like a broken implementation, setting a new low standard.

I kinda disagree here. There is really no standard, AFAIK, for the response
time for any kind of flow control.

At the other extreme, I used to have great trouble with Data General serial
interfaces that would stop on the current _bit_ whenever hardware flow
control became active (ie: CTS dropped). This had a nasty result on the
communications!

> (Like Rockwell modem chips that REQUIRE a V.22BIS answer tone in 212A
mode!)

Ugly!

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\19@084626 by Alan B. Pearce

face picon face
>At the other extreme, I used to have great trouble with Data General serial
>interfaces that would stop on the current _bit_ whenever hardware flow
>control became active (ie: CTS dropped). This had a nasty result on the
>communications!

I have a feeling that early Intel 8251 USART chips (the non-A version) had a
problem like this, or maybe it was the National 8250 chip. I definitely remember
that there was a UART chip in common circulation that had a problem like this.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\19@093850 by Olin Lathrop

face picon face
> Sounds like a good case for setting the uart TX fifo to "1".

This is a bad idea since it would require a new interrupt for each
character.

> Also sounds like a broken implementation, setting a new low standard.

There has never been a standard that specified exactly how many characters
you were allowed to send after being asked to stop.  Most implementations
kept this to a reasonable number, like 8 or 16.  The problem is apparently
that some recent PC hardware has greatly increased that number.  In some
cases it may even be beyond a PICs ability to buffer :-(


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinspam_OUTspamKILLspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


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