Searching \ for '[PIC]: PBK' 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: 'PBK'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: PBK'
2002\08\09@165210 by Olin Lathrop

face picon face
I've been watching all the babble about the "PIClist Beginners Kit"
(PBK) going back and forth.  Mostly I've kept my mouth shut because I
don't intend to contribute towards its design.  (I think the
collective resources spent will exceed the cost of a Picstart+ for
everyone who will buy a PBK).  I also doubt it will ever be produced
because everyone wants it to be according to their own vision.  The
discussion already seems to be going in circles with everyone
talking, nobody listening, and nothing being decided.  (Yes, Byron,
we know you think it should be boot loader based.  I figured that out
after the first 10 times you said it.  Point noted.  Do we really
need to hear it an 11th time?)

Anyway, all this talk of programmers made me wonder what it actually
takes to program a PIC.  So far I've always used a Picstart+ for
development and a bootloader once when the customer wanted field
upgradeable firmware.  I've got some projects coming up that will
probably require one PIC to program one or more others, so I had
added reason to look into it.

To start with, I made a list of the reasonable "hobby" PICs.  These
are PICs that are suited for small volume personal use accross
multiple projects.  For that kind of application, it makes sense to
get the full feature versions.  There is no point in saving $.50 on a
stripped down PIC when you only buy 5 of them, and you might want to
use it in a different project next month.  Hobby PICs are therefore
mostly the biggest bestest you can get in the various DIP package
sizes.  The hobby PICs are:

 16F628  -  Most capable flash part with 18 pins.

 16F876  -  Best 16F part with 28 pins.

 16F877  -  Best 16F part with 40 pins.

 18F252  -  Best 28 pin PIC actually available.

 18F452  -  Best 40 pin PIC actually available.

I included the 16F876 and 877 only because a great deal of existing
code and support is available for them.  I expect they would be
dropped from the list as the 18F parts become more common.

So, how are these parts programmed?  It turns out that these 5 parts
require 3 different algorithms and have 2 different pinouts.  If you
can program these 5 parts, you can actually program any 16F62x,
16F87x, 18Fxx2, 18Fxx8, and possibly others but I haven't looked.

It would be nice if any of the supported parts could be plugged into
the same 40 pin ZIF socket and programmed without the user needing to
switch jumpers or the like.  To see if this is possible, I made a
list of all the pins used accross all the parts.  Fortunately none of
the pins collide in an incompatible way.  Since unused pins are set
to high impedence and ignored during programming, the various pins
used for the same thing accross parts can just be wired together.

The only gotcha is that MCLR is on pin 1 except for the 16F628 where
it is on pin 4.  Pin 4 isn't used by the other parts during
programming, but MCLR must be raised to 13V, which would damage any
pin except MCLR.  The programmer needs to detect this case and drive
the appropriate pin to 13V.

With all this in mind, I wanted to see what kind of hardware it would
take to implement a basic programmer.  The schematic I came up with
is at http://www.embedinc.com/pic/prog.pdf.  I'd be interested to
hear if I missed any gotchas from those who have been down this road
before.

THEORY OF OPERATION

The programmer is controlled by a 16F628 (IC3) which talks to the
host over a serial line via a standard RS-232 converter chip (IC4).
Serial line is the only viable choice for a simple programmer, mostly
because it's the easiest to control from app level software.  The
vast majority of machines have serial ports, and those that don't can
easily and cheaply add a USB serial port.

I envision the controller taking care of the specific programming
details, and the host sending mostly address/data information.  This
information gets used on the fly and is not stored.  The bandwidth of
the serial port greatly exceeds the flash programming bandwidth, so
this does not reduce performance.

Q5 and Q4 (top right corner) form a circuit to test whether anything
is plugged into pin 10.  This is to distinguish between 18 pin
devices and larger devices.  The only supported 18 pin devices are
the 16F62x which require the programming voltage on pin 4.  All the
other chips are larger and require the programming voltage on pin 1.
If a PIC is plugged in at pin 10, then the protection diode of that
pin will drop the pin voltage to a bit over 5V.  This causes Q5 and
then Q4 to turn on.  Q4 drives RB0 low, which has the internal
pullups enabled.  The net effect is that RB0 is high for chips with
more than 18 pins and low for chips with 18 or fewer pins.

