12. Networking and communications

Assignment on Embedded Networking and Communications

Group assignment:

• Send a message between two projects
• Document your work to the group work page and reflect on your individual page what you learned

Individual assignment:

• design, build and connect wired or wireless node(s) with network or bus addresses and a local input and/or output devices

Learning outcomes

• Demonstrate workflows used in network design
• Implement and interpret networking protocols and/or communication protocols

Have you answered these questions?

• Linked to the group assignment page
• Documented your project and what you have -learned from implementing networking and/or communication protocols.
• Explained the programming process(es) you used.
• Ensured and documented that your addressing for boards works
• Outlined problems and how you fixed them.
• Included design files (or linked to where they are located if you are using a board you have designed and fabricated earlier) and original source code.
• Included a ‘hero shot’ of your network and/or communications setup

Basic Definition of Networking and Communications

IUART, USART, SERCOM, PIO, bit-bang

1. Wired Communication Wired communication refers to the use of physical conductors (typically copper) to transmit data between devices. This form of communication is often chosen in embedded systems for its reliability, low latency, and resistance to electromagnetic interference (EMI) compared to wireless options.

   Academic reference:

   • [Tanenbaum & Wetherall, Computer Networks, 5th Ed., Pearson, 2011] provides foundational knowledge on physical and data link layer communication.

   • IEEE 802.3 standards cover Ethernet as a common wired protocol.

2. UART (Universal Asynchronous Receiver/Transmitter) UART is a hardware module used for asynchronous serial communication between devices. It does not use a shared clock signal; instead, it relies on baud rate agreement between transmitter and receiver. UART typically uses a full-duplex configuration with TX (Transmit) and RX (Receive) lines.

Key characteristics:

• Start and stop bits frame each data byte.

• Often used in debugging, GPS, Bluetooth modules, and RS-232/TTL serial communication.

Guide material:

• ARM Cortex-M microcontroller datasheets (e.g., STM32, NXP Kinetis)

Atmel AVR Microcontroller Datasheet, Atmel Corporation

[Silberschatz, Galvin, Gagne, Operating System Concepts, Wiley, for device communication basics]

1. USART (Universal Synchronous/Asynchronous Receiver/Transmitter) USART extends UART by supporting synchronous communication, where a shared clock line is used (along with data lines) for precise timing. This allows higher data rates and better synchronization, especially in master-slave configurations.

   Applications:

   • Interfacing with synchronous peripherals

   • Advanced embedded system communications (where noise immunity and speed are critical)

   Guide material:

   • SAM D21/DA1 Family Data Sheet, Microchip Technology Inc.

   • Embedded Systems: Introduction to the MSP432 Microcontroller, Jonathan W. Valvano, for USART applications

2. SERCOM (Serial Communication Interface) SERCOM is a modular communication peripheral available in Microchip/Atmel SAM series MCUs, allowing each SERCOM instance to be configured dynamically as I²C, SPI, or USART. This flexibility enables efficient pin usage and peripheral mapping.

   Advantages:

   • Pin multiplexing

   • Software-defined protocol assignment

   Resource optimization in constrained systems

   Technical reference:

   • SAM D21 Family Datasheet, Section 20: SERCOM

   • Microchip Developer Help on SERCOM configuration

3. PIO (Programmable I/O) PIO (Programmable I/O) is a distinctive feature of the Raspberry Pi RP2040 microcontroller. It allows the creation of custom hardware-level protocols using state machines and a simple, low-level instruction set. Unlike fixed-function hardware peripherals (e.g., UART), PIO can implement custom waveforms or emulate protocols not natively supported by the MCU.

   Applications:

   • Software-defined UART, I²C, SPI

   • Signal decoding (e.g., infrared, WS2812 LED driving)

   • Precise bit-timing control

   Academic-level guide:

   • RP2040 Datasheet, Raspberry Pi Foundation

   Getting Started with PIO on RP2040, Raspberry Pi Documentation: https://www.raspberrypi.com/documentation/pico

