Subject:
Re: DIY USB programmer ?
From:
David Willmore ####@####.####
Date:
5 Jan 2005 17:13:19 +0000
Message-Id: <200501051713.j05HDH5Y018536@localhost.localdomain>
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? ;)
> > 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?
> > > 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.
> > 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? ;)
> As a matter of fact, I wondered if it would be possible to
> "parameterize" the burning protocols such that there wouldn't be any
> changes necessary in the burder-PIC itself.
That's close to what it does. It does lack a nano-sleep function,
so there are a lot of 'wait 1uS' sleeps around the code because
there is no way to express anything smaller. This doesn't matter
for a host based programmer which can't access the hardware registers
more often than that, anyway, but for a slart slave, that's not the
case. Still, that would only save a little time.
> And the new USB flash PICs would be a great way for this. I even have
> two 18F2550's here :)
:) Oww, looks like you just offered to be a tester. :)
> > To the computer, it will look like an USB->RS232 'dongle', so most
>
> This is even better. Excellent idea. I'm looking forward to your design.
> Will it be free/open source ?
With all of the work Craig, Alain, and Scott have done for all of us,
could I honestly *not* make it open?
> Please keep me posted on your programmer project.
Sure will. I should probably set up a mailing list for interested
people.
Cheers,
David
