Home > database >  Embedded system, How to define or calculate a time period
Embedded system, How to define or calculate a time period

Time:01-21

For designing embedded systems, one of the steps is scheduling.

I know the execution time can be measured by using some functions. For example, I can use micro() in Arduino to measure the time between start time and end time.

But I have a question, how to define the period as known as deadline? I want my system to use Earliest Deadline First (EDF), Rate Monotonic Scheduling (RMS) or both.
How can I find out the correct number and proof that this system is schedulable? Giving a random number seems not a good way for designing, I think there should be a way to define or calculate a number for period.

(I have searched for this information for 1 hour, but I couldn't find any useful information. Any tips or comments are good for me.)


*update

so currently I am taking a class, embedded software systems. My professor asks us to simulate everything on the TinkerCAD by using Arduino. We have to create platooning trucks and implement part of the behavior based on this system. For example, there are three trucks traveling in a platoon, what will happen if the trucks encounter human, stop sign or animals? Maybe the leading truck sends a brake message to the following trucks, re-launch the engines then keep traveling in the platoon.

EDF example Take an example from the book, we already know the execution time, and how can we know that now we should place 5 for task 1's period and place 7 for task 2's period? When people are designing a system, how do they know what number will be placed for the period?

So my question is, how can I know or calculate the number for the period maybe for braking, for re-launch the engines and for keep traveling in a platoon when I am designing a system?

CodePudding user response:

The mathematics for EDF schedulability are described at https://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling, and similarly for RMS at https://en.wikipedia.org/wiki/Rate-monotonic_scheduling. It is all rather theoretical and in the real world it is often more empirical.

How can I find out the correct number...

It is not clear what "number" you are referring to, but if you mean how to calculate the "deadline" for a specific task, that is not really what the schedulability test yields. Rather it determines given the maximum-execution time of a task whether or not all tasks will meet their deadlines.

The theoretical models also make a number of assumptions such as periodic tasks and negligible context switch overhead. But event driven systems often have few or no periodic tasks. Meeting response deadlines in the microsecond order does not lend itself to periodic scheduling. In that case you must use both worst case execution time and worst case event rate.

CodePudding user response:

This seems like a really broad question since there are multiple things you are asking about and references to multiple scheduling algorithms. I can attempt to answer your first question: you have to know something about how the system is being used and what its users expect in order to define what the deadline or desired period is for a particular task.

For example, for the task of monitoring the state of a pushbutton that is pressed by a human finger, it's probably fine to monitor it once every 10 ms (100 times per second), because humans cannot press or unpress a button very quickly.

I don't know about those fancy scheduling algorithms you are referring to, but for many applications it is sufficient to just handle each task in your main loop, and then try to design your main loop so an iteration always completes within a few milliseconds.

Unfortunately, I don't know how to prove that the main loop will run in a specific time. It seems like that should be the job of your compiler to help you prove that, but I don't know of any popular embedded compilers that even attempt to do that. So the best we can do in practice is measure the run time.

For any tasks that need to run quickly or run more often than the main loop, consider using interrupts, and setting the interrupt priority levels carefully (if your system supports that).

  •  Tags:  
  • Related