Now, in this lecture, we're going to start talking about communication of protocols like you, A.R.T.,
now you A.R.T. is a through your communication protocol.
And it is used to transmit data between two devices.
I mean, think about it, how can we transmit messages or data in between two devices?
Well, let's go to the most basic idea.
It's all about sending a data from your digital output and meaning.
What do you mean?
Send data from digital output?
It just activating and deactivating meaning sending one zero one zero.
This is the only way to communicate between devices.
Right.
You just sent a bunch of bits.
Let's say I want to send three in binary.
How can I send it from one digital output?
In order to do that, I need to define some strict rules so that both devices understand what I am sending
when I am sending it, when the message starts, when the message stops.
I need some rules to do that because OK, I could send one bit between two devices by sending one from
its digital output and let's say the second embedded system digital input will read this message, this
one or zero.
Right.
But that's really limited because what if I want to send a message that contains larger data, like
larger numbers, maybe a sixteen bit number and maybe a 32 bits number, maybe an eight bit number.
How can we do that?
Maybe I'm trying to translate a message using letters, you know, letters.
We might need a blight in order to send letters, meaning eight bits to just form one letter.
OK, so we cannot really use one bit.
This is the whole meaning of having a communication protocols so that we can have a full message sent.
But the concept is the same.
You have a digital output sending an additional input at the other end.
Receiving it is as simple as that with some rules that we're all talking about.
So.
This is how it looks like you have a USB connected to your computer.
We have an order here, let's say, or it could be any embedded board we have here, a USB to serial
in the original case.
And this USB is going to a USB in your computer right here.
And they are communicating using you A.R.T. over USB, meaning there is a USB protocol.
It's called USB.
It's a really huge protocol, a really complicated.
But there is a very simple protocol that is embedded inside this USB protocol, which is called you
A.R.T., and it is sending one zero one zero one zero in between these two devices.
Now, as I said, you can imagine every bit as a digital output, activating voltage of signals with
either five volt or the Volt in sequence.
Now, let's say that we are activating this and deactivating at a certain speed.
So it means that I'm sending one, then I'm sending another one, then I'm sending a zero.
Then I'm sending go on.
And let's say that every four bits are one message.
So we need to program both of our embedded devices that, OK, once you account for bids, this is your
first message, go and translate it.
I mean, if we don't design this at all, we might be sending, let's say, five bits.
But the message is four bits and five bits could mean something totally different.
This is why we need to specify, OK, one message is eight with one message is four gigabit.
So that first device is sending big number one.
Second device is reading bit number one, then to receiving two third, but receiving third but fourth
with receiving full speed.
And stop here.
The second device is going to translate this for it to something meaningful.
Then the other device can continue sending other bits.
But there will be a totally different message.
It will count for a bit.
And then it's going to say, OK, those other four bits mean, let's say number five, then message
will end and it will be waiting for other four bits in order to read another message and so on and so
forth.
See why we need stricter rules, because you are sending multiple bits and both devices need to understand
how many bits are we sending right now in order to know when should I stop and when should I take this
message and translated to something?
And when I talk about translation, I mean when I said zero zero one zero, this is number two.
So it will translate into two when I send one one one one.
This is 15.
So the other end will translated to 15.
But if the other end does not know how many bits it could take, the first two bits which are let's
say one one and say, OK, this is my message, I am sending 15, which is one one, one one.
But the other side doesn't know how many bits.
So it reads the first two messages and says, OK, I don't want the number is the three.
That's wrong.
That's totally wrong because I'm sending fifteen.
I'm reading all the three.
That does not make any sense.
So this is why we need to agree on the number of bits.
So this is what we mean when we say accumulation, we accumulate a number of bits to form a message
and both ends should agree on this.
No, the UAE already has a certain form.
Now, every protocol has a certain forg for its message.
Unwealthy is the most basic, simplest protocol you would see in your life.
It's very simple.
It consists of a database, which is the data, so you can send numbers between zero and 255 if you
are considering the unsigned representation.
It also has one start bit and one or two stop bits.
So take a look here.
This is your start bit.
This is your stop.
It's OK.
So when you send your other device a zero, the other end will understand that, OK, a message will
come right now.
So the first device is sending a signal saying, hey, I am sending a message if it was sending a one
at the beginning.
Well, it is in idle meaning.
I'm not sending you anything, but the moment it sees a zero, it knows that Stargate that has been
received and it knows that I am ready to receive eight bits.
So I'm going to count eight bits in order to understand your message.
So it's going to start receiving one one zero zero one zero one.
Let's consider that this does not exist right now.
OK, so it received eight bits, so it received the first sort of five five zero zero four five Volda
of one Volt.
And then it stops the receiving end had counted eight bits and now it will stop.
It will say, OK, this is my message.
And and after counting eight, it should receive this stop right here.
It should receive a low value.
It should receive a zero.
So after eight bits, it receives a zero and it knows, OK, I am done.
This is my message.
And after that they're sending and will send a one and it will keep sending ones because this is idle.
That means I'm not sending you anything.
So the whole point is that these bits are being transmitted, but at a certain rate, OK, what does
at a certain rate mean?
Do you remember our clock in the VDL?
I'm going to link these two concepts to the clock, organizes everything.
So inside you, Adreno and inside you, any embedded system, there is a clock and this clock can be
configured to be at a certain speed.
And this is the communication clock.
So you need to configure both of your embedded systems at a certain o'clock.
And once you do that, well, you would say at every falling edge, are you gonna count one bit?
OK, so as the falling edge, this is the time allowed to receive one bit.
So let's say it is only twenty milliseconds.
OK, so every twenty milliseconds we are seeing a different bit.
So it is a clock and the other end at every twenty milliseconds it is saying, OK, I received this
bit after other twenty milliseconds it will say, OK, I'm ready for the next twenty milliseconds elapsed.
It says OK, I'm ready for the next.
But this is how they understand how long every bit should be.
Because otherwise when you send one one how could the other device distinguish between this one and
this one.
It can distinguish because there is a clock that is counting twenty milliseconds here, twenty milliseconds
here, meaning at every twenty milliseconds.
I am sampling the data right here.
So this is the clock I'm talking about.
Take a look at every falling edge I am sampling at every falling edge.
I am checking the data.
So this is how I know that the data should come at this moment.
So if we can maybe 20 milliseconds.
I know that.
OK, first twenty milliseconds are done following it has come.
I will start sampling now are you wait for another twenty milliseconds at twenty milliseconds between
two falling edges.
OK, so it will wait another twenty millisecond and then it will read the digital output.
So this twenty second waiting is just the clock of your device.
And this is why it's very important that both the clocks are synchronized together.
If both clocks are synchronized together, we will have no problem in communication, but let's say
this one is counting every 20 milliseconds, but your sending device is counting every 30 milliseconds,
then you're going to have a lot of problems and your messages will not be read as expected.
And that is the whole point right here.
If your message is not being read as expected, this could cause a problem.
This is why there is an agreed rate in between two, which is called the boat rate.
Now, the boat rate is certain, similar to Pittsburgh seconds.
It's not exactly bit bits per second, but it is a concept similar to bits per second.
So how many bits per second I can receive when both parties, when both embedded systems agreed to the
same similar boat rate, then you can transmit messages and they can both understand it very well.
So actually, this is nothing but a finite state machine that that has 10 states.
So the first the state is receiving start, but then a second state is maybe to receive first that second,
third, fourth.
Up until eight.
Then the tenth state would be the stop it.
So it will wait until it receives a stop it or a high voltage.
So this can be easily designed as a state machine, as a federal project.
This is why I'm telling you embedded system is wrong.
Understand it very well.
You need to study VDL.
You will have a very, very powerful background understanding of everything.
If you could stop yourself and Videl, I hope you enjoyed this lecture.
And please leave my questions in the Q&A if you have any.