Verhalten der Gerätetreiberfunktion bei Interrupt

Angenommen, ein eingebettetes System führt FreeRTOS aus und ein Anwendungsprogramm ruft eine Gerätetreiberschnittstelle auf (nehmen wir I2C an). Was genau passiert, wenn dies durch einen externen Interrupt unterbrochen wird? Wie sinnvoll ist es außerdem, die Treiberfunktionen als Tasks zu implementieren?

Antworten (2)

Was genau passiert, wenn dies durch einen externen Interrupt unterbrochen wird?

Wie Interrupts gehandhabt werden, hängt vom System ab. Aber ein Treiber ist wie jeder andere Code, er stoppt die Ausführung vorübergehend zugunsten des Interrupts.

Wie sinnvoll ist es außerdem, die Treiberfunktionen als Tasks zu implementieren?

Ein richtig geschriebener Treiber besteht aus zwei Modulen: einer Hardware-Abstraktionsschicht, die Ihre Anwendung aufruft, und dem eigentlichen Treiber, der systemspezifisch und nicht portierbar ist.

Im Idealfall sollte der Treiber völlig frei von anwendungsspezifischen Dingen sein, daher macht es keinen Sinn, einen Treiber in eine Betriebssystemaufgabe zu stecken. Ein Treiber ist/sollte viel niedriger sein als Dinge wie Betriebssysteme. Sie könnten jedoch den gesamten Anwendungscode, der mit einem bestimmten Treiber kommuniziert, in eine eigene Aufgabe packen. Beispielsweise ein Protokollcodierer/-decodierer.

Ein Gerätetreiber (für Geräte wie I2C) ist normalerweise in eine Anwendungsschnittstelle und eine Hardwareschnittstelle aufgeteilt.

Die Anwendungsschnittstelle legt die Daten, die Sie an das Gerät senden möchten, normalerweise einfach in einen Puffer und benachrichtigt den Hardwareschnittstellenteil des Treibers, dass Daten zu senden sind, und kehrt dann zum Aufrufer zurück. Das Anfordern von Daten würde beinhalten, zu prüfen, ob bereits genügend Daten verfügbar sind, und entweder darauf zu warten, dass die Daten verfügbar werden, oder sie sofort zurückzugeben.

Der Hardwareabschnitt der Schnittstelle nimmt Daten aus dem Schreibpuffer und leitet sie so schnell an die Hardware weiter, wie die Hardware sie annehmen kann. Die Hardware benachrichtigt den Treiber normalerweise durch einen Interrupt, um zu sagen, dass sie entweder Daten zur Verarbeitung erhalten hat oder es kann mehr zu übertragende Daten akzeptieren.

Es besteht die Anforderung, dass die Hardware- und Anwendungsabschnitte nicht gleichzeitig versuchen, die gemeinsam genutzten Speicherpuffer zu modifizieren, und es gibt mehrere Möglichkeiten, dies zu erreichen.

Die Verwendung von Interrupts ist optimal, da der Prozessor nur dann Arbeit zur Wartung der Hardware leisten muss, wenn die Hardware anzeigt, dass sie bereit ist. Um dasselbe in Tasks zu tun, ist ein Prozess erforderlich, der als "Polling" bekannt ist und im Wesentlichen die Hardware fragt, ob sie bereit ist. Sie können sich das so vorstellen, als würden Sie den Klingelton Ihres Telefons ausschalten und regelmäßig zum Telefon greifen, um zu sehen, ob jemand anruft.

"Die Verwendung von Interrupts ist optimal" Nun, das ist eine ziemliche Vereinfachung. Es hängt von Ihrer Spezifikation ab und davon, wie sich das Programm verhalten soll. Wenn Sie einen Chirurgen haben, der einen kritischen Moment mitten in der Operation abbricht, nur um sein klingelndes Handy abzuholen, macht er einen viel schlechteren Job als der Chirurg, der sein Telefon ausschaltet und es erst nach der Operation überprüft. Tatsächlich sind asynchrone Interrupts aus vielen verschiedenen Gründen sehr problematisch und werden daher in unternehmenskritischen Anwendungen normalerweise vermieden.