Hallo NG, heute ist endlich meine AT91SAM7S256 ARM Entwicklungsplatine um das lange ersehnte JTAG-Verbindungskabel erweitert worden :-) Kann mir jemand kurz sagen, was ich benötige, um meinen ARM in Assembler (nicht C! etc...) zu programmieren (bevorzugt frei verfügbare Tools)? Mir wäre auch wichtig, dass ich die Programme zum Testen ins SRAM laden kann, so dass ich mir keine Gedanken in Sachen Lebensdauer vom Flash machen muss... Vielen Dank für jeden Tip! Peter
hello peter, wenn du tatsächlich den arm in assembler programmieren möchtest dann solltest du dir vor allem viel zeit nehmen und mal ein paar tutorials und datasheets ansehen (stichwort "arm arm"). als weitere gute-nacht-lektüre kann ich dir das buch "arm system deveoper's guide" ans herzen legen (findest du im amazon). wenn dir dann der arm core vertraut ist, lädst du dir die gnu tools (am besten von www.yagarto.de) runter, da ist dann auch ein assembler drin. und danach viel spass beim assembler programmieren! p.s. wenn du dir das o.a. buch zu gemüte führst und alle darin enthaltenen ratschläge beachtest solltest du mit c nahezu die gleiche performance errichen wie mit assembler. gruss gerhard
Hallo Peter Vergiss Assembler für den ARM , sonst wirst du nicht mehr froh bei der Programmierung. Nur wenn du auf einige Register zugreifen willst, brauchst du Assembler. die Register sind : Programcounter Linkregister Systemregister Alles andere geht in C. Und glaub mir Niemand programmiert freiwillig einen ARM in Assembler, zumindest wenn es mehr als "Hello World" sein soll.
> Vergiss Assembler für den ARM , sonst wirst du nicht mehr froh bei der > Programmierung. Ach was, auf den Dingern macht Assembler doch echt Spass (ausser Thumb-Mode, das ist weniger lustig, aber auch nicht wirklich ein Problem). Ich würde den GNU Assembler nehmen.
"Ach was, auf den Dingern macht Assembler doch echt Spass" Masochist ?
> wenn dir dann der arm core vertraut ist, lädst du dir die gnu tools (am > besten von www.yagarto.de) runter, da ist dann auch ein assembler drin. Ok, dann hätte ich mal den Assemblermit dem ich wahrscheinlich die Binaries erzeugen kann. Leider fehlt mir jetzt immernoch die Möglichkeit, das Ganze auf den Chip zu bekommen. Mit diesem "SAM-BA" kann ich leider nur immer den Flash-Speicher nützen. Das möchte ich aber nicht. Ich würde gerne irgendwie ein Tool haben, wo mein Zeug ins SRAM laden kann: Lade meinen BIN-File an ZB. 0x20000 (wenns denn eine SRAM-Adresse wäre) und beginne mit der Ausführung bei 0x2001A... Was dann natürlich auch cool wäre, wäre sowas wie in anderen Monitor-Programmen, wo ich Schrittweise immer den nächsten Befehl ausführen lassen kann und mir dann die Registerinhalte anschaue, was passiert ist... Danke für jeden Tip! Peter
Das geht mit OpenOCD + GDB. Wenn es etwas komfortabler sein soll IAR oder Crossworks.
Was Du Dir da wünscht, ist ein Debugger. Und das Hardware-Tool, damit dieser Debugger mit dem ARM kommunizieren kann, ist ein JTAG-Interface. Damit kannst Du Programme im Single-Step-Betrieb ablaufen lassen, Dir Registerinhalte ansehen, Breakpoints verwenden ... und das nicht im Simulator, sondern in Deinem ARM. Insight/gdb und OpenOCD sowie entweder ein "Wiggler" (simpler Parallelport-Adapter, wird auch von Andreas Schwarz hier im Shop verkauft) oder ein FT2232-basierender USB-JTAG-Adapter ("ARM USB JTAG Adapter für OpenOCD", auch von Andreas hier im Shop zu beziehen). Damit macht das Arbeiten richtig Spaß.
Das Programmieren per Makefile geht einwandfrei, aber ich muss sagen dass ich manchmal ganz schön am fluchen bin wenn ich mit OpenOCD und GDB debugge. Wenn es Crossworks ARM für OS X gäbe würde ich wohl die $149 investieren.
Ok, jetzt habe ich - so denke ich mal alles soweit hinbekommen:
Openocd-pp läuft.
Wenn ich mich mit Telnet auf Port 4444 verbinde scheint auch alles zu
gehen.
Allerdings hab ich noch eine Frage:
wenn ich z.B mit:
> armv4_5 disassemble 0x00000 100
diese Ausgabe bekomme (Auszug):
.
.
0x0000001c 0xe599820c LDR r8, [r9, #0x20c]
0x00000020 0xe3a0d004 MOV r13, #0x4
0x00000024 0xe58bd128 STR r13, [r11, #0x128]
0x00000028 0xe59ad04c LDR r13, [r10, #0x4c]
0x0000002c 0xe59cd004 LDR r13, [r12, #0x4]
0x00000030 0xe21dd001 ANDS r13, r13, #0x1
0x00000034 0x125ef004 SUBNES r15, r14, #0x4
0x00000038 0xe59ad03c LDR r13, [r10, #0x3c]
0x0000003c 0xe21ddf80 ANDS r13, r13, #0x200
0x00000040 0x01cc80b0 STREQH r8, [r12, #0x0]
0x00000044 0x11cc80b2 STRNEH r8, [r12, #0x2]
.
.
...sind das dann schon die "richtigen" Befehle des AT91SAM7S256. Weil
mich stört das armv4_5 vor dem Disassemble-Befehl. Passt das schon für
ARM7?
MfG
Peter
Ja, denn es ist nicht ARM4 (der CPU Core), sondern ARMv4 (ARM Instruction Set Version 4). Der ARM7 nutzt das ARMv4 Instructinon Set.
mal meine 0,02€: Ich habe schon ein wenig zum Thema "Signalverarbeitung" (Audio) auf dem ARM7 programmiert - in C mit dem gcc. Oftmals war ich dann erstaunt, wie enorm effizient der generierte ASM-Source ist (super-kompakt, sinnvolle Registernutzung etc.) - natürlich wenn man die Optimierungen einschaltet... Meine Erfahrung: Soll es mehr als "Hello World" sein, auf jeden Fall zu C greifen - der gcc macht seine Sache exzellent.
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.