gnupic: DIY USB programmer ?
Subject:
Re: DIY USB programmer ?
From:
David Willmore ####@####.####
Date:
14 Jan 2005 04:52:52 +0000
Message-Id: <200501140452.j0E4qnVZ014326@localhost.localdomain>
> >Hmmm, this is where we're going to have an issue. You can't get a PIC
> >at radio shack. Nor can you get the PCB. What parts of this programmer
> >do you want to put that restriction on? Just the bootstrap portion?
>
> The bootstrap portion. Remember that I'm still working on it as an isolated
> circuit.
Okay, that part makes sense to keep restricted in this way. For the rest,
well, maybe a few more parts.
> Also Microchip samples virtually all of their chips. So it's possible to get
> a double handful of PICs without having programmer, PCB, or parts in hand.
> By restricting the bootstrap portion to a RatShack parts list, it's possible
> to get instant gratification. It's not a requirement for everyone to do
> so, but I'm sure someone will be grateful that they can go in on a Sunday
> afternoon and get all of the parts necessary to bootstrap.
That's true. The rest of the programmer will require a little more than
RS parts--from what I can tell. We'll see.
> >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.
> >Good idea. I only use the GUI, so I hadn't thought about that. It would
> >probably be a good debugging too to do it with pkp.
>
> I'm sure that the GUI isn't too terribly difficult to do. But I'll leave it
> up to those who are used to doing it.
Alain keeps trying to get me to do it. :) I probably should, but I'm
no GUI programmer. :) I'm likely to mangle stuff up.
> 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.
> 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.
> >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.
Cheers,
David
