gnupic: DIY USB programmer ?
Subject:
Re: DIY USB programmer ?
From:
Byron A Jeff ####@####.####
Date:
14 Jan 2005 01:52:38 +0000
Message-Id: <20050114015235.GA19400@cleon.cc.gatech.edu>
On Thu, Jan 13, 2005 at 08:01:50PM -0500, David Willmore wrote:
>>>For those who just want to build the think from digikey parts,
>>
>>Radio Shack David. The US gold standard is parts from the RatShack parts
>>drawers as expensive as they may be.
>
>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.
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.
>
>>>>I took a 5 minute look at Pikdev. It'll require adding a new type of
>>>>programmer
>>
>>Port, not programmer.
>
>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.
>
>We'll probably need to come up with a new term. "interface"?
Works for me.
>
>>>>separate from the parallel and serial programmers defined now. Fortunately
>>>>the class only has a handful of definitions. I didn't see how to connect
>>>>the type to the class though.
>>
>>I found it. A new port is instantiated in hardware.cc. I got a failure of
>>pkp when I set the type=555 in .pkprc. So it's just a line of code.
>
>Does this include the work to add a new GUI pannel for configuring the
>port?
Nope.
>
>>>I thought it would fit in pretty easily. You'd need to make a new
>>>programmer
>>>dialog for it, but it would only have to have a pulldown for serial port
>>>as an
>>>option--maybe we'd need some calibration stuff in there too, huh?
>>
>>I'll leave that up to Alain to decide the interface. I'll do all of my
>>testing using pkp and the .pkprc file from the command line.
>
>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.
>
>>>I've been using it for use with your THVP for a while now and I've had great
>>>luck. For those PICs that it didn't support, I found that it wasn't that
>>>hard to add it. Of course, I have to finish submitting that... Sorry
>>>Alain...
>>
>>I happy to find out that it works. Is there a Windows port for pikdev. I
>>didn't see anything for it in the download section.
>
>Not to my knowledge. It's a KDE app, so you need Qt--which is commercial
>for the Windows platform. So, we might need a professional developer for
>that port. Or integrate the backend into some other program. pkp might
>run there more easily.
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.
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.
[SNIP on kitting]
>>>Keep up the good work, Byron!
>>
>>I'm very interested now because I can see the light at the
>>end of the tunnel.
>>The bootstrapper will serve all of my immediate needs because once it's
>>coupled with pikdev I'll be able to program all the 18F chips that I've
>>been sampling along with the 12F parts that I've been drooling over. I'll
>>finally retire Brian Lane's picprog that I've been helping limp along for
>>the last few years.
>
>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.
BAJ
