Gibt das SPI-Protokoll an, wie viele Takte ein Master-Gerät an den Slave senden soll?

Ich versuche, ein SPI-Gerät in Verilog zu implementieren. Ich habe viele Probleme mit der Koordination von Master und Slave, da das SPI-Master-Gerät manchmal (mit meiner aktuellen Impl.) nicht genügend Taktimpulse an den Slave sendet, damit es seine Verarbeitung beenden kann.

Dies kann beispielsweise auftreten, wenn der Slave so implementiert ist, dass seine Zustandsmaschine mehr Zustände hat und er aufhört, Taktimpulse zu empfangen, bevor er seinen Zyklus beendet.

Ich könnte meine Implementierung so modifizieren, dass diese beiden Geräte in Bezug auf Taktimpulse koordiniert werden, dies bedeutet jedoch, dass der Master-Implementierer die Impl kennen muss. Details des Sklaven (und aller potenziellen Sklaven). Das erscheint mir überhaupt nicht richtig.

Gibt das SPI-Protokoll genau vor, wie viele Impulse der Master dem Slave liefern muss, wenn er beispielsweise ein Byte sendet? Wenn nicht, wie kommt es, dass jedes SPI-Master-Gerät mit jedem Slave kompatibel ist? Wäre es in Ordnung, für alle Fälle eine Tonne Impulse (z. B. 64 Impulse für 1 Byte) an den Slave zu senden?

Autsch, gute Frage! Es scheint, je nachdem, wer seinen Standard nennt. Ich habe einen Wikipedia- Artikel gefunden, Intel behauptet, ihr Standard sei: "Dieser Standard unterstützt Standardspeicherzyklen mit Längen von 1 Byte bis 4 Kilobyte Daten." Ich bin mir nicht sicher, warum nicht 4 Bit auf 1 MB.
@jay was meinst du mit 'Speicherzyklen'? Ich verstehe, dass sie sagen, dass Sie Daten von 1 Byte bis 4 KB senden können, aber ich sehe immer noch nicht, wie viele Taktzyklen insgesamt gesendet werden sollten.
SPI taktet jeweils einen für ein Datenbit, sodass ein Byte 8 Takte benötigt. Somit sind 4 KB x 8 = 32 K Taktzyklen.
Sie müssen sich das Datenblatt des Geräts ansehen, das Sie fahren möchten. Es hat alle Regeln. Im Allgemeinen: Befolgen Sie das im Datenblatt des Geräts definierte Protokoll. Typischerweise wird die SPI-Transaktion "zurückgesetzt", wenn der Master die Slave-Auswahl von inaktiv auf aktiv umschaltet, und dann wird gemäß dem Datenblatt eine bestimmte Anzahl von Takten gesendet.
Einige Slave-Geräte benötigen eine Mindestanzahl von Bytes oder verlangen, dass ein „Dummy“-Byte gesendet wird.
"Das bedeutet, dass der Master-Implementierer die Implementierungsdetails des Slaves (und aller potenziellen Slaves) kennen muss" - nun, ja und nein. Beispielsweise muss die SPI-Hardware auf einem Mikrocontroller nicht alle möglichen Slaves kennen, es reicht normalerweise aus, nur eine Hardwarefunktion zum Takten eines Bytes auf der Leitung zu haben. (vielleicht plus Pufferung für Geschwindigkeit) Die Software kann dann mit den Besonderheiten der im Gerät verwendeten spezifischen Slaves umgehen, sie benötigt bereits gerätespezifisches Wissen darüber, was die Daten sind, also ist es nicht wichtig zu wissen, ob z. B. ein Dummy-Byte gesendet werden muss enorme Belastung.

Antworten (4)

Der SPI-Master ist nicht dafür verantwortlich, dass die interne Zustandsmaschine des Slaves „genügend“ Taktimpulse erhält. Der Master ist nur für einen Takt pro Bit verantwortlich, das zum oder vom Slave übertragen wird - das war's.

