DEENESPTFRRUARHIKOZHNL

Memory Abstraction Interface (MemIf)

ModulMemIf (Memory Abstraction Interface)
BSW-Modul-ID22
Standard-Header#include "MemIf.h"
SWS-SpezifikationAUTOSAR_SWS_MemoryAbstractionInterface.pdf
ClusterMemory Services

Guide du moduleGÉNÉRÉ PAR IA

Transmet les requêtes de mémoire du gestionnaire NVRAM à l'émulation Flash-EEPROM ou à l'abstraction EEPROM par index de composant.
GÉNÉRÉ PAR IA non vérifié Modèle : claude-opus-5-5 · Effort : high · Température : non réglable · Prompt : 423eb9cf4c9b Provenance Questions ouvertes (5)
Ancre causale : R20-11 Valable à partir de R20-11 Synthétisé pour cette version de spécification.
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Transmet les requêtes de mémoire du gestionnaire NVRAM à l'émulation Flash-EEPROM ou à l'abstraction EEPROM par index de composant.

MemIf transmet les requêtes de mémoire du NVRAM Manager aux modules Fee ou Ea et masque leur nombre derrière une API uniforme SWS MemIf p. 7. Le paramètre DeviceIndex sélectionne le module ; si un seul est configuré, il est ignoré et MemIf est implémenté sous la forme d'un jeu de macros SWS MemIf p. 17. Les services acceptent les requêtes de manière synchrone et transmettent la valeur de retour, tandis que l'opération de mémoire s'exécute de manière asynchrone en dessous. L'état et le résultat sont fournis par MemIf_GetStatus et MemIf_GetJobResult. Lorsque la détection des erreurs de développement est active, les appels erronés renvoient E_NOT_OK ou MEMIF_JOB_FAILED.

La Memory Abstraction Interface remplace les anciennes couches d'interface de pilotes pour Flash et EEPROM. Elle permet au NVRAM Manager d'adresser plusieurs modules d'abstraction via une API uniforme : la Flash EEPROM Emulation (Fee) et l'EEPROM Abstraction (Ea) SRS MemHwAb p. 5. MemIf masque le nombre de ces modules et propose une segmentation virtuelle sur un espace d'adressage linéaire SWS MemIf p. 7.

kontext cluster_services Services Layer cluster_abstraktion Memory Hardware Abstraction cluster_treiber Memory Drivers NvM NvM (NVRAM Manager) MemIf MemIf (Memory Abstraction Interface) NvM->MemIf MemIf_Read / MemIf_Write / ... (DeviceIndex) Fee Fee (Flash EEPROM Emulation) MemIf->Fee Fee_* Ea Ea (EEPROM Abstraction) MemIf->Ea Ea_* Lib Herstellerspezifische Bibliothek (statt Fee/Ea + Treiber) MemIf->Lib même API que Fee/Ea Det Det (optional) MemIf->Det Det_ReportError Fee->NvM NvM_JobEndNotification / NvM_JobErrorNotification Fls Flash Driver Fee->Fls Ea->NvM NvM_JobEndNotification / NvM_JobErrorNotification Eep EEPROM Driver Ea->Eep

Diagramme de contexte : MemIf sert d'intermédiaire entre NvM et Fee/Ea ; les notifications de fin proviennent directement de Fee/Ea à destination du NvM. Sources : SWS Fee p. 6, [SWS_MemIf_00047]

MemIf ne possède aucune logique de mémorisation propre. Le paramètre DeviceIndex sélectionne le module ; si un seul est configuré, il est ignoré et MemIf est implémenté sous la forme d'un jeu de macros. En présence de plusieurs modules, la distribution s'effectue par exemple via des tables de pointeurs de fonction SWS MemIf p. 17. Dans R20-11, DeviceIndex est du type uint8 [SWS_MemIf_00039] ; des versions ultérieures utilisent uint16.

Les services acceptent les requêtes de manière synchrone et transmettent la valeur de retour du module [SWS_MemIf_00040]. L'opération de mémoire s'exécute ensuite de manière asynchrone dans la fonction principale de la couche inférieure. Le NvM prend connaissance de la fin du traitement par un rappel issu de Fee/Ea ou par scrutation (polling) de MemIf_GetJobResult SWS Fee p. 48. MemIf_GetStatus signale UNINIT, IDLE, BUSY ou BUSY_INTERNAL [SWS_MemIf_00064]. Le résultat de tâche se rapporte toujours à la dernière requête et distingue notamment les blocs interrompus, incohérents et invalides [SWS_MemIf_00065]. MemIf_SetMode s'applique à tous les modules simultanément [SWS_MemIf_00038].

Tâche d'écriture via MemIf (exemple Ea/Eep)NvMMemIfEaEepTâche BSW (tâche OS ou appel cyclique)Use Case: Auftragsannahme (synchron)MemIf_Write(DeviceIndex,BlockNumber, DataBufferPtr)Sélectionner le module via DeviceIndexEa_Write(BlockNumber, DataBufferPtr)Eep_Write(EepromAddress,DataBufferPtr, Length)Std_ReturnTypeStd_ReturnTypeStd_ReturnType (inchangé)Use Case: Exécution (asynchrone)Jusqu'à la fin, GetJobResult renvoieMEMIF_JOB_PENDINGloopjusqu'à ce que la tâche soit terminéeEep_MainFunction()altBenachrichtigung konfiguriertEa_JobEndNotification()NvM_JobEndNotification()Polling-BetriebMemIf_GetJobResult(DeviceIndex)Ea_GetJobResult()MEMIF_JOB_OKMEMIF_JOB_OK

Diagramme de séquence : acceptation synchrone via MemIf, exécution asynchrone dans le pilote, achèvement par rappel ou scrutation. Sources : SWS Ea p. 41, [SWS_MemIf_00040]

En cas d'erreur, MemIf signale les index de composants non valides et les pointeurs NULL comme erreurs de développement [SWS_MemIf_00006]. Les services renvoient alors E_NOT_OK, MemIf_GetJobResult renvoie MEMIF_JOB_FAILED SWS MemIf p. 21. Les erreurs d'exécution de la mémoire sont détectées par Fee ou Ea ; le NvM les lit en mode scrutation sous forme de MEMIF_JOB_FAILED et a la charge d'y remédier ErrorDescription p. 58.

Rôle dans la pile de mémoire : aiguillage entre NvM et Fee/Ea

La Memory Abstraction Interface (MemIf) remplace les anciennes couches d'interface de pilotes pour Flash et EEPROM. Elle permet au NVRAM Manager (NvM) d'adresser plusieurs modules d'abstraction de mémoire via une seule API : la Flash EEPROM Emulation (Fee) et l'EEPROM Abstraction (Ea) SRS MemHwAb p. 5. Vers le haut, MemIf masque le nombre de modules Fee et Ea sous-jacents. Elle offre une segmentation virtuelle sur un espace d'adressage linéaire uniforme SWS MemIf p. 7. Fee et Ea fournissent l'adressage par blocs et un nombre « virtuellement illimité » de cycles d'effacement-écriture. Par conséquent, le NvM n'a pas besoin d'être modifié lors d'un changement de pilote ou de composant SRS MemHwAb p. 5.

MemIf ne contient lui-même aucune logique de mémorisation. Son API doit être mappée sur l'API des modules d'abstraction, et le comportement fonctionnel est défini par les spécifications de ces derniers ou par celles des pilotes de mémoire SWS MemIf p. 17. En conséquence, MemIf nécessite les services des modules d'abstraction, pour Ea par exemple Ea_Read, Ea_Cancel, Ea_GetStatus et Ea_GetJobResult [SWS_MemIf_00047]. De manière optionnelle, il utilise Det_ReportError [SWS_MemIf_00048]. Les types MemIf_StatusType, MemIf_JobResultType et MemIf_ModeType définis dans MemIf.h constituent le vocabulaire commun de la pile [SWS_MemIf_00064] [SWS_MemIf_00065] [SWS_MemIf_00066]. Ainsi, Fls_GetJobResult fournit par exemple directement MemIf_JobResultType SWS Fls p. 36.

Les figures des versions plus récentes montrent, sous Ea et Fee, les modules MemAcc et Mem supplémentaires SWS Ea p. 42. Pour R20-11, la vue d'ensemble plus ancienne, dans laquelle Fee repose sur le pilote Flash et Ea sur le pilote EEPROM, est vraisemblablement déterminante (supposition) SWS Fee p. 6. Pour MemIf, cette différence n'a aucune importance, car il ne fait que retransmettre jusqu'au niveau d'abstraction SWS MemIf p. 17. Question Q-3c74a6029dd0d159 (ouverte)

kontext cluster_services Services Layer cluster_abstraktion Memory Hardware Abstraction cluster_treiber Memory Drivers NvM NvM (NVRAM Manager) MemIf MemIf (Memory Abstraction Interface) NvM->MemIf MemIf_Read / MemIf_Write / ... (DeviceIndex) Fee Fee (Flash EEPROM Emulation) MemIf->Fee Fee_* Ea Ea (EEPROM Abstraction) MemIf->Ea Ea_* Lib Herstellerspezifische Bibliothek (statt Fee/Ea + Treiber) MemIf->Lib même API que Fee/Ea Det Det (optional) MemIf->Det Det_ReportError Fee->NvM NvM_JobEndNotification / NvM_JobErrorNotification Fls Flash Driver Fee->Fls Ea->NvM NvM_JobEndNotification / NvM_JobErrorNotification Eep EEPROM Driver Ea->Eep

Diagramme de contexte : MemIf s'intercale entre le NvM et les modules d'abstraction Fee/Ea ; les notifications de fin parviennent au NvM directement depuis Fee/Ea. Sources : SWS Fee p. 6, SRS MemHwAb p. 5, [SWS_MemIf_00047], [SWS_MemIf_00048]

Sélection du composant via DeviceIndex : macros ou table de distribution

Le paramètre DeviceIndex sélectionne le module d'abstraction et donc le composant mémoire. Si un seul module est configuré, il est ignoré SWS MemIf p. 17. Dans ce cas, MemIf doit être implémenté sous la forme d'un ensemble de macros, tel que #define MemIf_Write(DeviceIndex, BlockNumber, DataPtr) Fee_Write(BlockNumber, DataPtr). En présence de plusieurs modules, les appels doivent être distribués via des mécanismes efficaces ; la spécification cite comme solution des tables de pointeurs de fonction indexées par DeviceIndex SWS MemIf p. 17. Si une bibliothèque spécifique au constructeur remplace tous les modules Fee et Ea nécessaires, MemIf n'est constitué que de macros SRS MemHwAb p. 5.

Dans R20-11, DeviceIndex est du type uint8 [SWS_MemIf_00039] [SWS_MemIf_00041]. Des versions ultérieures de la spécification l'indiquent comme uint16 SWS MemIf p. 18. La référence normative pour cette version est uint8.

abbildung start Konfiguration von MemIf q0 Une bibliothèque constructeur remplace-t-elle tous les modules Fee et Ea ? start->q0 lib MemIf se compose uniquement de macros vers l'API de la bibliothèque q0->lib Oui q1 Combien de modules d'abstraction sont configurés ? q0->q1 Non ende La fonction du module est appelée, la valeur de retour est transmise lib->ende ein Des macros mappent l'API MemIf (par ex. MemIf_Write -> Fee_Write) q1->ein exactement un mehr Effiziente Verteilung, z. B. Funktionszeigertabelle q1->mehr mehrere ign DeviceIndex est ignoré ein->ign ign->ende idx DeviceIndex sélectionne le module (Fee ou Ea) mehr->idx idx->ende

Diagramme d'activité : le nombre de modules d'abstraction configurés détermine le choix entre un mappage par macro et une distribution par DeviceIndex. Sources : SWS MemIf p. 17, SRS MemHwAb p. 5

Déroulement d'une tâche : acceptation synchrone, exécution asynchrone

Tous les services MemIf sont spécifiés comme synchrones. Chacun appelle la fonction du même nom du module sélectionné et renvoie sa valeur de retour, à l'exemple de Read, Write et InvalidateBlock [SWS_MemIf_00039] [SWS_MemIf_00040] [SWS_MemIf_00044]. L'opération de mémoire proprement dite s'exécute ensuite de manière asynchrone dans la fonction principale appelée cycliquement de la couche inférieure. La séquence Ea présente à cet effet une boucle sur Eep_MainFunction dans la tâche BSW SWS Ea p. 41. Selon la spécification Fee, ce modèle s'applique également aux autres services asynchrones SWS Fee p. 48.

Selon la configuration de la pile, le NvM est informé de la fin de la tâche par l'une de deux voies. Soit le module d'abstraction appelle un callback tel que NvM_JobEndNotification ou NvM_JobErrorNotification, soit le NvM scrute MemIf_GetJobResult SWS Fee p. 48 EXP ErrorDescription p. 45. MemIf ne fournit lui-même aucune fonction de rappel ; son API se compose des services suivants [SWS_MemIf_00038] [SWS_MemIf_00046].

ServiceID de serviceretourEffet
MemIf_SetMode0x01–appelle SetMode de tous les modules d'abstraction [SWS_MemIf_00038]
MemIf_Read0x02Std_ReturnTypelit Length octets du bloc à partir de BlockOffset vers DataBufferPtr [SWS_MemIf_00039]
MemIf_Write0x03Std_ReturnTypeécrit un bloc [SWS_MemIf_00040]
MemIf_Cancel0x04–annule la tâche en cours [SWS_MemIf_00041]
MemIf_GetStatus0x05MemIf_StatusTypeétat du module [SWS_MemIf_00042]
MemIf_GetJobResult0x06MemIf_JobResultTyperésultat de la dernière tâche [SWS_MemIf_00043]
MemIf_InvalidateBlock0x07Std_ReturnTypeinvalide un bloc [SWS_MemIf_00044]
MemIf_GetVersionInfo0x08–Informations de version, réentrant [SWS_MemIf_00045]
MemIf_EraseImmediateBlock0x09Std_ReturnTypeefface un bloc [SWS_MemIf_00046]
Tâche d'écriture via MemIf (exemple Ea/Eep)NvMMemIfEaEepTâche BSW (tâche OS ou appel cyclique)Use Case: Auftragsannahme (synchron)MemIf_Write(DeviceIndex,BlockNumber, DataBufferPtr)Sélectionner le module via DeviceIndexEa_Write(BlockNumber, DataBufferPtr)Eep_Write(EepromAddress,DataBufferPtr, Length)Std_ReturnTypeStd_ReturnTypeStd_ReturnType (inchangé)Use Case: Exécution (asynchrone)Jusqu'à la fin, GetJobResult renvoieMEMIF_JOB_PENDINGloopjusqu'à ce que la tâche soit terminéeEep_MainFunction()altBenachrichtigung konfiguriertEa_JobEndNotification()NvM_JobEndNotification()Polling-BetriebMemIf_GetJobResult(DeviceIndex)Ea_GetJobResult()MEMIF_JOB_OKMEMIF_JOB_OK

Diagramme de séquence : une requête d'écriture est acceptée de manière synchrone via MemIf, exécutée de manière asynchrone dans le pilote et terminée par callback ou scrutation. Sources : SWS Ea p. 41, SWS Fee p. 48, ErrorDescription p. 60, [SWS_MemIf_00040]

État, résultat de job et mode de fonctionnement

MemIf_GetStatus fournit l'état du module sélectionné [SWS_MemIf_00042]. Les valeurs possibles sont MEMIF_UNINIT, MEMIF_IDLE, MEMIF_BUSY et MEMIF_BUSY_INTERNAL. Avec MEMIF_BUSY_INTERNAL, le module d'abstraction est occupé par des tâches d'administration internes, tandis que le pilote peut être occupé (busy) ou inactif (idle) [SWS_MemIf_00064]. La spécification de Fee concrétise les conditions et cite comme exemple de gestion interne la réorganisation de la mémoire flash (ramasse-miettes / garbage collection) SWS Fee p. 30. Pour le pilote flash, l'état peut être interrogé dès avant l'initialisation et vaut alors MEMIF_UNINIT SWS Fls p. 35.

status start commencer UNINIT MEMIF_UNINIT start->UNINIT IDLE MEMIF_IDLE UNINIT->IDLE Modul initialisiert BUSY MEMIF_BUSY IDLE->BUSY Tâche de la couche supérieure en cours de traitement BUSYINT MEMIF_BUSY_INTERNAL IDLE->BUSYINT interne Verwaltung (z. B. Garbage Collection) BUSY->IDLE Auftrag beendet BUSYINT->IDLE interne Verwaltung beendet

Diagramme d'états : cycle de vie de l'état de module visible via MemIf_GetStatus. Sources : [SWS_MemIf_00064], SWS Fee p. 30