IC1A and IC1B each form a separately controllable 13V source.  The
firmware enables at most one of these at a time, depending on what
kind of chip is plugged in.  Q3 and R6 limit the current to around
100mA as specified by Microchip.

The power line (VDD) to the chip being programmed can be continuously
controlled from 0 to 5V.  This is done using the PWM output RB3.
This is low pass filtered by R13, C1, R14, and C2, then unity
amplified to low impedence by IC2A and Q6.  The purpose of this is to
allow the firmware the option of verifying the programmed data at
different supply voltage levels.  Microchip strongly recommends that
the data be verified accross the operating voltage range, although
they only do this in the Promate programmer and not in the
Picstart+.  The firmware could ignore this and simply set RB3 high to
power up the chip.  The extra few parts to allow varying the supply
voltage are so cheap that it doesn't seem worth leaving them off.

The chip is programmed using the PGC (clock) and PGD (data) lines.
These are connected between the controller and the chip being
programmed by 10K resistors.  This is to limit the current thru the
protection diodes when the chip being programmed is being operated at
a different supply voltage from the controller.  This will slow the
rise and fall times a bit, but overall performance won't be effected
much because it is dominated by the flash programming time.


Sean, if you're still reading this far down, I'm curious what kind of
production cost you think a board like this would take.  Most of the
parts are generic and can be substituted for locally available
similar parts.


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

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


2002\08\09@174552 by Dave Tweed

face
flavicon
face
Olin Lathrop <.....olin_piclistKILLspamspam@spam@EMBEDINC.COM> wrote:
> With all this in mind, I wanted to see what kind of hardware it would
> take to implement a basic programmer.  The schematic I came up with
> is at http://www.embedinc.com/pic/prog.pdf.  I'd be interested to
> hear if I missed any gotchas from those who have been down this road
> before.

Would it be worthwhile to provide a voltage divider in the feedback loop
around IC2A, to allow Vdd to be driven 5% or 10% *above* the nominal value
during program verification? High-end device programmers do this, but maybe
it isn't necessary here.

-- Dave Tweed

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


2002\08\09@184307 by Olin Lathrop

face picon face
> Would it be worthwhile to provide a voltage divider in the feedback loop
> around IC2A, to allow Vdd to be driven 5% or 10% *above* the nominal value
> during program verification? High-end device programmers do this, but
maybe
> it isn't necessary here.

Good point.  It should be able to go to the highest allowable supply voltage
for any of the supported PICs.  I think that is 5.5V.


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

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


2002\08\09@191446 by Tom Messenger

flavicon
face
Hi Olin

I have two comments about your schematic.

My PICSTART PLUS has two things you so far have omitted: LEDs: one for
POWER, one for ACTIVE. Most of the time, these are not needed. But then at
some point, when things are going wrong, they immediately tell you "turn on
the power, dummy" or "the powers on, look elsewhere for your problem". Plus
the ACTIVE led tells you when it's completely safe to plug/unplug a target
device.  Come to think of it, an led that sits on the dataline from the PC
also tells you that your PC is working insofar as getting data to the
programmer.  This sort of thing helps the debug process when things aren't
going right.

The other comment is just wondering whether pulldowns are needed on the
'628 output to keep the 13 volt drivers off during power up.  Devices
'shouldn't' be inserted before power of course, but sometimes the power
gets cycled (ac line brownouts, etc.) so maybe this is a useful idea. Maybe
not.

Tom M.

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


2002\08\09@194700 by Olin Lathrop

face picon face
> My PICSTART PLUS has two things you so far have omitted: LEDs: one for
> POWER, one for ACTIVE. Most of the time, these are not needed. But then at
> some point, when things are going wrong, they immediately tell you "turn
on
> the power, dummy" or "the powers on, look elsewhere for your problem".

I suppose a power light could be useful.

> Plus
> the ACTIVE led tells you when it's completely safe to plug/unplug a target
> device.

I use a Picstart+ also, but don't find much use for the active light.  You
can get the same information by looking at the screen.  Still, it's just one
resistor and one LED to add.

> Come to think of it, an led that sits on the dataline from the PC
> also tells you that your PC is working insofar as getting data to the
> programmer.  This sort of thing helps the debug process when things aren't
> going right.

I can feel the creeping featuritis settling in.  The host software can tell
you just as well if it is communicating properly.

