Image Map Image Map
Results 1 to 8 of 8

Thread: RS232 bridge

  1. #1

    Default RS232 bridge

    So I've been talking about making a RS232 bridge in this thread:

    ... primarily to deal with a vt420 terminal that only supports XON/XOFF, but I'd like to make it work with things that don't like the Zeta 2 SBC I built that supports RTS/CTS handshaking.

    My thought was to make a pass through type pcb with two DB9 connectors on it, one would be DTE (male) and the other DCE (female) so it could easily be connected inline between two RS232 devices. It would essentially use a pair of ST3232CDR or similar transceivers to convert RS232 signals to TTL level and then use an AVR like the atmega328pb which has to USART's on it to be a bridge. The idea is that you could set the baud/databits/parity/stopbits/handshaking on each side (DTE, DCE) and it would bridge them. In the case of my vt420 I'd set it to 38400N81 with XON/XOFF and the other side I'd set to 38400N81 with DTS/CTS and try it with the Zeta 2. The microcontroller has 2K of SRAM, so I can probably buffer 768 bytes in each direction as well. You could use different baud rates, data bit lengths, etc. as well.

    I've thought about some other features as well that might be handy for retrocomputing type things like only retaining 7 bits even if bridging between two 8 bit devices, or always setting uppercase or lowercase, or in the conversation linked above, we were talking about methods to pass a ^Q or ^S to a non software handshaking device from a software handshaking device...

    Has anyone made something like this already? Any other ideas or features that would make it useful?

  2. #2
    Join Date
    Sep 2006
    Silicon Valley


    Quote Originally Posted by alank2 View Post
    So I've been talking about making a RS232 bridge
    consider using the Maxim MAX214 and making the device auto DTE/DCE switching

  3. #3
    Join Date
    Oct 2008
    Kamloops, BC, Canada
    Blog Entries


    This sounds like a much more advanced version of the serial buffer I had prototyped for my ASR 33 but never got coded. It let the terminal side be one fixed speed (110) while the other side was a faster and more standard rate (in my case, 300). The microcontroller buffered the data received and transmitted and needed only a small amount of memory to hold the buffer itself.
    = Excellent space heater

  4. #4


    Al Kossow - Wow, that MAX214 is interesting. I've never seen that before.

    NeXT - Exactly. I want to make it support the slower baud rates so it could be used this way.

  5. #5


    Not exactly the same but permit be to ramble on

    What I've setup is

    a) Raspberry Pi 3B+ which has 4 x usb ports
    b) buy upto 4 usb to serial converters, obviously ones compat with linux
    c) Get Pi up headless, mine has Ethernet LAN connectivity
    d) Connect then upto 4 Serial Vintage machines
    e) Over the LAN you can simply ssh into the remotely located Pi and then use screen command or other to talk to the port /dev/ttyUSBn

    Nice thing for me is that the Pi and vintage machines can be located anywhere e.g. in my garage 300 metres from my study.

    regards mb

  6. #6


    amouse, I agree, modern connectivity options can really expand usefulness. Being able to work remotely is pretty cool.

  7. #7


    Here are some notes about what I am thinking about - if you have ideas or improvements let me know:

    XON/XOFF mode will filter the XON/XOFF at the interface:
    It assumes the ones it receives are for handshaking and does not send them through.
    It generates the ones it sends for handshaking.
    It will not pass through ones from the other side even if it is not software handshaking.

    Send XON/XOFF to a none handshaking or rts/cts handshaking by using a translation character. This would allow us to remap another value on the XON/XOFF side such as ^W so that when a ^W is received, it sends a ^Q to the none/rts-cts side for example.

    Though it works in both directions, here is the though about just one of the directions since both are the same:

    from one interface we will receive
    we have no control over receiving a frame, so if we receive one and there is room in the buffer, we will add it
    if the receiving side is
    none hs, then we do nothing ever.
    xon/xoff hs, then we will send XOFF at a specific point and XON at another point.
    rts/cts hs, then we will change a signal to indicate whether we can receive or not, again at certain points.

    to the other interface we will transmit
    if the transmit side is
    none hs, then we always send at any time
    xon/xoff hs, then we will only send when in XON mode
    rts/cts hs, then we will only send when the signal indicates we can

    It will have a single button then when tapped, does a reset, but when held for 3s, enters configuration mode which will always be accessible at 9600N81 on the DCE side with some simple menu type setup like this:

    RS232 Bridge Board 1.00

    1-DTE baud rate [38400]
    2-DTE data bits [8]
    3-DTE parity [NONE]
    4-DTE stop bits [1]
    5-DTE handshaking [Software XON/XOFF]

    6-DCE baud rate [115200]
    7-DCE data bits [8]
    8-DCE parity [NONE]
    9-DCE stop bits [1]
    0-DCE handshaking [Hardware RTS/CTS]

    T-Translation options
    S-Save and exit
    X-Exit without saving
    Option? 1

    Translation Options

    1-Retain bits [9] ;even if both sides are 8 bits, setting to a 7 will strip the highest bit
    2-Case change [Uppercase] ;changes letter case, none, lower, or upper
    3-XON passthrough [Off] ;allows passing through a XON from a side with software handshaking
    4-XOFF passthrough [127] ;allows passing through a XOFF from a side with software handshaking



    A-60, B-75, C-100, D-110, E-150, F-225, G-300, H-450, I-600, J-1200, K-2400,
    L-4800, M-9600, N-14400, O-19200, P-28800, Q-38400, R-57600, S-76800, T-115200,
    Baudrate? _

    A-5 bits, B-6 bits, C-7 bits, D-8 bits, E-9 bits
    Bits? _

    N-No parity, E-Even parity, O-Odd parity
    Parity? _

    A-1 stop bit, B-2 stop bits
    Stop bits? _

    N-No handshaking, S-Software XON/XOFF handshaking,
    H-Hardware RTS/CTS handshaking
    Handshaking? _

  8. #8


    Also, I tried to think of LED's, but wanted a minimal number of them for simplicity, so this is what I came up with:

    Three LED's:
    Each side will have a receive (or in) LED.
    Off = not receiving
    On = receiving data
    Blink = on hold due to handshaking
    There will be an error LED (red) that indicates a buffer overrun or frame error for any side.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts