OT Physical Layer: UART, RS-485, and PLC Communication Modules

The reason lies in the architectural, economic, and operational realities of OT:

1. Massive legacy:

   • Equipment lifespan is 15-30 years;
   • PLCs, RTUs, and sensors are already deployed and running;
   • Replacement = production downtime + millions of dollars.

2. Simplicity and predictability:

   • Modbus is deterministic and transparent;
   • Engineers understand it perfectly;
   • Minimum magic, maximum control.

3. Limited device resources:

   • Older devices cannot handle TLS, encryption, or complex authentication.

4. OT engineering philosophy:

   • Priority: availability > security;
   • Better “insecure but working” than vice versa.

Inside a processor / microcontroller, data is not transmitted one bit at a time; that is too slow. There are “highways” laid out inside – data buses.

In the picture, the Data Bus consists of 8 parallel conductors inside the microcontroller itself. A whole byte is transmitted across them in a single clock cycle.

Rough schematic representation:

UART1 and UART2 on the diagram are those very transceivers. They take the data arriving on a “broad front” and line it up into a single file.

The main assembly rule: the transmitting line TX (Transmit) of one device is connected to the receiving line RX (Receive) of the other.

This connection method can be compared to neuron connections in the central nervous system:

• The neuron’s dendrite receives the signal;
• The neuron’s axon transmits the signal further;
• The connection between neurons is called a synapse.

So the signal goes from the axon of one neuron → to the dendrites of another:

• TX ≈ axon (transmits)
• RX ≈ dendrite (receives)

But there is a crucial difference! In neurons, the connection is not symmetrical, and there is no “return wire”. In UART, we have two independent lines: TX→RX and RX→TX.

In the past (in the 80s and 90s), UART was actually a separate chip on the motherboard. Today, the UART block is a microscopic piece of silicon embedded right inside the microcontroller.

The CPU cannot “shoot bits” down a single wire with precise frequency – UART does that.

We write send("A") → the CPU writes 0x41 to the UART register → UART itself turns this into bits with correct timings.

CPU Core ↓ internal bus (AXI / AHB / APB) ↓ [ UART controller ] ↓ GPIO pins (TX/RX)

In the previous article, we designed and assembled an industrial control node.

If we were making a DIY project, we would take a microcontroller (Arduino) with its built-in UART, run wires to a cheap driver chip (MAX485), and route the wires from there to the factory floor.

But in industrial PLCs (like the Siemens S7-1200), the architecture is much trickier.

The Siemens CM 1241 module is an “independent mini-computer”.

When we snap the communication module onto the side of the PLC, we connect them not with slow RX/TX wires, but with a high-speed internal backplane bus.

Inside the module itself is its own dedicated microcontroller. And inside that microcontroller is a hardware UART, with an RS-485 driver soldered right next to it.

How the signal flows:

1. The main PLC CPU says: “I want to send a data packet”;
2. It instantly dumps the packet over the high-speed backplane bus into the expansion module;
3. The microcontroller inside the module catches the packet;
4. The built-in UART slowly begins slicing the packet into bits;
5. The RS-485 driver amplifies them and sends them down the long line.

Why the middleman?

It’s all about performance. The PLC’s job is to run the machine control logic at maximum speed (e.g., a 5 ms cycle time). UART is slow. If the UART were located right in the main PLC CPU, the processor would constantly be distracted by sending every single bit and getting bombarded by interrupts.

Therefore, Siemens delegates the routine. The main CPU dumps the data into the module and forgets about it. The tiny controller inside the module takes on all the “dirty” UART work: counting bits, waiting for timings, and talking to the RS-485 driver. And when a response comes from outside, the module assembles it into a neat, complete packet and hands it back to the main CPU.

We already know that inside the controller, data is transmitted in parallel via the data bus, while outside it goes over serial communication lines.

In serial transmission, timings are critical. But are there timings in parallel transmission?

Absolutely! But they work completely differently than in UART.

Outside (in UART), the interface is asynchronous. There are two devices, each with its own frequency generator, and they simply agree: “we read 9600 times a second”.

Inside the processor, everything is synchronous. There is one main “conductor” – the quartz resonator (clock generator). It ticks at enormous speeds (for example, 100 million times a second – 100 MHz).

Absolutely all blocks inside the chip dance to this “metronome”: the CPU core, memory, and the UART block.

How a byte is transferred from CPU to UART:

