3-Wire (TX/RX/0V) Serial Programming

hippy

This interface allows downloading / programming of a Propeller Chip using just a three wire serial interface; TX, RX, 0V. Handy for programming from PDA's, other micro's or in any case where additional handshaking isn't desired or easy to support. It should also avoid most Propeller resetting when serial ports are opened or closed.

This interface does not work with the Parallax Propeller Tool but can be used with third-party downloaders which can generate a 'break'. It's easy enough to generate 'break' and DTR so there doesn't even need to be any user configuration.

It uses an RC delay circuit to pull the Propeller /Reset low after a 'break' has been asserted on the TX from PC line for a long enough period. Normal serial transmissions will not trigger a reset. The diode to /Reset makes it effectively open-collector and prevents damage from any Reset Button on the Propeller board being pressed or /Reset otherwise being pulled low.

The TX to PC line is gated with the /Reset drive so the PC can determine when /Reset has been activated ( avoids guessing what the actual RC time is ). That gate input can be tied to 3V3 if preferred.

The diode around R1 and the gating for /Reset gives a ( hopefully ) fast and clean release of /Reset.

The circuit works for me but comes with no guarantees whatsoever. Use at your own risk etc etc. The circuit can certainly be improved upon ( I'm no electronics engineer ) ...

I used 74HC00 as that's what I had. Schmitt trigger gates would be preferable.

The serial interface is not RS232C compliant, but appears to be tolerant of +/-12V input from the PC. Should also work with laptop/USB 0V/5V signals.

The TX to PC is 0V/3V3. May be too low for some host serial interfaces. I powered the gates from the Propeller 3V3, they could be powered by 5V, the 1K on TX to Propeller should be enough to protect the I/O pin, the 0V/3V3 should be enough to switch the TX to PC buffer.

The RC time ( how long 'break' must be asserted for ), the 10K and 100uF, can be adjusted for a much shorter delay than what it currently requires.

The unit could be self-powered. A pull-up on the Rx from Propeller line would stop it being a floating line and prevent random data to the PC when disconnected from the Propeller board.

Minor modification ( for TX to Propeller ) should allow it to work in parallel with a PropPlug / Propclip or USB2SER interface.

Post Edited (hippy) : 12/12/2007 3:01:29 PM GMT

Rayman

I like the idea of using logic instead of xistors! I was just looking into how many mA I can leach of the unused handshaking signals...
But, I'd like something that works with the Prop tool. Do you have a similar circuit that is compatible with it?

hippy

I tend not to use transistors either

I've never understood the capacitor used in the usually cited two-transistor circuit for reset as it seems to me it's simply a case of either letting /Reset float high or pulling it low. Maybe my lack of knowledge means I'm missing something.

Attached is how I'd expect it to make it work using DTR for the Propeller Tool, but it may need another inversion after the DTR buffer. Just cut 'n' paste hacking, so not tested ...

kittmaster

Does this help for RS-232?

hippy

Not 100% as the MAX232 inverts so one ends up with a double inversion through the U1A and U1B gates. One can also lose R3, R4, R5, D3 and D4 as they are only there to make the inputs +/-12V tolerant. But it's in the right ball-park.

Out of interest; what have you used for your schematic ? I used Eagle and it looks quite poor quality in comparison.

Rayman

I just got some ADM3202, similar except takes 3.3 Vdd...· I was thinking I could connect directly to the Prop...

Phil Pilgrim (PhiPi)

Hippy,

You've answered one of my perpetually unasked questions: "Where do all those brown and green schematics that I see on the forum come from?"

-Phil

Joerg

If brown and red lines are disturbing: export the images in eagle
with the monochrome option selected and you may improve the quality
by simply set the resolution to 200 or more BPI!

Saluti Joerg

kittmaster

I am using Multisim to generate the schematic.

I retool it with the changes and repost it. Hopefully it will help someone out............um...........like me........[noparse];)[/noparse]

How confident do you feel on the design? I was thinking about integrating it into my design.

Peter Jakacki

While we are on the subject of serial programming this is the method that I use based upon a cheap $1 8-pin processor.

This circuit detects breaks or more correctly the end of the break and generates a reset which is useful for remote error recovery but can also be used for programming.

The programming control cpu also monitors the receive line for special command sequences so that I can reset, hold in reset and load the eeprom etc.

Well worth the $1 I spend plus it is only one small component. The programmer is a simple LM358 opamp along with +12V that is easy to burn from any micro with 3 or 4 I/O.

BTW, you might notice my circuit is setup for RS-422 but by the judicious use of a resistor (and no terminator) I can use the circuit in unbalanced mode to talk directly to RS-232 ports.

*Peter*

kittmaster

Peter Jakacki