MemIf_GetJobResult fournit le résultat de la dernière requête [SWS_MemIf_00043] [SWS_MemIf_00065]. La lecture, l'écriture et l'effacement partagent un unique résultat de job, de sorte que seul celui de la dernière requête peut être interrogé. Dès l'acceptation d'une nouvelle requête, il est positionné à MEMIF_JOB_PENDING SWS Fls p. 36 ; Fee parle de la dernière requête acceptée SWS Fee p. 31. Outre OK, FAILED et CANCELED, il existe deux résultats liés aux blocs. MEMIF_BLOCK_INCONSISTENT signifie que le bloc est corrompu ou introuvable ; MEMIF_BLOCK_INVALID signifie qu'il est marqué comme invalide [SWS_MemIf_00065].

jobergebnis neu Neuer Auftrag angenommen PENDING MEMIF_JOB_PENDING neu->PENDING OK MEMIF_JOB_OK PENDING->OK erfolgreich beendet FAILED MEMIF_JOB_FAILED PENDING->FAILED échec CANCELED MEMIF_JOB_CANCELED PENDING->CANCELED abgebrochen INCONS MEMIF_BLOCK_INCONSISTENT PENDING->INCONS Bloc corrompu ou non trouvé INVALID MEMIF_BLOCK_INVALID PENDING->INVALID Bloc marqué comme invalide OK->neu tâche suivante FAILED->neu tâche suivante CANCELED->neu tâche suivante INCONS->neu tâche suivante INVALID->neu tâche suivante

Diagramme d'états : une requête acceptée est à l'état PENDING et aboutit à exactement l'un des résultats finaux. Sources : [SWS_MemIf_00065], SWS Fls p. 36, SWS Fee p. 31

MemIf_SetMode est le seul service à ne pas posséder de DeviceIndex et appelle SetMode sur tous les modules d'abstraction [SWS_MemIf_00038]. Les modes sont MEMIF_MODE_SLOW et MEMIF_MODE_FAST [SWS_MemIf_00066]. Au niveau des pilotes, cela correspond respectivement à un accès en lecture lente ou accès SPI standard d'une part, et à un accès en lecture rapide ou rafale SPI (burst) d'autre part. Eep_SetMode ne doit pas être appelé pendant une opération en cours SWS Eep p. 34. Fls_SetMode rejette une requête lorsque le contrôle est actif et que l'état est occupé (busy) SWS Fls p. 42. Interprétation : étant donné que MemIf_SetMode atteint tous les modules, il ne devrait être appelé que si tous les périphériques signalent MEMIF_IDLE. Question Q-d6ee630fca619042 (ouverte)

Annulation des requêtes en cours

MemIf_Cancel appelle la fonction Cancel du module sélectionné [SWS_MemIf_00041]. L'annulation elle-même est synchrone, mais asynchrone vis-à-vis du matériel : le matériel peut continuer à fonctionner après le retour de l'appel SWS Fee p. 45 SWS Ea p. 44. Le résultat de job passe ensuite à MEMIF_JOB_CANCELED [SWS_MemIf_00065], ce que Fee considère expressément comme un échec SWS Fee p. 31.

Pour le chemin flash, la spécification du pilote présente la chaîne MemIf_Cancel → Fee_Cancel → Fls_Cancel suivie de notifications d'erreur. Elle exige en outre de ne pas appeler Fls_Cancel pendant une Fls_MainFunction en cours. Deux approches sont possibles : synchroniser les fonctions de job de NvM et du pilote flash, ou ne pas interrompre la tâche de la Fls_MainFunction SWS Fls p. 58.

Annulation d'une tâche Flash en coursNvMMemIfFeeFlsMemIf_Cancel(DeviceIndex)Fee_Cancel()Fls_Cancel()Fls_Cancel pas pendantlaufender Fls_MainFunctionRetourRetourRetour (synchrone)L'annulation est asynchronevers le matérieloptFehlerbenachrichtigung konfiguriertFee_JobErrorNotification()NvM_JobErrorNotification()MemIf_GetJobResult(DeviceIndex)Fee_GetJobResult()MEMIF_JOB_CANCELEDMEMIF_JOB_CANCELED

Diagramme de séquence : l'annulation s'exécute de manière synchrone à travers toutes les couches, la notification d'erreur suit, puis GetJobResult signale CANCELED. Sources : SWS Fls p. 58, SWS Fee p. 45, [SWS_MemIf_00041]

Règles d'appel, réentrance et intégration dans la BSW

À l'exception de MemIf_GetVersionInfo, tous les services sont non réentrants [SWS_MemIf_00045] [SWS_MemIf_00040]. Les appels parallèles depuis plusieurs contextes doivent donc être exclus. L'état et le résultat de job ne reflétant par module que la dernière requête, l'appelant ne devrait émettre une nouvelle requête qu'après l'achèvement de la précédente SWS Fls p. 36.

L'exemple de mappage mémoire d'un cluster ICC2 « MEM » associe MemIf à NvM. MemIf_SetMode y est modélisé sous forme de BswCalledEntity, et MemIf utilise le préfixe de section MEMIF SWS MemoryMapping p. 50. Le BSW Distribution Guide cite MEMIF aux côtés de FLS et FEE comme exemple de « Type I » ; le domaine de validité peut être limité à un seul cœur par SwAddrMethod avec une portée locale EXP BSWDistributionGuide p. 31. Vraisemblablement, MemIf doit donc être exploité de manière locale au cœur dans les architectures multicoeurs. Question Q-d998fdc58e0bcddd (ouverte)

Comportement en cas d'erreur

MemIf définit deux erreurs de développement. MEMIF_E_PARAM_DEVICE (0x01) correspond à un DeviceIndex incorrect, MEMIF_E_PARAM_POINTER (0x02) à un pointeur NULL [SWS_MemIf_00006]. Elles sont signalées via le module optionnel Det_ReportError [SWS_MemIf_00048]. Selon la table de traçabilité, les codes d'erreur spécifiques ne sont pas renvoyés via l'API SWS MemIf p. 12.

Si la détection des erreurs de développement est active et qu'une erreur est détectée, Read, Write, InvalidateBlock et EraseImmediateBlock renvoient E_NOT_OK [SWS_MemIf_00039] [SWS_MemIf_00040] [SWS_MemIf_00044] [SWS_MemIf_00046]. Dans ce cas, MemIf_GetJobResult renvoie MEMIF_JOB_FAILED SWS MemIf p. 21. Sinon, la valeur du module est transmise sans modification.

fehlerpruefung aufruf Appel d'un service MemIf (DeviceIndex, pointeur le cas échéant) q1 Entwicklungsfehlererkennung aktiviert? aufruf->q1 q2 Paramètres valides ? q1->q2 Oui weiter Appeler la fonction du module sélectionné via DeviceIndex q1->weiter Non det Det_ReportError avec MEMIF_E_PARAM_DEVICE (0x01) ou MEMIF_E_PARAM_POINTER (0x02) q2->det Non q2->weiter Oui fehl Retour de E_NOT_OK (MemIf_GetJobResult : MEMIF_JOB_FAILED) det->fehl rueck Renvoyer inchangée la valeur de retour du module weiter->rueck

Diagramme d'activité : vérification des paramètres lorsque la détection des erreurs de développement est active et transmission du résultat du module. Sources : [SWS_MemIf_00006], [SWS_MemIf_00048], SWS MemIf p. 18, SWS MemIf p. 21

Les erreurs d'exécution de la mémoire ne sont pas détectées par MemIf, mais par Fee ou Ea ; MemIf lui-même n'y réagit pas (« N/A »). En mode de scrutation (polling), NvM lit l'erreur via MemIf_GetJobResult sous la forme MEMIF_JOB_FAILED, et le traitement de l'erreur incombe à NvM ErrorDescription p. 58 ErrorDescription p. 60. Une version plus récente décrit ce traitement plus en détail. D'après celle-ci, NvM incrémente un compteur de tentatives lors des requêtes d'écriture, abandonne en cas de dépassement et signale NVM_E_REQ_FAILED au DEM EXP ErrorDescription p. 45. Pour R20-11, ce détail n'est pas étayé de façon normative ici.

Preuves détaillées supplémentaires

Guide généré par IA sur la base des extraits de spécification fournis dans le prompt. Les exigences référencées de la release R20-11 font foi. Les interprétations sont signalées comme telles.

Memory Abstraction Interface (MemIf)

Abstracts underlying Flash and EEPROM memory drivers.

Funktionen — Übersicht

Typen — Übersicht

Funktionen & Typen — Detailansicht

fonction MemIf_SetMode [SWS_MemIf_00038] 📄 PDF

void MemIf_SetMode (MemIf_ModeType Mode);

Invokes the "Set Mode" functions of all underlying memory abstraction modules.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : e9d6121ccdfc Provenance Questions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction MemIf_SetMode sert à commuter de manière synchrone le mode de fonctionnement via l’interface de mémoire [SWS_MemIf_00038]. Lors de l’appel, elle transmet le mode demandé aux fonctions individuelles « Set Mode » de l’ensemble des modules d’abstraction de mémoire sous-jacents [SWS_MemIf_00038]. Le mode cible Mode est transmis comme paramètre, tandis que la fonction ne fournit aucune valeur de retour [SWS_MemIf_00038]. L’interface est définie avec l’ID de service 0x01 dans l’en-tête MemIf.h [SWS_MemIf_00038].

Concernant la concurrence, MemIf_SetMode est spécifiée comme non réentrante (Non Reentrant) [SWS_MemIf_00038]. Interprétation : les appelants ne doivent probablement pas appeler la fonction de manière simultanée ou avec interruption depuis plusieurs tâches ou routines de service d’interruption, raison pour laquelle un accès concurrent devrait être coordonné, si nécessaire, par des mécanismes de protection externes. Question Q-02b14e9cb4b05dc9 (ouverte)

En raison de la sémantique d’exécution synchrone, l’appel ne revient à l’appelant qu’après la transmission de la demande aux modules d’abstraction de mémoire [SWS_MemIf_00038]. Aucune valeur de retour spécifique pour l’indication d’erreurs ni aucun message d’erreur DET ou DEM distinct ne sont prévus pour cette fonction dans la spécification de l’élément [SWS_MemIf_00038].

Cette note d’utilisation a été générée de manière automatisée et repose exclusivement sur les indications de la spécification AUTOSAR R20-11.

Guide de l'implémenteur à venir (complexité I1)

fonction MemIf_Read [SWS_MemIf_00039] 📄 PDF

Std_ReturnType MemIf_Read (uint8 DeviceIndex, uint16 BlockNumber, uint16 BlockOffset, uint8* DataBufferPtr, uint16 Length);

Invokes the "Read" function of the underlying memory abstraction module selected by the parameter Device Index.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 9f6882978f36 Provenance Questions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction MemIf_Read transmet de manière synchrone une requête de lecture au sous-module d'abstraction de mémoire sélectionné via le paramètre DeviceIndex [SWS_MemIf_00039]. Elle est déclarée dans l'en-tête MemIf.h et sert à la lecture de données d'un bloc de mémoire logique.

Paramètres et interface

L'appel de MemIf_Read comprend les paramètres d'entrée et de sortie suivants [SWS_MemIf_00039] :

  • DeviceIndex : index du périphérique cible pour la sélection du module cible.
  • BlockNumber : numéro de bloc logique du bloc de mémoire à lire.
  • BlockOffset : décalage en octets (offset) au sein du bloc logique à partir duquel la lecture est effectuée.
  • DataBufferPtr : pointeur vers le tampon destiné au stockage des données lues.
  • Length : nombre d'octets de données à lire.

Gestion des erreurs et valeurs de retour

Si la détection des erreurs de développement (Development Error Detection) est active et qu'une erreur de développement est détectée, la fonction renvoie E_NOT_OK [SWS_MemIf_00039]. Sinon, la valeur de retour de la fonction de lecture appelée du module sous-jacent est transmise comme Std_ReturnType [SWS_MemIf_00039].

Concurrence et restrictions

La fonction est spécifiée comme synchrone et non réentrante (Non Reentrant) [SWS_MemIf_00039]. Un appel devrait donc typiquement avoir lieu dans un contexte de tâche ; les appels parallèles ou imbriqués doivent être évités ou sérialisés par l'appelant. Question Q-b774bf07a69e28af (ouverte)

Cette note d'utilisation a été générée par une IA et est basée sur la spécification AUTOSAR R20-11.

fonction MemIf_Write [SWS_MemIf_00040] 📄 PDF

Std_ReturnType MemIf_Write (uint8 DeviceIndex, uint16 BlockNumber, const uint8* DataBufferPtr);

Invokes the "Write" function of the underlying memory abstraction module selected by the parameter Device Index.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 88682d2af3e3 Provenance
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Utilisation et contexte d'appel

La fonction d'interface MemIf_Write sert de couche d'abstraction et appelle la fonction Write du module d'abstraction de mémoire sous-jacent qui est sélectionné via le paramètre DeviceIndex [SWS_MemIf_00040]. Lors de l'appel synchrone, trois paramètres d'entrée sont transmis : l'index de périphérique DeviceIndex pour la sélection du pilote cible, le numéro de bloc logique BlockNumber ainsi que le pointeur DataBufferPtr vers le tampon contenant les données à écrire [SWS_MemIf_00040]. La fonction est spécifiée sous l'ID de service 0x03 et est disponible via le fichier d'en-tête MemIf.h [SWS_MemIf_00040].

Gestion des erreurs et valeurs de retour

La valeur de retour est de type Std_ReturnType [SWS_MemIf_00040]. Si la détection des erreurs de développement (Development Error Detection) pour le Memory Abstraction Interface est active et qu'une erreur de développement selon [SWS_MemIf_00022] est constatée, MemIf_Write renvoie le code d'erreur E_NOT_OK [SWS_MemIf_00040]. S'il n'y a pas d'erreur, la fonction transmet la valeur de retour du module sous-jacent appelé de manière inchangée à l'appelant [SWS_MemIf_00040].

Concurrence et contraintes

En ce qui concerne le comportement de concurrence, MemIf_Write est défini comme synchrone et non réentrant (Non Reentrant) [SWS_MemIf_00040].

Cette note d'utilisation a été générée par une IA sur la base de la spécification AUTOSAR Classic R20-11.

fonction MemIf_Cancel [SWS_MemIf_00041] 📄 PDF

void MemIf_Cancel (uint8 DeviceIndex);

Invokes the "Cancel" function of the underlying memory abstraction module selected by the parameter Device Index.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : fa67da25152e Provenance Questions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction synchrone MemIf_Cancel sert à appeler la fonction Cancel du module d'abstraction de mémoire sous-jacent, qui est sélectionné via le paramètre Device Index [SWS_MemIf_00041]. Le service ne possède pas de valeur de retour et transmet immédiatement la requête d'interruption à l'instance d'abstraction adressée [SWS_MemIf_00041].

Les propriétés techniques suivantes s'appliquent à l'appel et à l'intégration :

  • Contexte d'appel et concurrence : la fonction est définie comme non réentrante (Non Reentrant) [SWS_MemIf_00041]. Les appelants doivent s'assurer que l'exécution n'a pas lieu de façon concurrente ou avec interruption par d'autres contextes.
  • Signature et identification : l'interface void MemIf_Cancel (uint8 Device Index) possède l'ID de service 0x04 et est mise à disposition via le fichier d'en-tête MemIf.h [SWS_MemIf_00041].
  • Paramètres : le paramètre d'entrée Device Index (type uint8) sélectionne le module cible ; aucun paramètre d'entrée/sortie ou de retour n'est présent [SWS_MemIf_00041].
  • Traitement des erreurs : la spécification ne décrit aucun code d'erreur spécifique, valeur de retour ou message DET pour cette fonction [SWS_MemIf_00041] (interprétation : une vérification des index de périphériques non autorisés devrait être laissée à l'architecture système de niveau supérieur ou au module sous-jacent). Question Q-4a5d989ce611ba89 (ouverte)

Cette note d'utilisation a été créée par une IA sur la base de la spécification AUTOSAR R20-11.

fonction MemIf_GetStatus [SWS_MemIf_00042] 📄 PDF

MemIf_StatusType MemIf_GetStatus (uint8 DeviceIndex);

Invokes the "Get Status" function of the underlying memory abstraction module selected by the parameter Device Index.

fonction MemIf_GetJobResult [SWS_MemIf_00043] 📄 PDF

MemIf_JobResultType MemIf_GetJobResult (uint8 DeviceIndex);

Invokes the "Get Job Result" function of the underlying memory abstraction module selected by the parameter Device Index. Available v ia Mem If.h

fonction MemIf_InvalidateBlock [SWS_MemIf_00044] 📄 PDF

Std_ReturnType MemIf_InvalidateBlock (uint8 DeviceIndex, uint16 BlockNumber);

Invokes the "Invalidate Block" function of the underlying memory abstraction module AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_MemoryAbstractionInterface selected by the parameter Device Index.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 65e4894eca9b Provenance
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction synchrone MemIf_InvalidateBlock transmet la demande d’invalidation d’un bloc logique au module d’abstraction de mémoire sous-jacent sélectionné via le paramètre DeviceIndex [SWS_MemIf_00044]. L’interface est fournie via l’en-tête MemIf.h et porte l’ID de service 0x07 [SWS_MemIf_00044].

