Searching \ for '[PIC]: In Circuit Programming - 16F877' 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: 'In Circuit Programming - 16F877'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: In Circuit Programming - 16F877'
2002\03\09@045159 by Tim H.

picon face
<Topic Tag Added>

It depends on which method you're interested in. I'll describe both.
First, LVP (Low-Voltage Programming):

For LVP, you'll need control of MCLR (need control of MCLR in HVP as
well). You'll also need control of RB3. So, we have, Vss, MCLR, RB6, RB7
and RB3; 3 I/O lines. LVP needs to be enabled in the config bit for it
to work.

As for protocol:

RB6/RB7/RB3/MCLR LOW
RB3 goes HIGH and then Vdd is applied to MCLR.
You're now in LVP mode.

For HVP (High-Voltage Programming) mode, it's similiar, but one less pin
and the need for the Vpp (12-14V) on MCLR.

I've had success with entering HVP mode while the LVP bit was set in the
config word. To enter HVP, you do like so:

RB6/RB7/MCLR LOW
Vpp applied to MCLR
You're now in programming mode using HVP.

Note that the only way to turn off LVP is to enter HVP and clear the LVP
bit in the config word.

Was all that clear and conise?

-Tim Hamel

Brian Taylor wrote:
{Quote hidden}

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


2002\03\10@145204 by uter van ooijen & floortje hanneman

picon face
> It depends on which method you're interested in. I'll describe both.
> First, LVP (Low-Voltage Programming):

And maybe you don't need ICSP? Consider a bootloader, 1 pin minimum (and if
you pay me I'll make a version that can bootload using only the MCLR pin).

Wouter van Ooijen
--
Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler, Wisp programmer, WLoader bootloader, PICs kopen

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


2002\03\10@175900 by Dwayne Reid

flavicon
face
At 02:43 PM 3/10/02 +0100, wouter van ooijen & floortje hanneman wrote:

>(and if you pay me I'll make a version that can bootload using only the
>MCLR pin).

Its not April 1st yet.  How ???

dwayne


Dwayne Reid   <spam_OUTdwaynerTakeThisOuTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

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


2002\03\10@180532 by Bob Ammerman

picon face
> And maybe you don't need ICSP? Consider a bootloader, 1 pin minimum (and
if
> you pay me I'll make a version that can bootload using only the MCLR pin).
>
> Wouter van Ooijen

What a great idea, and I even know how to do it. Very sneaky!

Bob  Ammerman
RAm Systems

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


2002\03\10@202413 by Robert Rolf

picon face
Well, pay the man and you'll get your answer <G>

Think level modulation of the MCLR pin. Maybe a zener or two. Current
modulation for return data.

Dwayne Reid wrote:
>
> At 02:43 PM 3/10/02 +0100, wouter van ooijen & floortje hanneman wrote:
>
> >(and if you pay me I'll make a version that can bootload using only the
> >MCLR pin).
>
> Its not April 1st yet.  How ???
>
> dwayne

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


2002\03\10@202854 by Bob Ammerman

picon face
> At 02:43 PM 3/10/02 +0100, wouter van ooijen & floortje hanneman wrote:
>
> >(and if you pay me I'll make a version that can bootload using only the
> >MCLR pin).
>
> Its not April 1st yet.  How ???
>
> dwayne

Here is a hint: it's all in the timing.

Bob Ammerman
RAm Systems

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


2002\03\10@210711 by Olin Lathrop

face picon face
> > And maybe you don't need ICSP? Consider a bootloader, 1 pin minimum (and
> if
> > you pay me I'll make a version that can bootload using only the MCLR
pin).
> >
> > Wouter van Ooijen
>
> What a great idea, and I even know how to do it. Very sneaky!

I think I do too, but I don't want to spill his beans.  I wonder if we're
all thinking the same, or there are different solutions.  I admit I hadn't
thought of it until Wouter claimed he could do it.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.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.


2002\03\10@225620 by M. Adam Davis

