0% found this document useful (0 votes)
6 views16 pages

Lab2 DeviceNetwork

This document outlines a lab exercise on implementing two-way communication using the SPI protocol between a Master and two Slaves. The Master sends messages to each Slave upon button presses, and each Slave responds with a confirmation message. The report includes hardware and software setups, code examples, and testing plans to ensure proper functionality and communication integrity.

Uploaded by

kiemtra3121
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views16 pages

Lab2 DeviceNetwork

This document outlines a lab exercise on implementing two-way communication using the SPI protocol between a Master and two Slaves. The Master sends messages to each Slave upon button presses, and each Slave responds with a confirmation message. The report includes hardware and software setups, code examples, and testing plans to ensure proper functionality and communication integrity.

Uploaded by

kiemtra3121
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 16

THE UNIVERSITY OF DANANG

UNIVERSITY OF SCIENCE AND TECHNOLOGY


Faculty of Advanced Science and Technology

LAB 2

Instructor : Nguyen Huynh Nhat Thuong


Class : 21ES
Student : Phan Dinh Quy
Tran Dinh Bao
Truong Phuoc Thinh
Le Dinh Bao Tin

Da Nang, 20𝑡ℎ May, 2025


I. Requirements
This report outlines a lab exercise from the Device Network course, centered on
implementing two-way communication using the SPI protocol between one Master (A) and
two Slaves (B and C). The Master (A) has two push buttons, each triggering a unique
message to a specific Slave:
• Button 1: Sends "A hello B" to Slave B.
• Button 2: Sends "A hello C" to Slave C.
In response, each Slave sends a confirmation back to the Master:
• Slave B replies with "B hello A".
• Slave C replies with "C hello A".

II. Hardware Setup


1. Diagram
a. Wiring Diagram

Figure 1a. Wiring Diagram


b. Block Diagram
Figure 1b.
Block Diagram
2. Actual Circuit

Figure 2. Actual Circuit


III. Software Setup
1. Master A
Master A is set up in SPI Master mode and uses two push buttons connected to GPIO pins
PA0 and PA1 to start communication. The SPI1 interface is configured with a clock speed
that ensures stable data transfer. Two chip select lines (CS\_Pin and CS2\_Pin) are used to
choose between Slave B and Slave C. To begin communication, the Master pulls the
corresponding CS line low and sets it high to end the communication.

Figure 3. Pinout View of Master


Enable SPI1 from the “Connectivity” menu and select the “Full-Duplex Master” mode.
Figure 4. SPI Mode Setup for Master
In STM32CubeIDE, configure the following settings:
Basic Parameters:
• Frame Format: Motorola — the standard SPI format that supports Clock Polarity
(CPOL) and Clock Phase (CPHA) for proper data synchronization.
• Data Size: 8 Bits — each SPI transfer sends or receives 1 byte of data, which is
common for most SPI devices.
• First Bit: MSB First — transmission starts with the Most Significant Bit (bit 7 down to
bit 0), as used by most SPI peripherals.
Clock Parameters:
• Prescaler (Baud Rate Divider): 64 — divides the system clock to reduce SPI speed.
For example, with an 8 MHz system clock:
SPI Clock = 8 MHz / 64 = 125 kHz
• Baud Rate: 125.0 KBits/s — a slower speed that is suitable for testing or
communication with low-speed devices such as sensors or other MCUs.
• Clock Polarity (CPOL): Low — the SPI clock remains low when idle.
• Clock Phase (CPHA): 1 Edge — data is sampled on the first clock edge, which is the
rising edge when CPOL is low.
Figure 5. Parameter Settings for Master
2. Slave B and C
Slaves B and C operate in SPI Slave mode; each connected to the Master through a separate
Chip Select (CS) line. They receive data through SPI1 and reply with predefined messages
(“B hello A” or “C hello A”). When selected by the Master, the slaves either echo the received
message or send their designated response.
Figure 6. Pinout View of Slave
Activate SPI1 from the “Connectivity” menu by selecting “Full-Duplex Slave” and enabling
“Hardware NSS Input Signal”. In this configuration, the NSS pin functions as a hardware-
controlled input:
• When NSS is low, the SPI slave is activated and ready for communication.
• When NSS is high, SPI communication is disabled.

Figure 7. SPI Mode Setup


We leave the “Preemption Priority” and “Sub Priority” settings at their default value of 0. The
SPI1 interrupt handler is triggered whenever an SPI event occurs. A lower numerical value
indicates a higher priority, allowing this interrupt to preempt others with a lower priority (higher
number). The Sub Priority of 0 helps resolve conflicts between interrupts that share the same
preemption priority, with the one having the lower sub-priority being handled first.

Figure 8. SPI NVIC Settings