> The other comment is just wondering whether pulldowns are needed on the
> '628 output to keep the 13 volt drivers off during power up.  Devices
> 'shouldn't' be inserted before power of course, but sometimes the power
> gets cycled (ac line brownouts, etc.) so maybe this is a useful idea.
Maybe
> not.

I think it is.  Good point.


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

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


2002\08\10@120513 by Byron A Jeff

face picon face
On Fri, Aug 09, 2002 at 04:51:05PM -0400, Olin Lathrop wrote:
> I've been watching all the babble about the "PIClist Beginners Kit"
> (PBK) going back and forth.  Mostly I've kept my mouth shut because I
> don't intend to contribute towards its design.  (I think the
> collective resources spent will exceed the cost of a Picstart+ for
> everyone who will buy a PBK).  I also doubt it will ever be produced
> because everyone wants it to be according to their own vision.  The
> discussion already seems to be going in circles with everyone
> talking, nobody listening, and nothing being decided.  (Yes, Byron,
> we know you think it should be boot loader based.  I figured that out
> after the first 10 times you said it.  Point noted.  Do we really
> need to hear it an 11th time?)

Unfortunately yes. I'd really like to shut up about it but except for James
I feel like I'm talking to my self. Here's how the conversation goes:

me: The Designer is a bootloaded target. There's no need for a programmer.

Response: I see. But when we do the programmer we'll need ICSP.

me: But there's no need for a programmer as the primary function. The Designer
   is the target and it can program itself throught the bootloader.

Response: OK. But I wonder if we should use a single 40 pin ZIF for the
         programmer or if individual ZIFs for each size is appropriate.

me (exasperated): That hardware isn't necessary as all of the development
                 occurs onboard. All that's required is a simple ICSP
                 port for the final transfer to the target.

Response: But then the bootloader will take some program memory away. So we
         need a 2 chip system: one is the programmer chip, and the other is
         the target chip. I wonder how to wire a single 40 pin ZIF socket
         so that 8, 18, 28, and 40 pin DIP parts can be programmed by the
         programmer.

me (for the 10th time): No programmer is required with a bootloaded target.
You can pick the interface instead of being bound to Microchip's. You get
a debugging back channel. You can reduce the number of I/O pins required to
generate the interface. You get field programmability. You get plug an play
operation without having to build a separate target board. Yadda. Yadda. Yadda.

And the response is...

>
> Anyway, all this talk of programmers made me wonder what it actually
> takes to program a PIC.  So far I've always used a Picstart+ for
> development and a bootloader once when the customer wanted field
> upgradeable firmware.  I've got some projects coming up that will
> probably require one PIC to program one or more others, so I had
> added reason to look into it.

So I ask for the 11th time: Presuming that you have a self programmable part
in the 16F87X or 18FXXX family, why do you need a programmer at all for
development?

{Quote hidden}

We're in perfect agreement here.

>
> So, how are these parts programmed?  It turns out that these 5 parts
> require 3 different algorithms and have 2 different pinouts.  If you
> can program these 5 parts, you can actually program any 16F62x,
> 16F87x, 18Fxx2, 18Fxx8, and possibly others but I haven't looked.

And tht brings up another point I get to wap everyone over the head with:
with a bootloader, there's only one algorithm, and one pinout, and one
interface for the final 4 chips. 16F628's are not self programmable. A major
design flaw IMHO as making it self programmable would have made it a perfect
18 pin part.

Anyway it just seems to me to be a case of "We do programmers because that's
how we've always done it." But frankly I'm annoyed about everything about
the programming process. Other than ICD it offers absolutely no benefit to
the development process. Oh and the fact you need a programmer once in order
to put a bootloader into the chip! ;-)

I guess I'll shut up about it now.

BAJ

