{"id":10158,"date":"2015-02-25T15:27:48","date_gmt":"2015-02-25T14:27:48","guid":{"rendered":"http:\/\/cogito-ergo-blog.de\/blog\/?p=10158"},"modified":"2015-02-25T15:27:48","modified_gmt":"2015-02-25T14:27:48","slug":"eclipse-cdt-zur-pic-pic32-entwicklung-nutzen","status":"publish","type":"post","link":"https:\/\/cogito-ergo-blog.de\/blog\/2015\/02\/25\/eclipse-cdt-zur-pic-pic32-entwicklung-nutzen\/","title":{"rendered":"Eclipse CDT zur PIC \/ PIC32 Entwicklung nutzen"},"content":{"rendered":"

Will man auf den Micro-Controllern der PIC Familie von Mircochip Software, so tut man sich auf der Suche nach einer professionellen IDE schwer. Vor allem wenn es nichts kosten soll und man den Komfort von Eclipse gewohnt ist.<\/p>\n

Es gibt die MPIDE und MPLAB X, letzteres auf Basis von Netbeans und daher wahrscheinlich recht m\u00e4chtig (ich hatte noch keine Gelegentheit es zu testen).<\/p>\n

Was die Suche zus\u00e4tzlich erschwert ist die Vielfalt der angebotenen Boards und Prozessortypen. Was in der AVR-Welt noch halbwegs \u00fcberschaubar ist, ist bei Microchip doch recht un\u00fcbersichtlich bzw vielf\u00e4ltig.<\/p>\n

Gut gefallen hat mir da UECIDE<\/a>. Sie bietet mit ihrem Plugin-Manager genau das Mittel schnell und einfach f\u00fcr unterschiedliche Boards und unterschiedliche “Cores” (Laufzeit-Umgebungen) eine Umgebung zusammen zu stellen. Die notwendigen Source und Toolchains werden einfach herunter geladen und im Homeverzeichnis “installiert”. Selbst die “Uploader” zum Flashen der Boards sind direkt dabei.<\/p>\n

Nat\u00fcrlich kann man diese IDE trotzdem niemals mit der M\u00e4chtigkeit einer Eclipse vergleichen und auch das Tooling (SVN, GIT, Debugging, Code Analyse usw.) ist bei weitem nicht so gut.<\/p>\n

Wenn man allerdings eine reine CDT-Eclipse (Kepler) installiert und die Toolchains und Board-Definitionen von UECIDE mitbenutzt, dann hat man sehr schnell eine lauff\u00e4hige Eclipse-Umgebung mit allem Komfort.<\/p>\n

<\/p>\n

Folgende Schritte sind nacheinander durch zu f\u00fchren:<\/p>\n

UECIDE installieren<\/h2>\n

Zun\u00e4chst installiert man f\u00fcr sein Board die Toolchain (den Compiler) und den core. In meinem Fall z.B. das Pinguino Board und den chipKit-Core.<\/p>\n

Hat man in der UECIDE einen lauff\u00e4higen Build, so kann man im Men\u00fc mit “Help” -> “Debug” -> “Debug Console” eine Konsolenansicht \u00f6ffnen, die den kompletten Build Ablauf zeigt. Dieses Log ist n\u00fctzlich, wenn wir sp\u00e4ter die genauen Optionen und DEFINES in der Eclipse nachbauen wollen. Also am besten raus kopieren und in einem Editor-Fenster bereithalten.<\/p>\n

Eclipse f\u00fcr C++\/C Entwickler installieren<\/h2>\n

Einfach herunterladen und entpacken. Dann neues “Core”-Projekt anlegen “C++ Projekt” , Static Library, Empty Projekt. Namen am besten so w\u00e4hlen, wie der core heisst z.B. “chipKit”.<\/p>\n

Weiter auf “Cross Toolchain” und dann bei “Cross GCC Command” einen Compiler der UECIDE eintragen:<\/p>\n

\"Bildschirmfoto<\/a>Hier also z.B. den pic32 Compiler.<\/p>\n

Um sp\u00e4ter leichter auf die Include Pfade referenzieren zu k\u00f6nnen setzen wir noch eine Build-Variable: “pictools” (oder \u00e4hnlich) mit Verweis auf den Pfad wie oben.<\/p>\n

Anschliessend legen wir das erste Projekt an f\u00fcr den Core also die Laufzeitumgebung des Boards. Neu -> C++ Projekt -> Statische Library. Dann importieren wir den Core, den wir verwenden wollen (hier chipKit) in den Workspace. Die Cores liegen alle im Homeverzeichnis unter “.uecide\/cores”.<\/p>\n

Dann im Projekt die Eigenschaften \u00f6ffnen und unter C\/C++ Build -> Settings den Compiler f\u00fcr C \/ C++, den Linker und den Assembler so einstellen, wie er auch in der UECIDE aufgerufen wurde. Dazu schauen wir einfach in das Debug Console Log der UECIDE (siehe oben), welches wir im Editor aufbewahrt haben.<\/p>\n

Damit der Core erfolgreich kompiliert, m\u00fcssen wir das Board noch festlegen. Dazu importiert man das Board, welches genutzt werden soll direkt in das Core Projekt in Eclipse unter “board”.<\/p>\n

Bei den Include-Pfaden muss das Board-Verzeichnis und das api Verzeichnis des Cores mit auf die Liste:<\/p>\n

\"Bildschirmfoto<\/a>Einstellungen sind f\u00fcr C Compiler und C++ Compiler und die anderen Werkzeuge jeweils getrennt vorzunehmen.<\/p>\n

Am Ende des Builds hat man dann eine libCore_api.a vorliegen. Genau die Library f\u00fcr den eingestellten Core und das Board, welches unsere Anwendung nutzen will.<\/p>\n

Applikations-Projekt erstellen<\/h2>\n

Als n\u00e4chsten Schritt machen wir das gleiche nocheinmal und erstellen diesmal aber ein normales Projekt (nicht Statische Library). Wieder m\u00fcssen alle Compiler und Linker Einstellungen angepasst werden. Am Ende des Artikels gibts f\u00fcr meine Test-Umgebung ein Archiv mit fertigem Beispiel. Man muss nur noch die Pfade anpassen.<\/p>\n

Linker-Scripts beachten<\/h3>\n

Beim Erstellen des Executables f\u00fcr einen Controller ist es besonders wichtig, an welchen Adressen was im Binary landet. Das Speicher-Layout ist von jedem Board \/ jedem Controller fest vorgegeben. Dies steuert man \u00fcber sogenannte Linker-Scripts.<\/p>\n

Auch hier gilt wieder die Regel: alles genauso \u00fcbernehmen, wie es im Debug Console Log der UECIDE nachlesbar ist. Die passenden Linker-Scripte sind im Core Projekt \/ dem Board-Verzeichnis bereits enthalten.<\/p>\n

Main-Datei<\/h3>\n

Entgegen den \u00fcblichen .pde oder .ino Dateien mit den typischen Funktionen setup() und loop() benutzt man eine ganz normale C oder C++ Datei, die eben diese Funktionen zur Verf\u00fcgung stellt. Der Startup-Code des Cores findet sie dann von alleine.<\/p>\n

Will man die \u00fcblichen API verwenden, dann darf der “#include <WProgram.h>” oder #include <Arduino.h>” Befehl nicht fehlen, weil Eclipse den eben nicht wie andere IDEs automatisch hinzuf\u00fcgt.<\/p>\n

Wenn man das alles beachtet, hat man in 30 min eine lauff\u00e4hige Eclipse Umgebung f\u00fcr nahe zu alle Boards \/ Cores, die auch die UECIDE unterst\u00fctzt. Eclipse ist im Editor, im Source-Code-Browsing, in der Anbindung von SVN oder Git, Refactoring, Auto-Completion usw. der UECIDE nat\u00fcrlich haushoch \u00fcberlegen.<\/p>\n

Debugging<\/h2>\n

Die K\u00fcr stellt jetzt noch das Debugging dar. Mit dem passenden Adapter (pickit 3 oder pickit 2) und dem richtigen GDB bzw. Eclipse-Plugin, kann man seine Anwendung sogar direkt auf dem Controller debuggen. Davn vielleicht mehr in einem anderen Artikel.<\/p>\n

Downloads<\/h2>\n

Core-Projekt mit dem Pinguino-Micro-Board und dem chipKit-Core: chipKit-Core<\/a><\/p>\n

Blink Beispiel Projekt, welches den chipKit-Core verwendet: Blink<\/a><\/p>\n

Upload des Codes auf das Board<\/h2>\n

Um ein passendes Hex-File zu bekommen, muss vom erzeugten ELF File eine HEX Datei erzeugen. Auch hier hilft wieder ein Blick in das Debug-Console Log der UECIDE. So konfiguriert man beim Applikations-Projekt noch einen “Post-Build”-Schritt und erzeugt sich so das Hex-File.<\/p>\n

Das Uploaden kann man entweder gleich ebenfalls in den Post-Build eintragen, oder man definiert eine “External Tool” Run-Configuration, so dass man das Uploaden leicht \u00fcber einen Eclipse Men\u00fc Eintrag erreichen kann.<\/p>\n

\"Bildschirmfoto<\/a> Viel Spass mit dem Beispiel. Freu mich \u00fcber R\u00fcckmeldungen.<\/p>\n

Ach ja, inspiriert hat mich vor allem die Seite von Krl3<\/a> und HJFs Blog<\/a>.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Will man auf den Micro-Controllern der PIC Familie von Mircochip Software, so tut man sich auf der Suche nach einer professionellen IDE schwer. Vor allem wenn es nichts kosten soll und man den Komfort von Eclipse gewohnt ist. Es gibt … Weiterlesen →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/posts\/10158"}],"collection":[{"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/comments?post=10158"}],"version-history":[{"count":4,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/posts\/10158\/revisions"}],"predecessor-version":[{"id":10167,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/posts\/10158\/revisions\/10167"}],"wp:attachment":[{"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/media?parent=10158"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/categories?post=10158"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/tags?post=10158"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}