Searching \ for '[EE][PIC] Why programmers use PICs as controllers?' 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=programmer
Search entire site for: '[PIC] Why programmers use PICs as controllers?'.

Exact match. Not showing close matches.
PICList Thread
'[EE][PIC] Why programmers use PICs as controllers?'
2005\11\03@064736 by Juan Cubillo

flavicon
face
Hello group,

Why is it that some programmers (wisp628, kit 149, GTP-USB, etc)use PICs in them to controll programming?
If the old programmers like icprog or elcheapo are able to control the clock, data, and mclr lines, why can´t you just add support for newer PICs to their software. As far as I know all(?) PICs use the same method to load data into them.

Is there any good reason to use controllers inside programmers VS computer controlled lines?

Juan Cubillo

2005\11\03@081804 by Maarten Hofman

face picon face
> Why is it that some programmers (wisp628, kit 149, GTP-USB, etc)use PICs in them to controll programming?
> If the old programmers like icprog or elcheapo are able to control the clock, data, and mclr lines, why can´t you just add support for newer PICs to their software. As far as I know all(?) PICs use the same method to load data into them.
>
> Is there any good reason to use controllers inside programmers VS computer controlled lines?

I don't think there is a reason to have a PICmicro rather than any
other microcontroller (except that you're working with PICmicros
anyway, so why not stick with what you know) but I can see a
microcontroller having distinct advantages in the form of ensuring
timing and allowing longer cable lengths.

I can also tell you from experience, that even with a completely
compatible parallel port and serial port, the JDM and El Cheapo
programmers are NOT able to program all Microchip devices. I tried
five different software suites, but the El Cheapo will not program the
16F628A, 16F877A, 16F688. The JDM programmer is capable of programming
them, but timing wise it is already on the edge, meaning that any
disturbance will have bad results (especially if you're doing the full
8KWord of the 16F877A).

As said earlier, I didn't know all this until I got a PicKit 2 (of
which the USB interface installed like a breeze, by the way, on all my
computers) and discovered the pleasure of a programmer with a PICmicro
inside it.

This doesn't mean that the JDM is a bad programmer. If your serial
port is "proper" (-12V to -15V and 12V to 15V signal levels), and you
keep your cable short enough, it will work fine.

Greetings,
Maarten Hofman.

2005\11\03@083713 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Maarten Hofman" <spam_OUTcashimorTakeThisOuTspamgmail.com>
Subject: Re: [EE][PIC] Why programmers use PICs as controllers?


> I can also tell you from experience, that even with a completely
> compatible parallel port and serial port, the JDM and El Cheapo
> programmers are NOT able to program all Microchip devices. I tried

There really are few limitations on what PICs you can program based on the
programming hardware.  This is generally controlled more by the software.
Generic hardware typically has an army of people working on the software,
and will generally allow you to program more different models that
proprietary hardware.

But if you want to keep up with the latest and greatest, then Microchip iron
is obviously the best bet.  However, it is important to keep in mind that
Microchip doesn't guarentee that some particular programmer will program
every PIC ever available in the future.  Mchip will make business decisions
to support, or drop support, of any particular device based on business
considerations.  So in my view, buying a PICkit or ICD2 or whatever, is
something of a crap shoot, and maybe more risky than buying/building some
generic programmer.  But the starting out point is often better, and if the
device you select is relatively new, then the odds are you will have support
for at least a few years.

But I do think one needs to look at the device and what it will do
(including what operating system versions are supported), and consider
whether the price is worth it for "renting" a programmer for a year or two
or three or whatever your estimate is.

--McD


2005\11\03@085817 by Maarten Hofman

face picon face
> There really are few limitations on what PICs you can program based on the
> programming hardware.  This is generally controlled more by the software.

It could be... But the fact remains that despite the software
supporting the devices, the hardware did not. And believe me, I tried
many things to get them to work.

> considerations.  So in my view, buying a PICkit or ICD2 or whatever, is
> something of a crap shoot, and maybe more risky than buying/building some
> generic programmer.  But the starting out point is often better, and if the
> device you select is relatively new, then the odds are you will have support
> for at least a few years.

The PicKit 2 comes with open source software. I agree that the
database of devices is a little bit dense to figure out, but if I
needed to, I'm sure I can add support for other devices to it as well.
As you said yourself: most of it is in the software, and with the
PicKit 2, the software is easy to change.

Greetings,
Maarten Hofman.

2005\11\03@095611 by olin piclist

face picon face
Juan Cubillo wrote:
> Why is it that some programmers (wisp628, kit 149, GTP-USB, etc)use
> PICs in them to controll programming?

Because those people designing PIC programmers are generally familiar and
comfortable with PICs.  Besides, it's hard to find tools for a 4004 anymore.

> If the old programmers like icprog or elcheapo are able to control the
> clock, data, and mclr lines, why can´t you just add support for newer
> PICs to their software.

Why can't I?  I probably could, but I don't feel like it.

> As far as I know all(?) PICs use the same
> method to load data into them.

At the low electrical level and for transferring bits, yes.  However the
higher level protocols are very different between PICs.

> Is there any good reason to use controllers inside programmers VS
> computer controlled lines?

Lots, else nobody would have gone thru the trouble of designing more
complicated programmers with controllers in them.


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

2005\11\03@193838 by Chen Xiao Fan

face
flavicon
face
A bit of advertising here:

So please consider joining the pickit-devel project and add some chip
support to PICKit 2 like 16F627A/628A/648A (already supported by
firmware) and others. You can also hack the firmware as well.
http://groups.google.com/group/pickit-devel/

Mark Rages and Jeff Post are working on the python version and
C version of alternative host program for PICkit 2. The python
version (aka pyk) is now working under Linux and support quite
some chips already including 16F7x and 16F7x7 which has not
been supported by Microchip Windows host program yet.

Regards,
Xiaofan

{Original Message removed}

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