mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM: Compiler und Debugger


Autor: ARM USER (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

mir ist immer noch nicht ganz klar, warum sich ein Entwickler einen
"teuren professionellen" C-Compiler (IAR, KEIL, Tasking, etc.)
kaufen
soll, wenn es einen freien GNU-Compiler gibt? Also muss es bezüglich
Qualität, Optimierung (Size, Speed), Error-Pathes... doch einen
gravierenden Unterschied geben - oder?

Was für Nativ Debug Möglichkeiten hat die ARM7-Core über JTAG. Soweit
ich weiß, kann man max. 3 Breakpoints setzen und sich Speicherinhalte
anzeigen lassen. Was darüber hinaus geht, wird über spezielle Debugger
Software (IAR, PLS, Segger, etc.) implementiert - oder?

Als Hobby Bastler kommt sicherlich die "GNU-Lösung" nur in frage.
Wenn man beruflich damit zu tun hat, machen sich die ca. 3000Euro bald
bezahlt (ein paar Tage Fehlersuche) - oder.

Vor einem Jahr hat mal ein Halbleiter-Hersteller zu mir gesagt, dass
der GNU-Compiler genauso gut ist wie die anderen.

Was ist Eure Meinung bzw. welche Erfahrungen habt Ihr gemacht. Welche
Empfehlung bezüglich Compiler und Debugger könnt Ihr mir geben?

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

während meines Studiums habe ich mit Texteditor und
Kommandozeilen-Assembler/Compiler gearbeitet. Bei einfachen Programmen
ohne große Intelligenz genügt es.
Habe jetzt aber beruflich mit den Keil-Compiler in der µVision IDE und
der IAR Workbench zu tun gehabt.
Ein riesen Unterschied sag ich da nur. Hat nur Vorteile, wenn ich
Editor, Assembler/Compiler und Debugger/Simulator in "einem" Programm
habe. Wie du schon gesagt hast, bei der ersten Fehlersuche hat sich das
Geld für die IDE schon gelohnt - deutlich schneller und
nervenschonender.

Als Fovoriten habe ich Keil und IAR
(wobei das liebste sind mir die (ds)PICs im MPLAB, aber keine ARMs)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Compiler als codeerzeugendes Tool ist weniger das Problem - gcc wird
auch von vielen kommerziellen Entwicklungssystemen verwendet.

Sehr große Unterschiede gibt es aber in der Qualität des Debuggers. Auf
der "freien" Schiene "wiggler" - ocdremote - gdb/insight kann man
wohl, ausreichend Geduld vorausgesetzt, auch sowas wie glücklich
werden, aber das ist unter Windows-Systemen äußerst zäh.

Daß das mit der gleichen Hardware und dem gleichen Betriebssystem
anders geht, beweist Rowley Crossworks. Das funktioniert mit dem
einfachen "Wiggler" am Parallelport und bietet einen ziemlich
anständigen integrierten Debugger sowie eine ebenfalls ziemlich
anständige IDE.

Übrigens kostet Crossworks keine 3000 EUR (mich würde interessieren, wo
diese Zahl herkommt, die wird ja gerne genannt), sondern "nur" 500
UKP, was auf etwa 750 EUR hinausläuft.

Auch IAR-Compiler sind für weniger Geld zu bekommen, im Bundle mit
einer Demo-Platine und einem USB-JTAG-Adapter oft schon für 300 EUR.
Das ist dann eine auf 32K Codegröße beschränkte Version, aber das
genügt für viele Projekte.

Nun sind IDEs ja so eine Sache für sich; gerade Leute, die aus dem
*nix-Umfeld kommen, möchten alles mit Emacs oder gar vi anstellen und
finden alle nicht kommandozeilenorientierten Tools verwerflich, andere
Leute wiederum möchten sich nicht um die Erzeugung von Makefiles
kümmern müssen, sondern wollen eine integrierte Projektverwaltung etc.
...

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich finde die keil entwicklungsumgebung einfach klasse! arbeite schon
seit einem jahr beruflich damit! wenn ich die mit dem mplab
vergleiche... du kannst jedoch auch den gcc compiler in die keil ide
integrieren! bei keil gibt es auch eine frei version, die auf 32k
beschränkt ist.

mfg, Mathias

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ganz extrem gesagt, der Compiler ist nicht mehr viel wert. Wie Rufus
schon geschrieben hat, die integrierte Entwicklungsumgebung macht den
Unterschied.
Da ich mit vielen der Toolherstellern arbeite gebe ich keine Praeferenz
ab. Lade doch einfach mal die Demoversionen runter und generiere ein
kleines Projekt, dabei sollten schon Unterschiede deutlich werden.
Noch ganz wichtig ist das Debugging, mit GDB zu arbeiten hat schon so
manchen um den Solltermin fuer die Markteinfuehrung des Produktes
gebracht.
Gruss, Robert

Autor: ARM USER (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Beiträge.

Jetzt habe ich noch eine Frage zum Debugger. Klar ist, dass es einer
sein soll, der auf die JTAG-Schnittstelle zugreift. Welche Unterschiede
gibt es da? Welche könnt Ihr Empfehlen?

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist das schoene bei den integrierten Umgebungen, da ist der Debugger
schon mit drin. Als Stand alone debuggers gibt es Loesungen von, Hitex,
Lauterbach, Nohau, Signum, PLS, Segger, ansonsten U-Link mit Keil,
J-Link mit IAR, Real-View Ice mit ARM Real-View Tools....
Hab jetzt einfach mal ein paar Namen genannt damit du Goggle-Futter
hast ;-)

Gruss, Robert

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.