Hallo, ich soll eine ARM/Cortex Entwicklungsumgebung für meine Firma einkaufen. Hierzu sollen natürlich die Kosten so klein wie möglich gehalten werden. Dazu möchte ich nicht nur die Kosten für die Entwicklungsumgebung berücksichtigen, sondern auch die Zeit, die man durch eine teurere Entwicklungsumgebung einsparen kann. Opensourse Zeugs, kenne ich von WinAVR. Ist für den Hobbybedarf OK, aber... Dann habe ich mir Crossworks etwas näher angesehen. Ist schon mal ganz gut. Jetzt bin ich nur am Überlegen, ob Keil evtl. noch besser wäre. Sind die Mehrkosten für Keil schnell wieder kompensiert, wenn man die mitgelieferten Bibliotheken, evtl. einfacheres Debuggen(?), mehr Beispiele im Netz berücksichtigt?
Eine Alternative zu den Produkten von Keil wäre die Embedded Workbench von IAR, die solltest Du jedenfalls auch noch untersuchen.
Hi, auch wenn ich "befangen" bin :-) beim Keil MDK hast latürnich den Debugger mit dabei mit allen seinen Möglichkeiten, sowie tonnenweise example code "out of the box". VG, /th.
Wenn ich das richtig überblicke, sind IAR und Keil preislich ähnlich. Sind sie das auch vom Handling und Ausstattung her auch? Ich bin ARM/Cortex Anfänger, habe bisher nur mit AVR und WinAVR gearbeitet (ein paar Jahre). Könnte man von den Beiden behaupten, dass Einer besser für den Einstieg/Wechsel geeignet ist. Rein gefühlsmäßig, tendiere ich zu Keil... Wegen den "Tonnen, out of the box" Dann dieser JLink2 bzw. JLink Pro. Ist der Pro eine viel größere Debug-Hilfe? Rentieren sich die 600 €?
Wir nehmen die IAR-cortex Variante und J-Link. Habe bisher prima ohne J-Trace leben können. Ich denke, Keil/IAR geben sich nix. Allerdings finde ich die RTOS-Plugins bei IAR ganz nett.
Frank schrieb: > Wenn ich das richtig überblicke, sind IAR und Keil preislich ähnlich. > Sind sie das auch vom Handling und Ausstattung her auch? > Ich bin ARM/Cortex Anfänger, habe bisher nur mit AVR und WinAVR > gearbeitet (ein paar Jahre). Könnte man von den Beiden behaupten, dass > Einer besser für den Einstieg/Wechsel geeignet ist. Rein gefühlsmäßig, > tendiere ich zu Keil... > Wegen den "Tonnen, out of the box" > > Dann dieser JLink2 bzw. JLink Pro. Ist der Pro eine viel größere > Debug-Hilfe? > Rentieren sich die 600 €? Hi, da vertust du dich etwas :-) ULINK2 und pro sind von Keil. JLink und JTrace ist von Segger. Läuft aber in Keil :-) ULINK2 oder JLink reicht idR. aus zum Debuggen, Variablen/Register/Speicher guggen und ändern, im Logic Analyzer Variablen als Signale darstellen, usw. ULINK pro ist zum Tracen, dazu brauchst schon ne "fette Kiste", weil der Kram in Realtime über USB in die Maschine geht. Alternativ, mit 4MB Trace Buffer, läuft auch der JTrace in Keil. Trace ist nur dann notwendig, wenn du mit den herkömmlichen Maßnahmen (Step, Register, Memory und Breakpoints, ...) keinen Fehler finden kannst, und dich durch seitenweise Assemblercode arbeiten musst. Andererseits ist der ULINK pro wesentlich schneller im Daten liefern, für z.B. den logic Analyzer, eine Art Scope für Variablen. Willst du ne flexible Lösung, dann kauf dir nen JLink von Segger, und teste Keil und IAR. Der (gelbe) JLink von IAR läuft logischerweise nicht im µVision (Keil), denn der ist "locked" auf IAR. Der (schwarze) JLink läuft aber fast überall, Keil, IAR, div. gnu's. Willst du dich auf ein Paket festlegen, empfehle ich dir Keil µVision + ULINK2. Lad dir einfach mal die Demo und probier die Beispiele im Simulator aus, damit kannst du die ganze Funktionalität ändern. VG, /th.
Nachtrag:
> Alternativ, mit 4MB Trace Buffer, läuft auch der JTrace in Keil.
Der JTrace streamt nicht! Intern 4MB voll & STOP / Auswerten.
Ich habe mir mal die Keil-Versionen angesehen. Diese Middleware Libraries in der Professionalversion, scheint interessant zu sein. Ist das sein Geld wert? Wenn man berücksichtigt, dass ich noch nichts mit USB, SD-Karten und FAT gemacht habe und dies dann aber brauchen werde.
Beim Keil sind die Originalcompiler von ARM drin. Ich sehe das als Vorteil gegenüber allen anderen Tools an, hab also für die Firma Keil angeschafft. Compiler, Assembler, Linker und Libs sind OK und sie sind auch einfach per Batchfile zu benutzen, deswegen ist Keil meine Empfehlung. Von der IDE bin ich nicht begeistert, allerdings von den anderen IDE's (IAR, RIDE usw) auch nicht. Die schränken einen nur ein und machen die Sache komplizierter als sie eigentlich ist. Und einen Segger JLink hab ich mir mal privat für UHU zugelegt, aber bislang noch nie gebraucht. Kommt allerdings auf die Chips an, die ihr einsetzen wollt. Wenn da kein Bootlader drin ist, bleibt dir nix anderes übrig, als JTAG zu benutzen. W.S.
Hab schon mit beiden IAR und Keil gearbeitet. Beide IDEs haben sehr gute Compiler. Welche IDE Dir besser gefaellt kannst Du ja ausprobieren, einfach die Schnupperpakete runterladen. Ob sich der Mehrpreis zu Crossworks lohnt kommt auf deine Vorlieben und darauf an wie knapp die Speichergroesse bemessen ist. Keil und IAR werden dann besonders wertvoll, wenn es zum Schluss ganz eng wird im internen Speicher. Dann bekommst du einfach noch eine zusaetzliche Funktione rein, die beim GNU nicht mehr reinpasst. Die Studenten, die bei mir gearbeitet haben sind mit Keil etwas schneller ans Ziel gekommen. Der Hauptvorteil von IAR liegt darin, dass die Embedded Workbench fuer viele verschiedene Architekturen verfuegbar ist -> nur einmal einarbeiten. hth, Robert
Ja, ich denke mir halt, dass ich mit Keil am Bessten fahre, weil es auch so verbreitet ist. Kennst Du diese zusätzlichen Libraries der Professionalversion? Ist so etwas sinnvoll? Mein Chef, würde da Geld investieren wollen, wenn es sich lohnt. Aber das einzuschätzen, bin ich nicht in der Lage. :-( Wäre gut, wenn mir da jemand ein paar pro und contras nennen könnte.
Hallo, die Aussage von Robert Teufel bezüglich Crossworks ist nicht ganz richtig, da Crossworks eigene Standard Libraries enthält und nicht z.B. die Newlib benutzt. Von daher ist der Code nicht größer als bei IAR oder Keil, evtl. könnte es sein das IAR oder Keil etwas besser als GCC optimiert, aber selbst dabei wäre ich mir nicht sicher, könnte man mal untersuchen. Vorteil von Crossworks ist natürlich der deutliche günstige Preis als IAR oder Keil, die Entwicklungsumgebung gefällt mir persönlich sehr gut, alles sehr durchdacht. Außerdem gibt es einen Haufen BSP und Samples mit dabei. Letzlich sind alle drei sehr gut und haben Ihre Stärken und Schwächen. Ich würde mir tatsächlich von allen drei mal eine Trial Version herunter laden und einfach ausprobieren mit welcher du am besten zurecht kommst. Die Middleware Sachen, die teilweise mit dabei sind, kann man sicher benutzen ich würde für sowas aber eher etwas profesionelles von Segger nehmen. Als Emulator würde ich ganz klar den J-Link von Segger nehmen, ist halt Industriestandard und hat den Vorteil, das er von so ziemlich jeder Workbench unterstütz wird (wird schon seinen Grund haben, das sogar Keil, die einen eigenen Emulator haben, diesen unterstützen ;-) ). Aber auch mit einem ULink wirst du sicher glücklich werden.
Uwe schrieb: > [...] da Crossworks eigene Standard Libraries enthält und nicht z.B. > die Newlib benutzt. Von daher ist der Code nicht größer als bei IAR oder > Keil, Wo ist denn da der Zusammenhang? Auch eine eigene Library kann größer sein. Behauptet hat das allerdings niemand -- auch nicht Robert. > evtl. könnte es sein das IAR oder Keil etwas besser als GCC > optimiert, aber selbst dabei wäre ich mir nicht sicher, könnte man mal > untersuchen. Getan. Das Ergebnis ist zwar schon älter, aber immerhin haben sich beide toolchains (Keil bzw RVCT, GCC) weiterentwickelt. Das Ergebnis in bezug auf Größe/Performance fällt erwartungsgemäß zugunsten des ARM compilers aus. Ob einem das den Preisunterschied wert ist, muss jeder für sich entscheiden. Gruß Marcus
Marcus Harnisch schrieb: > Wo ist denn da der Zusammenhang? Auch eine eigene Library kann größer > sein. Behauptet hat das allerdings niemand -- auch nicht Robert. Natürlich kann Sie das, hat ja auch niemand behauptet... Ein Problem bei GCC im Embedded Bereich ist aber die Newlib, die halt standardmäßig genutzt wird. Diese Library war ursrünglich nicht für den Embedded Bereich gedacht und nicht darauf optimiert. Dies ist bei Rowley durch eine eigen Standard Library gut gelöst. Es gibt halt mehrer Faktoren, die dafür verantworlich sind, ob die Applikation noch reinpasst oder nicht...und die Standardlibrary ist einer davon, Zusammenhang jetzt klar? ;-) Aber ok, wenn wir jetzt alleine von unterschiedlicher Codegröße durch unterschiedlich gute Compiler Optimierungen reden, wie groß sind denn da die Unterschiede? Das würde mich wirklich mal interessieren, vielleicht kann man mal die Ergebnisse hier posten.
Uwe schrieb: > Ein Problem bei GCC im Embedded Bereich ist aber die Newlib, die > halt standardmäßig genutzt wird. Diese Library war ursrünglich nicht > für den Embedded Bereich gedacht und nicht darauf optimiert. "Newlib is a C library intended for use on embedded systems." -- http://sourceware.org/newlib/ > Zusammenhang jetzt klar? ;-) Klar :-) > Aber ok, wenn wir jetzt alleine von unterschiedlicher Codegröße durch > unterschiedlich gute Compiler Optimierungen reden, wie groß sind denn da > die Unterschiede? Das würde mich wirklich mal interessieren, vielleicht > kann man mal die Ergebnisse hier posten. Ich weiß nicht, ob irgendwelche EULAs mir das posten verbieten, aber in Extremfällen kann das nach meiner Beobachtung den Faktor zwei überschreiten. Im Durchschnitt ist das natürlich weniger. Schlechter war der RealView Compiler nie. Einen ARM Compiler Vergleich findest Du hier: http://hardwarebug.org/2010/01/15/arm-compiler-update/ Bezieht sich aber nur auf die Ausführungsgeschwindigkeit. Worauf Robert anspielte, war der kommerzielle Einsatz. Wenn ich durch bessere Optimierung eines Compilers, der ein paar tausend € mehr kostet als das Produkt eines Mitbewerbers, den Code in einen günstigeren Chip hineinbekomme, kann sich der Preisunterschied schnell umkehren. Gruß Marcus
Code Composer Studio von Texas Instruments kann ich empfehlen.
Uwe schrieb: > Marcus Harnisch schrieb: >> Wo ist denn da der Zusammenhang? Auch eine eigene Library kann größer >> sein. Behauptet hat das allerdings niemand -- auch nicht Robert. > > Natürlich kann Sie das, hat ja auch niemand behauptet... Ein Problem bei > GCC im Embedded Bereich ist aber die Newlib, die halt standardmäßig > genutzt wird. Diese Library war ursrünglich nicht für den Embedded > Bereich gedacht und nicht darauf optimiert. Dies ist bei Rowley durch > eine eigen Standard Library gut gelöst. Sehe ich genauso und damit meine ich beide Beitraege. Mir ist sehr bewusst, dass Crossworks eigene (kleinere) Libs hat und mein Beitrag soll wirklich niemanden vom Crossworks Einsatz abhalten. Ich halte sehr viel von Rowleys. Mein Punkt sollte sein, dass tatsaechlich die Compiler Optimierung bei ARM und auch IAR etwas besser ist als bei einer GNU version. Erfahrungen der Entwicklungsteams in den Firmen fuer ich ich arbeite und gearbeitet habe sind irgenwo zwischen ganz wenigen Prozenten und der Faktor 2. Faktor 2 kommt normalerweisse mit newlib zustande, ist also Aepfel mit Birnen verglichen. Ganz wenige Prozente sind dann normal, wenn sich alles im 32-bit Bereich abspielt und die Compiler von IAR und Keil, die aus dem Embedded Bereich mit kleinem Speicher kommen ihre Staerken nicht ausspielen koennen. Meine Schaetzung fuer ein "groesseres" Programm, das waere z.B. >64K code, lautet zwischen 5 und 10 Prozent Unterschied. Das heisst, fuer kleine Stueckzahlen lohnt sich der Mehrpreis einen groesseren Chip zu kaufen, fuer grosse Stueckzahlen oder wenn man schon den groessten verfuegbaren Chip einsetzt werden Keil und IAR sehr interessant! Will man gleich fuer letzteres planen, nur keine Hemmungen. Ein weiteres Argument in Deutschland waere der Support. Ich weiss aus eigener Erfahrung, dass Keil sehr guten Support liefert, bei Rowley habe ich per e-mail support auch ueberwiegend gute Erfahrungen gemacht. IAR kann ich nicht wirklich beurteilen, denn ich war da kein Kunde sondern ein Geschaeftspartner und habe immer speziellen Zugriff zu den Spezialisten gehabt. Die waren sehr gut! Support in deutscher Sprache war am besten von Keil, in Englisch hat sich's nicht viel getan. Es gibt noch etwas zu beruecksichtigen. Wenn es sich bei der Hardware z.B. um einen STM32 handelt, dann ist Raisonance im gleichen Zuge zu erwaehnen wie Crossworks, wenn es sich um einen NXP handelt, dann waere CodeRed eine echte Alternative und dann gibt's noch ein paar mehr. Ausser Keil und IAR bauen fast alle auf GCC auf und haben somit in der Compiler Optimierung keine echten Unterschiede. Jetzt kommts noch darauf an wie gut der Debugger ist, wie gut hardware U-Link / J-Link mit den Compilern arbeiten. Die IDE / Debugger ist weitgehend mit den persoenlichen Vorlieben verbunden. Ich mag einen lieber als den anderen aber das ist nur wenig auf Fakten zu basieren, deshalb lass ich hier auch die Namen weg ;-) Einen Rat wuerde ich dem OP allerdings geben. Wenn Keil, dann U-Link (PRO), wenn IAR, dann J-Link (PRO oder Trace). Gruss aus California, Robert
Nicht wirklich on-topic aber dennoch: Betr. Newlib: was bei Verwendung der Newlib wirklich Programmspeicher auffrisst sind einige Funktionen aus stdio. Fliesskommaformate werden per default unterstützt und jede Verwendung von z.B. printf zieht die Unterstützung mit in den Maschinencode. Falls Fliesskommazahlen nicht benötigt werden, nutzt man z.b. iprintf (integer printf, gibt ach iscanf, siscanf etc.) und spart einiges an Speicher. Einige wenige Funktionen der Newlib für ARM-Cores wurden vor nicht allzu langer Zeit von allgemeinem C-Quellcode auf "handoptimierten" Assembler-Code umgestellt. Etwas mehr on-topic: Bei ARM/Keil µVision wird ein sehr ordentlichen Simulator mitgeliefert. Mir ist bis dato kein ähnlich guter Simulator für "kleine" ARM-basierte Controller inkl. deren integrierter Peripherie begegenet - was aber nicht viel heissen mag, habe nicht viele kommerzielle Entwicklungswerkzeuge ausprobiert. Mit dem Simulator kann man einiges ganz ohne Hardware durchspielen. Müsste ich derzeit eine kommerzielle IDE erweben, wäre allein der Simulator kaufentscheidend (an zweiter Stelle evtl. Unterstützung diverser RTOS im Debugger). Die Editoren bei den von mir ausprobierten Eval./Kickstart Versionen von MDK-ARM und EWARM (bei beiden nicht die aktuellste Fassung ausprobiert) sind im Vergleich zu denen in Visual Studio und Eclipse funktionsarm - die Hersteller nennen das dann wahrscheinlich funktional. Sollte man ausprobieren bevor man von dem Teil der IDE, den man als Codeschreiber häufigst benutzt, enttäuscht ist. Bezügl. "Middleware" erstmal ein wenig herumschauen, es gibt viele kommerzielle und auch kostenlose Alternativen für RTOS, Dateisysteme und Speicherkarteninterface für diverse Controller. Lieferbarkeit von Libraries und Beispielen mit der IDE mag den Einstieg erleichtern, birgt aber auch die Gefahr, dass der Sichtschutz am Tellerrand blickdichter wird.
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.