Utilisation et paramètres

L’appel s’effectue de manière synchrone et transmet les paramètres d’entrée suivants à la cible d’adressage [SWS_MemIf_00044] :

  • DeviceIndex : index numérique du module d’abstraction de mémoire sous-jacent [SWS_MemIf_00044].
  • BlockNumber : identifiant univoque du bloc de mémoire à invalider [SWS_MemIf_00044].

Gestion des erreurs et valeurs de retour

La fonction renvoie une valeur d’état du type Std_ReturnType [SWS_MemIf_00044] :

  • si la détection des erreurs de développement (Development Error Detection) est activée pour le Memory Abstraction Interface et qu’une erreur selon SWS_MemIf_00022 survient, la fonction renvoie E_NOT_OK [SWS_MemIf_00044].
  • si aucune erreur de développement n’est constatée, l’interface renvoie le résultat de la fonction appelée du module sous-jacent [SWS_MemIf_00044].

concurrence

La fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_MemIf_00044].

Cette note d'utilisation a été générée automatiquement sur la base de la spécification AUTOSAR Classic Release R20-11.

fonction MemIf_EraseImmediateBlock [SWS_MemIf_00046] 📄 PDF

Std_ReturnType MemIf_EraseImmediateBlock (uint8 DeviceIndex, uint16 BlockNumber);

Invokes the "Erase Immediate Block" function of the underlying memory abstraction module selected by the parameter Device Index.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : e3fb9cffcdad Provenance Questions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Utilisation

La fonction synchrone MemIf_EraseImmediateBlock déclenche l’effacement d’un bloc classé comme immédiat dans le module d’abstraction de mémoire sous-jacent [SWS_MemIf_00046]. L’appel est fourni via l’en-tête MemIf.h et porte l’ID de service 0x09 [SWS_MemIf_00046]. Les paramètres d’entrée utilisés sont DeviceIndex pour l’adressage du périphérique de mémoire ou du module d’abstraction spécifique et BlockNumber pour l’identification du bloc cible [SWS_MemIf_00046]. Il n’existe pas d’autres paramètres Inout ou Out [SWS_MemIf_00046].

Valeurs de retour et gestion des erreurs

La fonction renvoie une valeur d’état de type Std_ReturnType [SWS_MemIf_00046]. Lorsque la détection des erreurs de développement est activée pour le Memory Abstraction Interface et qu’une erreur correspondante est constatée conformément à [SWS_MemIf_00022], l’appel fournit la valeur de retour fixe E_NOT_OK [SWS_MemIf_00046]. Si aucune erreur de ce type ne survient, le résultat immédiat de la fonction appelée du module sous-jacent est transmis à l’appelant [SWS_MemIf_00046].

Concurrence et restrictions

L’exécution de MemIf_EraseImmediateBlock s’effectue de manière synchrone et est spécifiée comme non réentrante (Non Reentrant) [SWS_MemIf_00046]. Interprétation : comme les appels parallèles de l’interface ne sont pas autorisés, la fonction ne devrait probablement être appelée dans l’ensemble du système que depuis un contexte synchronisé au niveau tâche, afin d’éviter des incohérences de données dans les pilotes de mémoire sous-jacents. Question Q-4fce518bab0115db (ouverte)

Cette note d'utilisation a été générée de manière automatisée sur la base de la spécification AUTOSAR CP R20-11.

type MemIf_StatusType [SWS_MemIf_00064] 📄 PDF

Denotes the current status of the underlying abstraction module and device drive. AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_MemoryAbstractionInterface

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : a0c9a4a73b28 Provenance
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Le type d’énumération MemIf_StatusType caractérise l’état actuel de fonctionnement et d’exécution du module d’abstraction de mémoire sous-jacent ainsi que du pilote de périphérique associé conformément à [SWS_MemIf_00064]. Ce type est défini dans le Memory Abstraction Interface et est disponible pour les appelants via le fichier d’en-tête MemIf.h [SWS_MemIf_00064].

L’énumération comprend quatre états distincts pour représenter l’état de préparation opérationnelle [SWS_MemIf_00064] :

  • MEMIF_UNINIT : le module d’abstraction sous-jacent ou le pilote de périphérique associé n’est pas (encore) initialisé [SWS_MemIf_00064].
  • MEMIF_IDLE : le module d’abstraction ou le pilote de périphérique est prêt à fonctionner et n’exécute actuellement aucune demande [SWS_MemIf_00064].
  • MEMIF_BUSY : le module sous-jacent ou le pilote de périphérique traite actuellement une opération [SWS_MemIf_00064].
  • MEMIF_BUSY_INTERNAL : le module d’abstraction traite des opérations de gestion internes, tandis que le pilote peut être inactif ou occupé [SWS_MemIf_00064].

Les couches appelantes utilisent cet état afin de déterminer de manière synchrone, avant l’attribution de requêtes, si les couches de mémoire sont opérationnelles ou si des opérations de gestion internes sont en cours [SWS_MemIf_00064]. Comme MemIf_StatusType représente une simple définition de type de données, les aspects fonctionnels tels que les messages DET ou DEM, les règles de réentrance ou les contextes d’appel ne sont pas mentionnés séparément dans l’élément de spécification.

Ce texte a été généré par une IA sur la base de la spécification AUTOSAR.

Guide de l'implémenteur à venir (complexité I1)

type MemIf_JobResultType [SWS_MemIf_00065] 📄 PDF

