Optimization

AN3423

6/13

Doc ID 018987 Rev 2

Note:

In EB's AUTOSAR OS the interrupt lock status is considered to be part of the task's context.

Each newly activated task starts with interrupt enabled.

●

OsCallIsr [DIRECTLY, VIA_WRAPPER]

–

If ISRs are called DIRECTLY they always run as supervisor with kernel protection

boundaries, and they cannot be killed. If a protection error occurs in an ISR the

only possible course of action is SHUTDOWN.

●

OsCallAppErrorHook [DIRECTLY, VIA_WRAPPER]

–

If application-specific ErrorHooks are called DIRECTLY they always run as

supervisor with kernel protection boundaries, and they cannot be killed. If a

protection error occurs in a hook function the only possible course of action is

SHUTDOWN.

●

OsCallAppStartupShutdownHook [DIRECTLY,VIA_WRAPPER]

–

If application-specific startup and shutdown hooks are called DIRECTLY they

always run as supervisor with kernel protection boundaries, and they cannot be

killed. If a protection error occurs in a hook function the only possible course of

action is SHUTDOWN.

●

OsPermitSystemObjects [TRUE,FALSE]

–

In a system with OS-Applications, enabling this feature permits OS-objects to

belong to “the system” and not to any particular application. Such objects can

“access” other objects without restriction. This feature is useful for objects such as

schedule tables that control the scheduling of all applications in a system.

●

OsUserTaskReturn [KILL_TASK,LOOP]

–

This option determines what happens when a task returns from its main function.

KILL_TASK is AUTOSAR-conformant but requires the full error handling and error

action to be enabled for correct functionality. LOOP means that if a task returns

from its main function it tries to terminate. If that fails it shuts down the AUTOSAR

OS. If that fails it enters an endless loop, which has the effect of locking out all

tasks of equal or lower priority.

Note:

On architectures such as Tricore where return from-task is caught using a special exception

handler, this option has no effect.

2.4

API removal

API removal is most important for kernels that use an hardware trap mechanism (called a

“system-call”) for calling kernel functions. On the Power Architecture, use of the system-call

is a configurable option.

When a system-call is not used, the user's code calls kernel functions directly. This means

that kernel functions that are not used do not get selected from the library at link time. With

a system-call, each call to a system service results in a system-call with a unique index, and

the index is used by the system-call handler to select the appropriate kernel function from a

table.

In a kernel with system-calls, many kernel functions can be eliminated automatically. For

example, if there are no Resources defined, the GetResource and ReleaseResource

functionality can be excluded. However, it is not possible to determine from the configuration

whether some kernel functions are used or not. A good example is ChainTask(), which can

be quite large and is seldom used.