LIN-Bus-Technologie wird optimiert
Die neue LIN-Spezifikation 2.1 – Teil 2
Fortsetzung des Artikels von Teil 2
Application Program Interface (API)
Die Änderungen des Application Program Interface (API) haben sich im Wesentlichen aus den vorher beschriebenen Änderungen und aus den bisherigen Erfahrungen mit der API ergeben. Die Beschreibungen der Funktionen sind meist konkretisiert worden. Es wurde jetzt auch eindeutig definiert, ob die Funktionen nur für den Master, den Slave oder beide gelten. Außerdem wurde für die meisten Funktionen eine Referenz in die anderen Teile der Spezifikation eingefügt, um die Wirkung eines Funktionsaufrufs nachvollziehen zu können. Das API besteht nach wie vor aus den drei Teilen: Core-API, „LIN Node Configuration and Identification API“ und „LIN Transport Layer API“. Nachfolgend werden die Änderungen dargestellt.
In dem Core-API wurden die Interface-Funktionen l_ifc_conncet() und l_ifc_disconnect() entfernt. Die Funktion l_ifc_read_status() erhielt drei neue Flags:
- Save Configuration: Dieses Flag wird im Slave gesetzt, wenn er den neu eingeführten Service „Save Configuration Request“ empfängt.
- Event Triggered Frame Collision: Dieses Flag wird im Master gesetzt, wenn er eine Kollision erkannt hat und auf die „Collision Resolving Schedule“-Tabelle umschaltet; es bleibt so lange gesetzt, bis es wieder zurück zur normalen Tabelle geht.
- Bus Activity: Das Flag wird gesetzt, wenn der Knoten eine Bus-Aktivität feststellt. Damit kann die Applikation feststellen, wann die 4 bis 10 s der Busruhe verstrichen sind und der Knoten in den „Sleep Mode“ wechseln muss.
Für die Knotenkonfiguration wurden vier neue Funktionen definiert; außerdem gab es bei zwei Funktionen Änderungen. Die Funktion ld_is_ready() hat vier Rückgabewerte bekommen, mit denen die Masterapplikation feststellen kann, in welchem Zustand sich der aktuelle Master-Request und der dazugehörige Slave-Response befindet:
- LD_SERVICE_BUSY zeigt an, dass der Master Request Frame (MRF) übertragen wird;
- LD_REQUEST_FINISHED zeigt an, dass die Übertragung des MRF abgeschlossen ist und nun die Abfrage des Slave-Response läuft;
- LD_SERVICE_IDLE zeigt an, dass der Slave-Response abgeschlossen ist und der Master die Antwort auswerten kann;
- LD_SERVICE_ERROR zeigt an, dass ein Kommunikationsfehler aufgetreten ist.
Bei der Funktion ld_check_response() erfolgt die Rückgabe jetzt nur noch über die Parameter RSID und error_code. Es wurden folgende Funktionen hinzugefügt:
- ld_save_configuration(): Mit dieser Funktion startet der Master den Service „Save Configuration Request“.
- ld_read_configuration(): Mit dieser Funktion liest der Slave seine Konfiguration aus dem LIN-Stack aus. Das sind die NAD und alle PIDs seiner Frames.
- ld_set_configuration(): Diese Funktion setzt die NAD und alle PIDs des Slave.
- ld_read_by_id_callout(): Diese Funktion wird aufgerufen, wenn der Slave den Service „Read by Identifier“ mit den nutzerdefinierbaren IDs (32 – 64) empfängt.
In der Transport Layer API enthalten die Statusfunktionen nun mehr Rückgabewerte. Im Einzelnen gilt das für die Funktionen:
- ld_raw_rx_status(): LD_NO_DATA zeigt an, dass der Empfangspuffer leer ist.
- ld_raw_tx_status(): LD_QUEUE_AVIABLE zeigt an, dass der Sendepuffer Daten enthält, aber noch nicht voll ist.
- ld_tx_status(): LD_N_AS_TIMEOUT zeigt an, dass ein N_AS-Timeout aufgetreten ist.
- ld_rx_status():
LD_N_CR_TIMEOUT zeigt an, dass ein N_Cs-Timeout aufgetreten ist.
LD_WRONG_SN zeigt an, dass eine unerwartete Sequenznummer empfangen wurde.
Jobangebote+ passend zum Thema
- Die neue LIN-Spezifikation 2.1 – Teil 2
- „Node Capability Language Specification“
- Application Program Interface (API)
- Implementierung im Slave
- Transport-Protokoll-Implementierung