4. Bit-Banging Bit-banging is a method of implementing serial communication protocols entirely in software by manually toggling GPIO (General Purpose Input/Output) pins. While versatile, it is CPU-intensive and highly timing-dependent, limiting its use to low-speed or resource-constrained scenarios.

   Common uses:

   • Emulating UART, I²C, or SPI when hardware support is unavailable

   • Initial bootloader communication or sensor interfacing

   Challenges:

   • No buffering

   • Timing jitter due to interrupts or task switching

   References:

   • [Embedded Systems Design with the Atmel AVR Microcontroller, Han-Way Huang, Cengage Learning]

   • [Real-Time Embedded Systems: Design Principles and Engineering Practices, Xiaocong Fan]

RS Standards for Asynchronous Serial Communication

The RS (Recommended Standard) family, developed by the Electronic Industries Association (EIA), defines electrical characteristics and signaling for serial communication. Below are the most widely used:

1. RS-232 (Recommended Standard 232)

   • Developed: 1960s

   • Wiring: Single-ended (ground referenced)

   • Voltage levels:

   • Logic 1 (mark): −3 to −15 V

   • Logic 0 (space): +3 to +15 V (Note: inverted logic compared to TTL)

   • Distance: Up to 15 meters (50 feet)

   • Speed: Up to 115.2 kbps typically

   • Wiring: Point-to-point (1 transmitter, 1 receiver)

   • Connector: DB-9 or DB-25

   • Use Cases: Legacy PC serial ports, modems, CNC machines

   • Reference:

   • TIA/EIA-232-F standard

   • Embedded Systems: Real-Time Interfacing to ARM Cortex-M Microcontrollers, Valvano, J. W.

2. RS-422 (Recommended Standard 422)

   • Developed: 1978 (as an improvement over RS-232)

   • Wiring: Differential (balanced pair)

   • Voltage levels: ±2V differential signals

   • Distance: Up to 1,200 meters (4,000 feet)

   • Speed: Up to 10 Mbps (short distances)

   • Topology: One transmitter, up to 10 receivers (multi-drop, not multi-master)

   • Use Cases: Industrial automation, PLC communication, long-distance device control

   • Advantages:

   • Better noise immunity and longer distance due to differential signaling

   • Higher speeds than RS-232

   Reference:

   • TIA/EIA-422-B specification

   • National Instruments RS-422/485 Guide

3. RS-485 (Recommended Standard 485)

   • Developed: 1983

   • Wiring: Differential (like RS-422)

   • Voltage levels: ±1.5V typical differential

   • Distance: Up to 1,200 meters (at lower baud rates)

   • Speed: Up to 10 Mbps (shorter cables)

   • Topology: Multi-point (up to 32 drivers and 32 receivers per bus)

   • Duplex: Supports half-duplex (2-wire) and full-duplex (4-wire)

   • Use Cases: Industrial networks (Modbus, Profibus), HVAC, lighting control, building automation

   • Advantages:

   • Supports multi-master communication

   • Robust against noise and reflections

   • Cost-effective bus architecture

   Reference:

   • TIA/EIA-485-A standard

   • Industrial Communication Systems, Bogdan M. Wilamowski, J. David Irwin

Experiments on Networking and Communications

Experiment with I2C - synchronous serial

I2C - synchronous serial

I2C - synchronous serial:

In this experiment, I set up I2C communication between two Arduino Uno boards, with one configured as the master and the other as the slave. I connected the SDA and SCL lines (usually pins A4 and A5 on the Uno) between the two boards, along with a common ground. The master Arduino was connected to my computer via USB, while the slave was powered through another USB cable. Using the Wire library, I programmed the master to continuously request one byte of data from the slave and display it on the Serial Monitor.

On the software side, the slave Arduino was assigned the I2C address 0x08 and programmed to respond with a byte of data each time a request came from the master. I used the Wire.onRequest() function to handle sending the data. The master’s Serial Monitor showed it successfully receiving values like 61 and 62, while the slave’s monitor showed it sending the same values. This confirmed that the I2C connection and communication were functioning correctly, allowing for consistent and reliable data exchange between the two boards.

Experiment with UART - Wired

UART - Wired

UART - Wired:

Arduino Code:

``` void setup() { Serial.begin(9600); // Start serial communication pinMode(13, OUTPUT); // Use onboard LED }

void loop() { if (Serial.available()) { // Check if data is available from Bluetooth incomingData = Serial.read(); // Read the character if (incomingData == ‘1’) { digitalWrite(13, HIGH); // Turn LED ON Serial.println(“LED ON”); } else if (incomingData == ‘0’) { digitalWrite(13, LOW); // Turn LED OFF Serial.println(“LED OFF”); } else { Serial.println(“Unknown command”); } } }

```

In this experiment, I explored UART (Universal Asynchronous Receiver/Transmitter) communication using an Arduino Uno and a Bluetooth module (likely an HC-05 or HC-06). The Bluetooth module was connected to the Arduino’s TX and RX pins (usually pins 1 and 0, respectively). The module was also powered using the 5V and GND pins from the Arduino. Once everything was connected, the module powered up and was ready to communicate wirelessly with a paired device, such as a smartphone or computer with a serial terminal app.

I programmed the Arduino to send and receive serial data using the Serial.begin() function to initialize UART communication. Data sent from the Bluetooth device appeared on the Serial Monitor and vice versa. In the test, I used a simple command to toggle an LED on the Arduino board using messages sent via Bluetooth. The video confirms the real-time interaction: when specific characters were sent from the paired device, the onboard LED turned on or off accordingly. This successful experiment demonstrated how UART allows wireless control and communication between Arduino and external devices using a Bluetooth module.

Wiring Summary:

• VCC → 5V (Arduino)
• GND → GND
• TX (Bluetooth) → RX (Arduino pin 0)
• RX (Bluetooth) → TX (Arduino pin 1)

ESP32 via HTTP to WIFi

ESP32 via HTTP to WIFi

ESP32 via HTTP to WIFi:

Code:

```

include

include

// Replace with your network credentials const char ssid = “YOUR_SSID”; const char password = “YOUR_PASSWORD”;

// Create an instance of the web server running on port 80 WebServer server(80);

// Define GPIO pins to control const int led1 = 5; const int led2 = 18;

void handleRoot() { server.send(200, “text/html”, R”rawliteral( <!DOCTYPE html>

ESP32 Web Server

GPIO 5 - ON

GPIO 5 - OFF

GPIO 18 - ON

GPIO 18 - OFF

)rawliteral”); }

void setup() { Serial.begin(115200); pinMode(led1, OUTPUT); pinMode(led2, OUTPUT);

// Connect to Wi-Fi WiFi.begin(ssid, password); Serial.print(“Connecting to WiFi”); while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print(“.”); } Serial.println(“\nConnected to WiFi”); Serial.println(WiFi.localIP());

// Define HTTP endpoints server.on(“/”, handleRoot); server.on(“/on1”, { digitalWrite(led1, HIGH); server.sendHeader(“Location”, “/”); server.send(303); }); server.on(“/off1”, { digitalWrite(led1, LOW); server.sendHeader(“Location”, “/”); server.send(303); }); server.on(“/on2”, { digitalWrite(led2, HIGH); server.sendHeader(“Location”, “/”); server.send(303); }); server.on(“/off2”, { digitalWrite(led2, LOW); server.sendHeader(“Location”, “/”); server.send(303); });

// Start the server server.begin(); }

void loop() { server.handleClient(); }

```

In this experiment, I used an ESP32 development board to create a simple web server that controls GPIO pins over Wi-Fi using a web interface. After uploading the code via Arduino IDE or PlatformIO in VS Code, the ESP32 connected to a local Wi-Fi network. Once connected, it hosted a webpage accessible via the ESP32’s IP address (displayed in the Serial Monitor). This webpage contained buttons labeled “ON” that allowed me to control the state of two GPIO pins on the ESP32 remotely from any device on the same network.

The web interface displayed in the browser confirms that the ESP32 is serving the page correctly. Each button sends an HTTP GET request to the ESP32, which the ESP32 processes to switch the state of the corresponding GPIO pin. In the second image, the code visible in VS Code uses the WiFi.h and WebServer.h libraries to establish the connection and handle HTTP requests. This demonstrates the ESP32’s ability to function as a low-cost, wireless IoT server, making it ideal for smart home or automation projects.