Subject:
Re: DIY USB programmer ?
From:
Byron A Jeff ####@####.####
Date:
5 Jan 2005 20:51:05 +0000
Message-Id: <20050105205102.GA25012@cleon.cc.gatech.edu>
On Wed, Jan 05, 2005 at 12:13:17PM -0500, David Willmore wrote:
> Manuel,
>
> > On Tue, Jan 04, 2005 at 01:13:48PM -0500, David Willmore wrote:
> > > Buying a preprogrammed PIC from someone is probably a bit easier than
> > > getting one of the FTDI chips and it's certainly easier than *working*
> >
> > Yes, true, but I've had one fellow who went to a place where he got the
> > PIC programmed, but that wasn't cheap. And my designs consists of different
> > boards, and some types of them need PICs. So the cost would add up
> > quickly, esp when I do updates (for those boards that don't have
> > bootloading capability yet).
>
> I was thinking of offering to supply pre-programmed PICs for the project
> and I don't see that as a big money making angle. :) So, PIC cost+
> shipping. It'd probably be $10 or so. Or were you thinking of replacing
> the whole micro?
>
> 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?
>
> > > with them. If you're afraid of getting a PIC programmed SMT soldering
> > > probably isn't your thing, either. :)
> >
> > Believe it or not, one guy has way more trouble with PIC burning than
> > SMT soldering (and it was his first SMT).
>
> I'm with you in thinking that SMT soldering is often considered much
> harder than it is. But, PIC programming is quit easy--just not from
> a raw USB port. :(
>
> > > > I've skimmed the programming specs for two chips, and it looked like
> > > > most timings don't have a "max" defined. So, would this be possible ?
> > >
> > > Possible or useful?
> >
> > More like useful.
>
> Okay, then don't expect the FTDI chips to be helpful. I'll explain later.
>
> > > > What do you guys think ? Could it be possible to build a simple burner
> > > > that does not need "intelligence" apart from an USB interface chip.
> > >
> > > I just don't see the benefit.
> >
> > Same as JDM does for owners of serial ports :)
> > Simplicity, cost, availablility.
>
> 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.
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.
BTW the FTDI parts fail all of the above as a complete module using the
chip isn't easily available and is expensive.
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.
>
> > > > I know the FTDI USB chips have a "bit-bang mode".
> > >
> > > Yes, and there are some drivers for it, but I've heard of issues with
> > > people who have used it in that it still does not preserve the timing
> > > as they expected it to.
> >
> > Thats why I was wondering about the max timing values...
>
> But the max values aren't the catch with those guys. From the experiences
> of some friends of mine who tried that it seems that the windows driver
> has a few 'gotchas'. Here's a common task for speaking to a PIC when
> you're programming it:
> set data line <wait> assert clock <wait> deassert clok <wait> next bit....
>
> 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.
In TX we trust!
>
> > > I'm a bit biased as I'm working on a USB PIC (well, doesn't just have
> > > to be PICs) programmer. It will likely be just one PIC18F2550 or
> > > '2455 with some fairly simple external parts--transistors, resistors,
> > > caps, and diodes. Mostly junk box variety parts. If you squint your
> > > eyes *real hard*, it may look like a Wisp628, but that would be a bit
> > > of an illusion.
> >
> > This sounds cool.
> > What you describe, I was wondering if something like that existed.
> > If I have to go the "intelligent" programmer route, this would be the
> > best alternative.
>
> The thing that I feel makes it a good solution is that the programmer
> isn't all that 'intelligent'. I really want to resist the temptation
> to make it really 'intelligent'. For that way lies specialization
> and that doesn't buy me--as a programmer--much. Sure, if I was making
> some very specific tool for quickly programming chips and it had to
> do it as fast as possible, sure. But for a hobbiest or more casual
> professional designer, a few seconds is no huge issue. Especially if
> it ends up being able to program more chips. :)
>
> > I've actually thought about this myself, but, as I said in my other
> > post, its a matter of time. It takes time to develop and to maintain.
>
> 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?
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.
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.
BAJ
