CTS/RTS handshaking isn't used across the PSTN boundary. It is used between the modem and the DTE (usually by the modem to indicate that its buffer is temporarily full). To tell the upstream device to stop sending in the unlikely event that you've found a modern microcontroller that can't keep up with a modem or are doing a shipload of processing or slow I/O on the data received consider using XON/XOFF handshaking
formatting link
l and apparently pronounced EKS-AWN EKS-AWF - possibly in some of the hillier souther regions of the USA) or something similar.
Cheers,
- Alf snipped-for-privacy@remove.the.obvious.ieee.org (Good, Fast, Cheap - Pick any two).
I'm messing around with a SocketModem at the moment, trying to develop some basic driver software for an AVR. Between the modem and uC is a simple RTS flow control signal. My question is this: Assume the modem is receiving data down the phone line and passing it to the uC (i.e. nRTS is driven low by the uC). The receive buffer in the uC becomes too full and the nRTS signal is set high to temporarily stop more data being sent. What happens to the flow of data down the phone line? Will my receiving modem somehow signal up the line to the sending modem to stop sending data? If not how is a fully flexible link capable of handing downloads and bottlenecks at the receiving processor implemented?
That's why he asked if there was some other way the two modems do flow control.
I'm pretty user the v.NN protocols do provide modem to modem flow control. A few Usenet postings Google found confirm my recollections:
Quoting from
formatting link
If the modems have negotiated an error correction protocol (such as MNP or V.42) then the sending modem will indeed receive a flow control signal when the receiving computer tells the receiving modem to halt (whether via hardware flow control or software flow control). Modem error correction protocols include a mechanism for flow control messages between the modems, and if the receiving modem's buffers fill up it will signal to the sending modem that trasmissions should stop.
formatting link
Pretty close. All high-speed (>=9600bps) modems use synchronous links between the modems. On top of this, they use LAP-M (which is an HDLC-based protocol) and V.42 or V.14 to adapt asynchronous traffic to the modem's synchronous interface.
The LAP-M protocol is basically a reliable transport protocol which uses retransmission timers and sequence numbers to achieve reliability. In this protocol, flow control is done by having the receiver indicate that it's willing to receive more data, and not necessarily by a "flow off" message as with XON/XOFF. (Though, confusingly, V.42 does provide a way to carry RS-232 signals end-to-end. Sigh!)
formatting link
Yes, the modem will communicate the "halt of data" to your modem. How it is done (in-band or out-of-band) is part of the modem specs that we hear about all the time. Usually you don't need to worry about the specifics of how the modems communicate this info back and forth.
I don't have a copy of the CCITT specs, so I can't confirm the details. I do remember testing end-to-end flow control once with v.92 modems, and it seemed to work fine for me.
Avoid Xon/Xoff at all costs (even if you have to learn to solder so you can build a cable). Xon/Xoff is implimented very inconsistently from one OS to the next, and your chances of getting end-to-end Xon/Xoff to work correctly through a pair of modems is sufficiently close to zero to be ignored.
Just use RTS/CTS hardware handshaking on both ends between the modems and the computers, and then let the modems do their own flow control.
--
Grant Edwards grante Yow! Did we bring enough
at BEEF JERKY?
visi.com
This end to end flow control can be quite "elastic", especially when XON/XOFF handshaking is used.
When the receiving DTE (uC) wants to suspend the reception by dropping DTE or sending XOFF, the DCE (receiving modem) sooner or later stops sending bytes to the DTE.
With XOFF, it can take a while before the XOFF has propagated through the modem Rx FIFO and handled by the modem software and only then no new bytes are inserted into the Tx FIFO. Thus the previous contents of the Tx FIFO is transmitted. Thus, after the uC has sent the XOFF, a number of characters will still be received, the number is grater than the sum of the modem UART Rx and Tx FIFO sizes. Thus the uC ISR should be capable of storing at least these characters.
Even if HW handshaking is used, the DCE can send at least one byte, if it has already been transferred to the Tx shift register in the DCE UART. Thus, the uC must still be able to receive one additional character.
What happens between DTE and DCE in the receiving end does not necessary have any direct implication in the phone line communication between the two DCEs (modems). The transmitting DCE will send frames and the receiving DCE will acknowledge these frames until the internal buffers are filled in the receiving DCE. At this point the receiving DCE stops acknowledging the HDLC frames.
Since the transmitting DCE does not get acknowledges, it tries to resend the frames. If the transmitting DTE (PC) still send bytes, sooner or later the sending DCE buffers are filled and it requests the sending DTE to stop sending by dropping the CTS signal or sends XOFF to the sending DTE.
Thus, the flow control from the receiving DTE to the sending DTE can take seconds if large buffers are used.
--------
However, I would look at the OP's problem in a different way.
Any interrupt service routine in any current uC should be capable of handling the data rates from any phone line modem.
In large downloads, which should include some mechanism for error detection and recovery, the data is divided into blocks and the receiving system acknowledges the reception of the block by sending some kind of positive or negative acknowledge to the sender.
In the simplest case, each received block is acknowledged immediately and only after this acknowledge, the sender resends the old block (if negative acknowledge) or sends the next block (if positive acknowledge from the previous block). Thus, the receiving end interrupt service routine only needs to be able to store the full block size. In many protocols this size can be negotiated at startup. If the normal routines handling the received block needs more time to process it, it simply delays the transmission of the acknowledgement.
Sending the acknowledgement after each received data block greatly reduces the throughput, so many protocols send a few blocks before demanding an acknowledgement. In some protocols up to 7 frames can be sent before demanding an acknowledgment (window size 7), but multiple blocks can acknowledged at once, so usually the data transfer is continuous. This also means that the interrupt service routine Rx buffer must be capable of holding all 7 blocks.
In some protocols this window size can be negotiated to a smaller value. With window size 2, the data flow is usually continuous, but now only two frames need to buffered. Using two separate buffers, in which the interrupt service routine fills up one buffer, while the other buffer containing the previous block is processed by the normal code. For the next block, the role of these buffers are reversed. The interrupt service routine must be capable of understanding the frame format, so it know, when a complete frame has been received.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.