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

Artikel STM32
oder
http://www.yagarto.de/

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.

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

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

OK, stimmt.

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}).

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=112...

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

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

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:

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:

STM32F10x_StdPeriph_Lib_V3.4.0/Project/STM32F10x_StdPeriph_Template/TrueSTUDIO/STM3210B-EVAL/

Wenn man das Script öffnet steht ziemlich weit oben folgendes:

Abstract    : Linker script for STM32F103VB Device with
**                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...

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

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.

Wieso soll er jetzt Eclipse weg werfen, wenn alles geht???

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

>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)

Den funktionierenden Download-Link für OpenOCD habe ich hier 
geschrieben:
http://www.mikrocontroller.net/articles/STM32#Inst...

Ich selbst habe auch lange danach gesucht, aber der klappt nun seit 
einem Jahr.

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.

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

@Simon Huwyler (simi)
Diese OpenOCD-Version ist eine URALT Version und sollte nicht 
verwendet werden!

Hier:
http://www.mikrocontroller.net/articles/STM32#Inst...
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 (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 :-)

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.

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

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.

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

Wenn jemand Zeit hat, dann testen.

@yello8247:
Hier ist auch beschrieben wie man auf das Amontec JTAG Interface 
umstellen könnte.

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.

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.

Ja, macht Sinn, wegen der einfacheren Sicherung und Test von Updates, da 
auch in das Eclipse diverse PlugIn's mit installiert werden.

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 

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.

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.

Hallo !

O.K. zu Olimex und LCD... 
[[http://shop.embedded-projects.net/index.php?module...]]

@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

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.

Hier der Vergleich, diesmal J-Link und der Segger GDB-Server.

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.

ado

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.

int main(void)
{
  // Init system and clock
  Sys_Init(); // Dieser Aufruf MUSS zu Anfang stehen!
  Clk_Init(); // Erst danach hat die CPU die richtige Geschwindigkeit

  // Benutzerdefinierte INIts
    IO_InitApp();
    Timer_TaskInit();

  while(1)
  {
    Timer_Task();

    GPIO_WriteBit(GPIOC, GPIO_Pin_12, tBlink); // Port C.12 blinken 
    // Auf PC12 ist die LED beim Olimex-Board
  }
  return 0;
}

void IO_InitApp(void)
{
  SAVE_PC();

  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC , ENABLE);

    GPIO_InitTypeDef GPIO_InitSt;

  GPIO_InitSt.GPIO_Pin =  GPIO_Pin_0;  // Ausgang PA0
  GPIO_ResetBits(GPIOA, GPIO_InitSt.GPIO_Pin);
  GPIO_InitSt.GPIO_Mode = GPIO_Mode_Out_PP;
  GPIO_InitSt.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_Init(GPIOA, &GPIO_InitSt);

GPIO_Pin_13;  // Ausgang Port D

  GPIO_InitSt.GPIO_Pin =  GPIO_Pin_12;  // Ausgang Port C
  GPIO_ResetBits(GPIOC, GPIO_InitSt.GPIO_Pin);
  GPIO_Init(GPIOC, &GPIO_InitSt);
}

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:

void IO_InitApp(void)
{
  SAVE_PC(); // Für Debug-Zwecke

  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC , ENABLE); // Enable von Clock für den Port C (sonst geht nichts)

  GPIO_InitTypeDef GPIO_InitSt;
  GPIO_InitSt.GPIO_Pin =  GPIO_Pin_12;  // Pin 12
  GPIO_ResetBits(GPIOC, GPIO_InitSt.GPIO_Pin); // PortPins vorinitialisieren
  GPIO_InitSt.GPIO_Mode = GPIO_Mode_Out_PP; // Portdefinition
  GPIO_InitSt.GPIO_Speed = GPIO_Speed_50MHz; // Geschwindigkeit
  GPIO_Init(GPIOC, &GPIO_InitSt); // PortC mit Portdefinition initialisieren
}

Der Segger GDB-Server ist auch an?
(Run External Tools)

Ich habe die 4. installiert und kenne die anderen nicht.
Dazu das CDT Plugin, so wie in Yagarto beschrieben.

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.

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)

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.

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.

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.

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

SRC += src/timer_task.c

stehen hast und die Datei in Wirklichkeit

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.

Ja.

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

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.

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.

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

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.

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.

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.

> 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

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.