Hallo liebe ARM-Gemeinde,
möchte mich in die ARM-Welt einarbiten, nachdem ich schon einiges mit
den AVRs und WinAVR gemacht habe. Soll erstmal nur 'ne Art Fortbildung
sein.
Habe zu Hause ein kleines Modul von TaskIt mit einem AT91SAM7S256 drauf.
Habe leider noch keinen JTAG Debugger, aber es ist ja der Bootloader
drauf. Für erste "Gehversuche" reicht es. Habe ein Testprogramm mit
SAM-BA laden können.
Nun zu meinem Problem: Habe ziemlich viel Suchmaschinen benutzt, aber
bin aber es hat nicht geholfen :-( Das Testprogramm war eines aus der
WinARM Toolchain von Martin Thomas (vielen Dank für die Toolchain
Martin).
Ich würde aber gerne die CodeSourcery Lite Version verwenden, weil die
den Cortex-M3 unterstützt.
Mir ist es nicht gelungen, ein kleines Programm zum laufen zu bekommen,
weil mir folgendes nicht ganz klar ist:
1) Startup-Code: Laut Doku von CS gibt es einen Assemblerteil und danach
läüft noch ein C-Teil für die Startup Sequenz ab. Von dem C-Teil geht es
ab ins main(). Ich habe weder den C-Teil noch den Assemblerteil als
Source gefunden. Wird der automatisch dazugelinkt? Sprich der Linker
weiß es? Kann ich mir schwer vorstellen, da ja die Hardware
unterschiedlich sein kann. Wo finde ich evtl. Beispiele dafür? Hat
jemand soetwas?
Weiß jemand, wo das für CS dokumentiert ist, eine Startupsequenz zu
schreiben? Ich habe nichts brauchbares gefunden.
2) Linkerscripte sind bei CS dabei für bestimmte Boards. Wenn ich das
richtig sehe, ist da keines für einen AT91SAM7xxx dabei. Und die
CS-"general" Linkerscripte sind so vollgestopft, dass ich echt nicht
durchblicke. Kenne mich mit den Linkerscripten auch nicht besonders aus.
Hat jemand ein passendes oder ähnliches Script, passend zu meiner CPU?
Oder einen Link wie die soetwas für CS aussehen muß?
3) Frage zum Luminary LM3S6965 Evaluation Board
Dort ist eine JTAG-Schnittstelle drauf, mit der man auch externe ARMs
debuggen kann. Laut Luminary auch nur Luminary-CPUs. Kann ich mir schwer
vorstellen. Aber vorsichtshalber meine Frage, kann ich dieses EVAL-Board
auch als JTAG Debugger/Programmer für beliebiege ARM und/oder Cortex-M3
benutzen? Hat das jemand schon so benutzt und es geht ohne
Einschränkungen? Funktioniert es mit OpenOCD?
4) Letzte Frage: Wenn ich nur den Bootloader verwende, kann ich diesen
entweder mit meinem Testprogramm überschreiben (ist blöd) oder geht es
evtl. auch, ein einfaches Testprogramm so zu schreiben, dass man es für
das RAM linkt, dorthin hinter den Bootloader lädt und dann startet? Der
Bootloader hat ja einen "GO"-Befehl. Z.B wegen den Interruptvektoren
stelle ich mir das schwer vor. Oder weiß jemand, wie das geht?
Danke für Eure Hilfe.
Gruß Joachim
Joe wrote:
> Hallo liebe ARM-Gemeinde,>> möchte mich in die ARM-Welt einarbiten, nachdem ich schon einiges mit> den AVRs und WinAVR gemacht habe. Soll erstmal nur 'ne Art Fortbildung> sein.>> Habe zu Hause ein kleines Modul von TaskIt mit einem AT91SAM7S256 drauf.> Habe leider noch keinen JTAG Debugger, aber es ist ja der Bootloader> drauf. Für erste "Gehversuche" reicht es. Habe ein Testprogramm mit> SAM-BA laden können.>> Nun zu meinem Problem: Habe ziemlich viel Suchmaschinen benutzt, aber> bin aber es hat nicht geholfen :-( Das Testprogramm war eines aus der> WinARM Toolchain von Martin Thomas (vielen Dank für die Toolchain> Martin).
Freut mich, dass mein Zeug hilfreich ist. Leider komme ich nicht dazu,
dass Ganze mal auf neuesten Stand zu bringen. Einige Beispiele sind
nicht wirklich toll. Betr. Toolchain wurde ja schon eine moderne
Alternative gefunden.
> Ich würde aber gerne die CodeSourcery Lite Version verwenden, weil die> den Cortex-M3 unterstützt.
CS lite nutze ich inzwischen auch meistens. Ist schon eine gute Wahl, da
CS von ARM dafür bezahlt wird, die GNU Tools zu verbessern. Die Leute
von CS kennen sich gut aus.
> Mir ist es nicht gelungen, ein kleines Programm zum laufen zu bekommen,> weil mir folgendes nicht ganz klar ist:>> 1) Startup-Code: Laut Doku von CS gibt es einen Assemblerteil und danach> läüft noch ein C-Teil für die Startup Sequenz ab. Von dem C-Teil geht es> ab ins main(). Ich habe weder den C-Teil noch den Assemblerteil als> Source gefunden. Wird der automatisch dazugelinkt? Sprich der Linker> weiß es? Kann ich mir schwer vorstellen, da ja die Hardware> unterschiedlich sein kann. Wo finde ich evtl. Beispiele dafür? Hat> jemand soetwas?> Weiß jemand, wo das für CS dokumentiert ist, eine Startupsequenz zu> schreiben? Ich habe nichts brauchbares gefunden.
Die Fragen betreffen wohl CS3. Das muss man nicht benutzen, zumindest
habe ich es selbst noch nie benutzt, obwohl ich das Toolchain-Paket von
CS verwende. Man kann analog zu den Beispielen für andere Pakete
Linker-Script und Startup-Code "von Hand" vorgeben. CS3 ist, soweit ich
das nachvollziehen kann, nicht viel mehr als der Versuch eine Art
Standard für Linker-Scripte und Startup-Code zu definieren, der
möglichst unabhängig vom Zielcontroller ist. An sich eine gute Idee für
Leute, die sich nicht mit eigenem Startup-Code und Linker-Skripten
kasteien wollen.
> 2) Linkerscripte sind bei CS dabei für bestimmte Boards. Wenn ich das> richtig sehe, ist da keines für einen AT91SAM7xxx dabei. Und die> CS-"general" Linkerscripte sind so vollgestopft, dass ich echt nicht> durchblicke. Kenne mich mit den Linkerscripten auch nicht besonders aus.> Hat jemand ein passendes oder ähnliches Script, passend zu meiner CPU?> Oder einen Link wie die soetwas für CS aussehen muß?
Man kann auch mit CS lite einfache (=nicht "vollgestopfte")
Linkerscripte nutzen. Es ist schlussendlich immer noch eine "ganz
normale" GNU-Toolchain mit ein paar extra Dateien. Es fehlen dann aber
mglw. Definitionen, die von den mitgelieferten Startup-Codes und evtl.
der libc (Heap-End in sbrk) genutzt werden. Also entweder alles nach
CS3-"Style" oder eigene Scripte/Startup-Codes verwenden. Mischung dürfte
mehr Verdruss als Nutzen bringen.
> 3) Frage zum Luminary LM3S6965 Evaluation Board> Dort ist eine JTAG-Schnittstelle drauf, mit der man auch externe ARMs> debuggen kann. Laut Luminary auch nur Luminary-CPUs. Kann ich mir schwer> vorstellen. Aber vorsichtshalber meine Frage, kann ich dieses EVAL-Board> auch als JTAG Debugger/Programmer für beliebiege ARM und/oder Cortex-M3> benutzen? Hat das jemand schon so benutzt und es geht ohne> Einschränkungen? Funktioniert es mit OpenOCD?
Bei den neueren Eval-Boards hat Luminary etwas mehr Aufwand für den
JTAG-Teil betrieben als bei den alten LM3S811-Boards, wohl auch um das
Cortex 2-wire Debug-Interface ansprechen zu können. Mit dem alten
LM3S811 hatte ich erfolgreich AT91SAM7 über OpenOCD "flashen" können
aber das hat simples FT2232-interface (ohne SRST und TRST). Habe auch
schon Modifikationen des 811-Boards gesehen, um /SRST vom FT2232 an den
Connector zu führen. Ob das mit den LM3S69xx-Eval-Boards geht, kann man
ausprobieren, ist aber den Aufwand eher nicht wert. FT2232 "stand-alone"
Adapter wie die "kleinen" von z.B. Olimex und Amontec sind recht
günstig.
> 4) Letzte Frage: Wenn ich nur den Bootloader verwende, kann ich diesen> entweder mit meinem Testprogramm überschreiben (ist blöd) oder geht es> evtl. auch, ein einfaches Testprogramm so zu schreiben, dass man es für> das RAM linkt, dorthin hinter den Bootloader lädt und dann startet? Der> Bootloader hat ja einen "GO"-Befehl. Z.B wegen den Interruptvektoren> stelle ich mir das schwer vor. Oder weiß jemand, wie das geht?
Das kann hoffentlich jemand anderes beantworten, habe den
Atmel-Bootloader/SAM-BA vielleicht zweimal ausprobiert und auch nur zum
flashen, war mir zu unpraktisch. Es gibt aber alternative Bootloader,
die einem das 10-sec-Warte-Ritual ersparen und die gewünschte
Funktionalität bieten sollten aber nicht selbst ausprobiert.
Hallo Martin,
jetzt mit Anmeldung, heute Nachmittag ging das nicht.
> Freut mich, dass mein Zeug hilfreich ist.
Ich muß nochmal danke sagen. Ohne die WinARM Toolchain wäre ich wohl
verzweifelt. Ich habe auch schon öfter auf Deine Seite nach Tips
gegraben zu den AVRs. Mein erster JTAG-ICE war ein Evertool (der
modifizierte von myevertool). Ich war zu faul, auf Lochraster zu löten
und bei dem gab es Platinen :-)
> Leider komme ich nicht dazu, dass Ganze mal auf neuesten Stand zu> bringen.
Nun ja das ist schade, wahrscheinlich auch zu viele Projekte am laufen.
Bei mir reicht es bis nach der Rente ;-)
Mit WinARM bekommt man immerhin auf Anhieb ein Beispiel zum laufen. :-)
> Einige Beispiele sind nicht wirklich toll. Betr. Toolchain wurde ja> schon eine moderne Alternative gefunden.
Ich hatte die erst ausgewählt, da Cortex-Unterstützung drin ist.
Inzwischen hatte ich auch erfahren, dass die Jungs von ARM gesponsert
werden. Ein paar Beispiele für die CS-Lite Version wären allerdings
nicht schlecht.
> Die Fragen betreffen wohl CS3. Das muss man nicht benutzen, zumindest> habe ich es selbst noch nie benutzt, obwohl ich das Toolchain-Paket von> CS verwende.
Womit wird denn gesteuert ob CS3 verwendet wird? Mit den Linkerscripten
vermute ich. (?)
> Man kann analog zu den Beispielen für andere Pakete> Linker-Script und Startup-Code "von Hand" vorgeben.
Ja, soetwas hatte ich schon gesehen, allerdings war ich mir nicht
sicher, ob es funktioniert, wegen dem CS3 eben.
> CS3.... An sich eine gute Idee für> Leute, die sich nicht mit eigenem Startup-Code und Linker-Skripten> kasteien wollen.
Hab ich auch keine Lust zu. Aber nach Lust geht es leider nicht immer
;-)
> Man kann auch mit CS lite einfache (=nicht "vollgestopfte")> Linkerscripte nutzen.
Werde ich jetzt versuchen.
Hast du evtl. eine Art "Hello World" für mich?
Mal mein freundlichstes Gesicht aufsetze ;-)
> Ob das mit den LM3S69xx-Eval-Boards geht, kann man> ausprobieren, ist aber den Aufwand eher nicht wert. FT2232 "stand-alone"> Adapter wie die "kleinen" von z.B. Olimex und Amontec sind recht> günstig.
Da ich mir eh einen Cortex-M3 zulegen wollte, dachte ich, da wäre das
Board von Luminex eine gute Wahl. Dann hab ich das Board und ein JTAG
zusammen. Ist denke ich etwas günstiger, als beides getrennt zu kaufen.
Hmmm.....
> flashen, war mir zu unpraktisch. Es gibt aber alternative Bootloader,> die einem das 10-sec-Warte-Ritual ersparen und die gewünschte> Funktionalität bieten sollten aber nicht selbst ausprobiert.
Hmm... muß wohl nochmal 'n Riemen auf die Suchmaschine werfen ;-)
Ich danke dir soweit für deine Hilfe. Hab mich sehr gefreut :-)
Gruß Joachim
Hallo Thomas,
ich nochmal.
[activateBrain]
Nachdem ich ein wenig überlegt hatte, bin ich drauf gekommen, einfach
den Startup-Code und das Linkerscript zu nehmen und das Makefile so zu
ändern, dass er die CS-Tools aufruft. Der Linker meckerte, dass er
_isatty() nicht findet. Nun dass schnell behoben in syscalls.c und ....
HURRA! Jetzt läuft es mit der CS-Toolchain. Bin ja begeistert.
Beispiel war dein "at91sam7s64_Hello".
Habe es für den S256 modifiziert. War ja nicht so schwer. ;-)
Super! Nochmal danke.
Steht nur noch die Entscheidung an, ob ich mir einen extra JTAG kaufe.
Mal sehen. Bei Amontec nervt mich, dass die Versandkosten so sind, als
wenn sie einen berittenen Kurier schicken. Hmmm...
Gruß Joachim
900ss D. wrote:
>...>> Freut mich, dass mein Zeug hilfreich ist.> Ich muß nochmal danke sagen. Ohne die WinARM Toolchain wäre ich wohl> verzweifelt. Ich habe auch schon öfter auf Deine Seite nach Tips> gegraben zu den AVRs. Mein erster JTAG-ICE war ein Evertool (der> modifizierte von myevertool). Ich war zu faul, auf Lochraster zu löten> und bei dem gab es Platinen :-)
Hehe, die Evertool-Seite wird immer noch gut besucht. Scheint noch für
einige nützlich zu sein, v.a. für solche aus Nicht-Wohlstandsstaaten.
Benutze meine Prototypen schon eine Weile nicht mehr, da inzwischen
"offizielle" Tools im Werkzeugkoffer und Projekte mit "zu modernen"
AVRs. Myevertool ist meines Wissens in "Stase".
>> Leider komme ich nicht dazu, dass Ganze mal auf neuesten Stand zu>> bringen.> Nun ja das ist schade, wahrscheinlich auch zu viele Projekte am laufen.
Eigentlich nicht. Aber auch auf zu vielen verschiedene "Baustellen"
tätig Mikrocontroller-"Gebastel" ist nur eine davon.
> Bei mir reicht es bis nach der Rente ;-)
Ist doch prima.
> Mit WinARM bekommt man immerhin auf Anhieb ein Beispiel zum laufen. :-)
Das ist die Idee dahinter, eine Art "Batteries included" angelehnt an
WinAVR. Ursprünglich aus reinem Eigennutz entstanden, als die anderen
vorgefertigten Pakete unter Win32 noch die elende cgywin1.dll sehen
wollten und die libc/newlib nicht so gebaut war, dass newlib-lpc
funktionierte (achja, welch Freude, als seinerzeit der Timer-Interrupt
die LED auf dem LPC-P1 blinken lies). Später ist WinARM offensichtlich
auch für viele andere nützlich geworden, der kleine Server-Rechner
"raucht" gelegentlich unter der Download-Last, musste den nicht
unerheblichen Traffic schon - glücklicherweise problemlos -
rechtfertigen. sf.net wollte mich seinerzeit nicht.
>> Einige Beispiele sind nicht wirklich toll. Betr. Toolchain wurde ja>> schon eine moderne Alternative gefunden.>> Ich hatte die erst ausgewählt, da Cortex-Unterstützung drin ist.
Die Unterstützung durch den Compiler, Assembler, Linker sollte
inzwischen in allen GCC>=4.2.x/binutils>=2.18 basierten Paketen drin
sein. Die newlib ist aber meines Wissens erst in den aktuellsten
Versionen für thumb2 tauglich. Da hat CS vorher schon eigene
Erweiterungen eingebaut, die es wohl nicht immer zügig "upstream"
schaffen.
Eine gute Alternative ist noch DevkitARM aber wenn man nicht grade eine
Heimbrauerei für Spielkonsolen betreibt gibt es keinen wirklichen Grund
von CS lite dahin zu wechseln. Ausser evtl. noch man ist dogmatischer
"Open-Sourcer", denn das was-wie-wo ist bei DevkitARM genau
nachvollziehbar. Bei CS darf man sich die darin gemachten Anpassung
selbst aus einem friss-oder-stirb Quellcodepacken zusammendiffen, mglw.
inzwischen schon alles "upstream" in den GNU Quellen. Was vielleicht
noch wichtig ist: die aktuelle Version von CS (habe ich selbst noch
nicht installiert) hat wohl Fehler im gdb (arm-none-eabi-gdb), ist aber
nur Hörensagen aus der OpenOCD mailing-list, evtl. ja schon behoben.
Alternativ an man die gdb-"exe" aus einer früheren CS Version, DevkitARM
oder Yagarto nutzen, sollte nur nicht allzu alt sein.
Als weitere Alternative ist noch Anglia SARM/Idealist zu nennen, enthält
ein paar nette Beispiele für STR7/9/STM32, aus denen man einiges lernen
kann, auch wenn man Controller anderer Hersteller mit gleichen ARM-cores
nutzt.
> Inzwischen hatte ich auch erfahren, dass die Jungs von ARM gesponsert> werden. Ein paar Beispiele für die CS-Lite Version wären allerdings> nicht schlecht.
Hat sich ja bereit erledigt. Im Grund fängt man einfach damit an, in den
Makefiles arm-elf- durch arm-none-eabi- zu ersetzen und hangelt sich
dann weiter.
>> Die Fragen betreffen wohl CS3. Das muss man nicht benutzen, zumindest>> habe ich es selbst noch nie benutzt, obwohl ich das Toolchain-Paket von>> CS verwende.>> Womit wird denn gesteuert ob CS3 verwendet wird? Mit den Linkerscripten> vermute ich. (?)
Im Prinzip ja CS3 ist eine Sammlung aus Linker-Scripten, Startup-Code
und w.r.e. noch specs-Dateien. Eigenes Linker-Skript angeben (-T)
default startup-files deaktivieren und das sollte CS3 fernhalten aber ja
schon selbst herausgefunden.
>> Man kann analog zu den Beispielen für andere Pakete>> Linker-Script und Startup-Code "von Hand" vorgeben.>> Ja, soetwas hatte ich schon gesehen, allerdings war ich mir nicht> sicher, ob es funktioniert, wegen dem CS3 eben.>>> CS3.... An sich eine gute Idee für>> Leute, die sich nicht mit eigenem Startup-Code und Linker-Skripten>> kasteien wollen.>> Hab ich auch keine Lust zu. Aber nach Lust geht es leider nicht immer> ;-)
Etwas Linker-Skript know-how ist dann wichtig, wenn man etwas exotische
Sachen bastelt: teile des Programmcodes im RAM, andere im Flash,
bestimmte Sachen an festgelegten Adressen (Exceptions-Vector,
Bootloader-Code). Sicher nicht simpel aber auch kein Hexenwerk. Man muss
das Rad nicht neu erfinden: halbwegs passende Vorlage nehmen, ld-Manual
lesen, anpassen, probieren, noch mehr lesen. MAP-files und Disassembly
helfen und ersparen Debug-Sitzungen an der Hardware. Die vergleichbaren
"Scatter-load-files" der kommerziellen Tools RV und EWARM sind auch
nicht wirklich simpel - nach "Aktenlage", nie selbst daran Hand
angelegt.
>> Man kann auch mit CS lite einfache (=nicht "vollgestopfte")>> Linkerscripte nutzen.>> Werde ich jetzt versuchen.> Hast du evtl. eine Art "Hello World" für mich?
Habe ich irgendwo aber hat sich ja schon erledigt.
> Mal mein freundlichstes Gesicht aufsetze ;-)>> Ob das mit den LM3S69xx-Eval-Boards geht, kann man>> ausprobieren, ist aber den Aufwand eher nicht wert. FT2232 "stand-alone">> Adapter wie die "kleinen" von z.B. Olimex und Amontec sind recht>> günstig.>> Da ich mir eh einen Cortex-M3 zulegen wollte, dachte ich, da wäre das> Board von Luminex eine gute Wahl. Dann hab ich das Board und ein JTAG> zusammen. Ist denke ich etwas günstiger, als beides getrennt zu kaufen.> Hmmm.....
Habe weiter untern ein wenig Nähkästchengeplauder dazu geschrieben.
>> flashen, war mir zu unpraktisch. Es gibt aber alternative Bootloader,>> die einem das 10-sec-Warte-Ritual ersparen und die gewünschte>> Funktionalität bieten sollten aber nicht selbst ausprobiert.> Hmm... muß wohl nochmal 'n Riemen auf die Suchmaschine werfen ;-)
Jep, findet sich. Im Zweifel nochmal melden, habe zumindest einen
Bootloadercode irgendwo auf der Transportplatte.
>...> Nachdem ich ein wenig überlegt hatte, bin ich drauf gekommen, einfach> den Startup-Code und das Linkerscript zu nehmen und das Makefile so zu> ändern, dass er die CS-Tools aufruft. Der Linker meckerte, dass er> _isatty() nicht findet. Nun dass schnell behoben in syscalls.c und ....
Jep, diese isatty-Geschichte kam irgendwann mit einer Umstellung in der
newlib. Ist nicht CS spezifisch.
> HURRA! Jetzt läuft es mit der CS-Toolchain. Bin ja begeistert.> Beispiel war dein "at91sam7s64_Hello".
Prima.
> Habe es für den S256 modifiziert. War ja nicht so schwer. ;-)> Super! Nochmal danke.
Habe ja gar nichts gemacht ;-)
> Steht nur noch die Entscheidung an, ob ich mir einen extra JTAG kaufe.> Mal sehen. Bei Amontec nervt mich, dass die Versandkosten so sind, als> wenn sie einen berittenen Kurier schicken. Hmmm...
Zu Amontec JTAGkey/tiny vergleichbare Adapter gibt es in dem Shop, der
im Menü links verlinkt ist. Die FT2232-basierten Adapter schenken sich
nicht viel, die Belegung der GPIOs für SRST und TRST variiert und die
eingesetzten Levelshifter. Von Olimex gibt es noch einen "großen"
Adapter, bei dem man noch eine DC-Buchse an USB gehängt hat und den
zweiten Kanal des FT2232 als "seriell-USB-Adapter" nutzen kann, sind
ganz nette Bonbons aber muss man nicht haben. Von OpenOCD dürften alle
unterstützt werden, wenn nicht, ist die Anpassung des Quellcodes kein
Hexenwerk. Habe allerdings auf Basis FT2232 nur einen JTAGkey, ein von
einem Dritten selbstgebautes Teil und das LM3S811 Eval-board, kann also
zu den anderen keine Erfahrungsberichte liefern. OpenOCD unterstützt
derzeit aber noch nicht SWD für z.B. Cortex M3. Wenn richtig erinnert,
sind im CS-Packet aber "closed-source" GDB-server für LMI-Boards dabei.
Nennen sich debug-sprites o.ä., viel mehr kann ich dazu aber auch nicht
schreiben, da bis dato nicht selbst ausprobiert, das "große" LMI
Ethernet/CAN board hat es aus Zeitmangel immer noch nicht auf den
Basteltisch geschafft.
Hoppla, schon wieder längliche Ausführungen mit Plappertendenz getippst,
hoffe, zumindest irgend etwas dazwischen ist auch nützlich.
Hey man, brauchst du keinen Schlaf? Um die Uhrzeit hier posten, das
nenne ich Einsatz :-)
Martin Thomas wrote:
> Hoppla, schon wieder längliche Ausführungen mit Plappertendenz getippst,> hoffe, zumindest irgend etwas dazwischen ist auch nützlich.
Klaro ist was nützliches dabei.
Also wenn du mich fragst, manchmal ist der Verbose-Mode auch ganz
nett ;-) Passiert mir auch gerne mal. :-)
Macht natürlich das finden von Infos für andere geneigte Leser etwas
schwierig.
Danke nochmal für deine Tips und Hinweise. Werde mal sehen, wie ich
weiter komme. Wenn nicht, dann melde ich mich.
Gruß Joachim