1. The CPU places 8 bits (voltage 1s and 0s) onto the parallel Data Bus;
2. The CPU pulls a special control line: “UART, I am writing data!”;
3. Timing: The CPU only needs to hold this voltage on the bus for one or two clock cycles (millionths of a second);
4. On the next “tick” of the main metronome, the UART instantly “photographs” the state of the data bus.

This is where the “camera” comes into play. Inside the UART, there are physical memory elements – flip-flops, grouped into registers.

As soon as the clock pulse passes, the electrical voltage from the data bus is latched inside these flip-flops. That’s it – the data is now physically stored inside the UART block.

Immediately after this (on the next clock cycle), the processor removes the voltage from the data bus and runs off to do other things. It no longer needs to hold anything. The UART will use its internal copy of this byte.

How is backpressure (flow control) implemented?

Inside a basic UART, there is actually not one, but two registers (two boxes for data):

• Transmit Data Register (TDR) / Buffer: This is the “reception area”. The CPU instantly drops a byte here.
• Shift Register: This is the “workshop”. From here, bits are pushed out one by one into the TX wire.

Normal Operation Scenario

The processor drops a byte into the TDR. If the workshop (Shift Register) is empty, the byte instantly drops in there and begins slowly (at 9600 baud) driving out onto the wire. Meanwhile, the TDR becomes empty again! This means the processor can drop another byte in there while the previous one is still being sent.

What if the CPU drops a third byte?

The Shift Register is busy sending the first one. The TDR is busy waiting (the second byte is sitting there). If the processor blindly writes a third byte into the TDR, it will physically overwrite (destroy) the second byte.

The hardware provides no physical mechanism to stop the processor from doing this. The data will simply be lost.

To prevent the processor from “overfeeding” the UART, the hardware provides Status Flags. These are special bits that the UART sets for the processor to read:

• The TXE (Transmit Empty) flag – the TDR buffer is empty, you can drop the next byte.
• The TC (Transmission Complete) flag – absolutely everything has been sent, the line is free.

There are 3 operating modes for handling these flags:

1. Polling – blocking mode:
   • The processor constantly checks the TXE flag in a loop.
   • “Empty? No. Empty? No. Empty? Yes!” → Writes the byte to UART.
   • Downside: The CPU wastes time idling, waiting for the slow UART.
2. Interrupts – asynchronous mode:
   • The processor drops the first byte and goes off to run the machine.
   • As soon as the UART sends the byte and the buffer empties, the UART hardware “taps” the processor (triggers an interrupt).
   • The processor gets distracted for a microsecond, drops the next byte, and returns to the machine.
3. Hardware FIFO Buffers:
   • In modern microcontrollers and PCs, the UART is a full hardware FIFO queue, for example, 16 or 64 bytes deep.
   • The processor can fill this queue all at once and leave, and the UART will slowly pull bytes from it and send them on its own.

But how can the processor read these flags? And how do the devices on the ends of the wire agree on pauses?

It is important to make a distinction here: flow control can be external (between two devices) and internal (between a processor and its own UART).

1. External Hardware Flow Control – RTS / CTS signals – is rarely used today.

In the classic old RS-232 standard, besides the RX, TX, and GND wires, there were additional physical wires:

• RTS (Request To Send);
• CTS (Clear To Send).

This is called Hardware Flow Control.

Why was this needed? In the 1980s, processors were very slow, and memory buffers were tiny. If a computer started sending data to a printer too fast, the printer couldn’t print it fast enough.

The printer would then physically change the voltage on the CTS wire (raise a “red flag”). The computer saw this voltage and stopped sending data (paused its UART). The printer caught up, lowered the CTS wire (“green flag”), and transmission resumed.

Why was this abandoned? Today, even the cheapest microcontroller runs at tens of megahertz and has plenty of RAM. It manages to pull data from the UART and drop it into its internal memory (buffer) thousands of times faster than it arrives over the slow wire.

The problem of receiver-side overflow has practically disappeared.

(Note: sometimes true Software Flow Control (XON/XOFF) is encountered. In this case, devices do without extra RTS/CTS wires, and simply send special control bytes over the TX/RX lines: “Pause” and “Resume”.)

2. Internal Control (working with UART registers) – TXE, RXNE, TC flags – is always present.

