mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM Compiler?


Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich möchte mich jetzt etwas näher mit den ARM Prozessoren von ATMEL 
auseinandersetzen, weiß aber nicht genau was ich alles für den Einstieg 
brauche.

Der AT91SAM7SE512 scheint recht brauchbar zu sein. Welche Software 
(Compiler, Tools...) benötige ich dazu? Zum Debuggen werde ich den 
AT91SAM-ICE JTAG Emulator verwenden.

Welche Software ist gratis? Welche Software ist empfehlenswert?

Gibt es (günstige) Development Boards mit diesem Prozessor?


mfg Thomas


Autor: olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

Boards + JTAG gibts hier im Shop (von OLIMEX).
Empfehlen würde ich als OS eCos (ecos.sourceware.org),
als IDE yagarto (Eclipse + GCC Compiler + jtag Anbindung).

Gruß

Olaf

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es das ganze als gezippte Datei? Also alles was ich irgendwie 
brauchen könnte? Hab leider kein Internet zuhause und es wäre mühsam 
wenn ich Tage benötigen würde nur damit ich dann schlussendlich alles 
zusammen habe.
Wäre echt nett!

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo thomas,
unter www.yagarto.de findest du alles was du suchst.

gruss
gerhard

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal rein interessehalber: Kann das Debugging-Tools auch auf 
C-Source-Level simulieren wie das AVRstudio?

Gruß Johannes

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, das sieht schwer gewöhnungsbedürftig aus. Ich mein, beim AVRstudio 
hab ich einen gelben Pfeil links neben der jeweiligen Source-Zeile und 
alle geänderten Register und Speicherstellen rot markiert, sofern ich 
die entsprechenden Views offen habe...

Ich will ja keinem zu nahe treten, aber irgendwie fühle ich mich bei 
diesem Anblick um über ein Jahrzehnt zurückgebeamt in eine Zeit, als ich 
noch unter purem DOS meinen ersten Rein-ASM-PIC-Simulator von einer 
Floppy installier und in Betrieb genommen habe.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist die Unix-Philosophie: willst du einen Simulator, nimmst du einen 
Simulator, willst du ein GUI, nimmst du ein GUI. Für GDB gibt's 
haufenweise GUIs, z.B. auch ein Eclipse-Plugin. Aber so kompfortabel wie 
beim AVR-Studio wird's zumindest unter Windows nicht.

Autor: Roland Schmidt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das Bild im Anhang zeigt das Debuggen mit Eclipse.

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damit ist die Unix-Philosophie nichts anderes als die CP/M-Philosophie, 
die noch einmal >10 Jahre älter ist als die DOS-Philosophie. Und 
tatsächlich ist die Unix-Philosophie noch weit älter...

Es ist doch schon seltsam: Da ziehen sich die Leute, die so hochmoderne 
Software schreiben, doch immer wieder auf Ebenen zurück, die weit vor 
jeder halbwegs modernen Anwenderoberfläche liegen, und sind auch noch 
stolz darauf.

Ich meine, es hat mir bisher keiner ein integriertes Entwicklunssystem 
unter Unix/Linux bieten können, das auch nur annähernd den Level eines 
Turbopascal oder Delphi erreicht hat. Und das, wo sich die Szene doch 
gerade damit rühmt, so viele Programmierer-Resourcen zu haben. Eclipse 
mag schön und gut sein, aber dem fehlt die "handfest-unkomplizierte" 
Debugging-Ebene. Und die existierenden Debugger mögen schön und gut 
sein, aber ihnen fehlt die schlüssige Einbindung in ein IDE, und von 
Simulatoren will ich in diesem Zusammenhang gar nicht erst anfangen.

Und unter Windows ist Eclipse überhaupt nicht komfortabel. Kein 
Vergleich zu anderweitig existierenden Tools. Ich weiß bisher nur einen 
einzigen Grund, warum Entwickler unter Windows Eclipse benutzen, und das 
ist die Versionskontrolle - und dabei sind alle, von denen ich bisher 
gehört habe, am schimpfen darüber, dass sie die make-files alle wieder 
per hand editieren müssen...

(ironie anfang) Echt spitzenklasse. Das animiert natürlich jeden, beim 
Schwenk auf den ARM auch den Schwenk zu irgendeinem Unix-Derivat in 
Erwägung zu ziehen... (ironie ende)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob du es glaubst oder nicht, das ist einfach Geschmackssache. Ich habe 
schon die verschiedensten "komfortablen" IDEs ausprobiert, aber ob 
AVR-Studio, Xilinx, Eclipse oder Matlab, am Ende bin ich dann doch 
meistens wieder bei vim, make und Kommandozeilen-Versionskontrolle 
gelandet. Weil das für mich komfortabler ist.

