Express Logic-Boss Bill Lamie

„Als Erstes schrieb ich die Bedienungsanleitung“

08.02.13 | Redakteur: Franz Graser

William „Bill“ Lamie ist der Mitbegründer und CEO des US-Betriebssystemherstellers Express Logic. Er entwickelte das Echtzeitbetriebssystem ThreadX, das von Express Logic vertrieben wird, und das RTOS Nucleus, das Mentor Graphics heute vermarktet.
William „Bill“ Lamie ist der Mitbegründer und CEO des US-Betriebssystemherstellers Express Logic. Er entwickelte das Echtzeitbetriebssystem ThreadX, das von Express Logic vertrieben wird, und das RTOS Nucleus, das Mentor Graphics heute vermarktet. (Bild: Express Logic)

Bill Lamie, CEO des Echtzeitspezialisten Express Logic, hat mit Nucleus und ThreadX zwei ausgesprochen erfolgreiche RTOS-Plattformen entwickelt. Im Gespräch mit ELEKTRONIKPRAXIS plaudert er aus dem Nähkästchen.

Nicht jeder kann von sich behaupten, gleich mehrere erfolgreiche Echtzeitbetriebssysteme entwickelt zu haben. Bill Lamie, CEO des Softwerkers Express Logic, hat dagegen mit Nucleus – das von Mentor Graphics vermarktet wird – und ThreadX zwei weit verbreitete Systemplattformen programmiert, die heute noch am Markt sind und in Milliarden Geräten laufen.

Dabei interessierte sich der Sohn eines Informatikprofessors zunächst gar nicht für Computer. Nur „damit sein Vater endlich Ruhe gab“, schrieb er sich an der University of San Diego in einen Computerkurs ein und entdeckte dabei die Liebe zur Informatik.

Ergänzendes zum Thema
Literatur und Links

Herr Lamie, Sie haben zwei sehr erfolgreiche Echtzeitbetriebssysteme entwickelt – Nucleus und ThreadX. Wo würden Sie den Hauptunterschied zwischen den beiden Systemen sehen?

Eigentlich waren es sogar drei: Es gab zwei Versionen von Nucleus – Nucleus RTX, das erste RTOS, das ich um 1990 herum entwickelt habe, und Nucleus PLUS, das ich 1994 schrieb, und dann ThreadX.

Als ich Nucleus RTX entwarf, war es meine Absicht, die grundlegende Funktionalität bereitzustellen, die Entwickler wollten und brauchten. Ich wollte außerdem den Quellcode zugänglich machen, so dass die Kunden den Funktionsumfang des RTOS erweitern konnten und weil ich die Echtzeitbetriebssysteme, mit denen ich bis dahin gearbeitet hatte und deren Quelltext nicht vorlag, nicht mochte.

Eines Tages entdeckte ich, dass ich die Erfordernisse des Marktes nicht gut genug erkannt hatte. Das war der Grund dafür, dass ich bei einigen fundamentalen Dingen der Echtzeitsteuerung daneben lag. Die Entwickler wollten ein RTOS mit mehr Inhalt – eines, das den immer komplexer werdenden Herausforderungen gewachsen war. Da trat das zweite RTOS auf den Plan, Nucleus PLUS.

Mit Nucleus Plus schlug ich exakt die entgegengesetzte Richtung wie bei RTX ein und baute praktisch alles ein, was es unter der Sonne gab. Ich integrierte eine dynamische Objekterzeugung sowie Wege, Warteschlangen-Messages mit fester oder variabler Länge zu versenden, eigentlich alle möglichen Optionen, die mit Warteschlangen-Messages zu tun hatten. Die API enthielt Hunderte von Diensten, im Gegensatz zu den 20 bis 30 bei Nucleus RTX. Ich überarbeitete außerdem die komplette Interrupt-Architektur, weil ich versuchen wollte, sie responsiver zu machen.

Nachdem Nucleus PLUS auf den Markt gekommen war, entdeckte ich, dass mein Ansatz der pure Overkill war. Einerseits brachte die zusätzliche Funktionalität mehr Overhead, und das nur, um exotische Anwendungsfälle abzudecken. Andererseits war der Code komplexer, weit umfangreicher und schwerer zu warten. Kurz nach der Veröffentlichung von Nucleus PLUS bedauerte ich zwei Dinge: Die Komplexität, die ich mit der Vielzahl von APIs geschaffen hatte, und die Interrupt-Architektur, mit der ich versucht hatte, die inakzeptable Latenzzeit bei Interrupts bei Nucleus RTX zu beheben.

Und was passierte dann?

