(1) Service-Call-Type Programming

What is a Service Call?

A service call is a command used to request a function of the OS. The target of the function or necessary values such as time should be specified as parameters through a command. The necessary parameters depend on each command. A service call was called a system call in μITRON version 3.0 and earlier versions.

What is Service-Call-Type Programming?

This programming method requests functions of the OS through commands to execute necessary processing. Requesting a function through a command is called “issuing” a service call.
In C language, calling a function corresponding to a service call with specifying parameters is a request for processing in the OS. Each function returns the result of the request (a value indicating OK or NG for the request) or an assigned ID number. Some service calls return data through the memory address that has been specified by a service call parameter.
The functions for service calls differ from normal functions in that execution does not always return to the caller of a function after completion of the called function processing. When a service call is issued to place the invoking task in WAITING or DORMANT state, the scheduler in the OS is activated and switches execution to another task. Execution never returns from the issued service call until the task is released from WAITING state and dispatched. In other words, while a task continues processing without any service call being issued, execution is not switched to another task because the scheduler does not work.
There is only one case where execution is switched to another task even if the task being executed does not issue any service call; it is when an interrupt handler issues a service call. When interrupts are not disabled in the microprocessor, execution is forcibly switched to the interrupt handler. Note that when the task being executed has a higher priority than the other tasks, execution is not switched to another task. (The interrupt handler and service call processing is executed, but the task having the highest priority is dispatched again.) In this case, the task invoked from the interrupt handler is placed in the execution wait queue.

(2) Event-Driven Programming

What is Event-Driven?

An event-driven program works with changing task states every time a related event occurs.
There are several types of events; external status changes such as timer events or interrupt events can be used as triggers, and changes in the internal state of the system such as message transmission from another task, setting of event flags, release of resources, or error occurrence can also be used as triggers. In the embedded system, programs work by being activated, placed in DORMANT or WAITING state, or released from WAITING state, when triggered by these events. In this regard, event-driven programming differs from the data (form)-driven programming used in business software. In Windows-based applications in personal computers, the OS monitors every event, such as the clicking of a button or updating of a text box display on a window, and activates the corresponding program when detecting an event. This is also called event-driven programming, but it differs from that used in a real-time OS.

(3) Driver-Type Programming

What is a Driver?

A driver is software that operates specific hardware, such as a communication device.

Each manufacturer of hardware products provides drivers for their products for each OS. By embedding the drivers in the target OS, application development engineers can operate hardware through standard application programming interface (API) functions; thus, the engineers can handle advanced devices without knowledge of hardware-specific details or complicated interrupt processing. Even for a hardware product for which no driver is provided, the application should be created in the driver-type structure so that the application software can be reused, and engineers can be efficiently assigned to suitable development jobs; that is, only driver development engineers need to have hardware knowledge, and application development engineers do not need to know about hardware.