View Full Version : Serial I/O w/ FC not working properly

01-16-2007, 03:24 AM
Gentlemen -

I've used the BS2 off and on for literally dozens of projects over the past several years, always able to figure things out for myself without harassing others in these forums (in fact, I've never even used these forums, but happen to be exceptionally thankful for them on this particular day). I've encountered a bit of a problem that has me puzzled.

I've a BS2 circuit attached at one end to my PC using SOUT, SIN, ATN and VSS lines. VIN and VSS on the right side of the chip are connected. The chip powers and works fine.

On Pins p8, p9, p10 and p11, a Male DB9 is connected as outlined in the diagram. The Signal Ground from the DB9 ties back to the VSS of the power source on the right just below VIN.

I am attempting to empower the·BS2 to communicate with an automation controller which uses DTR handshaking. I've written a simple VB6 application which communicates with the controller flawlessly, proving that my cable works fine. The cable itself carries only pins 1 through 5; pins 6 and 7 perform a loopback at each end of the cable.

To further test the cable (as well as my BS2 code), I am able to communicate through the BS2 to a secondary PC using a similar VB6 application. In the VB6 app, DTR handshaking is enabled. The data seems to flow smoothly from the stamp to the PC both with and without use of the flow control function on P11.

So we've established that (A) the cable is fine, since it works both from PC to automation controller AND from Stamp to PC using DTR handshaking, (B) the stamp code at least SHOULD be working fine since it talks from the stamp to PC both with and without DTR handshaking in the code, and (C) the wiring of the circuit appears to be fine, given that the stamp circuit communicates at all.

When connected to the automation controller, however, the automation controller does not respond when the data stream is transmitted (as it does when the same stream is transmitted from the VB6 app on the PC). I know it's got to be a flow control issue, but I'm pulling my hair out and thus far have been unable to resolve it. I do not have the ability to disable DTR handshaking on the automation controller itself.

I've tried OUTing P8 high (the CD line) just on the off-chance the automation controller requires a signal on the CD pin. The automation controller seems indifferent.

Bright ideas would be VERY welcome right about now. Thanks in advance for any assistance you might be able to offer.

progjh@yahoo.com (mailto:progjh@yahoo.com)

Mike Green
01-16-2007, 03:49 AM
You may damage the BS2 with the secondary PC connection. The Stamp has special circuitry on the programming pins that converts the signal levels (RS232) to the voltages used by the Stamp (TTL). You need something similar on the other connection. You can use a MAX232 or equivalent or the same kind of discrete (transistor and resistor) circuitry used on the Stamp (see the Stamp schematics and the descriptions for the SERIN/SEROUT statements in the PBasic manual for details).

Post Edited (Mike Green) : 1/15/2007 8:56:19 PM GMT

01-16-2007, 04:19 AM
I've attached DB9 pins to BS2's in this manner for years (and literally hundreds of units) without a problem... and can't think of even one case where the BS2 has been damaged as a result. They've always been stable and performed predictably and reliably, and it's because of this quick, easy interface through the use of SERIN and SEROUT that I've used the BS2 for such a wide array of projects.

Bear in mind the serial port is *not* a secondary PC connection. This is the serial port interface to an automation controller which will be driven by the BS2 (although it's basically the same thing as a PC, for all practical intents and purposes).

It's possible, I suppose, that the signal level to voltage conversion is not throwing the proper value for Flow Control to operate properly... although why it talks to a PC (with a simple communications emulator simulating the automation controller) and not to the automation controller itself is still beyond me.

Mike Green
01-16-2007, 04:26 AM
Maybe, but I'm assuming the automation controller port is RS232. Many RS232 input circuits will work with the 0 to +5V range output by the Stamp, but some will not. The Stamp will "survive" many RS232 output circuits, but it's not intended to work without at least a current limiting resistor (the 22K one mentioned in the PBasic manual). If the automation controller is a "stickler" for proper RS232 signals, it may not be responding to the Stamp's outputs and, without a current limiting resistor, may indeed damage the Stamp's input pins.


01-16-2007, 04:39 AM
Hey, I'm game to insert the resistor if that's what it takes to eliminate another possible cause for the problem! It won't be the first change I've made in an attempt to eliminate this pesky problem with this particular interface. ;o)

Will let you know if this turns out to be the source of the problem...