Kittmaster, your circuit would put the prop into reset when the line idles high (inactive state). Remove U1C so that the RC circuit starts to charge when the logic level receive line goes low.
You could probably replace D2 with a 1K resistor or even omit the resistor and just connect directly if you have nothing else driving the reset.

*Peter*

hippy

@ Peter : I was wondering about a simple PICmicro, especially as it
could potentially handle the inversion of TX and RX. That would get
a whole serial interface down to just one 8-pin PICmicro and a couple
of resistors. Sampling at 8MHz ( 2MIPS ) and counting highs for 'break'
might be a bit tight; 8.7uS per bit at 115200.

Just doing break detect, it saves the discretes needed to do the timing.
Neat idea about handling serial commands.

With some multi-dropping and the right downloader you could give each
an ID and program multiple Propellers from a single line. That's handy
for anyone thinking of "Propeller Super Computing".

@ Kittmaster : I'd recommend bread-boarding first. The RC time is
currently quite long ( around 4s ) and I'd shorten it myself. I would
also go with Schmitts, and ...

@ Peter, on polarity. You're right, I messed up; U1C should be
removed. One inversion too many.

Post Edited (hippy) : 12/13/2007 1:25:10 AM GMT

hippy

A thought ... If there's a PICmicro in there, why not have it receive
8-bit byte at a time Propeller image, convert that to the 1T/ 2T the
Propeller wants ( simply pass through responses inverted ). Using
115200 that would cut the time of a full 32KB download to just 3s.
Most would be in the blink of an eye. Not sure what the minimum
spec is for download bit timing but I believe it's faster than 115200.

Peter Jakacki

The PIC is a little slow using it's internal oscillator and I just use a simple bit-bashed receive routine at 19,200 baud.
There is also the C8051F301 from Silabs which I have used that runs at 25MIPS on it's internal oscillator and includes a UART, all in a 3x3mm pack!

Ideally, the prop boot code would handle inverted coms but alas that is not the case. It is possible to include a PIC in the PC end to detect the
DTR transition and generate a break I guess, that way it would be compatible with the prop tool.

As you can see from my circuit I am not adverse to handling RS-232 with alternative circuits, even RS-422 as it is one simple little 8-pin chip and no caps are required.
One advantage I have in using RS-422 drivers for RS-232 is that I can communicate over really long lines from the PC if I include an RS-422 driver at the PC end.

All this plus and minus 9 volts nonsense for simple serial communications is a real throwback to the 1960s. I have never ever had any problems talking to PCs with
low voltage signals straight from logic circuits. I only include RS-232 drivers in commercial products because I have to for "compliance" reasons.

I like your idea of using the PIC to invert the data for the prop although it means that the PIC has to sit in a tight loop echoing the inverse of both the lines and maybe
just it will work. If it were doing that then there is no way to get it to detect a break other than by using it's internal watchdog timeout to reset the PIC and thereby the prop.
Or perhaps it might wait for a break and then reset the prop and wait in that tight echo invert loop for the first second or so before it drops back to the break/command loop.

It is also possible to couple the DTR via a cap to the PC's receive line. Huh? Why? Well if we resistively couple the transmit back to the PC at the prop end we can detect an
override pulse on that line caused by the DTR and react accordingly. Cool?

I think I'll have to play with these ideas.


*Peter*

Chad George

Here's a thought (don't know if its a good one, but...)

What if instead of trying to program the prop in the "serial" (1T/2T) mode, we program the prop in the EEPROM boot mode.
Wouldn't it be possible to program some PIC (to its ram) that emulates an I2C eeprom. It seems like a system could be
constructed that can work with both the prop tool and a faster bootloader (serial only and even wireless) as well.

It seems like the propeller reads the EEPROM a whole lot faster than it loads 32K to RAM from the Prop Tool.

-Chad

Chad George

One other thought.

I once wrote an application that acted like a propeller being programmed from the Prop Tool.
This way I was able to press F10/F11 and my program responded on a loop back virtual serial port like a valid Propeller device.
Then the Prop Tool happily sends the compiled program.

In my app, I send it over a wireless network to a PC on the robot which was attached to the real prop and used the
python loader, but...

Maybe this might be helpful too with a custom (real serial) bootloader.

It was quite a while ago, but as I recall the only thing I didn't like was how I made the loop back device.
If someone as a better (free) utility for doing this I'd be interested in getting it working again.

My goal would be to be able to program a propeller wirelessly directly from the Propeller Tool.

Of course as others have mentioned before, this could be made simple for us if the Prop Tool saves a .binary or .eeprom to the
working directory every time it compiles. Along with limiting the serial ports scanned [noparse]:)[/noparse] I know Chips very busy. I'll wait patiently.


Chad