Ich verwende eine ARM Cortex M4 MCU. Wenn ich einen Interrupt-Handler für einen GPIO mit Priorität 2 und einen SPI-Treiber mit Priorität 3 (dh niedrigere Priorität als die GPIOs) habe, und ich einen (blockierenden) SPI-Lesevorgang innerhalb des GPIO-Interrupt-Handlers anrufe, wird die SPI-Funktion funktionieren ?ARM Cortex-M4 Interrupt Prioritäten
Die Antwort auf Ihre Frage hängt davon ab, wie es blockiert, um die Übertragung zu behandeln, wie @Notlikethat sagte.
Wenn Ihr SPI-Treiber ein Abruftreiber ist, wird es höchstwahrscheinlich funktionieren. In diesem Fall würde Ihr GPIO-Interrupt Flags innerhalb des SPI-Peripheriegeräts aktivieren und darauf warten, dass jeder Teil der Übertragung abgeschlossen ist.
Wenn Ihr SPI-Treiber interruptgesteuert ist, funktioniert es nicht. Da Sie einen Interrupt der Priorität 2 (GPIO) ausführen, wird der Interrupt der Priorität 3 (SPI) nicht ausgeführt, bis der GPIO-Interrupt beendet ist. Abhängig davon, wie Ihr SPI-Treiber geschrieben wird, kann dies Ihr System vollständig blockieren oder es kann zu einem Timeout kommen.
Wenn Ihr SPI-Treiber DMA-gesteuert ist, ist die Antwort nicht so klar und hängt davon ab, wie der Treiber funktioniert. In diesem Fall ist es möglich, dass Ihre Transaktion abgeschlossen wird. Wenn die Funktion jedoch das Warten auf einen DMA-Interrupt blockiert hat, wird sie möglicherweise nie in Abhängigkeit von ihrer Priorität ankommen.
In jedem der oben genannten Fälle würde es im Allgemeinen als keine gute Idee sein, so etwas in einem Interrupt zu tun. Wenn Sie über ein RTOS verfügen, können Sie eine Aufgabe mit hoher Priorität verwenden, die auf einen Semaphor wartet, um die SPI-Transaktion auszuführen, oder, wenn das Betriebssystem dies unterstützt, die verzögerte Interruptverarbeitung verwenden. Wenn Sie nicht mit einem RTOS arbeiten, würde ich überlegen, ob es eine Möglichkeit gibt, einen Interrupt niedrigerer Priorität zu signalisieren (d. H. PendSV mit der niedrigsten Priorität zu verwenden) oder ein Flag innerhalb des Hauptprozesses zu überwachen. Wenn Sie einen Interrupt mit niedrigerer Priorität verwenden, können Sie den Hauptprozess (falls dies erforderlich ist) immer noch unterbrechen, aber alle anderen Interrupts können weiterhin ausgeführt werden. Wenn Sie ein Flag in Ihrem Hauptprozess überwachen können, würde dies auch Ihren Interrupts erlauben, fortzufahren, aber wenn Sie Zeitbeschränkungen haben, ist dies möglicherweise nicht möglich (wieder abhängig davon, wie Ihre Anwendung strukturiert ist)
Die MCU, die ich verwende, ist ein nordisches nRF52 ohne RTOS. Das Problem, das ich haben werde, ist, dass ich einen SPI-Sensor habe, der alle 4ms Daten bereithält, die von SPI bei jedem Interrupt gelesen und in einem Puffer gespeichert werden. Nachdem eine Anzahl von Proben gelesen wurde, werden die Daten verarbeitet. Die Verarbeitung wird voraussichtlich 10 ms dauern. Daher wird erwartet, dass zwei weitere Abtastwerte während der Verarbeitung bereit und gespeichert (zu einem Doppelpuffer) sind. Da es kein RTOS gibt, muss ich irgendwie zulassen, dass die neuen Daten Interrupts lesen, bevor sie den Verarbeitungshandler erreichen. Fortsetzung – tosa
Daher dachte ich daran, die SPI-Lesevorgänge direkt im GPIO-Interrupt-Handler ablaufen zu lassen, damit die Datenverarbeitungsfunktion von main aus (mit niedrigerer Priorität) ablaufen kann. Was ist der einfachste (und robusteste) Weg dies zu lösen? Vielen Dank! – tosa
Basierend auf den Zahlen, die Sie mir gegeben haben, klingt es so, als würden Sie nicht mithalten können. Wenn alle 4 ms neue Daten vorliegen, die 10 ms für die Verarbeitung benötigen, haben Sie nach 1 Sekunde ein Backlog von 150 noch unbearbeiteten Proben. In welchem Kontext findet die Verarbeitung statt? Ist es in einem der Interrupts, oder ist es im Hauptprozess? – rjp
Hängt davon ab Diese Funktion wird den SPI-Controller abfragen oder warten, bis ein Interrupt eintrifft ... – Notlikethat
Ein blockierendes Lesen (oder Blockieren von irgendetwas) in einem Interrupt-Handler ist eine wirklich schlechte Idee. Interrupts sollten immer so schnell wie möglich sein. –