Those TXE and TC bits are located in special registers inside the microcontroller itself. Not a single UART in the world works without them. Even Interrupts and Direct Memory Access (DMA) are hardware-tied to these exact same internal bits.

But where are these flags located? But wait, UART is a piece of hardware with an 8-bit input and TX/RX output pins. Where did the status flags come from?

In reality, UART is built in a more complex way. It’s a block containing several separate registers (memory cells). Each cell consists of 8 physical flip-flops (transistors storing a logical 0 or 1).

A typical UART has at least 3 such cells (registers):

• Data Register (DR). This is the “funnel”. The processor places the byte to be sent here.
• Control Register (CR). When powering up, the processor writes settings here: “run at 9600 baud, use 8 bits, no parity”.
• Status Register (SR). This is where our flags live! It is also an 8-bit hardware cell. But the processor cannot write
• to it; it can only read it.

How does the processor know which cell to read/write?

Between the processor and the UART, there isn’t just a Data Bus (8 wires). There is also an Address Bus.

The CPU communicates with the UART exactly the same way it does with normal RAM. Each UART register has its own unique physical address:

• Address 0x4000_1000 – Status Register;
• Address 0x4000_1004 – Data Register.

All this happens between the CPU and the UART, which are sitting on the same piece of silicon. Another device outside will never be able to read these flags over the copper wires.

But then how does the main PLC CPU know about an overflow on the expansion board?

The main PLC CPU has no idea about low-level UART flags!

Overload protection (backpressure) in Siemens is implemented at different layers:

1. The main PLC CPU;
2. The microcontroller inside the CM 1241 expansion board;
3. The UART block inside the expansion board.

Layer 1: The PLC talks to the expansion board

Let’s say we wrote a program in TIA Portal that needs to send 1 kilobyte of data to a Variable Frequency Drive. The main PLC CPU won’t send this kilobyte one byte at a time. It uses the internal high-speed Backplane bus.

But the expansion board has its own RAM – say, a 2-kilobyte buffer.

How does flow control work here? The PLC CPU uses a special high-level communication protocol with the module.

When we call a send block in TIA Portal (for example, Send_PTP or Modbus_Master), this block has outputs (software variables):

• REQ (Request) – command to send.
• BUSY – the module is currently digesting data.
• DONE – the module has sent everything.

The PLC “dumps” the entire kilobyte of data into the expansion module’s RAM all at once over the high-speed bus. The module tells the PLC: “I received the package, the buffer is full, starting work”, and sets the BUSY = TRUE signal for the PLC.

The PLC sees the BUSY signal and understands: “Aha, I won’t send the next batch there yet, so I don’t overflow the memory”. The main CPU goes off to calmly execute the rest of the logic (spinning motors, reading sensors).

Layer 2: The expansion board talks to UART

Now a kilobyte of data is sitting in the RAM of the tiny microcontroller inside the CM 1241 module. And now this controller has to spit them out at 9600 baud.

This is where the magic of the hardware flags we discussed earlier begins!

The module’s microprocessor takes the first byte from its RAM and drops it into its internal UART block. Then it checks the UART hardware status flag (the TXE flag - buffer empty):

• Is the flag raised? No. The module’s microcontroller waits (or goes into an interrupt).
• Has the first byte left? Yes, the UART raised the flag in hardware.
• The module’s microcontroller takes the second byte from RAM and drops it into the UART.

And it does this 1000 times until the entire kilobyte flies down the wires to the factory floor.

How does the cycle end?

When the module’s microcontroller feeds the last byte to the UART block and sees the “Transmission Complete” (TC) flag, it realizes: “The kilobyte has been sent”.

Then, this tiny controller sends a message over the high-speed bus to the main PLC CPU: “Boss, I’m all done!”

The block in TIA Portal drops the BUSY signal and outputs DONE = TRUE for one clock cycle. The main PLC CPU sees this and understands: “Excellent, we can send the next kilobyte”.

Summary: How do we prevent overflows?

The PLC does not overflow the expansion module because it watches the high-level BUSY flag (implemented in software by Siemens engineers over the high-speed bus).

The expansion module does not overflow its UART block because UART transmission within the module is interrupt-driven, based on the TXE status flag. When TXE=1, the peripheral generates an interrupt, and the handler loads the next byte into the transmit register.

The “handler” in this case is a piece of firmware code (ISR, Interrupt Service Routine) executed by the CPU when the hardware (UART) raises a TXE interrupt.