1. Not finding help here? Sign up for a free 30min tutor trial with Chegg Tutors
    Dismiss Notice
Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Question about RTOS

  1. Jul 2, 2014 #1
    scheduling is process by which operating system decide which one task will be next on processor

    scheduling determine the order in which task are executed

    different os kernel may use different scheduling algorithm

    scheduling algorithm

    First Come First Serve (FCFS) Scheduling

    Shortest-Job-First (SJF) Scheduling

    Priority Scheduling

    Round Robin(RR) Scheduling

    Multilevel Queue Scheduling

    Q1
    which scheduling is used in RTOS ?
    I think Priority Scheduling but I don't why ?


    I have another question about kernel I have read about kernel for RTOS

    1)type of kernel

    Monolithic kernels
    Micro kernel

    2)type of kernel

    preemptive kernel
    non preemptive kernel

    I don't understand difference between both type ,

    Q which type of kernel may be used in RTOS , I think preemptive kernel, Micro kernel
     
  2. jcsd
  3. Jul 2, 2014 #2
    So a RTOS is one that needs to accomplish a set of task in real time (ie as soon as possible). The OS will also have a bunch of other tasks that need to be accomplished but the can wait.

    so for Q1 priority is correct, but why? Ask yourself why would a RTOS need to ensure that certain processes get executed first?

    What is the difference between a microkernel and monolithic?
    A monolithic kernel was the first model of an OS that was developed. Developer put everything that the kernel could ever possibly need into kernel space. This carries a bunch of extra overhead. Why would this be bad for a RTOS?
    A micro kernel is one where just the bare minimum is included in the kernel, and any additional functionality that is needed needs to be built and run in user space.
    Why might this be good for a RTOS?

    Preemptive scheduling allows the OS to interrupt an executing process and allow another process to take over. Think about drivers pulling over to the side of the road to allow an emergency vehicle by.
    Non preemptive is the opposite. Once an process is allocated some execution time that process is allowed to finish its time before being interrupted.
    So which do you think would be better for a RTOS?
     
  4. Jul 2, 2014 #3

    nsaspook

    User Avatar
    Science Advisor

    Your questions really don't have a definitive answer as it depends on the task and what runs best in the field vs what's 'best' in CS theory.

    Preemptive scheduling for tightly bound event-driven hardware tasks should be used carefully, especially in devices that have limited resources like micro-controllers. As long as the processes are isolated things run smoothly but as soon as they become dependent on each other for resources it becomes a mine-field for bugs so a "super-loop" 'state machine/ISR' run-to-completion (RTC) or Task Switcher kernel approach to real-time is sometimes a better RTOS abstraction.

    http://www.barrgroup.com/Embedded-Systems/How-To/Preemption-Perils

    http://www.embedded.com/design/prototyping-and-development/4025691/Build-a-Super-Simple-Tasker
     
  5. Jul 2, 2014 #4
    type of RTOS
    Monolithic kernels
    Micro kernel
    preemptive kernel
    non preemptive kernel

    which one kernel support RTOS ?

    I am asking preemptive kernel non preemptive kernel not for scheduling ?
     
    Last edited: Jul 2, 2014
  6. Jul 2, 2014 #5

    Well any of them you could use for a RTOS. But I think you would go for a preemptive microkernel
     
  7. Jul 2, 2014 #6

    rcgldr

    User Avatar
    Homework Helper

    The term scheduling normally applies to a batch type situation where there are a list of jobs to be run on a multi-tasking (or single tasking) operating system. One goal could be to complete all jobs in the shortest time possible, but with constraints just as some jobs having higher priority than other jobs. This applies more to main frames than personal computers or embedded devices.

    A true RTOS should be preemptive, switching to higher priority threads based on events. Threads pend on these events to allow lower priority threads to run. A non-preemptive operating system relies on the threads to make calls to operating system functions to allow context switches to take place, sometimes called round robin scheduling. A real time application can be implemented with a non-preemptive operating system, but I'm not sure if that should be called an RTOS since the critical timing requirements are handle in thread code instead of by the operating system. In some preemptive situations, every thread has a different priority, so no time slicing is needed to share time between threads of equal priority.
     
  8. Jul 2, 2014 #7
    there are two type of kernel

    Monolithic kernels
    Micro kernel

    Monolithic kernels may be preemptive or non preemptive
    preemptive Monolithic kernels
    non preemptive Monolithic kernels

    Micro kernel may be preemptive or non preemptive
    preemptive Micro kernel
    non preemptive Micro kernel
     
  9. Jul 3, 2014 #8

    FactChecker

    User Avatar
    Science Advisor
    Gold Member

    "Real-time" has a variety of meanings. "Hard real time" control systems often use frequency based scheduling. They have a set of programs that must run in a specified order at a strictly scheduled rate. These programs have top priority and do not get interrupted. Essential hardware interrupts are usually handled by other processors. Event-driven or background tasks are run in the remaining time and can be interrupted. Kernel operations are kept as small as possible and divided up so that uninterruptable parts are done in very short times.
     
  10. Jul 4, 2014 #9
    I have little bit doubt

    does one RTOS support one or more then one kernel ?

    and same does one RTOS support one or more then one scheduling process
     
  11. Jul 5, 2014 #10

    FactChecker

    User Avatar
    Science Advisor
    Gold Member

    There are no official rules or definitions. OS developers do whatever is needed for the type of use they are anticipating. But there are some general conventions.

    The kernel is an abstract layer of software between the applications and the hardware. I think you would say there is only one. Some operating systems divide the computer resources and time so that different processes run as though they are running on different operating systems, but I think there is only one kernel, even in those systems.

    There can be combinations of scheduling modes working simultaneously in the same OS. They would have to be coordinated into a single scheduling process or they would conflict with each other.
     
    Last edited: Jul 5, 2014
  12. Jul 5, 2014 #11
    that means we can use one or more scheduling for one real time operating system

    f
     
  13. Jul 5, 2014 #12

    FactChecker

    User Avatar
    Science Advisor
    Gold Member

    Yes. If you are designing the RTOS, you will include the combinations that will get the job done for the targeted user (maybe allow frequency based schedule for some tasks and FIFO queue schedule for other tasks). If you are a user, you will need to live with the scheduler options that the RTOS provides. RTOS designers try hard to give flexibility to the user so their RTOS has a large market. An advanced user programmer can often work within an RTOS to get whatever he needs. In an extreme case, a user might allocate a slice of processor time to his own task that schedules subtasks any way he wants.
     
  14. Jul 8, 2014 #13
    Interprocess communication for real time operating system

    Interprocess communication is process of operating system that allow one process to communicate with another processes

    for example - email , chatting

    that means we can send message from one os to another

    shared memory - it can be in the form of shared memory
    queue - it can be in the form of queue
    mail box - it can be in the form of message


    can someone explain little bit what is interprocess communication for RTOS
     
    Last edited: Jul 8, 2014
  15. Jul 9, 2014 #14
    Similar as before there is no reason why you cannot use any of these methods for IPC in a RTOS. The questions you need to ask yourself is what properties of each will be of the best benefit for a RTOS.

    Shared Memory is fast but as the memory is shared you will need to ensure that the processes lock the memory (eg via semaphores) to avoid race conditions

    queue, the data needs to be copied to and from the queue, and then there is the overhead associated with managing the queue. How does the process know that there is something in the queue?? Generally a queue would only be 1 direction, so if 2 processes talked back and forth you would need multiple queues

    Mail Box, some process (most likely the kernel) will have to manage the the mail boxes and again how does the process know that it has mail? and again the conents will have to be copied into the processes memory.

    For a RTOS I would argue that the best method would be the shared memory approach. It seems to have the least overhead, and the processes can be "smart" and be built to give up control when they get blocked trying to access the shared memory, or set up so they can't be interupted when writing to the shared memory.
     
  16. Jul 9, 2014 #15

    rcgldr

    User Avatar
    Homework Helper

    The term process is often used to refer to multiple processes, each with it's own memory space. Some startup mechanism or initial assumptions are needed for the processes to communicate (named shared memory, named handles, one process spawning the other processes and passing handle values on the command line used to invoke the other processes, ... ).

    The alternative is a multi-threaded application, all of which share a common address space.

    As for queues or mailboxes, the most common implementations I've seen internally use either a circular buffer or a linked list. In the case of a linked list, the calling code may have to deal with the nodes directly, or the calling code provides a buffer, and the operating system, copies data between the caller's buffer and internal linked list nodes. The nodes or the caller's buffer may include additional pointers to data.
     
  17. Jul 13, 2014 #16
    I am not really going to design I just want to learn something before design
    I want to design my real time operating system , so I need features , requirement component and tool

    I need to develop program For real time operating system
    my effort
    1)basic tool
    compiler
    linker
    debugger

    2)language
    c language

    3)requirement
    requirement of real time os should be fast

    features
    kernel - micro kernel
    scheduler - real time scheduler
    multitasking - multitasking
    scheduling - preemptive scheduling


    I think I have forgotten some features
     
  18. Jul 13, 2014 #17

    FactChecker

    User Avatar
    Science Advisor
    Gold Member

    If you haven't already, look into the Board Support Package (BSP) (see http://en.wikipedia.org/wiki/Board_support_package ). I think that the board manufacturers usually write the BSP. Even if you don't program it you will want to define an interface that works with it. And it may give you some clues about what the OS needs to do.
     
  19. Jul 16, 2014 #18
    I am having problem to understand some statement

    kernel is not modular,
    kernel is not fault tolerant ,
    kernel is not configurable
    kernel is not power optimized

    can anyone explain little bit ?
     
  20. Jul 16, 2014 #19

    rcgldr

    User Avatar
    Homework Helper

    Where did you get these statements from?

    modular - the code is separated into reasonably small functions and reasonably small source files.

    fault tolerant - being able to handle faults, usually a reference to a fault in the hardware (not a fault in the software). Mostly an issue when health (like xray / electron beam machine) or a lot of money is at risk.

    configurable - This probably means run time configurable, as the source or make files can be modified to make the kernel source time or compile time configurable.

    power optimized - some processors have a low power state which can be used in a kernal when no tasks are runnable (all of them in some sort of wait state). The low power state for some processors is invoked by a halt instruction.
     
  21. Jul 16, 2014 #20
    I looked pdf in which I seen statement why os is not suitable in real time os

    kernel is not modular, fault tolerant , configurable
    take too much space , not design for critical application

    kernel is not modular- code is separated

    kernel is not fault tolerant - kernel can not tolerate fault

    kernel is not configurable- code and source can not modify
     
    Last edited: Jul 16, 2014
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook

Have something to add?
Draft saved Draft deleted



Similar Discussions: Question about RTOS
  1. Question about turbine (Replies: 1)

Loading...