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 become schedulable with Earliest Deadline First (EDF), Rate Monotonic Shcehduling (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.)

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).