Start in CAN Bus mit uC

Timo N. schrieb:
> Nimm dafür Vector CANoe bzw CANalyzer

Ohne Frage der Königsweg. Aber nicht jede Firma will/kann sich Vector 
leisten, das ist inkl. Wartung schon echt ein dicker Brocken. Ich weiß, 
das in einigen Branchen das völlig egal ist.

Wobei Oszilloskopieren der Bus-Signale auch bei Vector eine Besonderheit 
ist.
Die normalen VN-sonstwas schaffen das nicht. Ich kann mich erinnern, 
einen Fototransistor auf die Buserror Led vom Cancase gepappt zu haben, 
um ein Oszi zu triggern.
Für die Firma muss man sich halt vorher überlegen, was demnächst so 
ansteht.
Can-FD wäre sowas, was nicht jede Hardware beherrscht.
Einsätze beim Kunden mit einer gehäuselosen, italienischen Bastellösung 
sind unter Umständen auch nicht das, was der oberste Chef unter 
Corporate Identity versteht.
Unter spätestens wenn der Kunde was zu meckern hat und eine Datei mit 
der Endung .blf beilegt, ist klar, was er erwartet womit gearbeitet 
wird.

Aber zum Thema mehr fürs Geld : wenn klar ist, dass nie mehr benötigt 
wird, die Bälle ruhig mal flach halten. Es muss einfach funktionieren. 
Ich will damit Fehler suchen und mir nicht noch eine Fehlerquelle an 
Land ziehen.
Also selbst wenn die 125er genauso teuer ist wie ein Mofa. Nicht laut 
will haben rufen, sondern dran denken, dass für das eine noch der Erwerb 
eines Führerscheins ansteht...

> Ich kann mich erinnern,
> einen Fototransistor auf die Buserror Led vom Cancase gepappt zu haben,
> um ein Oszi zu triggern.
> Für die Firma muss man sich halt vorher überlegen, was demnächst so
> ansteht.

Im Prinzip genau das erste konkrete Problem dass es hier zu lösen gibt: 
Ab und zu steigt alles aus was am CAN Bus hängt. Alles was der 
CAN-Analyzer zeigt sind ein paar Tauseend "Error" Frames. Nach dem 
Gewitter hat sich eine zugekaufte Komponente vom Bus verabschiedet - ist 
auch verständlich, die Norm sagt ja ab wann sich ein Node passiv 
schalten muss wenn alle seine Pakete von den anderen Nodes als "Error" 
quittiert werden.
Das erste was ich machen werde ist mir das Oszi-Bild rund um den 
Zeitpunkt anzusehen wenn ich es geschafft habe auf Error-Frames zu 
triggern.
Als zweites schaue ich mich um was es für Debugging-Möglichkeiten gäbe 
die über den CAN-Sniffer hinaus gehen. Vor allem wenn ich aktiv und ich 
Echtzeit was am Bus ändern will um zu sehen ob es den Fehler triggert 
oder beseitigt.
Z.B. sendet eine der Komponenten eine Sturmflut an Paketen (Pause zw. 
den Paketen kleiner als die Paketlänge) wenn nicht eine zweite 
Komponente die Pakete mit ACK bestätigt. Wer weiß ob nicht das den 
Fehler triggert. Ich würde mir dann auf dem uC was programmieren was von 
den Paketen dann nur 10 pro Sekunde durch lässt. Oder einfach andere 
Eingriffsmöglichkeiten um bei Modulen mit Black-Box-Software zu sehen 
wer wie auf welche Situation am Bus reagiert.

Timo N. schrieb:
> Nimm dafür Vector CANoe bzw CANalyzer

So ein Budget bekomme ich vielleicht nachdem ich die ersten Probleme 
gelöst habe und sich meine Abteilung als CAN-Problemlöser etabliert hat.

Ansonsten wäre das für mich die ideale Ausrede mich mal in ARM 
einzuarbeiten... mir ist lieber ich kenne mich nachher mit ARM-uC aus 
als dass ich ich in ein super-spezial-CAN-Tool eingearbeitet bin und 
damit Wissen habe das ich sonst nirgendwo anwenden kann.

>Ich will so was können wie einen Trigger für ein Oszi auslösen
kann  ein STM32 schnell genug sein, muss aber nicht.

relaiv Preiswert mit FDCAN:
https://www.st.com/en/evaluation-tools/stm32h7b3i-dk.html?ecmp=tt14171_gl_enews_feb2020&cid=stmDM25664&bid=275955371&uid=B2HGDGxzzqEKxfvE5w32yagHhrOBby0E#overview

musst "nur" noch die Software schreiben, aber das  Einarbeiten war ja eh 
das Ziel.

Gruß,

dasrotemopped.

>> Nimm dafür Vector CANoe bzw CANalyzer
>
>Ohne Frage der Königsweg. Aber nicht jede Firma will/kann sich Vector
>leisten, das ist inkl. Wartung schon echt ein dicker Brocken. Ich weiß,
>das in einigen Branchen das völlig egal ist.

Peak-System gibt es auch noch https://www.peak-system.com/

asd schrieb:
> Ich will so was können wie einen Trigger für ein
> Oszi auslösen wenn ein Ereignis auftritt wie ein bestimmte Node-Adresse
> tritt auf, oder ein Error-Frame. Oder 99% Buslast erzeugen um zu sehen
> ob man dann Bugs provoziert, und andere Grenzfälle erzeugen um sie zu
> testen. Sind für sowas CAN Tranceiver von Mikrocontrollern geeignet?

Erstmal meinst Du einen CAN-Controller, ein Transceiver macht "nur" die 
letzte Schicht und ist bis auf ein paar Ausnahmen für Partial Networking 
erstmal quasi ohne Logik.

Und nein, ein CAN-Controller eines Mikrocontrollers ist eher ungeeignet 
um Tests vom Bus zu machen.
Der ist nämlich komplett für sich gekapselt und erlaubt per Software nur 
sehr begrenzten Zugriff.
Es wäre zum Beispiel nicht möglich damit eine fehlerhafte CRC zu senden 
um Error-Frames zu provozieren.
Und bei fehlerhaften Frames auf dem Bus bekommt man eher nicht mit, was 
nun genau das Problem ist, die Botschaft wird einfach nicht akzeptiert.

Sowas wäre eine Aufgabe für ein FPGA.

asd schrieb:
> Bisher habe ich mit AVR Megas rum gespielt, deswegen frage ich mich ob
> der AT90CAN128 noch aktuell ist oder eher zu den Opas gehört:

Ur-Opa, aktuell wäre einer der CAN-FD unterstützt und da gibt es keinen 
AVR.

Aber, klar, mit Classic CAN bei Erhalt einer Botschaft einen Pin wackeln 
zu lassen, das geht noch.
Und Buslast kann man damit auch erzeugen.

Der Pin wackelt eben nur erst wenn die Botschaft vollständig empfangen, 
vom CAN-Controller für gut befunden und von der Software verarbeitet 
wurde.