Subject:
RE: DIY USB programmer ?
From:
"Robert Lang" ####@####.####
Date:
6 Jan 2005 00:50:44 +0000
Message-Id: <000701c4f389$f4bb4800$68d194d0@boblang>
Sorry for joining this midway through:
Someone below suggested getting someone to burn the chip. I just
completed a pic programmer for the new PIC18F2455,2550,4550 and 4455 and
would be willing to burn a chip if you are using one of these 28 pin
devices. These are all USB chips. Currently my programmer does not
support data EEPROM.
Robert B. Lang Jr.
Have MIDI. Will travel.
####@####.####
www2.netdoor.com/~rlang
> > 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. :)
> > 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.
> 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.
> > 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? :)
> 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.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
