Why USB Devices Must Enumerate First

USB is often treated as “plug in and communicate”. Keyboards, flash drives, USB serial adapters, cameras, and debuggers all use USB and appear to share one connector.

To understand USB, first notice how different it is from UART, I2C, and SPI: USB is usually not peer-to-peer. A Host manages Devices. After a device is plugged in, it cannot just start sending arbitrary data. It must first be discovered, identified, and configured by the Host.

Why RS-485 Is Not Just UART Over a Longer Cable

RS-485 is often discussed together with UART and Modbus. Manuals say “RS-485 serial port”, and many tools treat it like a longer serial port.

That is convenient, but it creates bad debugging habits. UART defines asynchronous byte framing. Modbus RTU defines master requests to slave registers. RS-485 defines an electrical layer for differential signaling, multi-drop buses, longer distance, and noisy environments.

Why CANopen Is More Than a Set of CAN IDs

After learning CAN, it is easy to see CANopen as “some fixed message IDs on CAN”. That is only the surface.

CAN handles arbitration, frame transfer, and error handling on a shared bus. CANopen solves a higher-level problem: how an industrial device exposes parameters, exchanges cyclic process data, is configured, enters operation, reports faults, and tells tools what objects it supports.

Why Modbus Is Simple but Still Fails in the Field

Modbus often looks simple. Read registers, write registers, a few function codes, an address, a CRC. It seems quick to implement.

In the field, failures are usually not about memorizing function codes. They come from more practical details: whether register addresses start at 0 or 1, whether 40001 is a documentation number or a frame address, how a 32-bit float is split across two 16-bit registers, when an RS-485 half-duplex transmitter should release the bus, which downstream device a gateway unit id selects, and whether polling and retries overload the bus.

EtherCAT

Connecting servo drives, remote IO, and sensors to Ethernet sounds like a natural upgrade: the cabling is mature, the bandwidth is high, and the tools are familiar. But control systems are usually not blocked by whether data can arrive at all. They are blocked by whether data can arrive inside a stable cycle. A position value that arrives a few hundred microseconds late is not the same kind of problem as a web page that opens a few hundred microseconds late.

DBC

DBC is often first seen as a “CAN signal manual”: which bits in a given ID mean what, what the scaling factor is, and what unit is used. That understanding is not wrong, but it stays at the reference-document level. Anyone who has actually done packet capture, integration, or protocol handoff quickly learns that the real problem is usually not “there is no table.” The real problem is that everyone has a table, but they still cannot agree on how a frame should be interpreted, which node should send it, how the physical value should be calculated, or whether the version has changed.

UDS Flashing Flow

In ECU flashing captures, the first services you usually notice are Request Download, Transfer Data, and Request Transfer Exit. At first glance, it seems simple: tell the ECU to get ready, send the binary in chunks, and then finish. But real engineering is never that simple. Flashing is hard not because segmented transfer is complicated by itself, but because it is a high-risk business chain: if permissions are wrong, the session is wrong, erase is wrong, the block order is wrong, verification fails, or activation fails, the ECU can be left in a state worse than “not upgraded.”

OBD

OBD, UDS, and CAN are easy to mix together as if they were just different names for “vehicle diagnostics.” That misunderstanding is especially likely to distort capture analysis and system design, because the first thing you need to grasp about OBD is not a PID number or the shape of a 16-pin connector. It is the role it plays in the whole diagnostic stack.

The most important judgment about OBD is this: it provides a standardized and predictable diagnostic entry point for external tools, driven by regulation and general service scenarios. It does not try to cover every internal ECU diagnostic capability, and it is not the same as a vehicle maker’s private diagnostic stack. Its first goal is to make sure that different vehicles from different vendors can still expose emissions-related states, fault information, and basic data in a similar way to common tools.

UDS

In vehicle-diagnostics captures, the first things people often remember are a few hex service numbers: 0x10, 0x22, 0x27, 0x2E, 0x31, 0x34. Those numbers matter, of course, but memorizing service IDs alone still leaves later implementation, troubleshooting, and flashing analysis confused, because what you need to grasp first is not “which number means which function.” It is “why vehicle diagnostics cannot rely only on a few private commands, and instead need a full application-layer order.”

CAN TP

Once you understand classic CAN and CAN FD, the next natural thought is: if one frame cannot hold the data, why not just split it in application code and send multiple frames? That can work in the simplest experiments, but once a real system is involved, problems appear quickly: how does the receiver know where the long message starts and ends, what happens if one frame is missing, what if the sender transmits too fast for the receiver to keep up, and what if both directions have large messages at the same time?