Chris Savage
01-16-2007, 04:44 AM

If you’re talking to an RS-232 device there’s one more thing to consider besides the fact that the signals are different voltages than TTL. They are also inverted. So when you’re sending serial data out to the device are you using inverted or non-inverted baud mode?

Chris Savage
Parallax Tech Support

Mike Green
01-16-2007, 04:48 AM
I would suggest getting (or making) one of the little RS232 jumper boxes with LEDs on it that have a 9 pin serial connection on each end (one male and one female) and a little breadboard-like gadget in the middle with pin sockets connected to each of the 9 pins and bi-color LEDs with series resistors connected from ground to each of the signal pins. This way, you can experiment with the PC to automation controller connection that works and see what flow control signals are actually needed by the controller (and supplied by the PC). You should also have a minimal test program for the Stamp if you don't already have it that would supply the minimal signalling for the automation controller to test whether the connection works (and experiment with the jumper box to see what is actually getting to (and from) the automation controller.

01-16-2007, 04:56 AM
Chris -

Signal is definitively inverted - see the code below.

For any interested parties, this project will mate a wireless modem through the BS2 (or possible SX - still examining options) to the automation controller, enabling us to interface to the automation controller in the field from a web site accessible through a web browser.

The circuit will take inbound keystrokes over a wireless modem and send them through the stamp to the automation controller. Similarly, the BS2 will take terminal output from the automation controller, strip unnecessary air and provide simple compression, and transmit it through my wireless interface to my downlink server here for subsequent delivery through my web interface.

Code follows :

' {$STAMP BS2}
' {$PBASIC 2.5}

SI PIN 9 ' Serial input
SO PIN 10 'Serial output
FC PIN 11 ' Flow control pin

Inverted CON $4000
Open CON $8000
Baud CON 84 + Inverted
letter VAR Byte
inkbd VAR Byte

DEBUGIN STR inkbd\1 ' temporarily gather input from keybd
' later input will come from wireless modem
IF (inkbd = "*") THEN SEROUT SO, Baud, [1,114,0,16,160,15]
IF (inkbd = "1") THEN SEROUT SO, Baud,[1,114,0,1,96,3]
IF (inkbd = "2") THEN SEROUT SO, Baud,[1,114,0,2,32,2]
IF (inkbd = "3") THEN SEROUT SO, Baud,[1,114,0,3,225,194]
IF (inkbd = "4") THEN SEROUT SO, Baud,[1,114,0,4,160,0]
IF (inkbd = "5") THEN SEROUT SO, Baud,[1,114,0,5,97,192]
IF (inkbd = "6") THEN SEROUT SO, Baud,[1,114,0,6,33,193]
IF (inkbd = "7") THEN SEROUT SO, Baud,[1,114,0,7,224,1]
IF (inkbd = "8") THEN SEROUT SO, Baud,[1,114,0,8,160,5]
IF (inkbd = "9") THEN SEROUT SO, Baud,[1,114,0,9,97,197]
IF (inkbd = "0") THEN SEROUT SO, Baud,[1,114,0,0,161,195]
'SERIN SI,Baud,100,Main,[letter]
'Now send accumulated inbound data from secondary serial
'out via tertiary serial port to wireless modem...
GOTO gather

01-16-2007, 08:46 PM
One thing I ran into on a similar project was that the automation controller (a vehicle scale indicator in my case) didn't have a fully implemented RS-232 interface. The long and short of it was that the automation controller depended on 'stealing' the negative signal voltage from the PC's serial connection.
With the controller turned on and idle, check pins 2 and 3 to ground. One of them should be about -8 to -12 volts. If not, you'll have put a MAX232 or MAX233 between the controller and the stamp to create the required negative voltages.


Tom Sisk


Chris Savage
01-16-2007, 11:08 PM
Tom has a good point. Quite often the RS-232 peripheral is somewhat dependant on the host to generate the proper voltages. For this reason I always implement a MAX232 when talking to RS-232 equipment from the BASIC Stamp pins. It is even possible to have this issue from the BASIC Stamp programming port while trying to talk to a peripheral device for the same reason since the programming port is RS-232 compatible but does not use RS-232 levels. It too depends on the host equipment to provide the negative voltages. I hope this helps. Take care.

Chris Savage
Parallax Tech Support