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
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
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!
Mal rein interessehalber: Kann das Debugging-Tools auch auf C-Source-Level simulieren wie das AVRstudio? Gruß Johannes
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.
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.
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)
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.
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
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
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?
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
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
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).
Moment mal: Hat Eclipse oder eines der anderen GDB-GUIs einen Simulator inklusive? Oder hat den Keil, IAR oder Crossworks zu bieten?
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.
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
> 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.
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
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.
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.
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
<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>
Bitte 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.