| Name | Size | Uploaded | Xet hash |
|---|---|---|---|
| .git | 112 items | ||
| include | 28 items | ||
| src | 1 items | ||
| CMakeLists.txt | 623 Bytes xet | 8ebaaba4 | |
| README.md | 11.6 kB xet | 6824d4f3 |
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:
- Connect a microcontroller and a sensor
- Implement the I2C protocol
- 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:
- Read the three bytes
- Verify the checksum
- 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:
- Microcontroller sends an address (0–255) through TX
- Hard disk receives it
- 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
- Microcontroller sends a channel selection command via USART
- MUX activates the selected I2C channel
- Sensor communicates with the MUX through I2C
- Sensor data goes to the MUX
- 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
- Total size
- 5.54 GB
- Files
- 51,854
- Last updated
- Sep 12
- Pre-warmed CDN
- US EU US EU