Unit 5: Serial Communication & Industrial Interfaces - Subjective Questions

UART (Universal Asynchronous Receiver/Transmitter) is an asynchronous serial communication protocol used to exchange data between two devices without a shared clock signal.

A typical UART frame consists of:

• Idle state: The transmission line remains at logic HIGH when no data is being sent.
• Start bit: A logic LOW bit indicating the beginning of a frame.
• Data bits: Usually 5 to 9 bits, with 8 bits being the most common. The least significant bit is generally transmitted first.
• Parity bit: An optional error-detection bit. It may use even, odd, mark, or space parity.
• Stop bit: One or two logic HIGH bits indicating the end of the frame.

For a frame containing 1 start bit, 8 data bits, no parity, and 1 stop bit, the format is called 8N1. Both communicating devices must use the same baud rate, number of data bits, parity configuration, and stop-bit configuration.

Baud rate represents the number of signal symbols transmitted per second. In a basic UART system, one symbol carries one bit, so the baud rate is approximately equal to the bit rate.

In the 8N1 format, each byte requires:

• 1 start bit
• 8 data bits
• 0 parity bits
• 1 stop bit

Therefore, the number of bits per byte is:

For 100 bytes:

The transmission time is:

Thus, the approximate transmission time is 104.2 ms. This calculation excludes software delays, buffering delays, and flow-control overhead.

I2C (Inter-Integrated Circuit) is a synchronous, two-wire serial protocol used for communication between integrated circuits and embedded devices.

Its two signal lines are:

• SDA (Serial Data): Carries addresses, data, and acknowledgment bits.
• SCL (Serial Clock): Carries the clock signal generated by the controller or master.

Important characteristics include:

• Multiple controllers and multiple target devices can share the same bus.
• Each target is identified by a unique 7-bit or 10-bit address.
• SDA and SCL generally use open-drain outputs.
• External pull-up resistors are required to bring the lines to logic HIGH.
• Data on SDA should remain stable while SCL is HIGH, except during START and STOP conditions.
• Each byte is followed by an acknowledgment bit.

A transaction generally includes a START condition, target address, read/write bit, acknowledgment, one or more data bytes, and a STOP condition.

The important signaling conditions in I2C are:

• START condition: Generated when SDA changes from HIGH to LOW while SCL remains HIGH. It indicates that the bus controller is beginning a transaction.
• STOP condition: Generated when SDA changes from LOW to HIGH while SCL remains HIGH. It releases the bus after the transaction.
• ACK: After receiving eight bits, the receiver pulls SDA LOW during the ninth clock pulse. This confirms successful reception.
• NACK: The receiver leaves SDA HIGH during the ninth clock pulse. It may indicate an invalid address, unavailable device, completed read operation, or inability to accept more data.
• Repeated START: A new START condition is generated without first issuing a STOP condition. It allows the controller to retain control of the bus and change the direction of communication.

For example, when reading a register, a controller may first write the register address, generate a repeated START, and then read the register data without allowing another controller to acquire the bus.

SPI (Serial Peripheral Interface) is a synchronous serial protocol commonly used for high-speed, short-distance communication between a controller and one or more peripheral devices.

The main SPI signals are:

• SCLK: Clock signal generated by the controller.
• MOSI: Carries data from the controller to the peripheral.
• MISO: Carries data from the peripheral to the controller.
• CS or SS: Selects a particular peripheral, usually by being driven LOW.

SPI supports full-duplex communication. During each clock pulse:

1. The controller shifts one bit onto MOSI.
2. The selected peripheral shifts one bit onto MISO.
3. Both devices sample the incoming bits according to the configured clock polarity and phase.
4. After the required number of clock cycles, data has moved in both directions.

SPI does not define addressing or acknowledgment at the protocol level. Separate chip-select lines or external decoding logic are commonly used to select peripherals.

UART, I2C, and SPI can be compared as follows:

Typical applications:

• UART: Debug consoles, GPS modules, Bluetooth modules, and communication between two controllers.
• I2C: Sensors, real-time clocks, EEPROMs, LCD modules, and low-speed peripherals.
• SPI: Displays, ADCs, DACs, flash memories, and high-speed sensors.

The final choice depends on required speed, wiring limits, device count, communication distance, and hardware support.

SPI timing is controlled by clock polarity (CPOL) and clock phase (CPHA).

