Hallo zusammen Trotz guter Beschreibung der STM32 Familie und deren Toolchain blicke ich nicht durch ! Huch. Ich möchte gerne für Private Projekte für Zuhause eine komplette Entwicklungsumgebung im stile einer Keil ARM-MDK auf basis von Eclipse einrichten. Welche Tools rsp. step by step vorgehen muss ich da anwenden ? kann mir da jemand helfen oder gibt es einen Link mit komplettem Tutorial ? Sorry bin Anfänger und komme einfach nicht zurecht mit Eclipse trotz oder vielleicht gerade wegen der vielen Beitrage beim googeln. ich möchte einfach ein möglichst vergleichbare Toolchain wie Keil auf basis von Eclipse für Windows XP. Gruss Yello
Nimm zum Einstieg ggf. das Atollic True Studio Lite-Version. Basiert auf Eclipse und GCC. Keine Einschränkung bei Kodegröße. Debug auch ohne Grenze, jedoch nur mit den ST-Link Debugger von STM. (Ist günstig, ca. 25 Euro, schnell und verlässig.) oder über den interen STM UART-Bootloader flashen. http://www.atollic.com/index.php/targets/stm32 Vorteil: Alles ist konfiguriert bei der Installation, läuft sofort, erste LED kann nach wenigen Minuten blinken. Auch die STM FW-Lib ist gleich mit eingebunden. Die sonst so konfuse Installation der Einzelkomponenten entfällt.
Danke für die schnelle info ! genau der Artike STM32 verwirrt ! Yargarto Tools ist ja scheinbar eine eigene Toolchain. (bei welcher laut Homepage 3 Tools installiert werden müssen) Beim Artikel unter Zusammenstellung steht: - Eclipse -Yagarto Tools -Codesourcery Light -OpenOCD -Eclipse Plugin ''GDB Hardware debugging'' Ich dachte genau in der Reienfolge sollen diese Tools installiert werden Doch unter Punkt Installation für STM32 verstehe ich die Welt dann gar nicht mehr? Da ist plötzlich die rede von Eclipse Galileo usw. Sind den die Tools im Artikel unter Zusammenstellung eigenständige Toolchanges und wenn Ja Welches ist da das beste ? Gruss Yello
Eclipse haben immer Versionsnamen. Als ich damals vor ca. einem Jahr den Artikel geschrieben habe war die Version "Galileo" aktuell. Heute ist die Version "Helios" aktuell. Daher, es reicht die Anleitung von der Yagarto-Seite zu befolgen. Schlussendlich ist es das gleiche, nur bei der Yagarto-Seite ist die Beschreibung für die aktuelle Eclipse-Version. Für völlig unbedarfte und "Neue" ist das Atollic, siehe Posting von Matthias besser geeignet, da man weniger zusammenstupfen muss. Eclipse und GCC ist Freeware und es braucht für eine lauffähige Entwicklungsumgebung nun mal die verschiedenen Tools damit es klappt.
Oben genanntes kann ich nur zum Teil bestätigen. Eclipse ist nicht wirklich intuitiv. Ich kann nur empfehlen, die Atollic-Tutorials für die IDE zu studieren. Das Importieren eines Projekts ist ein Krampf, das Hinzufügen einer bestehenden Datei zu einem Projekt ist ein noch größerer Krampf. Die Konfiguration der tool chain ist auch nicht gerade intuitiv. Und außerhalb von Eclipse ist mir die Idee der "Workspaces" noch nie begegnet. Das ist aber bei allen Eclipse-basierten IDEs so. Wenn man da erst einmal durch ist, kann man damit ganz gut arbeiten. Allerdings ist die Atollic Lite-Version etwas eingeschränkt: - gelegentlich kommt ein "Update Now" Nervfenster - es läßt sich nur ein Breakpoint setzen - im Debug-Mode werden keine Peripherieregisterinhalte angezeigt - es wird m.W. nur SWD unterstützt, kein JTAG
frame schrieb: > Oben genanntes kann ich nur zum Teil bestätigen. > > > > Eclipse ist nicht wirklich intuitiv. Dies ist ja noch gelinde ausgedrückt ! Aber erst mal vielen Dank für die Inputs. Inzwischen habe ich mich mal auf der Yagarto-Seite durchgelesen. Der Anfang klingt vielversprechend. Nur 3 Tools zum Installieren rsp. Einrichten. Doch dann die Ernüchterung beim Tutorial. Da noch ein Zusatzpacket usw. Huch !!! Ich will einfach nur anstelle der Teuren Keil Lösung im Geschäft eine günstige für zuhause (Privat). Da will man kaum 3000 Euro ausgeben. Aber vermutlich komme ich nicht drumherum mir eine kostenpflichtige Lösung wie etwa Crossworks anzulegen. Gruss yello
Ich benutze das das Ganze auch nur privat. Deswegen wollte und konnte ich dafür keine Hunderte Euro abdrücken, wo die Zielhardware (STM32 Discovery) nur ca. 10 Euro kostet. Ich habe Atollic und IAR installiert, benutze meist ersteres und komme jetzt damit recht gut zurecht. Übrigens gibt es für Atollic reichlich Tutorials, auch Step-By-Step Anleitungen von fremden Sites, die mir den Einstieg erleichtert haben. Am meisten stört mich, daß : - die IDEs (Atollic, IAR, Keil) nur unter Windows laufen - ST mit seinem Discovery den USB-Standard verletzt ((noch) kein Treiber dafür unter Linux) - man bei Atollic -jede- Installation neu registrieren muß sonst läuft die Installation nicht durch; Ein JTAG Adapter und Kauf-Compiler würde sich für mich nur bei entsprechend hochpreisiger Zielhardware oder professionellem Einsatz lohnen. GCC Crosscompiler benutze ich z.B. für größere CPUs (Cortex A8 im Beagleboard). Die Einrichtung ist wirklich nicht trivial. Man braucht entweder Erfahrung oder Zeit -UND- Frustresistenz.
Eine Alternative wäre noch, eine Linux-Partition einzurichten. z.B. Ubuntu. Da die ganze GCC-Toolchain nativ auf Linux läuft, ist darauf alles ein kleines bisschen einfacher. Ansonsten: Ja, richtig, eine Eclipse-GCC Toolchain zum Laufen zu bringen ist nicht sooo ganz einfach. Schritt-für-Schritt-Infos kann ich Dir leider auch nicht geben, da meine letzte Windows-Installation schon ein Weilchen zurückliegt. Aber glaube einem, der selber schon mehrere Male am Verzweifeln war: Es ist machbar. Und man lernt sehr viel dabei, wie so eine Toolchain funktioniert. Und WENN es funktioniert, dann ist das eine sehr feine Sache. Ein Tipp: Geh schrittweise vor, bottom-up. Also: Zuerst mal OpenOCD installieren. Dann versuchen, über die Kommandozeile mit dem Prozi zu schwatzen. Dann GCC/GDB installieren. Von Hand mal was kompilieren und versuchen, das Compilat über OpenOCD zu brennen, und dann mit GDB zu debuggen. Dann Eclipse obendrauf. Das sollte dann keine Hexerei mehr sein. Gruäss und viel Erfolg! Simon
Simon Huwyler schrieb: > Ein Tipp: Geh schrittweise vor, bottom-up. Also: > > > > Zuerst mal OpenOCD installieren. Dann versuchen, über die Kommandozeile > > mit dem Prozi zu schwatzen. > > > > Dann GCC/GDB installieren. Von Hand mal was kompilieren und versuchen, > > das Compilat über OpenOCD zu brennen, und dann mit GDB zu debuggen. > > > > Dann Eclipse obendrauf. Das sollte dann keine Hexerei mehr sein. > > > > Gruäss und viel Erfolg! > > Simon Ohh vielen herzlichen Dank für Dein Tipp¨! Das ist ja schon fast eine Step to Step Anleitung. Gruss Roger
frame schrieb: > Und außerhalb von Eclipse ist mir die Idee der "Workspaces" noch > nie begegnet. Das ist aber bei allen Eclipse-basierten IDEs so. Kann mich mit den Workspace Konzept auch nicht anfreunden. Ich würde meine C-Projekte lieber in einzelne Ordner legen, dorthin wo auch die anderen Projektdateien sind. Ginge nur, indem man immer einen anderen Workspace anlegt. Ein neuer Workspace mit einen kleinen C-Projekt besteht aus 17 MByte mit 331 Verzeichnissen und 471 Dateien. Fraglich, was das soll...
Simon Huwyler schrieb: > Ein Tipp: Geh schrittweise vor, bottom-up. Also: > > Zuerst mal OpenOCD installieren. Dann versuchen, über die Kommandozeile > mit dem Prozi zu schwatzen. > > Dann GCC/GDB installieren. Von Hand mal was kompilieren und versuchen, > das Compilat über OpenOCD zu brennen, und dann mit GDB zu debuggen. > > Dann Eclipse obendrauf. Das sollte dann keine Hexerei mehr sein. Nun bin ich ein wenig verwirrt auf der Yagarto Homepage sind folgende Tools zum Installieren beschrieben: Introduction For a complete C/C++ development system we need the following components: 1. GDB Server 2. Native GNU ARM toolchain for windows 3. Integrated Development Environment Entpricht nun der GDB Server dem OpenOCD ? der GNU ARM toolchain dem GCC/GDB und 3. IDE dem Eclips (das einzige was mir klar ist) Gruss Roger
GDB-Server ist nicht OpenOCD. GDB-Server: Debug-Tool, das anhand der kompilierten ELF Datei mittels TCP/IP Kommandos mit einem Prozessor debuggen kann. OpenOCD: Tool, das über TCP/IP die Befehle vom GDB-Server entgegen nimmt und diese auf die JTAG Hardware (über USB) umsetzt. Damit wäre folgendes denkbar: Mikrocontroller > JTAG-Interface > USB > PC mit OpenOCD > Internet-Verbindung > PC mit Eclipse und GDB-Server Somit ist ein Remote-Debug eigentlich kein Problem...
Markus Müller schrieb: > GDB-Server: > Debug-Tool, das anhand der kompilierten ELF Datei mittels TCP/IP > Kommandos mit einem Prozessor debuggen kann. nicht ganz korrekt. Das, was Du beschrieben hast, ist GDB, das geht in obiger Beschreibung unter "Toolchain". Da wir aber remote-Debugging machen, braucht GDB einen Server. Das kann zum Beispiel OpenOCD sein. Insofern stimmt unter dem Strich schon, was Du geschrieben hast. Nur die Nomenklatur stimmt nicht ganz. OpenOCD = GDB-Server Gruäss Simon
Das ganze ist sehr verwirrend, ich weiss. Darum mal einige Worte dazu, warum das so kompliziert gemacht wurde. Die "Toolchain" beinhaltet einen Compiler, Assembler, Linker, diverses anderes nützliches Zeug, um aus C-Code Executables zu machen - und eben: GDB, sein Debug-Tool. Üblicherweise schreibt man damit Code, der auf der selben Maschine, auf der er geschrieben und compiliert wurde, auch laufen gelassen und getestet wird. Und zum Testen steht Dir GDB zur Verfügung. Nun nehmen wir mal an, Du schreibst Code für ein Ebedded Linux system. Auf dem willst/kannst du Deine IDE (Eclipse) sowie die ganze Toolchain, also Comiler etc. und GDB nicht laufen lassen. Das soll auf einem (Linux-) PC daneben geschehen. Um nun mit GDB auf dem Target (das Embedded-Linux-Maschinchen) testen zu können, musst Du auf dem Target einen GDB-Server installieren. Mit dem kann GDB, z.B. über Ethernet, schwatzen. Ok. Wir haben aber nicht mal ein Embedded-Linux-System. Wir haben einen kleinen Furz, der nicht mal annähernd genug brains hat, um einen GDB-Server, geschweige denn Linux laufen zu lassen. Was machen wir also? Wir debuggen über JTAG, schwatzen also direkt mit dem Prozi. Nun gibt es zwei Möglichkeiten: 1. (so hat man's nicht gemacht) Man schreibt für GDB ganz neue Interfaces, mit denen es über JTAG mit Prozis reden kann. Für jeden Prozi ein eigenes, notabene. 2. (so hat man's gemacht) Man sagt sich: Scheiss drauf, WO der GDB server ist. Der kann doch auch auf dem Host-Rechner, also auf dem selben Rechner wie GDB hocken. Man schreibt also einen GDB-Server, der weiss, dass er nicht selber auf dem Target hockt, sondern über JTAG mit dessen Prozi schwatzt. Und das ist OpenOCD. Jetzt muss sich GDB nur noch über Localhost mit OpenOCD verbinden, glaubt, es rede direkt mit dem Target, und alles funktioniert wie am Schnürchen. Gruäss Simon
Hallo Simi Super !!! Vielen dank Deiner ausführlichen Beschreibung. Gruss Roger PS: Tja warum einfach wenns auch kompliziert geht ! Lustig finde ich auch die Bemerkung auf der Homepage von Yagarto: YAGARTO is a hobby project and supported only by the community. If you want a faster start, a smoother workflow and professional support, take a look at a commercial toolchain like CrossWorks for ARM. Mal schauen ob ich die Geduld und vorallem den Biss habe bei diesem Hobby Projekt YAGARTO zu bleiben. Schon beim Linux musste ich schlussentlich die Flinte ins Korn werfen ! Nachdem dann selbst die Linux gemeinde zum schluss kam Rechner ungeeignet für Linux. Ein herber Schlag für all meine Kollegen die behaupteten Linux sei unkommpliziert und einfach auf jedem Rechner installierbar. Das ist aber natürlich ein anderes Kapitel. Gruss Roger
Hallo, ich muss mich nun auch einmal zu Worte melden. Das Problem das die Installation mittels Eclipse und der diversen Tools ein wenig Irreführend ist kann ich nur bestätigen. Ich habe mit den selben Problemen zu kämpfen gehabt. Mittlerweile läuft alles soweit, mit der Ausnahme (zum OpenOCD) das ich den GDB-Server von Truestudio benutze. Dies hat den Grund das auf dem Discoveryboard direkt ein "abgespekter??" ST-Link vorhanden ist und ich persönlich ebenfalls im Besitz eines ST-Links bin. Derzeit bin ich dabei, ein kleines Tutorial zu schreiben in der ich die installation von Eclipse (wenn man das so bezeichnen darf) und CodeSourcery/Yatargo sowie diversen Plug-Ins näher erläutern möchte. Ich werde in diesem Tutorial jeden Schritt erklären - jedoch auch eine kleine Erklärung dazu schreiben warum dies so ist - man siehe es mir nach wenn diese Informationen eher Oberflächlicher Natur sein wird. Ich bin nun mit diesem Tutorial angefangen - aber bei weitem nicht fertig. Sobald dies der Fall sein wird (ich hoffe das ich es nächstes Wochenende schaffe) werde ich dieses entsprechend im STM32 Artikel veröffentlichen.
Hallo Björn Wow das wäre fantastisch ! Bin nähmich schon wieder am anschlag und komme mir vor wie ein Vollidiot ! Huch sorry bin halt ein Anfänger was die Eclips Geschichte anbelangt. Nun zu meiner Frage: Laut Yagarto Tutorial folgendes: Download and install For our GDB Server we need the following components here: 1. J-Link "Software and documention pack" 2. YAGARTO Tools (like make, sh, rm, cp and mkdir) 1. J-Link "Software and documention pack": The J-Link is developed by SEGGER, therefore you can download the latest software from the SEGGER J-Link ARM software page. Download the "Software and documentation pack", expand the zip file, and start the setup program. For more information about how to install and setup the J-Link itself, take a look in the J-Link manual (pdf, about 2MB), which can be found at the following SEGGER page. Jetzt kommt da plötzlich noch eine J-Link Software ins spiel ????? Heist das dass die ganze YAGARTO-geschichte nur mit dem SEGGER J-Link funktioniert ??? Gruss Roger
nein, Yagarto beinhaltet nur die Routinen für Make, den Compiler, Linker
usw. Was nun erst einmal komplett unabhängig vom Debugger ist.
Das J-Link ist dafür, um den J-Link Debugger an's laufen zu bekommen.
Der Grund ist folgender, GDB selbst ist ersteinmal Debugger unabhängig,
die Treiber jedoch bzw. der Befehlssatz des Debuggers ist es nicht
(Sofern ich da nun falsch liege bitte korrigieren). Demzufolge benötigst
du eine Software, die den Debugger ansprechen kann und ggF. den
Befehlssatz auf den GDB-Befehlssatz mappen kann. Dazu dient die J-Link
Software oder in meinem Falle das True-Studio (nur ausgewählte Programme
{den GDB-Server}).
Das heisst ich muss auch im Falle eines Amontec JTAGKey2 die J-Link Software von SEGGER installieren ? Gruss Roger Und vielen Dank für die jeweils schnellen Antworten !
Nein. Die erwähnte JLINK-Software ist nun eben wieder so ein GDB-Server. Einer, der explizit nur mit JLINK redet. OpenOCD kann mit recht vielen Geräten reden, auch mit JTAGKey2, und übrigens auch mit JLINK. Gruäss Simon
@Björn Cassens Ja, ein Tutorial wäre super! Am besten es als Artikel hier erstellen und zum Artikel STM32 verlinken, dann kann das auch jeder Erweitern... Mache dann auch einen Thread auf, dann wissen es alle. Letztens habe ich auch neu installiert und bin anhand der Yagarto-Seite vor gegangen, das hat gut geklappt.
"Unfortunately it is not allowed to distribute binary version of OpenOCD, which is linked to the proprietary library FTD2XX provided by FTDI." Das ist eben der Schmarren an OpenOCD, wenn man mit Windows arbeitet. Kommt es für Dich in Frage, Deinem Rechner eine Linux-Partition zu gönnen? Das macht das ganze Eclipse-GDB-OpenOCD-Zeug einfach viel einfacher. Ansonsten: Das allerwichtigste ist jetzt erst mal Punkt eins, den ich oben nannte: OpenOCD (oder halt einen anderen GDB-Server) zum Laufen zu bringen. Mit Kommandozeile. Für Windows kann ich da leider nichts dazu sagen. Ich hatte damals, als ich noch ein Windowsianer war, ein Build installiert, bevor die Anwälte kamen und Build-Downloads verboten. Aber irgendeine Möglichkeit wird es auch heute sicher noch geben. Wenn Du den mal hast, ist der Rest vermutlich ein Klacks. @Markus: Hast Du OpenOCD installiert? Habe gerade das gesehen: http://forum.sparkfun.com/viewtopic.php?f=18&t=11221&sid=a6281a6a89fcc34dc173dce4b463618c Dazu benötigst Du aber doch wieder Cygwin (logischerweise).
Hallo, was innerhalb von 30 Minuten zum Ziel führt und das sogar unter Linux ist folgende Kombination, einen Segger J-Link vorausgesetzt. Eclipse CDT installieren. Als IDE. http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr2 GNU ARM Plugin für Eclipse. Damit man sich nicht selber um Makefiles kümmern muss. So kann dann auch einfach ein Sourcery G++ Projekt angelegt werden. http://sourceforge.net/projects/gnuarmeclipse/ Sourcery G++ Lite installieren. Das ist der Kompiler, Linker usw. http://www.codesourcery.com/sgpp/lite/arm/portal/release1592 Segger J-Link GDB Server für Linux/Windows. Unbedingt das Readme lesen, da wird für die Linux Version genau gesagt wie man den GBD startet usw. http://www.segger.com/cms/jlink-software.html Wenn man das alles installiert hat, gibt es nur noch 3 Hürden zu nehmen. 1.) Man braucht ein Linker Script für seinen uC. 2.) Man braucht den *.asm Startup Code. 3.) in Eclipse muss der GDB eingerichtet werden. -3.) GBD nach diesem Tutorial einstellen: http://deneb.homedns.org/things/?p=113 -2.) STM32 Firmware Lib runterladen und im Ordner
1 | STM32F10x_StdPeriph_Lib_V3.4.0/Libraries/CMSIS/CM3/DeviceSupport/ST/STM32F10x/startup/gcc_ride7/ |
die passende Datei für den uC auswählen. Beispielsweise für einen STM32F103RB wäre es die Datei:
1 | startup_stm32f10x_md.s |
Die kommt ins Hauptverzeichnis des Eclipse Projekts und wird am Ende von .s zu .asm umbenannt. -1.) Das Linker Script nimmt man auch aus der Lib:
1 | STM32F10x_StdPeriph_Lib_V3.4.0/Project/STM32F10x_StdPeriph_Template/TrueSTUDIO/STM3210B-EVAL/ |
Wenn man das Script öffnet steht ziemlich weit oben folgendes:
1 | Abstract : Linker script for STM32F103VB Device with |
2 | ** 128KByte FLASH, 20KByte RAM |
Das passt also für den STM32F103RB. Das Script kommt auch ins Hauptverzeichnis, muss aber auch noch in den Projekt Einstellungen beim Linker angegeben werden. Siehe auch: Beitrag "STM32 + Eclipse -> Hilfe" Diese Anleitung sollte auch in den STM32 Wiki Eintrag finde ich. Wer Fragen hat, einfach melden. Bei mir läuft diese Kombination unter Windows und Linux. Viele Grüße Daniel
Ach was ich vergessen hab. Man muss auch das GDB Hardware Debugging Plugin für Eclipse installieren...
Angehängte Dateien:
-
EclipseNewProject.png
15 KB
Matthias K. schrieb: > Kann mich mit den Workspace Konzept auch nicht anfreunden. Ich würde > meine C-Projekte lieber in einzelne Ordner legen, dorthin wo auch die > anderen Projektdateien sind. Ginge nur, indem man immer einen anderen > Workspace anlegt. Ist zwar etwas offtopic, aber das oben zitierte stimmt nicht. Die Projekte müssen nicht zwangsweise im Workspace-Ordner liegen. Man kann sich irgendwo ein Workspace anlegen und dann das eigentliche Projekt außerhalb, also z.B. in dem eigentlichen Projektordner wo der Rest dazu auch liegt. Wenn man ein neues Projekt anlegt, wird nach der Location gefragt (siehe Screenshot im Anhang). Default ist immer im Workspace, aber man kann die Default-Location ändern. In dem Workspace entsteht ein Eintrag zu dem Projekt, aber die eigentlichen Projektdateien liegen dann in der Project-Location, die man angegeben hat.
Hallo Zusammen Das ganze ist ja echt zum Kotzen ! Hab mir nun einfach mal stur ohne wirklich den Durchblick zu haben Step by Step die nötigen Dateien runtergeladen und diese versucht zu installieren ! Nun der Hammer Beim eclipse-platform-3.6.2-win32.zip wird ein Passwort verlangt. Hab noch versucht die Datei von verschiedenen Quellen runterzuladen. Aber immer das selbe. Beim entzippen wird ein password verlangt !! Was soll das kann mir da jemand weiterhelfen ?? Gruss Roger PS: An Simi: Nein leider (Oder zum Glück) kann ich bei meinem Rechner (HP TouchSmart) kein Linux draufkriege !! Ich muss also eine Windows Eclipse Umgebung einrichten
Hier geladen? http://www.eclipse.org/cdt/ Diese Beschreibung genutzt? http://www.yagarto.de/howto/yagarto2/index.html Ich hab vor ein paar Wochen das gleiche gemacht und es klappte, ohne Passwort!
Markus Müller schrieb: > Hier geladen? > http://www.eclipse.org/cdt/ > > Diese Beschreibung genutzt? > http://www.yagarto.de/howto/yagarto2/index.html > > Ich hab vor ein paar Wochen das gleiche gemacht und es klappte, ohne > Passwort! Ja genau gemäss Yargarto !!! Aber eben hab es auch noch von anderen Quellen versucht. Das ganze scheint mir das selbe debakel wie Linux zu sein !!!!!!!!!! Ich möchte mich eigentlich nicht mit unzulänglichkeiten des Systems abkämpfen müssen, sondern so schnell wie möglich mich der eigentlichen Anwendung widmen können. Aber wen wunderts Eglipse kommt ja auch aus der Linux Ecke !! (Zu viele Köche verderben den Brei) Gruss roger
Hier ist der Eclipse-Download: http://www.eclipse.org/downloads/ "Eclipse IDE for C/C++ Developers, 87 MB" Den CDT-Download muss man dann mittels Eclipse, wie in der Anleitung gezeigt öffnen.
Ja, es ist Freeware, wustelkram, kostenlos, zig Teile müssen wie ein Zahnrad zusammen spielen, wenn nur ein Bug in einem Rädchen ist fällt das ganze wie ein Kartenhaus zusammen. Dafür: Unbegrenzte Codegröße für kostenlos* (*ein paar Tage Einarbeitung und das ganze verstehen) Bei einer Firma, die 3 Progger beschäftigt kann sich das schnell rechnen. Oder man kauft mich ein und ich richte das ganze innerhalb weniger Stunden ein +Schulung (als Dienstleistung, nicht Software)
Markus Müller schrieb: > Hier ist der Eclipse-Download: > http://www.eclipse.org/downloads/ > > "Eclipse IDE for C/C++ Developers, 87 MB" > > Den CDT-Download muss man dann mittels Eclipse, wie in der Anleitung > gezeigt öffnen. Und warum ist dieser Link nicht auf der Yagarto homepage ? Nun auf jedenfall vielen dank für den Link Gruss Roger
zuckerle schrieb im Beitrag #2139891: > Autor: > > zuckerle (Gast) > > Datum: 10.04.2011 23:31 > > Oh gott ist das ein Wuselkram. > Denn lieber Geld in die Hand nehmen und was > ordentliches kaufen. Wie recht Du hast ! Allzulange tu ich mir dies nicht mehr an ! Rsp. nehme halt die 150$ in die Hand und nehme Crossworks. Aber eben es reizt mich eben doch diese Geschicht zum lauffen zu bringen. gruss Roger
Roger Schweizer schrieb: > Hab mir nun einfach mal stur ohne wirklich den Durchblick zu haben > Step by Step die nötigen Dateien runtergeladen und diese versucht zu > installieren ! Genau da liegt Dein Fehler! Hast Du meinen Rat mal befolgt, Schritt für Schritt vorzugehen? Nur eben nicht stur, sondern überlegt? Richtig, so eine Toolchain zu installieren, ist nicht P'n'P. Jetzt kann man - wie Du gerade in Deinem Frust - darüber schimpfen, dass es, wie Linux, ein Murks ist, und dass Du Dich lieber mit der eigentlichen Anwendung beschäftigen willst - oooooder: Du betrachtest Diese Installation als Teil der Herausforderung. (Ich gehe mal davon aus, dass Du das aus Spass/als Hobby machst.) Eins kann ich Dir sagen: Wenn Du wie von mir vorgeschlagen vorgehst, weisst Du nachher, wie das Ganze funktioniert. Und wenn ein Rädchen nicht drehen will, weisst Du, welche Rädchen Du überprüfen musst. Wenn Du aber einfach drauflosinstallieren willst, und keine Ahnung hast, was das eigentlich für Komponenten sind, die Du da installierst, kann das nicht gut gehen. Das ist kein Murks - wie auch Linux kein Murks ist. Aber es ist halt einfach nicht P'n'P. Das musst Du akzeptieren. Oder für viel Geld (es gibt einen Grund, warum die so viel kosten) für eine P'n'P Toolchain investieren. Von wegen: Ist ja klar, es kommt halt auch aus der Linux-Ecke: Ja, richtig. Das ist ein wesentlicher Grund, warum es für Dich jetzt so mühsam ist. Weil es aus der Linux-Ecke kommt. Und Du es auf Windows prügeln willst. Da gibt's nun mal Reibungsverluste. Ich könnte genausogut über Microsoft lästern. Denn es ist verflucht schwierig, deren Programme auf Linux zum Laufen zu kriegen. Diese Idioten von Microsoft kriegen das einfach nicht hin, ihre Tools vernünftig zu programmieren, damit sie auch sinnvoll unter Linux laufen. Kann man sich das vorstellen? ;-) Also: Mit Deiner Einstellung gegenüber Linux solltest Du wirklich auf gekaufte Tools gehen. Das ist keine Polemik, sondern begründet sich in der Tatsache, dass Du mit einer GCC-Toolchain knöcheltief in GNU (was für Nich-Linuxer dasselbe ist wie Linux) eintauchst und Dich mit diesen Konzepten befassen MUSST. Gruäss Simon
Hallo Simi Da gebe ich Dir völlig recht. Ich hatte nicht die Geduld mir in einem ersten Schritt OpenOCD zu verinnerlichen ! Hab dann einfach mal versucht die schritte gemäss Yagarto zu verfolgen, um dann meinen frust auf die Linux-Gemeinde abzulassen. Da es für mich wie Du richtig erkannt hast nur Hobby und Herausforderung ist werde ich auch nicht so schnell aufgeben. Ich bleibe dran bis es läuft !! Ich bin auch offen gegenüber Linux nur eben wie schon gesagt meine abneigung gegenüber Linux hat Linux sich schon selber zu verdanken. Das Teil läuft wirklich nicht auf meinem rechner. Ein Linux Fanatiker hat mir dann gesagt erst Liste der unterstützten Rechner konsultieren dann Rechner kaufen und erst danach Linux installieren. Vielen dank für Deine Tips Gruss Roger
Yagarto ist ein Hobby Projekt! Wieso sollte man sich das antun wenn man ein Profi Produkt für lau bekommen kann? Sourcery G++ Lite Edition ist kostenlos! Wenn man das so kaufen möchte, dass man nichts mehr selber einstellen muss kostet das ab 399$. Wenn allerdings die erste Hürde schon die Installation von Eclipse ist, wird es natürlich etwas schwieriger mit der Toolchain, da die naturgemäß ja aus mehreren Programmen besteht...
yello8247 schrieb: > Ich bin auch offen gegenüber Linux nur eben wie schon gesagt meine > abneigung gegenüber Linux hat Linux sich schon selber zu verdanken. > Das Teil läuft wirklich nicht auf meinem rechner. Ist zwar OT: Nö, das hat Linux nicht sich selber zu verdanken, sondern den HW-Herstellern. Linux läuft nämlich super. Aber wenn man natürlich für jeden Treiber erst mal die HW reverse engineeren muss, geht's halt etwas länger.
HI, also ich habe Eclipse, mit CodeSourcery und J-Link bei mir unter Win7 x64 zu laufen. Ich hatte aber mit Yagarto auch keine Probleme das einzu richten nur beim Debuggen hatte ich Fehler aber dazu gibt es einen guten Thread hier der die Einstellungen des J-Link GDB durch probiert :) Versuche es doch mal so: Eclipse CDT installieren GNU ARM plugin installieren (Link habe ich gerade nicht zu hand) GDB Hardwaredebuggin plugin installieren Codesourcery GCC Lite installieren dann in Eclipse ein Prijekt erstellen als ARM Codescourcery Projekt. Ein mein Beispiel Projekt dafür geistert hier auch noch um her Beitrag "Re: STM32 ST-Library Einstieg" Du wirst dich aber damit abfinden müssen dich mit den Tools zubeschäftigen. Aber man versteht dann auch Fehler besser. MfG Tec
>Du wirst dich aber damit abfinden müssen dich mit den Tools >zubeschäftigen. Insbesondere auch dem makefile und dem Linker-Script. Wenn man das grob verstanden hat, kann man nette Sachen machen wie z.B. einzelne Programmteile in bestimmte Flash-Positionen linken, womit man ein Bootloader im gleichen Quellcode wie die Applikation proggen kann. Ich denke, wenn man das mit den kommerziellen Tools machen möchte, dann muss man sich auch einlesen/verstehen. Ich habe auch mehrere Anläufe gebraucht, aber hab es hin bekommen. Das lag vor allem daran dass vor ein paar Jahren die ganzen Tools noch nicht richtig funktioniert haben und es im Internet nur begrenzt Lösungen/Hinweise/Anleitungen gab. Das ist heute, danke Eclipse/Yagarto/STM32-Artikel doch viel einfacher geworden.
Hallo, bei mir läuft jetzt auch alles unter Eclipse (statt unter Atollic). Als gdb-server benutze ich den von Atollic, da er mit dem STLink auch im SWD-Modus kann. Meine Frage: Beim Einstieg in die Peripherieprogrammierung vermisse ich eine Möglichkeit die Register von Timer, UART und Co auch mal zu sehen. Wenn ich ein Watch auf *TIM4 oder TIM4->SR mache kommt leider nichts raus. Der Degugger zeigt einfach die SFR Werte nicht an. Hat jemand ne Lösung?. Danke, Adib.
>Hat jemand ne Lösung?.
Sourceforge: Embsysregview.
HDH.
Frizz
Mal ne bescheidene Frage: Willst du programmieren ODER debuggen ODER dich mit den Befindlichkeiten von überfetteten Entwicklungsumgebungen herumschlagen? Bei Controllern von ST geb ich dir ein paar gute Ratschläge: 1. benutze zumindest für den Anfang die Originaltools von ARM, sauge dir also die bei Keil herunterladbare Toolchain. Zum eigentlichen Übersetzen schreib dir eine simple Batchdatei und zum Editieren nimm deinen Lieblingseditor. Die IDE von Keil laß einfach links liegen. 2. um den Code in den Chip zu bekommen benutze den eingebauten Bootlader des IC zusammen mit dem Programmiertool von ST. 3. mache einen RIESENBOGEN um die ST-Treiberlibrary. Die taugt nix und bauscht alles nur auf. We sich darauf einläßt, kriegt Pickel... Lies dich stattdessen in das dicke Referenzmanual ein, wenngleich das auch ein extrem hartes Brot ist. 4. schaff dir auf dem Zielsystem erstmal ein Minimalst-System, also seriell per simplem Polling rein und raus, ein paar Kommandos usw. Damit hast du wenigstens eine eigene Basis für das, was du eigentlich mit dem Chip machen willst. 5. Wenn du dann noch Lust auf Frust haben solltest, kannst du ja immer noch dir so eine Eclipse, GCC usw. installieren und dich damit herumschlagen... Alles Gute W.S
W.S. schrieb: > Mal ne bescheidene Frage: > Willst du programmieren ODER debuggen ODER dich mit den Befindlichkeiten > von überfetteten Entwicklungsumgebungen herumschlagen? > > bla bla bla So eine unqualifizierte Aussage. Ich nutze Eclipse + CodeSourcery Lite + JLink schon lange und es funktioniert sehr gut. Da ich mich mit Eclipse auskannte, war das einrichten schnell erledigt. Das alles ergibt eine vernünftige Arbeitsumgebung mit der man sehr gut arbeiten kann. Der Einstieg ist nicht so einfach, das ist wahr. Und mein Lieblingseditor ist schon Eclipse. Da muß erstmal ein Editor rankommen. Ich nutze allerdings auch dort Makefiles ein, weil die einfach flexibler und übersichtlicher sind als die Buildproperties innerhalb Eclipse. Die ST Lib ist zum nachschlagen nicht schlecht, effizienter kann man es selber besser machen. Die Funktionen, die ich genutzt habe funktioierten.
Daniel R. schrieb: > Wenn allerdings die erste Hürde schon die Installation von Eclipse ist, > wird es natürlich etwas schwieriger mit der Toolchain, da die naturgemäß > ja aus mehreren Programmen besteht... Hallo Zusammen Habs entlich geschaft wenigstens die Tools gemäss Yagarto zu installieren. Allerdings erst alls ich per Zufall bemerkt hatte das ich Zip-Datei für ein unzip eine Ordnereben höher gehen musste !!!!! Was für eine scheisse !! Die einem unnötig zeit raupt ! Morgen werde ich nun versuchen das ganze noch richtig einzurichten ! Gute Nacht und danke für die vielen Antworten Gruss Roger
W.S. schrieb: > 3. mache einen RIESENBOGEN um die ST-Treiberlibrary. Die taugt nix und > bauscht alles nur auf. We sich darauf einläßt, kriegt Pickel... Lies > dich stattdessen in das dicke Referenzmanual ein, wenngleich das auch > ein extrem hartes Brot ist. Das sehe bestimmt nicht nur ich etwas anders. Die LIB ist gerade zum Einstieg gut geeignet. Zu jeder Peripheriekomponente sind Beispiele drin. Man hat schnell ein Erfolgserlebnis, was mit den über 1000 Seiten des Ref.-Manuals bestimmt nicht gelingt. Mag sein, dass die LIB vom Quellcode etwas überladen aussieht, wenn man jedoch sich mal genauer damit beschäftigt erkennt man, das in den Funktionen praktisch nur die betreffenden SFR gesetzt oder gelesen werden. Sollte dies zeitlich ein Problem sein, hat man sowieso den falschen µC ausgewählt.
Matthias K. schrieb: > Mag sein, dass die LIB vom Quellcode etwas überladen aussieht, wenn man > jedoch sich mal genauer damit beschäftigt erkennt man, das in den > Funktionen praktisch nur die betreffenden SFR gesetzt oder gelesen > werden. Genau DAS sehe ich ganz anders - und es IST auch ganz anders. Wenn du dir mal die Mühe machen solltest, z.B. das SD-Interface in Betrieb nehmen zu wollen, dann würdest du spätestens beim Debuggen feststellen, daß in einigen Programmteilen alles mitgeschleppt wird ,also dort z.B. die Polling-Version, die Interrupt-Version und die DMA-Version. Dazu werden irrsinnig viele structs und statische Variablen dazu angelegt, die mit der eigentlichen Hardware garnix zu tun haben. Dazu gehören auch massenweise Plausibilitätsprüfungen von Aufrufen, die selbst aus der ST-Lib kommen. Bei Aufrufen, die ein Benutzer in senen Quellcode schreibt, wäre das ja noch zu verstehen, aber innerhalb der Lib?? Und dann stelle ich mir mal vor, wie man sich beim Debuggen totsucht. Nee, diese Lib macht so eine Art Zwischensphäre mit eigenen Begrifflichkeiten zwischen dem Nutzprogramm und der Hardware auf, ohne selbst irgendwelche echten Leistungen (z.B. eigene Fehlerbehandlung, eigene Initialisierung, eigene Geräteverwaltung) zu bringen. Man muß sich also nicht nur mit dem Manual herumschlagen, sondern obendrein auch noch mit all den von der Lib zusätzlich eingeführten Dingen. Viel Wust, viel toter Code, wenig Nutzen. Eigentlich GAR KEIN Nutzen, denn ein Neuling, der damit eine fertige Demo auf einem fertigen Demo-Board zum Laufen gebracht hat, hat von dem eigentlichen Chip noch nix gelernt. Das jähe Erwachen, wenns vom DemoBoard und DemoSoft zum eigentlichen selbst zu entwickelnden System geht, kommt dann, wenn der Betreffende bereits glaubt, genug von dem Chip verstanden zu haben... W.S.
W.S. schrieb: > Eigentlich GAR KEIN Nutzen, denn ein Neuling, Warst du auch solch ein Neuling? Hört sich so an! ;-)
Ich bin ein ST-Lib-Fan. Ich nutze diese sehr gerne, denn die Demos zeigen einem fast alles. Trotz dieser Lib, die viel extra Code generiert lasse ich meine CPU meist nur mit 8MHz (ohne PLL) laufen, denn der STM32 ist immer noch schnell genug für alles und das spart ein paar mA Strom. So schlecht ist die Lib nun auch wieder nicht!
Geschaft !!! Habs nun soweit hingekriegt das ich ein erstes Demo-Projekt Compilieren konnte. Das einrichten des GDB Server werde ich erst bewerkstelligen wenn ich den JTAGKey erhalten habe. Herzlichen dank an alle. Eure inputs waren eine Bereicherung ! Gruss Roger
Leute ich glaubs nicht. Vielen vielen Dank für diesen Thread. Was zwei Wochen lang bei mir nicht richtig laufen wollte hat jetzt innerhalb von vielleicht ner halben Stunde funktioniert. Einfach der Anleitung von Daniel R. weiter oben folgen, zusätzlich eine main.c mit folgendem Inhalt im Projekt anlegen:
1 | // Wird vom Startupcode angesprungen
|
2 | void SystemInit() |
3 | {
|
4 | |
5 | }
|
6 | |
7 | int main () |
8 | {
|
9 | while (1); |
10 | }
|
Und die Sache rennt! Sauber, vielen Dank nochmal!!!
Ich habe im Artikel STM32 unter "Programmierung" diese Zeile hinzugefügt: "Tipps für Installation mit Eclipse können in diesem Thread gelesen werden." mit einem Link auf diesen Thread. Ich denke das ist hilfreich.
peterguy schrieb: > main.c mit folgendem Inhalt im Projekt anlegen:// Wird vom Startupcode angesprungen > void SystemInit() > { > > } > > int main () > { > while (1); > } > > Und die Sache rennt! Die Funktion SystemInit() ist im Librarymodul system_stm32f10x.c enthalten. Wenn du das aus der ST-Library dazulinkst dann wird der Takt u.s.w. gleich eingestellt. Kann man natürlich auch selbermachen.
Hallo Zusammen Nun wie vermutet jetzt folgt der besonders harte integrationsteil ! Nachdem ich über das Tutorial von Yagarto keinen erfolg hatte. Was mich aber nicht wundert da dies ja für eine J-Link GDB Server gedacht ist. Ich habe aber nun einen JTAGKey2 von Amontec ! Nun so dachte ich mir lass ich das teil mal unter Crossworks (30Tage lizenz) laufen. Doch leider weit gefehlt ! Das JTAGKey wird nicht erkannt !!!!! folgende Fehlermeldung erscheint: cannot find FTDI driver for USBdevice... Windows driver von Amontec habe ich Installiert !! Auch sehe ich das USB Devise JTAG Amontec im Gerätemanager von Windows. Was soll das nun ? Hat jemand änliche Erfahrung gemacht oder kann mir Helfen ? Es bleibt einem wohl nichts erspart !!!!!!!!!!!!!!!!!!!! Gruss Roger
>Es bleibt einem wohl nichts erspart !!!!!!!!!!!!!!!!!!!! So ist es. Tipp 1: OpenOCD müsste mit dem Amontec gehen, ich habe aber nicht solch ein Teil. Der Download-Link steht hier: STM32 >> "Installation für STM32" Tipp 2: Im Demo-Projekt "ChaN's FAT-Module with STM32 SPI" (auch von hier STM32) gibt es die Parametrierung wie man den OpenOCD unter Eclipse startet und wie man die Debug-Session startet. Die dort anschauen und entsprechend für den Amontec anpassen. Ich nutze den ARM-USB-OCD von Olimex und der klappt gut.
skha schrieb: > @peterguy > > > > Auf welchem System? Auf einem STM32-H103 Board von Olimex. Da ist ein STM32F103RBT6 Controller drauf. Nächster Schritt wird FreeRTOS ans laufen zu bringen, das wir sicher auch noch spassig ;-) @900ss: Danke für den Hinweis, das war mir neu. Wie macht ihr das denn mit dem Library verlinken? Kopiert ihr die ganze lib in euer Projekt, oder kann man irgendwo einstellen, daß Eclipse (bzw. der Compiler) sich die Dateien an einem bestimmten Ort suchen soll?
Angehängte Dateien:
-
Bild1.png
19 KB
Bei mir sieht das ganze so aus wie im Bild. - inc: meine *.h - lib: alles fremde - lib/cm3 - lib/inc: ST-Lib *.h - lib/src: ST-Lib *.c - out: die kompilierten Dateien (Verzeichnisstruktur wie im Projekt, nur ein out davor) - prj: OpenOCD mit Konfig-Dateien und DLL, Linker-Script, sonstiges - src: meine *.c - scr/usb: meine *.c für USB (optional) Somit lässt sich das Projekt immer kompilieren, mit dem Stand der STM Lib, denn kommt ein Update, dann kann man selbst entscheiden für welches Projekt man das einspielen möchte. Auch OpenOCD ist mit dabei, den das ist das wichtigste Werkzeug für Debug/Download. Bei einem Update kann es sein dass OpenOCD neue/andere Befehle bekommt, daher das hier mit speichern. Um das Projekt zu sichern zippe ich immer das gesamt Workspace Verzeichnis, komplett, auch mit den Eclipse-Dateien. Das sind zwar ein paar MB, dafür sind dann auch alle Eclipse-Parameter dabei. Entzippen und wieder benutzen ist kein Problem.
Ok, also ich fasse mal zusammen: 1) Workspace und Arbeitsverzeichnis im gleichen Ordner 2) Alle verwendeten Libraries ins Arbeitsverzeichnis kopieren 3) Linkerscript auch ins Arbeitsverzeichnis 4) Debuggerzeugs ist bei mir in Eclipse eingestellt, da gibts keine separaten files für 5) makefile (?) Ich habe mein Projekt mit dem Projektwizzard erstellt, anscheinend generieret der kein makefile sondern konfiguriert alles unter Projekt -> Properties?
peterguy schrieb: > Wie macht ihr das denn mit dem Library verlinken? > Kopiert ihr die ganze lib in euer Projekt, oder kann man irgendwo > einstellen, daß Eclipse (bzw. der Compiler) sich die Dateien an einem > bestimmten Ort suchen soll? Beides funktioniert und noch eine Möglichkeit, du baust eine "echte" Library von der ST-Lib. Dann entsteht eine einzige Datei z.B. stm32lib.a. Diese kannst du dann zu jedem Projekt dazu linken. Da müsstest du dich mal mit den GNU Manuals beschäftigen, wie man eine Lib baut. Das Programm "ar" macht das, nachdem der Compiler alles übersetzt hast. Aus der Lib werden dann vom Linker nur die Teile hinzugelinkt, die auch gebraucht werden. Allerdings setzt das voraus, dass die Lib so für alle Pojekte gleich sein darf. Wenn ein Projekt doch eine Änderung braucht, dann wird es evtl. schwierig in einem anderen Projekt. Alle C-Sourcen in das Projekt kopieren ist auch möglich. Aber dann solltest du beim kompileren und linken jeweils Optionen mit angeben, dass nicht alles hinzugelinkt wird, sondern nur das, was wirklich benötigt wird. Sonst wird dein Programm unnötig groß. Die Optionen hab ich gerade nicht im Kopf. Die Sourcen der Lib an einer zentralen Stelle zu lassen ist evtl. auch unünstig. Wenn du mal an einer Datei (aus der Lib) eine Änderung machen solltest, dann funktioniert evtl. ein anderes Projekt nicht mehr wie auch bei der Library.
peterguy schrieb: > makefile (?) Ich habe mein Projekt mit dem Projektwizzard erstellt, > anscheinend generieret der kein makefile sondern konfiguriert alles > unter Projekt -> Properties? Doch, die makefiles werden von Eclips erzeugt und haben die Endung .mk. Sie liegen jewilt im Release oder Debug Verzeichnis. Die Projetdateien für Eclipse heißen .cproject und .project (versteckte Dateien) und liegen im Projektverzeichnis.
900ss D. schrieb: > Doch, die makefiles werden von Eclips erzeugt und haben die Endung .mk. > > Sie liegen jewilt im Release oder Debug Verzeichnis. > > Die Projetdateien für Eclipse heißen .cproject und .project (versteckte > > Dateien) und liegen im Projektverzeichnis. Tatsache. Allerdings scheinen die Verzeichnisse + Dateien erst erzeugt zu werden, wenn man das erste mal das Projekt baut. Vermutlich analysiert Eclipse die vorhandenen Verzeichnisse und Dateien und generiert die Makefiles + .mk files dann entsprechend.
Ich habe ein eigenes makefile, mit dem kann ich genau bestimmen was ich haben möchte und wie es gehen soll. Das Original kam, so glaube ich, von MT und habe es angepasst damit der die übersetzten Dateien in ein "out" Ordner speichert, damit ist der Ordner src übersichtlicher (daran hab ich sicher fast ein Tag geknobelt). Anbei die Datei.
Existiert eigentlich überhaupt eine sinnvolle Zusammenstellung mit der man mittels Eclipse über openOCD kommerziell einen STM32F107 programmieren kann, ähnlich der AVR32 über WINAVR Variante?
Ein "Fix-Fertig-Und-Alles-Geht-Auf-Anhieb-Eclipse-STM32.Setup.exe" gibt es nicht. Da muss man schon Keil oder IAR kaufen. Aber wie ja dieser Thread beweist, bekommen es die Leute hin.
Das habe ich inzwischen schon mitbekommen, ich wollte nur wissen ob es eine Konstellation gibt mit der man die Bedingungen erfüllen kann, da ich in den Lizenzen ständig "keine Kommerzielle Nutzung" lese. Beim GDB verweise ja auch alle ständig auf Segger. Mich wundert allerdings, dass noch keiner bis jetzt ein Bündel herausgebracht hat, gerade für Anfänger. Im übrigen habe ich gerade mit openOCD ständig das Gefühl vor verschlossenen Türen zu stehen (nicht funktionierende Links aus teilweise Rechtlichen Gründen ect.) Ich versuche mich gerade durch die Yagato Seite durch zu arbeiten. Ich hoffe der Server läuft auch mit dieser Quelle http://www.gnu.org/software/gdb/download/ANNOUNCEMENT ... aber so richtig verstanden habe ich das hier nicht. Das Problem fängt bei mir schon dabei an, dass man nie weiß wer mit wem zusammen arbeitet und man ständig wieder auf kommerzielle Produkte verwiesen wird. Unterstützt der Segger GDB jetzt auch alle openOCD, muss man trotzdem einen Serial eingeben wenn man das downloaden möchte? Momentan stehe ich wirklich kurz davor den AVR32 mal hallo zu sagen (was ohnehin irgendwann mal geschieht).
Auf die Gefahr hin, mich zu wiederholen: Wenn es darum geht, sich über JTAG mit dem uC zu verbinden, um das Programm runterzuladen und zu debuggen, ist jetzt wieder ein Bottom-Up-Ansatz angebracht. Wenn man nämlich einfach mal versucht, Eclipse irgendwie anhand von Tutorials beizubringen, das zu machen, geht garantiert irgendwo irgendwas schief, und man steht wie der Esel am Berg (eigene Erfahrung). Also: Eclipse zumachen. Kommandozeile aufmachen. Und das Manual von OpenOCD. Dann per Kommandozeile mal versuchen, dem Prozi einige Infos zu entlocken. Wieviel Flash hat er? Wie heisst er? Das bedingt natürlich erst mal, dass OpenOCD überhaupt mit dem Interface redet. Dann einfach mal irgendwelchen Code runterladen und wieder zurücklesen. Sich das Kapitel über Reset-Konfigurationen zu Gemüte führen. Im Schema nachsehen, wie Reset und JTAG-Reset verhängt sind. Mal einige Resets ausführen und sehen, ob die das tun, was sie sollen......... Dann, wenn man diesen Layer verstanden hat, kommt GDB dazu. Wieder mit Kommandozeile. Probieren, ob man den compilierten Code durchsteppen lassen kann. Das heisst: .elf file laden, mit OpenOCD verbinden, .bin file runterbrennen (direkt durch Kommandi an OpenOCD oder über GDB "durchgeschlauft"... Und DANN mal Eclipse wieder öffnen und es dazu bewegen, auf Knopfdruck diese Dinge zu machen, die über die Kommandozeile funktioniert haben.
stm schrieb: > Das Problem > fängt bei mir schon dabei an, dass man nie weiß wer mit wem zusammen > arbeitet und man ständig wieder auf kommerzielle Produkte verwiesen > wird. Unterstützt der Segger GDB jetzt auch alle openOCD, muss man > trotzdem einen Serial eingeben wenn man das downloaden möchte? Oh mann, es ist, als ob ich in meine eigene (nich so alte) Vergangenheit schaue! :-) Also: "Unterstützt der Segger GDB jetzt auch alle openOCD" Segger macht kein GDB. Sondern ein HW-Teil (JLink) und als Interface für GDB (das ja GNU ist) einen sog. GDB-Server. Man kann also sagen, dass GDB in gewisser Weise in Konkurrenz zu OpenOCD steht. Segger GDB Server: Server, über den GDB mit einem JLink reden kann. Kommerziell. OpenOCD: Server, über den GDB mit ganz vielen Geräten, inkl. JLink reden kann. OpenSource. Fazit: Wenn Du 'nen JLink hast, brauchst Du ENTWEDER einen Segger GDB-Server und GDB, ODER OpenOcd und GDB. Wenn Du einen anderen JTAG Adapter hast, nützt Dir Segger gar nichts. Dann bauchst Du ENTWEDER einen Server vom Hersteller des Adapters, oder (üblicherweise) OpenOCD und GDB.
Den Spaß hier?: http://openocd.berlios.de/doc/html/index.html#Top werds versuchen, momentan warte ich halt noch auf die openODC Hardware und dachte ich könnte hier schon mal ein bisschen "trocken" programmieren.
ich dachte bisher der GDB und der GDB Server ist das gleiche ;-)
http://fun-tech.se/stm32/OpenOCD/index.php Das ist zwar eine Anleitung für Linux, aber ich denke, das durchzulesen, hilft fürs Verständnis.
Ich bin dir für jede Hilfe dankbar. Wahrscheinlich tue ich mich mit dem Englisch auch stellenweise etwas scher schäm (also meiste bekomme ich ohne größere Probleme hin, aber es dauert halt und man überließt Dinge gern mal). Wo du sagst, dass dich das hier an deine Anfänge erinnert habe ich langsam das Gefühl, dass der Grund warum es so wenig gute Anleitungen gibt einfach der ist, dass man eine halbe Ewigkeit braucht, um hier richtig durchzusehen und dann schon wieder vergessen hat was einem am Anfang die größten Kopfschmerzen bereitet hat ^^.
>dass man eine halbe Ewigkeit braucht, um hier richtig durchzusehen und dann >schon wieder vergessen hat was einem am Anfang die größten Kopfschmerzen >bereitet hat ^^. So in etwa. Dabei hat man sicher 1000 Möglichkeiten ausprobiert und kann sich im Nachhinein nicht mehr korrekt erinnern wie denn die Reihenfolge war. Beispiel: Installation vom Original Olimex USB-Treiber geht nicht mit OpenOCD, also den erst deinstallieren/löschen und dann so machen wie in der OpenOCD Beschreibung beschrieben. Aber das dokumentieren wie man einen falsch installierten USB-Treiber wieder entfernen kann fehlt natürlich überall. (Tipp: Systemsteuerung > Gerätemanager)
Hallo, ich habe auch das 10€ STM32 Eval-Tool. Ich habe geplant meine ersten Schritte in der STM32 Welt mit folgendem Tool zu unternehmen : http://www.raisonance.com/mcu_downloads.html Hat jemand damit erfahrungen ? Ich denke für den Einstieg reichts. Ich denke das Paket Ride7 mit zugehörigem GCC besitzt lt. der oben genannten Seite keine Limitierungen und sieht nach einer Installation im Vergleich zu anderen ARM-Paketen recht schlank aus.
Hallo stm schrieb: > Im übrigen habe ich gerade mit openOCD ständig das > Gefühl vor verschlossenen Türen zu stehen (nicht funktionierende Links > aus teilweise Rechtlichen Gründen ect.) > Ich versuche mich gerade durch die Yagato Seite durch zu arbeiten. > Ich hoffe der Server läuft auch mit dieser Quelle Hallo Das kann ich nur bestätigen !! Ich habe mehr durch zufall den Download des OpenOCD für (Windows als setup) gefunden. Die angegebenen Links gehen meistens ins leere ??? Nun habe ich entlich den JTAGKey2 von Amontec bekommen und stehe schon wieder an ! Es ist schon unglaublich mit welch schlamperei diverse Firmen umgehen. Auf der Offiziellen Homepage von Amontec ist immer noch ein nicht funktionierender Treiber zum download. Erst in einem Forum fand ich dann den aktuellen. Nach installation läuft nun der JTAGKey mit der Testsoftware von Amontec. Doch zu meinem Frust unter Crossworks will die Scheisse immer noch nicht laufen. Dabei sollte Crossworks ja genau das "Fix-Fertig-Und-Alles-Geht-Auf-Anhieb-Eclipse-STM32.Setup.exe" sein !!!!!! Gruss von eine gefrusteten möchtegern Eclipse (Crossworks) user. Roger
Den funktionierenden Download-Link für OpenOCD habe ich hier geschrieben: http://www.mikrocontroller.net/articles/STM32#Installation_f.C3.BCr_STM32 Ich selbst habe auch lange danach gesucht, aber der klappt nun seit einem Jahr.
na schön, dass für dich die größte Herausforderung bei "Systemsteuerung
> Gerätemanager" lieg @ Markus. Seien wir doch mal ehrlich, wenn ich mir
deine Anleitung anschaue ist das ein ganz guter Wegweiser, aber wie
schon Eingangs bemerkt wurde fehlen eben Dinge die einen Anfänger
verwirren, so z.B. ein Hinweis, dass die Eclipse Versionen verschieden
Namen tragen und du deswegen auf Helios und einmal auf Galileo verweist,
was vielleicht mal angepasst werden sollte. Klar kann man sowas auch
selbst rausfinden, aber in zwei Sätzen beschrieben geht es halt
wesentlich schneller. Und in Massen stiften solche kleinen Dinge halt
eine Menge Verwirrung. Und was nach dem Download dieser Dinge geschieht
wurde zuvor auch nicht beschrieben, also bitte nicht so abwertend.
Ja, das ist nur eine absolute Kurzanleitung die ich vor über einem Jahr geschrieben habe und in der Zwischenzeit hat sich nunmal einiges geändert, so gibt es neue Versionen. Damals hat auch die Anleitung von Yagarto nicht funktioniert, heute ist diese angepasst auf das aktuelle Eclipse. Damals hatte ich einige Wochen gebraucht um das ganze zu verstehen und es gab kaum brauchbare Infos im Netz. Heute haben schon viele Eclipse am laufen und können Tipps geben. (Bei Problemen wusste ich zum Teil nicht einmal was ich fragen soll.) Ein anderer User möchte gerade eine Anleitung schreiben, ich habe die Anfänge der PDF schon gelesen. Vielleicht stellt er dies zum Download in den STM32 Artikel ein oder er macht einen eigenen Artikel daraus, dann kann wiederum jeder was beitragen.
Was halt meines Erachtens definitiv eine Überlegung wert ist, ist ein Wechsel auf Linux, wenn nicht komplett, dann vielleicht als Zweitpartition für die Programmierung. Denn in der Welt von OpenOCD, GCC, GDB etc. ist Windows einfach ein Fremdkörper. Es funktioniert irgendwie schon. Man kann auch Microsoft Office auf Linux laufen lassen (warum man das auch immer wollen sollte). Aber es ist halt komplizierter als auf Windows. Logischerweise. Und so ist es mit GCC etc. auf Windows. Das sind Linux-Tools. Und werden es immer bleiben. Windows-Distributionen bleiben immer Flickwerke mit darunterliegenden Kompatibilitätslayern. Wenn man zudem noch im Hintergrund behält, dass man vielleicht irgendwann mal ein Linux auf einen ARM9 packen will, macht ein Linux-System auf dem Host noch mehr Sinn.
Simon Huwyler schrieb: > Das sind Linux-Tools. Und werden es > immer bleiben. Windows-Distributionen bleiben immer Flickwerke mit > darunterliegenden Kompatibilitätslayern. Ich setze diese Tools schon seit Jahren unter Windows ein (privat wie beruflich) und habe keine Probleme, die mit Windows zusammenhängen. Weshalb erzählst du solch einen Quatsch? Das irritiert Anfänger bloß. Die Toolchains sind für Windows angepaßt (über einen Zwischenlayer eben) und funktioniert klaglos. Ist bei WinAVR z.B. so. Codesourcery für ARM auf Windows: klaglos. GCC für SPARC auf Windows: klaglos.
Simon Huwyler schrieb: > Was halt meines Erachtens definitiv eine Überlegung wert ist, ist ein > Wechsel auf Linux, wenn nicht komplett, dann vielleicht als > Zweitpartition für die Programmierung. Tja und was machst Du wenn das Linux sich einfach nicht auf den Rechner installieren lässt ?? (Wie in meinem fall GRRRR!) Bezeichnend für mich sind auch Aussagen von Linux-freaks (In unserem Geschäft) die dann (wenns trotz deren Tips einfach nicht geht) sagen Linux ist ein System für Bastler die es als freude und motivation sehen die vielen knacknüsse zu knacken ! Da musste ich mir dann sagen ok ich bleib bei Windows ! Schliesslich gibt es noch genügend Hürden mit einer Lauffähigen Entwicklungumgebung und den projekten. Aber wie schon mal gesagt, ich habe so langsam das Gefühl die Eclipse geschichte ob nun auf windows oder Linux ist eben die gleiche bastelei. Gruss Roger
900ss D. schrieb: > Weshalb erzählst du solch einen Quatsch? Ich schrieb bloss, was Du in Deiner Antwort wiederholt hast. Dass die Tools nativ auf Linux laufen und, um auf Windows zu laufen, Kompatibilitätslayer benötigen. Kein Grund, polemisch zu werden. Ja, richtig, "Flickwerke" ist etwas falsch ausgedrückt. Die laufen schon. Aber eben, dieser Thread zeigt, dass es halt schon nicht sooo einfach geht. Ich schrieb ja nicht, dass man das machen MUSS. Aber es wäre eine Alternative. Warum soll es Quatsch sein, wenn man Alternativen aufzeigt? yello8247 schrieb: > Tja und was machst Du wenn das Linux sich einfach nicht auf den > Rechner installieren lässt ?? > (Wie in meinem fall GRRRR!) Welche Distribution und vor wie langer Zeit? Da hat sich 'ne Menge getan. yello8247 schrieb: > Bezeichnend für mich sind auch Aussagen von Linux-freaks (In unserem > Geschäft) die dann (wenns trotz deren Tips einfach nicht geht) > sagen Linux ist ein System für Bastler die es als freude und motivation > sehen die vielen knacknüsse zu knacken ! Full Ack, so sollte es nicht sein. Meine persönliche Erfahrung mit Ubuntu ist eine ganz andere. Das lief praktisch out-of-the-box. yello8247 schrieb: > Aber wie schon mal gesagt, ich habe so langsam das Gefühl die Eclipse > geschichte ob nun auf windows oder Linux ist eben die gleiche bastelei. Eclipse selber hat unter Windows keine Probleme. Das ist Java. Dass das kein Bastel ist, zeigt die Tatsache, dass x Firmen ihre eigenen IDEs auf Eclipse aufbauen und das ganz gross in ihrer Werbung erzählen, als Garant dafür, dass es ein gutes Tool sei. Was Du vermutlich meinst, ist die darunterliegende Tool-Chain. Und das kannst Du mir glauben: Ein Bastel ist das auch nicht. Das ist sehr sehr ausgereift. Aber eben, sorry, ich wiederhole mich, es kommt aus der Linux-Welt. Linux WIRD damit kompiliert. Ich habe das auch mal auf Windows hingekriegt. Das läuft schon. Aber meine Erfahrung war halt, dass es ein wenig undurchsichtiger war. Und WENN es einen Grund geben sollte, Linux mal auszuprobieren, dann wäre DAS sicher ein sehr guter Grund. Gruäss Simon
Das habe ich zufällig gefunden. OpenOCD binary für Windows. Ich glaube zwar, weiter oben habe es schon einen Link, aber offenbar sind solche Windows-Binaries wirklich gesucht (weil laut Urhebern nicht erlaubt). Und bei mir war das damals die grösste Knacknuss. Na denn, hier der Link, nutzt's nicht's schadet's nichts. http://www.ethernut.de/elektor/tools/win/openocd-r520-20080322.exe
@Simon Huwyler (simi) Diese OpenOCD-Version ist eine URALT Version und sollte nicht verwendet werden! Hier: http://www.mikrocontroller.net/articles/STM32#Installation_f.C3.BCr_STM32 Unter "OpenOCD" ist der aktuellste Windows-Setup verlinkt! Und der geht problemlos mit STM32 !!!!
Ich hab mal einen Artikel angefangen: STM32 Eclipse Installation Jeder kann hier nun seinen Beitrag hinzufügen.
Markus Müller schrieb: > Ich hab mal einen Artikel angefangen: > > STM32 Eclipse Installation > > Jeder kann hier nun seinen Beitrag hinzufügen. Super Idee !! Danke für deine Bemühungen. Könnte man noch zum Bsp. den Titel: JTAGKey Amontec mit OpenOcd einrichten dazufügen Komischerweise gibts zum Segger haufenweise Tutorials nicht aber für die anderen JTAG's (OpenOcd). Gruss Roger
@ Markus Müller (mmvisual) Der Wiki Eintrag ist ja nur für Windows?!? Und zudem noch nur für Yagarto...
Ja natürlich für Windows. Weiter oben im Thread lese ich die ganze Zeit dass alle Windows-User auf Linux umsteigen sollen, weil es da viel leichter geht, also wieso soll dann das Wiki für Linux sein wenn das für Linux ohne Problemchen geht? Amontec muss ein anderer hinzufügen, ich habe dieses Teil nicht, daher auch keine Ahnung von der Parametrierung. Ich muss aber erst mal ein Leeres "Blink-LED" Projekt machen, gestern hab ich ein Projekt auf die FW-Lib V3.4.0 von ST geupdatend. Dauert aber.
"Kompatibilitätslayer" sind meines Wissens in keinem Element der
Toolchain mehr notwendig. Vor Jahren musste man noch an einigen Stellen
herumbasteln, um Compiler-Collection, den GDB (evtl Insight gdb) und die
Binutils als "native" Win32 Anwendung zu kompilieren. Daher wurde ehedem
von Codesourcery und gnuarm.org Cygwin genutzt. (War seinzeit meine
Motivation für das WinARM Paket, da ich mit cygwin(.dlls) zu oft Ärger
hatte). Inzwischen sind m.W. alle etwas verbreiteten freien
vorkompilierten GNU Cross-Toolchains für MS Windows Hosts "native" Win32
Anwendungen (CS G++, Yagarto, DevkitARM). Beim Bau wird evtl. noch ein
Canadian Cross genutzt (w.r.e. von Codesourcery) aber das interessiert
den Endanwender nicht. Bei Leerzeichen in Pfaden sollte man bei allen
Systemen etwas aufpassen ("" helfen oft).
Bei Makefiles von Anwendern unix-artiger System kann man darüber
stolpern, dass darin Shellfunktionen (z.B. der BASH) oder Hilfprogramme
wie sed und/oder awk aufgerufen werden, die bei MS Windows nicht im
Lieferumfang sind. Ist aber dann nicht der Toolchain selbst anzulasten.
Betr. OpenOCD: es sollten sich mindestens genauso viele Tutorials für
OpenOCD als GDB-Server finden, wie für Seggers GDB-Server. Man muss
lediglich darauf achten, dass viele Tutorials etwas älter sind und
OpenOCD zwischenzeitlich heftig weiterentwickelt wurde. Es ist eine gute
Idee, den bereits gegebenen Empfehlungen zu folgen und erstmal OpenOCD
über Telnet Schnittstelle zu erkunden und sich dann hochzuhangeln (gdb
Kommandoziele, Eclipse hardware debugging plugin).
Eine wenig anwenderfreundliche Besonderheit bei OpenOCD unter Win32 ist,
dass man keine Binärversion für die Herstellertreiber von Adaptern mit
FT2232(H) (Treiber sind dann minimal angepasste Versionen derer von
FTDI) weitergeben darf (GPL usw. usf.). Alternative sind auf libusb-w32
basierende Treiber, die in ensprechenden OpenOCD Binärpacketen enthalten
sind (auf Link zu F. Chopins Seite wurde von M. Müller schon verwiesen).
Mit denen können dann aber Programme nicht mehr "reden", die
FTDI-Treiber/DLLs erwarten (aus diesem Grund kompiliere ich mir OpenOCD
von Zeit zu Zeit selbst für FTDI-Treiber). Das kann aber durch
Filter-Treiber evtl. in kommenden libusb und OpenOCD Versionen wieder
nutzerfreundlicher werden, ist aber m.W. nicht spruchreif.
Wehklagen a la "geht nicht" bringen nichts. Man muss das Problem genau
eingrenzen und beschreiben, mit Schritt-für-Schritt Beschreibung und
Beispielcode/-einstellungen damit man es nachvollziehen kann.
Martin Thomas schrieb: > "Kompatibilitätslayer" sind meines Wissens in keinem Element der > Toolchain mehr notwendig. Das mag sein, dass selbst die inzwischen nicht mehr da sind. Aber selbst wenn, merkt man es als Anwender ja nicht. Das ist ja alles transparent. Und dass die Installation einer solchen Crosstoolchain unter Linux einfacher sein soll, als unter Windows oder das GCC o.ä. unter Windows Flickwerk ist (wie weiter oben versucht wurde darzustellen), ist Unfug. Es ist in beiden Fällen das Wissen über das Zusammenspiel des gesamten Systems notwendig und dass man seinen Kopf benutzt. ;-) Wenn Wissen nicht da ist oder man nicht bereit ist zu verstehen wie das alles zusammen spielt, nutzt weder Linux noch Windows etwas. Wenn man die Toolchain + Eclipse vernünftig installiert hat, dann laufen sie auf beiden Betriebssystemen gleichermaßen gut. Und Eclipse ist unter Linux wie auch unter Windows nicht unbedingt einfach für den Einsteiger. Aber es funktioniert recht gut :-)
Markus Müller schrieb: > Amontec muss ein anderer hinzufügen, ich habe dieses Teil nicht, daher > auch keine Ahnung von der Parametrierung. Hallo Markus Werd ich machen sollte ich das Teil je zum laufen bringen ! Gruss Roger
Es wird sicher helfen, wenn ich gezeigt habe wie es mit dem ARM-USB-OCD von Olimex aussieht. Normalerweise muss man nur die andere Datei für den Amontec anfügen.
Markus Müller schrieb: > Normalerweise muss man nur die andere Datei für den > Amontec anfügen. Tja und wo findet man diese andere Datei .gdb ?? Laut Anleitung yagarto sind diese ja im Projektordner der Bsp. Projekte (xxx_1.gdb). Doch leider ja eben alle nur für den JLink gedacht. Im ordner von OpenOcd lassen sich nur .cfg Dateien finden. Gruss Roger
Ich habe nun im Artikel STM32 Eclipse Installation ein Demo-Projekt hoch geladen, darin sind die Einstellungen für den Olimex ARM-USB-OCD Dongle sowie für den Segger J-Link. Die aktuelle OpenOCD.EXE sowie alle nötigen Dateien sind drin. Einfach den Ordner entpacken und mit Eclipse unter "File" > "Switch Workspace" auf dieses Projekt wechseln. Ctrl+B >> Build Kann das bitte jemand testen? Die Amontec Konfigurationsdateien sind unter: C:\WinARM\OpenOCD_0_4_0\interface Suche in den Dateien nach "Amontec", z.B. jtagkey.cfg
Auch wenn ich mich damit jetzt wohl lächerlich mache, ich hab das hier noch gefunden: http://www.jeroenhermans.nl/openocd-and-eclipse Was mich jetzt mal interessiert, hier wird ständig über darüber geschrieben, dass FTDI verbietet seine Tools mit GPL zu verknüpfen. Wenn man jetzt den normalen OpenOCD von z.b. Olimex nimmt haben die aber eigentlich nichts zu melden und man könnte das Teil sogar kommerziell einsetzen oder liege ich da falsch?
Markus Müller schrieb: > Die Amontec Konfigurationsdateien sind unter: > C:\WinARM\OpenOCD_0_4_0\interface > Suche in den Dateien nach "Amontec", z.B. jtagkey.cfg Komme mir langsam blöd vor. Huch Diese .cfg hatte ich schon auch gefunden. Unter Eclipse gemäss yagarto tutorial ist aber nur die rede von .gdb dateien. Sind das nun die selben Dateien ? Now change to the "Startup" tab and use the following settings: A file called sam7x256_ram_jlink.gdb is part of the example. Copy and paste the contents of the test file into the "Initialization Commands" area 1. Note: The setup for the Cortex M3 examples are slightly different. For these examples you will find two separate script files called xxx_1.gdb and xxx_2.gdb within the project folder. Copy the contents of xxx_1.gdb into the text box under Initialization Commands (1) and copy the contents of xxx_2.gdb into the text box under Run Commands (2). Do not check the boxes "Set Breakpoint at:" or "Resume". Gruss Roger
stm schrieb: > Wenn > man jetzt den normalen OpenOCD von z.b. Olimex nimmt In dem Olimex-Teil ist auch ein FTDI drin. Aber Du musst Dir da wohl keine grossen Gedanken machen. Binaries mit verlinkten Treibern anzubieten ist wohl juristisch irgendwie grenzwertig, weswegen die offizielle Seite das nicht mehr macht. Ich denke, das Ganze geht in die Richtung, dass etwas angeboten wird, ohne es selber geschrieben zu haben. Aber wenn Du doch irgendwie zu so einem Treiber kommst, darfst Du ihn bestimmt auch verwenden. Auch kommerziell. Wie gesagt, das ist ein Hüftschuss, wie es genau aussieht, weiss ich nicht.
stm schrieb: > Auch wenn ich mich damit jetzt wohl lächerlich mache, ich hab das hier > noch gefunden: > http://www.jeroenhermans.nl/openocd-and-eclipse > > Was mich jetzt mal interessiert, hier wird ständig über darüber > geschrieben, dass FTDI verbietet seine Tools mit GPL zu verknüpfen. Wenn > man jetzt den normalen OpenOCD von z.b. Olimex nimmt haben die aber > eigentlich nichts zu melden und man könnte das Teil sogar kommerziell > einsetzen oder liege ich da falsch? Hammer !!!! ueber deinen Link bin entlich auf was brauchbares gestossen. http://www.makingthings.com/documentation/tutorial/debug-with-openocd/configure-eclipse Nun verstehe ich auch den Unterschied .gdb zu.cfg Dateien Und vorallem schön erklärt wie man den OpenOCD in eclipse einbindet !! Cool vielen dank Gruss Roger
yello8247 schrieb: > Unter Eclipse gemäss yagarto tutorial ist aber nur die rede von > .gdb dateien. Sind das nun die selben Dateien ? Ich kenne weder Yagarto noch das Tutorial. Aber .gdb-Dateien sind wohl Init-Scripts für GDB. .cfg-Dateien hingegen sind Konfigurationsscripts für OpenOCD.
>... > Was mich jetzt mal interessiert, hier wird ständig über darüber > geschrieben, dass FTDI verbietet seine Tools mit GPL zu verknüpfen. Wenn > man jetzt den normalen OpenOCD von z.b. Olimex nimmt haben die aber > eigentlich nichts zu melden und man könnte das Teil sogar kommerziell > einsetzen oder liege ich da falsch? Woher kommt die Information, dass "FTDI verbietet"? "Ständig" habe ich dies bisher noch nicht gelesen. Mein Stand der Dinge ist, das die GPL unter der OpenOCD steht die Bindung an "closed source" Binäre im gleichen Adressraum verbietet. Tut aber auch nicht wirklich etwas zur Sache - wenn man OpenOCD nicht selbt bauen kann oder will, muss man mit dem zurecht kommen, was fertig kompiliert angeboten wird.
Nun hab ich das Demo-Projekt und die nötige Installation etwas ausführlicher beschrieben: http://www.mikrocontroller.net/articles/STM32_Eclipse_Installation#Installation Wenn jemand Zeit hat, dann testen. @yello8247: Hier ist auch beschrieben wie man auf das Amontec JTAG Interface umstellen könnte.
Markus Müller schrieb: > Nun hab ich das Demo-Projekt und die nötige Installation etwas > ausführlicher beschrieben: > http://www.mikrocontroller.net/articles/STM32_Ecli... > > Wenn jemand Zeit hat, dann testen. > > @yello8247: > Hier ist auch beschrieben wie man auf das Amontec JTAG Interface > umstellen könnte. Super arbeit Markus ! da hast Du aber mindestens ein Bierchen verdient. Kommst Du aus Deutschland oder der Schweiz ? (Sorry der indiskreten Frage, aber vielleicht kann ich Dich dann mal auf ein Bierchen einladen ?) Eine Frage noch Du hast nun genau den Teil beschrieben der mir immer gefehlt hatte (Auf Yagarto leider nicht zu finden) nähmlich "External Tools Configuration..." Super ! nun weiss man wo überhaupt die .cfg Dateien einzubinden sind. Bei Yagarto ist leider nur die "Debug Configuration..." beschrieben. (Oder ich hab das übersehen ?) Kann ich nun für den JTAGKey die dort eingebundenen .dbg Dateien belassen, oder müssen diese auch noch extra editiert oder mühsam gesucht werden! Gruss Yello
Zum Bierchen trinken wohne ich wohl mindestens 1500km zu weit weg. In meinem Demo hab ich keine DBG Datei drin. Vermutlich sind das GDB / GDB-Server Befehle, die können bei der grünen Käfer Debug-Taste, schwarzer Pfeil nach unten >> "Debug Configurations..." >> Im Reiter "Start" eingegeben werden. Alle Befehle die mit "monitor" beginnen werden direkt an den GDB-Server (OpenCOD) weiter geleitet, alle anderen sind für den GDB bestimmt. Die Yagarto-Seite ist schon sehr Umfangreich, es fehlen leider immer in paar Puzzleteile, denn das ganze ist schon sehr komplex. Kannst Du den Amontec in mein Demo-Projekt einbinden? Einfach meine OpenOCD-Einträge kopieren und entsprechend ändern. Dann, wenn es geht mir das Projekt mailen, dann kann ich es in das Demo im Artikel übernehmen.
Huch Doch noch eine zusätzliche Frage: Gilt die Angabe des Installation-Pfades von C:\WinARM nur für die Zusatztools und das Projekt ? Bei Yagarto steht Eclipse soll ins Verzeichnis C:\Eclipse installiert werden. Let's start with the JRE (1). If the JRE was not installed on your PC, start the installer and follow the instructions. After the JRE installation you must unzip the Eclipse file (2). Assumed you had unzipped it on drive C:\, you will see a folder named C:\eclipse. In that folder you will find the eclipse application itself, please create a shortcut on your desktop now. You can use this shortcut later to start the eclispe application. Gruss Yello
Yagarto ist ja nur ein Zip, das kann problemlos nach C:\WinARM\ entpackt werden. Ich mache alles immer nach C:\WinARM denn dann kann ich den Stand einfach Zippen und hab somit eine Datensicherung, falls ich mal irgend was kaputt mache. Und ich weiß ganz genau, dass die gesamte Entwicklungsumgebung nur in dem einen Verzeichnis drin ist. So habe ich auch ein Verzeichnis: C:\WinARM\Examples mit den Demo-Codes aus dem WWW C:\WinARM\Install mit den ganzen Setup-Paketen, die verwendet wurden. Damit ist das ganze aufgeräumt und man behält den überblick. (C:\WinARM ist 750MB dick und hat 13000 Dateien) Wenn ich mal irgend was neues installieren möchte, dann benenne ich C:\WinARM nach C:\WinARM_Geht um und mache ein neues C:\WinARM auf und darin installiere ich die neue Version. Wenn es nicht geht, einfach löschen und das alte C:\WinARM_Geht wieder zurück umbenennen. Ist also eine ganz einfache Sache.
Markus Müller schrieb: > Yagarto ist ja nur ein Zip, das kann problemlos nach C:\WinARM\ entpackt > werden. > > Ich mache alles immer nach C:\WinARM denn dann kann ich den Stand > einfach Zippen und hab somit eine Datensicherung, falls ich mal irgend > was kaputt mache. > Und ich weiß ganz genau, dass die gesamte Entwicklungsumgebung nur in > dem einen Verzeichnis drin ist. > > So habe ich auch ein Verzeichnis: > C:\WinARM\Examples mit den Demo-Codes aus dem WWW > C:\WinARM\Install mit den ganzen Setup-Paketen, die verwendet wurden. > > Damit ist das ganze aufgeräumt und man behält den überblick. > (C:\WinARM ist 750MB dick und hat 13000 Dateien) > > Wenn ich mal irgend was neues installieren möchte, dann benenne ich > C:\WinARM nach C:\WinARM_Geht um und mache ein neues C:\WinARM auf und > darin installiere ich die neue Version. Wenn es nicht geht, einfach > löschen und das alte C:\WinARM_Geht wieder zurück umbenennen. > Ist also eine ganz einfache Sache. Demnach installiert Du auch Die IDE (Eclipse) ins Verzeichnis C:\WinARM\Eclipse\ ???? Macht das Sinn ? Die IDE könnte man ja auf C:\Eclipse belassen ? Gruss Yello
Ja, macht Sinn, wegen der einfacheren Sicherung und Test von Updates, da auch in das Eclipse diverse PlugIn's mit installiert werden.
Markus Müller schrieb: > Kannst Du den Amontec in mein Demo-Projekt einbinden? > Einfach meine OpenOCD-Einträge kopieren und entsprechend ändern. > Dann, wenn es geht mir das Projekt mailen, dann kann ich es in das Demo > im Artikel übernehmen. Hallo Markus Schade 1500 Km sind schon ein wenig zuviel für ein Bierchen. Ich werde dies versuchen. Heute abend vielleicht wenn ich es entlich zum laufen bringe. jetzt aber ruft die Pflicht und ich muss (sollte) mich wieder einmal meiner Familie widmen. Bis später Yello
Unglaublich !!! Da wird man stundenlang geplagt von irgendwelchen errors. Support kann auch nicht helfen !! Und dann macht man mit der Familie einen Ausflug kommt nach Hause ändert rein gar nichts und plötzlich läuft die Scheisse !! Nun wenigstens weiss ich jetzt das mein Eval-Board mit JTAGKey2 und Crossworks funktioniert ! Und kann nun beruhigt an die Eclipse Geschichte ranngehen. Gruss Yello
Super!! Da hat sich wohl beim ständigen hin und her der USB Treiber im Hintergrund aufgehängt.
Hallo ! Jetzt weiß ich warum mir keiner antwortete - Roger hat das ganzen Forum für sich in Anspruch genommen sodass mir keiner mehr antworteten konnte ;-) Ne, spaß bei Seite. Ich bin nun kurz davor das ganze Zeugs in die Tonne zu treten (Olimex und JLink). Ich hab mich genau nach Yagarto's Installation gehalten und das ging auch bis auf ein paar klitze kleine Sachen - aber die konnte ich beheben nur aber das Ding will einfach nicht debuggen. Er connected sich mit dem J-Link EDU und es wird auch alles sauber erkannt. Wenn ich auf Debug Configurations gehe und dann auf den Button Debug dann kommt erstnochmal der Connect - schreibt wie wild auf der Console und löscht sie dann. Dann kommt ne Fehlermeldung-Box und bei Details steht "continue" The programm is not running. Wenn ich jetzt auf die andere Perspektive gehe und <Ctrl>-F11 (run) eingebe dann kommt The selection can not be launched usw. In Yagartos howto steht drin dass die "Commands" beim M3 slightly different sind, aber wie soll ich wissen was man da reinschreiben muss. Wer kann mir weiterhelfen ? Gruß Uli zermürbt
Uli B. schrieb: > Ich bin nun kurz davor das ganze Zeugs in die Tonne zu treten (Olimex > und JLink). Hallo Uli Da war ich auch kurz davor ! Ich kann Dir leider noch nicht weiterhelfen. 1. Hab kein Olimex 2. Bin froh mein Zeugs entlich mal auf einem sogenanten "Fix-Fertig-Und-Alles-Geht-Auf-Anhieb-Eclipse-STM32.Setup.exe" lösung von Crossworks zum laufen gebracht zu haben. Die haben übrigens einen super Support !! Der Typ hat sogar am Sonntag geantwortet. Von Amontec (JTAG Anbieter) habe ich bis jetzt noch keine Rückmeldung. Nun ich brauchte eine Pause will mich aber nochmals der Eclipse Geschichte annehmen. Einfach nur interessehalber. Schlussentlich werde ich mich wohl für die Crossworks lösung für 150$ entscheiden. Super Tool eine Installation und fertig ! Es kommen noch genügend probleme bei der findung der richtigen Einstellungen. Da ist man froh nicht noch Tage an der Installation zu verbraten ! Ich habe vollstes Verständnis zu Deiner Verärgerung. Viel Glück und bis später Roger
Leute was bastelt ihr denn da immer mit Yagarto rum ?!? Hier hab ich mal in Kurzform geschrieben wie es geht: Beitrag "Re: STM32 Eclipse Entwicklungsumgebung" Das geht so für Windows und Linux. Gerade mit einem J-Link in minutenschnelle !! Kostenlos !! Ohne irgendwelche Begrenzungen !! Wer dazu Fragen hat kann sich melden. Am besten hier, weil einige das ja schon so am laufen haben die hier geschrieben haben. Viele Grüße Daniel
Und in diesem Artikel: STM32 Eclipse Installation steht noch das drin was in der Yagarto-Seite fehlt. Das Demo-Projekt unterstützt den Olimex und JLink. Der Artikel ist zwar ziemlich am Anfang, aber dennoch hilfreich. Vielleicht hat ja noch jemand Zeit etwas rein zu schreiben.
Warum findes Du Yagarto so gut? Das ist nur ein Hobby Projekt. Der Sourcery G++ Kompiler ist wesentlich besser. Er hat außerdem eine einfache Installationsroutine.
Der "arm-none-eabi-..." ist doch der Sourcery G++, oder nicht? Und der ist in dem Yagarto-Setup drin. Somit muss ich eine Seite weniger besuchen um ein Setup zu laden. In jedem Fall klappte meine letzte Installation mit Yagarto relativ leicht, da ich zuvor schon Eclipse mit älterer Version nutzte.
Hallo ! Erstmal danke für die aufmunternden Worte ! Ich hab mir die STM32 hier durchgelesen und hatte halt das Gefühl das Yagarto am besten für mich passt. Ich hab das Gefühl bei Sourcery G++ Lite - das dies eine Version ist dass wenn ich ein bestimmtes Problem habe und genau diese Funktion (etc...) brauche dann popt so ein nettes Fensterchen auf - Wenn Sie diese Funktion haben möchten - dann überweisen Sie an Paypal oder sonstwo das Geld. So hab ichs mal erlebt. An Yagarto störte mich als einzigstes das er von Cygwin weg will. Ich arbeite aber schon lange mit Cygwin und ebenso Linux. Aber ich wollte das ganze erstmal mit Win ausprobieren. Ach ja - ich hab mir die Atollic-geschichte gezogen und beim start sah das ganze genauso Fatal aus - wie halt in Eclipse üblich. Hat auch nicht funktioniert. Dafür bekomme ich jetzt jedenfalls von denen wahrscheinlich immer schöne Mails. O.K. ich muss zugeben ich bin von ATMEL sehr verwöhnt. Was ich allerdings nicht brauchen kann sind Einschränkungen und Lite klingt halt schon so... bin aber für alles offen... Ich werd mir mal die unteren Tipps von Euch morgen reinziehen und vielleicht tut sich ja doch mal was. Aber jetzt erst mal guts Nächtle Gruß Uli
Lite bedeutet da nur, dass es nur Konsolen Tools sind, was bei Yagarto eh der Fall ist. Die Lite Version hat sonst keine Einschränkungen. >Der "arm-none-eabi-..." ist doch der Sourcery G++ Glaube nicht. >Somit muss ich eine Seite weniger besuchen Du musst doch auch auf die Yagarto Seite um runter zu laden ?!? Sourcery G++ runterladen, installieren und fertig. Dann hast Du Kompiler, Linker usw... Ich hatte beides mal ausprobiert, also Yagarto und Sourcery G++. Daher kann ich aus Erfahrung sagen, dass Sourcery G++ besser funktioniert. Probiert es aus und entscheidet selbst... Viele Grüße Daniel
Das Lite hießt, es ist nur der GCC Kommandozeilenkompiler, ohne extra Tools. Codesourcery darf dafür kein Geld verlangen, denn der ursprüngliche Code kommt vom GCC. Dennoch ist der ohne Codelimit und ohne jegliche Begrenzungen. In Verbindung mit Eclipse und make reicht das vollkommen aus.
>Ich hatte beides mal ausprobiert, also Yagarto und Sourcery G++. Daher >kann ich aus Erfahrung sagen, dass Sourcery G++ besser funktioniert. >Probiert es aus und entscheidet selbst... Wie wirkt sich das "besser funktioniert" denn aus?
Uli B. schrieb: > Ich bin nun kurz davor das ganze Zeugs in die Tonne zu treten (Olimex > und JLink). Was heißt das genau? Du hast ein Olimax-Jtag-I/F und einen J-Link und beides funktioniert nicht. Oder du ast einen J-Link und ein Board von Olimex? Welchen Controller genau? Das Debuggen ist auch nicht so einfach. Vielleicht wirst du im Seggerforum fündig? segger.com und dann Forum. Ob du YAGARTO oder Codesourcery verwendest ist im Prinzip egal. Beides sind volle Versionen. Das Lite steht bei Codesourcery nur für die kostenfreie Version ohne Support. Die Kaufversionen von Codesourcery hat nur ein paar Extras, die aber auch in Yagarto nicht enthalten sind. Außerdem gibt es eine auf Eclipse basierende IDE dazu. Poste mal ein paar Screenshots was du genau konfiguriert hast und was wann an Fehlermeldungen erscheint. "Es funktioniert nicht" ist keine Fehlermeldung ;-)
Hallo ! Wie heißt es: Gestern standen wir noch vor dem Abgrund... Heute sind wir einen Schritt weiter ... @900ss: Ein Olimex Board (das mit der LCD Anzeige) und den JLink EDU. Ich konnte irgendwie Eclipse kitzeln dass er mir die Error Log anzeigt. Viele Fehlermeldungen wie z.B. Internal Error org.eclipse.cdt.debug.mi.core Ich denke auch es ist egal welches Tool man nimmt sobald Eclipse ins Spiel kommt ist es sch...ön. Das Debuggen ist nicht einfach ? Meinst Du etwa die Console wo man direkt mit dem gdb quaseln kann ? Nun selbst da hatte ich selbst in Linux keine Schwierigkeiten, aber wir sprechen hier von Eclipse und das heißt bei mir Klicki-Bunti. Ich installiere doch kein Eclipse um nachher auf der Console rumzutippen. Aber um diese Internal Error wegzukriegen - kann man nicht irgendwie ein reinstall machen oder ist bei der Installation was falsch gelaufen ? Ich vermute genau aus diesem Grund funktioniert das debuggen nicht. Gruß Uli
Welches dieser vielen Programme sagt "Internal Error"? Screenshot?
Uli B. schrieb: > Das Debuggen ist nicht einfach ? Das bezog sich auf das Einrichten. Das Eclipse mit dem ARM-GDB quatscht und dieser dann mit dem Segger GDB-Server. Aber solange du nicht schreibst, wann genau was passiert ist es schwer dir zu helfen. Auch deine Angabe zu dem Controller ist nicht so genau. Olimex mit LCD...??? Uli B. schrieb: > Ich installiere doch kein Eclipse um nachher > auf der Console rumzutippen. Wo steht denn dass du das machen sollst? Uli B. schrieb: > kann man nicht irgendwie ein reinstall machen Klar kann man das irgendwie machen. Besser ist aber richtig. Ist doch recht einfach und in Sekunden erledigt. Eclipse mit der CDT installieren. Dann die Eclipse GDB Debugger Integration installieren. Fertig.
Angehängte Dateien:
-
EclipseDebug.png
44 KB
Wenn du nach dem Installieren im Menu RUN->Debug Configuration öffnest, dann er scheint der Dialog (siehe Anhang) wo du die Debug Configurationen einstellen kannst. Soweit warst du wohl schon. Wichtig ist der rot eingekreiste Teil. Der muß da sein. Unter diesem Punkt mußt du deine Debug-Konfiguration einrichten, also mit '+' hinzufügen.
Ich habe folgende Einstellungen nur zum Flashen einer Anwendung eingestellt: siehe Anhänge. Unter dem Startup-Tab sind 4 Initialization Commands zu sehen. Mehr sind dort nicht drin. Der Controllertyp ist wichtig in der Zeile "monitor flash device" Leider geht das debuggen damit nicht. Hab mich nicht länger damit beschäftigt. Zum Debuggen hab ich mir eine andere Config. eingerichtet. Die sieht im Prinzip genauso aus wie die zum Flashen, aber ich habe "Load image" im Startup-Tab deaktiviert. Damit kann ich dann debuggen. Du darfst auch die JTAG-Speed nicht zu hoch setzen. Ich habe die Zahlen nicht im Kopf, mußt du mal im Manual vom JLink schauen. Das hängt vom Controllertakt ab. Die Portnummer unter "Debugger" muß zu der eingestellten im GDB-Server für den JLink passen. Am GDB-Server kann man auch viel "kaputt" konfigurieren :-)
In den Bildern, die Zeile ganz unten, da steht "Using GDB (DSF) ...." Den anklicken und umstellen auf: "Using Standard GDB Hardware Debugging Launcher" Im dritten Bild ist rechts ein Scrollbalben, da kommen noch die "Run Commands". Wast steht da drin? Vermutlich fehlt unter "Initialize Commands" das: monitor flash breakpoints = 1 Aber ich sehe auch nicht alle Zeilen. Die bitte markieren und hier posten.
Markus Müller schrieb: > In den Bildern, die Zeile ganz unten, da steht > "Using GDB (DSF) ...." > > Den anklicken und umstellen auf: > "Using Standard GDB Hardware Debugging Launcher" Weshalb? Ich habe es probiert und ich habe im Verhalten beim Flashen wie auch Debuggen keine Änderung. Und meines Wissens ist GDB DSF Variante die "tollste" ääh die richtige. > Im dritten Bild ist rechts ein Scrollbalben, da kommen noch die "Run > Commands". Wast steht da drin? Die sind bei mir leer. Überall. > > Vermutlich fehlt unter "Initialize Commands" das: > monitor flash breakpoints = 1 Wofür? Ich hab alles was ich brauche. Solange ich die zur Verfügung stehenden Hardware-Breakpoints nicht überschreite ist alles gut. Wenn ich nicht irre sind es 6 HW Breakpoints die zur Verfügung stehen. Soviel brauche ich selten. > > Aber ich sehe auch nicht alle Zeilen. Die bitte markieren und hier > posten. Wovon?
Ich habe es gerade mal probiert mit den Breakpoints. Ich habe nichts in den Initialization Commands verändert. Ich konnte mehr als 6 Breakpoints setzen. Er macht scheinbar automatisch Flashbreakpoints jetzt, wenn die HW Breakpoints nicht ausreichen.
In dem Artikel: STM32 Eclipse Installation hab ich ein Demo-Projekt, darin ist auch die JLink-Konfiguration drin und die geht. Schon mal probiert?
Nein, meine Konfiguration funktioniert ja. Oder meinst du zum testen?
Ja, zum Test. Damit sollte problemlos debuggen möglich sein. Von Segger habe ich gerade die Version V425k und das ganze ist als SWD parametriert.
Angehängte Dateien:
-
Fehler1.jpg
290 KB -
Main.jpg
180 KB -
Debugger.jpg
190 KB -
Startup.jpg
200 KB
Hallo ! O.K. zu Olimex und LCD... [[http://shop.embedded-projects.net/index.php?module=artikel&action=artikel&id=24]] @Markus Müller (mmvisual): Welches dieser Programme...: Soviel ich jetzt in Eclipse verstanden habe ist das programmieren und debuggen getrennt - also in perspectives unterteilt. D.h. wenn ich in der Perspektive debuggen auswähle. Meintest du das ? Ich hab mal ein Screenshot angehängt. Das kommt schon bevor ich überhaupt noch irgendwas in Eclipse gemacht habe. @900ss D. (900ss): Das sieht wie in den Bildern bei dir ähnlich aus: -> siehe Anhang. Nur beim Main-Teil kann ich nicht wie oben Debug auswählen. Da gibts nur Standart oder Active. Also Speed und alles andere funktionieren denn der gdb-Server von JLink reagiert ja drauf. Ich hab hier auf Auto eingestellt aber ich habe gesehen dass er dann auf 5kHz steht. Ich könnt aber explizit auf 5kHz einstellen. Das ganze steht schon auf: Using Standard GDB Hardware Debugging Launcher. Ich hoffe ihr könnt mit meinen Angaben was anfangen. Gruß Uli
Angehängte Dateien:
-
Bild1.png
58 KB
Jeder, der die ersten Eclipse-Start-Versuche macht sollte man Besten das Demo-Projekt vom Artikel: STM32 Eclipse Installation laden und damit versuchen. Das hat die Vorteile: - Ich habe auch den Code und weiß wie es konfiguriert ist - Bei mir geht die Einstellung - Alle anderen Forum-Teilnehmer können den gleichen Code laden und auch Helfen. Damit hat man zumindest ein Projekt, das prinzipiell funktioniert und kann somit auch Installationsfehler finden. Daher bitte mein Demo-Code laden und damit starten. Meine Debug-Ansicht sieht etwas anders aus, da gibt es oben noch ein extra Fenster, vermutlich hast Du es zufällig geschlossen. Anbei ein Screenshot.
Uli B. schrieb: > Ich hoffe ihr könnt mit meinen Angaben was anfangen. Mach mal das Errorlogfenster zu. Das macht einen ja ganz raschelig. ;-) Im Ernst, da pinselt Eclipse allen möglichen "Müll" rein. Ist in den seltensten Fällen von Interesse. Ich schaue da kaum rein. Vergiß erstmal was da steht. Das Debugfenster (View) was der Markus vermißt, hast du schon offen nur etwas versteckt. Das ist in deinem ersten Screenshot der Reiter ganz links neben deinem Errorlogreiter. Ich habe mal genau deine Debug-Konfiguration eingestellt und bei mir läuft es problemlos damit :-O Fragen: 1) Wie flasht du dein Programm? Bitte genau beschreiben. Evtl. Screenshots von der Konfiguration dafür posten. 2) Läuft dein Programm wenn du es nur flasht ohne Debugger? 3) Wenn du den Debugger startest, was passiert genau, welche Fenster gehen auf? Wenn du dann in der Debug-Perspektive landest, klick mal auf den Debugreiter und ziehe das Fenster größer und poste mal den Screenshot. Es sollte so aussehen wie bei Markus seinem letzten Screenshot. Auch den Segger GDB-Server sollte nach dem starten des Debuggens alle Lampen an haben ;-) Also 4-mal grüne "Lampen". Auch so wie in Markus seinem letzten Screenshot. Hast du eigentlich das ARM-Plugin auch installiert und damit das Projekt erstellt oder wie hast du das Projekt kompiliert und gelinkt?
Hallo ! Erstmal danke an Markus und 900ss ! @Markus: Ich glaube auch dass das Demo-Projekt erstmal wichtig ist. Ich werde heut Abend versuchen das ganze auf das Demo mal umzustellen. @900ss: O.K. ich denk auch ich mach Error-Log erstmal zu. Das Debugger-Fenster mit den Variablen sieht man im letzten Screenshoot. Aber da rennt der Debugger schon. Ich habe das gefühl ich muss ihn erst anhalten bevor ich die Variablen und deren Inhalt sehen kann. Wäre eigentlich logisch. Oh - das läuft bei Dir .. O.K. 1. Flashen: Im Augenblick weis ich noch nicht wie man das Programm flasht, denn es läuft noch das Testprogramm was mit dem Board mitgeliefert wurde ! Ich vermute nach dem flashen ist das Testprogramm zumindest mal weg, wäre aber O.K. Bei den ATMELS habe ich halt über "Build & RUN" automatisch geflasht. Ich dachte das müßte hier ähnlich sein. 2. Hier kann ich noch nichts sagen. 3. Das Fenster wie bei Markus sieht identisch aus, nur das der Thread bei mir auf running steht. Das JLink-Fenster mit 4 LEDs sind nachdem ich Eclispe im Debug-Modus gestartet habe alle 4 an. Das ARM-Plugin habe ich nach Yagarto installiert also downgeloaded und dann über Archive das jar File eingebunden. Irgendwie sah das gut aus weis aber nicht wie ich überprüfen kann ob das Plugin auch wirklich reingezogen bzw angezogen wurde. Wie gesagt versuche heut Abend das Demo-projekt zum laufen zu bekommen. Gruß Uli
Uli B. schrieb: > Das Debugger-Fenster mit den Variablen sieht man im letzten Screenshoot. Nein, das ist die Debug-Perspektive. Die Debug-View öffnest du dann mit dem Tab links unten (Grüner Käfer wo DEBUG dransteht). Das Fenster hat Markus offen in seinem letzten Screenshot. > Aber da rennt der Debugger schon. Ich habe das gefühl ich muss ihn erst > anhalten bevor ich die Variablen und deren Inhalt sehen kann. Ja das ist so. Wenn das Programm rennt, werden keine Variablen vom Target gelesen. Obwohl es CPUs und Debugger gibt, die das können. Beim Cortex sollte das über SWV auch gehen aber das führt hier zu weit. > 1. Flashen: Im Augenblick weis ich noch nicht wie man das Programm > flasht, denn es läuft noch das Testprogramm was mit dem Board > mitgeliefert wurde ! Und die Einstellungen von deiner Debugkonfiguration sind dann zu dem Projekt des Demoprogrammes? > Ich vermute nach dem flashen ist das Testprogramm > zumindest mal weg, wäre aber O.K. Ja. > Bei den ATMELS habe ich halt über "Build & RUN" automatisch geflasht. > Ich dachte das müßte hier ähnlich sein. Mit dem AVR-Studio? Mit Eclipse ist es auch anders. > 2. Hier kann ich noch nichts sagen. Wenn es eine Demo ist, dann solltest du doch wissen, was sie machen soll? > 3. Das Fenster wie bei Markus sieht identisch aus, nur das der Thread > bei mir auf running steht. Das JLink-Fenster mit 4 LEDs sind nachdem ich > Eclispe im Debug-Modus gestartet habe alle 4 an. Immerhin. Die Verbindung arm...gdb zum JLink GDB-Server funktioniert. Probier entweder die Demo von Markus aus oder nimm die Einstellungen, die ich oben gepostet habe. Damit flasht du das Projekt auch. Das wird durch den Haken bei "Load program" ausgelöst. Beitrag "Re: STM32 Eclipse Entwicklungsumgebung" Wenn du in dem 3. Screenshot unten "Set program counter aktivierst und als Adresse 4 (nicht 0!) einträgst, dann sollte das Programm direkt nach dem Flashen auch richtig starten. Das klappte bei mir bisher nicht. Hab ich aber gerade mal ausprobiert. Du mußt 4 eintragen, da dort der Einsprung ins Programm steht. Auf Adresse 0 steht der Wert, mit dem der Stackpointer nach Reset geladen wird.
Hallo ! Ich hab jetzt mal das Demo-Projekt von Markus gezogen und wie folgt abgeändert dass der Port C Pin 12 blinken sollte. An dem Olimex-Board hängt auf PC12 direkt eine LED.
1 | int main(void) |
2 | {
|
3 | // Init system and clock |
4 | Sys_Init(); // Dieser Aufruf MUSS zu Anfang stehen! |
5 | Clk_Init(); // Erst danach hat die CPU die richtige Geschwindigkeit |
6 | |
7 | // Benutzerdefinierte INIts |
8 | IO_InitApp(); |
9 | Timer_TaskInit(); |
10 | |
11 | while(1) |
12 | {
|
13 | Timer_Task(); |
14 | |
15 | GPIO_WriteBit(GPIOC, GPIO_Pin_12, tBlink); // Port C.12 blinken |
16 | // Auf PC12 ist die LED beim Olimex-Board |
17 | } |
18 | return 0; |
19 | } |
1 | void IO_InitApp(void) |
2 | {
|
3 | SAVE_PC(); |
4 | |
5 | RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC , ENABLE); |
6 | |
7 | GPIO_InitTypeDef GPIO_InitSt; |
8 | |
9 | GPIO_InitSt.GPIO_Pin = GPIO_Pin_0; // Ausgang PA0 |
10 | GPIO_ResetBits(GPIOA, GPIO_InitSt.GPIO_Pin); |
11 | GPIO_InitSt.GPIO_Mode = GPIO_Mode_Out_PP; |
12 | GPIO_InitSt.GPIO_Speed = GPIO_Speed_50MHz; |
13 | GPIO_Init(GPIOA, &GPIO_InitSt); |
14 | |
15 | GPIO_Pin_13; // Ausgang Port D |
16 | |
17 | GPIO_InitSt.GPIO_Pin = GPIO_Pin_12; // Ausgang Port C |
18 | GPIO_ResetBits(GPIOC, GPIO_InitSt.GPIO_Pin); |
19 | GPIO_Init(GPIOC, &GPIO_InitSt); |
20 | } |
O.K. das abgeänderte Programm ist im IO_InitApp-teil von mir nicht sauber programmiert, da ich die Funktionsaufrufe noch nicht kenne. Dazu hab ich bei Markus in den Debug-Konfigurationen den letzten Teil verwendet der auch den Segger Adapter unterstützt. Also Konfig: <BlinkLED Segger Reset Load Debug> Nun testprogramm ist weg - war ja voraus-zu-sehen. Aber da blinkt nichts. >> Bei den ATMELS habe ich halt über "Build & RUN" automatisch geflasht. >> Ich dachte das müßte hier ähnlich sein. > > Mit dem AVR-Studio? Mit Eclipse ist es auch anders. Mit AVR-Studio... O.K. >> 2. Hier kann ich noch nichts sagen. > > Wenn es eine Demo ist, dann solltest du doch wissen, was sie machen > soll? Ich hab das Demo-Test-Programm von Yagarto verwendet: Folgender Link: http://www.yagarto.de/howto/examples/index.html Und davon das STM32Test. Gruß Uli
Anbei die angepasste Routine mit etwas Kommentar:
1 | void IO_InitApp(void) |
2 | {
|
3 | SAVE_PC(); // Für Debug-Zwecke |
4 | |
5 | RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC , ENABLE); // Enable von Clock für den Port C (sonst geht nichts) |
6 | |
7 | GPIO_InitTypeDef GPIO_InitSt; |
8 | GPIO_InitSt.GPIO_Pin = GPIO_Pin_12; // Pin 12 |
9 | GPIO_ResetBits(GPIOC, GPIO_InitSt.GPIO_Pin); // PortPins vorinitialisieren |
10 | GPIO_InitSt.GPIO_Mode = GPIO_Mode_Out_PP; // Portdefinition |
11 | GPIO_InitSt.GPIO_Speed = GPIO_Speed_50MHz; // Geschwindigkeit |
12 | GPIO_Init(GPIOC, &GPIO_InitSt); // PortC mit Portdefinition initialisieren |
13 | }
|
Der Segger GDB-Server ist auch an? (Run External Tools)
Hallo Zusammen Nachdem nun meine IDE Crossworks läuft will ich mich nochmals der Eclipse Geschichte (Sprich Yagarto rsp. STM32 Forum) widmen. Dazu nochmals eine Frage betreffend Eclipse Installation. Unter dem Link via Yagarto sind folgende Eclipse Download Varianten angegeben: 1.Eclipse SDK >eclipse-SDK-3.6.2-Win32.zip 2.Platform Runtime Binary >eclipse-platform-3.6.2-Win.zip 3.platform SDK >eclipse-platform-SDK-3.6.2-Win.zip Punkt 2 wird bei Yagarto als die benötigte Zip-Datei angegeben. Ist es aber richtig dass alle 3 Zip-Dateien Funktionieren würden ? @Markus Dein Link gibt nun wieder eine völlig ander Zip-Datei an ! 4.Eclipse IDE for C/C++ developers > eclipse-cpp-helios-SR2-Win32.zip Ist es Richtig dass es keine Rolle spielt, welche 4 Varianten ich nun entzippe und in das Verzeichnis C:\WinARM\Elipse kopiere ? Handelt es sich bei all diesen Zip-Dateien im Grunde um dass selbe nämlich die Eclipse IDE mit unterschiedlichen Plug-Ins ? Wenn ja sollte ich da nicht von anfang an Eclipse SDK nehmen ? Diese ist nähmlich die mit Abstand grösste Datei ! Gruss Roger
Ich habe die 4. installiert und kenne die anderen nicht. Dazu das CDT Plugin, so wie in Yagarto beschrieben.
Es gibt doch eine Version, wo die CDT schon dabei sind. Die ist genau richtig und spart die Extrainstallation der CDT.
900ss schrieb: > Heißt Eclipse for C/C++ Developers Also genau die 4.Version eclipse-cpp-helios-SR2-Win32.zip diese entspricht wohl der bei Yagarto angegebenen: eclipse-platform-3.6.2-Win.zip + Installation der CDT-master-7.0.2 Oder ? Gruss Roger Es scheint zwar ein detail zu sein sollte aber unbedingt noch genauer bei der STM32 Installation beschrieben werden
@markus Hast Du für das Demo folgendes Verzeichnis ? C:\WinArm\Projekt\BlinkLED oder C:\WinArm\Projekt\Proj_Demo\BlinkLED Gruss Roger
yello8247 schrieb: > Also genau die 4.Version > eclipse-cpp-helios-SR2-Win32.zip Ja > diese entspricht wohl der bei Yagarto angegebenen: > eclipse-platform-3.6.2-Win.zip > + Installation der > CDT-master-7.0.2 Ja, da kommt am Ende das selbe heraus. Die waren halt so freundlich und haben das schon für uns zusammen in ein Paket gepackt. :-)
C:\WinArm\Projekt\Proj_Demo\BlinkLED Wobei man einfach das ganze nach C:\WinArm\Projekt\ entpackt.
Uli B. schrieb: >> Mit dem AVR-Studio? Mit Eclipse ist es auch anders. > > Mit AVR-Studio... O.K. Wenn du es genauso haben öchtest, dann kannst du dir das einrichten, wenn du weißt wie das geht ;-) Mach erstmal alles schrittweise. 1) Compileren und linken (klappt wohl schon) 2) Flashen (eine Debug Konfiguration, heißt Debug, flasht aber nur) 3) Eine Debug Konfiguration zum Debuggen. Alles zusammenfassen kannst du immer noch, wenn du mit Eclipse mehr vertraut bist. Und Schritte 2/3 habe mit 1 nicht das Geringste zu tun in Eclipse. Das wird an völlig verschiedenen Stellen konfiguriert.
Schön dass sich dieses Themas hier mal ein paar Leute annehmen. Die Anzahl der Antworten zeigt wie dringend das ist. Vor über 2 Jahren habe ich OOCD/Eclypse später auch Yagarto auch schon mal probiert zu installieren und dann frustriert aufgegeben und viel Geld für etwas kommerzielles ausgegeben. Viele Leute werden den Hickhack um OOCD mit breitem Grinsen vergnügt lesen, denn wenn es den nicht gäbe, würden sie nichts verkaufen. Nun zur Gegenüberstellung der Qualität einer kommerziellen Lösung, in meinem Fall einen Hitex Tantino: Wer meint, er hätte viele Probleme los, indem er Geld für eine kommerzielle Lösung ausgibt, irrt sich in vielen Fällen. Nur hier ist man etwas hartnäckiger weil es viel Geld gekostet hat. Gut- mein Tantino hat die Seriennummer 2, aber trotzdem gibt es auch für alte Assemblerprogrammierer kaum eine Chance ohne Support auszukommen. Alle mitgelieferten Hitex Debug-Beispiele sind für Cortex-A8 eingestellt und mit einem M3 fliegt man fürchterlich auf die Fresse. Schliesslich will man ja nicht nur einen Debugger sondern auch eine Schulung dazu verkaufen. Weiter geht es mit dem Manual: Im Gegensatz zu Segger und anderen gibt keine einzige Stelle in der Doku wo beschrieben ist, wie das Zielsystem für die Fälle JTAG und SWD auszusehen hat. Datenblätter sind dazu i.d.R. ebenso ungeeignet und offensichtlich gibt es den jüngsten Artikel von mmvisual auch nicht umsonst. Aber schliesslich will man bei Hitex ja auch eine Entwicklungsdienstleistung verkaufen. Weiter geht es mit dem Compiler. Hier ist ein GCC sowie die Demoversion von Tasking beigepackt. Ursprünglich gab es bei ST Beispiele für Hitex - darunter verstand man dann die Tasking Version. Versuche mit dem Hitex GCC die GCC Version zu übersetzen endeten immer in einer Exeption beim Versuch den Code laufen zu lassen, weil der GCC Assembler das Thumb bit nicht gesetzt hat. Spätestens hier hat man nicht nur als Anfänger das Problem auf die Idee zu kommen, den Startup Code der ST Lib abzuändern damit überhaupt irgendwas geht. Aber schliesslich soll man ja nicht nur einen Debugger sondern auch einen kommerziellen C-Compiler dazu kaufen. Offensichtlich der einzige Grund, warum sich der Hitex GCC buildt in Details von den anderen unterscheidet. Mit dem Kauf eines Compilers ist es dann ja nicht getan, denn man soll ja auch noch den Support dazu kaufen usw. Nach unzähligen Bugfixes ist die Hitop Oberfläche zwischenzeitlich eine Version weiter geschritten. D.h. wenn ich jetzt einen STM32F2xx nehmen will, muß ich das Tool noch einmal kaufen, weil ich mit meiner Version das vermutlich nie flashen kann. Neben weiteren ständigen Abstürzen mal genug zu kommerziellen Lösungen. Summa Summarum ist die Zeit längst reif, daß es DAU Artikel zu OOCD, stabile Install und ansehliche Oberflächen zum GDB gibt und nicht jeder selbst bei Max und Moritz anfangen muß. Der ST Lib bin ich anfänglich wegen dem vielen Code auch kritisch gegenüber gestanden. Nach Portierung von einem F103 auf einen F107 bin ich aber überzeugt. Es hat einfach alles auf Anhieb funktioniert und ohne ST-Lib wäre das nicht so gewesen. Also, weiter so und vielen Dank - ich werde demnächst bei Gelegenheit auch mal wieder einen Installationsversuch probieren und mein Projekt anschliessend vom Hitex GCC auf einen Codesourcery GCC umstellen. Das Tantino Teil kann ich dann hoffentlich in die Tonne treten, wie das ein Kollege vor mir schon länger getan hat. Er hat dann übrigens notgedrungen bei IAR investiert.
J. V. schrieb: > Nun zur > Gegenüberstellung der Qualität einer kommerziellen Lösung, in meinem > Fall einen Hitex Tantino: Wer meint, er hätte viele Probleme los, indem > er Geld für eine kommerzielle Lösung ausgibt, irrt sich in vielen > Fällen. Hallo Bin Grundsätzlich der selben Meinung wie Du. Nur das mit der Gegenüberstellung kommerzieller Lösungen bin ich ganz anderer Meinung ! Wir arbeiten bei uns in der Firma mit Keil MDK-ARM. Das sind natürlich Welten betreffend Bedienung und Inbetriebnahme ! Kostet aber auch dementsprechend. Für eine Firma rechnen sich aber diese Kosten bei weitem ! Wenn ich denke wie viele Stunden ich schon verbraten habe ein kostenloses System wie Eclipse vergebens fehlerfrei in Betrieb zu nehmen im Gegensatz zu Keil (max.2Std dann läuft die Geschichte). Als privater aber will man natürlich nicht 3000.-Euro auf den Tisch blättern nur für ein paar Hobbyprojekte ! Als sehr gute Zwischenlösung gibt es Crossworks. Sehr schnelle Inbetriebnahme. Allerdings auch hier unmengen an parameter welche man einstellen kann (muss).Hier hat man aber wenigstens den Support So langsam kann ich aber verstehen warum Professionelle Lösungen wie Keil oder IAR so teuer sind. Denn im Grundegenommen müssen diese ja auch die verschiedensten SW-Module zu einer einzigen benutzerfreundlichen IDE zusammenführen. Und das hat wie wir ja alle schmerzhaft erfahren müssen nicht ganz so einfach. Frohe Ostern und viel vergnügen beim weiter Basteln Roger
Markus Müller schrieb: > C:\WinArm\Projekt\Proj_Demo\BlinkLED > > Wobei man einfach das ganze nach C:\WinArm\Projekt\ entpackt. Hallo Markus Hast Du somit Dein Workspace von Eclipse wie folgt eingestellt? C:\WinArm\Projekt\Proj_Demo Ich frage deswegen weil eclipse bei mir die c. files nicht findet (erst bei aktualisieren F5). In .metadaten sind ja sämtliche Eclipseinstellungen gespeichert ? von daher glaube ich ist es richtig den Workspace so einzustellen C:\WinArm\Projekt\Proj_Demo\.metadata Aber eben damit findet er keine Source-Dateien. oder muss ich den Workspace auf C:\WinArm\Projekt einstellen ? Dann würden aber zwei .metadaten verzeichnisse entstehen. Eines von Eclipse generiert und das ander vom Proj_Demo. Sorry für meine pingeligen Fragen Roger
Das Workspace ist C:\WinArm\Projekt\Proj_Demo darin ist dann das Projekt (= Verzeichnis) BlinkLED. Immer wenn man eine Datei von wo anders verändert hat, dann möchte Eclipse ein Refresh (F5) haben, damit liest er alles neu ein. Ich arbeite auf zwei PC's mit dem gleichen Projekt, wenn ich die Dateien rüber kopiere, dann muss ich auch immer mit F5 aktualisieren, dann geht es weiter mit dem anderen Rechner. (PC Werkstatt/Wohnung)
Ok vielen Dank Das bedeutet aber das Eclipse zu jedem Projekt ein eigenes .metadaten Verzeichnis hat und demensprechend auch bei jedem aufstarten von Eclipse auch ein neues Workspace (nähmlich das vom gerade zu bearbeitendem Projekt) angegeben werden muss ? Bei keil sind halt sämtliche IDE Einstellungen im Projektfile abgespeichert. Da muss kein Workspace beim aufstarten der IDE angegeben werden da diese ja beim öffnen eines Projektes automatisch festgesetzt werden. Gruss Roger
Im Workspace ist das .metadata sowie die Verzeichnisse der Projekte. In einem Workspace können mehrere Projekte drin sein. Im Projekt BlinkLED sind auch wiederum Eclipse Dateien drin, die projektspezifischen Einstellungen beinhalten. Im Workspace-Verzeichnis habe ich eine Batch-Datei drin, diese kann alle (mir bekannten) Verzeichnisse aufräumen und ein make clean ausführen, somit ist das Projekt etwas kleiner beim Zippen. Diese Batch-Datei muss natürlich von Hand angepasst werden. Ich glaube, du hast Workspace und Projekt verwechselt.
Markus Müller schrieb: > Ich glaube, du hast Workspace und Projekt verwechselt. Nein Nein ich glaub eher das wir aneinander vorbeireden. Für mich ist eben Dein Projektverzeichnis \Proj_Demo irreführend. Ich denke folgende Verzeichnisstrucktur wäre besser verständlich: C:\WinArm\Projekte\BlinkLED Das DemoProjekt (Hier können natürlich noch ander projekte sein) C:\WinArm\Projekte\ Workspace C:\WinArm\Projekte für Eclipse (Zugriff auf .metadata) So kann ich das Workspace für Eclipse fix auf C:\WinArm\Projekte eingestellt lassen. zusätzliche Projekte können dann unter C:\WinArm\Projekte dazugefügt werden Dein zusätzliches Verzeichnis Proj_Demo geht natürlich auch ist aber von der Namensgebung ein wenig verwirrend ! Wie Du ja ab meiner blöden Fragerei bemerkt hast. Gruss Roger
Unter C:\WinArm\Projekte\ habe ich all meine Workspaces (Verzeichnisse). Natürlich könnte ich auch alles in einer Workspace drin halten, aber ich denke es ist besser mehrere Workspaces zu haben. Wenn jetzt mehrere Leute an mehreren Projekten arbeiten ist das wichtig, denn sonst könnte man die nicht so leicht austauschen, weil die Projekt-Infos der Workspace in irgend welchen Eclipse-Dateien vergraben ist. Ich zippe immer das gesamte Workspace immer komplett und habe so eine vollständige Sicherung, unabhängig von anderen Workspaces. Natürlich könnte man: C:\WinArm\Projekte\ nach C:\WinArm\Workspaces\ umbenennen, aber mir ist die deutsche Bezeichnung da lieber.
Angehängte Dateien:
-
Fehler2.jpg
290 KB
Hallo !
Ein Bild sagt mehr als tausend Worte...
Ich weiß aber dennoch nicht weiter.
Bei manchen Debug Konfigs kann ich durchsteppen aber wenn ich mir die
Watch-Variablen anzeigen lassen will, dann kommt
<error(s)_during_the_evaluation>
Target request failed mi_cmd_var_create: unable to create variable
Object.
Gruß Uli
Uli B. schrieb: > Ich weiß aber dennoch nicht weiter. Es sieht so aus, als wenn du die Debug-Konfiguration für OpenOCD verwendest, aber einen Segger GDB-Server benutzt. Das paßt nicht zusammen. Hin und wieder, wenn das Debuggen nicht klappt, also Eclipse bricht ab, dann sollte man mal mit dem Windows Taskmanager schauen, ob wirklich Starter.exe und der ARM...GDB.exe beendet wurden. Das vergoßt Eclipse manchmal oder kann diese beiten Tasks aus mir unbekannten Gründen nicht beenden. Das muß man dann "mit der Hand" nachholen.
Markus Müller schrieb: > Natürlich könnte man: > C:\WinArm\Projekte\ > nach > C:\WinArm\Workspaces\ > umbenennen, aber mir ist die deutsche Bezeichnung da lieber. Dann müßte Dein Verzeichnis "C:\WinArm\Arbeitsbereich" heißen. Markus Müller schrieb: > Ich zippe immer das gesamte Workspace immer komplett und habe so eine > vollständige Sicherung, unabhängig von anderen Workspaces. Es reicht, wenn du den Projektordner sicherst. Da ist alles drin, was für das Projekt wichtig ist. Es gibt in jedem Projektverzeichnis die versteckten Dateien .cproject und .project. Darin stehen die Projekteinstellungen.
Hi Markus, da du schon mit dem Beitrag angefangen hast, versuche ich gerade den bisherigen Text von mir mit deinem zu mergen. Die Frage ist, welches Eval-Board du da in dem Artikel expliziet meinst, wenn du das Discovery-Board angedacht hast, würde ich vorschlagen dieses expliziet aufzuschreiben. Jedoch ist auf dem Discovery-Board ja eigentlich der ST-Link verbaut, so dass die in Betriebnahme der beiden äquivalent wäre. Daher würde ich evtl. eine andere Überschrift wählen. Ansonsten wenn du nichts dagegen hast das ich dir da ein wenig rein pfusche, würde ich dieses Unterthema gern beschreiben.
Hallo Bjoern, Es soll ein einfaches Demo-Projekt sein, ohne Bindung an ein spezielles Board. Die Ports für die Blink-LED kann man relativ leicht "umbiegen". Das Demo-Programm lässt auch schon unterschiedliche Portpins Blinken, damit hat man schon das ein oder andere Board abgedeckt. Wenn Du die Konfiguration für einen ST-Link hast, dann kannst du mir das in das Demo-Projekt einfügen und mir mailen, dann kann ich diese Einstellung (External Program / Debug-Konfig) mit in das Demo übernehmen. Irgend wann einmal hat man so ein "Master-Demo" das alle möglichen Adapter drin hat und jeder kann sich daraus seines laden. Ich hatte gehofft, dass du auch den Artikel erweiterst und vielleicht Schaubilder wie das zusammenhängt einfügst.
Markus Müller schrieb: > Es soll ein einfaches Demo-Projekt sein Ich gerade probiert, dein Projekt zu kompilieren. Dazu habe ich nicht Yagarto + Tools installiert da ich eine funktionierende Toolchain u.s.w. habe. Den Aufruf von "gmake" habe ich in den Projekteinstellungen zu "make" geändert. Der Buildprozess (make) läuft nicht durch. Das liegt daran, dass du in deinem Makefile
1 | SRC += src/timer_task.c |
stehen hast und die Datei in Wirklichkeit
1 | Timer_Task.c |
heißt. Also Groß- und Kleinschreibung sind unterschiedlich. Wenn man das korrigiert, dann funktioniert es. Mit den Yagartotools (habe dann nur die Tools installiert) funktioniert es auch, da das "Make" von Yagarto scheinbar nicht Case-Sensitiv ist. Das ist recht ungewöhlich für "Make" und eine Speziallösung. Solche Dinge solltest du in deinem Artikel erwähnen, dass das normalerweise nicht so ist. Die Leute, auf die dein Artikel abziehlt wissen diesen feinen Unterschied oft auch nicht und wundern sich, wenn sie mal eine andere Umgebung haben bzw. wenn sie selber einen Makefile schreiben der dann in einer anderen Umgebung nicht funktioniert. Das Debuggen hab ich noch nicht probiert, dazu muß ich erst noch das Testprogramm an meine Hardware anpassen.
Vielen Dank für den Hinweis. Ich habe den Name Timer_Task.c im makefile geändert. Außerdem habe ich den Stack gleich auf 20K initialisiert, dann sollte es mit den meisten Demo-Boards (mit STM32F103xB) gehen. Wegen "Make" wo steht das? Ich habe eine neue Version vom Demo gerade in den Artikel geladen: STM32 Eclipse Installation Und den Hinweis auf gmake direkt beim Download-Link hinzugefügt. Wenn ich das gmake bei mir auf make ändere kann ich nicht mehr kompilieren, da ich auch Delphi auf dem Rechner habe.
Markus Müller schrieb: > es ist besser mehrere Workspaces zu haben. Nun dann ist es aber doch wie ich anfangs vermutet habe ! Beim aufstarten von Eclipse (Je nach projekt welches man gerade bearbeiten will) wird eine ander Workspace ausgewählt. Oder ? Gruss Roger
900ss D. schrieb: > Es reicht, wenn du den Projektordner sicherst. Da ist alles drin, was > für das Projekt wichtig ist. Es gibt in jedem Projektverzeichnis die > versteckten Dateien .cproject und .project. Darin stehen die > Projekteinstellungen. Dann wäre eine Verzeichnisstruktur von C:\WinArm\Projekte\ Fixe Workspace-Einstellung für Eclipse da neben den Projektordnern ja auch noch der Ordner .metadata steht. In den Projektordern selber kann dann auf den Order .metadata verzichtet werden. (Resp.wird ja von Eclipse auch gar keines mehr angelegt) Verstehe ich das richtig so ? Gruss Roger
Markus Müller schrieb: > Ja. Hallo Markus Dein Ansatz hat den Vorteil das Du somit pro Projekt nicht nur die Projekteinstellungen gesichert hast sondern auch immer noch die Eclipse Einstellungen auch wenn dies in der Regel die selben bleiben. (Ausser man wechselt die Kontrollerplattform) Nachteil: Beim Starten von Eclipse ist jedesmal die Workspace neu zu wählen. Mein beschriebener Ansatz würde nur die Projekteinstellungen sichern. Dafür kann ich eine fixe Workspace bei Eclipse einstellen und müsste beim aufstarten dann diese nicht immer wieder neu wählen. Dein Demo-projekt beinhaltet somit sämtliche Eclipse-Einstellungen. Somit genügt es die Eclipse-Tools zu installieren und danach einfach Dein Projekt öffnen. Die Einstellerei gemäss Yagarto kann man sich sparen ? Richtig so ? Gruss Roger
yello8247 schrieb: > Verstehe ich das richtig so ? Ja. In den Projektordnern wird nur alles zum kompilieren des Projektes gespeichert. Die Debugkonfiguration leider nicht. Die ist aber schnell hergestellt wenn man es erst einmal begriffen hat. Ich verstehe auch nicht warum die nicht im Projekt abgelegt werden ist aber leider so.
Markus Müller schrieb: > Wegen "Make" wo steht das? Make kommt aus der Unixwelt und da sind Dateinamen case-sensitive. Bei Yagarto ist das ein Sonderfall, hat er wohl selber umgebaut. Ist mir sonst noch nie so begegnet. Wenn du zum Beispiel die Codesourcery Toolchain nimmst (da heißt das dann cs-make, ist aber ein GNU make) das ist case-sensitive. Eigentlich kann man ein beliebiges (evtl. schon installiertes) GNU-Make nutzen. Wenn man z.B. auch die WinAVR Toolchain installiert hat, dann kann man das Make benutzen (muß im Pfad stehen). > Und den Hinweis auf gmake direkt beim Download-Link hinzugefügt. Wenn > ich das gmake bei mir auf make ändere kann ich nicht mehr kompilieren, > da ich auch Delphi auf dem Rechner habe. Das liegt an den Pfaden. In deinem Pfad ist dann der zu dem Make von Delphi als ersten vorhanden. Wenn du den zu den Yagarto Tools als erstes in deinem Pfad einbaust wird er beim bauen von dem Demoprojekt das richtige Make nutzen. Dann funktioniert das bauen von Delphi--Projekten wahrscheinlich nicht mehr :-)
Hallo 900ss ! Wegen Deiner Antwort: Beitrag "Re: STM32 Eclipse Entwicklungsumgebung" Nachdem ich so oft gehört habe - das man den OpenOCD unbedingt braucht - habe ich ihn halt installiert. Ich benutze ihn nicht da ich im Augenblick nicht weiß was noch alles gebraucht wird. Ich hab nur das Demo-Projekt von Markus installiert. Wie der OpenOCD da rein kommt weiß ich nicht. Die Namen sind aber nur in der Debug Konfiguration als Überschrift so angegeben. Im Reiter "Debugger" wird meist der arm-none-eabi-gdb verwendet - falls ich Eclipse richtig verstanden habe. O.K. der OpenOCD ist offensichtlich ein On-Chip-debugger (der event. später zum Einsatz kommt - wenn mal Land in Sicht ist) aber mir würde es schon reichen wenn ich Programme debuggen könnte und dann auch flashen könnte. Gruß Uli
Es werden für openocd und Jlink unterschiedliche Kommandos verwendet. Die ich bei dir sehen konnte waren für openocd.
hmm das kann ich gern machen... ob ich dann heute schon dazu komme, das Beispiel einzupflegen weiß ich nicht, da ich heute Abend erstmal Windows XP in der VM installieren muss. Ich werde dieses dann direkt ausnutzen und zu jedem Schritt Screenshots machen, so dass man diese dann später in dem Artikel wieder verwenden kann.
Hallo 900ss ! O.K. heißt das nun dass das OpenOCD nicht rchtig installiert ist oder wie sollte ich jetzt weiter vorgehen ? Gruß Uli
Uli B. schrieb: > Hallo 900ss ! > > O.K. heißt das nun dass das OpenOCD nicht rchtig installiert ist oder > wie sollte ich jetzt weiter vorgehen ? > > Gruß Uli Du brauchst für den JLink kein OpenOCD. Kannst es getrost vergessen. OpenOCD ist ein freien GDB-Server der mit verschiedenen JTAG Debuggern (Olimex, Amontec, ....) zusammenarbeitet. Bei dieses Debuggern wird kein GDB-Server mitgeliefert sondern da mußt du den OpenOCD nutzen. Anders bei dem JLink von Segger. Dort ist der GDB-Server dabei. Der Segger GDB-Server eben. Den mußt du starten bevor du im Eclipse das Debuggen startetst. Du kannst den GDB-Server auch von Eclipse aus starten. Dafür mußt du dir das unter "External Tools" einrichten. Aber du mußt ihn auch dann extra und bevor du das debuggen aufrufst, starten. Du solltest eine Debugkonfiguration in Markus seinem Beispielprojekt haben die da heißt: "BlinkLED Segger Reset Load Debug". Die mußt du benutzen um dann das debuggen zu starten. Alle anderen sind für OpenOCD so wie der Name ja auch schon sagt.
Hallo Zusammen Wage mich wieder ans Eclipse Projekt. Ich gehe davon aus dass wenn ich das BlinkLED projekt von Markus in Eclipse Lade, sämtliche Einstellungen stimmen. Natürlich mit der Ausnahme des OpenOCD .cfg File für mein JTAGKey2. Dieses habe ich in das Verzeichnis kopiert und in der Configuration von OpenOCD geändert. Trotzdem bekomme ich keine Verbindung zu meinem Evalboard hin. Die Fehlermeldung kann man auf dem Printscreen sehen. Weiss da jemand was ich falsch mache ?
Ich vermute mal das ist der USB-Treiber. Versuche mal diese DLL (Anhang) auch in das prj Verzeichnis zu kopieren und dann nochmals versuchen. Wenn das nicht geht, dann muss der USB Treiber deinstalliert und erneut installiert werden. Mit dem Setup von OpenOCD müssten "drivers" dabei sein.
So ich habe auch wenn es im Artikel leicht OT sein könnte die Installation des GDB-Servers und Linux für das ST-Link hinzugefügt. Das Projekt selbst ist noch Beta, jedoch habe ich bisher keine Probleme feststellen können. Die Einrichtung vom ST-Link unter Windows werde ich dann die Tage weiter fortführen. Ich hoffe das dies genehm ist.
Markus Müller schrieb: > Ich vermute mal das ist der USB-Treiber. > Versuche mal diese DLL (Anhang) auch in das prj Verzeichnis zu kopieren > und dann nochmals versuchen. > Wenn das nicht geht, dann muss der USB Treiber deinstalliert und erneut > installiert werden. Mit dem Setup von OpenOCD müssten "drivers" dabei > sein. Hallo Markus Also dass mit der DLL ins Verzeichnis kopieren funktioniert nicht ! Ich habe ja auch die neuesten USB FTDI Treiber installiert siehe PDF im Anhang. Grossworks erkennt ja auch das FTDI Device (JTAGKey2) und funktioniert einwandfrei mit diesen Treibern. Auch Grossworks verwendet ja den OpenOCD im hintergrund ? Was mach ich falsch ? Auch habe ich in verschiedenen Foren gelesen das man den neuesten USB-JTAG Treiber von Amontec für den Betrieb mit OpenOCD installieren muss !
@Björn: Vielen Dank! @yello8247: Starte doch einfach mal den OpenOCD über Grossworks und versuche dich darüber mit Eclipse zu verbinden. Ob jetzt Grossworks oder Eclipse OpenOCD startet ist egal.
Markus Müller schrieb: > @Björn: Vielen Dank! > > @yello8247: > Starte doch einfach mal den OpenOCD über Grossworks und versuche dich > darüber mit Eclipse zu verbinden. > Ob jetzt Grossworks oder Eclipse OpenOCD startet ist egal. Also ich habe nochmals folgende möglichkeiten durchgeführt: 1. OpenOCD Treiber installiert Eclipse wie auch Crossworks funktioniert nicht ! 2. Treiber von Amontec Homepage installiert Eclipse wie auch Crossworks funktioniert nicht ! 3. Neuester Treiber von Amontec (komischerweise nur über Forums Downloadbar) Eclipse funktioniert nicht !! Crossworks Funktioniert einwandfrei ! 4. Crossworks gestartet und mit JTAGKey verbunden. Zusätzlich Eclipse gestartet aber trotzdem keine verbindung zum JTAGKey möglich. Ich glaube es liegt nicht am Treiber sondern eher an einer Einstellung unter Eclipse. Schon unglaublich welch hindernisse einem Eclipse hier in den Weg legt ! Gruss Yello8247
Dann ist es wichtig heraus zu finden wie Crossworks OpenOCD startet, also welche Start-Parameter Crossworks dem OpenOCD übergibt.
Markus Müller schrieb: > Dann ist es wichtig heraus zu finden wie Crossworks OpenOCD startet, > also welche Start-Parameter Crossworks dem OpenOCD übergibt. OpenOCD sollte in der Windows-Console so starten. Dann ist alles gut. Was Crossworks da speziell macht funktioniert bei einem anderen schon nicht mehr. yello8247 schrieb: > Ich glaube es liegt nicht am Treiber sondern eher an einer Einstellung > unter Eclipse. Ja. > Schon unglaublich welch hindernisse einem Eclipse hier in den > Weg legt ! Seit wann ist Eclipse für die Einstellungen zuständig (siehe oben)? Also den Schuh must du dir anziehen. Für die Unzulänglichkeiten der Bediener kann Eclipse nichts. ;-) Kannst du denn OpenOCD in der Windows Console (Cmd) starten? Das würde ich erstmal versuchen. Wenn das geht, dann sollte es auch von Eclipse aus gehen. Pfade solten stimmen. Die Konfigurationsdateien die selben. Das es von Crossworks aus geht zeigt, das es auch von Eclipse aus gehen sollte. Ich nutze OpenOCD aus verschiedenen Gründen nicht mehr und kann es deshalb auch nicht für dich probieren.
900ss D. schrieb: > Seit wann ist Eclipse für die Einstellungen zuständig (siehe oben)? Also > den Schuh must du dir anziehen. > Für die Unzulänglichkeiten der Bediener kann Eclipse nichts. ;-) Nun gut ich gebe mich geschlagen ! Da hast Du natürlich recht. > > Kannst du denn OpenOCD in der Windows Console (Cmd) starten? Können schon. Nur genau da erwarte ich bei einer IDE wie Eclipse dass mir dies erspart bleibt ! (Bei crossworks muss ich ja auch nicht noch auf consolenebene rumwursteln.) Aber ich werde es versuchen. Danke Yello8247
Hallo ! Ich möchte mich nochmals zu Wort melden, da ich es mittlerweile aufgegeben habe das ganze zum laufen zu bekommen. Es scheitert ja schon am durchsteppen des Programms BlinkLED von Markus. Nun was mir mittlerweile auffällt ist mit welcher Vehemenz das ganze versucht wird unter Eclipse zum laufen zu bekommen. Ich möchte bei diesem Thread weder Markus noch sonst jemand stören, nur wenn es schon an der Entwicklungs-Umgebung scheitert - dann ARMes Deutschland.... Ob ich eine andere Lösung habe ? Ja, offensichtlich gibt es die - nur ich kenne mich halt zu wenig aus um die Einstellungen richtig hinzubekommen. Ich erinnerte mich an früher zum Beispiel der ddd (Data-Display-Debugger). Den hab ich immer als Debugger genommen. Durch einen Zufall las ich in den JLink-Manuals dass die offensichtlich mit JLink funktionieren ! Gut O.K. Roger wird jetzt sagen das sind Linux-Geschichten und die laufen ja glaube ich bei ihm nicht. Es gibt aber die Möglichkeit Cygwin zu installieren und die beinhalten diese Tools die unter WinXX laufen ! Halt keine Panik davor - Diese Tools werden per Setup downgeloaded und installiert und hier gibt es kein Wenn und Aber wie bei Eclipse - installieren - läuft ! Wie ich meine sind diese Tools sehr viel transparenter als Eclipse. Ich habe es geschafft ddd und insight zwar mit den JLink zu connecten aber hier sind die Einstellungen nicht korrekt. Aber der ddd ist sehr angenehm im Handling und jeder sollte mal sich überlegen ob sich diese enorme Mühe lohnt das ganze unter Eclipse zum laufen zu bekommen. Gut bei dem wo es läuft ist es ja schön - aber die, die dran scheitern sollten es vielleicht mal mit Cygwin probieren. Nähere Auskünfte dazu kann ich gerne geben nur bei den Einstellungen kann ich nichts sagen. Gruß Uli
yello8247 schrieb: > (Bei crossworks muss ich ja auch nicht > noch > auf consolenebene rumwursteln.) Das soll doch nur ein Test sein, ob OpenOCD überhaupt läuft. Wenn du OpenOCD in der Konsole am laufen hast, dann solltest du dich mittels Eclipse verbinden können, also mit der Debugkonfigartion von Markus seinem Beispielprojekt. Wenn das geht, dann kannst du versuchen von Eclipse aus das OpenOCD zu starten. Um zwei Mausklicks kommst du aber trotzdem nicht rum :-) Der erste startet OpenOCD, der zweite das Debuggen. Uli B. schrieb: > nur ich kenne mich halt zu wenig aus um > die Einstellungen richtig hinzubekommen Da liegt das Problem und nicht bei Eclipse. Einfach kopflos mal eben was machen klappt halt nicht. Man muß schon verstehen, was dahinter werkelt. Eclipse ist nicht eine alles umfassende rundum-sorglos Lösung. Es ist komplex zu konfigurieren, das stimmt. Dafür kann ich aber auch fast jede Toolchain daran korken. Wenn du Crossworks oder sonst eine All-In-One Lösung nimmst, die kann auch nur das eine. Eclipse nutze ich für AVR, ARM und SPARC. Ach ja... kleine PC-Programme entwickel ich auch damit. Und ich hab keinen Pfennig dazubezahlt ;-)
Meines erachtens nach wissen die meisten leider nicht, welche Arbeit eine Toolchain abnimmt. Das mache ich keinem zum vorwurf auch nicht das man sag - hmm es läuft alles das reicht mir, aber der punkt ist schnell erreicht, wo alles zusammen kracht und die hürde die man anschließend nehmen muss ist schon sehr hoch ist um das Problem zu lösen. Das merke ich selbst derzeit an Linux - solange alles vernünftig läuft ist alles super aber kommt nur ein kleiner fehler - dann steht man wie ein Ochs vorm Berg davor. Das gleiche gilt auch für den Umstieg vom AVR zum STM32F10X. Eclipse kann viel - nur vergessen die Leute meist (und oft auch wegen unwissenheit) wieviel Arbeit dahinter steckt, damit Eclipse so läuift wie man es sich vorgestellt hat.
Björn Cassens schrieb: > Eclipse kann viel - nur vergessen die Leute meist (und oft auch wegen > unwissenheit) wieviel Arbeit dahinter steckt, damit Eclipse so läuift > wie man es sich vorgestellt hat. Nun das verstehe ich schon (Mittlerweile)! Für mich heisst die Lösung für Zuhause Crossworks ! 150 $ sind für Private zwecke noch verkraftbar. Aber meine Sturrheit lässt es nicht zu die ganze Geschichte nicht doch noch unter Eclipse selber zum laufen zu bringen. Es ist mir auch bewusst dass dies gerade als Greenhorn nicht ein einfaches unterfangen ist. Vielen Dank an all Eure intressanten Beiträge und verzeiht meiner zwischendurch etwas polemischen Sprüchen. Gruss Roger
Mal eine Frage an die Leute die es nicht hinbekommen. Habt Ihr beruflich mit solchen Dingen zu tun oder ist das nur Hobby? Mit runterladen und installieren brauche ich 15 Minuten unter Windows oder Linux und das ganze läuft. Allerdings ohne Yagarto und mit ein wenig Erfahrung im Umgang mit Eclipse. Das hat nichts mit wochenlangem rumtüfteln zu tun! Zu dem wie, das habe ich hier weiter oben ja schon geschrieben... Zu Eclipse. Die sind quasi Marktführer ohne für Ihr Produkt bezahlt zu werden. Es gibt keinen Editor der so bequem und komfortabel ist. Man kann alle möglichen Tool-chains einbinden und so den gleichen Editor für alle möglichen Plattformen benutzen. Nur das Visual Studio von MS kommt da mit. Das allerdings nicht für so viele Plattformen und auch nicht kostenlos.
Also ich habe beruflich wie privat viel mit Eclipse zu tun. Ich kann sagen, wenns einmal läuft ist das Tool hervorragend. Allerdings muss ich trozt mehrjähriger Eclipse Erfahrung immer wieder auf Hilfe von Kollegen oder Foren zurückgreifen. Das Hauptproblem von Eclipse liegt in meinen Augen darin, daß die Konfiguration einfach unkomfortabel und intransparent ist. Dazu kommen dann die unterschiedlichen Namen der Eclipse Versionen (Ganymede, Europe, Helios, ....), das Installieren von PlugIns und das erstmal gewöhnungsbedürftige Workspacekonzept. Und was ich bis heute nicht raffe: Wieso bekommt man das Eclipse auf einmal innerhalb von 15 min korrekt konfiguriert, wo man davor über eine Woche vergebens rumgedoktort hat? Wie gesagt, ein super Tool das (fast) alles kann, aber extrem zickig. Fast wie ne Frau ;-)
Daniel R. schrieb: > Mit runterladen und installieren brauche ich 15 Minuten unter Windows > > oder Linux und das ganze läuft. Achtung nicht falsch verstehen. Das runterladen und installieren ist ja auch nicht das Problem. Die Einstellungen sind die Knacknüsse ! Das hat vielleicht auch nicht direkt was mit Eclipse zu tun. (OpenOCD Make usw.) Man verwendet dann halt als Ueberbegriff Eclipse. Gruss Yello8247 PS: Ich habe Beruflich wie auch privat damit zu tun. Wenn man aber in der Firma mit professionellen Tools (KEIL ... usw) zu tun hat, braucht man sich nicht um details wie make usw. zu kümmern. Von da her fehlt einem dann das nötige KnowHow !
900ss D. schrieb: > Kannst du denn OpenOCD in der Windows Console (Cmd) starten? > > Das würde ich erstmal versuchen. Wenn das geht, dann sollte es auch von > > Eclipse aus gehen. Hallo 900ss D Habs nun versucht. Doch leider genau die gleiche Fehlermeldung ! c:\WinARM\OpenOCDTest>openocd -f jtagkey2.cfg -f stm32.cfg Open On-Chip Debugger 0.4.0 (2010-02-22-19:05) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 1000 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Error: unable to open ftdi device: device not found Command handler execution failed Was mach ich da falsch ? Die .cfg dateien für JTAGKey2 sowie STM32 sind ja bereits bei OpenOCD vorhanden. Auch gemäss Anleitung von OpenOCD sollte es doch funktionieren (openocd -f jtagkey2.cfg -f stm32.cfg) Gruss Yello8247 PS: oder muss ich da noch in den .cfg files änderungen vornehmen ?
> Error: unable to open ftdi device: device not found > Command handler execution failed > > Was mach ich da falsch ? Die .cfg dateien für JTAGKey2 sowie STM32 > sind ja bereits bei OpenOCD vorhanden. OpenOCD muss für den passenden Treiber kompiliert sein. Überprüft? Vgl. auch Beiträge weiter oben im Thread, STM32-Artikel und http://www.freddiechopin.info/index.php/en Eintrag vom Tuesday, 23 February 2010 18:46
Martin Thomas schrieb: > OpenOCD muss für den passenden Treiber kompiliert sein. Hmmm ?????????? kompiliert ??????? Da blick ich nun devinitiv nicht durch ! Ich benutze Windows und kein Linux. Ich dachte da muss ich eh schon eine kompilierte Version für Windows herunterladen ? Bei Linux gibt es die Binary-Versionen. Oder hab ich da was kommplett übersehen ? Gruss Yello8247
Martin Thomas schrieb: > Vgl. > auch Beiträge weiter oben im Thread, STM32-Artikel Hallo Martin Hier steht aber dass die Windows Version schon kompiliert ist !! * OpenOCD: Kompilierte Version für Windows: http://www.freddiechopin.info/ >> Download >> Software >> OpenOCD installieren nach "C:\WinARM\OpenOCD_0_4_0" ist auch auf der Seite Yagarto.de beschrieben. Was meinst Du ?? Gruss Yello8247
Ich kann auch nicht kompilieren. Warum man das sollte verstehe ich auch nicht. Denn mit Crossworks geht das ganze doch, ohne neu kompilieren! Somit: Es müssen irgend welche andere Kommandozeilenpparameter sein / bzw. in den Dateien steht was anderes drin.
Martin Thomas schrieb: > OpenOCD muss für den passenden Treiber kompiliert sein. Überprüft? Hallo Martin So langsam habe ich folgende Befürchtung: Auf der Yagarto Homepage kann man folgendes lesen: An OpenOCD installer based on libftdi can be found at the page from Freddie Chopin. Genau auf dieser homepage habe ich den OpenOCD Installer für Windows heruntergeladen.(Ist ja auch der einzig verfügbare !!!) Kann nun sein, dass diese OpenOCD Version nur mit libftdi läuft und somit meinen JTAGKey2 von Amontec nicht unterstützt ! Ich musste ja für Crossworks auch die neuesten Treiber von Amontec (Die leider nur in Foren zu finden sind) runterladen. Vielleicht hast Du recht das leider diese compilierte Version nicht mit meinen Treibern läuft ! Scheisse. (Wobei seltsamerweise ist ja eine JTAGKey2.cfg Datei vorhanden?) Crossworks hat natürlich versteckt einen selbst compilierten OpenOCD. Gruss Yello8247
Ich glaube nicht, dass Crossworks OpenOCD benutzt. Die haben ihren eigenen Debugger und eine Schnittstelle für FTDI-basierte JTAG-Adapter: http://www.rowley.co.uk/documentation/arm_1_7/index.htm?http://www.rowley.co.uk/documentation/arm_1_7/arm_ft2232_target_interface.htm Mit deiner Befürchtung hast du recht, das hat Martin auch mit "OpenOCD muss für den passenden Treiber kompiliert sein" gemeint.
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.