Hi, Was sollte man für eine vernünftige Entwicklungsumgebung, inklusive IDE, Compiler, Linker und Debugger, ausgeben? Lohnt sich sowas teures wie IAR oder Keil ARM-MDK, oder reicht irgendwas mit GCC/Eclipse/OpenOCD auch? Was würdet ihr nehmen, das möglichst stressfrei und gut funktioniert?
Hey, also ich benutze die Lite-Version von Atollic TrueSTUDIO und bin damit ganz zufrieden. Es ist zwar etwas nervig hin und wieder die Werbung für die Vollverion weg zuklicken. Die Entwicklungsumgebung funktioniert direkt und man hat keine probleme mit dem erstellen von Makefils oder Linkereinstellung etc. hier der Link für den download: http://atollic.com/index.php/download/downloadstm32 Viel Spass
Ich kann mich meinen Vorredner nur anschließen. Es gibt hier auf der Seite auch recht gute Tutorials/Wikieinträge für STM32 (Wenn ich mich nicht irre sogar welche speziell zu Attolic)
Lukas schrieb: > Hey, > > also ich benutze die Lite-Version von Atollic TrueSTUDIO und bin damit > ganz zufrieden. Danke, das schaue ich mir gleich mal an. Welches Debug-Interface benötigt es? Kann ich auch einen IAR J-Link anschließen? (Hab noch einen hier rumliegen)
OpenOCD würde ich im Firmenumfeld auf keinen Fall einsetzen. Dafür waren zu viele Änderungen nicht abwärtskompatibel, und alte Konfigurationen haben aufeinmal nicht mehr funktioniert Denkbar wäre J-Link von Segger, GCC und Eclipse. Aber auch in Eclipse muß man die Projekte erstmal per Hand erstellen. Letztlich entscheidet die Zeit und wie häufig man Applikationen entwicklet. entweder du bist geübt im Umgang mit Eclipse und GCC. Oder du entscheidest dich für eine komplette proprietäre IDE. Ich habe ganz gute Erfahrungen mit dem Crossworks 1.7 for ARM von Rowley gemacht. Mit Hilfe einer kompletten IDE ist der Einstieg leichter. Man muß sich nicht sofort um alle Einzelheiten wie z.B. den Stack aktiv kümmern, das passiert automatisch. Auf lange Sicht kommt man da natürlich nicht drumherum, auch über die versteckten Sachen besser bescheid zu wissen. Andererseits gibt es viele Erweiterungen für Eclipse wie z.B. svn anbindung oder stylechecker, aber man muß von Anfang an mit den Startup-Code und den Linker-Skripts tief in der Materie stehen, um z.B. den Stack richtig anzulegen.
Ich habe einen OpenOCD im Einsatz. Ja, das Stimmt dass zu Anfang die immer wieder die Konfiguration über den Haufen geschmissen haben, aber in den letzten 2 Jahren hat sich das stabilisiert. Es spricht somit nichts mehr gegen die Eclipse/OpenOCD Lösung. Ich habe neulich wieder eine Ecpilse-Umgebung eingerichtet und läuft gut.
Ich habe in letzter Zeit auch den Einstieg in STM32 und LPC17xx gemacht. Am Anfang ist Atholic bzw. CodeRed ganz gut. Eins bleibt aber bei allen. Es basiert alles auf gcc und zum debuggen gdb. Für fertige Projekte würde ich immer mit makefile's arbeiten und die Projektverwaltung links liegen lassen. Das funktioniert dann auch noch nach Jahren und dem x'ten Update von Eclipse. Wenn dann auch noch die Besonderheiten der newlib (printf und consorten) berücksichtigt werden, spielt es am Ende keine Rolle mehr welcher gcc da drüber läuft. Die Unterschiede sind marginal. Das selbe makefile kann eigentlich fast unverändert für die ganzen Derivate benutzt werden die auf gcc beruhen. Und ein mit CrossWorks übersetztes Projekt z.B. kann problemlos mit CodeRed gedebuggt werden. Also alles in allem recht universell, wenn man die ersten Hürden genommen hat und sich im makefile auskennt. Dann geht sogar das Neuerstellen von Projekten schneller von der Hand als interaktiv in den vielen Eclips-Dialogen Includepfade u.s.w. zu setzten.
Im Prinzip stimme ich Jürgen Liegner schon zu...aber ist das nicht arbeiten wie in der Steinzeit? Eine gute Lösung ist auf jeden Fall Rowley Crossworks + Segger J-Link. Wenn es auch teurer werden darf, dann auch gerne als IDE IAR oder Keil.
Naja, was heisst Steinzeit. Wenn man wie ich im Laufe der Jahre Turbo C, Borland C++, Zortech, Watcom dann VC in allen Varianten unter Windows, gcc für Linux Mac und Adroid, gcc für avr, Assembeler für 8051, php u.s.w durch hat, dann hat man längst die Nase voll von den ganzen IDE's. Ich brauche zum Arbeiten eine Editor und ein paar Scripte. Da reicht zum Einrichten simples Kopieren. Ich benutze auch noch cvs. Das deckt meine Bedürfnisse ab und ist auf der Kommandozeile auf allen Systemen gleich. Sicherlich ist manches in Eclipse recht net, aber ich habe häufig auf Linuxservern ohne Grafic zu tun, da nützt eine Ide auch nichts. Ich will hier keinen Grabenkrieg lostreten, jeder handhabt das wie er will. Ich wollte nur andeuten, dass es auch ohne dem ganzen GUI-Geraffel am Ende machmal einfacher ist. Für den Cortex M3 kann man mit dem gcc nicht viel verkehrt machen und ein Projekt was mit einem makefile läuft, lässt sich in Eclips auch gut handhaben wenn man will.
Ich nutze das auch so wie Jürgen, ich habe damals tief angefangen, nur wenige Vorlagen gab es. Heute gibt es fast alles auf den Silbertablett, siehe Artikel STM32 und auch Blink-LED Demos für Eclipse/GCC. Es ist wirklich leichter sich das Makefile zu kopieren und die LD Datei anpassen. So kann man z.B. Dateien, die man nicht übersetzen will einfach in der makefile auskommentieren. In anderen IDE's sind die in der IDE registriert und muss man extra dort löschen oder wo anders hin verschieben. Es ist zwar eine für den Anfänger konfuse Text-Datei, dennoch bietet dieses System wirklich alle Möglichkeiten. Bis hin zur wirklich freien uneingeschränkten Speicheraufteilung. Und der Eclipse Editor ist wirklich einer der aller besten, ich kenne keinen Editor der besser für Programmierung geeignet ist.
Vielen Dank für eure zahlreichen Antworten. Guest schrieb: > Wenn es auch teurer werden darf, dann auch gerne als IDE IAR oder Keil. Das sehe ich auch so. Auf Eclipse/GDB/OpenOCD und Makefile-Gefrickel würde ich gern verzichten, schwanke aber noch zwischen Keil und IAR. Mit beiden habe ich schon positive Erfahrungen gemacht. Den IAR nutzen wir in einem relativ großen Projekt für LPC2378'er. Mit Keil µVision hatte ich vor Jahren Kontakt in einem kleinern Projekt für den C166. Preislich liegen beide Toolchains, in ausreichender Ausstattung, etwa so um die 6000 Euronen. Man munkelt, der IAR erzeuge kompakteren und schnelleren Code. Aber kennt ihr vielleicht noch Argumente, die für oder gegen Keil und/oder IAR sprechen?
hallo, wenn die iar workbench ohnehin schon im einsatz ist dann nimm doch diese! gruss gerhard
Leprechaun schrieb: > Das sehe ich auch so. Auf Eclipse/GDB/OpenOCD und Makefile-Gefrickel > würde ich gern verzichten, schwanke aber noch zwischen Keil und IAR. Das sehe ich auch so. Lade Dir die EVA-Versionen runter und nimm Dir Zeit zum spielen. Ich würde zu Keil tendieren, subjektiv. Das ist aber sowas wie die Frage nach AVR oder PIC ;-)
Rein vom Handling her ist der IAR prima, einfacher geht es fast schon nichtmehr. Und debuggen ist auch deutlich einfacher als erst endlos an irgendwelchen gdb-Einstellungen rum zu frickeln. Was mich aber wirklich am IAR nervt, ist das er irgendwie nie so richtig stabil läuft. Ich habe schon einige Sachen mit verschiedenen STM32 (jeweils immer die F103xxx-Familie) mit dem ST-Link als JTAG-Adapter gemacht, aber irgendwie hängt sich der JTAG immer mal wieder weg. Manchmal so schlimm, das man den Rechner neu starten muss, oft reicht es aber den ST-Link ab- und wieder anzustecken.... Sowas ist bei einem teuren Tool wie dem IAR einfach nicht akzeptabel.
Ronny schrieb: > Was mich aber wirklich am IAR nervt, ist das er irgendwie nie so richtig > stabil läuft. Ich habe schon einige Sachen mit verschiedenen STM32 > (jeweils immer die F103xxx-Familie) mit dem ST-Link als JTAG-Adapter > gemacht, aber irgendwie hängt sich der JTAG immer mal wieder weg. > Manchmal so schlimm, das man den Rechner neu starten muss, oft reicht es > aber den ST-Link ab- und wieder anzustecken.... Ist sicher kein generelles Problem und kann viele andere Ursachen haben.
Leprechaun schrieb: > Aber kennt ihr vielleicht noch Argumente, die für oder gegen Keil > und/oder IAR sprechen? Aus meiner Sicht: Eindeutig pro Keil, denn dort sind die Original-Tools von Arm dabei - und das sehe ich als Vorteil an. Man kann die Tools ja auch ganz bequem per Batchdatei aufrufen. Das ist im Prinzip das gleiche wie es Jürgen Liegner tut, wenngleich ich eine erhebliche Abneigung gegen 'Make' habe. Ich hab auf meinem PC in der Firma ein halbes Dutzend "Make.exe" drauf - jedes zu einem anderen System gehörig und keines versteht die Syntax der anderen. Kurzum, Make kann ICH auf einem Windows-PC nicht verwenden, da es davon zu viele gibt. Deswegen die Batch-Datei, die ist simpel, eindeutig und leicht zu handhaben. Jürgen Liegner: > dann hat man längst die Nase voll von den ganzen IDE's. Ja, sehe ich ähnlich. Allein schon solche simplen Dinge wie der Wunsch, seinen eigenen Startup-Code verwenden zu wollen, scheitern bei den meisten IDE's kläglich, weil man es ohne Sherlock Holmes nicht herausfindet, wo man der IDE die Gurgel umdrehen muß, damit sie das macht, was man tatsächlich will. W.S.
Meine gcc make.exe hat ich in gmake.exe umbenannt, denn sonst mag das mit Delphi nicht. In Eclipse hab ich auch den gmake.exe eingetragen, dann klappt das prima. Da ich einen eigenen Start-Up Code habe und Bootloader in den gleichen Sourcen gleich mit drin ist, kann ich das mit dem makefile und Linkerscript einstellen. Die meisten IDE's scheitern da kläglich. Ist zwar etwas mehr Wissen und fummelei nötig bis das mit GCC tut, aber dafür ist wirklich alles möglich. Abgesehen davon kann ich mir für das Hobby zu Hause keine 5KEur IDE zulegen. Ist Keil ursprünglich nicht eine deutsche Firma gewesen? Wäre auch ein Pluspunkt für Keil, damit das eigene Land unterstützt wird.
Ronny schrieb: > Rein vom Handling her ist der IAR prima, einfacher geht es fast schon > nichtmehr. Und debuggen ist auch deutlich einfacher als erst endlos an > irgendwelchen gdb-Einstellungen rum zu frickeln. > > Was mich aber wirklich am IAR nervt, ist das er irgendwie nie so richtig > stabil läuft. Ich habe schon einige Sachen mit verschiedenen STM32 > (jeweils immer die F103xxx-Familie) mit dem ST-Link als JTAG-Adapter > gemacht, aber irgendwie hängt sich der JTAG immer mal wieder weg. > Manchmal so schlimm, das man den Rechner neu starten muss, oft reicht es > aber den ST-Link ab- und wieder anzustecken.... > > Sowas ist bei einem teuren Tool wie dem IAR einfach nicht akzeptabel. IAR mag schon ein teures (und gutes Tool) sein, das allerdings mit der billigsten der billigen Hardware Komponenten zu verheiraten ist schon so ne Sache. Schon mal daran gedacht, dass die Naeger nicht von IAR sondern vom ST-Link kommen koennten? Da ist mir der gute J-Link doch lieber. Robert
Wie viel zeit wollen sie brauche für setup ? Ist das für hobby oder profi ? Ich habe 8€ bezahlt http://www.watterott.com/de/STM8S-Discovery?x08c73=sge3ko5spvvk5n83gq5gsisks4 Beitrag "Use your STMxx-Discoveryboard as JTAG (SWD)" http://www.versaloon.com/bbs/viewtopic.php?f=2&t=17 Und dann Codesourcery Arm Eabi compiler Und CodeBlocks oder Eclipse mfg Bingo Dänemark
6KEUR = 1 Mann/Monat. Muss jeder selbst entscheiden, ob er nicht lieber doch Eclipse nimmt anstatt 6KEUR (je Arbeitsplatz!). Zumal die Einarbeitung in den Prozessor gleich ist, bzw. ohnehin nicht einspart. Ich könnte bei der Einrichtung von Eclipse & Co helfen (PN schreiben).
Moin, Ihr Habt noch CooCox vergessen. Ich weiß Chinesen, aber als Eclipse IDE nicht verkehrt zumindest fürs Hobby. MfG Tec
Wie gut ist die OOCD J-Link support ? Für hobby ist auch die J-Link EDU für einer gute preis ~ 70€ glaube ich. Andere ARM-Jtag debuggers (FTDI). Ich habe auch diser (Kein SWD, nur Jtag) , Ich brauchte das für meiner erste STM8S konvertierung zum Versaloon. http://www.watterott.com/de/SignalyzerLITE Aber wollte diser kaufen , ob ich kauft heute. (Kein SWD , nur Jtag) Die uart konverter etc ... sind sehr brauchbar zum entveklung http://www.watterott.com/de/Flyswatter mfg Bingo
Den STLinkV2 fuer etwa 30 Euro hat bisher keiner genannt...
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.