gnupic: Thread: PIC Programmer and Software


[<<] [<] Page 1 of 1 [>] [>>]
Subject: PIC Programmer and Software
From: Elias Jahn ####@####.####
Date: 17 Feb 2004 23:37:35 -0000
Message-Id: <1077059260.8050.15.camel@localhost.localdomain>

Hi people!

I just want to hear your opinion, it's the case that I intend to build a
PIC-Programming device and get a working software for it (under linux,
obviously). I have programmed PIC's before, so I'm no newbie, but the
programmer I had wasn't really good, and the software neither, so, what
I did, was looking (and asking, long time ago) for some solution on this
mailing list. I found quite a lot, so I analyzed them all, and made this
choice:

--Programming device:
Byron A. Jeff's HVP ParallelPort PIC Programmer (High Voltage, because,
although I'm convinced aswell, that the 16F84 is obsolete, I still have
some lying around here, and don't want to throw them into the
rubbish..., if it wasn't that, I would be happy with the LVP aswell)

--Programming software:
PiKDev (after reading so good comments about it and after looking at the
impressive details and screenshots about the project, it must be
great...)
But, as an alternative, Byron's modified version of picprg2.3d

So, I would like to hear what you think of my choice. Here are my goals:
--Program (at least) the following PIC's:
16F87x, 16F628, 16F84
--The programming software must be +- decent in use and "comfort", and
reliable.
--The programming software must be able to set and read the config bits,
and perform - obviously -, all normal programming operations, using
compiled output hex files made with gpasm.
--What I don't need (at least for now) is: In Circuit Programming, In
Circuit Debugging, nor do I want a Boot loader or other stuff (it must
be useful, for shure, but I find it a bit too complicated, I prefer to
load the PIC by the traditional way)

Do you think with my choice I will be able to reach those goals? Or do
you have better suggestions? Many thanks in advance, and sorry for
"wasting" your time ;-)

Cheers,
Elias

Subject: Re: PIC Programmer and Software
From: Byron A Jeff ####@####.####
Date: 18 Feb 2004 01:22:03 -0000
Message-Id: <20040218005038.GA16912@cleon.cc.gatech.edu>

On Tue, Feb 17, 2004 at 11:07:41PM +0000, Elias Jahn wrote:
> Hi people!
> 
> I just want to hear your opinion, it's the case that I intend to build a
> PIC-Programming device and get a working software for it (under linux,
> obviously). I have programmed PIC's before, so I'm no newbie, but the
> programmer I had wasn't really good, and the software neither, so, what
> I did, was looking (and asking, long time ago) for some solution on this
> mailing list. I found quite a lot, so I analyzed them all, and made this
> choice:
> 
> --Programming device:
> Byron A. Jeff's HVP ParallelPort PIC Programmer (High Voltage, because,
> although I'm convinced aswell, that the 16F84 is obsolete, I still have
> some lying around here, and don't want to throw them into the
> rubbish..., if it wasn't that, I would be happy with the LVP aswell)

Good choice. Of course I'm a bit biased. ;-) I'm planning on two updates in
the hopefully near future: a updated picprg with current programming algorithms
(I just got the 16F819 working yesterday) and a final solution to the short
programming cable problem.

> 
> --Programming software:
> PiKDev (after reading so good comments about it and after looking at the
> impressive details and screenshots about the project, it must be
> great...)
> But, as an alternative, Byron's modified version of picprg2.3d

I haven't tested it yet, but it's an active project with lots of chip
choices. So I think it could certainly be a good choice.

> 
> So, I would like to hear what you think of my choice. Here are my goals:
> --Program (at least) the following PIC's:
> 16F87x, 16F628, 16F84

I suggest that you may want to expand your pool and add the:

16F819: self programmable, 18 pin package, internal oscillator module giving
up to 8 Mhz with no external pins. Almost as good as the 16F628 except no
hardware UART. But it does add A/D capability. Under $2 in quantity.

16F88: The new 18 pin champ for the hobbyist. It has everything the 16F648A
has (hardware UART, 4K program space) plus all of the features of the 16F819
too. So it's a complete package for 18 pin package development.