Meine Erfahrungen mit Nucleus RTX und PLUS – das eine war zu simpel und das andere zu komplex – halfen mir dabei, den goldenen Mittelweg zu finden, der eine ausreichende Funktionalität bot, ohne dabei unnötig komplex zu sein. Mit diesem Wissen entwarf und entwickelte ich ThreadX im Jahr 1996. Ich begann die Entwicklung von ThreadX damit, indem ich als Erstes die Bedienungsanleitung schrieb! Damit wollte ich sicherstellen, dass das System einfach zu bedienen sein würde. Erst dann entwickelte ich den Code für jede Funktion.

In ThreadX konnte ich drei zentrale Verbesserungen umsetzen: Erstens die Reduzierung der Anzahl und Komplexität der Service-APIs, zweitens die Konzentration auf 90 Prozent der Anwendungsfälle anstatt zu versuchen, alle exotischen Bedingungen abzudecken, und drittens die dramatische Veränderung der Interrupt-Architektur, um die Effizienz zu verbessern. Diese Verbesserungen führten zu geringerem Overhead, erforderten weniger Prozessorzyklen, und der Code war weniger umfangreich, leichter zu lesen und einfacher zu verwenden.

Kurz und gut: Die wichtigsten Unterschiede meiner drei Echtzeitbetriebssysteme liegen in ihrer Komplexität und ihrer Benutzerfreundlichkeit: zu wenig komplex (Nucleus RTX), zu komplex (Nucleus PLUS) und gerade richtig (ThreadX).

ThreadX ist nun das Hauptprodukt des Unternehmens Express Logic. Was sind die wichtigsten Anwendungsfelder für ThreadX?

ThreadX und die dazugehörigen Middleware-Produkte für Netzwekkommunikation, USB, Graphik, Dateisysteme und Entwicklung sprechen drei zentrale Anwendungsgebiete an:

  • Endgeräte für Konsumenten, unter anderem Ein-Chip-Systeme für Smartphones, Drucker und Kameras,
  • Medizinische Geräte, darunter Defibrillatoren, Beatmungsgeräte und Geräte zur Patientenüberwachung und
  • Industrielle Steuergeräte, unter anderem LED-Anzeigesysteme, intelligente Zähler und Messgeräte und Inspektionssysteme.

Darüber hinaus wird das System erfolgreich im Luft- und Raumfahrtsektor sowie in der Automobilelektronik eingesetzt.

Zu unseren wichtigsten Kunden zählen HP (Tintenstrahldrucker), Broadcom (Systeme für drahtlose Kommunikation), Welch Allyn (medizinische Geräte) und GE (intelligente Zähler und Messgeräte). Auch zahlreiche andere große Industrieunternehmen in diesen Marktsegmenten nutzen ThreadX – einige davon möchten nicht genannt werden, einige weitere führen wir auf unserer Website auf.

Erst vor kurzem wurde das System für die Verwendung in Smartphones ausgewählt, und zwar immer in Zusammenhang mit einem Ein-Chip-System, das ThreadX verwendet und ein ganz bestimmtes Subsystem steuert: Baseband-Radio, Bluetooth-Funk, und WiFi. Unsere Hardwarekunden bauen SoCs, die jeden dieser Bereiche adressieren, und diese SoCs werden in Milliarden von Smartphones, Tablets und anderen Geräten verbaut, darunter auch im iPhone und im iPad.

Inhalt des Artikels:

»1 »2 nächste Seite

Kommentar zu diesem Artikel abgeben
Zuerst die Bedienungsanleitung schreiben? Interessant. Genau das schlage ich meinen Kunden nämlich...  lesen
posted am 08.02.2013 um 15:02 von barheine


Mitdiskutieren

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 37979540) | Fotos: Express Logic

Softwareengineering-Report abonieren

4 mal jährlich: Die kostenlose Pflichtlektüre für Embedded­-Software- und Systems-Entwickler, von Analyse bis Wartung und Betrieb

* Ich bin mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung und AGB einverstanden.
Spamschutz:
Bitte geben Sie das Ergebnis der Rechenaufgabe (Addition) ein.
Heftarchiv
ELEKTRONIKPRAXIS 16/2014

ELEKTRONIKPRAXIS 16/2014

Ideen-Board für Spansions FM ARM Cortex-M MCUs

Weitere Themen:

Geld verdienen mit sozialen Medien
Hardware für digitale Hörgeräte
Chips für smarte Stromversorgung

zum ePaper

zum Heftarchiv

ELEKTRONIKPRAXIS 15/2014

ELEKTRONIKPRAXIS 15/2014

Das Internet of Things ist mehr als die Summe seiner Teile

Weitere Themen:

Welches Display ist das richtige?
Datenmanagement mit C-Controller
Sicherungen für die Raumfahrt

zum ePaper

zum Heftarchiv

ELEKTRONIKPRAXIS 14/2014

ELEKTRONIKPRAXIS 14/2014

Wenn Optik und Haptik eines Displays entscheiden

Weitere Themen:

Verbesserte SiCLeistungs- MOSFETs
Theorie versus Prozesstoleranzen
Hardware Monitoring

zum ePaper

zum Heftarchiv