RS232 DTR/DSR/DCD on Amegea or UC3 or SAM

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok I have this requirement to potentially have 3 x RS232 interface on a board for protocol conversion. I need preferably all 3 interfaces to offer full RS232 V.24 spec with DTR/DSR/DCD as well as the usual RTS/CTS lines. I only see UC3C series (industrial) that offers the full set of pins but only for 1x USART interface.

 

Any advise? Should I just use the ARM SAMD21 chips (I would prefer) and use its regular RTS/CTS and just put DTR/DSR/DCD in EXTINT pin inputs? I understand the DTR/DSR is just session related stuff. No? What about DCD pin?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You want ‘advice’ and I can ‘advise’ you.
I’d suggest it would be unwise to connect the control lines to external ints - a simple wiring error might introduce 100,000’s of interrupts per second. This is probably not a good thing. Polling them via a timer tick would be much safer. Let’s face it, on a real modem data carrier detect isn’t going to transition too quickly. DTR can be used as a handshake from a printer for hardware flow control. This can be tested in your serial send code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IIRC, the RS232 specification names the various signals, but does not indicate how they are to be used, other than the signal names.  What are you connecting to and how does it uses the signals.

Greg Muth

Portland, OR, US

Atmel Studio 7.0 on Windows 10

Xplained/Pro/Mini Boards mostly

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On Mega devices, there is no integral serial control signal mechanism - DTR, DSR, and relatives. It is totally up to you to implement them in this environment. While I am not sure, I suspect that there is NO standard behavior such as a statement that: "all transmission shall be suspended on receipt of an assertion of control signal 'XX'". There certainly is a set of ad-hoc behaviors.

 

On such I/O signals, particularly ones that might be subject to the vagaries of poorly defined communications channels, I would really stay away from interrupts. You probably do not need service granularity faster than 1 character time, so just poll, with debouncing, of course. Maybe just before each character is transmitted or at some regular interval when inactive. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you need DTR/DSR and RTS/CTS then why not just bit-bang them on GPIO pins? At the end of the day that's pretty much all a "full" UART is effectively doing anyway. For DTR and DSR you just sense DSR as an input and just don't do any UART operation until you see it asserted. For DTR you probably just drive it active at power on and leave it that way - it's effectively just saying "there's a communicating device present at this end of the cable". For RTS/CTS just sense CTS on a character by character basis and only put the byte into UDR when you see CTS. For RTS just drive it active all the time unless you really are operating a circular buffer in which case de-assert RTS as the buffer is filled (or gets near filled). For DCD it's actually very like DTR. I'd just assert it and leave it that way. Obviously it's a hang over from "modem days" and is used to say "this modem is linked to another one". If you are just doing all this across some "local" wires the link will never break so there's no need to change DCD - just assert it so that the other end believes the link is always in place.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For "full modem control" don't forget RI, the DTE will only assert DTR after seeing RI go high, but only if in auto answer mode!

To force the modem to hang up, when the session (logout) occurs,  drop DTR and the modem will hang up!

 

Jim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Back in the day, when we were connecting modems to MCUs we generally ignored RI because if you expected the modem to be called you'd just ATS0=1and then wait for "RING"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
 For RTS/CTS just sense CTS on a character by character basis and only put the byte into UDR when you see CTS. 

IIRC, there is no requirement for CTS to be acted upon immediately - the sender is allowed a few characters "grace", and the receiver is required to allow a little overrun ...

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you expected the modem to be called you'd just ATS0=1and then wait for "RING"

You had fancy modems!  (modems are a lot fancier than they used to be - in the old days, RING would come from some sort of telco circuitry, and the "equipment" would raise DTR, and THAT closed a relay that took the phone line "off hook" and started carrier detection.  Eventually CD would come up, or the equipment would drop DTR to hang up.   Hayes was (I think) the first vendor to stick some sort of microprocessor in there that interpreted command and sent status inline with the data.  And RTS/CTS was for half-duplex.)

 

 While it's somewhat useful to have support for "hardware flow control" on RTS/CTS to prevent "skid" (especially if you have deep FIFOs (but I don't think any Atmels do)), polling should be more than sufficient for the "modem control" signals.  (Possible exception: if you're trying to do "pass-through" of something that bit-bangs the signals.)

 

It would be useful to understand the devices that you expect to connect.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
You had fancy modems!
I'm guessing your ones must have been housed in a shoebox in middle of t' road? ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think it took quite a while for the "smart" modems to drift up to the mainframe world where I was working.    The most common questions I had to deal with were: "How do I turn off commands, so the modems can't be used "nefariously" for dialout?", and "how do I turn off these responses so they don't interfere with login?  The smart modems were pretty good at having those modes, and during the "rapid modem technology advancements" of the 1980s, it wasn't so uncommon for quite a few "random" single modems to be hanging off of the serial ports.