0

This question has been bothering me from a long time, I tried to search online but didn't get any answer. I understand the difference between a normal OS and a RTOS. I wanted to understand what are the additional constraints (if any) imposed on an application programmer for a RTOS ?

For example I have some requirements and need to implement a solution which runs on a normal OS and an RTOS. What aspects should I take care when I am implementing the solution for the RTOS ? Should I profile my code to check the exact memory, processing requirements which I should give to the RTOS scheduler which will perform some feasibility analysis and determine if it can include my application in the existing schedule ?

Can some give me practical examples of how this is done in RTOS like OSE, Windriver etc ?

Neo
  • 141
  • 5
  • 16
  • 1
    Read about [rate monotonic scheduling](http://www.embedded.com/electronics-blogs/beginner-s-corner/4023927/Introduction-to-Rate-Monotonic-Scheduling) and see if that helps with your question. – kkrambo Nov 17 '13 at 21:04

1 Answers1

1

Most RTOS are thread schedulers rather than process schedulers, so there is only one "application" as such, made from multiple threads in a single process. In that context the issue of schedulability of your "application" is moot, since there is only one application.

If you have a non-realtime task (and it is perhaps implicit that this is the case if you are also able to run it on a general-purpose OS (GPOS), then on an RTOS you might run it at a low priority at a level shared by other non-realtime tasks with round-robin time-slicing enabled - those threads will then schedule in a similar manner to that of a GPOS. Note that if one or more of these threads never yields, they must be run at the very lowest priority level possible, and in any case such behaviour would be generally undesirable - essentially such threads become the idle task.

Clifford
  • 88,407
  • 13
  • 85
  • 165