[ Olin's excellent programmer design analysis deleted for brevity. ]

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


2002\08\10@133513 by Olin Lathrop

face picon face
> Unfortunately yes. I'd really like to shut up about it but except for
James
> I feel like I'm talking to my self. Here's how the conversation goes:
>
> ...
>
> me (for the 10th time): No programmer is required with a bootloaded
target.
> You can pick the interface instead of being bound to Microchip's. You get
> a debugging back channel. You can reduce the number of I/O pins required
to
> generate the interface. You get field programmability. You get plug an
play
> operation without having to build a separate target board. Yadda. Yadda.
> Yadda.

Yes, Byron, I understand your points.  You have stated them repeatedly.  I
understand them but I don't agree with your asessment of the relative
merits.  Perhaps people are reacting that way because they don't agree
either.  Your stating the same points over and over again won't convince
anyone, it just annoys them.  They probably figure (correctly in my
estimation) that debating with you will just go round and round with you
repeating the same statements with nothing accomplished.  They therefore
just ignore you and move on.

You are certainly entitled to your opinion, and I can see you have thought
it thru intelligently.  In the end it comes down to a series of judgement
calls on the relative merits.  We all know where you stand.  I respect your
opinion but I don't agree with it.  I won't debate my opinion because I
don't want to hear you say the same thing *again*.  You can't have a debate
with a broken record.  I'm not going to convince you, nor is there any
reason I should try, so it's better to keep my mouth shut and not refute
your points.

> And tht brings up another point I get to wap everyone over the head with:
> with a bootloader, ...

Groan.

> Anyway it just seems to me to be a case of "We do programmers because
that's
> how we've always done it." But frankly I'm annoyed about everything about
> the programming process. Other than ICD it offers absolutely no benefit to
> the development process. Oh and the fact you need a programmer once in
order
> to put a bootloader into the chip! ;-)

OK, you've baited me into it.  I know you won't agree with this.  Hopefully
you can accept that others have a different opinion and recognize that
agreement won't be reached.

I think every beginner should have a programmer because:

1  -  Even if you use a bootloader, it is the only way to recover if the
bootloader code gets scrambled.

2  -  High voltage programming is the *only* way to reprogram a device if
code protection gets set and low voltage programming disabled in the config
word.

3  -  Even if you use a bootloader, it is the only way to get the bootloader
into a new chip.  This way you can receive chips from anywhere in any state
and use them in your setup.

4  -  You can program chips for circuits that don't contain any
communications hardware suitable for the bootloader (serial port,
typically).

5  -  You get to use ALL the pins.

6  -  You get to use ALL the program memory.

Points 5 and 6 are relatively minor, but I think points 1-4 are
overwhelmingly conclusive.


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

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


2002\08\10@140232 by Byron A Jeff

face picon face
On Sat, Aug 10, 2002 at 01:34:33PM -0400, Olin Lathrop wrote:

[ Olin and I agree to disagree. Deleted for brevity. ]

> OK, you've baited me into it.  I know you won't agree with this.  Hopefully
> you can accept that others have a different opinion and recognize that
> agreement won't be reached.

Yes I agree to disagree. I just have one small comment on your list below.

{Quote hidden}

you missed points 7 and 8:

7 - It's the only mechanism available for chips that are not self programmable.

8 - It is the only mechanism under which ICD can be used.

I agree with you on each and every point. The only one observation I'd like
to throw out is that each and every one of the items you listed is an
exceptional situation. Scrambled memory, code protection, blank chips, no
usable interfaces, and resource exhaution are all extreme circumstances and as
such are out of the scope of the discussion of everyday development.

I never said one didn't need a programmer at all. As I'm sure you well know
I have a site that supports a simple programmer and simple programming
software (primarily for reason #3 and #7 above). But for self programmable
PICs it's sole existance is to solve #3.

You're right. I've said enough and everyone knows where I stand. So I plan
to now stand quitely on this issue and wait to see if anyone else comes up
with cogent arguments one way or the other.

BAJ

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


2002\08\11@152245 by Wouter van Ooijen

face picon face
> Points 5 and 6 are relatively minor, but I think points 1-4 are
> overwhelmingly conclusive.

They are, but only if you want to do 'serious' programming work
(translate: use more than a few PIC chips). If not: why not buy them
with a bootloader, or have someone put one in for you? And a bootloader
will not set protection bits because it can't (at least on 16f chips).

Wouter van Ooijen
----------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
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\08\11@171825 by Olin Lathrop

face picon face
> They are, but only if you want to do 'serious' programming work
> (translate: use more than a few PIC chips). If not: why not buy them
> with a bootloader, or have someone put one in for you? And a bootloader
> will not set protection bits because it can't (at least on 16f chips).

1  -  Because it's a pain.  Even though the added cost may be minimal, I
think lots of people would be uncomfortable with this.  It just feels wrong,
like you are too dependent on someone.  The beginner that posted here
earlier (Jumanji ?) seemed to agree with this.

2  -  Since a boot loader can't change some (all ?) of the config bits, do
you have to buy with/without watchdog enabled and choice of oscillator
modes?

3  -  What happens when someone's code bugs out and scribbles on the
bootloader?  I know it *shouldn't*, but stuff happens.  And it's guaranteed
to happen right at the start of a long weekend when you were planning on
doing some serious PIC development.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, 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


2002\08\11@192125 by Tony Nixon

flavicon
picon face
Olin Lathrop wrote:
>
> I've been watching all the babble about the "PIClist Beginners Kit"
> (PBK) going back and forth.

Hi Olin,

Nice job.

As you see, it's not too hard to create the hardware for a PIC
programmer. It's the software that follows that adds the big time -
initially, and the follow ups with new chips coming out and the fact
that the programming algorithms are changing. This is evident in your
chip list if the 877-A's take over from the 877's.


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
@spam@salesKILLspamspambubblesoftonline.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


2002\08\12@033742 by Wouter van Ooijen

face picon face
> > They are, but only if you want to do 'serious' programming work
> > (translate: use more than a few PIC chips). If not: why not buy them
> > with a bootloader, or have someone put one in for you? And
> a bootloader
> > will not set protection bits because it can't (at least on
> 16f chips).
>
> 1  -  Because it's a pain.  Even though the added cost may be
> minimal, I think lots of people would be uncomfortable with this.  It
> just feels wrong, like you are too dependent on someone.