• CPOL determines the idle level of SCLK.
  • CPOL = 0: SCLK is LOW when idle.
  • CPOL = 1: SCLK is HIGH when idle.
• CPHA determines which clock transition is used to sample data.
  • CPHA = 0: Data is sampled on the first clock transition and changed on the second.
  • CPHA = 1: Data is changed on the first transition and sampled on the second.

The four modes are:

The controller and peripheral must be configured for the same mode. An incorrect mode can cause shifted, corrupted, or unstable data because bits are sampled at the wrong clock transition.

Bus arbitration is the process used to determine which controller is allowed to control a shared communication bus when two or more controllers attempt to communicate simultaneously.

In I2C, arbitration is possible because SDA and SCL use open-drain outputs. A device can pull a line LOW but cannot actively force it HIGH. Therefore, logic LOW dominates logic HIGH.

The arbitration process is:

1. Multiple controllers may generate a START condition at nearly the same time.
2. Each controller transmits its address and data while monitoring SDA.
3. If a controller attempts to transmit HIGH but detects LOW, another controller is transmitting a dominant LOW.
4. The controller detecting the mismatch loses arbitration.
5. The losing controller stops transmitting without corrupting the winning transaction.
6. The winning controller continues communication.

Arbitration is non-destructive because the valid transaction from the winning controller is not interrupted. Clock synchronization also ensures that controllers operate using a common effective SCL timing.

I2C primarily supports two addressing methods:

• 7-bit addressing: Provides 128 possible bit patterns, although some values are reserved. It is the most widely used method.
• 10-bit addressing: Provides a larger address space and is used when more target addresses are required.

In a 7-bit transaction, the controller sends the target address followed by a read/write bit:

• Read/write bit = 0 indicates a write operation.
• Read/write bit = 1 indicates a read operation.

An address conflict occurs when two devices on the same bus respond to the same address. Common causes are:

• Two identical modules using the same fixed address.
• Incorrect configuration of address-selection pins.
• Confusion between a 7-bit address and the 8-bit address byte containing the read/write bit.

Possible solutions include:

• Changing hardware address pins or jumpers.
• Configuring a programmable address.
• Using an I2C multiplexer or bus switch.
• Placing conflicting devices on separate I2C controllers.
• Power-enabling one device at a time and assigning new addresses, if supported.

A protocol analyzer is a hardware or software tool that captures communication signals and decodes them into protocol-level information such as addresses, commands, data bytes, acknowledgments, and errors.

A logic analyzer can debug the protocols as follows:

• UART: Connect channels to TX and RX, configure the baud rate and frame format, and inspect decoded bytes, parity errors, framing errors, and timing mismatch.
• I2C: Connect channels to SDA and SCL, then inspect START and STOP conditions, addresses, read/write bits, ACK/NACK responses, repeated START conditions, and clock stretching.
• SPI: Connect channels to SCLK, MOSI, MISO, and CS. Configure CPOL, CPHA, word size, and bit order, then inspect transmitted and received data.

A typical debugging procedure is:

1. Connect analyzer ground to the circuit ground.
2. Connect probes without excessively loading the bus.
3. Select a suitable sample rate.
4. Configure the correct protocol decoder.
5. Trigger on a relevant event.
6. Compare the captured waveform and decoded data with the expected sequence.

The tool helps separate electrical problems from software or protocol-configuration problems.

Common serial communication faults include:

• Incorrect baud rate, clock frequency, or SPI mode
• Reversed UART TX and RX connections
• Missing common ground
• Incorrect device address
• Missing or unsuitable I2C pull-up resistors
• Signal noise, ringing, or excessive cable length
• Wrong voltage levels
• Bus contention
• Incorrect bit order or word length
• Buffer overflow or data loss
• Missing UART parity or stop-bit configuration
• Incorrect RS485 termination or biasing

A systematic diagnosis should include:

1. Verify power and ground: Confirm voltage levels and a common reference.
2. Inspect wiring: Check pin assignments, continuity, and connector orientation.
3. Check configuration: Verify baud rate, address, CPOL, CPHA, parity, and data length.
4. Measure electrical signals: Use an oscilloscope to inspect voltage amplitude, rise time, ringing, and noise.
5. Decode the protocol: Use a logic analyzer to examine frames and errors.
6. Reduce the system: Test with one controller and one peripheral.
7. Use known test data: Send repetitive patterns such as alternating bits or known text.
8. Check software buffers: Monitor overruns, timeouts, and interrupt latency.

