Serial link via MAX3232 IC?
parts-man73
Posts: 830
A question about making a serial port programming adapter. Would it be possible to use a MAX3232 chip instead of the transister network called for in the diagram refered to many times in this forum? This chip is functionally the same as the MAX232, it converts serial port level signals to TTL level signals. The "3232" version of the IC can be run at 3.3 volts.
One other related questions. Is the serial data Rx/Tx (P30,P31) inverted or non-inverted?
Thank you,
Brian
One other related questions. Is the serial data Rx/Tx (P30,P31) inverted or non-inverted?
Thank you,
Brian
Comments
The logic levels are TRUE, not inverted like the signals on the DB9.
You must make the low-pulse generator for positively-transitioning DTR. To do this, take the DTR signal from the·MAX chip·and couple it to the base of an NPN via a 10nf cap. Tie the NPN base via a 10k resistor to ground. Tie the NPN emitter directly to ground. The NPN collector must connect to the RESn pin on the Propeller chip. This way, when DTR goes from low to high, RESn will be pulsed low briefly to generate a reset.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
When you say "take the DTR signal from the MAX chip", I assume you mean the inverted signal from the level-translated side, right? Could it be inferred from your circuit description, then, that it doesn't matter which DTR edge triggers the reset? The reason I ask is that the transistor reset circuit you describe above is identical in function to the one shown here (http://forums.parallax.com/showthread.php?p=581926, lower schematic) without the intervening MAX3232 inverter (and which works well, in my experience). Your circuit triggers on DTR high-to-low (i.e. nDTR from the MAX chip going low-to-high), whereas the other circuit triggers directly from DTR going low-to-high. If the IDE sends a short pulse on DTR to effect the reset, both circuits should work equally well. But I just wanted to make absolutely sure, since I've got a board design that uses the circuit from the other thread.
Thanks,
Phil
Post Edited (Phil Pilgrim (PhiPi)) : 4/15/2006 7:17:07 AM GMT
Yes, I meant the level-translated DTR signal, not the raw one. Taking the raw DTR signal through the same circuit may work, but it could be unreliable. The reason for this is that the host-side software times itself from the (level-translated) DTR rising edge before talking to the Propeller. The Propeller takes ~50ms to begin executing the boot routine after a reset, then there is an additional ~50ms-to-center sweet spot where it is possible to talk to the Propeller before it tries to boot from the EEPROM. The PC software 'SET's DTR for 25ms·before 'CLR'ing DTR, resulting in the reset. So, opposite-edge triggering (by using the raw DTR signal), will cause the timing to be 25ms late. This could result in failure, especially at temperature extremes where the chip's internal oscillator speed is affected. Also, if DTR was already in the 'CLR' state, no reset pulse would be generated, at all. It may be possible to reduce the 25ms 'SET' to 1ms. Then, it won't matter any more because the important edge will be very close to the ~100ms sweet spot. We'll have to add an extra DTR transition in there, too, to make sure it fires.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey) : 4/15/2006 8:54:45 AM GMT
If the Propeller is connected to the Stamp IDE via the USB-clip, nothing happens when you check the box (DB9 DTR goes from low to high), but the Propeller resets when you uncheck the box (DB9 DTR goes high to low, and DTR\ seen by Propeller reset goes low to high.) Propeller is opposite of the Stamp in that respect, because on the Stamp, the capacitor is connected directly from DB9 DTR to the transistor circuit.
I'm used to the following situation. Most terminal programs (e.g. Hyperterminal), bring DTR to a high level when they start. On the Stamp that causes a reset, and I use that as a signal for the Stamp to enter a Menu mode. I have the DTR line indirectly connected to another Stamp pin, which uses the high level there to sort out whether the reset came from the COM line or from another source (reset button).
On the Propeller, throught the normal connection, a reset does not occur when you start up Hyperterminal, but a reset does occur when you disconnect. That negates the "Menu on connect" strategy. and it is disconcerting to have it reset when disconnecting. The Propeller of course has a lot more options for testing the state of the serial port, but those take extra protocol. So in my own systems I might opt for reset on the leading edge of DTR. If I understand you correctly, Chip, proper centering would be restored if a 25 millisecond delay is imposed after the rising edge of DB9-DTR?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
In light of your comments, I wonder if the transistor-only reset circuit might better be designed as a follower. (See attached schematic.) One caveat, but I don't think it matters: The reset pin can be pulled slightly negative (as the attached scope trace shows) — limited, I believe, by the forward voltage of the transistor's base-collector junction.
I guess any necessity for such a change depends on your commitment (or not) to the IDE download routine changes that you proposed above. On the other hand, I've noticed from my experiments that the DTR pulse width varies quite a bit. I'm guessing it's being bit-banged by the IDE, and I wonder if the software has enough control over the port to produce a pulse as narrow as 1mS reliably.
Thanks,
Phil
Addendum: Now, having read Tracy's comments, I'm beginning to doubt that the follower circuit is the right way to go...
Post Edited (Phil Pilgrim (PhiPi)) : 4/15/2006 6:25:27 PM GMT
Yes, it's hard to control timing on the order of milliseconds on the PC. Even though our software tries to generate an accurate pulse, it gets pre-empted and who-knows-what-else by Windows. On the latest Propeller.exe, Jeff switched over to the 'high performance timers' in Windows, instead of the regular (perhaps 'tick' based timer). This will be released soon. I'll try to get Jeff to comment on the observed performance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Is the reset pin pulled up with a resistive element or a constant-current source? What are the parameters (in ohms or microamps)?
Thanks,
Phil
Chip Gracey
Parallax, Inc.
The way the FT232RQ is set up, it produces that ~25 millisecond long 1->0->1 pulse. On the trailing, 0->1 edge it couples into the transistor base via 10nf/10k, which generates a 1-0-1 reset pulse approximately 100 microseconds long at the collector of the transistor, which is pulled up by the 5k pullup inside the propeller chip.
Now, suppose for some reason I want to reset on the leading edge instead of the trailing edge. For exampie, I want Propeller to reset when it is "connect now" in a terminal program like HTPE. I have to construct a modified clip that generates the inverted pulse, or couple directly to the transistor circuit from DB9-DTR (like the Stamp). However, like you have warned, if I then try to use my modified clip to program the propeller, the pulse from the IDE will be 25 milliseconds too early. So, I could compensate in my special clip, most easily, by stretching out the pulse in the inverter transistor, so that instead of being 100 microseconds long, it is roughly 25 milliseconds long. That would roughly compensate for time lag. Not exactly, because as has been noted, the 25 milliseconds is nowhere near exact, and an RC delay in the transistor would be nowhere near exact either. But is sounds like the Propeller has a +/- 50 milliscond window to hit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Another option is simply to DC-couple the common-emitter inverter. That way the Propeller will be in reset the entire width of the DTR pulse. The only thing that matters, timing-wise, is when it comes out of reset, and with DC-coupling, that will happen at the right moment. Of course, that'll be a problem for those terminal programs that insist on keeping DTR high. But those are going to be trouble for the transistor level-shifting circuit anyway, since the bias resistor from DTR to TxOUT will also be pulled high, making low excursions on TxOUT impossible.
I'm a little perplexed over why, with the free availability of the excellent PBASIC Debug screen, anyone would use HyperTerminal anyway. It's got to be the worst piece-of-Smile, user-unfriendly terminal program ever conceived!
-Phil
One thing we've been thinking about since the early SX days was to add GRAPHICAL debug windows. For the Propeller, we could make data-driven oscilloscopes, XY scopes, raster imagers, and all kinds of stuff. The Propeller Clip (or the FTDI chip, I should say) can handle 3MBPS serial. This is nice throughput for camera-type data, audio, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Chip, that makes my day! I was hoping you guys would do something like that, and the graphical stuff would be the icing on the cake. As much as I like the PBASIC Debug screen, having that capability integrated into the IDE makes it even sweeter. Thanks!
-Phil
-Phil
If I understand your query as to why some folks would want to use the Windows Hyterterminal program, it's often done for (optional) data capture directly to a PC data file, and not necessarily for direct display.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
1) It can capture capture text into a file, which is something the Stamp IDE can't at present do. Graphical Debug windows would be great too!
2) HTPE is resident without asking on practically every PC out there, back into the stone ages. It is KISS. Not everyone who hooks up to Propeller is going to be using an IDE. I'm thinking about my customers, or my customers' customers or field techs. I know the Propeller can support its own video display and keyboard, but for many applications the easiest way to configure it in an application setting will be with a PC through the pin a30/a31 serial/USB port. There are a lot of other terminal programs out there, and AFAIK they bring DTR high automatically when they connect. Sure, you could write a custom VB terminal program or application specific program, but it is always good to have good ol' HTPE avaialble in a pinch.
If I understand your DC coupled scheme correctly, Phil, when you connect that to HTPE or any other standard comms program, it will hold Propeller in reset so long as it is connected. Yikes.
It is not a big deal to do it with the reset at the trailing edge of the DTR pulse. The Propeller, unlike the Stamp, can continuously monitor the TX line for incoming activity, and wake up on that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 4/16/2006 5:03:23 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey) : 4/16/2006 6:06:45 AM GMT
Here's my dilemma: In order for the Propeller just to be able to transmit using the transistorized RS232 converter, DTR has to be low anyway, to pull /TxD negative when it's not being driven high. (This bias connection is made to /RxD on the Stamp boards, which works fine, since the Stamp can't do full duplex.) On the one hand, it might appear that the transistorized RS232 interface being flogged in that other thread needs to be reconsidered in its entirety. On the other hand, I see a simple, elegant hardware design being mooted by the ubiquity of ill-conceived legacy terminal programs that provide no (and I've checked this) negative handhake signals or any means to control them.
I could bias /TxD to ground instead of a negative voltage, and it would probably work with 90% of the PCs out there. (Mine even works with 0-to-3.3V signals.) But there's no guarantee that it would work on all of them.
The other option is to add a diode and storage cap to /RxD, to maintain a negative bias on /TxD when /RxD makes positive excursions. But this only works effectively with ICs like the DS276 that don't draw on the cap when /TxD is high. I would like to have used the DS276. I've used it in the past and have had great success with it. But ever since Maxim bought Dallas Semiconductor, I haven't been comfortable with the availability (or lack thereof) of Dallas's parts. That leaves the multiple-sourced MAX232 family, which seems like overkill for this app, but may provide the only relief.
So that's where things stand right now. I'm not terribly happy about it, but I guess I'll find a way to deal with it.
-Phil
P.S. Really? You've seen worse than HyperTerminal??
I don't think Microsoft ever really "got" RS232. From the DOS days forward, I've had to rely on third-party programs for reliable comms. These have included the BitCom and QModem terminal programs, and the MID interrupt-driven serial driver. I still have issues with their Windows serial drivers. What makes the situation particularly galling and hard to fathom is that it's not that hard to get it right! But it's like serial I/O was never a front-burner item with them — just something they tossed in at the last minute to say they had it.
-Phil
As easy as it might be to expect that Microsoft is the party responsible for Hyperterminal and all its horrors, another party is clearly responsible. If you check the program file properties, then look at the version, here is what you will find:
"HyperTerminal ® was developed by Hilgraeve, Inc. for Microsoft"
So, they are the guilty party!
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Before Parallax started adding the capacitors to the Stamp development boards and schematics, it was a perennial source of puzzlement: "Why is my Stamp dead, when I connect it to Hyperterminal". I'd hate to see the same issue arise again with Propeller. The issue will arise if the capacitor is left off, so I say, please keep it in there, even if it has to trigger on the trailing edge of DB9-DTR.
If you want to find crumb-bum serial programs, look at the current crop available for the Mac! GoSerial for exampe. zTerm is better, but still not good for control of scientific equipment. There is very little flexibilty or support for the hardware handshaking lines. On the PC, I used to use Procomm. But I've gotten adept and even fond of using Hyperterminal, despite its lack of Macro capability. The most galling thing is that it loses data if a laptop goes to sleep or Windows preempts for whatever. Once you have a setup file, it is easy to send that to other people as a starting point. (So who is going to write a Xmodem object for Propeller?!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I bit the bullet and put a MAX3232 on the board. That took care of the negative voltage issue. 'Went back to capacitive coupling using Chip's circuit, so the reset now occurs on the trailing edge of the DTR pulse. (But users can leave out the transistor inverter and one resistor, change the value of another resistor, and jumper the transistor's base and collector pads to get the reset on the leading edge.) 'Had to extend the board a quarter inch, bend the TO220 leads closer to the quick, and fold a couple resistors transistor-radio-style, but everything fits. It's been awhile since I've laid out a through-hole board. I'd forgotten how big that stuff is!
-Phil
I don't know if this helps in any way, but when I purchased vb6 pro, it comes with a sample terminal program written in vb6, which is (to me) much nicer than hyperterminal, but I'm not sure (off the top of my head) if it has the features you are speaking of.
I use it for setting up modems etc, and its a breeze compared to hyperterminal.
If you dont have it, I'd be happy to compile it and email it to you, or send the vb6 code so that you can then massage it a bit.
You could then perhaps modify it and add DTR controls as you wish. If that worked out, it could perhaps be made available as a basic program specially suited for comms with a prop.
Cheers, Chris.
Happy tinkering,
Brian