Während SPI anfänglich die Erweiterung einfacher 8-Bit-Mikrocontroller unterstützte, ist die Schnittstelle mittlerweile eine Grundlage für neueste Hochleistungsbausteine in aktuellen IoT-Anwendungen.

Während SPI anfänglich die Erweiterung einfacher 8-Bit-Mikrocontroller unterstützte, ist die Schnittstelle mittlerweile eine Grundlage für neueste Hochleistungsbausteine in aktuellen IoT-Anwendungen. (Bild: Panuwat - stock.adobe.com)

Das Serial Peripheral Interface (SPI) ist seit vielen Jahren eine der gebräuchlichsten Schnittstellen, um externe Peripherie, wie Sensoren oder Speicher, mit einem Host-Mikrocontroller zu verbinden. Weil sich die Funktionen der betreffenden MCU mithilfe der getakteten, synchronen seriellen Schnittstelle sehr einfach erweitern lassen, wurde SPI zur Standardimplementierung bei vielen Designs und ist heute auf fast allen Mikrocontroller-Typen zu finden.

Eine kurze Geschichte der SPI-Schnittstelle

SPI kam erstmals in den 1980er-Jahren in Mikrocontrollern von Halbleiterherstellern wie Motorola und National Semiconductor zum Einsatz. Besonders attraktiv war die einfache Möglichkeit, die überschaubaren Funktionen der damals noch simplen 8-bit-Mikrocontroller zu erweitern. Eine breite Auswahl an Peripherieelementen, wie EEPROMs, Analog-Digital-Wandler (ADC) und I/O-Erweiterungen, wurde schnell verfügbar. Die in der Folge sehr beliebten SPI-Peripheriebausteine beanspruchten dabei nur wenige Pins der Host-CPU. Im Gegensatz zur Peripherieanbindung über einen parallelen Bus verloren Anwender keinen kompletten I/O-Port. Dies bedeutete auch, dass SPI-Bausteine in der Regel weniger Strom aufnahmen als die parallel angebundenen Komponenten und dass sie in kleineren Gehäusen geliefert wurden. Somit waren sie auch kostengünstiger.

Ursprünglich war SPI vor allem bei Entwicklern beliebt, die ihre Designs um kleine nichtflüchtige Speicher ergänzen wollten. Im Laufe der Zeit haben jedoch immer mehr Bauelemente SPI unterstützt, sodass heute sehr viele verschiedene Funktionen angeboten werden. Die Schnittstelle verwendet ein einfaches, synchrones serielles Protokoll. Es kann als ein großer serieller Buffer betrachtet werden, den ein Master und ein Slave gemeinsam nutzen (Bild 1).

Bild 1: Vereinfachte SPI-Architektur: Im Shift-Takt des Masters lassen sich Daten von einem zum anderen Baustein transferieren.
Bild 1: Vereinfachte SPI-Architektur: Im Shift-Takt des Masters lassen sich Daten von einem zum anderen Baustein transferieren. (Bild: Renesas)

So lassen sich Daten unter der Kontrolle eines vom Master erzeugten Shift-Takts zwischen Bausteinen austauschen.

Die SPI-Schnittstelle wird vom Master gesteuert, der über vier logische Signale eine Verbindung zu einem oder mehreren Slaves herstellen kann. Diese sind üblicherweise bekannt als:

  • SCLK (Serial Clock, vom Master erzeugtes Taktsignal),
  • MOSI (Master Out Slave In, Datenausgabe vom Master),
  • MISO (Master In Slave Out, Datenausgang vom Slave),
  • CS (Chip Select, aktives Low-Signal, das vom Master erzeugt wird, um einzelne Komponenten zu adressieren und die Datenübertragung zwischen ihnen zu initiieren).

Bei den Mikrocontrollern der RA-Familie von Renesas wird SCLK gelegentlich auch als RSPCK und das CS-Signal als Slave-Select-Signal (SSL) bezeichnet.

