Subject:
Re: DIY USB programmer ?
From:
Byron A Jeff ####@####.####
Date:
5 Jan 2005 14:19:25 +0000
Message-Id: <20050105141915.GA368@cleon.cc.gatech.edu>
On Tue, Jan 04, 2005 at 06:39:41PM +0100, Manuel Bessler wrote:
> Hi all,
>
> I'm looking for a simple DIY design for a USB-based PIC programmer.
> (ok that part is easy)
> ... BUT ... if at all possible such a burner should not require a PIC
> itself. (the chicken and egg problem :( )
A problem that's as old as time itself.
>
> I have a PIC based Project (called the PIC HomeCockpit Controller, PHCC.
> Its for the flightsim people who want to build a cockpit at home).
>
> Now, most folks who build PHCC don't have a PIC programmer at home, so
> they need to buy or build one. Of course, the cheaper the better.
> But due to the demise of parallel port and serial port, the common types
> (JDM, Tait, BAJ) can't be used.
> Most new computers only have USB, but no "legacy ports".
I take issue with that statement. While of course PCs are trending to having
between 6 and 8 USB ports, every one that I have seen in recent memory have
had at least one parallel and one serial port.
>
> I've been wondering if it is possible to build a programmer based on the
> FTDI FT232BM or FT245BM chips.
Of course. But now you're back to the same issue. By the time you've put
together a board with these, you've spent way more than the cost of a
simple PIC programmer anyway. And the task of soldering surface mount parts
is daunting at best.
Also only the FT245 really makes sense because it presents a parallel
interface. The FT232 fundamentally gives you nothing more than a USB to
RS232 cable, which we've already seen gives you a complete interface for
about $10 USD.
>
> The problem here is the timing. USB can't guarantee the timings as far
> as I understand.
What timings?
>
> 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 ?
Would what be possible? Programming PICs is a static activity. If you had
debounced switches, you could program a PIC by hand.
>
> 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.
Yes. But you'll still have issues.
Let's table the FT parts for now and discuss the only sensible solution: a
USB to serial converter cable. They are cheap, complete, readily available,
and presents a standard interface without having to introduce any additional
drivers AFAICT.
The crux of the problem is that RS232 is a asyncronous interface. So there
is no clock signal that can easily be extracted from the transmitted signal.
Also I don't think it's possible to make any guarantees from the modem
signals (DTR, RTS, CTS, RI and the like). This is unfortunate because if
control and timing of those signals relative to the TX line could be
guaranteed, then a simple programmer could be built using little more than a
USB/serial converter cable and a MAX232. The DTR line could then be connected
to the PIC program data line and TX connected to the program clock line.
To program you'd set DTR to the appropriate bit then send a 0xff to clock
the data. You could also route back the PIC data line to DSR or CTS to
read back the data from the PIC. It would be a serial analog of my parallel
port based Trivial PIC programmer.
But as I said there are no guarantees of the relationship of the modem
control signals to TX. So you can't be sure that you can set/reset the modem
control signals. You also cannot be sure that if you can set/reset the modem
control signal that those changes would be in place before you clock TX.
So the only thing that you can guarantee is the TX signal. Fortunately there
are some guarantees there. Because of the async interface you know that
you'll get really precise timing at any particular bit rate. So you'll have
exact timings relative to the falling edge of the start bit.
So the simplest TX only programmer will require an external one shot to
clock in the data bit at some time relative to the falling edge of the start
bit.
This is when you trot in the venerable 555 timer. The problem with it is
that it needs to be non-retriggerable. A 5 minute Google search came up
with the interesting idea of using an NPN transistor as the gate. Let me
see if I can describe it:
1. Wire up the 555 in traditional one shot mode. There are a trillion
examples of this so I won't describe any further.
2. Add a NPN transistor to the trigger input of the 555. Wire the collector
to the trigger input (with a pullup resistor), the emitter to the 555 output,
and the base (with a suitable series resistor) as the new trigger input.
Here's how it works. The 555 trigger is active low and the 555 output is
active high. The transistor acts as an inverter so the base is now an
active high trigger. So if we start from the idle state where the trigger
input to the base is low and the output is low, the transistor is off and
the 555 trigger is pulled up by the pullup resistor.
Now you trigger the circuit by raising the base. The transistor turns on
pulling the 555 trigger low, this triggers the 555, which raises the output
high. So far so good.
But remember that the emitter of the transistor is connected to the output
of the 555. So when the output goes high it brings the emitter high too.
Since there is no longer a voltage differential between the emitter and the
base, the transistor turns off and the pullup pulls the trigger high again.
And as long as the output of the 555 is high, that trigger cannot be pulled
low. So you in theory can wiggle the base input as much as you like and it
won't affect the timing of the 555.
The only question is there any issue in terms of reverse breakdown of the
transistor if the base is negative relative to the emitter? If there is
an issue it possible to tie a reversed biased diode between the base and
the emitter right? A quick look at a 2N2222 datasheet shows a emitter-base
voltage of 6V. So presuming that we're working in a 5V system, no diode
should be necessary.
So if it all works there may be a winner here:
1. Use the 555 one shot output as the program clock for the PIC. There is no
need to invert the signal as the bit is latched on the falling edge of the
clock.
2. Since the new trigger is active high and with RS-232 the leading edge of
the start bit is a transition from 1 (-12V) to 0 (12V) (i.e. a rising edge)
you don't need to invert the TX signal, just condition it with a series
resistor and a 4.7V or 5.1V zener. The output of that junction goes to the
PIC program data PIC too in addition to the base of the trigger. Even better
in the idle state both the clock and data pins to the PIC are low, so you can
simply wire a switch from 13V to MCLR with a pulldown resistor to activate
programming mode.
3. Now you tune the 555 delay to about 1/2 a character transmit time. This
should be doable without any fancy equipment if you test with flip flop
like the 74HCT74. Simply tie the transistor base to the D input of the FF
and tie the output of the 555 to the clock (you may need to invert
the signal). Then tune the delay resistor until when you send a 0x00 down
the serial port you get one bit and when you send 0xff down the port you
get the other bit.
And that's it: a trivial serial PIC bootloader programmer that only uses the
TX line and a handful of cheap plentiful components. And it should work with
any USB to serial converter.
Now it won't be fast. Presuming that you tune to something like 4800 or 2400
BPS, it'll take awhile to program. To give you an idea Wouter's ZPL takes 70
seconds to fill a 8K 18F part using the same technique. But it's really a one
shot as you'll use it to program in a serial bootloader into the PIC and then
the PIC can program itself directly from then on.
The idea isn't new. As I said Wouter uses almost the exact same technique to
implement his Zero Pin Programmer for the 18F series measuring the length of
a transmitted character cell to transmit a bit. Also I'm sure that I've seen
using a 555 to extract clock information from a serial stream somewhere or
another.
But it fits the bill exactly. Requires no intelligence. Works with any serial
port. Doesn't require any modem control signals. Works with USB/serial
converters. Uses cheap and plentiful parts. Finally I'm pretty sure that
Wouter's ZPL Python software could be easily adapted into a programming base
for the setup, so you wouldn't have to start writing the programming software
from scratch.
Hope this helps. It's interesting enough that I think I may take an hour
today to breadboard and do some tests.
BAJ