Du willst eine IDE? Dann kauf dir eine IDE, z.B. Crossworks von Rowley.

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaub's Dir unbesehen, dass das Geschmackssache ist.

Und vielleicht magst Du es mir dann auch glauben, dass es für mich 
komfortabler ist, diverse tausend Zeilen Code direkt "durchzuhühnern" 
als immer zwischen Simulator-Output und Source-Zeile hin und her hüpfen 
zu müssen :-)

Ansonsten räume ich gern ein, dass ich einfach Borland-versaut bin, was 
ein Level ist, an den es echt nicht leicht ist, heranzureichen. Auch 
Microsoft hat es mit allen Visual-XXXs bisher nicht geschafft...

Und zur Kauf-IDE: Oh, Crossworks von Rowley sieht auf den ersten Blick 
gar nicht so schlecht aus. Und der Preis ist auch erstmal ok. Da werde 
ich dranbleiben. Danke für den Tip.

Gruß Johannes

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probier doch mal Keil. Mit der Demo kann man schon kleine Projekte 
bearbeiten. Und wenn GNU reicht, geht auch mehr. Aber wenigstens mit ner 
ordentlichen IDE und Projektverwaltung.

Gruß
Peter

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja das Problem ist, dass Keil den AT91SAM7SE512 nicht unterstützt. 
Ansonsten wäre ich ja ein Fan von Keil, da ich damit den C167 
programmiere...

Was hält ihr von IAR?

Kann man auf den ARMs eigentlich auch WinCE oder Linux zum Laufen 
bekommen?

Autor: Blackbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin gerade dabei, mich mit IAR (ICCV7) anzufreunden damit ich einen 
AT91SAM7S64 auf dem Olimex-Board zum Laufen bringen kann.
Mehr als Compilieren ind Linken kann er nicht, je nach Version (STD, 
Prof., ...) auch noch Versionsverwaltung usw.
Ein Binary kann man mit den Tools von WinARM machen, downloaden mit 
SAMBA, Debuggen geht nur mit extra Tools anderer Hersteller. Hab's noch 
nicht probiert, werde es aber brauchen.

EWARM von IAR ist als IDE schon etwas "vollständiger". Binaries kann man 
schon innerhalb des Projektes machen, wenn man die cygwin-Unterstützung 
für das mitgelieferte arm-elf-objcopy-Tool hat. Download wieder mit 
SAMBA.

Dokumentation ist dürftig.

Irgendwann habe ich mich sicher daran gewöhnt, aber die 
Einarbeitungszeit ist sehr, sehr hoch im Vergleich zu VC6 u.ä.

Blackbird

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn ich das so lese, kommen mir doch leise Zweifel, dass ich ein 
ARM-Programm überhaupt noch halbwegs komfortabel debuggen kann...

Also frag ich nochmal so: Wieviel Kohle muss ich investieren und für 
was, damit ich einen ARM auf der Ablauf-Ebene genauso source-orientiert 
step-by-step verfolgen kann, wie ich es beispielsweise von Delphi und 
Borland C++ für x86-Programme bzw. von AVRstudio für AVR-Software 
gewohnt bin?

Gruß Johannes

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn dir Eclipse oder eines der anderen GDB-GUIs ausreicht: garnichts.

Wenn du mehr Komfort willst: Keil, IAR, oder Crossworks.

Das Debuggen kann man in jedem Fall direkt auf dem Controller machen 
(per JTAG).

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moment mal: Hat Eclipse oder eines der anderen GDB-GUIs einen Simulator 
inklusive? Oder hat den Keil, IAR oder Crossworks zu bieten?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Simulator ist in GDB enthalten, wird aber von kaum einem genutzt, 
weil JTAG meistens (aber nicht immer) praktischer ist, und nicht viele 
von seiner Existenz wissen (darum der kleine Wiki-Artikel). Der 
Simulator ist allerdings sehr gut geeignet für Benchmarks und 
automatisierte Tests von (Assembler-)Funktionen.

Bei den anderen IDEs - keine Ahnung.

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, wenn er auf dem Level läuft, über den wir uns schon unterhalten 
haben, verstehe ich, warum ihn kaum einer nutzt.

Dann nächste Frage: Wieviel kostet ein ordentliches JTAG-Equipment für 
ARMs, das soweit allgemein verwendbar ist? Ich mein, wenn ich schon auf 
ARMs gehe, dann müssen sie insgesamt schon deutlich mehr bringen als 
z.B. die AVRs. Oder zumindest im Übergangsbereich dieselbe 
Debugging-Performance via JTAG.

Ich weiß, dass für "höhere" Controller ganz andere Steckverbinder üblich 
sind, und dass die definitiv nicht kompatibel zu 1/4"-Pfostensteckern 
sind.

Also was muss ich da kalkulieren?

Gruß Johannes

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahm, ich meinte nicht 1/4" sondern 1/10"-Pfostenstecker...

Gruß Johannes

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ok, wenn er auf dem Level läuft, über den wir uns schon unterhalten
> haben, verstehe ich, warum ihn kaum einer nutzt.

Du verwechselst Frontend und Backend.

Zum Thema ARM Debuggen wurde eigentlich schon genug geschrieben, hab 
keine Lust das alles hier zu wiederholen.

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube nicht, dass ich das verwechsle.

Meine Frage geht jedenfalls schon die ganze Zeit, und seit meinen 
letzten Postings verschärft dahin, ob es eine vernünftige simulierende 
Ablauf-Ebene für die ARMs gibt und wenn ja wie teuer die mich kommt. Und 
in zweiter Instanz hatte ich nach JTAG-Hardware gefragt, und konkret 
wiederum nach den Kosten, mit denen ich da rechnen muss.

Und dann auf einmal verwechsle ich Frontend und Backend, und muss mir 
erzählen lassen, dass Du plötzlich keine Lust mehr hast, auf meine 
konkreten Fragen weiter zu antworten.

Ja, ok, ich werde nie mehr konkrete Fragen an Dich richten.

Danke trotzdem.

Gruß Johannnes

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deine Beiträge zeigen, dass du dir nicht die geringste Mühe gemacht hast 
dich selbst über GDB und ARM-Debugging zu informieren. Das ist 
normalerweise üblich bevor man in einem Forum postet - ansonsten darfst 
du dich nicht über einsilbige Antworten wundern.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes, wo ist dein Punkt?

Jemand der mit ARM arbeiten will/muss, fragt zuerst, ob alles benötigte 
vorhanden ist. Vorhanden sind alle Tools, die man braucht. Sogar 
komplett kostenlose Toolchains, Libraries und Betriebssysteme. "Debuggen 
innerhalb einer IDE" inklusive. Die einfachste JTAG Hardware baut man 
sich für 5€ selbst und welchen Stecker man anlötet bestimmt das Target; 
die teuerste kann man für 2T€+ kaufen.

ABER: Jemand der einen Grund sucht, nicht auf einen ARM umzusteigen, 
findet immer genug Haare in der Suppe, um es zu lassen. Und wenn es 
Vergleiche mit dem Look&Feel seines geliebten Turbopascals sind oder das 
Bestehen auf einem Simulator mit IDE sind ;-)

Ich persönlich habe noch nie einen ARM-Simulator benutzt. Ich gehe 
lieber direkt mit dem Debugger direkt an reale Softwarebugs ran als an 
virtuelle Softwarebugs. Aber so eine Simulation könnte mir echt was 
bringen, wenn ich irgendwo im ICE zwischen Frankfurt und Hannover 
kräftig am Entwickeln bin und das Target nicht direkt neben mir habe.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein kurzer Beitrag zum Thema Simulator.
Verschiedene IDEs stellen einen sogenannten "Instruction Set Simulator" 
zur verfuegung. Das ist auch nich soo schwer. Keil ist meines Wissens 
der einzige, der einen "Device Simulator" zur Verfuegung stell. D.h. es 
koennen auch die Peripherals simuliert werden.
Dieses Feature steht fuer die gaengisten Typen am Markt zur Verfuegung, 
z.B. die Typen von NXP (Philips), ST und Atmel.

Gruss, Robert

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<off-topic>
ich hab mit delphi und VC gearbeitet. Die ganzen zusammenhänge
habe ich erst auf'm Linux rechner verstanden. Die ganzen IDE's
sind dermassen überladen. In der unix philosophie besteht alles
aus kleinen bausteinen, das ganze betriebsystem handling ist
damit nix anderes als programmieren mit diesen bausteinen.
Ob ich auf meinem rechner bin oder remote an der uni .. man
spürt den unterschied gar nicht. find, grep, make, gcc, awk, gdb,
sed .. und python, ruby, tcl für komplexere sachen finden sich
auf jedem system.
Wenn man eine analogie machen würde, so ist das als ob jedes
kleine tool eine unterfunktion ist, die immer wieder aufgerufen wird.
Anstatt eine grosse alles beinhaltende funktion(sprich programm)
zu schreiben. Was besser ist weiss jeder der schon mal etwas nicht
triviales programmiert hat.
</off-topic>

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.