Auch wenn SPI viele Pins für den Bus belegt, ist die Schnittstelle in der Lage, mit hohen Geschwindigkeiten zu arbeiten. Dabei unterstützen einige Bausteine Übertragungstakte von 60 MHz oder mehr. Zu den Vorteilen von SPI zählen die Unterstützung von Vollduplexkommunikation, hohe Geschwindigkeit und ein einfacher Kommunikationsmechanismus, der einen leicht zu entwickelnden Softwaretreiber voraussetzt. Bild 2 zeigt das Blockdiagramm einer typischen SPI-Anwendung mit vielen I/O-Pins für mehrere Peripheriebausteine.

Bild 2: SPI-Betrieb mit mehreren Mastern und Slaves, zusammen mit RA-MCUs.
Bild 2: SPI-Betrieb mit mehreren Mastern und Slaves, zusammen mit RA-MCUs. (Bild: Renesas)

Komplexer in der Praxis

SPI ist ein gutes Beispiel für eine nicht standardisierte De-facto-Norm. Unterschiedliche Implementierungen, die verschiedene Halbleiterherstellern vor Jahren herausgebracht haben, tragen je nach Bauelement und Hersteller unterschiedliche Bezeichnungen für die Logiksignale. Darüber hinaus haben die verschiedenen Hersteller SPI-Peripherien entwickelt, die in mehreren verschiedenen SPI-Varianten kommunizieren können. Dies erschwert die Initialisierung der Kommunikation zwischen mehreren Bauelementen.

Verschiedene Slaves können so konzipiert sein, dass sie kommunizieren, indem sie die Daten während der steigenden oder fallenden Taktflanke übertragen. Dies erfolgt entweder sofort, wenn CS aktiv wird, oder im nächsten Zyklus. Dies wird als Taktpolarität bezeichnet, und die Daten werden bei der jeweiligen fallenden oder steigenden Flanke, der so genannten Taktphase, abgetastet.

Slaves können in jeder dieser Varianten auftreten. Daher muss der SPI-Master auch in der Lage sein, in allen Varianten zu kommunizieren, um mit jedem potenziellen SPI-Slave zu kommunizieren. Darüber hinaus können SPI-Slaves erwarten, dass Daten entweder mit LSB oder MSB (Least/Most Significant Bit) zuerst übertragen werden, wobei die Datenlänge wählbar ist. Nutzt man mehrere Pins als Chip Selects, ist es möglich, unterschiedliche Peripherieelemente an einen Master anzubinden und jedes einzeln zur Initialisierung der Kommunikation auszuwählen.

Die Verwendung eines SPI-Masters auf einem Mikrocontroller kann recht komplex werden, wenn die MCU mit verschiedenen SPI-Peripheriebausteinen verbunden wird, die alle unterschiedliche Kommunikationsanforderungen stellen. Dies kann den Umfang des für die Schnittstelle erforderlichen Softwaretreibers stark vergrößern. Außerdem kann die Notwendigkeit, verschiedene Varianten zu unterstützen, eine Neukonfiguration der Schnittstelle zwischen einzelnen Datenübertragungen an verschiedene Slaves erfordern.

RA-Mikrocontroller: Das SPI im Detail

Das Serial Peripheral Interface der RA-Familie ist recht komplex, da es mit einer Vielzahl verschiedener Kommunikationsmethoden umgehen muss. Die Schnittstelle kann wie folgt programmiert werden: wählbare Taktpolarität oder Taktphase, programmierbare Datenübertragungslänge zwischen 8 und 32 bit, programmierbare Bitrate und die Möglichkeit, verschiedene SPI-Timings direkt zu steuern, etwa die Verzögerung vor der Freigabe des Chip Select und die Verzögerung bis zum nächsten Zugriff. Unterstützt werden Voll- und Halbduplex, sowohl reine Sende- als auch reine Empfangsoperationen.

