Searching \ for '[PIC]:connecting thru a modem' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'connecting thru a modem'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:connecting thru a modem'
2005\07\13@230331 by alan smith

picon face
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 its connected? Generally a text string sent back saying its connected typically? Then I assume its just sending data back and forth...



               
---------------------------------
Start your day with Yahoo! - make it your home page

2005\07\14@000734 by Chen Xiao Fan

face
flavicon
face
Normally the modem will send some response to the PIC, right?
For example, if a PIC send an AT command to a analog Modem, it will
reply with "OK" or something similar depends on the AT command.
Then you can check whether the response is what you expected.
If there is no response within a preset timeout period, then you
assume the communication is not established.

Regards,
Xiaofan

-----Original Message-----
From: alan smith
Sent: Thursday, July 14, 2005 11:04 AM

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 its connected? Generally a text string sent back saying
its connected typically? Then I assume its just sending data
back and forth...

2005\07\14@002156 by Lee Jones

flavicon
face
> 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

2005\07\14@011705 by Chen Xiao Fan

face
flavicon
face
Wow, thanks for the detailed reply. PIClist is great.

So are you interfacing a real analog MODEM? What is the application?
Are you running your own OS (cooperative multitasking)?

What do you mean by the "a mechanism to block the processes
in some sort of I/O wait"?

Regards,
Xiaofan

{Original Message removed}

2005\07\14@032223 by Shawn Tan Ser Ngiap

flavicon
face
> Once you send the AT commands to dial to a host....how does the PIC see its
> connected? Generally a text string sent back saying its connected
> typically? Then I assume its just sending data back and forth...

Yes, in the old days, you actually saw this CONNECT string when you tried to
connect, before windows hid everything behind a GUI... You can tell the modem
to either send a text or numeric return value.. You can set a timeout period
as well...

After that, just send bytes down and read bytes out... Just be careful of
certain escape sequences..

Check out the Hayes modem spec for more info.. you can configure the modem
with AT commands as well...

cheers..

--
with metta,
Shawn Tan

2005\07\14@061336 by Nate Duehr

face
flavicon
face
On Thursday 14 July 2005 01:23, Shawn Tan Ser Ngiap wrote:
> > Once you send the AT commands to dial to a host....how does the PIC see
> > its connected? Generally a text string sent back saying its connected
> > typically? Then I assume its just sending data back and forth...
>
> Yes, in the old days, you actually saw this CONNECT string when you tried
> to connect, before windows hid everything behind a GUI... You can tell the
> modem to either send a text or numeric return value.. You can set a timeout
> period as well...

I set up my GPRS cellular modem to work under Linux by hand, using some notes
from a website about the GPRS/celluar-specific AT strings, and standard old
pppd -- even though the cellular carrier claims the only way to use this
Sony/Ericsson GC79 card is via their special Windows management software.  

It pays to remember this old stuff, sometimes.  ;-)

Even better, under Linux the card appears to the OS (as I'm sure it does in
Windows too, but they hide it from you with their fancy little GUI tool) as
two separate cards.  I can fire up the GPRS portion of the card to get a
low-speed data link to the Net, and then turn on an Ad-Hoc 802.11b network to
allow others to NAT through my cellular connection if they're within reach of
my little card's signal on my laptop.

(It also pays to know how to set your own routes for TCP/IP like we used to
have to do and not rely on DHCP or other crutches other than when you feel
like it.)

> Check out the Hayes modem spec for more info.. you can configure the modem
> with AT commands as well...

AT&S0=1  ( GRIN )

> cheers..

+++ATH
NO CARRIER

;-)

--
Nate Duehr, spam_OUTnateTakeThisOuTspamnatetech.com

2005\07\14@070718 by Lee Jones

flavicon
face
>> 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).
>> ...
>> 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.

> Wow, thanks for the detailed reply. PIClist is great.

> So are you interfacing a real analog MODEM?

Yes.  Connectix modem chip set on PC board with PIC 18F6621 and
other peripheral chips.  Modem presents parallel interface that
looks identical to a PC 16550 UART with FIFOs.

Modem interface would work the same if I had an external modem
on the far side of a serial link via PIC UART.

> What is the application?

Medical with data comm; beyond that, client confidentiality kicks in.

> Are you running your own OS (cooperative multitasking)?

Yes.  More of a round robin process switcher.  All processes
(more like light weight threads since they have to keep their
own context) are staticly defined in code.  Main loop is

