In-Reply-To: <20110102172402.GB5850@mail.clayton.edu>

Byron,

> On Sun, Jan 02, 2011 at 04:42:35AM -0500, Michael Watterson wrote:
> > On 01/01/2011 23:45, Olin Lathrop wrote:
> > > Byron Jeff wrote:
> > >> >  But how do you program it? I know the typical answer to this is "=
buy a
> > >> >  programmer".
> > > Exactly.  It seems like you're going a long way to avoid getting a
> > > programmer.  Do you realize a fully compliant programmer is now avail=
able in
> > > singles for only $20
> > > (http://www.microchipdirect.com/ProductSearch.aspx?Keywords=3DTEMLP00=
1)?
> > > That's cheaper than I sell singles on my own web site.  I'll make the=
m
> > > available at subtantial discount if you want to outfit a whole lab or=
 get
> > > one for every student in a class.  Even before any educational discou=
nt,
> > > it's already a lot less money than any book the student will have to =
buy for
> > > a class.
> > >
> > > The LProg only handles the PICs that can enter program mode with the =
unlock
> > > sequence and don't require high voltage on Vpp, but there are plenty =
of
> > > those to chose from and that shouldn't be much of a constraint if you=
're a
> > > hobbyist or student.
> > >
> > > Hopefully it will do the 16F182x subfamily soon.  I'm digging thru th=
e
> > > normal high voltage programming algorithm now, and see that the POD h=
as been
> > > busy.  It's mostly the same, but just different enough to require mor=
e cases
> > > to be added in a few places.  After I get the 16F182x working with no=
rmal
> > > HVP on the USBProg, I'll try to add support to the LProg with LVP.
> > >
> > >> >  But if you're only going to use it once in a blue moon,
> > >> >  because the primary mode of development is a bootloader, it's not=
 as
> > >> >  simple a decision as you may think.
> > > But you're only using the programmer once in a blue moon because it k=
inda
> > > sucks, being a "dumper" as you call it.  Think of the reverse.  If yo=
u
> > > already had a programmer then you wouldn't have to hassle with a boot=
loader
> > > at all.
> >=20
> > Olin speaks great sense here.
> >=20
> > If I was doing production programming I'd not recommend the Pickit2. It=
=20
> > and other budget programmers are for people that want to dabble and=20
> > don't want to spend money.
> >=20
> > As I had my own home made ICSP programmer (using VP=3D12V) and serial p=
ort=20
> > bitbanging for several years, I bought the Pickit2 at recommendation of=
=20
> > the list here as I needed 3.3V prog for 18FxxJxx family. I wish I had=20
> > bought it sooner. It was actually cheaper on Microchip site than clones=
,=20
> > but delivery was 3 months. so I bought the clone from Sure Electronics=
=20
> > (it matches Microchip published schematic) and it happily loaded the=20
> > latest firmware version from Microchip. You can pay MORE in the Retail=
=20
> > High street for a dumb USB to Serial Adaptor.
>=20
> Gentlemen,
>=20
> Trust me when I say that there's more to the Universe than you show.
>=20
> I've never been a fan of programmers, ICSP or otherwise. The required
> interface has always been restrictive, requiring a minimum of 3 I/O pins
> (and until recently 4 with LVP) to operate. A developer is either stuck
> impacting their target to accomodate ICSP or having to pull the chip in
> order to program it, which really sucks.
>=20
> I thank Wouter for spoiling me rotten. With both WLoader, with its one pi=
n
> half duplex interface, and ZPL and its virtual zero pin interface, the
> programming interface becomes a single pin, or my choice, which usually a
> pin that's out the way, instead of the top two pins of PORTB, possibly th=
e
> middle of PORTB, and MCLR, which is always shared with an input. Frank
> Sargent followed a similar route with his PikMe bootloader, making it
> bitbanged input only. For example on the 16F1939, MCLR is shared with
> PORTE3 as an input. The top pin of the last port is completely out of the
> way.
>=20
> Take a read of Wouter's ZPL design document for a more detailed discussio=
n.
> I took the liberty of putting a copy on my site:
>=20
> http://kahuna.clayton.edu/byron/zpl.pdf
>=20
> Even though that was 8 years ago, all of his points are still valid:
>=20
> - Chips are getting faster with more memory
> - I/O space and peripheral usage is at a premium
> - A transparent bootloader using simple interface hardware can be a
>   useful development environment.
>=20
> Now it's even better with embedded precision oscillators and actual I/O
> being shared on the MCLR pin. The programmer to the target becomes
> essentially a 2 wire interface that's completely out of the way of the
> application. And the single real cost, the program memory usage, is the
> real cost that can be easily absorbed. The 16F1939 I'm using now has 16K
> words of program memory. A good bootloader will take up about 200 of thos=
e
> words.
>=20
> The final item is that no matter what type programmer you bring to the
> table, they are not going to be available off the shelf, and they only
> serve that one singular purpose of programming PICs. Even though they are
> similar in price, USB to serial converters are easily available, and they
> can serve more purposes than just programming PICs. It may even be an ite=
m
> that a new developer already has.
>=20
> It's a viable development method, and there are valid reasons for pursuin=
g
> it. ICSP just cannot ever be as transparent as a bootloader can be.
>=20
> BAJ
>=20
> --=20
> Byron A. Jeff
> Department Chair: IT/CS/CNET
> College of Information and Mathematical Sciences
> Clayton State University
> http://cims.clayton.edu/bjeff
>

But how do you do your debugging?

Brian Gregory.
briang@cix.compulink.co.uk

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.