AUTOSAR Classic Operating System
Guide du clusterGÉNÉRÉ PAR IA
Fournit l'ordonnancement temps réel déterministe, la protection mémoire, la synchronisation multicœur et le confinement des erreurs.
Fournit l'ordonnancement temps réel déterministe, la protection mémoire, la synchronisation multicœur et le confinement des erreurs.
Le cluster de modules Operating System fournit l'ordonnancement temps réel déterministe pour les tâches et les ISR ainsi que la protection mémoire et l'encapsulation des erreurs dans des OS-Applications partitionnées [SWS_Os_00445]. Il prend en charge les systèmes multicœurs grâce à des spinlocks inter-cœurs, à l'activation asynchrone de tâches et à l'Inter-OS-Application Communicator (IOC) [SWS_Os_00686], [SWS_Os_00824]. En cas de violations de protection, l'OS permet, via des hooks configurables, l'arrêt ciblé ou le redémarrage contrôlé de partitions individuelles au moment de l'exécution ApplicationLevelErrorHandling p. 53.
Dans AUTOSAR Classic, le cluster de modules « Operating System » fournit l'infrastructure fondamentale d'exécution et de protection pour les composants logiciels et les modules de logiciel de base. Le système d'exploitation encapsule les ressources telles que les tâches, les ISR, les alarmes et les compteurs dans des OS-Applications [SWS_Os_00445] et distingue ici les partitions de confiance (trusted) des partitions sans confiance (non-trusted) [SWS_Os_00446], afin de garantir un confinement strict des erreurs basé sur la protection mémoire par MPU SafetyConceptStatusReport p. 49. Dans les systèmes multicœurs, l'OS gère les cœurs logiques via des identifiants de cœur normalisés [SWS_Os_00790] et fournit l'Inter-OS-Application Communicator (IOC) pour l'échange de données et d'événements entre cœurs et partitions [SWS_Os_00824].
Diagramme de contexte : intégration du cluster OS dans l'architecture du logiciel de base AUTOSAR et interfaces vers EcuM, StbM, la RTE et le matériel. Sources : [SWS_Os_00445], [SWS_Os_00790], SWS_BSWGeneral p. 48.
Outre l'ordonnancement des tâches déclenché par des événements, l'OS permet le suivi temporel de l'exécution via des Schedule Tables [SWS_Os_00783]. Celles-ci peuvent être ajustées à des bases de temps globales du véhicule via le Synchronized Time-Base Manager (StbM) au moyen de SyncScheduleTable [SWS_Os_00199], SWS_SynchronizedTimeBaseManager p. 220. Pour la synchronisation au-delà des frontières de cœur, le module propose des spinlocks proches du matériel avec détection intégrée des interblocages [SWS_Os_00686], tandis que les activations de tâches inter-cœurs peuvent être exécutées de manière asynchrone avec ActivateTaskAsyn [SWS_Os_91022].
En cas d'erreur (par exemple lors de dépassements de mémoire), l'OS active le ProtectionHook [SWS_Os_00538]. Grâce à sa valeur de retour, une OS-Application défaillante peut être isolée et arrêtée de manière contrôlée, ou réinitialisée via une tâche de redémarrage dédiée, sans réinitialiser l'ensemble du système [SWS_Os_00787], ApplicationLevelErrorHandling p. 53.
Diagramme d'états : cycle de vie et états de partitionnement d'une OS-Application AUTOSAR en cas d'erreur. Sources : [SWS_Os_00773], [SWS_Os_00258], ApplicationLevelErrorHandling p. 53.
1. Architecture système & rôle du cluster de modules
Dans le modèle en couches AUTOSAR, le cluster de modules « Operating System » constitue le socle fondamental des System Services pour l'exécution et la coordination de tous les composants logiciels temps réel et modules de logiciel de base. Le module central [SWS_Os_00445] encapsule les tâches, les routines de service d'interruption (ISR), les alarmes, les compteurs (counters) et les tables d'exécution (Schedule Tables) dans des unités d'exécution configurables, appelées OS-Applications. Ici, le système d'exploitation distingue strictement les OS-Applications de confiance (trusted) et sans confiance (non-trusted) [SWS_Os_00446], afin de fournir la sécurité fonctionnelle et la protection mémoire conformément aux classes d'évolutivité requises SafetyConceptStatusReport p. 49.
Dans les architectures multicœurs, l'OS gère des cœurs logiques référencés par des identifiants uniques de type CoreIdType [SWS_Os_00790]. Les identifiants de cœur sont basés sur zéro et ordonnés de manière consécutive [SWS_Os_00825], la constante OS_CORE_ID_MASTER désignant le cœur maître SWS_OS p. 111. Via l'Inter-OS-Application Communicator (IOC) intégré, le système d'exploitation fournit des mécanismes pour le transfert sécurisé de données entre partitions et entre cœurs [SWS_Os_00824]. Grâce à la normalisation des interfaces selon OSEK OS et à leurs extensions spécifiques à AUTOSAR, l'OS garantit un comportement temps réel déterministe pour les modules de niveau supérieur tels que l'ECU State Manager (EcuM), le Synchronized Time-Base Manager (StbM) ainsi que l'environnement d'exécution RTE SWS_BSWGeneral p. 48.
Diagramme de contexte : intégration du cluster OS dans l'architecture du logiciel de base AUTOSAR et interfaces vers EcuM, StbM, la RTE et le matériel. Sources : [SWS_Os_00445], [SWS_Os_00790], SWS_BSWGeneral p. 48.
2. Interaction & voies d'interaction entre les modules
L'interaction entre les objets OS et les couches de l'architecture AUTOSAR s'effectue via des chemins de contrôle et de données nettement délimités. Pour l'échange de données inter-partitions, l'IOC génère des fonctions de communication typées avec une sémantique non mise en file d'attente (« data », IocWrite / IocRead) ou mise en file d'attente (« event », IocSend / IocReceive) [SWS_Os_00718], [SWS_Os_00738]. Lors des transferts de groupe, les services IocSendGroup ou IocReceiveGroup sont utilisés [SWS_Os_00728], [SWS_Os_00746]. Si un tampon interne du récepteur devient plein, l'IOC le signale à l'émetteur avec le statut IOC_E_LIMIT et consigne un IOC_E_LOST_DATA pour les opérations de lecture suivantes SWS_OS p. 225.
Lorsqu'une OS-Application sans confiance doit accéder à des services privilégiés d'une partition de confiance, le changement de contexte contrôlé s'effectue via le service système CallTrustedFunction [SWS_Os_00097]. Ici, les paramètres sont transmis via une structure de pointeurs de type TrustedFunctionParameterRefType [SWS_Os_00776]. Le système d'exploitation bascule temporairement les autorisations de la MPU vers celles de l'application cible SWS_OS p. 172. Pendant cette exécution, la fonction GetCurrentApplicationID renvoie l'identifiant de la Trusted Application appelée, tandis que GetApplicationID fournit l'application appelante d'origine [SWS_Os_00797].
Pour la synchronisation temporelle avec des bases de temps externes, le module StbM synchronise des Schedule Tables explicitement configurées via les interfaces de l'OS. Le StbM interroge d'abord cycliquement l'état de synchronisation via GetScheduleTableStatus [SWS_Os_00227], puis transmet la valeur de synchronisation actuelle à l'OS au moyen de SyncScheduleTable [SWS_Os_00199]. Le système d'exploitation calcule ensuite l'écart par rapport aux points d'échéance (expiry points) et ajuste progressivement les délais jusqu'à ce que la table fonctionne de manière synchrone avec la base de temps globale SWS_OS p. 57, SWS_SynchronizedTimeBaseManager p. 220.
Diagramme de séquence : synchronisation explicite d'une Schedule Table de l'OS par le Synchronized Time-Base Manager (StbM). Sources : [SWS_Os_00199], [SWS_Os_00227], SWS_SynchronizedTimeBaseManager p. 220.
3. Synchronisation, réentrance et contextes de tâche
Le modèle d'exécution distingue clairement le niveau des tâches, les niveaux d'interruption de catégorie 1 (Cat 1 ISR) et de catégorie 2 (Cat 2 ISR), ainsi que les routines de hook. Tandis que les Cat 1 ISR s'exécutent sans surcoût lié au système d'exploitation et ne doivent appeler aucun service de l'OS, les Cat 2 ISR sont entièrement gérées par l'OS [SWS_Os_00782]. L'identifiant de l'ISR active peut être déterminé au moyen de GetISRID ; lors d'un appel en dehors d'une Cat 2 ISR, le service renvoie INVALID_ISR [SWS_Os_00511]. Les sources d'interruption individuelles peuvent être contrôlées de manière ciblée au niveau du contrôleur d'interruptions via EnableInterruptSource, DisableInterruptSource ainsi que ClearPendingInterrupt [SWS_Os_91020], [SWS_Os_91019], [SWS_Os_91021].
Pour la synchronisation des sections critiques au-delà des frontières des cœurs de processeur, l'OS met à disposition des spinlocks [SWS_Os_00791]. Un spinlock est réservé de manière synchrone et bloquante avec GetSpinlock [SWS_Os_00686] ou interrogé de manière non bloquante via TryToGetSpinlock [SWS_Os_00703]. La libération s'effectue via ReleaseSpinlock [SWS_Os_00695]. Pour exclure les interblocages, l'OS vérifie en statut étendu la présence d'erreurs d'imbrication et de chevauchement (E_OS_INTERFERENCE_DEADLOCK, E_OS_NESTING_DEADLOCK) SWS_OS p. 199.
Pour les activations de tâches et le positionnement d'événements inter-cœurs, l'OS fournit des variantes d'API asynchrones : ActivateTaskAsyn et SetEventAsyn retournent immédiatement à l'appelant sans attendre l'exécution sur le cœur cible [SWS_Os_91022], [SWS_Os_91023]. Les erreurs éventuelles ne sont pas renvoyées à l'appelant, mais enregistrées via des hooks d'erreur configurés [SWS_Os_00816], SWS_OS p. 203.
4. Cycles de vie et modes de fonctionnement typiques
Le démarrage du système est principalement coordonné par l'ECU State Manager (EcuM). Sur le cœur maître, l'EcuM démarre les cœurs secondaires avant le démarrage du système d'exploitation via le service OS StartCore [SWS_Os_00676], SWS_ECUStateManager p. 82. Ensuite, chaque cœur démarré appelle StartOS de manière autonome. Après l'appel de StartOS, le système d'exploitation fait passer toutes les OS-Applications configurées à l'état APPLICATION_ACCESSIBLE avant que les hooks de démarrage ne soient exécutés SWS_OS p. 62. Le nombre de cœurs démarrés avec succès peut être interrogé à l'exécution avec GetNumberOfActivatedCores SWS_OS p. 196.
Les Schedule Tables sont régies par une machine à états clairement définie. Elles peuvent être démarrées de manière absolue via StartScheduleTableAbs [SWS_Os_00358], relative via StartScheduleTableRel [SWS_Os_00347] ou synchrone via StartScheduleTableSynchron [SWS_Os_00201]. Les tables peuvent être chaînées (NextScheduleTable, état SCHEDULETABLE_NEXT) [SWS_Os_00191] ou basculées immédiatement à l'état de repos SCHEDULETABLE_STOPPED avec StopScheduleTable [SWS_Os_00006]. Une synchronisation explicite en cours peut être interrompue au moyen de SetScheduleTableAsync, le traitement des points d'échéance se poursuivant [SWS_Os_00422].
Pour les modes d'économie d'énergie en veille, l'OS propose l'interface ControlIdle, grâce à laquelle l'EcuM peut configurer l'état de veille de cœurs individuels [SWS_Os_00769]. Lors de l'arrêt, l'EcuM coordonne la désinitialisation de toutes les couches et appelle finalement ShutdownAllCores ou ShutdownOS pour arrêter l'ensemble du système de manière contrôlée SWS_ECUStateManager p. 90.
5. Gestion des erreurs, traçage DET et dégradation
Les violations de protection (telles que les dépassements de mémoire ou les violations temporelles) entraînent l'activation du ProtectionHook global [SWS_Os_00538]. En fonction de l'erreur, le hook décide de la stratégie de récupération via une valeur de retour de type ProtectionReturnType [SWS_Os_00787] : terminaison de l'entité déclencheuse (PRO_TERMINATETASKISR), terminaison complète de la partition concernée (PRO_TERMINATEAPPL), déclenchement d'un redémarrage contrôlé de la partition (PRO_TERMINATEAPPL_RESTART) ou arrêt du calculateur (PRO_SHUTDOWN) ApplicationLevelErrorHandling p. 60.
Lorsqu'une OS-Application est arrêtée ou redémarrée, l'OS la fait passer de l'état APPLICATION_ACCESSIBLE à APPLICATION_RESTARTING ou APPLICATION_TERMINATED [SWS_Os_00773]. Toutes les tâches, ISR, alarmes et Schedule Tables actives de la partition sont immédiatement arrêtées et toutes les interruptions sont désactivées [SWS_Os_00447]. Dans l'état APPLICATION_RESTARTING, la OsRestartTask est exécutée de manière exclusive pour effectuer des nettoyages avant que le fonctionnement normal ne soit à nouveau autorisé ApplicationLevelErrorHandling p. 53, ApplicationLevelErrorHandling p. 76.
Diagramme d'états : cycle de vie et états de partitionnement d'une OS-Application AUTOSAR en cas d'erreur. Sources : [SWS_Os_00773], [SWS_Os_00258], ApplicationLevelErrorHandling p. 53.
Pour la prévention des erreurs, le système d'exploitation propose des fonctions de vérification de protection mémoire telles que CheckTaskMemoryAccess et CheckISRMemoryAccess [SWS_Os_00512], [SWS_Os_00513] ainsi que des vérifications de droits d'accès via CheckObjectAccess et CheckObjectOwnership [SWS_Os_00256], [SWS_Os_00017]. Ces vérifications normalisées permettent de s'assurer que les composants sans confiance n'effectuent pas d'accès non autorisés en écriture ou en exécution dans la mémoire SWS_OS p. 73.
Contexte de ce guide : établi sur la base des spécifications AUTOSAR Classic pour la version R20-11. Toutes les interfaces et transitions d'état sont rigoureusement étayées par les exigences SWS référencées.
Das AUTOSAR Operating System ist ein statisch konfiguriertes, echtzeitfähiges preemptives Betriebssystem nach OSEK/VDX mit Tasks, Events, Alarmen, Schedule-Tables und Speicherschutz.
Module im Cluster
Carte des thèmes
Os
79Aucune donnée d'élément pour cette version
Os
This callback function can be configured for the receiver of a communication. If configured, IOC calls this callback on the receiving core for each data reception. is the callback function name configured by the receiver in the Os Ioc Re ceiver Pull CB attribute to be called on data reception."
void <ReceiverPullCB> (void);This service determines if the OS - Applications, given by Appl ID, is allowed to use the IDs of a Task, Resource, Counter, Alarm or Schedule Table in API calls.
ObjectAccessType CheckObjectAccess (ApplicationType ApplID, ObjectTypeType ObjectType, void ...);Asynchronous version of the Activate Task() function. Intended to be used for cross core task activation. Possible errors are not returned to the caller, but may be reported via error hooks.
void ActivateTaskAsyn (TaskType id);This service sets the own state of an OS - Application from AP PLICATION_ RESTARTING to APPLICATION_ ACCESSIBLE.
StatusType AllowAccess (void);A (trusted or non - trusted) OS - Application uses this service to call a trusted function
StatusType CallTrustedFunction (TrustedFunctionIndexType FunctionIndex, TrustedFunctionParameterRefType FunctionParams);This service checks if a memory region is write/ read/ execute accessible and also returns information if the memory region is part of the stack space.
AccessType CheckISRMemoryAccess (ISRType ISRID, MemoryStartAddressType Address, MemorySizeType Size);This service determines to which OS - Application a given Task, ISR, Counter, Alarm or Schedule Table belongs
ApplicationType CheckObjectOwnership (ObjectTypeType ObjectType, void ...);This service checks if a memory region is write/ read/ execu te accessible and also returns information if the memory region is part of the stack space.
AccessType CheckTaskMemoryAccess (TaskType TaskID, MemoryStartAddressType Address, MemorySizeType Size);Service ClearPendingInterrupt.
StatusType ClearPendingInterrupt (ISRType ISRID);This API allows the caller to select the idle mode action which is performed during idle time of t he OS (e.g. if no Task/ ISR is active). It can be used to implement energy savings. The real idle modes are hardware dependent and not standardized. The default idle mode on each core is IDLE_ NO_ HALT.
StatusType ControlIdle (CoreIdType CoreID, IdleModeType IdleMode);Disables the interrupt source by modifying the interrupt controller registers.
StatusType DisableInterruptSource (ISRType ISRID);Service EnableInterruptSource.
StatusType EnableInterruptSource (ISRType ISRID, boolean ClearPending);This service determines the OS - Application (a unique identifier has to be allocated to each application) where the caller originally belongs to (was configured t o).
ApplicationType GetApplicationID (void);This service returns the current state of an OS - Application.
StatusType GetApplicationState (ApplicationType Application, ApplicationStateRefType Value);The function returns a unique core identifier.
CoreIdType GetCoreID (void);This service reads the current count value of a counte r (returning either the hardware timer ticks if counter is driven by hardware or the software ticks when user drives counter).
StatusType GetCounterValue (CounterType CounterID, TickRefType Value);This service determines the OS - Application where the caller of the service is currently executing. Note that if the caller is not within a Call Trusted Function() call the value is eq ual to the result of Get Application ID().
ApplicationType GetCurrentApplicationID (void);This service gets the number of ticks between the current tick value and a previously read tick value.
StatusType GetElapsedValue (CounterType CounterID, TickRefType Value, TickRefType ElapsedValue);This service returns the identifier of the currently executing ISR.
ISRType GetISRID (void);The function returns the number of cores activated by the Start Core function. This function might be a macro. AUTOSAR CP R20 - o f Document ID : AUTOSAR_SWS_OS
uint32 GetNumberOfActivatedCores (void);This service queries the state of a schedule table (also with respect to synchronization).
StatusType GetScheduleTableStatus (ScheduleTableType ScheduleTableID, ScheduleTableStatusRefType ScheduleStatus);Get Spinlock tries to occupy a spin - lock variable. If the function returns, either the lock is successfully taken or an error has occurred. The spinlock mechanism is an active polling mechanism. The function does not cause a de - scheduling.
StatusType GetSpinlock (SpinlockIdType SpinlockId);This service increments a software counter.
StatusType IncrementCounter (CounterType CounterID);This service initializes the data structures of the IOC. Tags: atp.Status=draft
void IocInit (void);This service modifies a given memory location () with the formula: * = ((* & ) | )
StatusType ModifyPeripheral16 (AreaIdType Area, uint16* Address, uint16 Clearmask, uint16 Setmask);This service modifies a given memory location () with the formula: * = ((* & ) | )
StatusType ModifyPeripheral32 (AreaIdType Area, uint32* Address, uint32 Clearmask, uint32 Setmask);This service modifies a given memory location () with the formula: * = ((* & ) | )
StatusType ModifyPeripheral8 (AreaIdType Area, uint8* Address, uint8 Clearmask, uint8 Setmask);This service switches the processing from one schedule table to another schedule table.
StatusType NextScheduleTable (ScheduleTableType ScheduleTableID_From, ScheduleTableType ScheduleTableID_To);The protection hook is always called if a serious error occurs. E.g. exceeding the worst case execution time or violating against the memory protection.
ProtectionReturnType ProtectionHook (StatusType Fatalerror);This service returns the content of a given memory location (
StatusType ReadPeripheral16 (AreaIdType Area, const uint16* Address, uint16* ReadValue);This service returns the content of a given memory location (
StatusType ReadPeripheral32 (AreaIdType Area, const uint32* Address, uint32* ReadValue);This service returns the content of a given memory location (
StatusType ReadPeripheral8 (AreaIdType Area, const uint8* Address, uint8* ReadValue);Release Spinlock releases a spinlock variable that was occupied before. Before terminating a TASK all spinlock variables that have been occupied with Get Spinlock() shall be released. Before calling Wait EVENT all Spinlocks shall be released.
StatusType ReleaseSpinlock (SpinlockIdType SpinlockId);Asynchronous version of the Set Event() function. Intended to be used for cross core event setting. Possible errors are not returned to the caller, but may be reported via error hooks.
void SetEventAsyn (TaskType id, EventMaskType m);This service stops synchronization of a schedule table.
StatusType SetScheduletableAsync (ScheduleTableType ScheduleTableID);After this service the OS on all AUTOSAR cores is shut down. Allowed at TASK level and ISR level and also internally by the OS. The function will never return. The function will force other cores into a shutdown.
void ShutdownAllCores (StatusType Error);It is not supported to call this function after Start OS(). The function starts the core specified by the parameter Core ID. The OUT parameter allows the caller to check whether the operation was successful or no t. If a core is started by means of this function Start OS shall be called on the core.
void StartCore (CoreIdType CoreID, StatusType* Status);The function start s the core specified by the parameter Core ID. It is allowed to call this function after Start OS(). The OUT parameter allows the caller to check whether the operation was successful or not. It is not allowed to call Start OS on cores activated by Start No n Autosar Core. Otherwise the behaviour is unspecified.
void StartNonAutosarCore (CoreIdType CoreID, StatusType* Status);This service starts the processing o f a schedule table at an absolute value "Start" on the underlying counter.
StatusType StartScheduleTableAbs (ScheduleTableType ScheduleTableID, TickType Start);This service starts the processing of a schedule table at "Offset" relative to the "Now" value on the underlying counter.
StatusType StartScheduleTableRel (ScheduleTableType ScheduleTableID, TickType Offset);This service starts an explicitly synchronized schedule table synchronously.
StatusType StartScheduleTableSynchron (ScheduleTableType ScheduleTableID);This service cancels the processing of a schedule table immediately at any point while the schedule table is running.
StatusType StopScheduleTable (ScheduleTableType ScheduleTableID);Service SyncScheduleTable.
StatusType SyncScheduleTable (ScheduleTableType ScheduleTableID, TickType Value);Service TerminateApplication.
StatusType TerminateApplication (ApplicationType Application, RestartType RestartOption);Try To Get Spinlock has the same functionality as Get Spinlock with the difference that if the spinlock is already occupied by a TASK on a d ifferent core the function sets the OUT parameter "Success" and returns with E_ OK.
StatusType TryToGetSpinlock (SpinlockIdType SpinlockId, TryToGetSpinlockType* Success);This service writes the to a given memory location (). Available vi a Os.h
StatusType WritePeripheral16 (AreaIdType Area, uint16* Address, uint16 WriteValue);This service writes the to a given memory location ().
StatusType WritePeripheral32 (AreaIdType Area, uint32* Address, uint32 WriteValue);This service writes the to a given memory location (). Available vi a Os.h
StatusType WritePeripheral8 (AreaIdType Area, uint8* Address, uint8 WriteValue);This type holds information how a specific memory region can be accessed.
This data type points to location where a Application State Type can be stored.
This data type identifies the state of an OS - Application. AUTOSAR CP R20 - o f Document ID : AUTOSAR_SWS_OS
This data type identifies the OS - Application.
App Mode of the core shall be inherited from another core.
Area Id Type identifies a peripheral area and is used by the API functions: Read Peripheral X, Write Peripheral X and Modify Peripheral X AUTOSAR CP R20 - o f Document ID : AUTOSAR_SWS_OS
Core Id Type is a scalar that allows identifying a single core. The Core Id Type shall represent t he logical Core ID
This data type identifies a counter.
This data type represents an event mask for extended tasks.
typedef uint32 EventMaskType;This data type identifies the idle mode behavior.
This data type identifies an interrupt service routine (ISR).
This data type holds the size (in bytes) of a memory region.
This data type is a pointer which is able to point to any location in the MCU address space.
This data type identifies if an OS - Application has access to an object.
This data type identifies an object.
This data type is used for values returned by the conversion macro (see SWS_ Os_00393) OS_ TICKS2_(). AUTOSAR CP R20 - o f Document ID : AUTOSAR_SWS_OS
This data type identifies a value which controls further actions of the OS on return from the protection hook.
This data type defines the use of a Restart Task after terminating an OS - Application.
This data type points to a variable of the data type Schedule Table Status Type.
This type describes the status of a schedule. The status can be one of the following: o The schedule table is not started (SCHEDULETABLE_ STOPPED) o The schedule table will be started after the end of currently running schedule table (sched ule table was used in Next Schedule Table() service) (SCHEDULETABLE_ NEXT) o The schedule table uses explicit synchronization, has been started and is waiting for the global time. (SCHEDULETABLE_ WAITING) o The schedule table is running, but is currently n ot synchronous to a global time source (SCHEDULETABLE_ RUNNING) o The schedule table is running and is synchronous to a global time source (SCHEDULETABLE_ RUNNING_ AND_ SYNCHRONOUS)
This data type identifies a schedule table.
Spinlock Id Type identifies a spinlock instance and is used by the API functions: Get Spinlock, Release Spinlock and Try To Get Spinlock.
This data type represents standard OSEK OS status codes (e.g. E_OK, E_OS_ACCESS).
typedef uint8 StatusType;-
The total number of cores
This data type identifies a trusted function.
This data type points to a structure which holds the arguments for a call to a trusted function.
The Try To Get Spinlock Type indicates if the spinlock has been occupied or not.
gemini-3.8-flash-low· 2026-10-13 · Original allemand