gnupic: Re: [gnupic] can't 'make' picprg
Subject:
Re: [gnupic] can't 'make' picprg
From:
Byron A Jeff ####@####.####
Date:
20 Jul 2006 03:55:53 +0100
Message-Id: <20060720025537.GB20882@cleon.cc.gatech.edu>
On Wed, Jul 19, 2006 at 11:28:00PM +0100, Rob Pearce wrote:
> On Wednesday 19 July 2006 22:06, Maxim Wexler wrote:
> > I decided to put aside the serial programmer and try the parallel type at
> >
> > www.finitesite.com/d3jsys/
> >
>
> I'm not familiar with that, but I'll look and see how similar it is to all the
> ones I know :)
My Trivial programmer is a parallel cable that uses a 74HCT573 (or similar
HCT part) for level transistions between the 3.3V that modern parallel ports
output and the 5V that most PICs require for proper programming.
> > Is there a fix? Does Jeff's programmer work with other software?
> >
> It probably would if that other software were configured right.
True. It's really just a Tait style parallel port programmer. Anything software
that allows for parallel port pin/polarity configuration will most likely
drive it properly. I've had reports of pikdev/pkp and winpicprog both driving
it fine. It's one reason I haven't really stayed on top of the programming
software game.
The other is outlined on my page. I'm a firm believer in bootloader based
development. The Trivial programmers are really designed to be bootloader
code dumpers, not traditional PIC programmers. While it does somewhat limit
my choices, as the part must be self programmable, I haven't run into any
real obstacles so far.
> If it looks
> likely to be compatible with my code I'll put a tarball up somewhere. I think
> the only external package I rely on is GTK, and there's still a very crude
> command line if you don't want that.
What chips can your code program? The real hassle of PIC programming software
is keeping track of programming algorithms.
> BDT-picprog is, as yet, the only lump of code I've tried to auto-make-ify from
> scratch. So far it's proved very reliable for me, and a friend even managed
> to build a version to run on a Windows box! (minus GUI)
Cool! Now since there is a GTK+ for windows, shouldn't the GUI be a reasonable
target? I of course like the duality of a CLI and a GUI interface so I can
choose what's appropriate for the particular situation. Pikdev/pkp fill that
need quite nicely. It's looking like your code may too.
BAJ
