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?
Atollic ist kostenlos, wenn Du als Debugger / Programmer den ST - Link verwendest. Viele Grüße, Michael
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.
Den Artikel STM32 kennst du? Viele Links und Tipps... Da gibts auch ein Demo-Projekt von MT mit makefile und Debugkonfiguration.
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.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.
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...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.