Home
Tutorial
Demoprojekt für Eclipse-Einsteiger
09.08.2007 | Autor: Richard Barry*
Richard Barry, Urheber des Open-Source-Betriebssystems FreeRTOS, berichtet anhand eines Demoprojekts auf Basis von ARM-Prozessoren über seine Erfahrungen mit einer Eclipse-basierten Open-Source-Toolchain. Die Schritt-für-Schritt-Anleitung ist auch als Einladung gedacht, das Demoprojekt nachzubauen.
 | |
|
Als Verfechter von FreeRTOS.org – einem winzigen Open-Source-Echtzeitbetriebssystemkern – werde ich ständig aufgefordert, Eclipse in die Liste der bereits unterstützten Entwicklungsumgebungen aufzunehmen. Ich habe das bis jetzt abgelehnt, insbesondere deswegen, weil meine früheren Experimente mit Eclipse zeigten, dass das File-Management nicht mit der etablierten Quellcodestruktur von FreeRTOS.org mithalten kann. Ich habe jedoch erfahren, dass ständige Weiterentwicklungen diese Limitierungen aufgehoben haben, so dass man sich nun die Frage stellen kann: „Ist die Zeit jetzt reif, Eclipse für die Open-Source-Entwicklung einzusetzen?“
Das Eclipse-Demoprojekt
Es ist nicht einfach, sich eine Meinung dazu zu bilden, ohne zunächst praktische Erfahrung mit dem Einsatz von Eclipse in einem realen Entwicklungsprojekt gesammelt zu haben. Zu diesem Zweck und nach einiger Internet-Recherche habe ich eine bereits in FreeRTOS.org existierende Implementierung eines Embedded-Web-Servers konvertiert, der mit der Eclipse-Workbench sowohl aufgebaut (build) als auch debugged wird. In diesem Artikel werden die dabei gewonnenen Ergebnisse präsentiert, zusammen mit Links für weitergehende Informationen und die Quellen, die ich für wertvoll erachte. Ich hoffe, dass diese Informationen dem Leser helfen, diese Entwicklungsumgebung rasch nachzuvollziehen und damit diese Open-Source-Tools für sich abschätzen zu können.
Sämtliche Werkzeuge, Projekt-Dateien und der Quellcode des Embedded-Webservers können kostenfrei herunter geladen werden, was es erlaubt, mit dem Setup zu experimentieren und es müssen nur die Kosten für die Hardware aufgebracht werden. Um diese möglichst gering zu halten, entschied ich mich für das Ethernet-Evaluation-Kit LM3S6965 von Luminary Micro. Es ist mit 79 US-$ nicht nur preiswert (79 Dollar), sondern enthält sämtliche Schaltungen, die für das Flash-Programmieren und das Debuggen nötig sind, so dass kein externes JTAG-Interface benötigt wird. Zudem wird das Evaluierungs-Board über USB mit Strom versorgt, wodurch keine externe Stromversorgung notwendig ist. Der ARM Cortex-M3-Core mit ROM und RAM auf dem Chip bietet vielfältige Ressourcen für das Implementieren des Webservers.
Links:
Kostenlose Tool-Chain
Die Open-Source-Entwicklungs- und -Laufzeit-Umgebungen, die verwendet wurden um das Demo-Modell des Webservers zu erstellen und zu betreiben (run), sind in Bild 1 gezeigt. Die vollständige Information über die erstellten Funktionen (Tasks) und Pages, die vom Demo-Modell unterstützt werden, finden sich auf der Webseite FreeRTOS.org. (Links siehe weiter unten).
Das nächste Kapitel beschreibt die Komponenten, die zum Aufbau (build) des Demo-Modells nötig waren und das darauf folgende Kapitel, die Komponenten, die in der Demo-Applikation verwendet wurden. Danach erkläre ich die schrittweise Vorgehensweise wie dieses Demo-Modell realisiert und debugged werden kann. Der Artikel schließt mit einer subjektiven Beurteilung der Entwicklungsumgebung.
Benötigte Komponenten: Eclipse
Dieses Kapitel beschreibt die Werkzeuge, die nötig sind, um den als Beispiel verwendeten Webserver aufzubauen. Die angegebenen Links finde ich persönlich am hilfsreichsten.
Eclipse ist ein Open-Source-Software-Framework, das ursprünglich von IBM entwickelt wurde und nun von der Eclipse Foundation gepflegt wird. Die einfache Erweiterbarkeit hat zu einer sehr heterogenen Gemeinschaft vor Eclipse-Anwendern geführt. Interessant für Entwickler von Embedded-Systemen ist das CDT-Projekt (C/C++ Development-Tools), das die C- und C++-Projektstruktur und Syntax in Eclipse integriert – und damit Eclipse in eine Embedded-Entwicklungsumgebung mit bekannter Bedienoberfläche verwandelt. Die Yagarto-Webseite liefert eine Download-Möglichkeit, die sowohl die Eclipse-Workbench als auch eine spezielle Cross-Entwicklungsversion von CDT, die als ein einziges bequem anzuwendendes Installationspaket fungiert, enthält. Der Link für diesen Download befindet sich auf der Yagarto-Homepage. Man sollte beachten, dass der Einsatz des Cortex-M3-Prozessors bedeutet, dass zum Zeitpunkt dieser Untersuchung die weiteren auf der gleichen Seite verfügbaren Entwicklungswerkzeuge noch nicht für die Demo-Anwendung nutzbar waren.
Eclipse wurde ursprünglich in Java geschrieben, so dass das Java-Runtime-Environment (JRE) zur Ausführung erforderlich ist. Die meisten Computer haben aber bereits die JRE installiert. Um zu prüfen, ob dies für einen Computer der Fall ist, öffnet man die „Java-Version“ eines Befehls-Prompts und -Typs. Wird der Befehl nicht erkannt, muss man die JRE von der Sun Microsystems Webseite herunterladen und installieren bevor man Eclipse installiert. Ich habe erfolgreich die Java-Version 1.6.0_01 verwendet.
Links:
GCC-Compiler und GDB-Debugger
Die Eclipse-Workbench bietet eine visuelle Bedienoberfläche, die zur Softwareentwicklung in einer ganzen Reihe von Sprache verwendet wird, und eine grafische Bedienoberfläche für die Compilier- und Debug-Tools, schließt aber die Compilerwerkzeuge selbst nicht mit ein. Diese müssen separat beschafft werden. Zum Zeitpunkt dieser Untersuchung war CodeSourcery der einzige Lieferant von vorinstallierten GCC-Tool-Chains, die den Cortex-M3-Core unterstützen und deshalb nutzbar für die Demo-Applikation sind. Die Version „ARM EABI Sorcery G++ Light Edition“ war als ein einzig zweckmäßiges Windows-Installationspaket verfügbar.
Man muss sicherstellen, dass das Datenverzeichnis (directory) in das die GCC-Binaries installiert sind, in der jeweils verwendeten PATH-Variablen der Entwicklungsumgebung enthalten ist. Um dies zu überprüfen öffnet man den Befehls-Prompt und Typ “arm-none-eabi-gcc.exe --version”. Wird der Befehl nicht gefunden, muss die eingesetzte PATH-Variable der Entwicklungsumgebung aktualisiert werden.
Link:
Zip-Datei zum Eclipse/Coretex-Demoprojekt
Die Zip-Datei der Demo-Applikation enthält eine OpenOCD-Executable, µIP-Quellcode, den FreeRTOS.org-Quellcode, die Quelldateien der Demo sowie ein Makefile, das es ermöglicht, das gesamte Projekt zu realisieren (build). Diese einzelnen Komponenten werden im nächsten Kapitel ausführlich beschrieben.
Link:
Einzelkomponenten der Demo-Applikation
Dieses Kapitel erläutert die im Zip-File der Demo-Applikation enthaltenen einzelnen Komponenten. FreeRTOS.org: FreeRTOS.org ist ein populärer und sehr kompakter Open-Source-Echtzeit-Scheduler, der auf viele 8-, 16- und 32-Bit-Prozessorarchitekturen portiert wurde. Zum Zeitpunkt dieser Untersuchung wurde der FreeRTOS.org-Quellcode mehr als 1000 mal in der Woche herunter geladen. Es sind auch zwei kommerzielle Varianten erhältlich: OpenRTOS ist eine kommerziell lizenzierte und unterstützte Version von FreeRTOS.org. Die Version SafeRTOS wurde in Übereinstimmung mit den Anforderungen für den Einsatz in Projekten die IEC-61508-SIL-3 entsprechen entwickelt und vom TÜV Süd zertifiziert.
Ich habe bereits den Quellcode von FreeRTOS.org in die Zip-Datei der Demo-Applikation Eclipse/Cortex integriert, so dass nichts von den folgenden Links herunter geladen werden muss.
Links:
OpenOCD
OpenOCD (Open On-Chip-Debugger) ist ein Softwarewerkzeug, das den GDB mit dem Evaluierungs-Board LM3S6965 verbindet. Es konvertiert Befehle, die über eine TCP/IP-Verbindung vom GDB empfangen werden in USB-Befehle, die zum LM3S6965-Degug-System gesendet und von diesem auch verstanden werden. OpenOCD kann ebenfalls dazu benutzt werden, den Flash-Speicher des Mikrocontrollers zu programmieren. OpenOCD wurde von Dominic Rath geschrieben und von Magnus Lundin für den Einsatz mit dem Cortex-M3-Core erweitert.
Ich habe eine vorbearbeitete OpenOCD-Executable in die Zip-Datei der Demo-Applikation Eclipse/Coretex integriert, so dass nichts von dem folgenden Link herunter geladen werden muss.
Link:
µIP – Embedded-TCP/IP-Stack
µIP ist eine von Adam Dunkels geschriebene TCP/IP-Implementierung speziell für den Einsatz in Embedded-Systemen mit begrenztem Speicher. Sie ist sehr einfach einzusetzen und zu konfigurieren. µIP verringert den RAM-Bedarf durch einen verringerten Datendurchsatz. Dies wird erzielt, da es jeweils nur einem Paket erlaubt wird, unbearbeitet auf dem Netzwerk zu einem gegebenen Zeitpunkt zu sein – Verzögerungen bei der Empfangsbestätigung dieses Datenpakets sind der Grund für den geringen Durchsatz. Diese Beschränkung wird am deutlichsten, wenn mit Desktop-Computern kommuniziert wird, ist jedoch nicht so offensichtlich bei der Kommunikation mit anderen µIP-Knoten (Desktop-TCP/IP-Implementationen versuchen im Allgemeinen den Datenverkehr in Netzwerk zu minimieren, und zwar durch absichtliches Verzögern der Empfangsbestätigung jedes empfangenen Datenpakets. Dies wird gemacht, um zu erkennen, ob weitere Datenpakete innerhalb eines kurzen Zeitfensters ankommen, was es ermöglicht, den Empfang mehrere Datenpakete gemeinsam zu bestätigen.) Der Datendurchsatz ist jedoch für die meisten Embedded-Systeme, die mit Bedienpersonen kommunizieren ausreichend, was µIP zu einer guten Wahl für die meisten Anwendungen macht. Wenn ein höherer Datendurchsatz erforderlich ist, kann IwIP an Stelle von µIP verwendet werden.
Ich habe den Quellcode von µIP in die Zip-Datei der Demo-Applikation Eclipse/Coretex integriert, so dass nichts von den folgenden Links herunter geladen werden muss.
Links:
Build, Laden und Ausführen der Web-Server-Demo
An dieser Stelle sollte mittels der bisher erwähnten Links nun die Eclipse- und GCC-Tools installiert und der Zip-File der Demo-Applikation gedownloaded sein. Dieses Kapitel führt den Leser durch die Schritte Erstellen (build), Herunterladen und Debuggen der Beispiel-Demo mit der Eclipse-Workbench – mit den durchnummerierten Punkten, die die Sequenz von erforderlichen Schritten anzeigt.
Öffnen des Demo-Projekts
1. Entzippen der Demo-Applikations-Dateien an einem geeigneten Speicherort, wobei ich im Weiteren voraussetze, dass dies c:\demo ist. Beim Extrahieren der Dateien ist darauf zu achten, dass die Struktur des Datenverzeichnisses erhalten bleibt. Nachdem die Dateien extrahiert sind, sollte c:\demo zwei weitere Verzeichnisse enthalten und zwar .metadata und RTOSDemo.
2. Starten von Eclipse – eine Verknüpfung muss dazu möglicherweise auf dem verwendeten Desktop platziert werden.
3. Man wird aufgefordert, einen Arbeitsbereich auszuwählen – dies ist der Speicherort, an dem die Projekt-Informationen gespeichert werden. Dazu gibt man c:\demo ein (oder ein beliebiges Verzeichnis, in die die Dateien entzippt wurden) so wie in Bild 2 dargestellt. Danach öffnet sich die Eclipse-Workbench.
Perspectives und Projektkonfiguration
Eine Eclipse-„Perspective“ ist eine Sammlung von Views und Editoren die definiert, wie die Daten dargestellt werden. Das Demo-Projekt verwendet zwei Perspectives, die C/C++-Perspective und die Debug-Perspective. Die beiden Buttons in der oberen rechten Ecke des Hauptfensters können dazu benutzt werden, zwischen beiden hin und her zu schalten (Bild 3). Die C/C++-Perspective wird für das Management und editieren des Projekts verwendet und die Debug-Perspective zum steuern der Debug-Sessions. Diese beiden Perspectives stellen die Informationen in einem Format dar, das den Anwendern kommerzieller Entwicklungsumgebungen bekannt sein sollte.
Die Eclipse-Workbench ist genau genommen eine grafische Bedienoberfläche für externe Entwicklungswerkzeuge. Dies ist der Grund warum ich es vermieden habe, sie als Integrierte Entwicklungsumgebung (IDE – integrated development environment) zu bezeichnen. Die Projekt-Konfiguration entspricht in diesem Fall der Definition, wie Eclipse mit einer Sammlung von externen (und deshalb nicht integrierten) Komponenten zusammenspielt. Man hat bereits gesehen, dass Perspectives definieren, wie die von diesen Werkzeugen ausgegebenen Daten dargestellt werden.
Die von der Eclipse-Umgebung gebotene Flexibilität kann es für Anfänger kompliziert machen zu wissen wo man beim Entwurf eines neuen Projekts am besten anfängt. Die Menge an Informationen, die im Internet verfügbar ist, kann ebenfalls überwältigend sein. Deshalb halte ich persönlich die Informationen auf der Yagarto-Webseite für einen besonders nützlichen Führer zur Erstellung und Konfiguration des Projekts.
Das Projekt, das im Zip-File der Demo-Applikation enthalten ist, ist bereits konfiguriert. Damit werden der CodeSorcery-GCC-Compiler und die MAKE-Utility aufgebaut, die mit dem Evaluierungs-Board LM3S6965 unter Nutzung des CodeSorcery-GDB-Debuggers und OpenOCD zusammen arbeiten und die Informationen mit den bereits beschriebenen Perspectives darstellen.
Link:
Aufbau der Demo-Applikation
4. Öffnen der C/C++-Perspective.
5. Die IP-Adresse des Embedded-Webservers muss kompatibel mit dem Netzwerk sein, in das er plaziert wird. Die IP-Adresse wird von den Konstanten uipIP_ADDR0 bis uipIP_ADDR3 in der Datei Demo/CORTEX_LM3S6965_GCC\webserver\µIP_Task.c gesetzt.
6. Mit der rechten Maustaste auf das RTOSDemo-Projekt im C/C++-Projektfenster klicken (Bild 4), dann „Build Project“ aus dem erschienenen Popup-Menü auswählen.
Das Ergebnis dieses Build-Vorgangs wird an das Console-Fenster (Bild 5) am unteren Rand der C/C++-Perspective gesendet. Build-Fehler und Warnungen können über die Auswahl des Problems-Tab angezeigt werden – wobei das Projekt ohne jegliche Fehler und Warnungen aufgebaut werden sein sollte.
Programmieren des Mikrocontroller-Flash-Speichers
7. Man verbindet das Evaluierungs-Board LM3S6965 nun über das mitgelieferte USB-Kabel mit dem verwendeten Computer. Wenn das Board das erste Mal mit dem Computer verbunden wird, wird man aufgefordert, mehrere USB-Treiber zu installieren alle davon sind auf der CD, die mit dem Evaluierungs-Board geliefert wird zu finden.
8. Man wählt aus dem Menü „Run/External Tools“ „OpenOCD“ aus (Bild 6). Dies ruft die OpenOCD-Executable in der korrekten Konfiguration auf, um den Flash-Speicher des Mikrocontrollers zu programmieren – der Output dieses Befehls kann im Console-Fenster dargestellt werden.
Starten einer Debug-Session
9. OpenOCD wird durch die Auswahl von „OpenOCD Server“ aus dem Menü „Run/External Tools“ gestartet. Dies ruft wiederum die OpenOCD-Executable auf. Dieses mal wird ihr aber mitgeteilt, ab jetzt auf eine Verbindung von GDB zu warten.
10. Umschalten zur Debug-Perspective (Bild 3).
11. Um eine GDB-Session zu starten klickt man auf den kleinen Bug-Speed-Button (Bild 7). Dies veranlasst GDB, sich über den OpenOCD-Server mit dem Evaluierungs-Board zu verbinden, und dann beim Start von main() wieder zu unterbrechen.
Steuern einer Debug-Session
Bis hierher wurde Eclipse verwendet, um zwei externe Tools zu starten, nämlich OpenOCD und GDB. Diese beiden aktiven Werkzeuge sind im Debug-Fenster zu sehen und können von dort aus auch gesteuert werden. Die Auswahl eines dieser Tools in diesem Fenster hat zwei Auswirkungen: Erstens kann der Output des Werkzeugs im Console-Femster dargestellt werden und zweitens erscheinen kontextspezifische Steuer-Buttons innerhalb des Debug-Fensters. Bild 8 zeigt den GDB-Session-Thread als gewähltes Werkzeug und die dargestellten GDB-spezifischen Buttons. Diese Buttons sind dieselben, die normalerweise verfügbar wären, um einen Debugger zu bedienen: Run, Stop, Step over, Step into, Step out of, etc.
Die Ausführung weiterführen oder anhalten: Um die Demo laufen zu lassen, wählt man das GDB-Programm im Debug-Fenster wie in Bild 8 gezeigt und klickt dann auf den grünen Pfeil „Go“. Um die Demo wieder anzuhalten, wählt man den Halt-Button. Über den in der Einleitung angegebenen Link erhält man weitere Informationen über den Funktionsumfang der Demo-Applikation.
Setzen von Break-Points: Breakpoints können im Editor-Fenster gesetzt werden indem man einfach doppelt auf den grauen Bereich links von der Zeile klickt, in der der Breakpoint gesetzt wird.
Anzeigen und Editieren von Variablen: Das Variablen-Fenster kann benutzt werden, Variable in der erwarteten Weise zu „beobachten“. Ein Beispiel: Die Demo-Applikation kreiert mehr als 20 Echtzeit-Tasks. Um zu sehen, welcher Task zu einer bestimmten Zeit ausgeführt wird, wird die Variable pxCurrentTCB zur „Watch“-Liste hinzugefügt. (Bild 9).
Abschließen einer Debug-Session: Um eine Debug-Session abzuschließen wählt man einfach die GDB-Applikation im Debug-Fenster (Bild 8) und klickt auf den roten Button „Terminate“. Ähnlich wählt man das OpenOCD-Tool im Debug-Fenster und klickt auf den Terminate-Button, um den OpenOCD-Server zu beenden (was erfolgt sein muss, bevor ein neues Binary in den Flash-Speicher des LM3S6965 programmiert wird).
Ergebnisbewertung zum Open-Source-Demoprojekt
Ich habe hier meinen ersten Versuch beschrieben, ein bestehendes FreeRTOS.org-Projekt zu konvertieren, damit es unter Einsatz der Eclipse-Workbench und OpenOCD aufgebaut, herunter geladen und debugged werden kann. Wie würde ich nun das Ergebnis bewerten?
Um dies zu beantworten, benötigt man als Referenz, eine kommerziell verfügbare IDE, mit der Eclipse verglichen werden kann. CrossWorks ist eine recht preisgünstige IDE, die ebenfalls die GCC-Compilierwerkzeuge benutzt. Sie ist deshalb ein geeigneter Kandidat für einen Vergleich (Tabelle 1).
Anwenderfreundlichkeit bei Installation und Konfiguration
CrossWorks installiert sämtliche erforderlichen IDE- und Compilier-Werkzeuge aus einer einzigen Installations-Executable. Das Verwenden einer Eclipse-Tool-Chain erfordert die Installation von Komponenten aus mehreren unterschiedlichen Quellen. Die Installation selbst war unproblematisch und schnell, aber erst nachdem ich die besten (oder zumindest meine bevorzugten) Installations-Packages gefunden hatte. Jetzt (wo ich diese Installations Pakete identifiziert habe) sollten auch zukünftige Upgrades kein Problem sein.
CrossWorks ist speziell als Embedded-Entwicklungsumgebung und zwar ausschließlich als solche entwickelt. Daher ist der erforderliche Konfigurationsaufwand nur minimal und darauf begrenzt, sicher zu stellen, dass das korrekte Chip- oder Board-Support-Installations-Package verwendet wird.
Eclipse ist ein universelles Werkzeug und muss zuerst konfiguriert werden, um sich wie ein Embedded-C-Entwicklungssystem zu verhalten. Wie bei der Installation erweist sich auch der Konfigurationsvorgang als recht geradlinig und unkompliziert, aber erst nachdem man präzise Instruktionen im Internet gefunden und befolgt hatte. Als Neuling stellte ich fest, dass die Menge an verfügbaren Informationen einen großen Zeitaufwand erforderte, um die für mich relevanten Informationen herauszufiltern.
Bewertung von Anwendung und Projektdefinition
CrossWorks enthält Wizards zur vereinfachten Erstellung von neuen Projekten. Der Build-Setup wird automatisch generiert, nachdem das Zielsystem ausgewählt wurde. Unterschiedliche Build-Konfigurationen (zum Beispiel Debug, Release, run from ROM, run from RAM etc.) können während der Projekt-Erstellung ausgewählt werden. Dies ist eine sehr leistungsfähige Funktion, obwohl das nachträgliche Editieren dieser Konfigurationen zunächst verwirrend sein kann (für diejenigen von uns, die niemals die vorhandene Dokumentation lesen).
Das auf Eclipse basierende Demo-Modell ist als ein „Standard-Make“-Projekt konfiguriert. Der Einsatz von Eclipse auf diese Weise befreit jedoch nicht von der Anforderung geeignete Make-Files und Linker-Scripts zu erstellen. Es bedeutet nur, dass das Projekt über einen Button in der Eclipse-Umgebung aufgebaut werden kann, anstatt die entsprechenden Befehle in der Command-Shell eintippen zu müssen. Der Aufbau (building) mit Eclipse bedeutet jedoch auch, dass Fehler oder Warnungen, generiert vom Build-Prozess, in einer anwenderfreundlichen Weise präsentiert werden, in der auch einfach navigiert werden kann.
Die alternative Methode beim Einsatz von Eclipse ist die Verwendung von „managed make“ anstatt von „standard make“. Die „Managed Make“-Projekterstellung ist dem CrossWorks-Prozess ähnlicher – mit einem Wizard, der einen durch die Schritte zur Erstellung mehrerer Konfigurationen führt. Allerdings, beim kreieren eines solchen Projekts, geriet ich in Schwierigkeiten zu definieren, welche Files ich in welchem Directory-Tree in den Build-Prozess einbinden wollte – da ich zu dieser Zeit nur mit „standard-make-Projekten zu tun hatte.
Ungeliebtes File-Management
Mein einziges echtes Problem mit Eclipse/CDT war die Art, wie es die Dateien handhabt, die in ein Build-Projekt eingebunden sind selbst wenn man die Standard-Make-Methode einsetzt. Die Position des Eclipse-Projekts muss sich an den „Wurzeln“ des Directory-Trees des Projekts befinden. Diese Tatsache macht seinen Einsatz nicht praktikabel für (wahrscheinlich) sämtliche professionellen Projekte an denen ich gearbeitet habe primär weil es dieWeise einschränkt, wie die in das Projekt eingebundenen Dateien strukturiert werden können. Im Besonderen erschwert es das gemeinsame Nutzen von Dateien in verschiedenen Projekten, ohne dass mehrfache Kopien des gemeinsamen Files vorhanden sind (unerwünscht).
Zum Beispiel, der primäre FreeRTOS.org-Download enthält Ports und Demos für sämtliche offiziell unterstützten FreeRTOS.org-Ports. Dies ist folgendermaßen organisiert:
FreeRTOS
¦
+-Demo
¦ ¦
¦ +-Common The demo application files that are used by all the ports.
¦ +-Dir x The demo application build files for demo x
¦ +-Dir y The demo application build files for demo y
¦
+-Source The FreeRTOS.org kernel code common to all ports
¦
+-Portable Processor specific code.
Deshalb wird der Makefile des Demo-Projekts, zum Beispiel LPC2106 in der Directory FreeRTOS/Demo/ARM7_LPC2106_GCC gefunden. Dies beinhaltet mehrere Quelldateien, die allen Demos in einem Verzeichnis gemeinsam sind (nicht nur der LPC2106-Demo), das höher angesiedelt ist als der Ort des Makefiles, das Verzeichnis FreeRTOS/Demo/Common. Es enthält auch die Quelldatei des FreeRTOS.org-Kernels in einemVerzeichnis, das wiederum höher angeordnet ist als das Directory, das das Makefile enthält, das Verzeichnis FreeRTOS/Source.
Die aktuelle CDT-Version kann diese Organisation der Verzeichnisse nicht verwenden. Sie kann nur Quelldateien lokalisieren (z.B. beim Debuggen oder wenn man auf einen Build-Fehler klickt), die unterhalb von ihr im Directory-Tree sind. Deshalb muss sich das Eclipse-Projekt auch in der „Wurzel“-Directory von FreeRTOS befinden. Dies ist jedoch nicht akzeptabel für einen Source-tree der mit vielen unterschiedlichen Compilierwerkzeugen aufgebaut ist und sich gemeinsame Dateien mit vielen anderen Projekten teilt.
Ich habe all das bereits gesagt und am Anfang dieses Artikels erwähnt, dass mir gesagt wurde, dass diese Nutzungsbarriere in der Version 4 von CDT beseitigt. Version 4 erlaubt es ein Projekt, mit Links zu Quelldateien, die sich außerhalb des Directory-Trees befinden zu erstellen und damit den Einsatz von wartbaren Projektstrukturen zu vereinfachen. Ich freue mich darauf, diese Embedded-Entwicklungsumgebung zu testen, mit der Vorfreude, dass sie ein effektives Interface für FreeRTOS.org-Anwender zur Verfügung stellt.
Das Navigieren zwischen Dateien in der Workbench kann ebenfalls mühselig sein, da ihr „navigation“-Fenster keine andere Möglichkeit bietet, als die Dateien in denVerzeichnissen, in denen sie auf der Hard-Disk gespeichert sind, anzuzeigen. Dies ist bei einem CrossWorks-Projekt völlig anders, dieses erlaubt mir Dateien von überall auf der Hard-Disk zu wählen und ermöglicht ihre Darstellung in logischen Gruppen.
Support und Robustheit der Open-Source-Tools
Es ist ein Merkmal von populären Open-Source-Projekten, dass es viele Leute gibt, die bereit sind schnell und begeistert praktischen Rat zu geben dies war auch hier meine Erfahrung. Aktive Foren, Newsgroups oder Mailing-Listen existieren für sämtliche Komponenten, mit denen die Webserver-Demo kreiert und aufgebaut ist.
CrossWorks hat bewiesen, dass es ein sehr zuverlässiges Werkzeug ist. Die IDE und das Debugging-Interface sind eng miteinander gekoppelt und arbeiten schnell und zuverlässig. Insgesamt fand ich die Open-Source-Tools zuverlässig und nützlich, bis auf einige Ausnahmen, die nachfolgend erläutert werden.
Das einzig wirkliche aber signifikante Problem, das ich bei der Eclipse-Workbench fand, trat auf, als ich versuchte, die Ausführung von einem externen Werkzeug aus abzubrechen, das über das Eclipse-Interface eingebunden war. Dies trat bei einigen Gelegenheiten auf einmal, beim Versuch OpenOCD zu schließen, bevor es komplett gestartet war, und einmal, beim Versuch einen „Build“-Vorgang abzubrechen, der die cs-make-Utility benutzte (CodeSource make). Bei diesen beiden Anlässen beendetet das externe Werkzeug weder die Aufgabe noch schloss es den Vorgang, sondern ging in einen „Zombie“-Zustand über. Trat dieser Zustand ein und versuchte Eclipse zu schließen resultierte dies in einem System-Crash.
Gelegentlich, etwa 10% der Zeit, versagte OpenOCD dabei, das target at main() zu stoppen wenn mit einer Debugging-Session gestartet wurde. Dies wurde einfach korrigiert, indem der Debugger gestoppt wurde und die Debug-Session erneut gestartet wurde ein sehr schneller Vorgang. OpenOCD gab auch einige Warnmeldungen an die Console aus, sowohl wenn es zum Flash-Programmieren als auch Debugging eingesetzt wurde. Dies scheint jedoch ohne Auswirkung auf die Funktion zu sein und durch die exzellente Unterstützung, die ich von Dominic Rath und Magnus Lundis erhielt, war ich in der Lage, einwandfrei festzustellen, dass diese Warnungen unkritisch waren.
Es sollte auch erwähnt werden, dass zum Zeitpunkt als die Cortex-M3-Erweiterungen für OpenOCD geschrieben wurden, dieses Tool noch nicht ausgereift war. Inzwischen sind sie in OpenOCD integriert, sind aber nach wie vor nicht so ausgereift wie das ARM7-Äquivalent.
Vorsicht muss man ebenfalls walten lassen, dass nicht eine installierte Firewall die internen TCP/IP-Verbindungen zwischen GDB und OpenOCD blockiert. Als ich OpenOCD das erste Mal startete, erhielt ich eine Warnung von der Windows-Firewall. Als diese Warnung abgeklärt war, musste ich OpenOCD schließen und erneut Öffnen, um eine Verbindung zu erhalten.
Gute Leistung, umfangreiche Dokumentation
Auf einem 1,7 GHz-Pentium-Prozessor mit 1 GByte RAM betrieben, fand ich die Leistung der Eclipse-Workbench mehr als ausreichend. OpenOCD war schnell sowohl beim Einschalten als auch beim Programmieren des Flashs des Microcontrollers. Dokumentation gibt es sicherlich mehr als genug, obwohl die kontextspezifische Hilfe für die CDT-Konfigurationen in einigen Punkten Schwächen aufwies.
Die Quintessenz
Meine Erfahrungen mit dem Setup und Einsatz dieser Tool-Chain waren positiv. Das einzige Problem ist das Projekt-File-Management, eine Schwierigkeit, die (hoffentlich) bald der Vergangenheit angehören wird.
Als Ingenieur schätzte ich die Einflussnahme, das Feedback und die Freiheit, die das Integrieren der unterschiedlichen Werkzeugkomponenten bietet dies gewinnt man jedoch auf Kosten einer Lernkurve, was nicht jedem Gefallen wird. Der Zeitaufwand zum Erlernen der Werkzeuge ist nämlich definitiv höher, als der für ein vergleichbares kommerzielles Produkt.
Einmal zusammengestellt, konnte die Tool-Chain verwendet werden, ein Projekt, wie den hier beschriebenen Embedded-Webserver, zu editieren, zu kompilieren, zu debuggen und zu warten. Es ist jedoch noch ein langer Weg hin, ähnlich eng gekoppelt zu sein und so problemfrei zu arbeiten wie kommerzielle Werkzeuge z.B. CrossWorks. Mit einer engagierten und stetig wachsenden Anwenderbasis jedoch wird Eclipse zweifellos auch weiterhin noch deutlich verbessert werden.
*Richard Barry ist Urheber des Open-Source-Betriebssystems FreeRTOS und leitet das Supportteam für OpenRTOS und SafeRTOS bei Wittenstein in Bristol.
Social Networks:
Themenverwandte Beiträge
Open-Source-Framework: Eclipse C/C++Entwicklungstools optimal nutzen
06.02.2007 - 2006 war ein Meilenstein für die Eclipse C/C++-Development-Tools (CDT). Fast jeder Projektbereich verzeichnete positive Wachstumsraten und über ein Dutzend Committer arbeitet am nächsten Release, das für Juni 2007 geplant ist. Was die Entwicklungswerkzeuge bieten, zeigt dieser Beitrag.
weiter
Mensch-Maschine-Schnittstellen: Lizenz für ARM-basierte Produkte in der Industrie
Mensch-Maschine-Schnittstellen: Lizenz für ARM-basierte Produkte in der Industrie
07.07.2009 - Wie können aktuelle Mikrocontroller und Entwicklungs-Tools das Design neuer und aufkommender Mensch-Maschine-Schnittstellen (Human Machine Interfaces) unterstützen? Eine Entwicklungsumgebung für Toshiba-ARM-MCUs bietet dazu einen Lösungsansatz.
weiter
Softwareentwicklungsumgebung: Embedded-Tuning für Eclipse
Softwareentwicklungsumgebung: Embedded-Tuning für Eclipse
28.08.2008 - Die Open-Source-basierte IDE Eclipse wurde eigentlich für die Java- und Desktop-Entwicklung geschaffen. Eine kostengünstige kommerzielle Anpassung schlägt jetzt eine neue Brücke für Embedded-Entwickler.
weiter
Kommentare zu diesem Artikel
Lizenzierung urheberrechtlich geschützter Artikel
Nutzen Sie diesen Artikel ID 219119 oder andere Fachinformationen für Ihr Marketing. Wir bieten Ihnen die Nutzungsrechte für Ihre Website, Ihren Newsletter oder Ihre Kundenzeitschrift. Für alle Fragen wenden sie sich bitte an Frau Maurer unter Tel. 0931 / 418-2888 oder unseren Content-Dienstleister www.mycontentfactory.de .
Artikel versenden
Druckversion
Artikel als PDF
Artikel Bewertung
- Der Originalbeitrag in englischer Sprache (PDF)
- Luminary: Details zum Luminary-Evaluierungskit
- Webserver-Implementierung auf FreeRTOS.org
- Sun: Link zur JRE-Installation
- Yagarto: Eclipse- und CDT-Downloads
- Entwicklungswerkzeuge ARM EABI GCC
- FreeRTOS.org: Zip-Datei zur Demo-Applikation Eclipse/Coretex
- Zur Homepage von FreeRTOS.org
- Zur Homepage von SafeRTOS
- Zur Homepage von High Integrity Systems
- Download OpenOCD (Open Chip Debugger)
- TCP/IP-Implementation von Adam Dunkels
- TCP/IP-Implementierung lwIP
- Yagarto: Ein neues Projekt in Eclipse erstellen
- Interview: Ralph Müller von der Eclipse Foundation im Gespräch
Open Source
Eclipse für Automotive und Mobile
Was passiert in der Eclipse Community aktuell bei Mobile und Automotive? weiter
Debugging von Embedded Linux-Anwendungen auf ARM-Prozessoren
Embedded Linux als Betriebssystem für moderne ARM-Prozessoren? Keine schlechte Idee! Aber da Linux ein Multitasking-Betriebssystem ist, verkompliziert sich das Debuggen von Prozessen. Wirklich?
Embedded Linux als Betriebssystem für moderne ARM-Prozessoren? Keine schlechte Idee! Aber da Linux ein Multitasking-Betriebssystem ist, verkompliziert sich das Debuggen von Prozessen. Wirklich?
Mobile Geräte auf der Grundlage der Freescale i.MX-Plattform
Eine Gemeinschaftslösung für die Bewältigung der zunehmenden Komplexität von Geräten, die sich auf die Produktivität und den Zugang zu Debug-Ports auswirkt und zusätzliche Kosten verursacht.
Eine Gemeinschaftslösung für die Bewältigung der zunehmenden Komplexität von Geräten, die sich auf die Produktivität und den Zugang zu Debug-Ports auswirkt und zusätzliche Kosten verursacht.
Hardware-Entwicklung mit den Debug-Tools von Wind River
Hardware-Ingenieure müssen PCBs rasch debuggen, um zuverlässige Plattformen für die Software-Entwicklung bereitzustellen
Hardware-Ingenieure müssen PCBs rasch debuggen, um zuverlässige Plattformen für die Software-Entwicklung bereitzustellen
Multicore- und Multiprozessor-Debugging vereinfachen
Optimale Nutzung der JTAG Scan Chain zum Debuggen mit dem Workbench On-Chip-Debugging
Optimale Nutzung der JTAG Scan Chain zum Debuggen mit dem Workbench On-Chip-Debugging
Copyright © 2012 Vogel Business Media
(nicht registrierter User)