> Sometimes you just need a little help when your brain cramped....
>  
> Once you send the AT commands to dial to a host... how does the PIC see
> it's connected? Generally a text string sent back saying it's connected
> typically? Then I assume its just sending data back and forth...

Basically.  With lots of little timing issues and such to make
life interesting.  Following is general concepts because the code
I recently wrote to do this is proprietary.

I use cooperative multitasking with a state machine for each thread.
Main loop calls thread if state is non-zero (maps nicely to TSTFSZ
on 18F).  Use states to implement timers and dismiss thread when it
is waiting for UART to become ready (Tx) or to have a char (Rx).

Build command string, e.g. ATDT9,13101234567\r , set pointer to the
first char, set first thread's state to transmit_char.  State, when
called, checks if UART TX buffer can accept a char.  If so, load char
via pointer, stuff char into UART, update pointer, and repeat.  If TX
not ready, return (i.e. dismiss, first thread gets called again "soon").

Second thread has a buffer assigned to hold response line.  Initialize
pointers & counters into it, set maximum wait timer, and set state to
wait_for_carrier.  It checks UART RX buffer to see if a char is ready.
If so, it grabs char and stuffs it into buffer.  If char is a linefeed,
then go check line in buffer against response strings.  If char is not
ready, check if timer (see third thread below) has expired.  If UART RX
is empty and timer is still running, then return (i.e. dismiss thread).

Third thread deals with hardware timer interrupt and turns it into a
usefull value, like 10mS or 20mS or 50mS.  Ticks are distributed to
all of the threads that have registered a pointer to a 16-bit timer
variable (if variable is non-zero, tick manager decrements it -- this
prevents the counter from wrapping around so client can just check the
2-octet variable for equal to zero for timer expired).

Even with 50mS ticks, 8-bit variable isn't long enough (~12 seconds)
to deal with modem dialing and call connect handshakes.  Variables
used for timers really need to be 16-bits.

I also use third thread to keep track of Carrier Detect signal from
modem by setting/clearing bit in a flag octet.  More robust if all
the other threads check these central flags rather than going out and
talking to the modem directly.

Now to answer your original question.  Following assumes that you have
the modem set for text response.  Modem may be configured to shorter
numeric responses.

After dialing, wait for both response string of  CONNECT*\r\n  .and.
carrier detect signal to be up.  Asterisk is a wildcard since the
connect response string may or may not contain the connection speed.
When both CONNECT response string and carrier are up within time-out
period, call has been completed and you can transfer data.

Abort call attempt if you see any of the following responses:

    ERROR\r\n
    NO CARRIER\r\n
    NO DIAL TONE\r\n
    BUSY\r\n
    NO ANSWER\r\n
    LINE IN USE\r\n
    DELAYED\r\n
    BLACKLISTED\r\n

I drop DTR for a couple seconds to ensure modem is hung up when
one of these conditions occurs.

Ignore other responses lines such as

    OK\r\n

(since it will be generated by the ATD command) and a bunch of other
strings that may be generated depending on the modem model and the
various option settings (Xn, Wn, S95, etc).

While you are dialing, a call may come in, so how you handle response
of  RING\r\n  depends on what your overall modem management strategy.

Remember that sending a dial string or reading a response take a
_long_ time in PIC terms.  You have to build a mechanism to block
the processes in some sort of I/O wait.

						Lee Jones

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist