|
Anzeige
|
CAN Hardwarefilter
Gast
#3361114
Guten Abend, für eine Anwendung wird ein Mikrocontroller mit CAN verwendet. Um den Mikrcontroller neu zu flashen wurde eine Windows Anwendung entwickelt. Der Datenaustausch erfolgt mit CAN. Ohne Buslast gibt es keine Probleme mit dem Flashvorgang. Mit Buslast wird der Flashvorgang verlangsamt bzw. sogar still gelegt. Als Maßnahme wurde der CAN Hardwarefilter eingesetzt. Auch hier gibt es die gleichen Probleme. Was könnte noch unternommen werden? CanUser schrieb: > Mit Buslast wird der Flashvorgang > verlangsamt bzw. sogar still gelegt. Als Maßnahme wurde der CAN > Hardwarefilter eingesetzt. Auch hier gibt es die gleichen Probleme. Was > könnte noch unternommen werden? Gib dem Datenaustausch zum Flashen durchweg höherpriore Message-IDs. Auch bei CANopen kann man dies noch beeinflussen.
Gast
#3361166
Was könnte ich noch tun, ohne die IDs verändern zu müssen?
Gast
#3361174
>Was könnte ich noch tun, ohne die IDs verändern zu müssen?
Die Buslast auf Null schrauben.
Gast
#3361177
CanUser schrieb: > Was könnte ich noch tun, ohne die IDs verändern zu müssen? Naja, Du hast die Lösung eh am Tisch: den Knoten die da ständig dazwischenreden (und damit die Datenmenge empfindlich reduzieren) einen virtuellen Maulkorb verpassen, zB. in einen Reset schicken, ausschalten oder was auch immer Dir da hilft, die Datenmengen zu reduzieren... Grüße MiWi
Gast
#3361200
>Mit Buslast wird der Flashvorgang >verlangsamt bzw. sogar still gelegt. Als Maßnahme wurde der CAN >Hardwarefilter eingesetzt. Der Filter hilft gar nichts wenn der Bus ausgereizt ist. Wenn keine Bandbreite zum übertragen der zu flashenden Daten mehr vorhanden ist, ist einfach Schluss. Auf einer Autobahn fahren die Autos schliesslich auch nicht übereinander wenn es einen Stau gibt. Beim CAN ist es genauso. Wenn die Strasse voll ist ist sie voll. Man kann aber noch auf dem Standstreifen fahren. Wenn die Message eine höhere Priorität hat wie z.B. ein Polizeiauto oder Krankenwagen dürfen sie auf dem Standstreifen an allen vorbeirauschen. Da Du als Gegenmaßnahme die Hardwarefilter genutzt hast, gehen alle davon aus, dass die problematische Buslast durch Fremdtraffic erzeugt wird. Ist dem so? Wirken die Filter? Kann es sein, dass eher dein Windowsprogramm durch den Traffic gestört wird und langsamer sendet (warum auch immer)? Die vorab gemachten Annahmen, dass dein Traffic durch höherpriore Nachrichten gebremst wird kann man leicht im Analyser prüfen.
Gast
#3370318
Den Can-Hardwarefilter habe ich nur auf dem Mikrocontroller im Einsatz. Mit dem Peak-Can-Dongle übertrage ich die Daten an dem Mikrocontroller. Um eine hohe Buslast zu simulieren, sende ich mit dem Peak-Can-Dongle drei Can Nachrichten alle 10 ms. Da bricht die Kommunikation nach einer gewissen Zeit ab.
Gast
#3370332
>>Die vorab gemachten Annahmen, dass dein Traffic durch höherpriore >>Nachrichten gebremst wird kann man leicht im Analyser prüfen. Von Peak habe ich nur den PCAN-View Software. Wo kann man dies mit dem Viewer feststellen?
Gast
#3370474
Um beim Flashen möglichst weinig Traffic auf dem Bus zu haben, habe ich das bei mir folgendermaßen gelöst: Ein Befehl vor Flashbeginn sorgt dafür, dass alle Knoten ein spezielles Flag setzen und danach nur noch wichtige Nachrichten, wie z.B. Alarmmeldungen oder bestimmte Tastendrücke auf den Bus geben. Alle anderen unwichtigen Nachrichten, wie z.B. Temperaturen oder die Uhrzeit werden nicht gesendet. Somit ist kaum Buslast und der Flashvorgang kann beginnen. Ist dieser zu Ende wird das Flag per Befehl wieder gelöscht und die Knoten senden wieder normal. Diese Mimik muss allerdings von jedem Konten verstanden werden, sprich in der Firmware integriert sein. Über sowas sollte man sich daher schon in der Planungsphase des Busses und der Software Gedanken machen. Gruß CanUser schrieb: > Um eine hohe Buslast zu simulieren, sende ich mit dem Peak-Can-Dongle Sendest Du auch mit dem gleichen Peak-Dongle die Daten für den Flash? Ansonsten ist mir dein Gesamtaufbau nicht klar. >>>Die vorab gemachten Annahmen, dass dein Traffic durch höherpriore >>>Nachrichten gebremst wird kann man leicht im Analyser prüfen. >Von Peak habe ich nur den PCAN-View Software. Wo kann man dies mit dem >Viewer feststellen? Der Testausbau erscheint mir ungünstig. Der Peak sollte hier nur mithören. Meine Annahme war, dass die zusätzliche Buslast durch weitere Teilnehmer am Bus erzeugt wird. Ansonsten das Trace-Fenster nutzen. Soweit ich weiß, werden hier auch die Sendenachrichten eingetragen. Entsprechend der Zeitstempel kann man herausfinden, ob Lücken zwischen den Nachrichten sind oder nicht. Trifft die Annahme zu, dass die höherprioren Nachrichten die niederprioren ausbremsen, darf zwischen diesen keine Lücke sein. Nebenbei: Welche Bitrate nutzt Du? Stark gerundet 1 Nachricht aller 3ms sind bei 250kbit/s oder höher nicht wirklich problematisch. > Mimik des Flashens Ich denke, man sollte eine Anlage nicht während des Betriebs updaten. Insofern sollte es einen "Konfigurations"-Modus oder ähnliches geben, bei der naturgemäß der Traffic gering ist. Zumal auch durch das Firmwareupdate selbst viel Buslast erzeugt werden kann. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
