Software-Tools Die Grenzen von »Eclipse«

»Leider ist die Eclipse-Realität weit vom ursprünglichen Traum einer Eclipse-Gemeinde entfernt«, meint Haakon Skar, Marketing Director für die »AVR«-Produktlinie bei Atmel
»Leider ist die Eclipse-Realität weit vom ursprünglichen Traum der Eclipse-Gemeinde entfernt«, meint Haakon Skar, Marketing Director für die »AVR«-Produktlinie bei Atmel

Ohne eine entsprechende Werkzeugkette für die Software-Entwicklung lässt sich heutzutage kein Mikrocontroller mehr verkaufen. Doch auf welche Tool-Chain soll der Entwickler setzen? Auf eine proprietäre des Herstellers oder auf eine offene wie zum Beispiel »Eclipse«? Wir fragten Haakon Skar, Marketing Director für die »AVR«-Produktlinie bei Atmel.

Haakon Skar, wie ist Ihre Einschätzung zum derzeitigen Markt für Software-Tools?

Es steht eine Vielzahl guter Entwicklungswerkzeuge zur Verfügung. Viele der neuen Tools tragen zu einer produktiveren und effizienteren Entwicklung bei. Verbessert wurden unter anderem die Editor-Technik, die Protokoll-Analyse, das automatische Testen und die Dokumentation von Projekten. Außerdem gibt es Werkzeuge, die sich an Steuerungssysteme anschließen lassen. Insgesamt ist ein hohes Maß an Innovation vorhanden, sodass sich die Entwicklungstools und deren Handhabung deutlich verbessert haben.

Worin unterscheiden sich Entwicklungswerkzeuge heute?

Eine offensichtliche Trennung besteht zwischen den professionellen Toolpaketen, für die man viel Geld bezahlt und den Amateur-Versionen, die jemand aus Eigennutz erstellt hat und dann im Internet veröffentlicht. Die wirklich guten Werkzeuge machen sich also rar und deren Spanne liegt weit auseinander. Obwohl einige Leute über ein Ecosystem für Tools sprechen, zeigt sich im Markt aber immer mehr eine Tendenz hin zu einem unübersichtlichem Nebeneinander, bei dem Gebiete abgesteckt und verteidigt werden, anstatt partnerschaftlich und in einer kontrollierten Umgebung zusammenzuarbeiten.

Eines dieser Ecosysteme oder Gemeinden ist »Eclipse«. Welche Meinung haben Sie über Eclipse?

Wir wissen viel über Eclipse, da Atmel der erste Anbieter von Mikrocontrollern waren, der es aufnahm. Zuerst dachten wir, die Idee einer offenen Plattform, zur der Entwickler beitragen und sich diese teilen können, sei eine großartige Möglichkeit, eine gemeinsame Plattform zu bilden. Tools würden interoperabel und unsere Werkzeuge würden zu den Tools unserer Partner passen.

Leider ist die Eclipse-Realität weit vom ursprünglichen Traum der Eclipse-Gemeinde entfernt. Leider vergrößert sich der Abstand sogar noch. Hier nur einige Beispiele: Entwickelt man ein Werkzeug, das für jede denkbare Hardware einsetzbar ist, ergibt sich ein unvermeidbarer und sehr komplizierter Konfigurationsprozess mit zahlreichen Optionen. Die Mehrzahl dieser Optionen passt nicht einmal auf die Tools, die gerade eingesetzt werden. Man muss sich also mit einer Schnittstelle herumschlagen, die 20 bis 30 Optionen bietet, von denen vielleicht gerade einmal nur zwei relevant sind. Ein weiteres Beispiel ist ein Plug-in, das für ein Werkzeug entwickelt wird. Es kann ein offener Standard sein, um Daten zu erstellen – kann aber auch nicht. Anderen Anbietern fällt es somit immer schwieriger, mit Eclipse zu arbeiten, um Add-ons zu entwickeln, die nahtlos zusammenpassen.

Welche Unterschiede bestehen in den Tools, die für Entwickler von Embedded-Systemen zur Verfügung stehen?

Die Unterscheidung liegt zwischen modularen und proprietären Werkzeugen und zwischen denen, die auf der Eclipse-Plattform basieren, die das Community-getriebene Tool ist. Es gibt auch integrierte Lösungen, die eine nahtlose Umgebung bereitstellen. Hier hat der Anbieter dafür gesorgt, dass alles gut zusammen passt und nur wenige Optionen, wenn überhaupt, benötigt werden. Sind Optionen vorhanden, können diese auch sehr intuitiv sein und den Informationen ähneln, die in den verschiedenen Unterlagen, wie zum Beispiel den Datenblättern der Bausteine, zu finden sind.

Betrachtet man die modulare Alternative, neigen einige davon – vor allem die Eclipse-basierten – unter ihrer offenen Art zu leiden. Sie sind offen für jeden Hardware-Debugger und so ausgelegt, dass sie alle Optionen darbieten. Für Anfänger, die dies zum ersten Mal sehen, kann das sehr einschüchternd wirken. Es gibt eine Vielzahl von Optionen, die nicht einmal relevant für die Hardware-Tools sind, die sie benutzen. Es können 30 oder mehr Optionen zur Auswahl stehen, und in der Realität sind vielleicht nur drei von ihnen relevant für die Hardware, die gerade angeschlossen wurde.

Wie entscheidet ein Entwickler bei 8, 16 oder 32 Bit, welches Tool er benötigt?

Hier kann man keine generelle Aussage treffen, in der Art, dass 8-Bit-Entwickler dieses und 32-Bit-Entwickler jenes Werkzeug benötigen. 32-Bit-Bausteine sind architektonisch ausgereifter, da sie größere Datenmengen bewegen müssen. Sie sind auch mit einer CPU ausgestattet, die eine andere Bandbreitenanforderung an das RAM hat. Und sie können auch einen Interrupt-Controller enthalten, der mehr Ebenen und Optionen bietet. Dabei zu sagen, dass das Entwicklungstool dann völlig anders ausgestattet sein muss, weil mehr Optionen zur Verfügung stehen, hat keinen Sinn. Ist man an eine Umgebung gewöhnt und setzt diese erfolgreich für ein Projekt ein, muss diese nicht unbedingt ausgetauscht werden, nur weil ein neuer Baustein verwendet wird. Bei einer neuen Umgebung kommen nur neue und unbekannte Optionen hinzu, was dazu führt, dass niemand weiß, ob entstandene Fehler durch den Baustein, die Software oder die falsche Konfiguration der Toolkette entstanden sind.

Wir empfehlen Kunden daher, nach Möglichkeit bei der gleichen Toolkette zu bleiben – selbst wenn sie von einem Mikrocontroller auf einen anderen wechseln. Es gibt zahlreiche Werkzeuge auf dem Markt, die verschiedene Bausteine unterstützen. Viele proprietäre Tools sind offen für verschiedene Mikrocontroller, sowohl für 8 Bit als auch für 32 Bit.