Most BASIC Stamp carrier boards include a DB-9 connector for programming the microcontroller and for performing simple debugging. Unfortunately, only three pins are actually connected to the DB-9: TX, RX, and ATN (for programming). This severely rules out any possibility for hardware flow control. Last year I needed to communicate with a device that was much faster than the little BS2 microcontroller, and implementing some kind of flow control was the only way to keep from losing bytes. After a decent amount of reading about flow control and RS-232, I came up with the following solution.
I enabled XON/XOFF software flow control on the fast device, and then manually sent the XON and XOFF bytes from the BS2 when I was ready to read bytes.
SoftwareFlowControlExample.bs2
' {$STAMP BS2}
' {$PBASIC 2.5}
'
' Software Flow Control Example Snippit
'
' This example lays out the basic framework for implementing software
' flow control on the basic stamp.
'
' Author: Christopher Chess Ellsworth
'
SerialInPin CON 16
SerialOutPin CON 16
T2400 CON 396
T19K2 CON 32
T38K4 CON 6
Inverted CON $4000
Baud CON T2400 + Inverted
'Timeout for reading from the serial port
SerialInTimeout VAR Word
SerialInTimeout = 1000
command VAR Byte
Init:
'Tell the host that we are not ready to recieve data
GOSUB X_OFF
Main:
GOSUB Read_Message
'Do something if command is not 0
'SELECT command
'ENDSELECT
GOTO Main
'Read a message from the server machine.
Read_Message:
GOSUB X_ON
SERIN SerialInPin, Baud, SerialInTimeout, Read_Message_Time_Out, [command]
GOSUB X_OFF
RETURN
'END Read_Message
'If no message can be read from the serial port.
Read_Message_Time_Out:
GOSUB X_OFF
command = 0
RETURN
'END Read_Message_Time_Out
'Send software flow control bytes
X_ON:
SEROUT SerialOutPin, Baud, [17]
RETURN
X_OFF:
SEROUT SerialOutPin, Baud, [19]
RETURN
The solution worked for me, although it was a fairly unique chain of devices I was talking to. Please let me know if anyone has any thoughts on this technique.