© Stmool/Shutterstock.com
Azure Sphere – Teil 3

Kommunikation mit großen Tieren


Der Datenaustausch zwischen Mikrocontroller und mehr oder weniger intelligentem IC ist ein Problem, das Entwickler wahrscheinlich seit Anbeginn der Entwicklung der Mikroelek-tronik zu lösen suchen. Im Laufe der letzten Jahre hat sich mit I2C und SPI eine Gruppe von Standards etabliert, die Azure Sphere seit einiger Zeit unterstützt.

Als Microsoft die MT3620-Plattform erstmals auf den geneigten C-Programmierer losließ, waren die APIs des Betriebssystems schlecht ausgebaut. Obwohl der unterliegende Prozessor sowohl I2C als auch SPI unterstützte, konnten die APIs nur mit normalen GPIO-Pins interagieren und über einen UART serielle Daten ausgeben. Seeed Studio bekämpfte dieses Problem durch die in Abbildung 1 gezeigte Adapterplatine, die die per serielle Kommunikation eingehenden Informationen weiterleitete.

hanna_sphere_teil3_1.tif_fmt1.jpgAbb. 1: Nicht mehr notwendig: das MT3620 Grove Shield

Da die Arbeit mit I2C und SPI zu den wichtigsten Kulturtechniken eines im Internet-of-Things-Umfeld lebenden Entwicklers gehört, wollen wir sie in diesem Artikel ein wenig näher ansehen.

Monochromatische Displays ansteuern

Waren grafische Displays im Pleistozän der Elektronik für Hauslaboratorien im Allgemeinen nicht leistbar, so hat die „Magie“ von AliExpress dafür gesorgt, dass man die Teile heute auch in den preiswertesten Projekten wiederfindet. Der Chiphersteller Solomon Systech hat mit seiner SSD-Serie im Bereich der Displaycontroller eine Quasivormachtstellung erreicht – auf dem SSD1306 basierende Displays sind heute für wenige Euro erhältlich und so gut wie überall verbreitet. In den folgenden Schritten wollen wir ein derartiges Gerät mit unserem Azure Sphere verbinden. Aus schaltungstechnischer Sicht verhält sich Sphere im Großen und Ganzen wie ein Arduino oder wie ein Raspberry Pi, weshalb die in Abbildung 2 schematisch gezeigte Schaltung erfahrenen Elektronikern eigentlich keine Hindernisse in den Weg legen sollte.

hanna_sphere_teil3_2.tif_fmt1.jpgAbb. 2: Aus elektrischer Sicht geben sich Sphere und Arduino nichts

Neben den beiden Statusleitungen ist bei Solomon-Systech-Controllern vor allem die DC-Leitung erforderlich. Hinter dem Namen verbirgt sich der Ausdruck Data/Control. Der an diesem Pin anliegende Wert entscheidet, ob der SPI-Transmitter des Chips mit der Steuerlogik oder dem Framebuffer des Controllers verbunden ist. Sinn dieser auf den ersten Blick aufwendigen Vorgehensweise ist, dass die (prozessintensiven) SPI-Framebuffer-Übertragungen so Eins zu Eins in den Framebuffer geschrieben werden können, ohne dass Protokoll und Controller-Logik Overhead für die Unterscheidung zwischen Kommando und Displaydaten einplanen müssen. Wichtig ist bei der SPI-Kommunikation dann noch, dass der für die Steuerung der Kommunikation verantwortliche Master auf der Taktleitung SCK eine – bis zu einem gewissen Rahmen beliebig schnelle – Arbeitsfrequenz generiert. Die Leitung MOSI (kurz für „Master Output, Slave Input“) trägt Informationen vom Master zum Slave. Für die Kommunikation in Gegenrichtung ist MISO („Master Input, Slave Output“) verantwortlich. Spezifikationsgemäß kann Information gleichzeitig in beide Richtungen fließen, aufgrund von Einschränkungen des MT3620 ist diese bidirektionale Kommunikation allerdings hier nicht möglich.

Im ersten Schritt wollen wir eine Aktualisierung des Azure SDKs durchführen. Nachfolgend wird in diesem Artikel Version 20.07 verwendet. Das Herumreiten auf spezifischen Versionen des Azure Sphere SDK ist dabei insofern keine Paragrafenreiterei, als Microsoft den Aufbau des Hardware-APIs in der Vergangenheit immer wieder grundlegend überarbeitet hat. Im nächsten Schritt öffnen wir Visual Studio 2019 und erzeugen ein neues Projekt auf Basis der Vorlage Azure Sphere Blink. Wundern Sie sich nicht darüber, wenn das Projektskelettauswahlfenster leer erscheint; Microsoft nutzte das letzte Update der Azure-Entwicklerwerkzeuge, um einige beliebte, aber bei Microsoft in Ungnade gefallene Projektvorlagen zu entfernen.

Festzurren der Hardwarekonfiguration

Wer Mikrocontroller-Systeme produktiv einsetzt und selbst entwirft, weiß, dass die Chiphersteller dem Elektroniker im Bereich des Mappings zwischen physikalischen und logischen Pins vergleichsweise viel Freiheit zugestehen. Es gibt kaum einen Controller, auf dem sich eine Hardware-Engine nicht mit zwei oder sogar drei unterschiedlichen Pinkomplementen verbinden lässt. Bei der Arbeit mit SPI ist das für uns insofern kritisch, als Microsofts Hardwarepartner im Bereich der Konfiguration ihr eigenes Süppchen kochen. Zur Lösung greift man auf als Hardwaredefinition bezeichnete Konfigurationsdateien zurück, die auf GitHub [1] zu finden sind. Angemerkt sei hier, dass man diese Dateien in der Welt von Yocto und anderen Embedded-Systemen als BSP bezeichnet – von der Funktion her sind sie allerdings identisch.

Wer mit der vom Autor verwendeten Hardware arbeitet, findet in...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang