Figure 7.3: Little Endian (LOW_BYTE_FIRST) byte ordering

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Speichermodell- / Endianness-Mapping-Diagramm (Hardware-zu-Logik-Abbildungsdiagramm).
• Technischer Zweck: Definition der byteweisen Serialisierung und Speicherabbildung eines skalaren 16-Bit-Ganzzahldatenworts im Speicher für Little-Endian-Zielarchitekturen gemäß AUTOSAR-Konvention LOW_BYTE_FIRST.
• Funktionale Einordnung: Verortung in Platform_Types (AUTOSAR_SWS_PlatformTypes) als hardwareabstrahierende Spezifikationsgrundlage für den Basic Software (BSW) Stack, Compiler-Abstraktion und Treiberentwicklung (MCAL) im AUTOSAR Classic Core.

2. Komponenten, Entitäten & Schnittstellen

• Domänen-Einteilung (Trennlinie gestrichelt):
  • Information (Logische Ebene):
    • 16-Bit Datenelement (16 bit width, z. B. uint16, sint16).
    • LS Byte (Byte0): Least Significant Byte (Bits 0–7 des logischen Werts).
    • MS Byte (Byte1): Most Significant Byte (Bits 8–15 des logischen Werts).
  • Hardware (Physikalische Ebene):
    • Byte-adressierbarer Speicher (Memory).
    • Basisadresse Address n: Niederwertigste Speicheradresse des Datenworts.
    • Folgeadresse Address n+1: Nächsthöhere Speicheradresse.
• Relationen & Adress-Mapping:
  • Value[7:0] → Address n
  • Value[15:8] → Address n+1
  • Der niederwertigste Byte-Anteil (LS Byte) belegt stets die niedrigere Speicheradresse (LOW_BYTE_FIRST).

3. Dynamisches Verhalten & Sequenzablauf

• Nicht zutreffend (Statisches Struktur- und Repräsentationsmodell): Kein Protokollablauf, Zustandsautomat oder asynchroner Kommunikationspfad.
• Zugriffssemantik im RAM/Register:
  • Byte-Zugriff auf Address n liefert direkt das Least Significant Byte (Byte0).
  • Wort-Lese- bzw. Schreibzugriffe des Prozessorkerns interpretieren die Byte-Sequenz [Address n, Address n+1] ohne Software-Swapping direkt als nativen Wert (Byte1 << 8) | Byte0.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Referenz:
  • [SWS_Platform_00051]: Spezifikation des Präprozessor-Makros CPU_BYTE_ORDER in Platform_Types.h. Für Plattformen gemäß dieser Abbildung zwingend zu definieren als:

    #define CPU_BYTE_ORDER LOW_BYTE_FIRST

• Auswirkungen auf BSW- und MCAL-Entwickler:
  • Com-Stack & PDU-Serialisierung (PduR / Com / CanTp): Signal-Extraktion aus Kommunikations-PDUs muss das Verhältnis zwischen CPU_BYTE_ORDER und der konfigurierten Signal-Endianness (z. B. COM_BUS_LITTLE_ENDIAN vs. COM_BUS_BIG_ENDIAN) abgleichen. Bei LOW_BYTE_FIRST-Hosts ist für Little-Endian-Signale kein Byte-Swapping erforderlich.
  • Treiber- & Speicherzugriffe (DMA / Fls / Fee / NvM): Blocktransfers über byteweise arbeitende Peripherie/Hardware (DMA-Kanäle, Flash-Treiber) behalten die Speicherreihenfolge n → Byte0, n+1 → Byte1 bei.
  • Portabilität: Vermeidung von plattformabhängigen Union-Overlays oder unaligned Byte-Pointer-Casts auf Multi-Byte-Typen in portablem SWC- und BSW-Code, da dies bei Wechsel auf Architekturen mit HIGH_BYTE_FIRST (CPU_BYTE_ORDER == 1) zu Fehlinterpretationen führt.