Denotes the result of the last job.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 975aee2541ba Provenance Questions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Le type d’énumération MemIf_JobResultType décrit le résultat de la dernière requête traitée auprès de l’interface de mémoire et est mis à disposition via le fichier d’en-tête MemIf.h [SWS_MemIf_00065].

L’énumération définit des états pour l’exécution ainsi que des états d’erreur et de bloc spécifiques [SWS_MemIf_00065] :

  • MEMIF_JOB_OK : la requête demandée s’est terminée avec succès [SWS_MemIf_00065].
  • MEMIF_JOB_PENDING : la requête n’est pas encore terminée [SWS_MemIf_00065]. Interprétation : cela indique que les requêtes sont traitées de manière asynchrone et que l’appelant détermine l’achèvement par le biais de cet état intermédiaire. Question Q-31078cf25506334e (ouverte)
  • MEMIF_JOB_FAILED : la requête ne s’est pas terminée avec succès [SWS_MemIf_00065].
  • MEMIF_JOB_CANCELED : la requête a été annulée [SWS_MemIf_00065].
  • MEMIF_BLOCK_INCONSISTENT : le bloc demandé est incohérent, contient éventuellement des données corrompues ou n’a pas été trouvé [SWS_MemIf_00065].
  • MEMIF_BLOCK_INVALID : le bloc demandé a été marqué comme non valide, de sorte que l’opération souhaitée ne peut pas être exécutée [SWS_MemIf_00065].

Lors de l’évaluation du résultat de la requête, le type sert à différencier les erreurs d’exécution générales (MEMIF_JOB_FAILED) des problèmes liés aux blocs (MEMIF_BLOCK_INCONSISTENT, MEMIF_BLOCK_INVALID) [SWS_MemIf_00065].

Ce texte a été généré par une IA et sert d'orientation.

type MemIf_ModeType [SWS_MemIf_00066] 📄 PDF

Denotes the operation mode of the underlying abstraction mod ules and device drivers.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 00926ceab163 Provenance
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Le type d’énumération MemIf_ModeType définit le mode de fonctionnement des modules d’abstraction de mémoire sous-jacents et des pilotes de périphérique [SWS_MemIf_00066]. Il est fourni via le fichier d’en-tête MemIf.h et sert à commander le comportement de vitesse et de fonctionnement des accès à la mémoire [SWS_MemIf_00066].

La plage de valeurs comprend deux états conformément à [SWS_MemIf_00066] :

  • MEMIF_MODE_SLOW : les modules d’abstraction et pilotes de périphérique sous-jacents fonctionnent en mode lent (Slow Mode) [SWS_MemIf_00066].
  • MEMIF_MODE_FAST : les modules d’abstraction et pilotes de périphérique sous-jacents fonctionnent en mode rapide (Fast Mode) [SWS_MemIf_00066].

Concernant le traitement des erreurs, la réentrance ou les contextes d’appel spécifiques, la spécification du type ne contient aucune stipulation particulière ; la transmission et l’évaluation du mode s’effectuent de manière synchrone via les interfaces correspondantes de l’interface de mémoire ou des pilotes sous-jacents [SWS_MemIf_00066].

Ce texte a été généré par une IA et sert à l'orientation technique.

Guide de l'implémenteur à venir (complexité I1)

Request a governed re-review of this record. The record is not changed immediately.

Record
AUTOSAR/AP/record/CP_MOD_MemIf
Status
unspecified
Version
AUTOSAR/AP/record/CP_MOD_MemIf@rel:R20-11#7e252a3c
Content hash
7e252a3c
Source
https://www.autosar.org/fileadmin/standards/R20-11/CP/AUTOSAR_SWS_MemoryAbstractionInterface.pdf#nameddest=SWS_MemIf_00038

Initialisation et état

Invokes the "Get Status" function of the underlying memory abstraction module selected by the parameter Device Index.

MemIf_StatusType MemIf_GetStatus (uint8 DeviceIndex);

Returns version information.

void MemIf_GetVersionInfo (Std_VersionInfoType* VersionInfoPtr);

Services

MemIf_Cancel fonction

Invokes the "Cancel" function of the underlying memory abstraction module selected by the parameter Device Index.

void MemIf_Cancel (uint8 DeviceIndex);

Invokes the "Erase Immediate Block" function of the underlying memory abstraction module selected by the parameter Device Index.

Std_ReturnType MemIf_EraseImmediateBlock (uint8 DeviceIndex, uint16 BlockNumber);

Invokes the "Get Job Result" function of the underlying memory abstraction module selected by the parameter Device Index. Available v ia Mem If.h

MemIf_JobResultType MemIf_GetJobResult (uint8 DeviceIndex);

Invokes the "Invalidate Block" function of the underlying memory abstraction module AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_MemoryAbstractionInterface selected by the parameter Device Index.

Std_ReturnType MemIf_InvalidateBlock (uint8 DeviceIndex, uint16 BlockNumber);
MemIf_Read fonction

Invokes the "Read" function of the underlying memory abstraction module selected by the parameter Device Index.

Std_ReturnType MemIf_Read (uint8 DeviceIndex, uint16 BlockNumber, uint16 BlockOffset, uint8* DataBufferPtr, uint16 Length);
MemIf_SetMode fonction

Invokes the "Set Mode" functions of all underlying memory abstraction modules.

void MemIf_SetMode (MemIf_ModeType Mode);
MemIf_Write fonction

Invokes the "Write" function of the underlying memory abstraction module selected by the parameter Device Index.

Std_ReturnType MemIf_Write (uint8 DeviceIndex, uint16 BlockNumber, const uint8* DataBufferPtr);

Types

Denotes the result of the last job.

Denotes the operation mode of the underlying abstraction mod ules and device drivers.

Denotes the current status of the underlying abstraction module and device drive. AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_MemoryAbstractionInterface