Windows 10 IoT Digital I/O Performance, Teil 3

14. Dezember 2016

In Teil 1 und 2 dieser Flurfunkserie wurde die Performance von Windows 10 IoT bei der Verarbeitung von Digital I/O Signalen analysiert. Als Fazit wurde festgestellt, dass Windows 10 IoT nicht einmal annähernd die Möglichkeiten der Raspberry Pi Plattform ausreizt. Hier sollen die Lightning Providers für Windows 10 IoT eine erhebliche Verbesserung bringen.

Setup der Lightning Providers

Voraussetzung für die Verwendung der Lightning Providers ist eine Windows 10 IoT Version von mindestens 10.10.0.10586.63 (Windows 10 1511). Die Einrichtung erfolgt in drei Schritten:

1. Zunächst wird auf dem Raspberry Pi 2 der Default Controller Driver vom standardmäßig eingestelltem Inbox Driver auf den Direct Memory Mapped Driver umgestellt. Dies erfolgt im Management Web von Windows 10 IoT:

Inbox Drivers

Default Inbox Driver

 

Memory Mapped Drivers

Direct Memory Mapped Driver

2. Zusätzlich wird im Visual Studio Projekt die Lightning Library als Nuget Package mittels Install-Package Microsoft.IoT.Lightning eingebunden.

3. Im Package.appxmanifest sind die folgenden Zeilen unter dem <Capabilities> Node hinzuzufügen:

<iot:Capability Name="lowLevelDevices" />
<DeviceCapability Name="109b86ad-f53d-4b76-aa5f-821e2ddf2141"/>

 

Damit sind alle Voraussetzungen zum Einsatz der Lightning Library geschaffen. Die Entwickler der Library haben das Ziel, beim Zugriff auf die Hardware komplett Api kompatibel zum Standardverfahren zu sein. Alle Objekte und Methoden sollen unterschiedslos zur Verfügung stehen. Die Verwendung der Lightning Library wird lediglich initial einmal beim Start des Programms über den folgenden C# Code festgelegt:

   1: if (Microsoft.IoT.Lightning.Providers.LightningProvider.IsLightningEnabled)

   2: {

   3:     LowLevelDevicesController.DefaultProvider = LightningProvider.GetAggregateProvider();

   4: }

Der komplette restliche C# Code kann unverändert bleiben.

Ergebnisse

Zur Messung der Digital I/O Performance wurde der in den Teilen 1 und 2 der Artikelserie benutzte Code benutzt. Lediglich die oben dargestellte Initialisierung der Lightning Library wurde ergänzt. In der folgenden Tabelle sind die gemessenen Werte für das reine Lesen und Schreiben Digitalein- und ausgängen (Verfahren 1) für die Windows 10 Versionen 1511 und 1608 dargestellt. Zum Vergleich wurde noch der beste gemessene Wert bei Verwendung des Inbox Drivers und der Standard Library aus Teil 1 mit aufgeführt:

Windows 10 IoT Version Frequenz Lesen Dauer Lesen Frequenz Schreiben Dauer Schreiben
1511 1,7MHz 589ns 1,9MHz 531ns
1608 1,7MHz 576ns 1,9MHz 525ns
1608 Inbox 0,2MHz 4100ns 0,2MHz 4300ns

Der Performancesprung ist beeindruckend. Die Ausführungsgeschwindigkeit ist um fast eine Größenordnung besser als bei Benutzung des Standardverfahrens mit den Inbox Treibern.Die Werte sind zwar immer noch weit vom theoretisch Machbaren entfernt. Dennoch zeigt die Lightning Library, welches Potential in Windows 10 IoT und der Programmierung mit Universal Apps bei der Verarbeitung von digitalen Hardwaresignalen steckt.

Leider ergibt sich bei der Analyse der Reaktionsgeschwindigkeit auf eine Signaländerung an einem Digitaleingang (Verfahren 2) ein ganz anderes Bild:

Die Implementierung des ValueChanged Events für Digitaleingänge funktioniert leider weder mit 1511 noch 1608. Erst mit Insiderpreviews ab 1608 wurde das Event implementiert. Dabei muss die Performance noch verbessert werden: Sind unter Verwendung des Default Inbox Drivers und der Standard Library 300µs als Reaktionszeit erreichbar, so sind dies unter Lightning bestenfalls 670µs. Dies bedeutet eine Verschlechterung um den Faktor 2. Damit wird das in Teil 2 geschilderte Anwendungsszenario eines Rotary Encoders praktisch nicht mehr umsetzbar. Hier hilft dann nur noch zyklisches Pollen der digitalen Eingänge und das Verarbeiten von Signaländerungen mit eigenem Code.

Fazit

Die Ergebnisse der Lightning Library sind vielversprechend. Es drängt sich allerdings der Eindruck auf, dass das Projekt noch Zeit benötigt, um die notwendige Stabilität und Reife zu gewinnen. So ist die angekündigte Kompatibilität zum Inbox Driver noch nicht erreicht: Es fehlen noch wichtige Properties wie z.B. der DebounceTimeout für GpioPin Objekte, mit denen z.B. das Prellen von mechanischen Schaltern herausgefiltert werden kann.

Auch abseits von GpioPin  gibt es noch Probleme: So war lange Zeit die Verwendung von I²C Bus Hardware nicht möglich, weil Timings nicht gepasst haben. Zur Zeit kann nur einer der zwei möglichen SPI Busse des Raspberry Pi benutzt werden. Teilweise kämpft der Entwickler mit nicht kompatiblen oder implementierten Methoden und Properties. Code, der mit dem Inbox Driver läuft, wird problemlos mit Lightning übersetzt, funktioniert aber dann nicht oder anders als erwartet.

Dennoch zeigt das Projekt, welche Performancereserven in Windows 10 IoT vorhanden sind. Es bleibt abzuwarten, bis das Projekt stabile Versionen liefert, die die erwartete Kompatibilität bei besserer Performance erfüllen. Dann steht auch einem produktiven Einsatz nichts im Wege.