MAINLOOP
       TSTFSZ TICK50MS, ACCESS         ; has a 50ms tick registered by ISR?
         CALL SYSTEM_THREAD                ; yes
       ;
       TSTFSZ MODEMSTATE, ACCESS
         CALL MODEM_THREAD
       ;
       TSTFSZ FOOSTATE, ACCESS
         CALL FOO_THREAD
       ;
       TSTFSZ BARSTATE, ACCESS
         CALL BAR_THREAD
       ;
       BRA MAINLOOP

System thread does switch scanning, debounce, LED on/off/blink, etc.

Each thread (excluding system thread) starts with:

MODEM_THREAD
       MOVF MODEMSTATE, W, ACCESS
       CALL DISPATCH_TOSTAB_BY_QUAD        ; jump to appropriate code fragment
       RETURN  ; bytes 1 & 2 of quad        ; state 0 not used / not valid
       RETURN  ; bytes 3 & 4 of quad        ; each state MUST use exactly 4 octets
       GOTO M_1_HANGUP                        ; entry state
       GOTO M_2_HANGUP_DCD_OR_TIMER        ; work state
       GOTO M_3_HANGUP_TIMER                ; work state
       GOTO M_4_other_subtask

DISPATCH_TOSTAB_BY_QUAD uses the value in W to select & execute
one GOTO instruction by manipulating top of stack (TOS).  After
dispatch, return address on stack is one left by CALL MODEM_THREAD
so a RETURN goes back to MAINLOOP.

There's a matching DISPATCH_TOSTAB_BY_WORD if the addresses are
localized enough to allow use of 2-octet BRA instructions.

Threads adjust state variable to control which label gets control
next time thread is activated.  Frequently, same state is used for
a while, e.g. take modem receive characters and fill a line buffer
until a linefeed is seen for checking response codes.

How you decide on the next state for a thread allows a whole lot
of flexibility in code design.  One thread can update the state
variable of another thread to trigger an action (modem thread
fills buffer, start flashrom thread to write buffer).  You can
have a multi-level stack of next states so you can sequence a
thread's future actions.


> What do you mean by the "a mechanism to block the processes
> in some sort of I/O wait"?

Just emphasizing the long (in PIC CPU instructions) delays
between I/O events that require CPU action.

Modem at 9,600 baud is ~1 character per millisecond.  FlashROM goes
away for 8-20 milliseconds after being given a command.  Call setup
& line speed negotiation can easily take half a minute.  Parallel
port printer may take thousands of octets as fast as you can feed
it then go off-line for (literally) hours when it runs out of paper
(and the staff is off at lunch).

Since I'm dealing with multiple peripherals, there has to be some
mechanism where a process can release the CPU (i.e. blocks itself)
while waiting for an octet to arrive or depart.  Threads must not
spin wait.  My software must time slice to multi-task. :-)

When it runs out of data, thread just does a RETURN which goes back
to the next TSTFSZ in MAINLOOP.  Each thread state value keeps a
bookmark into thread's overall task structure.

Threads can almost be thought of as polled with polling rate varying
but being pretty high.

Designer must ensure that a single code fragment doesn't tie up the
CPU for more than a few milliseconds.  Keeping that restriction in
mind, I limit each thread to only processing a certain amount of
data before releasing CPU  -- even if unlimited data is available.
Usually, data runs out before (self imposed) time slice expires.

Interrupts handle asynchronous data (e.g. modem receive chars) and
fill a buffer.  "Polled" modem thread empties buffer.  This way, modem
thread does not have to run several times per millisecond to keep from
loosing data on a 56Kbps connection.

Hope that all makes sense.

                                               Lee


'[PIC]:connecting thru a modem'
2005\09\24@131717 by Peter
picon face

I'd like to mention that it is possible to program most Hayes compatible
modems to auto answer and auto dial as necessary, without using any
Hayes commands at all. All control can be achieved using the DTR and RTS
lines usually. F.ex. sending a character from the computer causes the
modem to dial out, and the modem auto answers and sets CD when a
carrier is detected. DTR resets the modem (and drops a connection if
present at the time).

No actual handshaking needs to be used, the control signals can be
'misused' to control dialout and reset. If necessary, XON/XOFF can be
selected. The settings are programmed once (including the number to be
dialed) and stored in NVRAM by the modem. The modem thereafter reverts
to these settings after every power cycle or reset. Using ATDT...
dialout is still possible in this mode.

The mode is extensively used for alarm systems, vending machines, and
fixed service lines (like pump system remote control and the like).
Details vary but they are covered in the relevant Hayes command manual
(be sure to read the manual that applies to your modem, I have yet to
see two that use the same settings).

In all cases the settings are achieved by ATxx commands and arcane S
register settings. Sometimes flashing the modem with a certain firmware
version is required.

Peter

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...