Subject:
Re: DIY USB programmer ?
From:
####@####.####
Date:
5 Jan 2005 14:50:29 +0000
Message-Id: <23008f22dbda.22dbda23008f@southeast.rr.com>
One could use 74C221 (monostable non-retriggerable multivibrator) instead of 555 and transistor setup. Should be easier to setup and lower the part count.
Sergey Dryga
----- Original Message -----
From: Byron A Jeff ####@####.####
Date: Wednesday, January 5, 2005 9:19 am
Subject: Re: DIY USB programmer ?
> 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
> parallelport 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
> collectorto 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
> triggerinput 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
> diodeshould 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
> seriesresistor 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
> activateprogramming 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
> floplike 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/serialconverters. 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
>
> -------------------------------------------------------------------
> --
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
