mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32 Sorglospaket?


Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael K. (michael007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atollic ist kostenlos, wenn Du als Debugger / Programmer den ST - Link 
verwendest.

Viele Grüße,
Michael

Autor: Hitzschlag (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ride7 und RKit-ARM von Raisonance wären einen Blick wert.

Autor: Bernhard B. (schluchti)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Artikel STM32 kennst du?

Viele Links und Tipps...
Da gibts auch ein Demo-Projekt von MT mit makefile und 
Debugkonfiguration.

Autor: Eclipse-Nutzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias schrieb:
> Ich habe bereits einen J-Link sowie das allseits beliebte Dev-Board
> http://www.futurlec.com/STM32_Development_Board.shtml

Michael 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.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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 ...

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

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.