flavicon
face
The method I'm thinking of (timed resets) would not be very reliable
from pic to pic, I suspect, due to slight variations in startup times,
unless you went to very long timing periods, which would delay going
into the actual program under non-programming circumstances...

-Adam

Bob Ammerman wrote:

{Quote hidden}

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


2002\03\11@011006 by uter van ooijen & floortje hanneman

picon face
> Think level modulation of the MCLR pin. Maybe a zener or two. Current
> modulation for return data.

'level modulation' nice buzzword. But who needs return data?

Wouter van Ooijen
--
Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler, Wisp programmer, WLoader bootloader, PICs kopen

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


2002\03\11@011008 by uter van ooijen & floortje hanneman

picon face
> >(and if you pay me I'll make a version that can bootload using only the
> >MCLR pin).
>
> Its not April 1st yet.  How ???

An no-one is paying yet ;)

You can transfer data to a PIC by using the interval between resets. Note
that I did not promise any particular speed, it would be VERY slow (maybe 1
bit /second or so). I once made a one-button menu interface this way. May
the correct speed would be about 1 baud and using multiple bits per baud
could speed it up.

Wouter van Ooijen
--
Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler, Wisp programmer, WLoader bootloader, PICs kopen

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


2002\03\11@022533 by Robert Rolf

picon face
wouter van ooijen & floortje hanneman wrote:
>
> > Think level modulation of the MCLR pin. Maybe a zener or two. Current
> > modulation for return data.
>
> 'level modulation' nice buzzword.

It's good enough for DTH satellite guys. 12V H polarity, 18V V polarity.

> But who needs return data?

Verify programming success. Flash does wear out and sometimes you get a bad
bit.

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


2002\03\11@083649 by Olin Lathrop

face picon face
> Well, pay the man and you'll get your answer <G>
>
> Think level modulation of the MCLR pin. Maybe a zener or two. Current
> modulation for return data.

If it's what I'm thinking of then its timing, not level related.  You'll
have to pay Wouter for the details.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamspam_OUTembedinc.com, http://www.embedinc.com

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


2002\03\11@083654 by Olin Lathrop

face picon face
> The method I'm thinking of (timed resets) would not be very reliable
> from pic to pic, I suspect, due to slight variations in startup times,
> unless you went to very long timing periods, which would delay going
> into the actual program under non-programming circumstances...

I think it can be done quite reliably at reasonable speed.  Remember that
the oscillator keeps running during a reset.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, 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


2002\03\11@083706 by Olin Lathrop

face picon face
> You can transfer data to a PIC by using the interval between resets. Note
> that I did not promise any particular speed, it would be VERY slow (maybe
1
> bit /second or so). I once made a one-button menu interface this way. May
> the correct speed would be about 1 baud and using multiple bits per baud
> could speed it up.

I don't see why you can't transfer data into the PIC much faster than this.

In one scenario you use the length of the ON period only to transfer
information.  MCLR is blipped low just long enough to cause a reset, then
release for one of several specified times that each have diffefent
meanings.  The ON periods need only be long enough so that the work
associated with them can be carried out.

Other scenarios are also possible where the OFF period is timed, or both.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spamBeGoneolinspamBeGonespamembedinc.com, http://www.embedinc.com

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


2002\03\11@120903 by Dwayne Reid

flavicon
face
Ahhh . . .

The floodlights just went on!

At 08:21 AM 3/11/02 -0500, Olin Lathrop wrote:

>In one scenario you use the length of the ON period only to transfer
>information.  MCLR is blipped low just long enough to cause a reset, then
>release for one of several specified times that each have diffefent
>meanings.  The ON periods need only be long enough so that the work
>associated with them can be carried out.
>
>Other scenarios are also possible where the OFF period is timed, or both.

It should be possible to transfer several bits at at time: 2 bits seems
trivial and even 4 bits requires only 16 discrete time intervals.  That
would sure go a long way to reducing the overhead imposed by the power up
timer (1024 clock cycles after an external reset).

Rob Rolf mentioned needing a read-back mechanism for programming
verification - I would think that the bootloader itself should take care of
that.