Das SPI der RA-MCU kann bis zu vier Chip Selects automatisch steuern, womit bis zu vier Bausteine automatisiert kommuniziert werden können. Zusätzliche Bausteine lassen sich softwareunterstützt über Standard-I/O-Pins steuern. Das SPI der RA-Familie implementiert auch eine wählbare Pin-Invertierungsfunktion.

Die Schnittstelle verfügt über 128-bit-Sende- und Empfangsbuffer, die die Verwendung von bis zu vier Daten-Frames ermöglichen. Diese können in einer Sende- oder Empfangsrunde übertragen werden. Die Daten-Frames sind vom Anwender zwischen 1 und 4 für jede Übertragung wählbar.

Das SPI kann eine Vielzahl von Fehlern erkennen, die einen Interrupt auslösen. Interrupts können auch bei vollem Empfangsbuffer, leerem Sendebuffer und abgeschlossener Übertragung erzeugt werden. Mit diesen Ereignissen lässt sich auch ein Data Transfer Controller (DTC) oder ein DMA-Transfer auslösen.

Schließlich kann die Schnittstelle im Master-Modus arbeiten oder im Slave-Modus mit einem externen Master genutzt werden.

Übertragungen einfacher konfigurieren

Eine SPI-Übertragung wird durch das Schreiben von Daten in das SPI-Datenregister ausgelöst. Auf dieses Register kann man auf Byte-, Word- oder Longword-Basis zugreifen. Das SPI überträgt die Daten automatisch in den Sendebuffer und startet die serielle Übertragung.

Wenn Anwender mit mehreren Bausteinen kommunizieren wollen, beispielsweise über verschiedene SPI-Varianten mit unterschiedlichen Baud-Raten, müssen sie die Schnittstelle jedes Mal neu einrichten und die Übertragung auslösen. Dies kann eine Menge CPU-Overhead in Anspruch nehmen. Es wäre also viel einfacher, wenn es eine Möglichkeit gäbe, diese Konfigurierung und die Kommunikation automatisch auszuführen.

Die in der RA-Familie implementierte Schnittstelle RSPI nutzt einen hochentwickelten Befehlssequenzer in der SPI-Logik. Dieser ermöglicht die Konfiguration einer Reihe von automatischen Übertragungen zwischen verschiedenen SPI-Slaves und die Neukonfiguration der Schnittstelle zwischen den einzelnen Übertragungen. Dies kann die Anforderungen an die SPI-Interrupt-Service-Routine erheblich reduzieren. Die Entwickler müssen das SPI nicht mehr zwischen einzelnen Übertragungen zu einem anderen Baustein neu konfigurieren und können aus demselben Grund auch die Übertragungszeiten verkürzen. Die Verwendung des Command Sequencer, um das SPI zu managen, kann auch bei der Leistungseinsparung in der Anwendung vorteilhaft sein. Die CPU lässt sich nämlich in den Ruhezustand versetzen, während der Command Sequencer die Datenerfassung von verschiedenen Bausteinen automatisiert. Er kann entweder den On-Chip-DMA-Controller oder den DTC nutzen, um die zu sendenden Daten aus dem On-Chip-SRAM zu holen oder die empfangenen Daten in den SRAM Buffer zu laden, um sie später zu analysieren.

Mit dem SPI-Befehlssequenzer kann eine Sequenz von bis zu acht Übertragungen in einer Loop-Sequenz ausgeführt werden. Nachdem die Sequenz abgeschlossen ist, beginnt sie wieder mit dem ersten Befehl. Für jeden Befehl können die Funktionen Bitrate, Taktpolarität und -phase, Logiklevel der Slave-Auswahl, Länge der Datenübertragung und MSB/LSB zuerst eingestellt werden. Für jeden Befehl lässt sich außerdem auswählen, welcher Chip-Select-Pin verwendet werden soll, um so einen bestimmten Slave auszuwählen.

