Subject:
Re: DIY USB programmer ?
From:
Byron A Jeff ####@####.####
Date:
5 Jan 2005 23:01:31 +0000
Message-Id: <20050105230127.GA5822@cleon.cc.gatech.edu>
On Wed, Jan 05, 2005 at 05:14:49PM -0500, David Willmore wrote:
> > > You're unlikely to find a USB interface chip + PIC combo cheaper than a UBS
> > > PIC, so why not use use it from the beginning--and get the benefit of an
> > > 18F pic? ;)
> >
> > The original catch 22 problem. How do you program the USB PIC?
>
> Sure, so have someone program one for you. Send an email to
> ####@####.#### and ask someone to burn you a chip. SASE the chip
> to them. Not so hard. :)
David,
I've been listening to Manuel on the subject. He expressed issues in terms
of shipping, duties, taxes and the like.
Again the original project wasn't to build a programmer. It was to program
a chip for a cockpit simulator.
While shipping a preprogrammed PIC may be the solution, I tackled the
problem of "I have this blank PIC. I want my cockpit simulator now. So
now what?"
>
> > > Okay, maybe this is a definition problem, but the difference between 'dump
> > > USB interface chip' and uC with USB interface doesn't seem to be meaningful.
> > > Why not use base the programmer around a USB micro?
> >
> > Because you then have to either buy a preprogrammed micro or have a
> > programmer which will require a preprogrammed micro.
>
> Sure, that's no big deal, though.
>
> > Let's define the requirements again:
> >
> > 1) You have a user with a blank PIC.
> > 2) The user doesn't have a traditional PIC programmer of any type.
> > 3) As per the spec of the OP the user's machine only has USB.
> > 4) The user has access to ordinary electronics and computer parts such as
> > a USB to serial cable. However special parts, including preprogrammed
> > PICs, would require a significant investment in funds and time.
> > 5) And the most important one: The user really isn't interested in
> > programming PICs. So they don't want to buy a traditional programmer.
> >
> > Essentially the design is for a one off PIC programmer that can be driven
> > from the USB port. Keep the design simple, the parts cheap and available.
>
> That would be a very cool project, but I'd really only want to bootstrap
> the first 'real' programmer with it. Otherwise, you're going to be relying
> on too many marginal issues--timing, software, etc.
Again we aren't trying to build a real programmer here. I think that's the
point that most have missed. It's a one and one.
Of course you and I would use it to bootstrap a better programmer. But that's
not its intended purpose.
>
> > BTW the FTDI parts fail all of the above as a complete module using the
> > chip isn't easily available and is expensive.
>
> Digikey sells someones module with one on it for some $25 or so. What price
> range are we looking at? I was thinking $25 for micro/PCB/parts seems fair.
> For a case+ZIF, you're going to go up in price. But, if you have a
> breadboard and don't mind wiring stuff up, you're done.
>
> > I think the clear winner in this segment is the USB to serial cable.
> > It's cheap. It keeps the design simple and is readily available everywhere.
>
> If your 555 design can do it, I think it'd be cool. But, like the zero
> pin programming trick, not really useful for anything over the most
> casual development. So, as a true "I'm only going to do this once" bootstrap,
> I think it's great.
So we're in agreement.
>
> > > Fine, you say, those <waits> can be as long as they want. Sure, they
> > > can, but that's not what you run into. The FTDI windows driver *caches*
> > > things you send to it and only updates the chip (over the USB) some 8000
> > > times a second. If you say "do something" and wait a little bit and
> > > then say "do something else", there is no guarentee that those two
> > > somethings will be sequenced when they hit the chip--they may hit the
> > > chip simultaniously--violating setup times for data->clock. So, I find
> > > these chips to be useless for this task. Blink a LED with a pin, yeah,
> > > they can do that, but something with delicate timing? No.
> >
> > This is the reason that in another post I stated that I have some
> > apprehension about using the modem control signals on a USB to serial
> > cable. There's no guarantee with the timing relationships between those
> > signals.
>
> Exactly and the USB->RS232 are even worse than a hardware UART in that
> department--much worse.
>
> > In TX we trust!
>
> In TX *alone*. :) No way to *verify* the chip. ;)
>
> > > Develop, yes. We'll see how much time it takes, but the design is
> > > fairly simple from a hardware standpoint. The software isn't much
> > > more complex--look at the protocol used by the pulseEngine in PikDev
> > > and you'll see what I mean. Maintenance shouldn't be hard as once
> > > you can manipulate all of the pins, what more is there? ;)
> >
> > Well there's still the bootstrap issue. How you program the chip for a
> > programmer when you don't have a programmer?
>
> SASE+sample chip or just paypal someone $10 and ask nicely? :)
Or the bootstrap programmer that I've described.
>
> > That's what the OP means by intelligent. A "dumb" solution can be
> > "programmed" with solder and wire, not requiring an additional programmer in
> > order to program the chip to make the programmer. It breaks the catch 22
> > chain.
>
> Okay, so how about a 'front pannel' bank of toggles type of programmer and
> a contest to see who can write the smallest 18F2550 USB bootstrap program? ;)
>
> > Maybe we should come up with a term to describe this type of programmer
> > whose sole purpose is a one off load into a part. I nominate bootstrap
> > programmer because its purpose is to bootstrap a PIC with project code or
> > a bootloader.
>
> Yep, I think that's the perfect term. Is the OT wants a bootstrap programmer,
> you design looks like the way to go. If they want a very basic/flexable
> USB programmer, mine might be a better choice.
Of course.
BAJ