Since there is no read-back possible when using only the MCLR pin, the
loader at the PC would have to know what the clock speed of the target was
so that it (the PC end) could take into account the start-up delay.  But
that is just a detail.

Great concept, Wouter!

dwayne


Dwayne Reid   <RemoveMEdwaynerspamTakeThisOuTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

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


2002\03\11@130727 by M. Adam Davis

flavicon
face
But doesn't the POR activate on reset?  If so, the POR (IIRC) is
essentially an RC cirecuit inside the PIC, and is rated for a certian
range of time, but not calibrated...  You could disable the POR when you
load the bootloader, but then you're getting rid of a useful function
just so you can program through the MCLR.  You could also, I suppose,
calibrate it when you load the bootloader and take it into account, use
the watchdog and a crystal to find temperature and compensate for
temperature changes.

-Adam

Olin Lathrop wrote:

{Quote hidden}

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


2002\03\11@150737 by Olin Lathrop

face picon face
> It should be possible to transfer several bits at at time: 2 bits seems
> trivial and even 4 bits requires only 16 discrete time intervals.  That
> would sure go a long way to reducing the overhead imposed by the power up
> timer (1024 clock cycles after an external reset).

The power up timer only runs on power up.  The chip should start running
almost immediately after MCLR is released.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinTakeThisOuTspamspamembedinc.com, http://www.embedinc.com

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


2002\03\11@160346 by Olin Lathrop

face picon face
> But doesn't the POR activate on reset?

For the third time now in this thread, no.

For anyone that is itching to blurt out some "wisdom" about MCLR, please
save us all a lot of trouble and actually *read* about MCLR first.  In the
16F87x data book (DS30292C) it is section 12.3, "Reset", on pages 123-125.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinKILLspamspamembedinc.com, http://www.embedinc.com

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


2002\03\11@164343 by uter van ooijen & floortje hanneman

picon face
> But doesn't the POR activate on reset?

No. See midrange refernce manual. POR activates on power on. That's why it
is called POr ;)

Wouter van Ooijen
--
Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler, Wisp programmer, WLoader bootloader, PICs kopen

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


2002\03\11@164348 by uter van ooijen & floortje hanneman

picon face
> The power up timer only runs on power up.  The chip should start running
> almost immediately after MCLR is released.

My idea too, but I can not find any data on how immediate.

Wouter van Ooijen
--
Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler, Wisp programmer, WLoader bootloader, PICs kopen

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


2002\03\11@183008 by Dwayne Reid

flavicon
face
At 06:48 PM 3/11/02 +0100, wouter van ooijen & floortje hanneman wrote:

> > The power up timer only runs on power up.  The chip should start running
> > almost immediately after MCLR is released.
>
>My idea too, but I can not find any data on how immediate.

According to section 12.8 (pg 124) of ds30292c, "If MCLR is kept low long
enough, the timeouts will expire.  Bringing MCLR high will begin execution
immediately".

My earlier confusion centered around the oscillator startup timer (which I
erroneously shortened to "start-up delay").  But the text in the data sheet
clearly states this is not an issue.

dwayne


Dwayne Reid   <EraseMEdwaynerspamEraseMEplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

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


2002\03\11@184008 by Bob Ammerman

picon face
Section 12.8 of the PIC16F87x datasheet says:

The Power-up Timer provides a fixed 72 ms nominal
time-out on power-up only from the POR. The Power-up

Timer operates on an internal RC oscillator. The

chip is kept in RESET as long as the PWRT is active.

The PWRT's time delay allows VDD to rise to an accept-able

level. A configuration bit is provided to enable/dis-able

the PWRT.

The power-up time delay will vary from chip to chip due

to VDD, temperature and process variation. See DC

On power-up, the time-out sequence is as follows: The

PWRT delay starts (if enabled) when a POR Reset

occurs. Then OST starts counting 1024 oscillator

cycles when PWRT ends (LP, XT, HS). When the OST

ends, the device comes out of RESET.

