Hallo, ich debugge bei uns in der Abteilung CAN Bus Dinge. Dazu haben wir natürlich einen der üblichen CAN Sniffer. Für manche Sachen ist der aber nicht flexibel genug. 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? Nach einer Adresse fahnden sollte gehen, aber könnte man z.B. auch einen Error Frame sehen können? 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: https://www.olimex.com/Products/AVR/Development/AVR-CAN/ ARM ist sicher neuer, aber ich müsste mich erst einarbeiten. Gibt es für die STM32 sowas wie das AVR-Tutorial hier? https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/open-source-hardware Vielen Dank.
Nimm dafür Vector CANoe bzw CANalyzer samt CAN-Interface. Mach da keine Bastellösung draus.
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.
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: > https://www.olimex.com/Products/AVR/Development/AVR-CAN/ Für die gebotene Leistung sind die AVRs einfach zu teuer, da bekommst Du für das gleiche Geld besseres. Wenn Du aber schon die Tools (insbesondere ein Atmel-ICE zum Debuggen) hast, damit umgehen kannst und es Dir darauf ankommt, möglichst schnell zum Ziel zu kommen, dann mach das so. Ansonsten nimm das: http://www.ti.com/tool/EK-TM4C123GXL Kostet bei mouser.de 13.38€. Da ist gleich Debuggerhardware mit drauf, d.h. Du musst nur noch einen Transceiver Deiner Wahl (z.B. MCP2562 oder TJA1042T/3 mit 3.3V VIO-Pin) anschließen. TI liefert alles erforderliche gleich mit: Code Composer, TI ARM Compiler, TIVAware Treiberbibliotheken, TI-RTOS. Passt alles zusammen, funktioniert. Mit Registern brauchst Du Dich nicht unbedingt zu befassen, die Treiberbibliothek macht alles für Dich. fchk
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.
Mit der Option.Scope kann man in CANoe/CANalayzer auch die elektrischen CAN-Signale aufzeichnen (mittels USB-Scope, ich glaub das ist ein Pico-Scope). Da kannst du dann sicher auch mit CAPL festlegen, dass die Aufzeichnung z.b. mit einem Errorframe beginnen soll. Ich weiß, selbst CANalzyer ist noch teuer, aber wer einmal mit CAN zu tun hat, hat in der Regel oft mit CAN zu tun und da lohnt es sich einfach. Die Zeit, die es dich kostet dich um eine individuelle Lösung zu kümmern, kostet mehr Arbeitskosten als dich eine Lizenz von CANalyzer mit Scope Option je kosten könnte.
Nimm einen Salea Logic-Analysor. Der kann CAN-Protokoll. Du siehst sowohl das Timing als auch die Daten des CAN-Frames. Gruß Werner
Werner R. schrieb: > Nimm einen Salea Logic-Analysor. Der kann CAN-Protokoll. > Du siehst sowohl das Timing als auch die Daten des CAN-Frames. Der kann aber nur mithören, aber nix senden. Entspricht daher nicht dem, was der Fragesteller braucht. fchk
>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.
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.