Hello, welcome back.
So in this lesson, we going to reexamine our autonomous vehicle case study again and show the various
ways in which we could achieve what we want to achieve.
OK, so this diagram over here shows how we would do this in a busy wait system.
This is the the most popular we we ride to a firmware where we just have our function and then we do
an if condition and then we wait for that if condition to be met.
Once it is met, we move on to the next state.
Over here, what we have is check the light assets or status.
So check if it is ready, then read the data and then go on to check the the what you call it, the
radar sensor or if that is ready with the data.
And then come on to check the camera status, if it is ready, gets the data and then we come back to
the top, check Leida, check radar, check camera and then to the top.
OK, so what would happiness in an autonomous vehicle where things need to meet deadlines and everything
has to be precisely derived at a precise time?
It could be that.
When you check in the camera, Senso studies.
And then computing the parameters, because you've just you've now got in all the states of the three
sensors and you are taking actions such as turn left, it could be that by the time you reach here and
you are ready to take left based on the information you collected from here, here and here, the data
here may have changed.
So you would end up in a car situation?
It could be fatal, it could be dangerous to rely on a system such as this because you first check,
you check you and check you and then you think, OK, you know, the perfect state of all sensors.
So now you are ready to increase their speed or turn left back because it's arranged this way.
And you check this some time ago, the states may have changed.
So this could lead to a problem.
This is the busy wait system.
We wait over here until it is ready and then we check this, wait until it's ready.
And then after that, OK, we know the light.
Our status.
Is this the radar status?
Is this the camera status?
Is this therefore increased the speed?
OK.
So this is simple, this the standard way that people often write code sequential code like this.
Now, let's see another way that this could be arranged using what is known as the the interrupt service
routine.
So over here.
We have just our main function, all of this, you can think of all of this in a while, while one was
single main function.
OK, now let's see this other arrangement over here.
We have our main function.
We're saying take action only in our main function, but read into the light us.
That is the read us.
That is in the camera.
That is we're doing it in a separate threat known as background threats.
And our main function, we only see saying take action.
So what does this mean?
What is this background threat one with this background threat can be can be designed is by using timers.
Our microcontrollers allow us to use our time is to create periodic interrupts.
And what this means is that periodically.
The process is going to be interrupted and then a particular block of code will be executed.
And we use our time is to decide to decide to disappear out of frequency, so this I saw here starts
for interrupt service routine.
So we can see, OK, time are one, we want you to execute this block of code every.
Twenty milliseconds.
And then we can see Temotu.
We want you to execute this other block of code.
Every 20 milliseconds or every 30 milliseconds, because we are using different hardware timers, we
can decide on the frequency at which each interruption, OK, and we can see timer three should should
give us, I guess, our three.
We want you to execute this block of code known as cameras.
That is when you to execute this every twenty five milliseconds so we can initialize hardware timers
to create these interrupts periodically.
And then when it occurs periodically, there is a particular function known as the interest service
routine for each time we place our block of code there and then it'll be executed.
So what is going to happen is if we say this should occur every 20 milliseconds, what would happen
is every 20 milliseconds, the the Processo.
Is going to pass the main function and then execute the content in this block of code.
And once that is done, it's going to resume executing the main function, if this wants period, Protarchus,
is going to pass and then execute once it's done.
So the main function essentially ends up with a very low priority.
Right.
So what would happen is when we have these multiple interrupt service routines, we are allowed to assign
them priority levels as well, such that we know we have let's see if we have this once period to be
every 20 milliseconds and this one's period to be every 40 milliseconds.
We know they're going to collide eventually to collide, because when this one executes its first period
and the next period of this is plus another 20 milliseconds, which will occur at a forty millisecond
timestamp, that will be the first execution of this one whose period is every 40 milliseconds.
So in a situation where to interrupt service routines end up with the same period, how do we decide
who gets to execute?
Because of this, we are allowed to assign them priorities so we can assign this a higher priority than
this one, such that in such a situation, those with a higher priority execute.
Right.
So these ones here.
We have the foreground threat and the Bhagwat threat, right?
Another thing I should point out is there is also a debate based debate on which should be considered
a foreground threat and a background threat.
OK, an H over here.
There's a debate on which should be considered.
The foreground thread in the background thread, what are the main function should be the foreground,
foreground thread of the background thread I have just chosen, it's makes sense to me that the ones
in the back to interrupt service routines in the background, while whilst the main function, of course,
would deal with it all the time, is in the foreground.
So if you see this with this written us background in this as foreground, don't get alarmed.
OK, so this method here, we have our main function and we have had where time is generating interest
for us.
So it is the second way we can you know, we can deal with our autonomous vehicle case study.
Right.
So we know that Dobi coalitions, there will be, of course, the main function will be will be staffed
from process processing time.
Of course, every time the main function wants to do something, then one of them would have the period.
So the incorrupt would OK and the main function would have to stop and then let them deal with it.
So this is a compromise is better than the first one is a compromise.
Now, let's see our ARTUS.
So let's see what we've done.
We showed a busy wait system.
We should interrupt service routine system.
Now we are showing the ATA system, the realtime operating system to in the realtime operating system
solution.
We have each of the blocks in their own threads, we have each of them in their own thread or tasks
such that we take an action only in task one and then in task to we only dealing with a lighter sense
or task three, only dealing with a radar sensor task for only dealing with a camera essential.
So all of them are occurring based on the scheduling algorithm.
All of them are occurring independent of each other.
If we want, we can also pass the data.
Obviously we would need to pass the data between them.
They are tools that allows us to pass the data between these threats or these tasks in an efficient
and safe way.
So this is the the the Real-Time operating system solution, and with this, if we are using a simple
Round-Robin solution.
Then we could we could find a good enough time, slice them, make them OK.
Almost as if they were parallel.
Right, such that if we see each of them should execute four, five missed this executes five Emmis,
it saves its execution states and then restores the execution date of this five most saves and then
restores restores.
So by the time we come here is going to be almost as if nothing happened.
So this is the artist's evolution.
It's not perfectly parallel.
That's the word.
Sorry about that.
But this is the solution compared to the other two solutions.
So now you understand the artosis not perfectly parallel execution.
It is just rapidly quick context saving and context restoration.
We save the context of one thread where we start the context of another thread.
So because it's this fast, we just see it as if it is parallel.
I'm having problems with this pronunciation to the.
And when we go to practically execute our realtime operating system, we would be counting countless
variables and you would see that to almost have the same volume as if they've executed execute in parallel.
OK, so this or the risk for this lesson in the next lesson, we shall we shall give an overview of
of threats.
We shall give a very short overview of the components that Ethelred need to have and then we shall move
on from that.
If you have any questions, please leave them in the questions and answers.
If you have any feedback, just let me know.
I'll see you later.
Have a nice day.