Rx-Datenrate auf CAN-Bus schneller als Polling-Rate

Sie sollten Unterbrechungen nach Möglichkeit vermeiden. Themen:

1. Sie bringen vorhersagbares Echtzeitverhalten durcheinander.
2. Zahlreiche Interrupts können zu einer unvorhergesehenen Stack-Nutzung führen.
3. Es ist einfach, sehr subtile und sehr schwerwiegende Fehler zu schreiben, wenn Daten zwischen einem ISR und dem Hintergrundprogramm ausgetauscht werden.

Davon abgesehen können Sie diese Probleme durch sorgfältiges Systemdesign vermeiden.

1) ist nur ein Problem für nicht zyklische Interrupts, die zu einem beliebigen Zeitpunkt eintreffen können. Solange sich die Interrupts deterministisch verhalten und zyklisch ausgelöst werden, können Sie sie verwenden. In diesem Fall unterscheiden sie sich nicht von einem Prozess mit hoher Priorität, und Sie können immer noch das Echtzeitverhalten des Systems vorhersagen.

2) kann vermieden werden, indem die Anzahl der Interruptquellen so weit wie möglich reduziert wird. Andere Sicherheitsmaßnahmen bestehen darin, immer einen Stack zuzuweisen, der größer als nötig ist, und am wichtigsten: Platzieren Sie den Stack so, dass er bei einem Überlauf nicht in andere RAM-Speichersegmente wie .bss oder .data kaskadiert! Hier ist ein guter Artikel dazu .

3) Es ist am schwierigsten, sich davor zu schützen. Jede Variable, die zwischen einem ISR und dem Hintergrundprogramm geteilt wird, muss mit großer Sorgfalt behandelt werden. Es gibt zwei Probleme: Re-Entrancy- und Compiler-Optimierer-Probleme.

Der Wiedereintritt muss von Fall zu Fall mit atomarem Zugriff/Semaphoren/Mutex oder durch vorübergehendes Deaktivieren von Interrupts gelöst werden. Das ist immer knifflig und Sie müssen sicherstellen, dass Sie jedes Szenario berücksichtigt haben und dass der produzierte Maschinencode tatsächlich das tut, was Sie denken.

Das andere Problem ist, dass Ihr Compiler nicht erkennt, dass Ihre ISR von der MCU und nicht von Ihrem Code aufgerufen wird, und daher nicht versteht, dass alle von der ISR verwendeten Variablen jederzeit aktualisiert werden können. Der Compiler kann dann den Hintergrundcode falsch optimieren, da er davon ausgeht, dass eine bestimmte Variable nie verwendet wird. Dieser Fehler kann vermieden werden, indem Variablen, die mit einem ISR geteilt werden, immer als volatile.

Beide Probleme sind häufige Ursachen für sehr subtile, aber oft schwerwiegende Fehler. Es gibt keine Standardmethode, um sich davor zu schützen. Eine Sicherheitsmaßnahme kommt am nächsten, wenn Sie nur Ihrem hartgesottensten C-Veteranen erlauben, alle ISRs zu schreiben. Programmierer mit mittlerer Erfahrung, ganz zu schweigen von Anfängern, schreiben diese Fehler immer und immer wieder .

Aus diesem Grund ist es sehr schwierig, die Verwendung von Interrupts in sicherheitskritischen Anwendungen zu rechtfertigen. Sie müssten viel Zeit für Design, Tests und Dokumentation aufwenden, um sicherzustellen, dass nicht jeder dieser Interrupts Probleme verursacht. Daher kann ich verstehen, warum einige Sicherheitsstandards die Verwendung von Interrupts vollständig verbieten.

Was das spezifische Problem von CAN betrifft, so klingt es ein bisschen so, als hätten Sie entweder die falsche MCU für die Aufgabe ausgewählt oder den CAN-Controller nicht richtig verwendet. Fortgeschrittenere CAN-Controller haben Empfangspuffer, die Sie für dedizierte Nachrichten einrichten können, und zusätzlich einen Empfangs-FIFO, in den die restlichen Nachrichten gehen. Ich bin mir ziemlich sicher, dass NXP solche CAN-Controller für seine Cortex-M-Familien hat, zumindest auf dem LPC11C.

Mit einem solchen Ansatz und einem sorgfältig entworfenen CAN-Protokoll auf Anwendungsebene sollten Sie keine RX-Interrupts benötigen. Alle sicherheitskritischen CAN-Netzwerke müssen darauf ausgelegt sein, Nachrichten periodisch immer wieder zu senden. Wenn Sie wissen, dass eine bestimmte Nachricht nur alle 5 ms eintrifft, müssen Sie lediglich sicherstellen, dass Ihr Hintergrundprogramm schnell genug ist, um sie zu verarbeiten, bevor die nächste Nachricht eintrifft.

Für SIL4 hätten Sie wahrscheinlich mehr als einen CAN-Bus: Sie würden einen Bus für sicherheitskritische Echtzeitnachrichten reservieren und alles andere auf einen anderen, nicht kritischen Bus legen. Manchmal werden auch Redundanzlösungen mit mehreren CAN-Bussen verwendet, die dieselben kritischen Daten übertragen.