If MCLR is kept low long enough, the time-outs will

expire. Bringing MCLR high will begin execution imme-diately.

This is useful for testing purposes or to synchro-nize

more than one PIC16F87X device operating in

parallel



Bob Ammerman
RAm Systems.



{Original Message removed}

2002\03\11@210644 by Olin Lathrop

face picon face
> My idea too, but I can not find any data on how immediate.

They only say "immediately".  I don't know if the internal Q clock is runing
during MCLR, so it might have to wait for the next Q0 phase, maybe two to
get the pipline going.  For the 16F87x (DS3029C) the pertinent paragraph is
in section 12.8 on page 124: "If MCLR is kept low long enough, the time-outs
will expire.  Bringing MCLR high will begin execution immediately.  This is
useful for testing purposes or to synchronize more than one PIC 16F87x
device operating in parallel."


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spamBeGoneolinspamKILLspamembedinc.com, http://www.embedinc.com

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


2002\03\11@212531 by Bob Ammerman

picon face
> > My idea too, but I can not find any data on how immediate.
>
> They only say "immediately".  I don't know if the internal Q clock is
runing
> during MCLR, so it might have to wait for the next Q0 phase, maybe two to
> get the pipline going.  For the 16F87x (DS3029C) the pertinent paragraph
is
> in section 12.8 on page 124: "If MCLR is kept low long enough, the
time-outs
> will expire.  Bringing MCLR high will begin execution immediately.  This
is
> useful for testing purposes or to synchronize more than one PIC 16F87x
> device operating in parallel."

Hm....

If this is expected to _truly_ synchronize two PICs one might expect that
they will run clock-for-clock identically if MCLR is brought up with an
appropriate setup time relative to OSCin (assuming an external osc).

This would imply that the internal clock phasing would be set relative to
the rising edge of MCLR.

This would also imply very small jitter even if MCLR is not synchronized to
OSCin (or for an internal osc) -- not more than 1 cycle of the clock!

Bob Ammerman
RAm Systems

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


2002\03\11@230522 by M. Adam Davis

flavicon
face
And if the two PICs are clocked from the same signal, then you wouldn't
even have that.

Since the PIC is fully static, it would be very easy to test it out by
slow clocking (4Hz) or even hand clocking two identically programmed
pics.  Something I've wanted to do since the first time we talked about
it oh so long ago...

-Adam

Bob Ammerman wrote:

{Quote hidden}

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


2002\03\12@072054 by Bob Ammerman

picon face
> And if the two PICs are clocked from the same signal, then you wouldn't
> even have that.

If MCLR is not synchronized to CLKin then it may meet setup on one PIC but
not on the other. This would result in the two PICs being off by one cycle.

Bob Ammerman
RAm Systems


{Quote hidden}

to
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestspamspammitvma.mit.edu


2002\03\12@095306 by Olin Lathrop

face picon face
> If this is expected to _truly_ synchronize two PICs one might expect that
> they will run clock-for-clock identically if MCLR is brought up with an
> appropriate setup time relative to OSCin (assuming an external osc).
>
> This would imply that the internal clock phasing would be set relative to
> the rising edge of MCLR.
>
> This would also imply very small jitter even if MCLR is not synchronized
to
> OSCin (or for an internal osc) -- not more than 1 cycle of the clock!

I agree with your reasoning, but I'm not willing to read that much into
their statement without verifying it.  I can see how they might consider two
PICs "synchronized" if they are within a instruction or two of each other.

I think the answer depends on whether the Q clock is still running during
reset.  If not, then it would probably start at Q0 on the next oscillator
edge after MCLR high like you said.

I just looked over the timer sections in a data sheet, and it appears they
don't run from the instruction clock during MCLR.  The data sheet is vague
about what happens to timer 0 and 1 during MCLR, but timer 2 definitely does
not run.  This supports the idea that the Q clock is not running, which
makes your interpretation more likely.  I'd still want to test it or get a
definitive statement from Microchip before relying on this though.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinEraseMEspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


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