Up next in 10
STM32 UART #3 || Receive Data in Blocking Mode & Interrupt
75 views
Jan 14, 2024
Purchase the Products shown in this video from :: https://controllerstech.store ________________________________________________________________________________________ UART PART 2 :::: https://youtu.be/JaMwNT0m3Sw UART PART 4 :::: https://youtu.be/RpDOHqoVNTs STM32 UART Series Playlist :::: https://www.youtube.com/playlist?list=PLfIJKC1ud8gjmw-l5eDYfzzX5JI19lwhx STM32 Playlist :::: https://www.youtube.com/playlist?list=PLfIJKC1ud8gga7xeUUJ-bRUbeChfTOOBd DOWNLOAD THIS PROJECT FROM :::: https://controllerstech.com/stm32-uart-3-receive-data-in-blocking-interrupt-mode/ ________________________________________________________________________________________ ******* SUPPORT US BY DONATING****** https://paypal.me/controllertech *******Join the Membership******* https://www.youtube.com/channel/UCkdqtSMnhYuMsJkyHOxiPZQ/join
View Video Transcript
0:01
[Music]
0:09
hello and welcome to controllers Tech
0:12
this is the third video in the stdm 32
0:15
uart series and today we will start
0:18
receiving the data in today's video we
0:21
will see how to receive the data in the
0:23
blocking mode and using the interrupt we
0:26
will also see what are the advantages
0:29
and disadvantage vages of using the same
0:32
then we will cover the receiving using
0:34
the dma in the next video I will
0:37
continue using the project from the
0:39
previous video and here it is we need to
0:43
make some changes in the cube MX so
0:45
let's open the ioc file let's disable
0:49
the dma as we are not using it to
0:51
transfer the data today we will leave
0:53
the interrupt enabled as we will use the
0:55
interrupt to receive the data the rest
0:58
of the setup will remain as it is so
1:01
click safe to update the project let me
1:04
delete the extra code from the previous
1:07
video Let's Define a new buffer RX data
1:11
where we will store the data received by
1:13
the
1:14
uart in the while loop we will leave the
1:17
LED blinking as we are going to monitor
1:19
it
1:20
also all right so we will start with the
1:23
Blocking Mode
1:24
first huart receive function receives
1:27
the data in the blocking mode
1:30
the parameters are the uart instance the
1:33
buffer where the data will be stored the
1:35
data size to be received and the time
1:38
out the timeout plays an important role
1:41
as this function will only wait for this
1:43
time
1:45
period here I am setting it to 1 second
1:48
and if the five bytes data is not
1:50
received within 1 second the function
1:52
will time out let's set the LED blinking
1:56
to every 1 second all right let's build
2:00
and test it I will use the same serial
2:04
monitor to send the data from the
2:06
computer we are using the same
2:09
configuration so let's connect to the
2:11
virtual comp Port let me add the buffer
2:14
to the live
2:20
expression we should see the data under
2:23
this value
2:24
section let's run the code now here I am
2:28
sending the work hello but I did not
2:31
receive it this is probably because the
2:34
function timed out and the MCU was only
2:37
able to receive the first bite then the
2:40
CPU toggles the LED and waits for 1
2:44
second if the data is sent within this
2:47
time it will be
2:48
lost basically the data needs to arrive
2:51
at exactly the same time when the
2:53
control enters the U receive function
2:56
and the required data needs to arrive
2:58
within the timeout
3:00
let me show this I will run the debugger
3:04
and quickly send the five bytes
3:07
data I sent the data before 1 second and
3:10
the MCU received it quite well but this
3:14
is very unlikely to happen in the real
3:17
scenario another option is that we
3:19
increase the waiting time here I am
3:22
setting the time out to Infinity the CPU
3:25
Will Wait Forever Until all five data
3:27
bytes have been received
3:30
Let's test
3:35
this you can see the LED on board is not
3:38
blinking and this is because the control
3:41
does not come out of the receive
3:43
function now let's send one bite at a
3:46
time here we are receiving the data in
3:49
the buffer but the control still doesn't
3:51
come out as it is looking for five bytes
3:53
in total once all the five bytes have
3:56
been received the control finally comes
3:59
out of the receive function and the rest
4:01
of the while loop executes we can send
4:04
all five bytes at once and the control
4:07
will exit the function immediately this
4:09
is how the blocking mode works the CPU
4:13
will be blocked for a certain duration
4:15
and will be released only when either
4:17
all the data bites have been received or
4:19
if the timeout
4:21
occurs you might think that this is a
4:23
completely useless mode to receive the
4:26
data but that is not true if you are
4:29
using
4:30
R you can create a separate task and use
4:33
this mode to receive a single data bite
4:37
then store those data bites in the main
4:39
buffer and get yourself the complete
4:42
data this reduces unnecessary interrupts
4:45
in the rtos
4:47
application I am not using rtos in
4:50
today's video but I will show how to
4:52
store single data bytes in the main
4:54
buffer but using the
4:56
interrupt so we saw how to receive data
4:59
in blocking mode without R to it
5:04
certainly is not a reliable method to
5:06
receive the data this is where the
5:09
interrupt comes in huart receive it
5:13
takes the parameter as the uart instance
5:15
the buffer and the number of bytes to be
5:19
received again we need to know how many
5:21
data bytes are coming the interrupt will
5:24
not trigger until the required number of
5:27
bytes have been received but the
5:30
advantage is that the CPU is not blocked
5:32
during the wait the rest of the code can
5:36
execute as
5:37
usual once the required number of bites
5:40
have been received the interrupt will
5:42
trigger and the RX complete call back
5:44
will be
5:45
called we can process the data inside
5:48
this call back I am not going to process
5:52
the data for now so let's leave it the
5:55
interrupt is disabled after each call so
5:58
we need to enable it again in the call
6:00
back
6:01
function let's build and debug the
6:05
project run the debugger
6:08
now you can see the LED is blinking
6:11
every 1 second so the CPU is handling
6:14
the rest of the tasks as usual I am
6:17
sending one bite at a time but the
6:19
interrupt will only execute once it has
6:21
received all five data
6:28
bytes
6:39
this is the fifth bite and here you can
6:42
see the breakpoint got hit in the
6:44
Callback
6:58
function here it got hit again after
7:01
receiving five new bytes so we are able
7:04
to receive the data and the CPU can
7:07
process other tasks as well there is one
7:10
major issue here we can only receive the
7:12
data of fixed length this won't work
7:15
well for the data of random sizes so we
7:19
will modify this code a little let's
7:22
define another array of one or two bytes
7:25
now we will receive only one data BTE
7:28
via the uart
7:30
once the U received one bite the call
7:32
back will be called and here we will
7:34
store this bite in our main buffer let's
7:38
define an index variable to keep track
7:40
of how many bytes have been received in
7:42
total the index will also be used to
7:45
store the new data at a new position in
7:48
the buffer inside the call back store
7:51
the received data bite in the RX data
7:53
array now increment the index variable
7:57
and if its value is 20 or more reset it
8:00
to zero this is because our RX data
8:03
array can only store 20 bytes at Max
8:06
include the string header file for the
8:08
mem copy function to work all right
8:11
let's build and debug the project now we
8:15
can send as many data bytes as we want
8:18
the new data will always be stored at a
8:21
new position in the RX
8:28
buffer
8:37
note that the buffer does not have
8:39
enough space for this data so the data
8:41
should overlap from the beginning here
8:44
you can see it overlapped the previously
8:46
stored data from the beginning although
8:49
the space between what and is is
8:54
missing this is probably due to this
8:56
line here let me send another set of
8:59
data to confirm
9:11
this the last bite four is missing it
9:15
should have been stored at the beginning
9:17
of the buffer we need to First increment
9:20
the index variable and then check the
9:23
condition let's build and debug again
9:27
all right let's test it now
9:34
we have only two bytes space remaining
9:37
so the overlap should happen now the
9:39
last two bytes will be one and two and
9:42
the three should be stored at the
9:44
beginning of the buffer all right it
9:46
works fine now so we were able to
9:49
receive the data with unknown length
9:52
this will work fine for certain types of
9:55
communications but keep in mind we still
9:57
don't know the length of incoming data I
10:00
mean it is very hard to find how many
10:02
data bytes arrived at a certain point of
10:05
time Hall actually provides a dedicated
10:08
function for it and we will cover it in
10:10
the next
10:11
tutorial anyway we can still check some
10:14
conditions to know if the expected data
10:16
have arrived or not say for example I
10:20
know that the incoming data has a
10:22
terminating new line character also I
10:25
want to store my final data in a
10:27
separate buffer so we will check for
10:30
that particular character in the
10:32
incoming data actually let's do this in
10:35
the while loop if the character has
10:38
received this means we have received the
10:40
required data so we will copy the data
10:43
from the RX data buffer to the final
10:45
data buffer the length will be the same
10:48
as the value of the index
10:50
variable now reset the index to zero so
10:54
that the data storage in the RX data
10:56
buffer can start from the beginning
10:58
again
10:59
let's build and debug the code now this
11:03
checkbox is used to add the new line
11:06
character to the end of the data let's
11:09
first send the data without
11:16
it so we are receiving the data in the
11:19
RX data buffer let me add the final data
11:23
buffer to the live
11:27
expression you can see there is nothing
11:29
in it now I am adding the terminating
11:33
character to the data indicating this is
11:35
all I want to
11:36
send and here you can see all the data
11:39
from the start has been stored in the
11:41
final data buffer see I hope you
11:45
understood how this
11:46
works there are Limitless possibilities
11:49
here and you can write the code
11:51
according to what you expect to
11:53
receive this method still has some
11:56
drawbacks as things might get
11:58
complicated when you are receiving a
12:00
large amount of data at a very high rate
12:03
remember that the interrupt is being
12:05
triggered for each bite and by the time
12:08
the interrupt is served the call back is
12:10
called and the interrupt is called again
12:13
we might lose one or two data
12:15
byes we have other methods as well to
12:18
handle the unknown data lengths and we
12:20
will cover them in the upcoming
12:23
tutorials this is it for the
12:25
video you can download the code from the
12:28
link in the
12:29
description leave comments in case of
12:32
any doubt keep watching and have a nice
12:35
day ahead
#Electronics & Electrical
#Engineering & Technology
#Programming