Subject:
Re: DIY USB programmer ?
From:
Byron A Jeff ####@####.####
Date:
5 Jan 2005 17:09:17 +0000
Message-Id: <20050105170906.GB14720@cleon.cc.gatech.edu>
On Wed, Jan 05, 2005 at 05:29:31PM +0100, ####@####.#### wrote:
[Snippage...]
> > > The problem here is the timing. USB can't guarantee the timings as far
> > > as I understand.
> >
> > What timings?
> Multibyte timings, if programming multible bytes at the same time using a
> paging algorithm, there exist a timeout between the single bytes. Most
> programming sw using this in order to program the device in minor time. In
> bit bang mode, the timing for a ftdi chip is 2ms for a single port write and
> 1ms for streamed port writes. So trasmitting one word equals to 25 ms or 50
> ms, if some signaling issues exists, like caps, or other induction type
> interface, that compromites the 80ns rise time. The new ftdi232C have a
> internal ms... engine for i2c/spi/jtag/icsp/... trasmission. Using it, full
> speed programming is possible. The advantage of the bitbang modus is the
> possibility to use spare pins on the ftdi chip and connect it to the other hw
> without requiring jumpers. If the cpu can program itself, then burning a
> 100-250 bytes bootloader on it, and then using the hw rs232 port to download
> the program. Using the external timed programming algorithm (sw programming
> or low voltage programming), then it's possible the device in 3-4 seconds,
> including the bootloader programming and using the bitbang modus without the
> ms... jtag engine. The ftdi232C have two serial ports or one serial and on
> parallel, and it's possible to reserve one for the firmware update without
> need of rerouting the signals or needs for dedicated programming pins on the
> MCU.
I don't think speed is an issue. For the project the OP proposed, you'll only
burn once. So it doesn't matter if it takes a minute or two.
My concern is the cost and availablity of the parts to pull it off. FTDI parts
are not cheap, not easily available, and are not easily usable from a
prototyping/breadboarding perspective. So I tabled them because that's zero
for three.
[More snippage.]
> > 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
> The serial port has at minimum two input and two output signals, with direct
> sw control (rts/cts/dtr). This works reliable, ie, and don't are asynchronus
> betweend the two outputs and two inputs. This works mutch faster then the
> bit bang modus. Unfortunatly, this pins can be used by the sw, and so extra
> hw care must be taken. On bitbang modus, one can use the input pins for
> output the clock and data line. This eliminates mostly the needs of adding
> additionally hw protections, if the pins are used for other purposed and are
> not reserved.
Exactly how does one control the modem control signals on a virtual serial
port that is implemented via USB. I've already taken a look at a couple of
the ioctl in the Linux serial USB drivers. Many simply don't implement
the direct manipulation of the modem control signals.
>
> > 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.
> Using the TX/RX lines on a usb converter is not reliable as oppesed to the
> pc.
> In most case, the tx/rx and the dsr/cts samples are asynchronous and don't
> follow
> the rules as to the PC.
I know. that's why I proposed not using the modem control signals at all.
> You should use the other lines .
> This works pretty good.
There are no guarantees on how to manipulate the modem control signals. There
are also no guarantees of the latency or the relationship between the signals.
Flat out I don't trust them.
[Snippage of the 555 non-retriggerable explanation.]
> If a max232/max202 is present, then the 10v output can be used to put the
> flash device in high voltage programming mode. 9.2v is sufficient for
> activate the HVP. But only the maxim and the ex..., i don't remember exactly
> the replacement company, have parts, that have approximative 9.5V. The other
> manufacture uses diodes and not analog switches for the voltage double and
> don't reach the required voltages. And don't use the TX/RX pins. Even if
> there are handy, the hw layout requires jumpers, or relays or separate
> cables. Using the other pins, it's possible to use one or two jumpers
> connecting the high voltage using a standard serial cable. I use a modified
> version of odyssey that use the serial port instead of the parallel one, and
> program the part without the tx/rx lines. Normally the tx/rx lines is routed
> to the rx/tx hw module on the pic. And cheap usb to rs232 converter for less
> then 10 Euro exists. The new 18f parts can reprogram the option location in
> low power programming mode, so using the 18f parts without voltage doubler is
> possible, annother possibility is to connect a dry 12V or a new 9V battery to
> the reset pins with only one resistor to protect the port, in the case the
> reset pin is set as output without startup delay, this for the 10f-16f
> parts.
I think you have a skewed vision of the purpose of the project. From my
reading from the OP this is a single use standalone programmer for a
flight simulator console. It's not an ICSP programmer for general use.
It's a one shot one off programmer.
So it doesn't matter how RX and TX are connected. Jumpers and the like are
not relavent. Neither is the voltage doubler, a 9V battery as you propose
should be fine for a one off. Reason being is that you can use the one off
programmer to dump a bootloader into the chip, then you don't need a programmer
anymore.
The goals are to keep it dumb, simple, and cheap with easily available parts.
And nothing is dumber, simpler, cheaper, or more available than a 555 timer,
along with a handful of resistors, transistors, caps, and diodes.
BAJ
