Ethernet, CAN, and RS485 for Industrial SBCs#
Quick Answer#
For industrial SBCs, Ethernet, CAN, and RS485 should be evaluated as board-level systems, not only as SoC features. A UART pin is not an RS485 port until the board adds the correct transceiver, protection, termination, connector, and software configuration. The same applies to CAN and industrial Ethernet.
Why These Interfaces Matter#
Industrial HMI panels, gateways, energy devices, machine terminals, and building automation products often fail or succeed based on field interfaces. CPU performance is rarely the hardest part. Stable communication, surge tolerance, grounding, isolation, driver support, and diagnostics are usually more important.
Interface Comparison#
| Interface | Common Use | Main Design Risk |
|---|---|---|
| Ethernet | LAN, PLC network, cloud gateway, diagnostics | PHY support, EMI, surge, dual-port needs |
| RS485 | Modbus RTU, meters, industrial modules | Direction control, isolation, termination, grounding |
| CAN | Machine devices, vehicles, industrial control | Transceiver, bitrate, termination, SocketCAN support |
Ethernet Checks#
Start with the number of ports. A gateway may need dual Ethernet, VLANs, static IP, DHCP, firewall rules, VPN, MQTT, and long-running diagnostics. Some products also need PoE, which is a board power design issue rather than an SoC feature.
Verify Linux driver support, PHY model, link stability, suspend/resume behavior, and long-run traffic tests. For Android terminals, confirm Ethernet UI behavior, static IP configuration, and recovery after cable disconnect.
RS485 Checks#
RS485 is often implemented through UART plus an external transceiver. Ask whether direction control is automatic, whether termination and biasing are available, whether isolation is included, and whether the port has surge or ESD protection.
If the product uses Modbus RTU, test real devices early. Timing, bus loading, grounding, and cable length can expose problems that never appear in a short demo.
CAN Checks#
CAN requires a CAN controller, a transceiver, termination, and software support. On Linux, SocketCAN support is a major advantage because it gives a standard user-space interface.
Ask whether CAN has been tested under the target bitrate and bus length. Also check whether the board exposes one or more CAN ports and whether isolation is needed for the application.
Supplier Questions#
- Which Ethernet PHY is used?
- Are dual Ethernet ports independent?
- Are RS485 and CAN isolated?
- Is termination configurable?
- Are Linux drivers included in the BSP?
- Has Modbus or SocketCAN been tested?
- What ESD and surge protection is present?
- Are field diagnostics available?
Board-Level Reality#
Ethernet, CAN, and RS485 are often discussed as if they are simple SoC features, but the production behavior depends heavily on board design. Isolation, termination, surge protection, connector choice, grounding, power input, and cable environment can matter more than the processor family. A low-cost SBC may expose UART pins that can be converted to RS485, but that is not the same as an industrial RS485 port designed for noisy field wiring.
Ethernet should be evaluated for more than link speed. Industrial gateways need stable link recovery, watchdog behavior, driver support, and sometimes dual Ethernet separation between field network and upstream network. CAN needs the correct transceiver, termination plan, and software stack. RS485 needs direction control, biasing, isolation when required, and clear documentation for half-duplex behavior.
The SoC shortlist should start from the final wiring diagram. Count Ethernet ports, serial buses, CAN channels, USB expansions, isolated inputs, and power rails before choosing the processor. If the required interfaces are only available through USB adapters or untested expansion boards, the integration risk increases.
Validation Workflow#
Test each interface with the cable length, baud rate, packet rate, and electrical environment expected in the product. For Ethernet, run long-duration traffic tests, link unplug/replug tests, DHCP or static IP recovery, and power loss recovery. For CAN, test bus load, termination, error handling, and application behavior during disconnects. For RS485, test multiple nodes, direction control, grounding, and noise sensitivity.
Ask the board supplier whether the ports are isolated, which transceivers are used, whether schematics are available, and whether the BSP includes tested drivers and examples. For gateways, verify that watchdog and remote recovery still work when a field bus locks up or a cable is miswired.
Release Decision Criteria#
The interface design is ready when the team can show stable operation with the real field wiring. For Ethernet, that means link recovery, long traffic tests, static or DHCP behavior, and watchdog response. For CAN and RS485, it means correct transceivers, termination, isolation where required, driver support, and behavior under bus errors.
A board should not be released because a port appears in the datasheet. It should be released because the exact connector, transceiver, cable, grounding, and software recovery path have been tested in conditions close to the final installation.
Acceptance Notes#
Treat field interfaces as reliability features, not only connectivity features. A release candidate should include wiring diagrams, termination settings, grounding rules, surge or isolation assumptions, driver versions, and recovery behavior. The product should keep running or recover cleanly when a cable is unplugged, a bus is noisy, or a field device stops responding.
FAQ#
Can an SBC add RS485 through USB?
Yes for prototypes, but production industrial systems usually need board-level design.
Is CAN support only a software issue?
No. Controller, transceiver, termination, and wiring all matter.
Should interfaces be verified before SoC selection?
Yes. Interface requirements often eliminate otherwise attractive SoCs or boards.