Ein Blick in die Implementierung

Wir waren neugierig, wie pulseIn() implementiert wird - um herausfinden zu können, unter welchen Umständen pulseIn() vernünftige Ergebnisse liefern könnte.

Ein Blick in den Sourcecode der Microsoft-Implementierung des Wiring-APIs unter Windows ist möglich, da dieses unter einer BSD-Lizenz veröffentlicht wurde.

Die Implementierung ernüchtert uns - pulseIn() ist letztlich nur ein Wrapper um wiederholte digitalRead()-Aufrufe, es werden keine speziellen Treiberroutinen genutzt. Also testeten wir, wie lange ein einzelner digitalRead()-Aufruf benötigt.

Etwa 110 Millisekunden benötigt das Auswerten eines Pins! Zum Vergleich: Das im Galileo gespeicherte Linux braucht dafür nur 2 Millisekunden. Bei digitalWrite() fällt der Vergleich ähnlich ernüchternd aus: Unter Windows benötigt die Funktion um die 210 Millisekunden, das Linux begnügt sich mit 62 Millisekunden.

Eine leere loop()-Funktion selbst wird standardmäßig alle 16 Millisekunden aufgerufen - diese Zeitspanne entspricht der Standardtaktung von Windows. Sie ist zwar vergleichsweise lang, das Zeitmuster wird aber offenbar sehr stabil eingehalten. Unter Linux ist die Dauer mit von der Auslastung abhängig und liegt normalerweise im einstelligen Mikrosekundenbereich, sporadisch beträgt sie aber auch mal mehr als eine Millisekunde.

Ein erstes Fazit

Die gute Nachricht für die Linux-Fans: Sofort wird Windows Linux nicht von ihrem Bastelrechner verdrängen. Dazu fehlt es unter Windows noch an zu vielen kommandozeilenfähigen Werkzeugen - und Treibern für externe Hardware. "Mal so eben" komplexere Anwendungen zu scripten, geht vorerst nur mit Linux.

Doch das kann sich ändern. Die Out-of-the-Box-Integration des Galileo-Boards mit Visual Source ist exzellent und vereinfacht die Entwicklung enorm. Hier hatte Microsoft wirklich konsequent die Entwickler im Blick. Neue Treiber, kompatible Bibliotheken und Programme könnten schneller kommen, als mancher denkt. Erst recht, wenn Code tatsächlich kompatibel zu Desktop- und Mobile-Versionen von Windows sein soll.

Unser Eindruck von der Performance ist gemischt. Ja, Windows ist langsamer als Linux, aber es fühlt sich nicht so deutlich langsamer an, wie es zu erwarten wäre. Eine Copter-Steuerung würden wir damit nicht umsetzen, für eine Fütterungs- und Beleuchtungsautomatik am Aquarium reicht die Performance aber wohl. Eine Sanduhr als ASCII-Symbol haben wir jedenfalls nicht vermisst. Ein richtiger Benchmarktest steht allerdings noch auf unserer To-do-Liste.

Interessant wird es, wenn diese Windows-Version auch auf dem Intel Galileo der 2. Generation laufen wird. Dort soll die hardwareseitige GPIO-Ansteuerung verbessert worden sein; wir würden gern wissen, ob auch das Windows-GPIO-API davon profitiert.

Hätte Steve Ballmer vor einem Jahr behauptet, ein aktuelles Windows wäre auf einem Single-Core-x486-Prozessor mit 400 MHz und 256 MByte RAM benutzbar, wir hätten es als Marketingübertreibung abgetan. Aber in der Kommandozeilen-Variante funktioniert es tatsächlich.