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?
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.
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
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.