Beispiel: RA-Master mit drei Slaves

Bild 3 zeigt ein System mit SPI, das die RA-Master-MCU mit drei Slaves verbindet. Denkbar wäre eine Konstellation, in welcher der RA regelmäßig Daten von mehreren Messaufnehmern wie Druck-, Feuchtigkeits- oder Temperatursensoren erfasst. Der Befehlssequenzer ermöglicht es, deren Daten automatisch mit geringem CPU-Overhead zu erfassen. Der Befehlssequenzer kommt zum Einsatz, um die Kommunikation zwischen diesen Bausteinen zu managen. In diesem Beispiel wird eine Sequenzlänge von vier genutzt; auf Slave zwei wird zweimal zugegriffen, also doppelt so schnell wie auf die beiden anderen.

Bild 3: SPI-Betrieb in einem Beispielsystem mit mehreren Slaves und einer RA-MCU (links) sowie der dazugehörige Datenfluss (rechts).
Bild 3: SPI-Betrieb in einem Beispielsystem mit mehreren Slaves und einer RA-MCU (links) sowie der dazugehörige Datenfluss (rechts). (Bild: Renesas)

Die Verwendung des Befehlssequenzers reduziert die CPU-Last für die Lesevorgänge von seriellen Bausteinen über das SPI erheblich. In Kombination mit dem DTC oder dem DMA-Controller zur Automatisierung der Datenübertragung ist dies ein leistungsfähiges Tool zur Datenverwaltung von externen Komponenten wie Sensoren und Speichern, völlig automatisch und mit geringer CPU-Intervention. Es bietet eine hervorragende Möglichkeit, Daten von verschiedenen Sensoren ohne CPU-Beteiligung zu erfassen. In Kombination mit einigen anderen typischen Funktionen eines RA-Mikrocontrollers, wie dem DMA-Controller, kann das Lesen und Speichern der Daten externer Sensoren ohne CPU-Overhead vollständig automatisiert werden.

Das SPI wurde kontinuierlich weiterentwickelt, und seine Funktionen wurden ausgebaut. Die neuesten Versionen ermöglichen höhere Datenübertragungsraten und wurden insbesondere für die Unterstützung externer Speicher, wie PSRAMs und Flash, optimiert. Dazu gehört Quad SPI, welches den Datentransfer über einen parallelen 4-bit-Bus unterstützt und damit eine schnellere Übertragung zu und von externen Speichern ermöglicht. Einige QSPI-Peripherien unterstützen die XiP-Funktion (Execute in Place). Dies ermöglicht es den Mikrocontrollern, Code von den externen Speichern herunterzuladen und auszuführen, als ob der Code im lokalen Speicher des Mikrocontrollers läge. Einige der allerneuesten Bausteine lassen es sogar zu, den Code zu verschlüsseln, bevor er im externen Speicher abgelegt wird. Die SPI-Peripherie beherrscht die On-the-Fly-Entschlüsselung dieses Codes, sodass die MCU die entschlüsselte Anwendung ausführen kann und die Anwendungssoftware sicher bleibt.

Fazit: Weit mehr als gedacht

Während SPI anfänglich die Erweiterung einfacher 8-bit-Mikrocontroller unterstützte, ist die Schnittstelle mittlerweile eine Grundlage für neueste Hochleistungsbausteine in modernen IoT-Anwendungen. Das Anwendungsspektrum übersteigt die ursprünglichen Intentionen hinter dem Serial Peripheral Interface bei Weitem. Informationen über die SPI-Implementierung auf RA-Mikrocontrollern, einschließlich der neuesten Varianten, sowie über den SPI-Befehlssequenzer sind verfügbar unter: www.renesas.com/RA. (laa)

Graeme Clark, Renesas
(Bild: Renesas)

Graeme Clark

Principal Engineer bei Renesas Electronics

Sie möchten gerne weiterlesen?