Wenn Ihr Slave zusätzliche Taktung benötigt, liegt es an Ihnen, Ihre Implementierung so zu verwalten, dass dies unterstützt wird - vielleicht geben Sie eine Mindestanzahl von Bytes an, die übertragen werden müssen (auch wenn einige davon "Dummy"-Bytes sind), oder vielleicht haben Sie es getan um dem Slave zusätzlich zum SPI-Takt einen externen Takt bereitzustellen.

Ein gut erzogener SPI-Slave sollte seine SPI-Zustandsmaschine zurücksetzen, wenn sein Slave-Select-Eingang deaktiviert wird, damit alles, was der Master in einer Kommunikationsrunde tut, nicht unbedingt die nächste Runde unterbricht, weil sich etwas in einem unvollständigen Zustand befindet.

Eine SD-Karte im SPI-Modus verwendet Framing-Bytes. Sie erhalten ein bestimmtes sich wiederholendes Byte, dann das Rahmenbyte und dann Datenbytes. Es ist kein so schreckliches Modell.
Ich frage mich, warum relativ wenige SPI-Geräte eine Möglichkeit bieten, die "Frame" -Zustandsmaschine zurückzusetzen, während CS niedrig gehalten wird, z. B. indem drei aufeinanderfolgende steigende Flanken an MOSI gesendet werden, während CLK niedrig sitzt. Für Anwendungen, die nur ein einziges SPI-Peripheriegerät benötigen, würde dies einen I/O-Pin auf der steuernden MCU einsparen.
@supercat, billiger, CS nur an die Reset-Leitungen einiger Komponenten zu binden, als einen Zähler zu implementieren?
@supercat - möglicherweise, weil dies einfachen Slaves im Schieberegisterstil zusätzliche Verarbeitungsanforderungen auferlegen würde.
Erhalten SPI-Geräte im Allgemeinen zwei Taktsignale, eines für die Byte-Verarbeitung und ein schnelleres für die Verarbeitung der Zustandsmaschine? Wäre das eine schlechte Praxis? Würde es als besseres Design angesehen, Framing-Bytes wie oben erläutert zu senden, um Energie zu sparen?
@Martel Meiner Erfahrung nach hängt die SPI-Slave-Taktung davon ab, wie viele zusätzliche Takte (falls vorhanden) das Gerät benötigt, um seine Sache intern zu erledigen. Wenn zusätzlich zu den für die Datenübertragung erforderlichen Takten nur wenige zusätzliche Takte benötigt werden, wird häufig die Methode der "Dummy-Bytes" verwendet, bei der ein paar zusätzliche Bytes mit bedeutungslosen Daten übertragen werden, nur um diese Takte bereitzustellen. Wenn der Slave viele zusätzliche Takte (oder kontinuierliche Taktung) benötigt, hat er entweder seine eigene interne Uhr oder einen zusätzlichen Taktstift.

Die Antwort auf alle Fragen zum SPI-Protokoll lautet: Es gibt kein SPI-Protokoll! Es ist die einfachste Möglichkeit, serielle Daten zu übertragen, im Wesentlichen nur ein Schieberegister. Werfen Sie einen Blick auf ein typisches SPI-Modul in einer MCU, und Sie werden die Probleme erkennen, die mit der Tatsache verbunden sind, dass es keinen Standard gibt (z. B. welche Kante erfasst werden soll).

Sie benötigen eine Methode, damit der SPI-Empfänger eine lokale Uhr empfängt, und verlassen Sie sich nicht darauf, dass die SPI-Quelle eine Uhr bereitstellt, um etwas anderes als die Taktung in seriellen Daten zu tun. Sie können die gemeinsam genutzte SPI-Uhr zum Übertragen von Daten verwenden, aber eine lokale Uhr verwenden, um Ihre Zustandsmaschine zu warten.

SPI ist kein Protokoll in dem Sinne, den Sie meinen.

