Files/ComputerAssignments/CA1/code/README.md

# Computer Assignment No. 1  
## Communication Protocol Simulation

**Course:** Embedded Systems (Bare‑Metal)  
**Instructor:** Dr. Mehdi Shokri‑Saz  
**Teaching Assistants:** Dr. Mohsen …  
**Assignment Designers:** Sohrab Moradi, Aryan Firoozi, Hatef Rezaei  
**Field:** Computer Engineering  
**Semester:** Second Semester 1404–1405  

---

# Project Title
**Simulation of Communication Protocols**

---

# 1. Introduction

In this assignment, we aim to make the simulation of embedded systems more realistic by **adding communication protocols** to the system.

This assignment consists of **three implementation sections**, each followed by several questions:

• Implementation of an **Address‑Based Protocol (I2C)**  
• Implementation of a **Full‑Duplex Protocol (USART)**  
• Implementation of an **I2C Multiplexer**

In the following sections, the details and expected behavior of each part are explained.

⚠ **Important:**  
Before implementing each part, carefully read the **coding guide** provided.

---

# 2. Implementation of an Address‑Based Protocol (I2C)

The provided code base creates an environment to simulate connections between different hardware components.  
Connecting two or more physical modules requires not only **hardware connections**, but also **software and protocol agreements**.

In this assignment, hardware connections are already simulated, and the goal of this section is to **add support for the I2C protocol**.

The protocol implemented here is a **simplified version of the real I2C protocol**.

---

## Hardware Requirements

The protocol requires four pins between the **sensor board** and the **microcontroller**:

• **SCL** – Clock bus  
• **SDA** – Data bus  
• **GND** – Ground  
• **VDD** – Power supply  

These pins must be connected **pairwise between the sensor and microcontroller**.

---

## I2C Communication Process

The protocol works as follows:

### Step 1
The **microcontroller writes the destination sensor address** on the SDA line.

Each sensor has a predefined address.

Example:

VL530X sensor address = **0x29 (HEX)**

---

### Step 2
If a sensor detects its own address, it sends an **ACK bit** on the SDA line.

After that, the sensor can **send the data it has received from the environment**.

---

### Step 3
Once the microcontroller receives the ACK bit, it becomes ready to **read data from the sensor**.

The sensor and microcontroller stay synchronized using the **SCL clock line**.

For simplicity in the simulator:

• The **SCL line is automatically connected to the microcontroller clock**  
• You **do not need to generate or control the clock signal**

---

## Task

You must:

1. Connect a **microcontroller and a sensor**
2. Implement the **I2C protocol**
3. Use it to **transfer data between the two devices**

The required data format is described in the **coding guide**.

---

# Questions

### 1
Since **I2C is a bus protocol**, what problems occur if **multiple sensors with the same address** are connected?

### 2
Compared to the **real I2C protocol studied in class**, mention **four general weaknesses** of this simplified implementation.

### 3
Explain the functionality of:

• `ByteVector`  
• `ByteStream`  
• `getByte`

---

# Coding Guide

The project includes:

• **ESP8266 board**  
• **VL530X sensor**

Each board has a **GPIO interface**.

Board files:

ESP8266
```
{PROJECT_DIR}/include/CPS4042/Hardwares/Boards/Esp8266.h
```

VL530X
```
{PROJECT_DIR}/include/CPS4042/Hardwares/Sensors/VL530X.h
```

---

## GPIO

The GPIO interface contains multiple pins used for different hardware functions.

For example:

• Presence of **SDA and SCL pins** indicates that the board supports **I2C communication**.

Both boards include a subclass named:

```
I2C
```

---

# Implementing the I2C Class

Your task is to implement the **I2C protocol class**.

It contains **four functions**.

---

### 1. run()

Executed automatically in every **CPU cycle**.

Inside this function you must implement the **internal logic of the protocol**, including:

• detecting addresses  
• storing data  
• handling received bits  

---

### 2. init()

Called inside the **setup() function of the sketch**.

Here you must **set the address of the sensor** you want to communicate with.

---

### 3. read() and write()

These functions act as the **protocol API**.

Inside the sketch's `loop()` you should call them using the protocol object.

Example usage is shown in the document.

---

### 4. Helper utilities

Some required functions are provided in:

```
Protocols::AbstractI2C
AbstractProtocol
```

You should use these helpers to implement the protocol.

---

# main Function

You must create instances of the boards and connect them together.

Example:

Two instances of boards are created and **linked together using Link objects**.

Important macros:

```
CPS_SET_OBJECT_NAME
CPS_SET_OBJECT_NAME_PTR
```

These help with **debugging and logging**.

Also remember to call:

```
exec()
```

at the end of the `main()` function.

This simulates **connecting two boards in the real world**.

---

# Sketch Classes

The two boards are controlled by two sketches:

• `MicroController`  
• `Sensor`

Both are subclasses of:

```
Sketch
```

These sketches simulate **Arduino‑style programming**.

They contain:

```
setup()
loop()
```

• `setup()` runs once  
• `loop()` runs repeatedly

Sketch files must be placed in:

```
{PROJECT_DIR}/include/CPS4042/Sketchs
```

---

# Sensor Behavior

The sensor must return a **random number between 0 and 4000**.

Because the protocol works with **bytes**, the number must be transmitted using:

• **2 bytes** for the number  
• **1 byte checksum**

Checksum:

```
checksum = larger_byte − smaller_byte
```

The checksum is always **non‑negative**.

On the microcontroller side:

