Hallo Leute, ich bin im Bereich Mikrocontroller noch nicht wirklich erfahren, aber auf jeden Fall lernbegierig und motiviert. Ich hätte ein paar Fragen über Zusammenhänge, die sich mir die letzte Zeit aufgedrängt haben und ich hoffe, dass mir hier weiter geholfen werden kann. Vielleicht könnt ihr mir ja auf die Sprünge helfen. Ich versuche gerade, eine IDE einzurichten, mit der ich auf meinem Cortex-M3 u.a. debuggen kann. Soweit habe ich das nun hinbekommen - und zwar mit folgenden Bestandteilen (dahinter meine Deutung, was wofür zuständig ist. Bitte verbessert mich, falls etwas falsch sein sollte): - Eclipse CDT: der intelligente Code-Editor für C/C++ (dank CDT) - GDB-Server: übersetzt die GDB-Kommandos in JTag-/JLink-Kommandos - Yagarto: liefert GCC, GDB, make - kein cygwin dafür notwendig Ich habe bereits ein Beispiel-Programm von der Yagarto-Website auf meinem Cortex-M3 (IAR-Evaluationboard) erfolgreich debuggen können. Nun möchte ich mich in den nächsten Wochen darin einarbeiten, das freie RTOS ecos auf den Controller zu portieren. Laut ecos-Website ist für Download & Installation von ecos auf Windows Cygwin notwendig. Ich habe nun via Cygwin ecos heruntergeladen und zusätzlich noch das ecos-Toolchain "arm-eabi" was u.a. für Cortex-M geeignet sein soll. Nun meine eigentlichen Fragen: 1) Kann ich mit diesem ecos-Toolchain nun all das, was ich mit Yagarto auch kann? Wahrscheinlich sogar mehr? Sind gcc, gdb, make etc. bei Yagarto & ecos-Toolchain identisch bzw. worin liegt der Unterschied? 2) Stimmt folgende Annahme: Cygwin selbst bietet mir u.a. einen gcc. Das ecos-Toolchain für arm-eabi bietet mir auch einen gcc, jedoch speziell für diverse Ziel-Architekturen (Cortex-M, ARM9, ...)? 3) Könnte ich bei meinen Bedürfnissen (ecos auf Cortex-M3 portieren) mit Yagarto überhaupt etwas anfangen? Ich kann mir vorstellen, dass die meisten Fragen für euch etwas seltsam klingen, aber wie gesagt bin ich ziemlich neu in dem Gebiet. Vielleicht erbarmt sich ja der Ein oder Andere und hilft mir beim Einstieg :) Viele Grüße, Lukas R.
Hi, der Hauptunterschied der beiden Toolchains dürften die Versionsnummern der enthaltenen Tool sein (Yagarto hat wohl die aktuelleren). Make, cp, ... gehören nicht direkt zur Toolchain. Yagarto liefert Versionen mit, die direkt unter Windows laufen. eCos benutzt die Versionen von Cygwin. Der in Cygwin enthaltene gcc ist zum erzeugen von x86 Code, je nach Installation für Windows und/oder Linux. Prinzipiell sollte sich eCos auch mit Yagarto vertragen, die config scripte, make files etc. sind aber auf Cygwin ausgelegt. Du müßtest also für Yagarto vieles von Hand selber machen. Btw. Muß es unbedingt eCos sein? FreeRTOS (http://www.freertos.org) dürfte wesentlich einfacher handhabbar sein, insbesondere in Verbindung mit Yagarto. Und läßt sich zum Testen auch für Windows kompilieren (MSVC/MinGW). PS: Yagarto + Eclipse geht am einfachsten via GNU ARM Eclipse Plugin (http://gnuarmeclipse.livius.net)
Vielen Dank für deine Antwort :) > Make, cp, ... gehören nicht direkt zur Toolchain. Was genau gehört aber dann zum Toolchain? > Der in Cygwin enthaltene gcc ist zum erzeugen von x86 Code, je nach > Installation für Windows und/oder Linux. Okay :) ...demnach erzeugt der im ecos-Toolchain enthaltene GCC nicht x86-Code, sondern Code speziell für die unterstützten Architekturen wie bspw. Cortex-M3, richtig? > Btw. Muß es unbedingt eCos sein? FreeRTOS (http://www.freertos.org) > dürfte wesentlich einfacher handhabbar sein, insbesondere in Verbindung > mit Yagarto. Und läßt sich zum Testen auch für Windows kompilieren > (MSVC/MinGW). FreeRTOS und ecos weisen jedoch schon einige Unterschiede auf, wie ich das mitbekommen habe. Besonders bzgl. Treiber und Stacks (TCP/IP, ... hat ecos einiges zu bieten.
Weiß evtl. jemand mehr zu meinem letzten Kommentar?
Ich hatte vor Jahren mal versucht, dieses Ecos zum Laufen zu bringen - ohne jeglichen Erfolg. Hintergrund war, daß ich mir dachte es evtl. auf die Fujitsu FR Architektur portieren zu können. Aber der Aufwand lohnt überhaupt nicht. Nach meiner Meinung ist es allemal effektiver, sich ein eigenes kleines OS zusammenzuschreiben, als solche angeblich universell einsetzbaren tollen OS zur tatsächlichen Benutzbarkeit zu bringen. Wenn du nen ARM oder Cortex mit Firmware füllen willst, dann mach dir was Eigenes oder guck bei Keil nach deren Mini-Scheduler (Name fällt mir grad nicht ein), aber verplempere deine Zeit nicht mir solchen Gurken wie Ecos. Ich hatte voriges Jahr auch mal (von den Siemens-Leuten glaub ich) eine Demo von einem 'überragend guten' OS namens "Euros" übergeholfen bekommen, aber auch dieses OS ist eine Krücke, so wie eigentlich alle anderen auch. Momentan hab ich grad einen Blick in das "NuttX"-OS getan, eigentlich der gleiche Krempel, bei dem man sich fragt, _wozu eigentlich_ haben all diese Programmierer sowas mit viel Fleiß zusammengeschrieben? Ganz viel vergeudeter Programmiererschweiß. Mal ne ganz einfache Frage meinerseits: WOZU willst du dir solches Zeugs um die Ohren hauen? Wenn du dein IAR-Evalboard mit irgendwas zum Laufen bringen willst, und dir dabei sowas wie ein Betriebssystem vorschwebt, dann definiere doch erstmal, was dieses BS denn eigentlich können soll, wie sein API aussehen soll und wie die Executables der zugehörigen Applikationen aussehen sollen. Ich hab das am Beispiel eines älteren ARM7TDMI mit der Lernbetty hier im Forum mal durchexerziert: Eine Art Basisprogramm (= Betriebssystem), was die vorhandene Peripherie bedient, dazu ein API, das die SVC-Funktionalität der ARM's benutzt (gibt es ähnlich übrigens auch auf anderen 32 Bit uC) und Apps, die sich unabhängig vom BS programmieren lassen. Wenn dein System einen Massnspeicher (SD Karte z.B.) hat, dann wäre im BS nur noch ein Programmlader (zusammen mit einem gut definierten Exe-File-Format) und eine Art Navigator oder Programmfinder oder ein 'Command.com' o.ä. nötig und du hast ein tatsächliches kleines BS. W.S.
alle anderen sind doof, nur W.S. nicht.
Hallo, bin gerade auf diese Diskussion gestossen, ist zwar schon alt, aber die Fragen blieben unbeantwortet. eCos kann wirklich sehr hilfreich sein. Es hat so viele Funktionen und ist für so viele Plattformen und Prozessoren bereits verfügbar, so etwas schreibt man nicht schnell mal selber. Eine Portierung auf einen Prozessor, der noch nicht unterstützt wird, ist natürlich aufwändig, so etwas überlässt man wohl besser einem Spezialisten Aber für Echtzeitanwendungen ist es ideal; auch einen kleineren Treiber selbst entwickeln ist kein Problem. Einen Treiber für Ethernet, USB oder ähnlich Komplexem halte ich aber für einen Anfänger als nicht machbar. Toolchain ist so ein Thema....es gibt zwar eine Beschreibung für den Open Source Weg, aber der ist steinig! http://ecos.sourceware.org/getstart.html diese Anleitung hält meistens nicht Schritt mit den Tool-Version, auf die sie verweist. Neue Compiler Versionen benötigen dann Anpassungen im Source-Code und in den Kommandofiles, daran kann man sich die Zähne ausbeissen. Es geht auch einfacher mit fertigen Toolchains! http://tiprom.itrgmbh.com/projects/itr-products-ecos-toolchain Diese Toolchain nimmt einen das Installationschaos ab und bietet noch weitere Features, die das Leben sprich das Programmieren und Debuggen einfacher machen!
Wieso tut man sich sowas überhaupt an? Das ist so also wollte man an einem Auto einen Reifen wechseln und fängt erstmal damit an nach dem Erz zu buddeln um sich das Werkzeug selber zu gießen... Es gibt genug Toolchains die out of the box arbeiten, z.B. emIDE.org oder jede Codesize limitierte Version einer kommerziellen Toolchain wie IAR, Keil, usw. Als Betriebssystem dann z.B. die Trial Version von Segger embOS. Das gibts für alle gängigen CPUs mit fertigen Startprojekten, die auch out of the box laufen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.