0:12
this is the sixth video in the
0:15
stm32i2c slave series and today we will
0:18
see how the slave will send the data
0:21
in the previous video we saw the slave
0:24
was able to save the data in the
0:27
today we will program the slave to send
0:30
the data back to the master
0:32
the video covers two different ways to
0:36
when the master simply requests to read
0:38
the data without mentioning the memory
0:40
location to read from
0:42
and when the master specifies which
0:45
memory location it wants to read the
0:46
data from and how many bytes it wants to
0:49
read we will continue where we left in
0:54
here is the code from the part 5
0:58
let's define an array and store the data
1:03
just like our X count Define a variable
1:06
to keep track of the number of bytes
1:09
once the master initiates the request
1:12
the address callback will be called
1:15
we will write the rest of the code under
1:17
the condition that the transfer
1:19
direction is received
1:21
here we set the TX count to zero
1:24
and now call the sequential transmit in
1:26
the interrupt mode to send one byte of
1:29
data we will send the data to send
1:31
buffer and the transfer option will be
1:37
this is the same as how we programmed
1:42
once one data byte is transferred the
1:45
slave transmit callback will be called
1:50
here we will increment the TX count
1:52
variable so that the next byte is the
1:55
buffer can be transferred
1:56
now send one byte again but with the
1:59
option of the next frame
2:01
let's build and debug the code
2:05
let's add the TX count variable to the
2:10
i2c read will simply request four data
2:16
here we have received the data this is
2:19
the same as what we defined in the
2:23
let's read six bytes now
2:26
we have received the entire buffer this
2:29
looks a bit confusing so let me change
2:32
the data in the buffer
2:44
let's read the six bytes again
2:47
now you can see the data received is the
2:50
same as what we defined in the buffer
2:52
note that the TX count is seven
2:55
each time the Callback is called the TX
2:58
count gets incremented
3:00
so when the last byte is transferred the
3:03
Callback is called again and the TX
3:05
count gets incremented again
3:08
this makes the value of t x count 1
3:10
higher than the actual data bytes sent
3:13
let's try to receive 10 bytes
3:16
we received the 6 bytes as per the
3:18
values defined in the buffer and the
3:21
next four bytes are random data
3:23
this is basically the data stored in the
3:26
next memory location where the buffer is
3:29
now let's talk about the errors
3:32
no matter how many bytes the master
3:34
requests there will always be the error
3:36
the acknowledgment failure error since
3:40
we don't know how many bytes the master
3:41
has requested the slave transfers one
3:44
byte each time the master sends the
3:48
when the master sends The Knack response
3:50
it acts as an acknowledgment failure for
3:54
here the error code will be four and
3:56
this is the same what we get while the
3:58
slave is receiving data
4:01
so we need to make a check for whether
4:03
the slave is receiving or transmitting
4:05
the data after encountering the error we
4:09
will first clear the error flag
4:13
now we will check the TX count variable
4:16
if the TX count is zero it means that
4:19
the slave never transmitted the data and
4:22
hence the error must have occurred while
4:25
and in that case we will call the
4:27
process data function same as what we
4:30
did in the previous video
4:32
but if the TX count is not zero that
4:34
means the error must have occurred while
4:36
the slave was transmitting
4:39
in this case we will reduce the TX count
4:41
variable by 1. remember I mentioned
4:44
earlier that the TX count variable ends
4:47
up at one Higher value than the number
4:49
of bytes actually transferred
4:51
so here we are correcting it let's build
4:59
I am putting a break point in the
5:01
process data function to check if it
5:05
we have received 10 bytes of data
5:08
the TX count value is 10 there was an
5:11
error but the process data wasn't called
5:15
so this is working fine
5:18
the function i2c read is similar to
5:20
using the function Hal i2c Master
5:24
here we mention where the data will be
5:27
stored and how many bytes the master
5:31
it does not specify the memory address
5:33
in the slave instead simply requests the
5:36
data the interrupt or dma versions of
5:39
the same function can also be used for
5:43
so we saw how the simple read operation
5:45
can be performed on the slave
5:48
now we will see a bit more complex read
5:50
operation where the master specifies the
5:55
the function memory can be used by the
5:57
master for this purpose
5:59
here the master specifies the start
6:01
register it wants to read from and how
6:04
many bytes it wants to read
6:06
in the slave file we have already
6:09
defined the registers
6:11
we will treat these as the memory
6:13
registers for the slave
6:15
let's understand how the slave will
6:17
receive the requests from the master
6:20
the read from function is the same as
6:22
the memory function we just discussed
6:25
here the master is requesting three data
6:28
bytes starting from the register five
6:31
it received the data as we haven't
6:34
modified the code yet and the slave is
6:36
still sending the data to send buffer if
6:40
you look at the RX buffer you see the
6:42
first byte holds the address of the
6:44
register the master has requested to
6:47
I am hoping that you already have an
6:50
idea about how the protocol actually
6:53
the master first writes the register
6:55
address it wants to read the data from
6:58
this address gets stored in the first
7:01
byte of the RX buffer then the master
7:03
sends the restart condition with the
7:07
since the process starts from the
7:10
beginning the address callback is called
7:13
the transfer direction is received this
7:15
time hence the slave will transmit the
7:19
let's create a variable to store the
7:21
position of the start register
7:27
this time we are transmitting the data
7:29
from the i2c registers
7:36
update the position variable with the
7:40
and then use the register address as the
7:43
offset while transmitting the data
7:49
let's build and debug this now
7:53
first the master is writing the data
8:00
let's add the i2c registers to the live
8:07
here you can see the registers got
8:10
updated with the new data
8:13
now the master is reading four bytes
8:15
starting from the register 3.
8:18
we got the data 6 5 4 3. you can see the
8:24
data is exactly the same as stored in
8:26
the registers starting from register 3.
8:30
let's try reading four bytes starting
8:36
here we got the accurate data again
8:43
let's read all 10 bytes starting from
8:48
we got the data again and this is the
8:50
same as what's stored in the registers
8:53
so the slave driver is working very well
8:57
we saw how the master requests the data
8:59
from the slave and the slave send that
9:03
this is it for this video
9:06
I hope you understood how to program the
9:08
slave to respond to the read request
9:11
in the next video we will see how to
9:14
handle some common errors in the i2c
9:17
the link to download the code in the
9:19
description of the video
9:21
leave comments in case of any doubt
9:24
keep watching and have a nice day ahead