1. Read the three bytes
2. Verify the checksum
3. If valid → print the result

Useful classes:

```
Utils/ByteStream
Units/Byte
ByteVector
getByte
```

---

# USART Full Duplex Protocol

In the second part, you must implement a simplified version of the **USART protocol**.

USART is used for **serial communication** and supports **Full Duplex communication**, meaning:

Both devices can **send and receive data simultaneously**.

---

## USART Pins

• **TX** – Transmit  
• **RX** – Receive  
• **VDD** – Power  
• **GND** – Ground

Important:

The **sensor wiring is reversed** relative to the microcontroller:

```
TX ↔ RX
```

---

# Task

Simulate a **Hard Disk device** that communicates with the microcontroller via USART.

Procedure:

1. Microcontroller sends an **address (0–255)** through TX  
2. Hard disk receives it  
3. Hard disk returns the corresponding **data through RX**

A partially implemented sketch is already provided.

---

# USART Frame Structure

Data is transmitted as **frames** consisting of:

• Start Bit  
• Data Bits  
• Parity Bit  
• Stop Bit

---

## Frame Details

### Start Bit
Normally the line is **HIGH (1)**.

To start transmission the sender pulls it **LOW (0)**.

---

### Data Bits

Usually **8 bits**.

They are transmitted **LSB first**.

This part is already implemented internally.

You only need to use:

```
write()
```

---

### Parity Bit

Used for error detection.

Types:

• Even  
• Odd

(Not required for this assignment.)

---

### Stop Bit

One or two bits with value **1**.

Indicates end of frame.

Already implemented.

You only need to listen for incoming data inside:

```
run()
```

using

```
hasBitToRead()
```

---

# Example Frame

Sending data:

```
01010101
```

Frame:

```
Start | Data | Stop
1     | 01010101 | 0
```

Transmission line:

```
1 01010101 0
```

---

# Questions

### 1
Why are **start and stop bits not confused with data bits**?

### 2
Without a clock signal, how does USART **synchronize and detect data bits**?

### 3
Is it possible to implement USART **purely in software using digital pins** if the microcontroller has no hardware USART module?

Explain your reasoning.

---

# Coding Guide

You must implement a board that supports the **USART protocol**.

This board must contain the subclass:

```
USART
```

Important settings:

Do NOT set the board frequency to **Driven**.

Set:

```
BaudRate = BaudRates::NotSpecified
BitRate = BitRates::same(BaudRates::NotSpecified)
```

You must also create required **GPIO pins**.

Place the board in:

```
Hardwares/Comm
```

Use the **VL530X constructor** as an example for installing the protocol in the processor.

The processor can manage **multiple protocols simultaneously**.

---

⚠ Important

Do NOT modify the **Transmitter class**.

Using the protocol functions correctly should avoid logic errors.

---

# Part 3 — I2C Multiplexer

In this part, several sensors must connect to the microcontroller through **I2C**.

However, sensors with **identical addresses cannot share the same I2C bus**.

Solution:

Use an **I2C Multiplexer (I2C MUX)**.

---

# System Architecture

```
Microcontroller
      │
    USART
      │
    I2C MUX
      │
Multiple I2C Channels
      │
    Sensors
```

---

# System Operation

1. Microcontroller sends a **channel selection command via USART**
2. MUX activates the selected **I2C channel**
3. Sensor communicates with the MUX through I2C
4. Sensor data goes to the MUX
5. MUX forwards the data to the microcontroller through USART

---

# Advantages of I2C MUX

• Connect multiple sensors with identical addresses  
• Prevent I2C bus conflicts  
• Easier sensor management  
• Increase number of sensors connected to system  

---

# Task

Create **at least two sensors** with different data ranges.

Example:

Sensor 1 → numbers between **0–20**  
Sensor 2 → numbers between **50–100**

Or another sensor returning **characters of a string**.

The microcontroller should:

• Use a **static counter**  
• Select sensors sequentially through the MUX  
• Read and print their data

---

You must implement:

```
I2C Mux class
```

inside:

```
Hardwares/Comm
```

Creating a **generic reusable I2C class** that can be instantiated multiple times will give **extra credit**.

---

# Questions

### 1
Explain the function **reverse()** in `Byte.h`.

Where is it used?  
Is such an operation realistic in real hardware systems?

---

### 2
Explain the difference between the functions in:

```
Bit.h
takeNthBit
```

---

### 3
Explain the function:

```
Board::attachPinToCommunicationClock
```

both in terms of **code implementation and purpose**.

---

# Final Notes

Deadline:

**1405/02/11 — 23:59**

---

### Group Work
Projects must be completed in **groups of 4**.

---

### Language and Libraries

Use:

• **C++ (C++20)**  
• **Boost library**

The simulator uses **Boost header‑only modules**, so you do not need to build Boost.

---

### Compilation

If you are using Windows, a **precompiled build** is provided.

Make sure the **include paths are correctly set in `CMakeLists.txt`**.

---

### Grading

Part of your grade depends on:

• Clean code structure  
• Clear documentation  
• A well‑written report

Submissions **without a report will not be graded**.

Reports can be written in:

• **Markdown (.md)**  
• **Word**

---

### Academic Integrity

The goal is learning. Please complete the assignment yourselves and collaborate properly with your team.

---

### Questions

Ask questions in the **discussion forum** when possible.

For private questions contact:

Aryan.Firoozi@ut.ac.ir  
Hatef.Rezaee@ut.ac.ir  
M.Moradi1998@ut.ac.ir