Das Windows-API kann benutzt werden

Bei den kompilierten Programmen handelt es sich um normale Windows-Programme. Und sie können auch Teile des normalen Win32-APIs verwenden. Leider dokumentiert Microsoft nicht, welche Einschränkungen bestehen - vermutlich betrifft das vor allem Funktionen mit Bezug auf die grafische Oberfläche.

In einem kleinen "Sketch" nutzen wir das Win32-API, um uns beim Programmstart die Windows-Version anzuzeigen zu lassen:

#include "stdafx.h"
#include "arduino.h"
#include "windows.h"
 
int _tmain(int argc, TCHAR* argv[])
{
    DWORD dwVersion = GetVersion();
    DWORD dwMajorVersion = (DWORD)(LOBYTE(dwVersion));
    DWORD dwMinorVersion = (DWORD)(HIBYTE(dwVersion));
 
    Log(L"%d.%d\n", dwMajorVersion, dwMinorVersion);        
 
    return RunArduinoSketch();
}
 
...

Nun kann dieses Programm auch unter anderen Windows-Varianten auf der Kommandozeile laufen, wenn eine bestimmte DLL parallel in diesem System mitkopiert wurde (embprusr.dll). Interessanterweise liefert uns das Programm für die Windows-Variante auf dem Galileo-Board die Versionsnummer 6.3, unter Windows 8.1 Pro hingegen 6.2.

Microsoft will später noch zusätzliche APIs und C#-Integration anbieten, so dass auch Universal-Apps unter dieser Windows-Version laufen können.

Wer nach der langen Bootzeit vermutet, dass auch Programme auf der Kommandozeile lange zum Start brauchen, der irrt. Bei unseren kleinen Testprogrammen gab es beim Start über Telnet direkt auf dem Galileo keine Wartezeiten.

GPIO-Pins unter Windows nutzen

Unter Linux konnten GPIO-Pins eines Rechners schon lange über das Dateisystem angesteuert werden. Der Ansatz ist äußerst flexibel und zwingt dem Anwender keine Programmiersprache auf. Intels Implementierung des Wiring-APIs des Arduino auf dem Galileo setzt darauf auf. Der Umweg über das Dateisystem ist allerdings vergleichsweise zeitintensiv, Auswertungen im Milli- oder gar Mikrosekundentakt sind schon deswegen kaum möglich. Deshalb hat Intel auch auf eine Implementierung der pulseIn()-Funktion des Wiring-APIs verzichtet, die eine bestimmte Schnelligkeit voraussetzen würde.

Auch unter Windows können GPIO-Pins angesteuert werden, diese Funktion wurde aber lange Zeit im API für die Treiberprogrammierung versteckt.

Beim Windows für den Galileo geht Microsoft einen anderen Weg und führt das "Embedded Peripheral Usermode API" ein, das von der oben angesprochenen DLL embprusr.dll implementiert wird. Dieses API ist derzeit nicht weiter dokumentiert, lediglich ein Blick in die zugehörige C-Header-Datei gibt einige Informationen preis: So wird der Lese- wie Schreibzugriff auf GPIO-Pins unterstützt, PWM- und Analog-zu-digital-Funktionalität als auch der I2C- und SPI-Zugriff.

Um es vorwegzunehmen: analogRead() sowie digitalWrite() und digitalRead() funktionieren ohne Murren.

Viel interessanter ist, ob sich die vorhandene pulseIn()-Funktion sinnvoll nutzen lässt. Das haben wir mit einem Entfernungsmesser auf Ultraschallbasis getestet. Der Sensor übermittelt die Entfernung, indem am Echo-Anschluss ein HIGH-Signal anliegt. Die Dauer des Signals korreliert mit der gemessenen Entfernung. Allerdings ist das Signal auch bei größeren Entfernungen nur wenige Mikro- bis Millisekunden lang. Bei einem Microcontroller ist die Auswertung kein Problem, das entsprechende Programm "auf dem blanken Metall" hat die Ressourcen des Controllers exklusiv. Sobald ein Programm aber auf einem multitaskingbasierten Betriebssystem läuft, wird es schwierig.

So war es absehbar, dass unser Windows-Programm scheitern würde - zur Erinnerung: Unter Intels Ansatz mit Linux kann es nicht scheitern, weil die entsprechende Funktionalität ganz fehlt.