CAN: Wie sollte man am besten die Firmware aufbauen?

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.

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

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.

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.

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.

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.