0:12
this is the second video in the i2c
0:14
slave series and today we will continue
0:17
from where we left in the previous video
0:20
we saw how to write a simple code for
0:22
the slave to receive the data in the
0:26
if you remember we wrote the function to
0:28
receive six bytes of data and set the
0:31
transfer option as the first and last
0:34
this enabled the slave to receive six
0:37
bytes of data and if the master sent
0:39
more than six bytes the slave sent the
0:43
I also mentioned that since the slave is
0:45
set to receive six bytes if the master
0:48
sends less than that the slave will
0:50
generate an acknowledgment failure error
0:57
this is the previous project we worked
1:01
let me launch the debugger
1:11
all right it's ready now
1:14
I am putting a break point in the error
1:19
let's send two bytes of data
1:24
I forgot to run the debugger
1:32
all right we have received the two bytes
1:35
and the breakpoint also got the hit
1:38
this means indeed there is an error
1:41
if you hover on the i2c you can see the
1:44
error code that is 4.
1:47
let's see the i2c header file to know
1:51
here you can see the error 4 corresponds
1:54
to the a-f error that is acknowledgment
2:01
if the master sends six bytes of data we
2:04
will not get any error because it is
2:06
supposed to receive 6 bytes
2:09
but sending less than that will trigger
2:13
this error Rises because the slave
2:16
detects an early stop condition we will
2:18
talk about this in a while
2:21
the AF error is not an issue here
2:24
as long as we are receiving the data it
2:28
we can just clear the error and move on
2:33
the problem with the previous code was
2:35
that it only received a fixed amount of
2:38
if we are using this code for
2:40
communication between two devices and we
2:43
don't know how much data the master is
2:45
going to send we can't use it there
2:48
so today we will make changes to the
2:50
code so that the slave can receive
2:53
pretty much any amount of data without
2:55
sending a knack response
2:57
in the previous video we used the
3:00
transfer option first and last frame
3:03
today we will check out other options we
3:06
have like i2c first frame next frame and
3:11
the first frame is used to manage the
3:14
start condition and the data transfer is
3:16
done without a final stop condition
3:19
the next frame is used to manage a
3:21
restart condition and the data transfer
3:24
is done again without a final stop
3:28
the last frame is again used to manage a
3:30
restart condition but the data transfer
3:33
is done with a final stop condition
3:36
you see how these options are very
3:38
similar yet different from each other
3:41
basically the first frame is used when
3:43
you want to receive data where the
3:45
master is starting the communication
3:48
the next and the last frame is used to
3:50
receive data where the master is using a
3:53
restart condition basically in a
3:55
situation where it wants to switch to a
3:57
read from right or vice versa
4:00
the last frame is used when the slave
4:02
wants to end the transfer
4:05
if we'll receive the data with the
4:06
option of the last frame so as to
4:09
indicate that it does not want to
4:12
this certainly does not mean that the
4:14
master will stop transmitting it's just
4:16
that the master will send NAC after this
4:20
let's see all of this in the operation
4:23
let's define some new variables first
4:27
the RX count will be used to keep the
4:30
track of the buffer position
4:32
I am also defining different counters so
4:35
that we know which function was called
4:39
when there is an address match this
4:41
address callback is called
4:44
here we will first increment the address
4:46
counter and then the slave will receive
4:49
one byte of data with the indication
4:51
that it is the first frame
4:54
once the slave successfully receives one
4:57
bite the receive complete callback will
5:03
here we will increment the RX count so
5:06
that the new data can be saved at a new
5:08
location in the buffer
5:10
if the RX count exceeds the buffer size
5:12
reset it back to zero so that it starts
5:16
overwriting the data from the beginning
5:18
this whole Arrangement will make this
5:20
reception in a circular buffer mode
5:24
now we will again receive one byte of
5:26
data and store it in a new position in
5:30
this time we will provide the option
5:32
next frame indicating that the slave is
5:35
ready to receive the next data byte also
5:38
let's increment the RX complete counter
5:42
I am incrementing the error counter in
5:44
the error callback function
5:46
all right everything is set now let's
5:49
build and debug the code
5:52
let me add the counters in the live
5:58
everything is set now so let's send the
6:01
two bytes of data first
6:03
here we received the data in the first
6:06
two bytes of the buffer
6:08
notice that the address counter is 1
6:11
that means the address callback was only
6:13
called once whereas the received
6:15
callback was called twice
6:18
basically when the master initiates the
6:20
transfer and there is an address match
6:23
the address callback gets called
6:26
here the slave requests one data byte
6:30
unsuccessfully receiving it the receive
6:32
complete callback is called and the
6:35
receive counter increments
6:37
the slave requests another data byte
6:40
on receiving a second byte the receive
6:43
complete callback is called again and
6:45
the counter increments to 2.
6:48
the slave requests another data byte but
6:51
the master is only sending two bytes
6:54
hence a sop condition is detected while
6:57
the slave was waiting for the data
6:59
this triggers the acknowledgment failure
7:01
error and the error counter is
7:03
incremented to 1. now if a master sends
7:06
a new data it will store at an updated
7:09
position in the buffer
7:11
since it's a fresh new data where the
7:13
master again starts with the address
7:15
matching the address counter is
7:21
let's send six bytes now
7:26
it started from a new updated position
7:28
and once the data exceeded the buffer it
7:31
started overwriting the data from the
7:34
let's see it one more time
7:43
you can see the 7 8 overwrites the 1 2.
7:47
the error will always be there each time
7:49
the master transmits something
7:52
this is because the slave never sends a
7:56
the error actually arrives because the
7:58
stop F bit is set in the status register
8:02
this happens because the slave detected
8:04
a stop condition while it was waiting
8:06
for new data to arrive
8:08
any way we can ignore the error for now
8:10
we will handle it in future videos
8:14
so we are able to receive the data in a
8:16
circular mode where the new data
8:18
overwrites the old data in the buffer
8:21
more importantly the slave can receive
8:24
as much data the master can send
8:26
this is it for this video
8:29
I hope you understood the concept
8:31
in the next video we will make this
8:34
receiving a little more interesting more
8:36
like an idol line interrupt case in you
8:40
we will also see the usage of the option
8:46
the link to download the code is in the
8:50
leave comments in case of any doubt
8:53
keep watching and have a nice day ahead