Hallo. Ich verwende mehrere STM32F4 und kommuniziere über CAN. Unter Laborbedingungen ist die Kommunikation soweit stabil. Bin gerade dabei mir Gedanken zu machen wie ich den gesamten Aufbau/Firmware stabiler bekomme. Denke an die Auswertung der Fehlerbits etc. Was habe ich zu bedenken, damit der CAN auch in einer "gestörten" Umgebung stabil läuft? Gestört meine ich nicht nur im Sinne von elektrisch, sondern auch z.B. wie stelle ich sicher, dass keine Pakete verloren gehen, wenn z.B. der Bus längere Zeit geklemmt ist etc. Gibt's Tutorials? o.Ä. Was sollte man noch bedenken? Vielen Dank schon mal, Pepe.
Pepe schrieb: > Denke an die Auswertung der Fehlerbits etc. Was habe ich zu bedenken, > damit der CAN auch in einer "gestörten" Umgebung stabil läuft? Gestört Nichts, der CAN macht das schon für dich. > meine ich nicht nur im Sinne von elektrisch, sondern auch z.B. wie > stelle ich sicher, dass keine Pakete verloren gehen, wenn z.B. der Bus > längere Zeit geklemmt ist etc. Jedes Paket wird numeriert, genauso die Antwort auf dieses Paket. Alle 500ms wird ein Paket "AN ALLE" geschickt, somit wissen die Slaven, dass der Bus frei und Master bereit ist. Der Master kann von Zeit zu Zeit auch ein 'LEERES' Kommando an jeden einzelnen Slaven schicken und eine 'LEERE' Antwort erhalten, das ist schon mehr als genug. > Gibt's Tutorials? o.Ä. Was sollte man noch bedenken? Nur die Adressen. Je wichtiger, desto niedriger die Adresse.
Pepe schrieb: > wie stelle ich sicher, dass keine Pakete verloren gehen, wenn z.B. der Bus > längere Zeit geklemmt ist etc. Müssen denn überhaupt alle Pakete ankommen (Flashen mal ausgenommen)? Im automotive-Bereich werden Nachrichten sowieso alle 10-20ms wiederholt, langsame Messwerte bis zu 1s. Wenn mal eine Nachricht nicht nach 10ms da ist, sondern evtl. erst nach 30ms muss das Steuergerät damit zurecht kommen. Ist die Reihenfolge der Borschaften relevant oder man will wissen ob die Applikation auf dem sendenden Steuergerät wirklich aktiv ist und nicht nur immer die gleiche Botschaft rausgeschickt wird, dann baut man einen Botschaftszähler (alive-counter) ein: Ein Byte wird einfach in der Botschaft hochgezählt und beginnt wieder bei 0. Ansonsten ist es sowieso "Pflicht" immer die TX- und RX-Error-Counter auszulesen.
Thomas F. schrieb: > Müssen denn überhaupt alle Pakete ankommen (Flashen mal ausgenommen)? > Im automotive-Bereich werden Nachrichten sowieso alle 10-20ms > wiederholt, langsame Messwerte bis zu 1s. Wenn mal eine Nachricht nicht > nach 10ms da ist, sondern evtl. erst nach 30ms muss das Steuergerät > damit zurecht kommen. OT Ahh, dann verstehe ich jetzt so manche Fehlfunktion meines Fahrzeugs :( Nach automatischem Motorstart und zu schnellem Kupplung-Drücken fängt der wie wild an/abzuschalten dass man fürchtet der Motor würde aus der Halterung springen. Die einzige Möglichkeit den Zustand zu beenden ist dann der Griff auf die AN/AUS Taste und manuell abstellen. /OT
6a66 schrieb: > OT > Ahh, dann verstehe ich jetzt so manche Fehlfunktion meines Fahrzeugs :( > Nach automatischem Motorstart und zu schnellem Kupplung-Drücken fängt > der wie wild an/abzuschalten dass man fürchtet der Motor würde aus der > Halterung springen. Die einzige Möglichkeit den Zustand zu beenden ist > dann der Griff auf die AN/AUS Taste und manuell abstellen. > /OT OT Da muss ich dir leider Recht geben. Gerade im automotive Bereich sollte man eigentlich davon ausgehen können, dass da Könner am Werk sind. Mein C4 hat da auch so ein paar Software-Bugs, wo man sich echt fragt, ob die ausser Ein/Ausschalten jemals mehr getestet haben. Zum Glück nichts im unbedingt notwendigen Bereich. Mit diesem Hintergrund fragt man sich echt, ob es nicht sinnvoller wäre, die Jungs ordentlich auszubilden anstatt auf Misra zu pochen. /OT
Thomas F. schrieb: > Ansonsten ist es sowieso "Pflicht" immer die TX- und RX-Error-Counter > auszulesen. Und wie reagiere ich dann darauf? Beim STM32 hast Du für den TEC ja die Möglichkeit eine autom. Wiederaufnahme der Kommunikation zu aktivieren. Aber wie reagiere ich auf die RX Fehler? Da hab ich ja eigentlich nur die Möglichkeit zu warten, bis der Counter wieder niedriger ist oder ? Thomas F. schrieb: > Wenn mal eine Nachricht nicht > nach 10ms da ist, sondern evtl. erst nach 30ms muss das Steuergerät > damit zurecht kommen. Bei zyklischen Abfragen geht das. Da hab ich nur leider relativ wenig Werte. Die meisten Messages starten irgendeinen weiteren Job auf einem anderem Controller. Und da hab ich immer nur ein Ereignis, was ausgelöst werden soll.
Karl H. schrieb: > Mit diesem Hintergrund fragt man sich > echt, ob es nicht sinnvoller wäre, die Jungs ordentlich auszubilden > anstatt auf Misra zu pochen. OT Pssst, möchte nicht wissen wieviele von den Jungs hier mitlesen /OT
Pepe schrieb: > Und wie reagiere ich dann darauf? Beim STM32 hast Du für den TEC ja die > Möglichkeit eine autom. Wiederaufnahme der Kommunikation zu aktivieren. > Aber wie reagiere ich auf die RX Fehler? Da hab ich ja eigentlich nur > die Möglichkeit zu warten, bis der Counter wieder niedriger ist oder ? Eines der schwierigen Kapitel in der Software-Branche: Wie reagiert man auf Fehler. Wenn du haufenweise Rx Fehler hast (was 'haufenweise' bedeutet, definierst du), dann wirst wahrscheinlich nicht umhin kommen, deinen Benutzer mal darauf aufmerksam zu machen, dass es da ein Problem gibt. Viele Möglichkeiten hast du meistens sowieso nicht. Subsysteme abschalten und Benutzer informieren sind die häufigsten. Bei CAN kommt dann auch noch ein Bus-Reset dazu. Aber auch hier: Musst du den Bus zu häufig resetten, dann ist das etwas, von dem ein Benutzer bzw. Techniker Kentniss erhalten sollte.
Karl H. schrieb: > Mit diesem Hintergrund fragt man sich > echt, ob es nicht sinnvoller wäre, die Jungs ordentlich auszubilden > anstatt auf Misra zu pochen. MISRA soll doch nur Anfängerfehler verringern, gegen logische Fehler oder Ablauffehler ist es völlig nutzlos. Da hilft nur ein ordentlicher Programmablaufplan, bevor man überhaupt anfängt Code einzuhacken.
Peter D. schrieb: > Karl H. schrieb: >> Mit diesem Hintergrund fragt man sich >> echt, ob es nicht sinnvoller wäre, die Jungs ordentlich auszubilden >> anstatt auf Misra zu pochen. > > MISRA soll doch nur Anfängerfehler verringern Da keimt in mir sofort die Frage auf: Was haben Leute die Anfängerfehler en mass machen, in der automotive Branche im Produktionscode verloren? Du siehst schon: ich kann mich mit Misra nicht anfreunden. Das liegt zum Teil auch daran, dass es in Misra Code dann auch schon mal zu seltsamen Kopfständen kommt, nur damit man Misra konform bleibt, obwohl es "konventionell" viel simpler wäre.
Karl H. schrieb: > Viele Möglichkeiten hast du meistens sowieso nicht. D.h. doch eigentlich, dass ich den REC regelmäßig abfrage, ob er eine Schwelle überschritten hat, und dann den Benutzer informiere.
Marc V. schrieb: > Alle 500ms wird ein Paket "AN ALLE" geschickt, somit wissen die Slaven, > dass der Bus frei und Master bereit ist. Und diese Nachricht sollte die niedrigste Priorität in deinem System haben. Thomas F. schrieb: > Pepe schrieb: >> wie stelle ich sicher, dass keine Pakete verloren gehen, wenn z.B. der Bus >> längere Zeit geklemmt ist etc. > > Müssen denn überhaupt alle Pakete ankommen (Flashen mal ausgenommen)? Das ist ja der Vorteil von CAN, dass auch der Sender merkt, ob und wann seine Nachricht korrekt versendet wurde. Einen Bus, an dem Error Passive oder Busoff Knoten hängen ist fehlerhaft. Hier sollte das Fehlerhandling greifen. > Im automotive-Bereich werden Nachrichten sowieso alle 10-20ms > wiederholt, langsame Messwerte bis zu 1s. Das macht man gern im sicherheitskritischen Bereich. Verringert dadurch aber auch den möglichen Traffic. > Wenn mal eine Nachricht nicht > nach 10ms da ist, sondern evtl. erst nach 30ms muss das Steuergerät > damit zurecht kommen. Oftmals erkennt man daran eine fehlerhafte Situation. Inwiefern man in der jeweiligen Situation fehlertolerant sein darf oder nicht, kommt auf die Applikation an. > Ist die Reihenfolge der Borschaften relevant oder man will wissen ob die > Applikation auf dem sendenden Steuergerät wirklich aktiv ist und nicht > nur immer die gleiche Botschaft rausgeschickt wird, dann baut man einen > Botschaftszähler (alive-counter) ein: Ein Byte wird einfach in der > Botschaft hochgezählt und beginnt wieder bei 0. In vielen Fällen reicht auch schon ein Togglebit. Speziell wenn man sicherstellen will, dass die Nachricht durch die Applikation verschickt wird und nicht einfach vom CAN Controller mehrfach verschickt wird. > Ansonsten ist es sowieso "Pflicht" immer die TX- und RX-Error-Counter > auszulesen. Naja, unseren Kunden reicht die Information über die Zustände Error Active /Passive/Busoff. Manchmal ist es schwierig zu vermitteln, den Error Passive Zustand als Fehlerzustand anzusehen, da die Kommunikation ja prinzipiell noch geht. (Industrie/Automatisierung)
Pepe schrieb: > Karl H. schrieb: >> Viele Möglichkeiten hast du meistens sowieso nicht. > > D.h. doch eigentlich, dass ich den REC regelmäßig abfrage, ob er eine > Schwelle überschritten hat, und dann den Benutzer informiere. Naja, die wenigsten CAN Geräte bekommst du zu Gesicht. Man kann noch versuchen zeitig eine Fehlernachricht an die Steuerung/Display zu schicken. Dies hat gute Chancen, wenn sich der Fehler langsam aufbaut und die Kommunikation noch nicht zusammengebrochen ist. Man sollte bloß vermeiden den Traffic durch die Fehlernachrichten weiter zu erhöhen, da die Durchlässigkeit durch die vielen Sendewiederholungen niedriger ist.
Kann ich davon ausgehen, dass der Master/Steuerung einen RX-Fehler bekommt, wenn bei den Slaves TX-Fehler auftreten?
Nicht, wenn bereits der Anfang der Nachricht vom Sender nicht auf dominant gezogen werden konnte. Wenn du dann den REC Counter nur pollst, kann dieser auch durch korrekte Nachrichten eines anderen Senders wieder auf 0 gesetzt sein. Ich würde nicht zu solch spitzfindigen Überlegungen raten. Wobei sie einem Experten schon bei der Fehlersuche helfen.
Pepe schrieb: > Kann ich davon ausgehen, dass der Master/Steuerung einen RX-Fehler > bekommt, wenn bei den Slaves TX-Fehler auftreten? Bei CAN gibt es keine Master und Slaves. Nur die Botschaften unterscheiden sich in ihrer "Wichtigkeit". Welches Steuergerät die Botschaft sendet ist dem Bus egal. Jeder CAN-Controller stellt nur Fehler an seinem Busknoten fest. Ob CAN-Controller anderer Steuergeräte Fehler feststellen wird untereinander erst mal nicht weitergegeben.
Thomas F. schrieb: > Bei CAN gibt es keine Master und Slaves Richtig. Aber ich hab eine Steuerung, die mir die Verbindung zur restlichen Welt per Ethernet herstellt. Die eigentlichen Controller hängen dann nur über den CAN an diesem "Master" dran. Aus meiner Sicht ist dies der "Master". CAN sieht das etwas anders ;-)
Pepe schrieb: > Die eigentlichen Controller > hängen dann nur über den CAN an diesem "Master" dran. Okay, ist dann halt kein "Bare-CAN-Protokol" mehr. Da läuft dann bei dir wohl noch ein höheres Protokoll. Aber da bin ich dann raus da ich nur Nachrichten verschicke.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.