ICSP standard ?

Started by Dave Mucha June 22, 2005
Hi all,

I've been trying to figure the best way to connect pins for ISCP for a
couple chips. 16F877 (40 pin) 16F873 (28 pin) and the 16F628(18 pin)

one thing that seems to be really consistant is the lack of
consistance of which pins on a ICSP header are which.

Can anyone offer some guidance ?

I'm pretty tempted to use the Olimex pin-out in the event I need to
buyu their proto boards.

Dave



> I've been trying to figure the best way to connect pins for ISCP for a
> couple chips. 16F877 (40 pin) 16F873 (28 pin) and the 16F628(18 pin)
>
> one thing that seems to be really consistant is the lack of
> consistance of which pins on a ICSP header are which.
>
> Can anyone offer some guidance ?

This discussion has been on the other (real? MIT?) piclist. The
consclusion was that the number of standards depends on the number of
pins in your header, being all possible assignments.

Another 'standard' is the ICD2 connector, but it is not very roubust,
must be at the edge, and uses more PCB area than an pinheader.

> I'm pretty tempted to use the Olimex pin-out in the event I need to
> buyu their proto boards.

Nothing wrong with picking the one you'd most likley use from the
multitude of 'standards'.

Wouter van Ooijen

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



I think you may be disappointed with the Olimex pinout. It
overlooks the PGM pin (where required) and the requirement that it
be grounded for high voltage programming. That's the problem with
the PICs; there are a bunch of different requirements, all a
function of the device.

One thing you might consider is a 2 row cable header. It connects in
series with MCLR/Vpp, RBx, RBy, PGM and Vcc. Gnd is present but not
interrupted. During normal operation there is a jumper plug across
the header for the various signals and Vcc. During programming the
PIC signals and VCC are completely isolated from the surrounding
circuitry by removing the shorting plug. A 12 lead cable is then
used to connect to the programmer with only 6 leads active.

The thing is, you can't just ground the PGM pin. What if it is the
output of some other bit of logic? Isolation is required, in my
view, for all of the signals and Vcc.

There are various recommendations at the Microchip site. You may
want to search over there before locking in to a particular design.
The requirements vary from device to device and, I believe, the 12
pin header design accomodates most. --- In piclist@picl..., "Wouter van Ooijen" <wouter@v...>
wrote:
> > I've been trying to figure the best way to connect pins for ISCP
for a
> > couple chips. 16F877 (40 pin) 16F873 (28 pin) and the 16F628(18
pin)
> >
> > one thing that seems to be really consistant is the lack of
> > consistance of which pins on a ICSP header are which.
> >
> > Can anyone offer some guidance ?
>
> This discussion has been on the other (real? MIT?) piclist. The
> consclusion was that the number of standards depends on the number
of
> pins in your header, being all possible assignments.
>
> Another 'standard' is the ICD2 connector, but it is not very
roubust,
> must be at the edge, and uses more PCB area than an pinheader.
>
> > I'm pretty tempted to use the Olimex pin-out in the event I need
to
> > buyu their proto boards.
>
> Nothing wrong with picking the one you'd most likley use from the
> multitude of 'standards'.
>
> Wouter van Ooijen
>
> -- -------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: www.voti.nl/hvu


> The thing is, you can't just ground the PGM pin. What if it is the
> output of some other bit of logic? Isolation is required, in my
> view, for all of the signals and Vcc.

The same would hold for PGC and PGD, and even for MCLR. When you want to
do ICSP you will have to design the circuit with ICSP in mind, including
the driving capacity of the programmer you want to use.

For PGM I can think of 3 strategies
- the programmer must pull it low
- the target circuit must keep it low (during programming)
- only PICs that do not require this feature are used

Also note that for some chips you will officially need Vcc cycling to
enter programming mode (in practice only when you configure MCLR as
input). For some other chips power cycling will *prevent* entering
programming mode :(

Wouter van Ooijen

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


Wouter,

It is a real pit! Cycling Vcc is indeed required for some
configurations hence the recommendation to interrupt that at the
header as well. It would be nice to know what is sufficient for ALL
the devices and just design to that. Make them all the same.

I had originally thought of a short list of devices such as the
16F628 and 16F877(A) but, as I copy what I find on the Internet,
that doesn't always work out. Some authors pick other chips and
sometimes it is more effort to change the code than to give up and
use the recommended device. Often, source code isn't available.

By the way, thanks for the tip on Knoppix. It has come in quite
handy as a Swiss Army Knife!

Richard

--- In piclist@picl..., "Wouter van Ooijen" <wouter@v...>
wrote:
> > The thing is, you can't just ground the PGM pin. What if it is
the
> > output of some other bit of logic? Isolation is required, in my
> > view, for all of the signals and Vcc.
>
> The same would hold for PGC and PGD, and even for MCLR. When you
want to
> do ICSP you will have to design the circuit with ICSP in mind,
including
> the driving capacity of the programmer you want to use.
>
> For PGM I can think of 3 strategies
> - the programmer must pull it low
> - the target circuit must keep it low (during programming)
> - only PICs that do not require this feature are used
>
> Also note that for some chips you will officially need Vcc cycling
to
> enter programming mode (in practice only when you configure MCLR as
> input). For some other chips power cycling will *prevent* entering
> programming mode :(
>
> Wouter van Ooijen
>
> -- -------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: www.voti.nl/hvu


> It is a real pit! Cycling Vcc is indeed required for some
> configurations hence the recommendation to interrupt that at the
> header as well.

I hate 'disruptive' headers, so Wisp628 gets away with temprarily
*shorting* the targets power :) This of course must be taken into accont
when designing the target circuit, but a lowly 7805 or 78L05 will do
fine. In fact some more sophisticated (foldback) supplies will not :(

Wouter van Ooijen

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


At 01:16 PM 6/22/2005, Wouter van Ooijen wrote:

>I hate 'disruptive' headers, so Wisp628 gets away with temprarily
>*shorting* the targets power :) This of course must be taken into accont
>when designing the target circuit

I'll have to keep Wisp628 in mind!

This would work extremely well on all of my higher volume products - the
PIC power supply is a simple zener regulator. In fact, I'm trying real
hard to think of any of my PIC stuff where it wouldn't work - and I can't
right now. Pretty much everything I build uses a tiny +5V supply with all
of the high-current stuff (even LEDs) being powered from the unregulated DC
input.

I haven't designed anything using a 78(L)05 for years now. If I need an
accurate Vdd for a/d stuff, I use a LP2950. If not, I use a zener
supply. A transient short on either of those is no problem at all.

It probably shows that just about everything I do is powered from either AC
mains or large vehicle battery (12 or 24V).

dwayne

--
Dwayne Reid <dwayner@dway...>
Trinity Electronics Systems Ltd Edmonton, AB, CANADA
(780) 489-3199 voice (780) 487-6397 fax

Celebrating 21 years of Engineering Innovation (1984 - 2005)
.-. .-. .-. .-. .-. .-. .-. .-. .-. .-
`-' `-' `-' `-' `-' `-' `-' `-' `-'
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.