In this case, navigate to the “GPIO Settings” tab and configure the following pins:
• PA4 (NSS): Acts as the chip select signal from the master to enable the slave. Set it
to Input mode. No internal pull-up or pull-down is needed if it's controlled externally.
• PA5 (SCK): This is the clock signal from the master. Set it to Input mode, as the slave
listens for clock pulses.
• PA6 (MISO): Used by the slave to send data back to the master. Configure it as
Alternate Function, since it functions as an output from the slave’s side.
• PA7 (MOSI): Carries data from the master to the slave. Set it to Input mode, allowing
the slave to receive incoming data.
Figure 9. SPI GPIO Settings
Basic Parameters:
• Frame Format: Set to Motorola, the standard SPI format that uses NSS, SCK, MISO,
and MOSI lines.
• First Bit: MSB First, meaning the most significant bit is transmitted first.
• Clock Polarity (CPOL): Low — the clock line remains low when idle (CPOL = 0).
• Clock Phase (CPHA): 1 Edge — data is captured on the first clock edge, which is the
rising edge when CPOL = 0.
Figure 10. SPI Parameter Settings
IV. Flowchart

Figure 11. The operating of system


V. Code
1. Master A
The code is added in between /* USER CODE BEGIN Includes */ and /* USER CODE END
Includes */. Insert this code in between:
#include <stdio.h>
#define sizeofBuff 12
uint8_t SPI1_TxBuff[sizeofBuff] = "Nhom 4";
uint8_t SPI1_RxBuff[sizeofBuff];
uint8_t SPI2_RxBuff[sizeofBuff];
uint8_t state = 1;

The code is added in between /* USER CODE BEGIN WHILE*/ and /* USER CODE END
WHILE*/. Insert this code in between:
if(HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_1) == 0) //Button for slave B
{
while(HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_1) == 0) {}
sprintf((char*)SPI1_TxBuff, "A hello B\n");
HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET);
HAL_SPI_TransmitReceive(&hspi1, SPI1_TxBuff, SPI1_RxBuff, sizeofBuff, 100);
HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET);
state = 1;
}
else if(HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_0) == 0)// Button for slave C
{
while(HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) == 0) {}
sprintf((char*)SPI1_TxBuff, "A hello C\n");
HAL_GPIO_WritePin(CS2_GPIO_Port, CS2_Pin, GPIO_PIN_RESET);
HAL_SPI_TransmitReceive(&hspi1, SPI1_TxBuff, SPI1_RxBuff, sizeofBuff, 100);
HAL_GPIO_WritePin(CS2_GPIO_Port, CS2_Pin, GPIO_PIN_SET);
state = 2;
}

2. Slave B and C
The code is added in between /* USER CODE BEGIN Includes */ and /* USER CODE END
Includes */. Insert this code in between:
#include <stdio.h>
#define sizeofBuff 12
uint8_t u8_SPI1_TxBuff[sizeofBuff] = "B hello A\n"; // Change to "C hello A" for Slave C
uint8_t u8_SPI1_RxBuff[sizeofBuff];

The code is added in between /* USER CODE BEGIN 0*/ and /* USER CODE END 0*/. Insert
this code in between:
void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi)
{
/* Prevent unused argument(s) compilation warning */
UNUSED(hspi);
if(hspi->Instance == SPI1)
{
HAL_SPI_TransmitReceive_IT(&hspi1, u8_SPI2_TxBuff, u8_SPI2_RxBuff, sizeofBuff);
}
sprintf((char*)u8_SPI2_TxBuff, "B hello A\n");
}

The code is added in between /* USER CODE BEGIN 2*/ and /* USER CODE END 2*/. Insert
this code in between:
HAL_SPI_TransmitReceive_IT(&hspi1, u8_SPI2_TxBuff, u8_SPI2_RxBuff, sizeofBuff);

VI. Results
1. Testing Plan
• Button Functionality Test
Pressing Button 1 on the Master sends the message "A hello B" to Slave B, and
pressing Button 2 sends "A hello C" to Slave C, with each button triggering the correct
message to the respective slave.
• Slave Response Test
Slave B responds with "B hello A" only upon receiving "A hello B," and Slave C
responds with "C hello A" only when it receives "A hello C," ensuring accurate and
specific responses from each slave.
• SPI Data Integrity Check
A logic analyzer monitors SPI communication between the Master and Slaves,
confirming that all exchanged messages are complete and free from corruption.
• Sequential Communication Test
Pressing the Master’s buttons sequentially triggers communications one after another,
with the Master handling each transaction in turn without conflicts.
• Idle State Test
When the system is powered on without pressing any buttons, no SPI communication
occurs until a button is pressed, ensuring the system remains idle as expected.
• Error Handling Test
Simulating unexpected or malformed messages, the Slaves ignore unknown
messages and do not respond incorrectly, maintaining robust error handling.
• Simultaneous Press Test
Pressing both buttons simultaneously (if feasible) allows observation of the Master’s
ability to handle message collisions or queue them properly without errors.
• Response Timing Test
The time between sending a message and receiving a response is measured,
confirming that communication completes within an acceptable timeframe, such as
under 100ms.
2. Result of Debug

Figure 12. Debug Screen of Master A when Communicating with Slave B


Figure 13. Debug Screen of Master A when Communicating with Slave C
Figure 14. Debug Screen of Slave B

Figure 15. Debug Screen of Slave C

You might also like