This layered approach isolates physical, protocol, and software faults efficiently.

RS485 is an electrical standard designed for robust serial communication over relatively long distances and in electrically noisy industrial environments.

Its main features are:

• Differential signaling: Data is represented by the voltage difference between lines A and B. Noise coupled equally onto both wires is largely rejected by the receiver.
• Multi-point operation: Multiple transmitters and receivers can share the same bus, subject to transceiver loading limits.
• Bus topology: A linear daisy-chain topology is preferred. Long star branches should be avoided because they create reflections.
• Twisted-pair cable: Helps maintain impedance and improves rejection of electromagnetic interference.
• Termination: Resistors approximately equal to the cable's characteristic impedance, commonly around , are placed at both physical ends of a long bus.
• Biasing: Pull-up and pull-down resistors establish a known idle state when no transmitter is active.
• Direction control: In two-wire half-duplex systems, the driver-enable signal controls whether a node transmits or receives.

RS485 defines the electrical layer only. A higher-level protocol, such as Modbus RTU, is required to define device addressing and message formats.

The three terms represent different concepts:

• UART: A digital communication peripheral that generates and receives asynchronous serial data at logic-level voltages.
• RS232: A point-to-point electrical standard using single-ended signaling and positive and negative voltage levels.
• RS485: A differential electrical standard supporting longer distances, better noise immunity, and multiple nodes.

A microcontroller UART cannot normally be connected directly to RS485 lines because:

• UART uses logic-level TX and RX signals referenced to ground.
• RS485 represents data using the differential voltage between A and B.
• UART pins cannot safely drive the cable impedance or tolerate RS485 bus voltages.
• A shared half-duplex network requires transmitter direction control.

An RS485 transceiver performs the required conversion:

• Converts UART TX logic into differential A/B signals.
• Converts differential A/B signals back into UART RX logic.
• Provides appropriate output drive strength and input protection.
• Provides driver-enable and receiver-enable controls.

Thus, UART defines byte transmission inside the controller, while RS485 defines how those bits are electrically transported over the industrial bus.

Modbus RTU is a request-response industrial protocol commonly transported over RS485. A typical frame contains:

1. Device address: Identifies the target server or slave. Address 0 is generally used for broadcast messages.
2. Function code: Specifies the requested operation, such as reading coils, reading holding registers, or writing registers.
3. Data field: Contains register addresses, quantities, values, or returned data, depending on the function code.
4. CRC field: A 16-bit cyclic redundancy check used to detect transmission errors.

The general frame is:

Modbus RTU uses silent time intervals to separate frames. A gap of at least approximately 3.5 character times indicates a frame boundary. Within a frame, a large inter-character delay may cause the receiver to reject the message.

When a server reports an exception, it returns the function code with its most significant bit set and includes an exception code describing the error.

A microcontroller can interface with a Modbus RTU sensor through the following arrangement and procedure:

Hardware arrangement:

• Connect the microcontroller UART TX and RX pins to an RS485 transceiver.
• Connect the transceiver's differential A and B terminals to the industrial bus.
• Control the transceiver's driver-enable pin using a GPIO pin.
• Use twisted-pair cable, proper grounding practices, end termination, and fail-safe biasing where required.

Communication procedure:

1. Configure UART parameters such as baud rate, data bits, parity, and stop bits to match the sensor.
2. Construct a Modbus request containing the sensor address, function code, register address, and quantity.
3. Calculate and append the Modbus CRC.
4. Enable the RS485 transmitter.
5. Send the complete request through UART.
6. Wait until the last stop bit has physically left the UART.
7. Disable the transmitter and switch to receive mode.
8. Receive the response before the timeout expires.
9. Validate the address, function code, byte count, and CRC.
10. Convert register values into engineering units using the manufacturer's scaling information.

The software should also handle timeouts, exception responses, retries, invalid CRC values, and byte-order differences.

Modbus RTU uses a 16-bit cyclic redundancy check, commonly called CRC-16 Modbus, to detect corrupted frames.

The basic generation procedure is:

