How does an embedded application and RTOS communicate with each other?

Question

I am working on a project which uses ARM 7 processor and a micrium - os II RTOS. Kindly help me out in understanding the fundamental questions that have come to me regarding this project.

Below are the questions:

1. How does the application interact with the RTOS?
2. Inturn how does the RTOS interact with the controller? (same as windows ineracts with the intel processor?)
3. We specify the location of RAM, ROM, stack etc., but how are the ports identified via the C program i.e., we specify some hex value in our program but how are this linked back to the controller
4. How does the RTOS know where to start the execution of the program?
5. Once the application is loaded into the ROM and on switching ON the embedded device, how does it know where to start exectuing the application?

Answer 1

I haven't used an ARM7 before, but I have used µC/OS-II on an 8 bit microcontroller before. I'm not an expert but will try to answer your questions.

1. An RTOS will typically allow you to create "tasks", which are like separate threads of execution. µC/OS-II can use cooperative multitasking, which would mean it's up to your tasks to give control of the processor back to the operating system. (It also supports preemptive multitasking.) You'll define priority levels for each task as well.

2. Via tasks, you'll interact with the controller just as you would if you weren't using an RTOS. Write functions that do stuff and call them!

3. I don't know about ARM7, but on my processor the I/O ports are just memory mapped, so yes you just set / read the value at the address assigned to the port of interest. You will probably want to define the port as volatile so that the compiler doesn't optimize out things that it shouldn't.

4,5. the RTOS is just running where any normal program would run, so the reset vector points to its start of execution.

Answer 2

how does the application interact with the RTOS

The RTOS has an API - a set of function calls - that the application calls. For example, to create an RTOS task, you call the RTOS API function that creates a task for you. There are other API calls for sending messages, etc.

I believe in uCOS you also need wrappers on interrupt functions to tell the RTOS when you are inside an interrupt.

Inturn how does the RTOS interact with the controller (same as windows ineracts with the intel processor?)

Normally this class of RTOS will just need to use one of the microcontrollers timer peripherals to generate a periodic tick interrupt. It may also need to use the software interrupt vector.

we specify the location of RAM, ROM, stack etc., but how are the ports identified via the C program i.e., we specify some hex value in our program but how are this linked back to the controller

I don't understand what you are asking in this question.

how does the rtos know where to start the execution of the program.

Unless you modify it otherwise, the C start up code will call main() as normal. Your application code in main() will then create some tasks using the RTOS API before starting the RTOS. You can also create new tasks from existing tasks after the RTOS has started.

once the application is loaded into the ROM and on switching on the embedded device, how does it know where to start exectuing the application.

uCOS is statically linked. It just creates an executable binary, just as if you were not using an RTOS. When the program is compiled and linked and loaded into the microcontroller, on reset the microcontroller will run whichever code the reset vector tells it to. This will normally be C start up code, which then calls main, which then runs your application code, which will then create RTOS tasks, and then start the RTOS. From that point on the RTOS decides which task to run when.