Hallo,
ich habe ein paar Jahre AVR-Erfahrung (mit WIN-AVR, AVR-Studio und dem
STK500) und will nun die Cortex M3 kennenlernen.
Ich habe bereits einen J-Link sowie das allseits beliebte Dev-Board
http://www.futurlec.com/STM32_Development_Board.shtml
Beim AVR-Einstieg damals war ich mit dem STK500 und AVR-Studio sehr
zufrieden, da ich mich wirklich auf die Chips konzentrieren konnte.
Einziger Kostenpunkt war das STK500.
Bei den CM3 sieht es wohl anders aus: Hier braucht man wohl eine
kommerzielle IDE mit Debugger etc., um sorglos starten zu können. Man
kann wohl Eclipse oder andere IDE wie bei YAGARTO oder CodeSourcery
verheiraten, muß aber ziemlich frickeln mit Startup, makefile und vor
allem dem GDB per Kommandozeile. Da ich zwar sehr interessiert bin, aber
jetzt im Urlaub und bei dem Wetter auch noch mehr vor habe, ist mir
meine Freizeit doch etwas wert. Allerdings scheint mir mit derzeit 120 €
als einzig "bezahlbare" Lösung Crossworks in Frage zu kommen. Ich werde
mir jetzt wohl erstmal die 30 Tage-Version freischalten lassen und dann
mal schauen.
Oder kennt jemand etwas ähnliches?
Ich verwende im Moment Keil uVision3, funktioniert echt sehr gut. Bin
total begeistert von dem Programm. Einzige Einschränkung: Du hast ne 32K
Grenze...
Bin mir aber nicht sicher ob der J-Link mit Keil harmoniert, das
müsstest du recherchieren.
Wenn du Eclipse erstmal eingerichtet hast, dann läuft es eigentlich
sorgenfrei, wenn auch mit Makefiles.
Wenn du die nicht möchtest, dann gibt es noch das ARM-Plugin für
Eclipse. Must mal gogglen. Das ist zwar nicht ganz so leistungsfähig wie
das AVR-Plugin aber es funktionirert.
Ansonsten gibt es als kostenlose IDE noch Code::Blocks. Da kannst du
auch eigene Compiler einbinden und das sogar recht komfortabel.
Tobias schrieb:> Ich habe bereits einen J-Link sowie das allseits beliebte Dev-Board> http://www.futurlec.com/STM32_Development_Board.shtmlMichael K. schrieb:> Atollic ist kostenlos, wenn Du als Debugger / Programmer den ST - Link> verwendest.
J-Link und das Futurlec-Board sind doch als vorhanden/Voraussetzung
genannt worden.
Hitzschlag schrieb:> Ride7 und RKit-ARM von Raisonance wären einen Blick wert.
S.o.
Bernhard B. schrieb:> Ich verwende im Moment Keil uVision3, funktioniert echt sehr gut. Bin> total begeistert von dem Programm. Einzige Einschränkung: Du hast ne 32K> Grenze...> Bin mir aber nicht sicher ob der J-Link mit Keil harmoniert, das> müsstest du recherchieren.
Keil läuft super mit dem J-Link. Kompilieren kann man wohl > 32 kB, aber
nicht debuggen. Keil hat aber seinen eigenen Compiler (falls man
GCC-Support aus Foren wünscht, schon ein Argument). Man kann zwar auch
einen Fremdcompiler auswählen, allerdings ist die ganze Unterstützung
durch die IDE dann dahin (Startupfile, Linkerparameter etc.); dann kann
man also gleich irgendeine Eclipsevariante nehmen. Ansonsten schade mit
den 32 kB, aber klar muß irgendwo ein Unterschied zu den teuren Lizenzen
sein. Den Anfang schafft man sicher unter 32 kB (außer großes rumgease
mit fetten Libs), aber auch die Nutzung der konkreten IDE ist richtig
Zeit. Und dann später umsteigen (müssen), ist sicherlich nicht effektiv.
Markus Müller schrieb:> Den Artikel STM32 kennst du?
Den Artikel finde ich auch ganz gut, zu Anfang war auch viel
geändert/aktualisiert worden, aber mittlerweile scheint nicht mehr viel
Bewegung zu sein. Trotzdem für den allerersten Einstieg super!
Crossworks habe ich auch gerade die 30 Tage am laufen, wegen des Wetters
allerdings wenig genutzt...
Scheint aber wirklich vollständig und vor allem professionell zu sein,
und vor allem mit GNU-Unterbau. Dieses wilde Startup- und
Linkergefrickel mit Eclipse brauche ich nämlich auch nicht. Debuggen mit
Kommandozeile, nein Danke. Der "Neben"kriegsplatz ist mir dann fürs
Hobby auch zu groß und ich werde wohl die 150 $ opfern; Geiz ist eben
nicht immer geil und hat seine Schmerzgrenze. Auch kann man sicherlich
das Programm ins RAM linken, um auch mit Hardware ohne zu flashen zu
spielen.
Was ich nur noch nicht rausgefunden habe, ob man die Personal-Lizenz
auch bei Version 2.0.8, 2.1, 3.0 etc. nutzen kann. Und wie die Kopplung
an Hardware o.ä. mit der Zeit (=> neuer Rechner irgendwann etc.)
funktioniert.
Ich habe mir heute mal YAGARTO angeschaut. Also Eclipse als Editor hat
es mir schwerst angetan.
Aber dann ...
Sofern man sich einfach an die Screenshots der Installation hält, kein
Problem. Super gemacht. Aber geschafft hat man dann außer der
Installation nix. Anscheinend muß man makefile, Linker- und Debugscript
selbst basteln, oder habe ich das falsch verstanden?
Wenn man das alles einmalig quasi als Standardvorlage hat, wär's ja echt
nicht schlimm. Im makefile CPU anpassen, im Linkerscript einstellen ob
ins RAM oder FLASH, Debugscript kann wahrscheinlich so bleiben.
Dann wäre der Vorteil von Crossworks in meinen Augen dahin. Nur leider
muß man diese Vorlagen erstmal haben (und verstehen!).
Lutz schrieb:> nicht immer geil und hat seine Schmerzgrenze. Auch kann man sicherlich> das Programm ins RAM linken, um auch mit Hardware ohne zu flashen zu> spielen.
Man kann, problemlos.
> Was ich nur noch nicht rausgefunden habe, ob man die Personal-Lizenz> auch bei Version 2.0.8, 2.1, 3.0 etc. nutzen kann.
Mein unmassgeblicher Eindruck: 2.0 gekauft => 2.x verwendbar, 3.x
Neukauf.
> Und wie die Kopplung> an Hardware o.ä. mit der Zeit (=> neuer Rechner irgendwann etc.)> funktioniert.
Mir ist keine Kopplung aufgefallen.
Hier gibts ein Demo mit allen Files drin:
http://www.mikrocontroller.net/articles/STM32#Demo-Projekte
Einfach entpacken und dann unter Eclipse mit
File >> Switch Workspace >> other
dann das entpackte Verzeichnis auswählen.
Es braucht das "GDB Hardware Debugging" Plugin.
In jedem Fall, Eclipse ist "nur" ein Editor. Er kann anhand von
einparametrierten Pfaden (includes) selbstständig die Verwiese finden
und zeigen.
Wenn der Kompiller die nicht findet, dann fehlt der Eintrag im
Make-File. Also man muss die Pfadangaben immer an 2 stellen machen,
makefile und Eclipse.
Ist ja irre: Es gibt einige fix und fertige Beispiele (wie z.B. oben
erwähnt) inkl. Debugging mit Eclipse zum Einrichten der Toolchain und
zum Spielen. Aber wenn man jetzt einfach mal anfangen will, damit z.B.
einen STM32f103RB mit YAGARTO völlig ohne irgendwelche Altlasten
(zusammenkopierte Geschichten aus anderen Projekten von denen nur die
Wenigsten wissen, was das alles bedeutet) zu programmieren, steht man ja
echt auf dem Schlauch. Da ist nix. Geht zumindest mir gerade so.
Wie machen das denn alle? Immer irgendwo was rauskopieren und
anpassen/rumfrickeln, bis es anscheinend läuft? Oder nutzen die meisten
dann doch eine kommerzielle Toolchain? Ist leider doch eine ganz andere
Liga als die guten AVR's.
Lutz schrieb:> Ist ja irre: Es gibt einige fix und fertige Beispiele (wie z.B. oben> erwähnt) inkl. Debugging mit Eclipse zum Einrichten der Toolchain und> zum Spielen. Aber wenn man jetzt einfach mal anfangen will, damit z.B.> einen STM32f103RB mit YAGARTO völlig ohne irgendwelche Altlasten> (zusammenkopierte Geschichten aus anderen Projekten von denen nur die> Wenigsten wissen, was das alles bedeutet) zu programmieren, steht man ja> echt auf dem Schlauch. Da ist nix. Geht zumindest mir gerade so.
Welche "Altlasten" sind gemeint?
> Wie machen das denn alle? Immer irgendwo was rauskopieren und> anpassen/rumfrickeln, bis es anscheinend läuft?
Kann nicht für "alle" schreiben aber zumindest ich mache das so. Wobei
man nach 2-3 Projekten nicht mehr "rumfrickeln" muss, sondern weiss, wo
etwas einzustellen ist.
- kopiere mir den Eclipse-Workspace meines letzten Projekts als Basis
für das nächste. Darin dann:
- Makefile: Quellcode-Dateien, mcu-Parameter, CFLAGS - im Grund das, was
man auch in anderen Umgebungen in "Project settings", "compiler-options"
usw. Dialogen einstellt.
- Startup-Code anpassen: auch dafür gibt es insbes. für Controller mit
Cortex-Kern meist schon etwas Fertiges vom Hersteller in dessen CMIS
Packet. Das kann man direkt oder mit minimalen Änderungen verwenden.
- Linker-Script anpassen: manchmal gibt es ein fertiges Scipt vom
Hersteller für GNU, das man verwenden kann. Wenn nicht, reicht es oft
aus, nur die Speichergrößen in der Kopie eines eigenen Scripts
anzupassen.
- OpenOCD Configuration-Script: entweder gibt es auch hier etwas Fertigs
in der OpenOCD Target-Library oder man kann zumindest eine Datei aus der
Target-Library als Basis für eigenen Anpassungen nehmen. (J-Link
gdb-server kenne ich nicht wirklich, spielt dann aber die gleich Rolle
wie OpenOCD).
- Gegebenenfalls die Debug-Launches für Eclipse gdb-hardware-debugging
für verwendeten gdb-server anpassen (J-Link gdb-server oder OpenOCD) und
das Target anpassen. Wenn überhaupt, dann sind das zumindest bei OpenOCD
nur 1-2 geänderte "monitor" Anweisungen. Hängt auch von der config-datei
ab, mit der man bei OpenOCD einiges Schicke machen kann.
Ja, das ist nicht alles ganz simpel aber auch kein Hexenwerk. Grade bei
OpenOCD ist einiges im Fluss, in letzter Zeit wird allerdings
augenscheinlich zumindest an den Nutzerfunktionen nicht mehr so viel
verändert. Vieles wurde vereinfacht aber manchmal wurden "gewohnte"
Funktionen ersetzt und man muss sich die Dokumentation genau durchlesen.
Ja, manchmal hilft auch nur ausprobieren und ja, machmal gibt es auch
Fehler in OpenOCD und/oder einem mitgelieferten Sript.
>Oder nutzen die meisten dann doch eine kommerzielle Toolchain?
Die Frage können nur "die meisten" beantworten. In Bezug auf die
Toolchain bin ich froh mit make/gcc/binutils/libc. Eclipse ist als IDE
und Debug-Frontend brauchbar, der Editor ist sehr gut. Ohne Plugin, das
die Cross-Compiler und Remote-Debugging-Funktionen gut vorkaut, ist es
allerdings manchmal etwas spröde in der Bedienung. Aber solche Plug-ins
gibt es ja (arm-gcc-plugin, Attolic, Codesourcery u.a.). Komme selbst
allerdings noch gut ohne aus (o.k., manchmal wünsche ich mir, dass ein
man Hotkeys besser konfigurieren könnte, um etwas Mausgeschiebe
einzusparen). Das Debug-Frontend bietet Source, Disassembly, Variablen,
Core-Register aber in der Standardkonfiguration ohne Plugins nicht die
schicke Funktionen, Hardwareregisterinhalte auszuwerten (z.B. ist SPI x
Control Register auf Mode y?), wie man sie z.B. von uVision kennt.
>Ist leider doch eine ganz andere Liga als die guten AVR's.
Von Seiten der GNU Toolchain (make/makefile gcc, binutils) eigentlich
nicht so sehr. Deren Bedienung ist immer gleich. Das finde ich sehr
praktisch: vieles was man bei einem Target gelernt hat, kann man bei
einen anderen wiederverwenden. Umstieg von avr-gcc/avr-libc auf MDK-ARM,
EWARM oder was auch immer wäre sicher kniffliger, wären da nicht die
IDEs der Hersteller, mit denen mal sich vieles schön zusammenklicken
kann - das ist dann AVR-Studio-look-and-feel. Rowley, Codesourcery,
Raisonance und andere setzen im Hintergrund auf die ordentliche GNU
cross-toolchain für ARM und machen diese mit ihren IDEs und/oder
Eclipse-Plugins leichter anwendbar. Das ist dann noch ännlicher dem
AVR-Studio mit avr-gcc/"WinAVR"-addon.
Ich habs zumindest so gemacht und dabei sehr viel gelernt und wenn etwas
nicht klappt finde ich viel schneller den Fehler.
Irgendwann wollte ich zum STM32 Artikel auch mal eine
Install-Anleitung mit einem Start-Demo Projekt machen. Kam aber bislang
nicht dazu.
Da ich noch nie viel Spaß daran hatte erst viel Zeit für die Config
meiner Arbeitsumbegbung zu verschwenden un lieber Entwicklen will bei
bedarf nen Support möchte hab ich mich für CrossWorks entschieden und
bin sehr zufrieden damit.
Läuft gerade mit dem j-Link super und 120€ für keine grauen Haare ist
eindeutig ok.
Vom Support bekommt man auch schnell und engagiert Hilfe
Gruß
Tom
>> Aber wenn man jetzt einfach mal anfangen will, damit z.B.>> einen STM32f103RB mit YAGARTO völlig ohne irgendwelche Altlasten>> (zusammenkopierte Geschichten aus anderen Projekten von denen nur die>> Wenigsten wissen, was das alles bedeutet) zu programmieren, steht man ja>> echt auf dem Schlauch.Martin Thomas schrieb:> Welche "Altlasten" sind gemeint?
Wie schon in der Klammer erwähnt: Man kopiert irgendwas aus einem
anderen Projekt und schaut, ob es läuft. Wenn man sich damit aber nicht
auskennt, weiß man nicht, was es damit auf sich hat. Kann irgendwas drin
sein, was vielleicht sogar diesmal egal ist, beim nächsten Projekt aber
nicht.
Generell ist die Vorgehensweise ja klar und logisch, nur wenn man am
Anfang quasi überall anfängt (und im übertragenen Sinne in immer weiter
verschachtelte Interrupts springen muß) und alles nachschlagen muß, weiß
man nach ein paar Sprüngen schon gar nicht mehr, wonach man eigentlich
ursprünglich gesucht hat. Klar lernt man dabei immens, und jetzt nach
dem Essen bin ich auch wieder etwas entspannter :-)
So als Vergleich: Übersetzte mal eine Seite DIN A 4 aus dem Finnischen
ins Deutsche. Mußt wahrscheinlich wirklich jedes Wort nachschlagen weil
das wirklich sowas von fremd ist.
Der Vergleich mit der GNU Toolchain ist richtig, stimmt aber nur unter
der Voraussetzung, daß man damit auch "core" arbeitet (und nicht ein
aufgepflanztes Helferchen benutzt, der das vor einem verbirgt). Aber
genau letzteres ist heutzutage der Punkt: Übergeordnete Software
verbirgt die Komplexizität vor dem normalen User; nur deshalb hat sich
z.B. der PC mit klickibunti und Fenstern bei der breiten Masse
durchsetzen können. Und die Konsequenz daraus ist: Es ist ein Markt
entstanden. Und ein Markt lebt vom Geld. Und wer als Hobbyist mit (und
nicht für) sowas arbeiten will, muß bezahlen. Zu letzerem zähle ich mich
jetzt wohl ...
Habe mich jetzt mal über's Wochenende weiter mit Eclipse und GCC
beschäftigt. Echt anstrengend, wenn man damit vorher noch nichts
(direkt) gemacht hat. Aber jetzt ist doch schon etwas mehr Durchblick
über die Funktionsweise bzw. das Zusammenspiel der GNU-Komponenten da
(auch wenn ich es immer noch nicht richtig bedienen kann).
Martin Thomas schrieb:> Ohne Plugin, das> die Cross-Compiler und Remote-Debugging-Funktionen gut vorkaut, ist es> allerdings manchmal etwas spröde in der Bedienung. Aber solche Plug-ins> gibt es ja (arm-gcc-plugin, Attolic, Codesourcery u.a.). Komme selbst> allerdings noch gut ohne aus (o.k., manchmal wünsche ich mir, dass ein> man Hotkeys besser konfigurieren könnte, um etwas Mausgeschiebe> einzusparen). Das Debug-Frontend bietet Source, Disassembly, Variablen,> Core-Register aber in der Standardkonfiguration ohne Plugins nicht die> schicke Funktionen, Hardwareregisterinhalte auszuwerten (z.B. ist SPI x> Control Register auf Mode y?), wie man sie z.B. von uVision kennt.
Unter arm-gcc-plugin ist http://sourceforge.net/projects/gnuarmeclipse/
zu verstehen? Habe ich jetzt auch. Die Installation war irgendwie
"witzig". Im Original steht nichts über's "wie" dabei; im Allgemeinen
heißt es immer "nicht einfach was ins plugin-Verzeichnis kopieren, das
langt nicht". Aber hier scheint es genauso zu sein. Somit werden jetzt
auch automatisch makefiles erzeugt und ich kann unter Codesourcery oder
YAGARTO auswählen.
Von Codesourcery gibt es auch ein freies Eclipse-Plugin? Attolic wohl
nur als Light kostenlos und dann auch nicht mit J-Link.
Welche Eclipse-Plugins gibt es noch, die z.B. die anderen Register (wie
z.B. das erwähnte SPI) darstellen? So einfach in Eclipse
Registervariablen einrichten (nach dem Motto Name, Adresse und Größe
angeben) scheint nicht zu sein.
Nachdem das GNUARM-Eclipseplugin makefiles erstellt, ich mir ein paar
sehr einfache Linkerscripte besorgt habe, kann ich zwar jetzt unter
Eclipse kompilieren, es aber nicht in den Chip bringen (und Debuggen
schon gar nicht). Mit Keil und Crossworks klappt das. Keil erzeugt ja
kein ELF-File (in der Eval), aber Crossworks. Und dieses kann ich auch
mit Eclipse und J-Link flashen. Also "hängt" es derzeit noch an der
Eclipsekompilierten Version sowie dem Debuggen. Denn das
Crossworks-ELF-File kann ich unter Eclipse auch nicht debuggen.
Gibt es also noch mehr/andere Plugins für Eclipse, die es einem
erleichtern?
Lutz schrieb:> Habe mich jetzt mal über's Wochenende weiter mit Eclipse und GCC> beschäftigt. Echt anstrengend, wenn man damit vorher noch nichts> (direkt) gemacht hat. Aber jetzt ist doch schon etwas mehr Durchblick> über die Funktionsweise bzw. das Zusammenspiel der GNU-Komponenten da> (auch wenn ich es immer noch nicht richtig bedienen kann).>> Martin Thomas schrieb:>> Ohne Plugin, das>> die Cross-Compiler und Remote-Debugging-Funktionen gut vorkaut, ist es>> allerdings manchmal etwas spröde in der Bedienung. Aber solche Plug-ins>> gibt es ja (arm-gcc-plugin, Attolic, Codesourcery u.a.). Komme selbst>> allerdings noch gut ohne aus (o.k., manchmal wünsche ich mir, dass ein>> man Hotkeys besser konfigurieren könnte, um etwas Mausgeschiebe>> einzusparen). Das Debug-Frontend bietet Source, Disassembly, Variablen,>> Core-Register aber in der Standardkonfiguration ohne Plugins nicht die>> schicke Funktionen, Hardwareregisterinhalte auszuwerten (z.B. ist SPI x>> Control Register auf Mode y?), wie man sie z.B. von uVision kennt.> Unter arm-gcc-plugin ist http://sourceforge.net/projects/gnuarmeclipse/> zu verstehen?
Ich kenne das Plugin nicht wirklich. Aber dessen Funktion besteht wohl
hauptsächlich darin, auch für gcc-cross-Toolchain recht einfach ein
Eclipse "managed projekt" nutzen zu können und nicht selbst Makefiles
editieren zu müssen.
> Habe ich jetzt auch. Die Installation war irgendwie> "witzig". Im Original steht nichts über's "wie" dabei; im Allgemeinen> heißt es immer "nicht einfach was ins plugin-Verzeichnis kopieren, das> langt nicht". Aber hier scheint es genauso zu sein. Somit werden jetzt> auch automatisch makefiles erzeugt und ich kann unter Codesourcery oder> YAGARTO auswählen.> Von Codesourcery gibt es auch ein freies Eclipse-Plugin?
Ein kostenloses kenne ich nicht. Meines Wissens gehören Eclipse Plugins
zu den kostenpflichtigen CS G++ Paketen.
> Attolic wohl> nur als Light kostenlos und dann auch nicht mit J-Link.> Welche Eclipse-Plugins gibt es noch, die z.B. die anderen Register (wie> z.B. das erwähnte SPI) darstellen? So einfach in Eclipse> Registervariablen einrichten (nach dem Motto Name, Adresse und Größe> angeben) scheint nicht zu sein.
Man kann sich den Wert der SF-Register über die gdb-Kommandozeile
anzeigen lassen (so mache ich das, ist spröde aber reicht mir - brauch
das nur selten) oder in eine lokale "volatile"-Variable kopieren, die
man dann in der Liste im Variables-View findet. In der STM32-Library
(wenn richtig erinnert auch bei TI/LMI) gibt es eine
"Debug-Mode"-Einstellung, bei der für jede Funktionseinheit ein C-Struct
mit "volatiles" angelegt wird, damit kann man auch ganz gut arbeiten.
Ist aber alles nicht so praktisch wie die Peripheral-Dialoge in uVision.
Das Plugin, dass die SFR "aufdrösselt" findet sich auf sf.net, irgendwas
mit SFR Eclipse, habe aber schon lange nicht mehr dannach geschaut. Beim
letzten Mal waren nur für wenige Controller Definitionen dabei. Man
konnte aber augenscheinlich selbst erweitern durch Dateien im XML Format
(war mir aber seinerzeit zu viel Aufwand für zu wenig Nutzen).
> Nachdem das GNUARM-Eclipseplugin makefiles erstellt, ich mir ein paar> sehr einfache Linkerscripte besorgt habe, kann ich zwar jetzt unter> Eclipse kompilieren, es aber nicht in den Chip bringen (und Debuggen> schon gar nicht). Mit Keil und Crossworks klappt das. Keil erzeugt ja> kein ELF-File (in der Eval), aber Crossworks.
Realview-Compiler erzeugt meines Wissens auch Dateien in einem
elf-Format, mglw. gibt es aber irgendwelche Herstellerspezifischen
Erweiterungen. Keil uVision als IDE für GNU Toolchain ruft den Linker
so, dass elf-Dateien erzeugt werden, mglw. haben die dann die
Dateiendung .axf. Man kann auf jeden Fall extern mit GNU-Tools erzeugte
elf-Dateien in uVision zum Debuggen/Simulieren verwenden.
> Und dieses kann ich auch> mit Eclipse und J-Link flashen. Also "hängt" es derzeit noch an der> Eclipsekompilierten Version sowie dem Debuggen.
Mein Vorgehensweise:
- OpenOCD wird im Hintergrund gestartet (per Eclipse "external tools")
- ich lege mehrere debug-launches an (CDT gdb hardware debugging s.u.).
Eines davon macht im Grund nichts anderes als per gdb load das
Flash-Image über OpenOCD zu schreiben und dann gdb zu beenden. Für
"Flash schreiben, reseten und dann Debuggen" und "resten und dann
debuggen" oder "ohne reset direkt reinhängen" (geht nicht bei allen
Controllern problemlos) gibt es weitere debug-launches.
> Denn das> Crossworks-ELF-File kann ich unter Eclipse auch nicht debuggen.> Gibt es also noch mehr/andere Plugins für Eclipse, die es einem> erleichtern?
cdt-hardware-debugging und das Plugin von Zylin (siehe z.B.
Erläuterungen auf yagarto.de). Bieten im Grunde gleich Funktionalität
aber das Zylin Plugin habe ich nie ausprobiert.
Martin Thomas schrieb:> Realview-Compiler erzeugt meines Wissens auch Dateien in einem> elf-Format, mglw. gibt es aber irgendwelche Herstellerspezifischen> Erweiterungen. Keil uVision als IDE für GNU Toolchain ruft den Linker> so, dass elf-Dateien erzeugt werden, mglw. haben die dann die> Dateiendung .axf.
The linker generates an output file that can only be loaded with the
µVision Debugger. Only the full version of MDK-ARM generates a standard
ELF/DWARF image as output file.
Zitat aus der Eval. Ich habe leider nur die Eval ...
Es werden .axf-Dateien erzeugt, die aber (zumindest bei mir) nicht
anderweitig zu nutzen sind (weder als .axf noch als einfach umbenannte
.elf z.B. als Import in Crossworks). Obwohl ich auch bei Keil bisher nur
den Realview-Compiler genommen habe, weil da "alles automatisch" läuft.
Martin Thomas schrieb:> Man kann auf jeden Fall extern mit GNU-Tools erzeugte> elf-Dateien in uVision zum Debuggen/Simulieren verwenden.
Gilt evtl. auch nur für die Vollversion, da ich bisher in der Hilfe und
auch den Menüpunkten der Eval nichts gefunden habe, was in die Richtung
geht. Bei Crossworks sieht das, wie gesagt, anders aus. Da "darf" man
auch mit Fremdprodukten erzeugten Code nutzen.
Martin Thomas schrieb:> In der STM32-Library> (wenn richtig erinnert auch bei TI/LMI) gibt es eine> "Debug-Mode"-Einstellung, bei der für jede Funktionseinheit ein C-Struct> mit "volatiles" angelegt wird, damit kann man auch ganz gut arbeiten.
Kannst Du da bitte etwas Anleitung bzw. einen Einstiegslink geben?
Lutz schrieb:> Martin Thomas schrieb:>> Realview-Compiler erzeugt meines Wissens auch Dateien in einem>> elf-Format, mglw. gibt es aber irgendwelche Herstellerspezifischen>> Erweiterungen. Keil uVision als IDE für GNU Toolchain ruft den Linker>> so, dass elf-Dateien erzeugt werden, mglw. haben die dann die>> Dateiendung .axf.>> The linker generates an output file that can only be loaded with the> µVision Debugger. Only the full version of MDK-ARM generates a standard> ELF/DWARF image as output file.> Zitat aus der Eval. Ich habe leider nur die Eval ...> Es werden .axf-Dateien erzeugt, die aber (zumindest bei mir) nicht> anderweitig zu nutzen sind (weder als .axf noch als einfach umbenannte> .elf z.B. als Import in Crossworks). Obwohl ich auch bei Keil bisher nur> den Realview-Compiler genommen habe, weil da "alles automatisch" läuft.
O.k., daran wird es liegen. Ich nutze die Realview-Tools fast nie und
habe mir die auch nicht so genau angeschaut. Bei GNU-Tools kann
eigentlich nur 'richtiges' elf-Format rauskommen, denn man kann die
erzeugte Datei problemlos durch diverse bintuils "jagen". Ja, GNU ist
nicht "alles automatisch" aber in den 'options for target'-Dialogboxen
halbwegs gut vorgekaut.
>> Martin Thomas schrieb:>> Man kann auf jeden Fall extern mit GNU-Tools erzeugte>> elf-Dateien in uVision zum Debuggen/Simulieren verwenden.>> Gilt evtl. auch nur für die Vollversion, da ich bisher in der Hilfe und> auch den Menüpunkten der Eval nichts gefunden habe, was in die Richtung> geht.
Funktioniert mit der Eval-Version, zumindest mit der inzwischen nicht
mehr aktuellen, die ich ausprobiert hatte. Hatte auch nichts besseres
als Eval.-Version. Man muss nur das Projekt entsprechend einrichten.
Kann fast leer sein, GNU tools und output-name (oder so ähnlich)
einstellen müsste wenn richtig erinnert reichen.
> Bei Crossworks sieht das, wie gesagt, anders aus. Da "darf" man> auch mit Fremdprodukten erzeugten Code nutzen.
Fremder als GNU-Toolchain düften die wahrscheinlich nicht sein - aber
ich weiss zu wenig über Crossworks...
> Martin Thomas schrieb:>> In der STM32-Library>> (wenn richtig erinnert auch bei TI/LMI) gibt es eine>> "Debug-Mode"-Einstellung, bei der für jede Funktionseinheit ein C-Struct>> mit "volatiles" angelegt wird, damit kann man auch ganz gut arbeiten.> Kannst Du da bitte etwas Anleitung bzw. einen Einstiegslink geben?
Sorry, grade nochmal gelesen, es hat sich etwas geändert mit V3.x.x der
StdPerLib. Weiteres aus erster Hand in ST Microelectronics AN2953,
Abschnitt 3.1.1.
Martin Thomas schrieb:> Weiteres aus erster Hand in ST Microelectronics AN2953,> Abschnitt 3.1.1.
Aha, verweist auf
STM32F10x_StdPeriph_Lib_V3.3.0/Project/STM32F10x_StdPeriph_Examples/Lib_
DEBUG/
Da werde ich demnächst doch mal nachschauen; das sieht auf den ersten
Blick sehr vielversprechend aus. Danke.
Tja, nun bin ich mittlerweile doch schon wieder viel tiefer
eingestiegen als ich ursprünglich wollte, aber außer Zeit"verlust" wird
es wohl nicht schaden...
