Searching \ for '[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: techref.massmind.org/techref/microchip/devprogs.htm?key=programmer
Search entire site for: 'Why programmers use PICs as controllers?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Why programmers use PICs as controllers?'
2005\11\03@070340 by Jan-Erik Soderholm

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?

It works "better".

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

Depends on your definition of "same method".
But generally speaking, no, there are 5-10
different "methods".

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

Works on newer PCs (without serial ports).
Easier to use on newer Windows versions.
Easier to use on "other" operating systems.
Better control of the programming voltages.

Jan-Erik.



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

flavicon
face
----- Original Message -----
From: "Jan-Erik Soderholm" <spam_OUTjan-erik.soderholmTakeThisOuTspamtelia.com>
Subject: RE: [PIC:] Why programmers use PICs as controllers?

A little more detail

> Works on newer PCs (without serial ports).

Programming a PIC with the serial port only actually uses the serial port in
a way in which it was not intended.  As a result, USB to serial converters
don't work for programming when the programmer doesn't include its own
intelligence.  Although the problem is somewhat simpler with parallel ports,
parallel ports are also getting scarce.

Even if you don't use USB, having intelligence onboard means you can use the
serial port as a serial port, which means you can use "normal" Windows
software, and don't have to play all sort of "tricks", and USB to serial
converters work for machines with no serial port.

> Easier to use on newer Windows versions.

I would argue with this one.  Accessing the serial port on newer Windows
versions is a real pain for the developer of the PIC programming software.
But to date, installing USB software is often a real pain for users of that
software.  Go read Microchip's ICD2 forum.  A huge fraction of those threads
are about people battling the installation of the USB software.  I suppose
if you use serial with an onboard PIC avoids these issues, you now expect
many users to use a USB to serial converter.

> Easier to use on "other" operating systems.

I have no data, although again, using a serial port as a serial port has to
be easier for the developer of the programming software.  I see no reason
for it to be easier for the user of that software.

> Better control of the programming voltages.

Microchip suggests that you verify the result at several voltages.  If the
programmer has no onboard intelligence, there really isn't a realistic way
of doing this with a serial port.  There simply aren't enough lines.  I
could imagine doing this with a parallel port, but it would be a major pain.

Putting some intelligence in the programmer opens up all sorts of options,
and since we are programming a PIC, a PIC is an obvious way to get that
intelligence.

--McD


2005\11\03@074315 by Jan-Erik Soderholm

face picon face
John J. McDonough wrote :

Thanks for "expanding" my points, but there are
a few ones I don't understand.


>
> > Easier to use on newer Windows versions.
>
> I would argue with this one.  Accessing the serial port on
> newer Windows versions is a real pain for the developer
> of the PIC programming software.

If you use the serial port as it was ment to be used,
I don't see that it's "pain". It's more or less the same
OS-API's as always, isn't it ?

That's why I said that a "intelligent" programmer is easier
to use on modern Windows versions, since you don't have
to deal with special drivers to access the hardware port.

> > Easier to use on "other" operating systems.
>
> I have no data, although again, using a serial port as a
> serial port has to be easier for the developer of the
> programming software.  I see no reason
> for it to be easier for the user of that software.

Neither do I, and I don't think the questions (or my reply)
was specificaly about the "user" anyway...

Regards,
Jan-Erik.



2005\11\03@075601 by Wouter van Ooijen

face picon face
> > Easier to use on newer Windows versions.
>
> I would argue with this one.  Accessing the serial port on
> newer Windows versions is a real pain for the developer of the PIC
> programming software.

Not if you are playing the 'modern windows rules': use the OS calls.

Especially not if you use a library call that is the same on windows,
linux, ... :)

> > Easier to use on "other" operating systems.
>
> I have no data, although again, using a serial port as a
> serial port has to
> be easier for the developer of the programming software.  I
> see no reason
> for it to be easier for the user of that software.

It makes it easier by being available!

Wouter van Ooijen

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


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

flavicon
face
----- Original Message -----
From: "Jan-Erik Soderholm" <.....jan-erik.soderholmKILLspamspam@spam@telia.com>
Subject: RE: [PIC:] Why programmers use PICs as controllers?


> If you use the serial port as it was ment to be used,
> I don't see that it's "pain". It's more or less the same
> OS-API's as always, isn't it ?

If you use the serial port as it was meant to be used, there are APIs that
have been available since at least Windows 3.x, and some of the newer APIs
are actually a lot more convenient, if harder to get your head around.  But
people writing PIC programming software are often people who use PICs, and
thus are a lot more confortable getting close to the iron than some VB
programmer used to writing invoicing programs.  For these people, the APIs
they like are no longer available.  Further, programming a PIC without
onboard intelligence requires that you do some things that the serial port
never intended.  These things were pretty easy on 3.x, got harder on 9x, and
got to be a major pain in NT (Windows 2000 and XP are actually NT 5.0 and
5.1).

> That's why I said that a "intelligent" programmer is easier
> to use on modern Windows versions, since you don't have
> to deal with special drivers to access the hardware port.

Yes, absolutely.  When I wrote about issues for the user, I was really
thinking in terms of USB programmers.  For modern PCs these seem to be the
straightest line, but Windows handling of installing USB drivers still isn't
what we would like it to be.

> Neither do I, and I don't think the questions (or my reply)
> was specificaly about the "user" anyway...

Yeah, and I don't know that the user (gets weird when the user is a
developer, doesn't it) really sees any difference.  I suppose for
"programmer friendly" operating systems like Linux, where a lot of what is
going on under the covers is obvious to the end user, that a nice, normal
serial connection, or even a USB connection, might be somewhat easier than
apps where you need to do weird things to the port, but I'm guessing that
it's not all that different.  I have a fair bit of experience with Linux,
but I've never installed a PIC programmer of any flavor on Linux.

But on reflection, I don't know of a "simple" PIC programmer where the
installation on XP SP2 is all that "simple".  Quite a bit of software that I
have tried I have neot been able to make work at all.  FPP, which is really
wonderful on 9x, and not bad on XP/SP1, is a major pain to install on SP2.
Even on SP1 it requires the user to install some drivers that aren't really
much fun.  FPP only programs a handful of PICs but it is very fast and easy
to use.

Winpic (the one from the German guy -- I think there are at least two
Winpic's) is basically a straightforward install, but it can only be used on
XP by an administrative user.  As people get more security conscious, this
gets to be a problem.

Both of these can adapt to a wide variety of programming hardware.  I
haven't messed with anything proprietary except ICD2.

--McD


2005\11\03@210335 by Juan Cubillo

flavicon
face
Thanks for the asnwer

----- Original Message -----
From: "Jan-Erik Soderholm" <jan-erik.soderholmspamKILLspamtelia.com>
To: <.....piclistKILLspamspam.....mit.edu>
Sent: Thursday, November 03, 2005 6:03 AM
Subject: RE: [PIC:] Why programmers use PICs as controllers?


{Quote hidden}

> --

2005\11\03@210355 by Juan Cubillo

flavicon
face
Thanks for the asnwer

----- Original Message -----
From: "Jan-Erik Soderholm" <EraseMEjan-erik.soderholmspam_OUTspamTakeThisOuTtelia.com>
To: <piclistspamspam_OUTmit.edu>
Sent: Thursday, November 03, 2005 6:03 AM
Subject: RE: [PIC:] Why programmers use PICs as controllers?


{Quote hidden}

> --

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