Up next in 10
STM32 UART #2 — Send Data Like a Pro with Interrupts & DMA
89 views
Jan 6, 2024
In this video, we dive deep into **STM32 UART communication** and learn how to transmit data using **interrupts and DMA (Direct Memory Access)**. This approach allows your microcontroller to send data efficiently without blocking the CPU, making your embedded projects faster and more responsive. You’ll learn: ✅ How to configure UART with interrupts in STM32CubeMX ✅ How to set up DMA for UART transmission ✅ How to combine DMA & interrupts for non-blocking communication ✅ Complete HAL code walkthrough for STM32 UART TX with DMA ✅ Practical example running on STM32 using CubeIDE This is the **second part** of the STM32 UART tutorial series, so make sure to check out the other videos for a complete learning path. **📂 Download the Project Files:** 🔗 [https://controllerstech.com/stm32-uart-2-use-interrupt-dma-to-transmit-data/] **📺 Suggested Videos in the STM32 UART Series:** 1️⃣ **Part 1:** [STM32 UART – Transmit Data using Polling](https://youtu.be/KdXSRyPCYuM) 2️⃣ **Part 3:** [STM32 UART – Receive Data using Interrupt & DMA](https://youtu.be/U-NmsOgNB8c) #STM32 #UART #STM32CubeIDE #STM32Tutorial #DMA #Interrupt #EmbeddedSystems #MicrocontrollerProgramming #STM32CubeMX #HAL #Controllerstech #STM32F4 #STM32F1 #STM32Projects #EmbeddedC #SerialCommunication #STM32DMA #STM32Interrupt #IoT #DMAUART
View Video Transcript
0:01
[Music]
0:09
hello and welcome to controllers Tech
0:12
this is the second video in the stdm 32
0:15
uart series and today we will continue
0:18
sending the data we will use the
0:20
interrupt and the dma to send data to
0:23
the serial console on the computer I
0:26
have already covered the basic
0:28
configuration in the previous video so I
0:30
will skip that part in today's video I
0:34
will only focus on sending the data
0:36
using interrupt and dma this is the
0:39
project from the previous video and I
0:41
will continue with it in today's video
0:44
Also let's open the cube MX
0:47
configuration file to demonstrate the
0:50
advantage of using interrupt and dma we
0:53
would need to run some other process
0:55
also so I am setting the pin pa5 as the
0:58
output which is connected to the onboard
1:01
LED we will monitor this led as some
1:04
continuous process in the code go to the
1:08
usart 2 nvic Tab and enable the global
1:12
interrupt I am not making any changes to
1:15
the parameters as we will use the same
1:18
configuration as the previous video
1:20
Let's also enable the dma we are sending
1:24
the data so select the usart
1:27
2tx there are different DM is available
1:30
in the MCU and dma1 stream 6 got
1:34
selected for this purpose the data
1:36
direction is memory to peripheral as we
1:38
are sending the data from memory to the
1:41
usart the dma can be used in the normal
1:44
mode or the circular mode I will
1:47
demonstrate both but let's leave it to
1:49
the normal mode for now the data width
1:52
is set to bite as we can transfer one
1:55
byte at a time in the uart after sending
1:58
each data BTE the memory address will be
2:00
incremented automatically so leave this
2:03
option checked that is all the
2:05
configuration we need click save to
2:08
generate the project or right here you
2:11
can see the usart 2 dma Handler got
2:15
defined now first we will see why we
2:17
need to use the interrupt or dma in the
2:20
first place let's define an array of 10
2:23
kilobytes which we will end via the uart
2:27
now after everything is initialized fill
2:30
the array with some
2:37
data we will send the data in the while
2:39
loop so modify the U Transit function to
2:42
send the array we defined the timeout is
2:46
set to H Max delay this means the
2:48
function will never time out basically
2:51
we are allowing the U to take as much
2:53
time as possible to send the data now
2:56
toggle the LED and give a delay of 5 00
3:01
milliseconds basically we are sending
3:03
the data in the blocking mode so if the
3:05
data transfer takes more time the LED
3:08
will take more than 500 milliseconds to
3:11
Blink let's build the code now all right
3:15
there are no errors so let's flash it to
3:18
the
3:20
board here you can see the LED is
3:23
definitely taking more than 500
3:25
milliseconds to
3:27
Blink this is because the uart takes a
3:29
of time to transfer 10 kiloby of the
3:32
data we can see the data on the console
3:36
and it is arriving in groups every 500
3:39
milliseconds the LED does not blink at
3:42
the required rate sending a large amount
3:45
of data in the Blocking Mode is not a
3:47
good idea as it delays the rest of the
3:50
processes this is because the CPU needs
3:52
to wait for the transfer to complete
3:55
before it can execute the next statement
3:58
to overcome such an issue we use the
4:01
interrupt let's Define a variable to
4:04
keep track if the data has been
4:06
transferred in the while loop we will
4:09
only transmit the data if this variable
4:11
is set to one here call the function
4:14
holu transmit it the parameters of the
4:18
function are the uart instance the data
4:20
buffer and the size after calling the
4:24
function set the variable to zero in the
4:27
interrupt mode the data is transferred
4:30
in the background while the CPU can
4:32
process the rest of the tasks when all
4:35
the data has been transferred and
4:37
interrupt will trigger and the transfer
4:39
complete call back will be called inside
4:43
the call back we can do the rest of the
4:45
processing here we will simply set the
4:48
variable to one so to inform the CPU
4:51
that the data has been
4:54
transmitted let's also Define two
4:57
counters which will keep track of how
4:59
many times times the interrupt has been
5:00
called and the while loop has run
5:03
completely all right let's build and
5:06
debug the
5:07
project let me add the counters to the
5:10
live
5:16
expression here you can see the
5:18
interrupt counter is half of that of the
5:20
while loop the while loop is running
5:24
independently irrespective of if the
5:26
data has been transferred or not you can
5:29
see the LED is now blinking every 500
5:34
milliseconds here you can see the data
5:36
received in the console and the
5:38
reception is now continuous compared to
5:40
what we saw in the Blocking
5:42
Mode basically it is taking around 1
5:45
second to transfer 10 Koby of data and
5:48
this is why the interrupt counter is
5:50
half of the while loop let me change the
5:53
blink delay to 1 second and debug the
5:56
project
5:58
again
6:02
now you see both the counters are
6:04
incrementing at the same rate the LED
6:07
now blinks every 1 second the data
6:11
transfer is still continuous and it does
6:13
not take 1 second delay into
6:16
consideration this is because the data
6:18
is transferred in the background and by
6:21
the time the CPU waits for the whole
6:23
delay to finish the data is
6:26
transferred then the loop calls for the
6:28
transfer
6:29
again so we were able to transfer the
6:32
data using interrupt and the CPU still
6:35
managed the LED blinking at the defined
6:38
rate we can always use interrupt to
6:41
transfer the data but the transfer is
6:43
still done by the
6:45
CPU so when transferring a large amount
6:48
of data it puts too much load on the
6:51
CPU this is where the dma comes in dma
6:56
stands for direct memory Access
6:58
Controller and it is is used to provide
7:00
high-speed data transfers between
7:02
peripherals and memory and between
7:04
memory and memory data can be quickly
7:07
moved by the dma without any CPU action
7:10
this keeps CPU resources free for other
7:14
operations we will use the function holu
7:17
transmit dma to send the data via the
7:20
dma the parameters are the same as the
7:23
interrupt function once the data has
7:26
been transferred the you transmit
7:28
complete call back will be called and
7:31
here we will set the variable to one we
7:34
basically use the same setup that we
7:36
used for the
7:38
interrupt let's build and debug the
7:41
project
7:46
now here you can see the counters are
7:48
incrementing just as they were during
7:50
the interrupt the LED is blinking every
7:54
1 second so the process is running fine
7:58
we are receiving data continuously just
8:00
as we were using the
8:02
interrupt I don't have the means to show
8:04
the CPU load but it is reduced while
8:07
using the
8:08
dma now while configuring the dma we
8:11
came across the dma modes the normal
8:14
mode and the circular mode right now the
8:17
dma is configured in the normal mode and
8:20
in this mode the dma does not reload the
8:22
address after the transfer is complete
8:25
basically it transfers the data once and
8:28
after the data has been transferred the
8:30
dma stops let me show this by calling
8:34
the transfer function outside the while
8:36
loop let's build and debug the
8:42
project here you can see the interrupt
8:45
counter only incremented once and the
8:47
while loop continues to run this is
8:50
because the dma transferred the data
8:53
once so the interrupt is only triggered
8:55
once here you can see the serial console
8:58
rece received 10 Koby of data and that's
9:04
it now let's keep the same code go to
9:07
the cube MX configuration and change the
9:10
dma mode
9:15
circular let's build and debug the
9:18
project
9:27
again you can see the interrupt counter
9:30
is increasing at a faster rate than the
9:32
while loop basically the dma is
9:35
continuously sending the same data and
9:38
the rate is faster than 1 second this is
9:41
why the counter is increasing at a
9:43
faster rate in the circular mode the
9:46
source and the destination addresses and
9:49
the number of data to be transferred are
9:51
automatically reloaded after the
9:52
transfer
9:54
completes so the dma continues sending
9:57
the same data to the same address and
9:59
from the same
10:00
address it does that in the background
10:03
and without affecting the CPU
10:06
load now I will show how to use the
10:08
circular mode more effectively and how
10:11
to stop the
10:12
dma just like the transfer complete call
10:15
back we also have a half transfer
10:18
complete call back this call back is
10:21
triggered when the dma finishes
10:23
transferring half the data we will
10:26
utilize this call back in our code we
10:29
are transferring 10 kiloby of data so
10:32
half transfer complete call back will be
10:34
called when dma has transferred 5
10:37
kilobytes basically it will be called
10:40
when the first half has been
10:42
transferred inside this call back we can
10:45
load new data to the first half of the
10:47
buffer while the dma is sending the
10:49
second half similarly when the second
10:53
half is transferred the transfer
10:55
complete call back will be
10:57
called the DM a is in the circular mode
11:00
so it is transferring the first half
11:03
again and during that time we will load
11:05
new data to the second half of the
11:08
buffer basically when the dma transfers
11:11
the second half we update the data in
11:13
the first half and when it transfers the
11:15
first half we update the data in the
11:18
second half this process will continue
11:21
till we issue a stop
11:23
instruction we can set some condition
11:26
and once the condition is satisfied call
11:28
the function you at dma stop to stop the
11:31
dma in the main function we still need
11:34
to send all the data at once so
11:37
everything can start from there all
11:40
right let's build and debug the
11:52
project you can see the new data is
11:54
being received by the
11:56
console and the dma stopped in the end
12:00
the interrupt counter has been stopped
12:03
while the loop counter continues to
12:05
count the data was loaded as we
12:07
programmed it to do we can use the dma
12:11
in circular mode to transfer large data
12:14
whereas we can still have smaller
12:15
buffers and load the new data in the
12:17
runtime
12:18
itself this is it for the
12:21
video I hope you understood the use of
12:24
interrupt and dma while transferring the
12:26
data via the
12:27
uart you should use the different modes
12:30
as per the data
12:32
requirement use blocking mode for small
12:35
data interrupt for more data and use dma
12:38
when you have a lot of data to be
12:41
transferred I will continue with this
12:43
series in the next video and we will see
12:46
the receiving part you can download the
12:49
code from the link in the
12:52
description leave comments in case of
12:54
any doubt keep watching and have a nice
12:58
day ahead
#C & C++
#Computers & Electronics
#Engineering & Technology
#Software