Es ist nur eine Schnittstelle, um Bits automatisch seriell zu übertragen, am häufigsten in Vielfachen von acht, um Bytes zwischen Geräten zu übertragen.

Sicher, es ist ein Protokoll in dem Sinne, dass sich alle Parteien darauf einigen müssen, wie Daten gesendet werden sollen, einschließlich Dinge wie Taktphase, um zu wissen, an welcher Kante die Daten geladen werden und was die Leerlauftaktpolarität ist.

Und obendrein liegt es an den Geräten, ein Bit- oder Byte-Protokoll zu verwenden, um zu wissen, was die Bits und Bytes bedeuten.

Wenn Ihr SPI-Empfänger eine bestimmte Menge an Bits benötigt, muss der SPI-Sender diese Menge an Bits übertragen, nicht mehr und nicht weniger. Es liegt an Ihnen, was diese Bits enthalten und wie Ihr SPI-Empfänger funktioniert, wenn nicht die richtige Menge an Bits übertragen wird.

Die Reaktion des Slaves auf eine MOSI-Übertragung liegt ganz bei Ihnen, da Sie das Slave-Verhalten gestalten.

Wenn die Übertragung das einzige Mal ist (wenn der Frame aktiv ist), muss der Slave, um zu antworten, entweder sein Verhalten anpassen, um während des Frames fertig zu werden, ODER er muss dieses Verhalten implementieren und beschreiben, damit ein Master, der diese Fähigkeit verwendet, taktet MOSI-Daten lang genug (Fülldaten), um den Slave fertigstellen zu lassen.

Das ist der springende Punkt.

Ein Beispiel dafür, wo ich dies gesehen habe, ist der Teil Microsemi SmartFusion 2 (MS2090):

Es ist eigentlich nicht so seltsam oder ungewöhnlich. Der Microsemi M2S090 hat eine ähnliche Bedingung beim Polling für HW_STATUS. Das MOSI sendet 0xFF, und während des Taktens des Befehls enthalten die MISO-Daten die Antwort. Im selben Rahmen wird beim Eintakten des Befehls MOSI nicht nach 0xFFdem Slave getaktet.

Vergleichen Sie den Unterschied zu anderen Befehlen, bei denen der Master, nachdem die Nutzlast mit MOSI getaktet wurde, den Rahmen aktiv hält und mehr Daten-MOSI taktet, damit der Slave je nach Anforderung antworten kann. Der Master hält den Rahmen aktiv und während er aktiv ist, hält er die Uhr am Laufen.

Es ist Ihr Design und damit Ihre Anforderungen.

Was ich getan habe, um einen Vergleich zu untersuchen, war, einige Arduino-Boards M / S laufen zu lassen und das Verhalten zu untersuchen. Ich habe dieses Szenario verwendet, um eine Erwartung des Slaves zu validieren, auf die MOSI-Befehle/Daten zu reagieren.

EDIT: Beim zweiten Nachdenken liegt das nicht ganz bei Ihnen. Tatsächlich gibt es Standards, auf denen Drittanbieter aufbauen. Wenn Sie absolut sicher sind, dass Ihr ummauerter Garten der FPGA- und SPI-Nutzung isoliert ist, tun Sie, was Sie wollen. Wenn jedoch ein Gerät eines Drittanbieters eine Verbindung zu Ihrem Master herstellen und mit ihm Transaktionen durchführen soll, muss das Verhalten des Masters während eines Rahmens der SPI-Übertragung sorgfältig behandelt werden. (Ich denke hier an Mode, und es gibt Artikel auf Wikipedia usw. dazu sowie Ihr Datenblatt Ihres Siliziums, an dem Sie noch besser nachsehen sollten).

Gibt das SPI-Protokoll an, wie viele Takte ein Master-Gerät an den Slave senden soll?
AntwortenHierDatenschutz-Bestimmungen1y, 0v