Der einst als Gründer des hinter ThreadX stehenden Unternehmens Express Logic hat mit PX5 ein neues Echtzeitbetriebssystem am Start. Primäres Verkaufsargument ist die pThreads-API – was es sonst zu sagen gibt, zeigt dieses Interview.
Interview-Modus: wie lief das Interview?
Bill Lamie spricht nicht Deutsch. Aus diesem Grund erfolgte das Interview per e-mail in englischer Sprache. Die Übersetzung ins Deutsche erledigte der Autor per Hand. Wer den Originaltext haben möchte, kann tamhan aeht tamoggemon punkt com anschreiben.
Bildquelle alle: gestellt von PX5
Hallo Bill, danke, dass du Dir die Zeit für dieses Interview genommen hast. Bitte verrate uns ein wenig mehr darüber, wie sich Deine Lebensgeschichte präsentiert.
Während ich an der Universität war, hatte ich das Glück, in einem Unternehmen ein Praktikum zu machen, dass sich mit einem Echtzeit-Betriebssystem für eine militärische Anwendung auseinandersetzte - das System hieß damals EXOS. Obwohl Compiler, Prozessorarchitektur und das Design des Betriebssystems komplett anders waren, als es heute der Fall ist, setzte es mich trotzdem auf den Pfad der Echtzeitbetriebssystem-Entwicklung. Mein erstes kommerzielles Echtzeitbetriebssysteme Nucleus RTX entwickelte ich im Jahre 1989, danach folgte Nucleus Plus. Beide entwickelte ich unter dem Namen des Unternehmens Accelerated Technology, das später von Mentor Grafics aufgekauft wurde und jetzt zu Siemens gehört. Im Jahre 1997 startete ich das Unternehmen Express Logic und lancierte ein neues Echtzeitbetriebssysteme namens ThreadX. ThreadX wurde auf mehr als 10 Milliarden Geräten ausgeliefert, und 2019 von Microsoft aufgekauft. Letzten Sommer habe ich Microsoft dann verlassen und bin wieder im Embeddedbereich zurückgekehrt und habe eine - meiner Meinung nach disruptive-Technologie namens PX5 entwickelt.
OK! Lass uns In Medias Res gehen. Bitte gib mir einen „Elevator Pitch“ für PX5.
Das interessanteste Attribut von PX5 ist, dass das Betriebssystem die POSIX-pThreads-API nativ umsetzt. Wir haben die POSIX-Standard-API mit einem Echtzeitbetriebssystem kombiniert, um Geräte-Firmware portable zu gestalten und außerdem den Trainingsaufwand zur Einschulung von Entwicklern stark zu reduzieren. Wir hoffen, dass wir die Embedded-Entwicklung um die POSIX-APIs zusammenfassen und vereinheitlichen können. Außerdem möchte ich anmerken, dass PX5 für die Industrie als Ganzes im Bezug auf Performance, Platzbedarf, Einfachheit der Nutzung und Sicherheit einen Schritt nach vorne darstellt.
Warum hast Du Dich ausgerechnet für POSIX-Kompatibilität entschieden? Probiert die Linux Foundation mit Zephyr nicht etwas ähnliches?
Unsere Entscheidung, POSIX-pThreads „nativ“ zu implementieren, liegt vor allem an der immensen Popularität von Embedded Linux-Systemen. Embedded Linux macht mehr als 70 % der gesamten Embedded-Industrie aus. POSIX ist also nicht nur ein Industriestandard, sondern auch die best bekannte und meist benutzte API im Embedded-Bereich. Ich hoffe, dass wir den gesamten Embedded-Bereich - spezifisch meine ich hier auch die klassische Entwicklung von Mikrocontroller-Applikationen - um die POSIX-pThreads-API standardisieren können. Im Bezug auf Zephyr: Ich gehe davon aus, dass der Fokus auf POSIX-pThreads, egal ob es von Zephyr oder von einem anderen Echtzeit-Betriebssystem-Anbieter her erfolgt, für die Industrie als Ganzes ein „net positive“ darstellt. Nun aber noch spezifisch zu Zephyr: Das Betriebssystem ist eigentlich ein Derivat vom bei Eonic erzeugten Virtuoso RTOS, und ist nicht von Haus aus auf POSIX optimiert. Stattdessen hast Du die POSIX-API, die auf einer hauseigenen API “reitet“. Dieser mehrschichtige API-Aufbau führt nur allzu oft zu suboptimaler Performance und aufgeblähtem Code.
Welche Kerne unterstützt ihr anfangs?
Anfangs planen wir Unterstützung für Cortex-M/A/R , unter Unterstützung der Entwicklungswerkzeuge von IAR, GCC und ARM. Unterstützung für RiscV, 64 Bit-Kerne und SMP planen wir dann innerhalb der nächsten zwölf Monate.
Ich vermisse hier die Angebote von GigaDevice ein wenig. Gibt es denn schon „News“ zu den ARM-basierten Angeboten von GigaDevice? Und wie sieht es mit Unterstützung für andere ISAs wie RiscV oder X86 aus?
Unser „Off the Shelf“ Support ist architekturspezifisch - jeder Halbleiter-Anbieter, der einen Prozessor auf einer unterstützten Architektur hat, hat so gut wie sofort Unterstützung - das inkludiert explizit auch GigaDevice.
Unterstützung für RiscV planen wir innerhalb von zwölf Monaten. Zu X86 haben wir derzeit noch überhaupt keine Pläne.
Trotzdem bleibt eine Frage offen: Wie möchtet Ihr Integration in Codegeneratoren wie Cube oder MCC abbilden. Die in den diversen Mikrocontroller integrierten Peripheriegeräte werden immer komplexer.
Ja, langfristig werden wir uns definitiv in die verschiedenen Codegeneratoren integrieren. Anfangs ist unser Ziel allerdings ein anderes: Wir wollen sicherstellen, dass es geradezu Deppensicher ist, das PX5-Betriebssystem per „Drop-in“ in jedes beliebige vorhandene Mikrocontroller-Projektskelett einzubinden. PX5 besteht ja wie gesagt aus nur zwei Codedateien, normalerweise sind nicht einmal Eingriffe in die Einstellungen des Linkers erforderlich. Das bedeutet, dass Du Dir einfach die beiden Dateien „greifst“, die Headerdatei pthread.h inkludierst und die Methode px5_pthread_start aufrufst. Damit ist die Integration auch schon abgeschlossen.
OK, das klingt gut. Die nächste Frage sind die Benutzerinterfaces: STMicroelectronics hat Graupner, während Renesas ebenfalls einen hauseigenen GUI-Stack hat. Auch hier mache ich mir ein wenig Gedanken, weil ja moderne Mikrocontroller immer mehr „hauseigene“ 2-D-Beschleuniger mitbringen, die beispielsweise Rotation in Hardwarebeschleunigung erledigen. Im Allgemeinen ist hierfür allerdings „Hauseigenes“ Codieren erforderlich - OpenGL oder DirectX sucht man vergebens.
Wir unterstützen das quelloffene LVGL-Paket. In der Zukunft wird es außerdem Integration mit verschiedenen anderen kommerziellen GUI-Stacks geben. Weil das PX5-Echtzeitbetriebssystem auf POSIX-pThreads basiert, wird jede andere GUI (oder jede andere Middleware) mit Embedded Linux-Unterstützung auch auf PX5 ausführbar sein.
Was plant ihr zu TCP/IP?
Wir arbeiten derzeit an einem hauseigenen TCP/IP-Stack, und hoffen, dass dieser im Frühling zur Verfügung stehen wird.
Damit bleibt noch ein Thema offen: Was tut Ihr für die Thema Cloud? Sowohl AzureRTOS als auch FreeRTOS werden ja von Unternehmen vorangetrieben, die - mehr oder weniger umfangreiche - Cloud-Angebote in der Hinterhand haben.
Die Bedeutung des Internets der Dinge ist uns wohl bekannt. Wir planen, alle „marktführenden“ Anbieter von Cloud-Systemen gleichermaßen zu unterstützen. PX5 ist konzeptuell komplett anders als die anderen Systeme, weshalb wir diese (also Azure RTOS und FreeRTOS) nicht als direkte Konkurrenz zu unseren Angeboten wahrnehmen.
Lasst uns ein wenig über die Vergangenheit reden. Es gibt ja immer wieder Gerüchte, dass der Verkauf von FreeRTOS an Amazon eine „Notverkaufshandlung“ seitens Real Time Engineers war. Hast du diesbezüglich irgendetwas zu sagen?
Ich weiß nichts darüber, „wie“ die Transaktionen zwischen Amazon und Real Time Engineers abgelaufen sind. Weil FreeRTOS in der Vergangenheit aber ein vergleichsweise frei lizenzierbares, quelloffenes Betriebssystem war, kann ich mir nicht ganz vorstellen, wie es zu einem Notverkauf kommen sollte.
Diese Entscheidung dürfte Microsoft unter Druck gesetzt haben. Oder hast du eine andere Erklärung für die Übernahme von ThreadX?
Ich bin mir sicher, dass „so etwas von so etwas“ kommt. Und wenn es nur der Effekt war, dass diese doch stark publizierte Übernahme mehr Aufmerksamkeit für den Embedded-Bereich als Ganzes geschaffen hat.
Microsoft hatte bisher im Embedded-Bereich durchaus Probleme: Egal ob Sendo, der NetDuino oder der Gagdeteer. Denkst du, dass ThreadX in seinem „neuen Heim“ eine gute Zukunft haben wird?
Ich denke, dass ThreadX ein großartiges neues Zuhause gefunden hat. Das IoT-Team bei Microsoft versteht definitiv, wie der Embeddedbereich funktioniert und ist sich auch über die Bedeutung bzw. Relevanz von ThreadX im klaren.
Wenn einer meiner Leser mit ThreadX anfangen möchte - welche Ressourcen würdest Du empfehlen?
Ich würde vorschlagen, dass er im ersten Schritt unsere Firmenwebseite besucht. Dort gibt es jede Menge technische Informationen. Wer noch mehr Daten haben möchte, soll sich den User Guide herunterladen.
Planst Du auch, Präsenz außerhalb der vereinigten Staaten von Amerika zu haben?
Ja, im Laufe der Zeit werden wir unseren internationalen „Footprint“ erweitern - ganz analog dazu, wie es damals bei Express Logic lief.
Entwickler von Echtzeit-Betriebssystemen reden nur ungern über den Preis. Ich muss aber trotzdem fragen - in einer Zeit der kostenlosen Echtzeitbetriebssysteme würde ich gerne wissen, was wir „ungefähr“ im Bereich der Kostenfrage erwarten dürfen.
Wir werden permanente Lizenzen anbieten, die ohne Zahlungen für die einzelnen Geräte auskommen - im Bereich der Preise kann ich „reasonably priced – generally less than a couple months of an engineer’s salary“ zusagen. Außerdem werden wir ein Abonnement anbieten, wo Startups pro Entwickler bezahlen.
Community-Frage: Wie unterscheidet sich von der PX5 vom unter https://nuttx.apache.org/ bereitstehenden NuttX. NuttX ist ja seit vielen Jahren am Markt, und behauptet ebenfalls, POSIX-kompatibel zu sein.
Ich habe in der Vergangenheit immer wieder einen Blick auf NuttX geworfen, ohne es aber im Detail zu studieren. Wie ich vorher zu Zephyr gesagt habe: Jede Lösung, die die POSIX-PThreads-API „vorwärts treibt“, ist meiner Ansicht nach für die Embedded-Industrie als Ganzes ein net positiv.
Danke Dir vielmals für deine Zeit. Gibt es sonst noch etwas, was Du sagen möchtest?
Ich möchte mich noch vielmals dafür bedanken, dass ich über diese Themen mit Dir reden darf. Und es freut mich sehr, wieder zurück in der Embedded-Industrie zu sein.
Thread beobachten
Seitenaufteilung abschalten