RS-232, RS-485, and CAN Bus in Industrial SBCs: What Engineers Should Check

Industrial SBC buyers often ask for “serial ports” or “CAN support” as if those terms are simple. They are not. RS-232, RS-485, and CAN are electrical and protocol ecosystems with different wiring, distance, noise behavior, and software expectations. A board that exposes UART pins is not the same as a board with protected RS-485 terminals. A SoC that supports CAN internally is not the same as a finished product with a proper CAN transceiver.

Understanding these interfaces helps avoid field failures, communication errors, and expensive redesigns.

Interface Overview

Each interface needs the right physical layer. Software alone cannot fix poor termination, bad grounding, or missing protection.

RS-232

RS-232 is point-to-point and common in older industrial equipment. It uses voltage levels different from TTL UART. If an SBC exposes only UART pins, an external RS-232 transceiver is required.

Check:

• voltage-level compliance
• DB9 or terminal block pinout
• hardware flow control if needed
• ESD protection
• cable length
• isolation requirements

RS-232 is simple, but pinout confusion is common. Document whether the device is DTE or DCE, and provide wiring diagrams.

RS-485

RS-485 is widely used for Modbus RTU and multi-drop industrial networks. It supports differential signaling and longer cable runs, but it requires proper termination and biasing.

Important RS-485 checks:

Automatic direction control is useful because it reduces software timing complexity. If the board requires manual RTS toggling, test carefully under load.

CAN Bus

CAN is common in vehicles, battery systems, motors, and distributed controllers. Many Linux systems expose CAN through SocketCAN, which is a strong and standard interface.

Check whether the board includes:

• CAN controller support
• physical CAN transceiver
• termination option
• isolation if required

In vehicle and mobile equipment, these CAN details become part of the broader industrial SBC smart transportation design, alongside ignition power, GNSS, cellular recovery, and vibration.

• SocketCAN driver support
• CAN FD support if needed

On Linux, a basic SocketCAN setup may look like:

ip link set can0 type can bitrate 500000
ip link set can0 up
ip -details link show can0

For CAN FD, additional data bitrate settings may be required, depending on hardware and driver support.

Isolation and Grounding

Isolation is often ignored until field installation. Long cables between machines can create ground potential differences. Without isolation, communication may become unreliable or hardware may fail.

Use isolation when:

• devices are powered from different supplies
• cable runs are long
• equipment is near motors or drives
• outdoor wiring is involved
• safety or reliability requirements are high

Isolation adds cost, but it can prevent difficult field failures.

Linux Device Names and Testing

Serial ports may appear as /dev/ttyS*, /dev/ttyUSB*, or /dev/ttyAMA* depending on implementation. USB serial adapters are convenient but can change enumeration order unless udev rules are used.

Useful checks:

dmesg | grep -i tty
ls -l /dev/ttyS* /dev/ttyUSB* 2>/dev/null
ip link show | grep can

For production, use stable device naming and clear configuration files.

Board Selection

When comparing industrial SBCs, ask whether the interface is native, bridged, protected, and documented. If the interface list is still changing, the broader industrial SBC selection checklist should be settled before locking the board.

Validation

Test with real cable length, real devices, and electrical noise if possible. Simulators are useful, but the field environment matters. For RS-485, test multi-drop networks and termination settings. For CAN, test bus-off recovery and error frames.

Protocols Above the Physical Layer

RS-232 and RS-485 define electrical behavior, not the full application protocol. Many industrial systems use Modbus RTU over RS-485, but others use proprietary frame formats. CAN is also only the bus layer; higher-level protocols such as CANopen, J1939, or vendor-specific messages define how data is interpreted.

This distinction matters when selecting software. A board can have a working RS-485 port but no Modbus library. A Linux system can expose can0 through SocketCAN but still require application work to decode the target protocol. Confirm protocol requirements early and test with the real device, not only a loopback adapter.

Serviceability

Industrial communication failures are often wiring problems. Make the system easy to service. Label terminals clearly, document pinouts, provide LEDs for TX/RX or bus activity if possible, and log communication errors with enough context. For RS-485, log timeouts and CRC failures separately. For CAN, log bus-off events and recovery attempts.

Good diagnostics reduce support cost. A technician should be able to tell whether the issue is wrong baud rate, reversed A/B wires, missing termination, device offline, or application protocol error.

Procurement Questions

Before approving a board, ask the supplier for details that are often missing from short product pages. Are the serial ports isolated? Can RS-485 termination be enabled per port? Is the CAN transceiver populated on the standard SKU? Are Linux examples provided? Are the ports tested over the full temperature range? If the answer is unclear, assume extra validation work will be needed.

Recommendation

Choose an industrial SBC with the physical interfaces your product actually needs, not only SoC-level support. For RS-232 and RS-485, verify transceivers, protection, and direction control. For CAN, verify transceiver, SocketCAN support, and recovery behavior.

Industrial communication is a system problem. The board, cable, grounding, software, and connected devices all determine reliability.