16F777: It's the 87XA family with the nanowatt features including the 8 Mhz
internal oscillator. Looks like a great chip. I order some samples from
Microchip. A bit pricy at $4.50 in the 25 piece range, but looks real
interesting.

18F2320: When you're ready to step up to 18F family, could be a good starter
chip. has nanowatt. Can run up to 40 Mhz. 28 pin package. Has all of the
features of the 18F family.

BTW getting samples is a great way to test all the cool new technology out.

> --The programming software must be +- decent in use and "comfort", and
> reliable.
> --The programming software must be able to set and read the config bits,
> and perform - obviously -, all normal programming operations, using
> compiled output hex files made with gpasm.
> --What I don't need (at least for now) is: In Circuit Programming, In
> Circuit Debugging, nor do I want a Boot loader or other stuff (it must
> be useful, for shure, but I find it a bit too complicated, I prefer to
> load the PIC by the traditional way)

Well sir, you and I can no longer speak! ;-) ;-) ;-)

In all honesty I'm exactly the opposite in every respect. The traditional
route adds a lot of process complexity because you have to move the chip
when you develop. This slows down the process. Once I build the hardware
I like to become a software developer again. So being able to attach a 
cable to the target and develop away without having to do anything to the
hardware is of great benefit.

My order of preference:

1) Bootloader: The best of the best. Not only do lose the mobility requirement
for programming, you get to choose the interface that best fits what you need.
Wouter van Ooijen's Wloader loader used only a single I/O pin (your choice).
His ZPL loader is even better, because it uses the MCLR pin to program the
part, which means that you don't lost an I/O pin at all. Just plug and go.

2) ICSP: Not as good because you have to dance around the pins required for
doing ICSP. But better than nothing because you can work in place.

3) ICD: I find problematic because Mchip hasn't been real forthcoming about
exactly how it works. It has the same issues as 2, but when it works you can
get debugging in real time which is always helpful.

4) Standard Programmer: It's only purpose in life for me is to get the
bootloader going.

But first and foremost is to have an environment that works for you. 

BAJ

Subject: Re: PIC Programmer and Software
From: Elias Jahn ####@####.####
Date: 19 Feb 2004 00:38:37 -0000
Message-Id: <1077149318.7600.17.camel@localhost.localdomain>

Hi.

Thanks for your reply Byron.
Actually I like your "order of preference", I can't say anything against
it ;) , but even though, I won't do it like that for now, and that's
why: I want to "take off" quickly, and (for now) I don't want to learn
all that new stuff with boot loader, etc, and I would have to manage a
way (buying special connector, probably) to connect the programmer to my
PIC in the target circuit, and some other problems, which surely could
be perfectly resolved and I would get a much better and more comfortable
way of programming PICs, but I just have lack of time for that, what I
want is start programming again, and as soon as possible (I made a much
too long break, had so much things to do... but that's not good, one
forgets some stuff...). So I don't worry if I have to take out the PIC
of the programmer, put it in my target, test, and if I find errors
(which is most likely to happen ;), then I have to put it in the
programmer again, etc... I've done that already some time ago with my
older programmer, well, it really isn't comfortable, but it doesn't
bothers my neither... as long as the PIC gets well programmed and the
stuff works easily... So that's my point of view, just wanted you to
know it ;) (main reason for it is, actually, that I don't program lots
of PICs, and I just do it occasionally, it's just a hobby... if you want
to see a few projects I did, look here at my site (it's in portuguese
language, but should be no problem if you just take a look at it, you
find links to the projects in the left frame of this page): 
http://electronicos.planetaclix.pt/piclink.htm )
So, that's all, now I'm going shopping some required parts, hehe, not
much actually, and then I'll build the hardware, download the software
and start programming. I'll then tell you and the people on gnupic if it
works ;)

Regards and happy coding,
Elias Jahn



Am Mi, 2004-02-18 um 00.50 schrieb Byron A Jeff:
> On Tue, Feb 17, 2004 at 11:07:41PM +0000, Elias Jahn wrote:
> > Hi people!
> > 
> > I just want to hear your opinion, it's the case that I intend to build a
> > PIC-Programming device and get a working software for it (under linux,
> > obviously). I have programmed PIC's before, so I'm no newbie, but the
> > programmer I had wasn't really good, and the software neither, so, what
> > I did, was looking (and asking, long time ago) for some solution on this
> > mailing list. I found quite a lot, so I analyzed them all, and made this
> > choice:
> > 
> > --Programming device:
> > Byron A. Jeff's HVP ParallelPort PIC Programmer (High Voltage, because,
> > although I'm convinced aswell, that the 16F84 is obsolete, I still have
> > some lying around here, and don't want to throw them into the
> > rubbish..., if it wasn't that, I would be happy with the LVP aswell)
> 
> Good choice. Of course I'm a bit biased. ;-) I'm planning on two updates in
> the hopefully near future: a updated picprg with current programming algorithms
> (I just got the 16F819 working yesterday) and a final solution to the short
> programming cable problem.
> 
> > 
> > --Programming software:
> > PiKDev (after reading so good comments about it and after looking at the
> > impressive details and screenshots about the project, it must be
> > great...)
> > But, as an alternative, Byron's modified version of picprg2.3d
> 
> I haven't tested it yet, but it's an active project with lots of chip
> choices. So I think it could certainly be a good choice.
> 
> > 
> > So, I would like to hear what you think of my choice. Here are my goals:
> > --Program (at least) the following PIC's:
> > 16F87x, 16F628, 16F84
> 
> I suggest that you may want to expand your pool and add the:
> 
> 16F819: self programmable, 18 pin package, internal oscillator module giving
> up to 8 Mhz with no external pins. Almost as good as the 16F628 except no
> hardware UART. But it does add A/D capability. Under $2 in quantity.
> 
> 16F88: The new 18 pin champ for the hobbyist. It has everything the 16F648A
> has (hardware UART, 4K program space) plus all of the features of the 16F819
> too. So it's a complete package for 18 pin package development.
> 
> 16F777: It's the 87XA family with the nanowatt features including the 8 Mhz
> internal oscillator. Looks like a great chip. I order some samples from
> Microchip. A bit pricy at $4.50 in the 25 piece range, but looks real
> interesting.
> 
> 18F2320: When you're ready to step up to 18F family, could be a good starter
> chip. has nanowatt. Can run up to 40 Mhz. 28 pin package. Has all of the
> features of the 18F family.
> 
> BTW getting samples is a great way to test all the cool new technology out.
> 
> > --The programming software must be +- decent in use and "comfort", and
> > reliable.
> > --The programming software must be able to set and read the config bits,
> > and perform - obviously -, all normal programming operations, using
> > compiled output hex files made with gpasm.
> > --What I don't need (at least for now) is: In Circuit Programming, In
> > Circuit Debugging, nor do I want a Boot loader or other stuff (it must
> > be useful, for shure, but I find it a bit too complicated, I prefer to
> > load the PIC by the traditional way)
> 
> Well sir, you and I can no longer speak! ;-) ;-) ;-)
> 
> In all honesty I'm exactly the opposite in every respect. The traditional
> route adds a lot of process complexity because you have to move the chip
> when you develop. This slows down the process. Once I build the hardware
> I like to become a software developer again. So being able to attach a 
> cable to the target and develop away without having to do anything to the
> hardware is of great benefit.
> 
> My order of preference:
> 
> 1) Bootloader: The best of the best. Not only do lose the mobility requirement
> for programming, you get to choose the interface that best fits what you need.
> Wouter van Ooijen's Wloader loader used only a single I/O pin (your choice).
> His ZPL loader is even better, because it uses the MCLR pin to program the
> part, which means that you don't lost an I/O pin at all. Just plug and go.
> 
> 2) ICSP: Not as good because you have to dance around the pins required for
> doing ICSP. But better than nothing because you can work in place.
> 
> 3) ICD: I find problematic because Mchip hasn't been real forthcoming about
> exactly how it works. It has the same issues as 2, but when it works you can
> get debugging in real time which is always helpful.
> 
> 4) Standard Programmer: It's only purpose in life for me is to get the
> bootloader going.
> 
> But first and foremost is to have an environment that works for you. 
> 
> BAJ
> 
> 

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.