1. Initialize a 16-bit CRC register to hexadecimal FFFF.
2. XOR the CRC register with each incoming data byte.
3. For each byte, perform eight iterations.
4. In each iteration, examine the least significant bit.
5. Shift the CRC register one bit to the right.
6. If the removed bit was 1, XOR the shifted value with the polynomial value hexadecimal A001.
7. Repeat for every frame byte except the received CRC bytes.
8. Append the low-order CRC byte first, followed by the high-order byte.

To validate a received frame:

• Separate the message bytes from the received CRC.
• Recalculate the CRC using the address, function, and data fields.
• Compare the calculated low and high bytes with the received CRC bytes.
• Accept the frame only if the values match and other checks, such as address and length, are valid.

A valid CRC indicates that transmission errors are unlikely, but it does not provide encryption, authentication, or protection against intentionally modified messages.

An I2C character LCD module commonly combines an HD44780-compatible LCD with an I2C I/O expander such as the PCF8574.

Hardware interface:

• Connect the module's VCC and GND to the appropriate supply.
• Connect SDA and SCL to the microcontroller's I2C pins.
• Ensure suitable pull-up resistors are present on SDA and SCL.
• Set the module address using hardware jumpers if available.

Operation:

• The microcontroller sends a byte to the I/O expander.
• Expander outputs control the LCD data lines and control signals such as RS, enable, and backlight.
• The LCD is commonly operated in 4-bit mode, so each command or character is sent as two nibbles.
• The enable signal is pulsed for each nibble so that the LCD accepts it.

Initialization sequence:

1. Wait for LCD power stabilization.
2. Configure the display for 4-bit operation.
3. Select the number of lines and character format.
4. configure display, cursor, and blinking options.
5. Clear the display and select the entry mode.
6. Send character data and cursor-position commands.

Using an I2C adapter reduces the number of required microcontroller pins but introduces additional communication and software overhead.

Small I2C OLED modules commonly use controllers such as the SSD1306.

Interfacing steps:

1. Connect VCC, GND, SDA, and SCL.
2. Confirm that the supply and I/O voltage levels are compatible.
3. Determine the I2C address, commonly 0x3C or 0x3D, using documentation or an address scanner.
4. Initialize the I2C peripheral at a supported clock rate.
5. Send controller commands to configure multiplex ratio, addressing mode, charge pump, contrast, orientation, and display state.
6. Send pixel data to the display memory.

A framebuffer is an array in microcontroller RAM representing the screen pixels. For a monochrome display of width and height , the required memory is:

For a monochrome OLED:

Graphics and text are drawn into the framebuffer, after which the buffer is transferred to the OLED. Full-buffer updates simplify drawing but consume RAM and bus bandwidth. Partial updates can reduce transfer time when only a small region changes.

The two display technologies differ significantly:

A character LCD is suitable when low cost, simple text output, and minimal RAM usage are important. An OLED is preferable when compact size, high contrast, graphics, and flexible layout are required.

A high-speed data logger must acquire, timestamp, buffer, and store data continuously without losing samples.

Suppose there are sensors, each sampled at samples per second, with bytes per sample. The raw throughput is:

For 8 sensors sampled at samples/s with 2 bytes per sample:

Protocol headers, timestamps, checksums, file-system overhead, and safety margin must also be included. A practical design should provide storage bandwidth significantly greater than the calculated average rate.

Proposed architecture:

• Use hardware timers to generate a precise sampling interval.
• Use ADC triggering or synchronous digital interfaces for deterministic acquisition.
• Use DMA to move samples into memory with minimal CPU intervention.
• Use double buffering or a ring buffer so acquisition and storage occur concurrently.
• Add timestamps from a high-resolution timer or real-time clock.
• Store data in blocks rather than writing individual samples.
• Use a high-speed SPI SD interface, eMMC, flash memory, or a host link with sufficient sustained throughput.
• Add sequence numbers and checksums to detect missing or corrupted records.

Loss-prevention techniques:

• Reserve enough RAM for temporary storage latency.
• Preallocate files to reduce file-system delays.
• Monitor buffer occupancy and overrun counters.
• Avoid slow display updates or blocking communication in the acquisition path.
• Use priority-based interrupts and minimize interrupt execution time.
• Perform graceful file synchronization and maintain recovery metadata.

The system should be tested using worst-case sustained rates rather than only short burst-transfer benchmarks.