You will always depend on where you buy your chips. Just suppose that
each f877 sold contained a bootloader - just like it has LVP enabled
now!

> 2  -  Since a boot loader can't change some (all ?) of the
> config bits, do you have to buy with/without watchdog enabled and
choice of oscillator
> modes?

I don't suggest a bootlader is heaven for all, just that it is very
practical for a beginner who might not want to choose an oscillator
setting (what IS an oscillator setting? - just use 20 Mhz xtal with 2 *
20 pf, the chip is already set for this) and does not even know what a
watchdog is for (that's like a Tamagotchi, right? You stay up all night
and feed it every hour - :( ).

> 3  -  What happens when someone's code bugs out and scribbles on the
> bootloader?  I know it *shouldn't*, but stuff happens. And
> it's guaranteed to happen right at the start of a long
> weekend when you were planning on
> doing some serious PIC development.

Then you are screwed, just like when you applied the 5V/12A from a PC
power supply to your PIC, backwards. But note that one a beginner
reaches the level that he/she will (deliberately or accidentally)
overwrite code in her program she might be better off with a next step
up the ladder (I would suggest an ICSP HVP programmer, like my Wips628
[OK Byron, I'll mention my designs/products more often!]).

Wouter van Ooijen
----------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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


2002\08\12@062926 by Byron A Jeff

face picon face
On Mon, Aug 12, 2002 at 09:36:38AM +0200, Wouter van Ooijen wrote:
>(I would suggest an ICSP HVP programmer, like my Wips628
                                                 ^^^^^^^
> [OK Byron, I'll mention my designs/products more often!]).

Better. But now we just have to work on our spelling! ;-)

BAJ

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


2002\08\12@155418 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Unfortunately yes. I'd really like to shut up about it but except
> for James I feel like I'm talking to my self. Here's how the
> conversation goes:

As far as I could see the conversation going, it was

Byron: "We should make it a bootloader, here's why"
Someone else: "Nah, there are some good reasons to do it another way"
Byron: "But those are more advanced tools, all we need is a boot
loader"
Someone else: "It really wouldn't be that tough"
Byron: "But I don't see it that way.  I don't think we need that"

Etc...

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPVgScAVk8xtQuK+BEQJ8VgCg4cPhEeowINDapX7rWnD/f8yBBKAAoLSZ
rzPA7BqfCdIeCB3ESddzz+sc
=KkvZ
-----END PGP SIGNATURE-----

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


2002\08\12@162045 by Byron A Jeff

face picon face
>
> > Unfortunately yes. I'd really like to shut up about it but except
> > for James I feel like I'm talking to my self. Here's how the
> > conversation goes:
>
> As far as I could see the conversation going, it was
>
> Byron: "We should make it a bootloader, here's why"
> Someone else: "Nah, there are some good reasons to do it another way"
> Byron: "But those are more advanced tools, all we need is a boot
> loader"
> Someone else: "It really wouldn't be that tough"
> Byron: "But I don't see it that way.  I don't think we need that"

Isn't perspective wonderful? I promised Olin that I'd keep quite on the
issue. And I shall.

BAJ

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


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