gnupic: DIY USB programmer ?
Subject:
Re: DIY USB programmer ?
From:
Byron A Jeff ####@####.####
Date:
14 Jan 2005 05:37:34 +0000
Message-Id: <20050114053730.GA1941@cleon.cc.gatech.edu>
On Thu, Jan 13, 2005 at 11:52:49PM -0500, David Willmore wrote:
[I keep snipping just to keep it managable.]
> > >Hmmm, we have dumb parallel, dumb serial, bootstrap serial, and 'smart'
> > >serial.
> >
> > Correct. But Alain has done a pretty good job of isolating the specific
> > hardware interface from the generic hardware interface. But with the
> > interfaces (as you call them) for the bootstrap serial and smart serial
> > being so significantly different from the others, which are both bit
> > twiddlers, that maybe there needs to be another intermediate abstraction.
> > But I can't specify exactly what it should be off the top of my head. But
> > consider that the smart serial interface needs to be sent a much higher
> > command interface than the bit twiddlers.
>
> The chip 'personality' code calls pulseEngine() which is pretty much the
> level that the 'smart' serial programmer will fit in. The three 'dumb'
> programmers all live down at the 'turn a line on, turn it off' level.
> The bootstrap serial programmer will require a little bit of work to
> replace the bit manipulation routines, but I'll work with Alain on that.
> C++ seems to do that stuff pretty well--if what I learned on doing the
> chip 'personality' programming is true.
Actually I've already talked to Alain today. I sent him a preliminary spec
of what the new port interface would have to so. It's serport with a
handful of modifications.
[SNIP]
> > Well pkp can be a stopgap as far as I'm concerned. I learned from hard
> > experience that maintaining a single codebase should be a goal. Last year
> > I had one of my students spend a semester porting picprog to Windows. But
> > it's just to difficult trying to keep up. I applaud Alain for his efforts.
>
> Same here.
I know it's not Windows folks natural interface. I never realized how
strongly the point and click paradigm is ingrained into Windows folks until
I saw one of my students recently trying to point and click on a BIOS screen!
While there are some options (wxWindows, pdcurses with mouse support) I'm
just not too sure I want to tackle another GUI.
>
> > If anyone is interested I can point out the right drivers for parallel I/O
> > that works on everything from 95 up to XP plus the appropriate bit twiddling
> > interfaces for parallel. I'm not sure about serial since it uses ioctls.
>
> If we get a taker for a windows port, that would be *invaluable* information.
> >From watching the PIC-EL folk try to do the ELMER-160 lessons on windows,
> using FPP, I expect it to be very useful to get right.
What kinds of problems did you see?
>
> > >I think that's two wins. :) It removes the need to support picprog--which
> > >is probably already dead with TLVP/THVP with pkp. It also may increase the
> > >interest in Pikdev which helps us all.
> >
> > Definitely a win win situation.
>
> It's sometimes sad to retire useful code, but sometimes it's easier for
> everyone--once it's been outgrown. Maybe we need to have a little memorial.
Actually Brian is still working on it as far as I know. I posted a couple of
items to his picprg forum maybe a year ago.
BAJ
