Kann SPI sicher unterbrochen werden?

Ich schreibe von meiner Firmware aus auf eine microSD -Karte, aber es ist die Aufgabe mit der niedrigsten Priorität, sodass sie während des Lesens/Schreibens durch andere Aufgaben unterbrochen werden kann.

Angenommen, ich habe mit dieser microSD-Karte über einen UART kommuniziert. Das Problem beim Lesen wäre, dass das Hardware-RX- FIFO überlaufen würde, sodass die maximale Verzögerung, die ich anstrengen könnte, (FIFO-Größe × Bytes/Sekunde) wäre, und beim Schreiben gäbe es kein Problem, weil das andere Ende nur warten würde, bis ich Senden Sie das nächste Zeichen.

Wie funktioniert das jetzt, wo ich SPI verwende? Ist die Situation die gleiche, dass es für Schreibvorgänge keine Rolle spielt und für Lesevorgänge von der SPI-FIFO-Größe abhängt?

Antworten (2)

Die überwiegende Mehrheit der SPI-Geräte ist mit jeder Datenrate unterhalb des angegebenen Maximums vollkommen zufrieden. Man könnte einen Teil einer Transaktion durchführen, an einem beliebigen Punkt eine Pause einlegen, ein paar Jahre später wiederkommen und sie abschließen. Vorausgesetzt, dass es keine Störungen auf der Uhr, der Auswahl oder den Stromleitungen gab, würde die Transaktion normal abgeschlossen werden.

Es gibt drei Hauptvorbehalte, die Sie beachten sollten:

  1. Im Allgemeinen darf, sobald eine Transaktion auf einem SPI-Bus begonnen hat, keine der Leitungen auf dem Bus für andere Zwecke verwendet werden, bis diese Transaktion abgeschlossen ist. Im Allgemeinen bedeutet dies, dass ein Interrupt keinen SPI-Bus verwenden darf, es sei denn, es ist das einzige, was den Bus verwendet (es kann möglich sein, dass der Interrupt den Bus zu bestimmten Zeiten exklusiv verwendet, und für den Haupt Programm zur ausschließlichen Verwendung zu anderen Zeiten). Einige Geräte enthalten spezielle Pins, damit sie den Bus mitten in einer Transaktion "ignorieren" können, aber selbst mit solchen Funktionen würde ich nicht empfehlen, zu versuchen, einen Interrupt zu veranlassen, eine SPI-Transaktion mit einem Gerät auszusetzen, eine Transaktion mit einem anderen Gerät durchzuführen, und lassen Sie dann den zugrunde liegenden Code seine Transaktion mit dem ersten fortsetzen. Es ist besser, den Interrupt über einen separaten SPI-Bus zu verwenden.
  2. Einige Geräte verhalten sich möglicherweise merkwürdig, wenn eine Transaktion zu lange dauert. Einige Echtzeituhr-Chips puffern beispielsweise die Zeit-/Datumsregister nicht doppelt, sondern verriegeln stattdessen alle "Zeitvorlauf"-Ereignisse, die während einer Transaktion auftreten würden, und wenden sie an, nachdem die Transaktion abgeschlossen ist. Wenn eine Transaktion so lange dauert, dass ein zweites Zeitvorlaufereignis eintrifft, wird das letztere Ereignis ignoriert, wodurch die Uhr um diese Zeitspanne vorrückt. Ich sehe wirklich keine Entschuldigung dafür, einen Chip auf diese Weise zu entwerfen (selbst wenn man die Kosten für die doppelte Pufferung der Daten nicht haben wollte, wäre die Angabe, dass die Software für die Gewährleistung ihrer Kohärenz verantwortlich ist, billiger als das Hinzufügen der Logik "Update-Verzögerung". und würde die Wahrscheinlichkeit einer Taktstörung minimieren), aber solche Chips existieren.
  3. Es gibt einige Geräte, die ein Takt- und Datensignal verwenden, aber eine "Pause" verwenden, um das Framing anzuzeigen. Das jüngste Beispiel dafür, das mir begegnet ist, war eine LED-Lichterkette mit Controller pro Glühbirne. Ich mag solche Designs nicht besonders (man könnte das Framing genauso gut mit drei aufeinanderfolgenden steigenden Flanken auf der Datenleitung ohne dazwischenliegenden Takt anzeigen), aber noch einmal, solche Geräte existieren.

Während bestimmte Kommunikationsarten die Verwendung bestimmter Timings erfordern, gibt es selten einen Grund für SPI-Geräte, diese zu erfordern. Dennoch muss man sich bewusst sein, dass es solche Geräte gibt.

+1 Schön! Stimme all deinen Meinungen/Frustrationen voll und ganz zu. Auch zu oft gesehen.

Beim Überprüfen einer Kopie der Spezifikation (die ich aus Urheberrechts- / NDA-Gründen nicht zitieren kann) wird die SPI-Rate ab 0 Hz angegeben, was bedeutet, dass der statische Betrieb in Ordnung ist. Unter SPI erhalten Sie nur Daten zurück, während das Gerät getaktet wird. Wenn Sie also ein Hardware-SPI verwenden, erhalten Sie nur etwas, nachdem Daten (auch wenn 0 / egal) gesendet wurden. In dieser Hinsicht unterscheidet es sich also von einem UART, bei dem Sie jederzeit unaufgefordert Daten zurückerhalten können.

Meine einzige Sorge sollte also sein, dass die MicroSD-Karte eine Art Zeitüberschreitung eingebaut hat, aber nicht SPI selbst?
Laut den Spezifikationen von allem, was ich sehen konnte, sollte es auch keine Form von Zeitüberschreitung auf der SD-Karte geben, also sehen Sie nicht wirklich, dass Sie irgendwelche Probleme haben sollten. Vor Jahren habe ich benutzerdefinierten Code geschrieben, und während des Debuggens war ein Einzelschritt durch den Code, wobei zwischen den SPI-Operationen beispielsweise 10 Sekunden oder mehr lagen, und alles war in Ordnung.
+1, Die Möglichkeit, SPI auf 0 Hz herunterzufahren, ist für das Debugging nützlich zu wissen. Danke.
Es ist erwähnenswert, dass sich bei einigen SPI-Geräten die Datenausgabe nur an einer bestimmten Taktflanke ändern kann, bei einigen anderen kann sich die Datenausgabe jedoch manchmal asynchron ändern. Dies ist besonders häufig bei einem "Besetzt"-Bit der Fall. Wenn man bei einigen Chips den Zustand des "Busy"-Bits ausgetaktet hat und es immer noch am Ausgang ist, wenn der Teil frei wird, ändert sich der Ausgang asynchron. Auf einigen anderen Chips ändert sich der gemeldete "Beschäftigt"-Zustand nicht, bis er neu getaktet wird. Beide Designs haben Vor- und Nachteile, daher ist es hilfreich zu wissen, dass es beide Arten von Designs gibt.