Ich nutze ein STM8A/128-EVAL-Board und das STM8_LIN-Package_5.1 Ich habe ein LDF File, welches ein Master und zwei fast identische Slave Knoten (slave_1 und slave_2) hat. Die Slaves unterscheiden sich eigentlich nur im den Frame Namen, die Funktion dahinter ist identisch. Mit dem Board kann ich einen Slave abbilden. D.h. ich kann für einen Slave Daten empfangen und senden. Das Ziel soll aber sein den Slave via LIN zu konfigurieren, damit er entweder als slave_1 oder slave_2 funktioniert und dementsprechend auf die Nachrichten reagiert. Genauer gesagt: slave_1 empfängt slave_1_state und slave_1_position. slave_2 empfängt slave_2_state and slave_2_position. Jetzt will ich aber nicht zwei verschiene Codes und diese dann separat auf ein Board flashen. Ich will ein Code, den ich auf das Board flashe und dann per LIN vom Master aus sage, dass es ein slave_1 ist oder ein slave_2 und auf welche frames er dementsprechend reagieren soll. Ich denke assign_NAD oder assign_frame_id_range aus dem LIN-Standard gehen in die Richtung, was ich möchte, verstehe aber die Umsetzung noch nicht so ganz. Hat hier jemand Erfahrung und kann mir weiterhelfen?
Ra B. schrieb: > Ich will ein Code, den ich auf das Board flashe und dann per LIN vom > Master aus sage, dass es ein slave_1 ist oder ein slave_2 und auf welche > frames er dementsprechend reagieren soll. Das ist nicht möglich, wenn das Netzwerk mit beiden Slaves gleichzeitig startet. Beide Slaves würden auf dieselbe NAD reagieren, woher soll welcher Slave wissen wer gemeint ist. a) einen EEPROM-Parameter einführen, der die Einstellung persistent speichert. Dann das Netz mit einem Slave in Betrieb nehmen. Wenn der Master in einer Netzwerkstartphase ... * einen Slave Nummer 0 findet, wird der als Nummer 1 umparametriert * eine 0 und eine 1 vorfindet wird die 0 zur 2 gemacht * eine 0 und eine 2 vorfindet, wird die 0 zur 1 gemacht * 1 und 2 vorfindet, wird nichts unternommen. 0 wird garnicht Adressiert. b) einen EEPROM-Parameter einführen, der die Einstellung persistent speichert. eine speziell getriggerte Variante des Umadressierens mit nur einem Slave 0, dem außerhalb des Netzes eine Nummer vorparametriert wird. Braucht für die Inbetriebnahme einen Spezialmaster (Bandendeprüfung) oder einen speziellen Betriebsmodus des Masters. c) Hardware-gesteuerte Enumeration, d.h. z.B. ein Jumper, der nur bei einem der beiden gesteckt wird. Oder mehrere Portpin binär kodiert. Oder ein ADC-Input an den Slaves mit Spannungsteiler dran, der dann 8 verschiedene NADs konfiguriert. Dein Problem ist übrigens ein sehr reales Problem. passend zu a) und b) Stelle dir mal einen linken und einen rechten Außenspiegel vor, die beide am selben LIN hängen sollen. Welcher ist der Linke und welcher der Rechte? Vorgehen, entweder beim Zulieferer der Spiegel an dessen Bandendeprüfung links und rechts zu kodieren(b), oder beim Autoverbau das Body-Steuergerät beim Anstecken der Spiegel laufen lassen, zuerst den linken anstecken(a), in der Werkstatt den abgefahrenen Spiegel einfach ersetzen. Kombination aus a+b natürlich auch möglich. passend zu c) Stelle dir einen digital auslesbaren Sensor mit nötiger Redundanz, z.B. Gaspedal vor. Zwei μCs mit am sich gleichen LIN-Responses, leicht verschiedene Messverfahren, aber auf derselben Platine. Da kann man die Binärkodierung direkt auf der Platine vornehmen. mfg mf
:
Bearbeitet durch User
Hallo mf,
vielen Dank für die ausführliche und nachvollziebare Antwort. Das hat
mir schon mal sehr geholfen.
Du schreibst:
> Beide Slaves würden auf dieselbe NAD reagieren...
Aber reagieren die Slaves nicht eigentlich auf die Frame-ID und nicht
auf die NAD?
Die NAD wird doch im Transport-Layer verwendet.
Aber für was genau wird in der Praxis der Transport-Layer bzw. die
Diagnostic Frames benutzt?
Das verstehe ich nicht so richtig.
Wann wird dann assign_NAD oder assign_frame_id_range verwendet?
Ra B. schrieb: > Aber reagieren die Slaves nicht eigentlich auf die Frame-ID und nicht > auf die NAD? Sie reagieren auf beides :P Die NAD brauchst du als Knoten-Name für die Doagnoseprotokolle, um z.B. die Frame-IDs/-ID-ranges zu (re)assignen bzw. umzusortieren oder NADs umzusortieren. Und noch anderes Gedöns. So ein Slave startet immer mit seiner Standardkonfiguration. Dein Problem besteht jetzt darin, ein Netzwerk mit zwei exakt identischen Slaves starten zu wollen. Du kannst die exakt identischen Slaves aber nicht einzeln adressieren, weder über ihre normalen Frames noch über Diagnostic-Frames mit der NAD. Implementier dir doch mal die Jumper-Lösung und experimentiere ein wenig. Ra B. schrieb: > Aber für was genau wird in der Praxis der Transport-Layer bzw. die > Diagnostic Frames benutzt? * LIN-Netzwerkdiagnose mit entsprechenden Services(ach was) * OBD würde zwar gehen, ist aber nicht für LIN vorgesehen * UDS-Diagnose mit entsprechenden Services * XCP-Protokoll ... Das sind alles Protokolle, wo man auch mal mehr als 8 Bytes in einer logischen Einheit verschicken muss. Zum Beispiel für Firmware-Updates oder Parameterdatensatz-Updates oder Datalogging-Downloads usw. mfg mf PS. Schau dir doch mal die Webinare von Vector an, die sind ein guter Startpunkt, im sich in der LIN2.2 spec zurechtzufinden.
:
Bearbeitet durch User
Hallo mf, danke für deine Antwort. Variante b. ist das, was für mich in Frage kommt. Werde das umsetzten. In welchem praktischen Zusammenhang wird die Funktion assign_frame_id_range genutzt? Hast du mir noch einen Link zu den Vector Webinaren zum Thema LIN? Ich kenne nur das E-Learning-Modul (https://elearning.vector.com/mod/page/view.php?id=199) mit freundlichem Gruß Ra B
Ra B. schrieb: > In welchem praktischen Zusammenhang wird die Funktion > assign_frame_id_range genutzt? Die Lin-Spec gibt doch schon mehrere nette Beispiele. Siehe Anhang. Ich könnte mir da z.B. vorstellen, ein Kleinst-Elektromobil mit 4 Akku-Steckplätzen. Die NAD wird über die Steck-Position kodiert. Der Master kann nun mehreren Frames eines Slaves freie frame-IDs zuweisen. Das ganze kann dann auch dynamisch sortiert werden. So liegen z.B. dann die VoltageCurrentPowerChargestate-Frames alle hintereinander, dann die Fehlerbit-Diagnosestatusframes usw. Und weil der Softwareentwickler es so toll fand, sortiert er die Frames beim Betrieb laufend nach gemeldetem Ladezustand der Batterien um. Warum? Weil er's kann ;) Ra B. schrieb: > Ich kenne nur das E-Learning-Modul Ja genau das Webinar/e-learning/selbstklickbarePowerpoint meinte ich. Danach kannste anfangen, die Spec zu lesen. Ist mehrfach redundant im Netz zu finden. mfg mf
Hallo mf, mal angenommen es besteht ein LIN Cluster aus angehängtem LDF. Es hat ein Master und zwei Slaves A_S1 und A_S2 (Akku_Steckplatz1 und 2) Über den statischen Funktionsprototyp l_u8_wr_A_S1_Voltage(l_u8 12) wird dem Signal A_S1_Voltage der Wert 12 übergeben.(siehe LIN Spezifikation 7.2.2.3 Scalar signal write) A_S1 verschickt A_S1_Stat_Frame und somit A_S1_Voltage, wenn es dessen fram_id (14) erkennt. Der Master schickt jetzt folgende Diagnose-Befehle: assign_frame_id_range(iii, 5, 0, {0x15 0xFF 0xFF 0xFF}) weist dem 0ten Frame von A_S1 (NAD 5) die ID 0x15 zu. assign_frame_id_range(iii, 6, 0, {0x14 0xFF 0xFF 0xFF}) weist dem 0ten Frame von A_S2 (NAD 6) die ID 0x14 zu. D.h. A_S1_Stat_Frm hat nicht mehr die ID 14, sondern 15 und A_S2_Stat_Frm hat nicht mehr die ID 15, sondern 14. Wenn jetzt vom Master der Header mit der ID 15 gesendet wird, antwortet A_S1 mit A_S1_Stat_Frm und nicht A_S2. Das LDF ist also an dieser Stelle nicht mehr gültig, denn dieses sagt, dass ID 15 zu A_S2_Stat_Frm gehört. Der Master muss sich merken, welchem Slave (welcher NAD) er welche frame_id zugewiesen hat. Stimmt das so? Wie würde das LDF aussehen, wenn es einen allgemeinen Slave Knoten geben würde, der dann am Bandende über assign_frame_id_range entsprechende frame_ids zugewiesen bekommt? Und wie würde dann der statische Funktionsprototyp aussehen? Das wäre dann so ähnlich wie in Variante b aus deinem Post vom 05.03.2021.
Ra B. schrieb: > Der Master muss sich merken, welchem Slave (welcher NAD) er welche > frame_id zugewiesen hat. > Stimmt das so? Ja, weil er die Frames sonst nicht mehr mit dem Header anfordern könnte und die RX-Knoten die enthaltenen Daten nicht interpretieren könnten. Die RX-Slaves dieses Frames und nicht nur der Master müssen das umsortieren berücksichtigen. Ra B. schrieb: > assign_frame_id_range entsprechende frame_ids zugewiesen bekommt? Das LDF enthält erstmal nur die Basiskonfiguration. Fürs Feld, wenn die Slaves permanent umgestellt sind, brauchst du dann ein neues LDF. Ra B. schrieb: > wie würde dann der statische Funktionsprototyp aussehen? Wos ist des? mfg mf
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.