Result Code Recognition
Hayes modems support both verbose and numeric result codes. Unless echo
is a problem and you are installing the controller in a limited-growth environment,
verbose results are preferred. Numeric result codes make it easier for software
to control the modem, but there are two primary reasons they should not
be used:
1. Software can be confused by a command echo. For example, if the following
command were sent with echo on (En - Select Command
Character Echo Option ) and numeric results (Vn
- Select Result Code Format Option ) on:
AT ... S9=20 <CR>
The resulting data, echoed by the modem, would be followed by the numeric
result code zero, meaning OK:
AT ... S9=20<CR>0 <CR>
Software can be confused by a 0<CR>result that is part of the command
echo, then another 0<CR>which is the numeric result. A program can
lose synchronization with the command processor in the modem.
Turning off echo mode (E0) in the initial setup string solves this problem;
however, do not end the echo command with any digits (simply E).
2. Software must anticipate all possible responses. This requires updating
controller software whenever new result codes are added. For example, suppose
a CONNECT 115200 result were added with a numeric value of 31. If verbose
results were used instead, and the controller directed to interpret the
number after the CONNECT result as simply the connection speed in bits/s,
no changes to the driver are required by the new result code. If numeric
result codes were used, the result code 31 must be added to the table, and
the controller modified to interpret it appropriately.
As characters are received, they should be processed through a state machine
providing the functionality in the following example. This state machine
recognizes strings surrounded by <CR>t<LF>characters and stores
the string in a character array. <CR><LF>are defined in Sregisters
S3 and S4.
Sample State Machine
Initialize with: state = 1 ;
ch = ;
switch( state )
{
case 1: /*-- Scanning for leading CR --*/
if( ch == CR ) state = 2 ;
i = 0 ;
break ;
case 2: /*-- Scanning for leading LF --*/
if( ch == LF ) state = 3 ;
else if( ch == CR ) state = 2 ;
else state = 1 ;
break ;
case 3: /*-- Buffer result, watch for trailing CR --*/
if( ch == CR ) state = 4 ;
else buf[ i++ ] = ch ;
if( i >LIMIT ) state = 1 ;
break ;
case 4: /*-- Scanning for trailing LF --*/
if( ch == LF ) state = 5 ;
else if( ch == CR ) state = 2 ;
else state = 1 ;
break ;
}
if( state == 5 )
{
buf[ i ] = 0 ; /* Null terminate buffer */
;
state = 1 ;
}
This state machine can be imbedded within a loop that reads all received
data one character at a time, checks for a time-out, and also checks for
user abort. Once a result is recognized, that loop can be exited or continued
if additional results are expected.
Once a result code string is returned, it can be compared against the known
result code strings. Some strings may incorporate wild-card suffixes. For
example CONNECT followed by any numeric value indicates a successful connection
at the indicated transmission rate. Even if a result such as CONNECT 38400
is not anticipated, if the controller has been coded for wild-card recognition,
the controller will be capable of interpreting such responses correctly.
This practice also helps the modem interpret a connection failure messages
that are preceded by NO followed by another character string such as DIALTONE,
CARRIER, or ANSWER.
Click here to return to the Contents page.