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
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
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
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.
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.
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
voidSystemInit()
3
{
4
5
}
6
7
intmain()
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?
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 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
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
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
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.
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
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
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
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.
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
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
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
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
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
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. :-)
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.
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
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.
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
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
Flo G. schrieb:> Mit deiner Befürchtung hast du recht, das hat Martin auch mit "OpenOCD> muss für den passenden Treiber kompiliert sein" gemeint.
Na dann, muss ich wohl zähneknirschend mein Vorhaben begraben !!!
1. Linux lässt sich nicht auf meinem Rechner installieren !!
(Damit hätte ich die chance eine compilierte version für JTAGKey2 zu
generieren)
2. Einen J-Link werde ich mir nicht extra dazukaufen, nur um die OpenOCD
für Windows zum laufen zu bringen.
Schade aber nun kann ich mich voll auf Crossworks konzentrieren.
Gruss
Yello8247
PS: jetzt ist mir auch klar warum das Tutorial auf der YAGARTO-Homepage
für einen Segger J-Link (Eigener GDB-Server) geschrieben ist.
Da gibts die wenigsten Probleme !! Alle ander können sich die
Zähne ausbeissen !!! Super
yello8247 schrieb:> PS: oder muss ich da noch in den .cfg files änderungen vornehmen ?
Hi Yello,
ich kann die zu OpenOCD leider keine weiteren konkreten Tips geben, da
ich den nach erfolgreicher Installation vor langer Zeit dann doch nicht
weiter nutzen wollte. Aktuelle Versionen kenne ich nicht. Ich habe mir
den JLink gekauft. Der tut es ohne großen Aufwand. Einfach so :-)
Thomas hat sich ja schon eingeklingt. Der wird dir sehr viel mehr dazu
sagen können.
Halten wir fest:
Geht nicht mit Eclipse/OpenOCD/Yagarto:
- Amontec JTAG Key
Geht:
- Olimex ARM-USB-OCD, nur mit Treiber von OpenOCD
- Segger J-Link mit GDB Server von Segger
Flo G schrieb:> Man kann OpenOCD mit dem FTDI-Treiber auch unter Windows kompilieren:>> http://www.openpilot.org/OpenOCD_Compile_on_x86 oder> http://www.openpilot.org/OpenOCD_Compile_on_x64
Hallo Zusammen ich will noch nicht aufgeben und habe mir mal den Cygwin
heruntergeladen und installiert.
Nun bin ich ein bisschen unsicher wie weiter ?
Gemäss Tutorial openpilot:
INF Files
The driver from the FTDI site has the USB identifiers set for the FTDI
devices and not those from Olimex, so that these drives are recognised
as the correct drivers for the Olimex devices you need to change a
couple of areas in the .inf files. If you wish you can download the
already changed versions of the INF files here, these should work with
any version of the drivers from FTDI. There are also two two more of the
files in this archive, these will not be used.
Diese Aenderungen der .inf files betreffen ja wiederum den Olimex
und nicht den JTAGKey2 !
Oder geht es hier nur um den Treiber für Windows den ich ja eh von
Amontec schon installiert habe (Mit .inf files von Amontec) ?
kann ich somit diesen Punkt edit INF Files überspringen, und
direkt mit Build OpenOCD weiterfahren ?
Gruss
Yello8247 (Roger)
Ja genau, den Schritt brauchst du dann nicht.
Versuch mal OpenOCD zu kompilieren (die aktuelle stabile Version 0.4,
nicht die aus der Anleitung).
Grüsse
Flo
Flo G. schrieb:> Versuch mal OpenOCD zu kompilieren (die aktuelle stabile Version 0.4,> nicht die aus der Anleitung).
Hab ich schon versucht hat aber nicht Funktioniert !
Absolute Funkstille.
Bin dann auf diesen Link gestossen.
(Etwas aktueller beschrieben)
http://piconomic.co.za/fwlib/index.html
Aber auch da bekomme ich folgende Fehlermeldung:
configure: error: unrecognized option: -mno-cygwin
Siehe auch PDF-Anhang
Gruss
Yello8247
Flo G schrieb:> Sind das wirklich Anführungszeichen auf dem Screenshot?
Scheisse !! Natürlich nicht !
Danke für den Hinweis.
Nun geht was. Ob es Funktioniert muss ich noch testen.
Ergebnisse folgen.
Auch Du hättest mindestens ein Bierchen verdient.
Aber warscheinlich wohnst Du auch wie Markus 1000km entfernt ?
Gruss
Yello8247
>Halten wir fest:>Geht nicht mit Eclipse/OpenOCD/Yagarto:>- Amontec JTAG Key
Woher kommt diese Information?
Da betr. OpenOCD und JTAGkey(2) scheinbar etwas Verwirrrung herrscht: Es
gibt im Grund zwei "Treiberfamilien" für die FTDI-ICs wie sie z.B. in
den JTAGkeys stecken.
(1) Treiber des Chipherstellers (FTDI). Hersteller von Adaptern auf
FT2232*-Basis wie z.B. Amontec oder Olimex nehmen diese Treiber, änderen
USB-VID, PID und einige Zeichenketten in der/den INF-Datei(en), lassen
(hoffentlich) von MS neu signieren und stellen das dann als Treiberpaket
bereit. Treiber sind closed source, daher darf OpenOCD, das unter GPL
Lizenz steht, nicht als Binärversion (="EXE" bei MS Windows) mit
integrierter Unterstützung für die FTDI-Treiber weitergegeben werden.
Man darf sich aber natürlich aus dem OpenOCD Quellcode eine Version mit
Herstellertreibersupport zusammenbauen. Das mache ich hier und daher
sind die Informationen im folgenden Punkt 2 nicht aus eigenen Versuchen.
(2) Treiber libusb(-w32) mit libftdi: Lizenz dieser Treiber ist
kompatibel zur Lizenz von OpenOCD und damit darf man Binärfassungen von
OpenOCD dafür weitergeben, wie es z.B. F. Chopin tut. Man bekommt also
die eine vorkompilierte Version, muss dann aber auch dafür sorgen, dass
libftdi/libusb-Win32 als Treiber für den JTAG-Adapter in der
Gerätesteuerung verwendet wird und nicht der von FTDI. Dann kann es aber
sein, dass andere Programme (z.B. Crossworks) nicht mehr mit dem Adapter
"sprechen" können, da diese den Herstellertreiber erwarten.
Abhilfe aus dieser Endanwenderunfreundlichkeit dürfte ein Open-Source
Filter schaffen, der zwischen OpenOCD und dem FTDI-Herstellertreiber
liegt. Dann kann der FTDI-Treiber installiert bleiben und auch eine
OpenOCD-Binärfassung dafür weitergeben werden. Sowas ist wenn richtig
erinnert auch Plan bei libftdi und/oder libusb, kenne aber den
allerneusten Stand nicht.
Hallo Zusammen
Nun das kompilieren des Openocd für ftd2xx Treiber hab ich nun
hingekriegt.
Doch nun habe ich andere Fehlermeldungen.
Mit Eclipse:
Open On-Chip Debugger 0.4.0 (2011-04-30-19:26)
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
Warn : Unable to open FTDI Device tried: 'Amontec JTAGkey' and 'Amontec
JTAGkey A'
Error: unable to open ftdi device: 2
Error: ListDevices: 2
Error: 0: "Amontec JTAGkey-2P A"
Error: 1: "Amontec JTAGkey-2P B"
Command handler execution failed
Ohne Eclipse Openocd mit cmd von Windows: gleiche Fehlermeldung
Gruss
Yello8247
mthomas schrieb:> (2) Treiber libusb(-w32) mit libftdi: Lizenz dieser Treiber ist> kompatibel zur Lizenz von OpenOCD und damit darf man Binärfassungen von> OpenOCD dafür weitergeben, wie es z.B. F. Chopin tut. Man bekommt also> die eine vorkompilierte Version, muss dann aber auch dafür sorgen, dass> libftdi/libusb-Win32 als Treiber für den JTAG-Adapter in der> Gerätesteuerung verwendet wird und nicht der von FTDI. Dann kann es aber> sein, dass andere Programme (z.B. Crossworks) nicht mehr mit dem Adapter> "sprechen" können, da diese den Herstellertreiber erwarten.
Klingt einleuchtend !
Ich werde dies gleich versuchen.
Danke Deiner Info
Gruss
Yello8247
Aus der Hüfte geschossen (Nach kurzem googeln): Versuch mal jtagkey2.cfg
statt jtagkey.cfg.
Eventuell könnte es auch Probleme geben wenn du beide Treiber
installiert hast (FT2xx und libftdi).
Grüsse
Flo
Flo G schrieb:> Aus der Hüfte geschossen (Nach kurzem googeln): Versuch mal jtagkey2.cfg> statt jtagkey.cfg.
Also eher umgekehrt ! ich habe bis jetzt immer mit jtagkey2.cfg versuche
gemacht.
Aber es geht auch mit jtagkey.cfg nicht !
Also ich denke die Sache ist Hoffnungslos.
Ich habe in der Zwischenzeit auch die Idee von mthomas
verfolgt.
Leider ohne Erfolg !
Sobald ich die treiber von OpenOCD installiert habe.
wird das ftdi device wieder nicht mehr erkannt !
Ich glaube es geht nur wenn man OpenOCD neu compiliert und zwar
mit den ftdi Treiber von Amontec ! Leider betreffen die Tutorials
nur das compilieren mit den Treibern libusb(-w32)/libftdi:
Diese aber können leider mein JTAGKey2 nicht erkennen.
Gruss
Yello8247
PS: Vielleicht findet sich ja noch ein Tutorial welche das compilieren
resp. die nötigen Anpassungen für JTAGkey2 beschreibt.
Es kann doch nicht sein das ich der einzige bin der diesen JTAG in
Verbindung mit OpenOCD verwenden will.
Ich habe mir, weil es vor ein paar Jahren auch nicht klappen wollte,
einen zweiten angeschafft.
Vielleicht musst Du auch in den sauren Apfel beißen und entweder einen
Olimex oder J-LINK EDU kaufen. Beide kosten etwa gleich viel, wobei der
J-Link nur privat verwendet werden darf und der Olimex einen
zusätzlichen COM-Port hat. (Ich habe beide und mit beiden gehts)
> Es kann doch nicht sein das ich der einzige bin der diesen JTAG in> Verbindung mit OpenOCD verwenden will.
Ist auch nicht so. Habe diesen JTAGkey2-Adapter und den Vorgänger auch
mit OpenOCD im Einsatz, allerdings, wie oben geschrieben, mit den
FTDI/Amontec-Treibern und selbstkompiliertem OpenOCD (das dank
Lizenzkettenrasseln und Drohung mit GNU-Rechtsabteilung in der
OpenOCD-dev-Mailingliste nicht mehr von mir zum Download bereitgestellt
wird).
@yello8247
Schreibe mir ein PN, ich denke ich kann weiterhelfen. MT hat mich gerade
auf eine Idee gebracht, aber Posten darf ich es aus GNU rechtlichen
Gründen nicht.
Martin Thomas schrieb:> Es sind nur zwei Konfigurationsoptionen zu ändern, um OpenOCD für> FTDI-Treiber zu bauen. Mein "Skript" für Cygwin+mingw-Toolchain:
Nun Blick ich nicht mehr durch !
Genau das habe ich ja durchgespielt mit dem Resultate:
Open On-Chip Debugger 0.4.0 (2011-04-30-19:26)
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
Warn : Unable to open FTDI Device tried: 'Amontec JTAGkey' and 'Amontec
JTAGkey A'
Error: unable to open ftdi device: 2
Error: ListDevices: 2
Error: 0: "Amontec JTAGkey-2P A"
Error: 1: "Amontec JTAGkey-2P B"
Command handler execution failed
Dann der hinweis von Dir:
Man bekommt also die eine vorkompilierte Version, muss dann aber auch
dafür sorgen, dass libftdi/libusb-Win32 als Treiber für den JTAG-Adapter
in der Gerätesteuerung verwendet wird und nicht der von FTDI.
Dies hat dann gar nicht Funktioniert (Ftdi device wird nicht erkannt)
!!!
Muss ich nun doch den in den Tutorials angegebenen zu modifizierenden
Treiber ($ unzip CDM20602.zip -d ftd2xx) installieren ?????
Im Forum SparkFun aussert sich Amontec auch nur dahingehen dass man den
neuesten Treiber von Amontec und zusätzlich noch Openocd für windows
kompilieren muss.
Trotz diesen Angaben hat es aber der Typ vom Forum auch nicht zum laufen
gebracht !! Danach war Funkstille.
Link:
http://forum.sparkfun.com/viewtopic.php?f=18&t=25328
Gruss
Yello8247
yello8247 schrieb:> Martin Thomas schrieb:>> Es sind nur zwei Konfigurationsoptionen zu ändern, um OpenOCD für>> FTDI-Treiber zu bauen. Mein "Skript" für Cygwin+mingw-Toolchain:>> Nun Blick ich nicht mehr durch !
Das heißt aber jetzt hoffentlich nicht, dass alles nochmal von vorne
losgeht.
> Genau das habe ich ja durchgespielt mit dem Resultate:> Open On-Chip Debugger 0.4.0 (2011-04-30-19:26)> 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> Warn : Unable to open FTDI Device tried: 'Amontec JTAGkey' and 'Amontec> JTAGkey A'
Mit welchen Parametern aufgerufen?
Für den JTAGkey2 sollte da stehen:
1
...
2
Warn : Unable to open FTDI Device tried: 'Amontec JTAGkey-2' and 'Amontec JTAGkey-2 A'
3
...
Hinweis von Flo G./20:51 betr. jtagkey2.cfg wirklich beachtet?
>> Error: unable to open ftdi device: 2> Error: ListDevices: 2>> Error: 0: "Amontec JTAGkey-2P A"> Error: 1: "Amontec JTAGkey-2P B"> Command handler execution failed
Scheinbar ein JTAGkey2P, dafür gibt es eine jtagkey2p.cfg (unterscheiden
sich nur im "descriptor string", habe den *P zwar auch hier, aber noch
nicht verwendet, bisher nur JTAGkey"1" und JTAGkey2 genutzt).
der Reihe nach:
- OpenOCD ist wie von mir oben beschrieben für die ftd2xx konfiguriert
und gebaut?
- Treiber von Amontec/FTDI ist installiert? Im Gerätemanager
nachgeschaut?
- Wie ist die Ausgabe nach folgendem Aufrufen?
> Dann der hinweis von Dir:> Man bekommt also die eine vorkompilierte Version, muss dann aber auch> dafür sorgen, dass libftdi/libusb-Win32 als Treiber für den JTAG-Adapter> in der Gerätesteuerung verwendet wird und nicht der von FTDI.>> Dies hat dann gar nicht Funktioniert (Ftdi device wird nicht erkannt)> !!!
Welche Parameter wurden configure beim Bau von OpenOCD mitgegeben? Im
Zweifel die Augabe von configure in einen Datei umleiten und diese an
eine Mitteilung hier anhängen.
> Muss ich nun doch den in den Tutorials angegebenen zu modifizierenden> Treiber ($ unzip CDM20602.zip -d ftd2xx) installieren ?????
Wenn OpenOCD mit --enable-ft2232_ftd2xx konfiguriert wurde, kann der
Treiber von Amontec installiert werden (ist bis auf PID und Strings in
der INF-Datei identisch mit dem Treiber von FTDI). Hiermit ist gemeint:
der Treiber für MS Windows, der dann in der Gerätesteuerung auch
angezeigt wird. Modifikation an den INF-Dateien ist nicht wirklich
erforderlich. Amontec-Treiber basiert zwar auf einer etwas älteren
Version des FTDI-Treibers, reicht aber. Verwende die hier wg.
WHQL-Signatur auch. Wenn es sein muss, kann man später dort noch eine
neue Baustelle einrichten.
Betr. "unzip": in dem zip-Archiv sind die Dateien zum Bau von OpenOCD
für ftd2xx enthalten (.h .lib), die lib-Datei enthält die
stub-Funktionen über die zur Laufzeit die Funktionen der ft2xx.dll
aufgerufen werden, die wiederum mit dem FTDI-Treiber "reden".
> Im Forum SparkFun aussert sich Amontec auch nur dahingehen dass man den> neuesten Treiber von Amontec und zusätzlich noch Openocd für windows> kompilieren muss.
Wenn, dann auch vollständig: Da steht 'OpenOCD für Windows _mit
ftd2xx-Support_' kompilieren.
> Trotz diesen Angaben hat es aber der Typ vom Forum auch nicht zum laufen> gebracht !!
Woraus wird das geschlossen?
>Danach war Funkstille.
Wahrscheinlich, weil keine Fragen mehr offen sind.
> Link:> http://forum.sparkfun.com/viewtopic.php?f=18&t=25328
Der darin angegeben Link
http://piconomic.co.za/fwlib/_b_u_i_l_d___o_p_e_n_o_c_d.html gibt doch
gute Information. Welche Fragen bleiben offen?
Martin Thomas schrieb:> Der darin angegeben Link> http://piconomic.co.za/fwlib/_b_u_i_l_d___o_p_e_n_o_c_d.html gibt doch> gute Information. Welche Fragen bleiben offen?
Tja genau nach diesm Link bin ich ja auch vorgegeangen (siehe oben im
Threat). Die parameter zum aufruf der ./configure entsprechen ja auch
genau
Deinen Angaben.
Es hat ja auch was verändert: Ich bekomme nicht mehr die Fehlermeldung
Ftdi device not found !!! Sondern eben wie oben beschrieben.
Betreffend .cfg File bin ich mir 100% sicher das ich jtagkey2.cfg
benutzt
habe (Kann man auch in einen meiner Threat mit PDF sehen)
Aber eine jtagkey2p.cfg habe ich nicht gefunden !
Im verzeichnis von OpenOCD stehen nur die Jtagkey.cfg Jtagkey2.cfg und
jtagkey-tiny.cfg Dateien.
Der unterschied P ist ja auch nur das dass JTAGKey2p mehr Strom liefern
kann als das JTAGkey2.
Gruss
Yello8247
Nachtrag: Sorry vom vielen ausprobieren hatte ich die falsche
Fehlermeldung
gepostet (für jtagkey.cfg) bei einstellung jtagkey2.cfg bekommme ich
folgende Fehlermeldung:
Open On-Chip Debugger 0.4.0 (2011-04-30-19:26)
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
Warn : Unable to open FTDI Device tried: 'Amontec JTAGkey-2' and
'Amontec JTAGkey-2 A'
Error: unable to open ftdi device: 2
Command handler execution failed
Gruss
Yello8247
yello8247 schrieb:>...>Aber eine jtagkey2p.cfg habe ich nicht gefunden !>Im verzeichnis von OpenOCD stehen nur die Jtagkey.cfg Jtagkey2.cfg und>jtagkey-tiny.cfg Dateien.
Es gibt eine jtagkey2p.cfg im OpenOCD-git.
>...> Der unterschied P ist ja auch nur das dass JTAGKey2p mehr Strom liefern> kann als das JTAGkey2.
(a) nicht "mehr", 2P bietet Möglichkeit zur Stromversorgung, 2ohneP
nicht
(b) nicht nur "der unterscheid", es gibt zumindest einen weiteren bei
der Device Descriptor Zeichenkette, die, wenn angegeben, auch von
OpenOCD bzw. ftd2xx.dll verwendet wird, vgl. Funktion
ft2232_init_ftd2xx, in src/jtag/drivers/ft2232.c. Problem ist mglw.
einfach die Abweichung zwischen Angabe in .cfg-Datei und Rückgabe aus
der Hardware. In einer Kopie von jtagkey2.cfg ein P an die
Descriptor-Zeichenkette anhängen und damit testen. Statt:
Martin Thomas schrieb:> In einer Kopie von jtagkey2.cfg ein P an die> Descriptor-Zeichenkette anhängen und damit testen
Hmm Sorry so langsam komme ich mir vor wie ein vollidiot !
Wie kann ich diese .cfg Datei editieren ?
Mit einem Text editor entsteht eine .txt Datei sobald ich speichere.
Bei Crossworks entsteht eine Datei
Und mit Eclipse öffnet es mir automatisch den .txt editor !!!!
Das .cfg file selber habe ich im netzt nicht gefunden.
Nur immer die Angaben was man editieren soll.
Sorry meiner doofen Grundlagenfragen.
Gruss
Yello8247
Martin Thomas schrieb:> einfach die Abweichung zwischen Angabe in .cfg-Datei und Rückgabe aus> der Hardware. In einer Kopie von jtagkey2.cfg ein P an die> Descriptor-Zeichenkette anhängen und damit testen. Statt:ft2232_device_desc
"Amontec JTAGkey-2"
> dies:ft2232_device_desc "Amontec JTAGkey-2P"
Hmm zum verrückt werden !!!
Jetzt bekomme ich folgende Fehlermeldung:
Open On-Chip Debugger 0.4.0 (2011-04-30-19:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Runtime error, file ".\prj\jtagkey2P.cfg", line 1:
invalid command name "#"
Gruss
Yello8247
>...>... invalid command name "#"
Wenn so etwas erscheint, schaut man sich die Datei nochmal genauer an,
im Zweifel mit einem hex-Viewer. Wahrscheinlich mit einem Texteditor
hantiert, der mit den Unix-Zeilenendungen nicht zurecht kommt.
Kopie jtagkey2p.cfg-Datei aus dem OpenOCD git im Anhang.
Martin Thomas schrieb:> Kopie jtagkey2p.cfg-Datei aus dem OpenOCD git im Anhang.
Vielen Dank für die Datei.
Hmmm Nun bekomme ich wieder die selbe Fehlermeldung wie mit der
jtagkey2.cfg Datei:
Open On-Chip Debugger 0.4.0 (2011-04-30-19:26)
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
Warn : Unable to open FTDI Device tried: 'Amontec JTAGkey-2P' and
'Amontec JTAGkey-2P A'
Error: unable to open ftdi device: 2
Command handler execution failed
Ich versuche mal OpenOCD neu zu kompilieren.
Vielleicht ist da was schief gelaufen ??
Gruss
Yello8247
Geil es klappt !!!!!!!!
Ich hatte noch die alten Treiber bei Windows installiert !
Open On-Chip Debugger 0.4.0 (2011-04-30-19:26)
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
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 556RX0PIA
Info : Description: Amontec JTAGkey-2P A
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b,
part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020,
part: 0x6414, ver: 0x0)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
Vielen Dank für Die Unterstützung.
Gruss
Yello8247
Martin Thomas schrieb:>>...>>... invalid command name "#"> Wenn so etwas erscheint, schaut man sich die Datei nochmal genauer an,> im Zweifel mit einem hex-Viewer. Wahrscheinlich mit einem Texteditor> hantiert, der mit den Unix-Zeilenendungen nicht zurecht kommt.
Fast. Das ist die UTF-8 Byte-Order Mark, von Editoren wie notepad
eingefügt, um anzuzeigen, dass es eine UTF-8 Datei ist. Die wird man los
z.B. durch bearbeiten mit Notepad++, da kann man unter "Format" dann
"UTF-8 ohne BOM" auswählen, und dann speichern.
NPP (Notepad ++) hätte ich auch empfohlen:
http://notepad-plus-plus.org/release/5.9
Das trägt sich in das Explorer-Menü ein und man kann mit Rechtsklick
jede Datei öffnen und Editieren.
Hallo Zusammen
Ich habe in der Zwischenzeit noch herausgefunden das es gar
nicht nötig gewesen wäre openocd neu zu kompilieren !!!
Das ganze läuft jetzt mit der richtigen .cfg Datei auch mit der .exe
von F. Chopin.
Gruss und guten Wochenstart
Yello8247
Hallo Zusammen
Im Moment blicke ich nicht mehr Durch !
In der Firma will die Sache noch nicht laufen.
Ich werde nochmals minutiös testen mit welcher openocd.exe
das jtagkey2p.cfg funktioniert.
Gruss
Yello8247
Hallo Markus
Ich habe festgestellt, dass bei Deinem aktuelles Projekt
(BlinkLED) beim Aufstarten von Eclipse keine Projekteinstellungen
mehr vorhanden sind (Eclipse bleibt leer) !
Was hat sich da geändert.
Bei Deiner ersten Version die Du ins Forum stelltest war dies nicht so !
Gruss
Yello8247
Ich habe diese Batch-Datei ausgeführt, die alle temporären Dateien
löscht, damit wurde das ZIP um einiges kleiner.
Kannst du ein Screenshot machen wie das aussieht?
Markus Müller schrieb:> Ich habe diese Batch-Datei ausgeführt, die alle temporären Dateien> löscht, damit wurde das ZIP um einiges kleiner.> Kannst du ein Screenshot machen wie das aussieht?
Hier das Screenshot
PS:Wenn ich das alte Projekt öffne ist das Projekt sowie auch die
Einstellung vorhanden.
Gruss
Yello8247
Markus Müller schrieb:> @yello8247: Kannst Du das in den Link hochladen?
Ich werde es versuchen, nachdem ich es getestet habe.
Auch die entsprechende Openocd für JTAG2P werde ich Dir noch
bereitstellen.
Gruss
Yello8247
Hallo !
Kurze Zwischenfrage zum Cortex M3...
Ich habe wie etwas weiter oben beschrieben das Olimex-Board und den
Jlink-EDU Adapter.
Gibt es die Möglichkeit auch Trockenschwimm-Übungen d.h. quasi
Simulator-mäßig ohne(!) angeschloßener Hardware Programme zu debuggen ?
Gruß Uli
Hallo Zusammen
Ich habe es endlich geschafft !!
Das Demo-Projekt von Markus läuft nun einwandfrei mit dem JTAGKey2P
-Adapter und OpenOCD 0.4.0 (Neu Compiliert)
Unter Eclipse kann ich nun auch den Code Debuggen.
Allerdings erst nachdem ich realisiert hatte das man
die CDT-Master 7.0.2 von YAGARTO unter Eclipse noch intallieren muss !!
(GDB Hardware Debugging usw.)
Aufgefallen ist mir noch folgendes:
Unter der Anleitung YAGARTO wird beim C/C++ Build -Settings der
GNU Elf Parser aktiviert und nicht wie im Demo-Projekt den Elf Parser.
Welchen Unterschied haben diese Einstellungen ?
Vielen Herzlichen Dank für die Unterstützung aller.
Nun kommt noch die Knochenarbeit sich in die Umgebung von Eclipse
einzuarbeiten. Diese scheint mir mit der enormen einstellvielfallt nicht
so intuitive und einfach wie zum Bsp. bei Keil zu sein.
Gruss
Yello8247
Hallo,
habe nun auch einen Teil des Wochenendes damit verbracht Eclipse zum
laufen zu bringen. Leider stecke ich nun schon seit Stunden fest und
vielleicht kann mir ja einer von euch den entscheidenden Tipp geben.
Als Adapter kommt ein J-Link zum einsatz.
Folgende Schritte habe ich abgearbeitet:
+ Installation: Java Runtime
+ Installation: Eclipse IDE for C/C++ Developers, 87 MB nach
C:/WinARM/Eclipse
http://www.eclipse.org/downloads/
+ Installation: CodeSourcery nach C:/WinARM/CodeSourcery ...
http://www.codesourcery.com/sgpp/lite/arm/portal/package8737/public/arm-none-eabi/arm-2011.03-42-arm-none-eabi.exe
+ Installation: Segger J-Link Software
+ Installation: GNU ARM Plugin for Eclipse
http://sourceforge.net/projects/gnuarmeclipse/
über Eclipse -> Help -> Install New Software
+ Installation: GDB Hardware Debugging
http://www.eclipse.org/cdt/downloads.php
über Eclipse -> Help -> Install New Software wie auf dem ersten Bild von
http://deneb.homedns.org/things/?p=113 zu sehen.
+ Download des Beispielprojekts hier aus dem Thread. Das Beispielprojekt
aus dem Artikel (
http://www.mikrocontroller.net/articles/STM32_Eclipse_Installation )
konnte ich mit Eclipse hingegen nicht öffnen.
============================================
Nun der Status:
1. Eclipse an sich läuft, das Beispielprojekt kann geöffnet werden.
2. Der Segger J-Link GDB Server kann von Eclipse aus geöffnet werden.
Eine Verbindung mit dem Target kann hergestellt werden. Über die
arm-none-eabi-gdb.exe von Codesourcery kann ich mittels Kommandozeile
auf den GDB Server zugreifen (
http://www.punctr.com/joomla/index.php?option=com_content&view=article&id=22:gdb-pur&catid=5:stm32-einstieg&Itemid=31
)
3. Das Projekt lässt sich nicht kompilieren. Das liegt vermutlich daran
dass er cs-make nicht kennt und wie in der Anleitung beschrieben ein
gmake erwartet.
Ich habe kurzerhand in den Projekteinstellungen gmake in cs-make
umbenannt mit dem Ergebnis dass nun eine andere Fehlermeldung auftritt
mit der ich allerdings auch nicht mehr anfangen kann. Auch wenn ich in
den Projekteinstellungen cs-make mit vollständigem Pfad angebe
Hier hänge ich nun schon seit einiger Zeit und weiß nicht wo ich noch
rumschrauben soll. Hat von euch einer eine Idee was hier falsch laufen
könnte bzw. was ich übersehen haben könnte?
Hallo,
erstell doch mal selber ein Projekt in Eclipse und wähle dabei G++ als
Kompiler aus. Dann eine Datei erstellen, und zwar so in dieser Art:
Beitrag "Re: STM32 Eclipse Entwicklungsumgebung"
Zudem musst Du noch wie hier beschrieben:
Beitrag "Re: STM32 Eclipse Entwicklungsumgebung"
Das Linker Skript angeben und den Startup Code reinkopieren.
Falls ich mal dazu komme mache ich dazu ein Tutorial mit screenshots.
Viele Grüße
Daniel
Anbei das aktuelle Demo-Projekt.
Mit dabei ist ein zweites OpenOCD, kompiliert für FTDI-Treiber.
In dem Demo sind die Parameter für Segger J-Link, Olimex ARM-USB-OCD und
Amontec Jtagkey.
Die passenden DLL's für die FTDI-Version sind nicht im ZIP. USB Treiber
auch nicht.
Hat jemand einen Tipp wie ich einen Jtag von NGXtechnologies einbinden
kann? Ich bin gerade im external tools und müsste jetzt wohl etwas
installieren und dann dort die Verknüpfungen eingeben.
Der Adapter basiert ebenfalls auf einem FTDIChip IC, IDs und
Initialisierung dafür sind aber im aktuellen git von OpenOCD soweit
gesehen nicht enthalten.
Mit etwas C-Kenntnissen kann man die Initialisierung anderer Adpater als
Vorlage nehmen und selbst erweitern (Datei ft2232.c im OpenOCD
Quellcode). Erforderliche Daten finden sich in der Dokumentation im
Abschnitt Crossworks-Konfiguration und im Schaltplan. Evtl. ist die
GPIO-Belegung kompatibel zu einem anderen Adapter, dann kann man mittels
OpenOCD-Anweisung ft2232_vid_pid die IDs "unterschieben" und per
ft2232_layout verschiedene GPIO-Layouts durchprobieren.
Danke, ich guck mir coocox mal an. Als ich das erste mal von Eclipse mit
Open OCD gehört habe hatte ich irgenwie nicht verstanden, dass man sich
alles selbst schreiben muss. o.O Es muss doch ein Tutorial geben wie und
wo man die Daten dafür bekommt bzw. was man wie schreiben muss und
warum. So dass man es in einer endlichen Zeit hinbekommt ein Programm zu
schreiben.
Naja da ich erstmal zu potte kommen möchte werde ich mir wohl doch den
olimex Jtag bestellen. Hat jemand einen Plan ob es einen Unterschied
gibt zwischen dem "ARM-USB-OCD" und dem "ARM-USB-OCD-H" außer dem
geringen Spannungsunterschied und was der Unterschied sein soll? Bzw.
vielleicht kennt auch jemand einen schnellen Händer dafür?
Ich werd verrückt !!!!!!!
Hab heute die coocox IDE ausprobiert und oh Wunder
Funktionierte auf anhieb wunderbar sogar mit dem JTAGKey 2
!!!!!!!!!!!!!!
Es geht also doch !!!!!
Ein einziges Install-file runterladen installieren und fertig !!
Gruss
Yello
Hallo Yello !
Auch ich hab mir das Teil mal angesehen und ich muss wirklich sagen, das
ist wirklich gut. Scheint irgendwie eine auf ARM basierende
Eclipse-Umgebung zu sein. Was ich als Anfänger sehr gut finde ist das
Repository mit dem man sich einen vordefinierten Code anzeigen/erzeugen
lassen kann. Das macht den Einstieg etwas einfacher.
Ich weiß jetzt nur noch nicht ob ich auch mit der CooCox-IDE meinen
J-Link-EDU anbinden kann. Das wäre aber nicht so schlimm, denn im
Augenblick sind trocken-schwimm-Übungen angesagt und da wäre es schön
wenn man einen internen Debugger/Simulator anschmeissen könnte ohne
gleich das Target anschließen zu müssen.
Aber sieht soweit gut aus !
Gruß Uli
Hallo !
Ich hab doch gestern Abend noch ein paar Fragen gehabt. Da hatte ich
noch die IDE 1.2.4 und da ging der J-Link EDU noch nicht. Als ich heute
mir die Seite anschaute stellte ich fest dass es schon die 1.2.5 gibt
und siehe da - auch der J-Link funktioniert jetzt.
CooCox ist bis jetzt das beste was ich gesehen habe !
Gruß Uli
Uli B. schrieb:> Hallo !>> Ich hab doch gestern Abend noch ein paar Fragen gehabt. Da hatte ich> noch die IDE 1.2.4 und da ging der J-Link EDU noch nicht. Als ich heute> mir die Seite anschaute stellte ich fest dass es schon die 1.2.5 gibt> und siehe da - auch der J-Link funktioniert jetzt.> CooCox ist bis jetzt das beste was ich gesehen habe !>> Gruß Uli
Moin,
Ich habe mirgerade mal die Seite angeschaut und war positiv überrascht.
Freie Eclipse IDE mit integriertem RTOS und vielem mehr, ich bin
begeistert.
Werds mal ausprobieren, Danke für den Tip.
MfG
Tec
Mit der neuen CoIDE Version funktioniert nun auch ST-Link und somit
Debuggen auf dem preiswerten STM32 Discovery Board.
(Mittels ST-LINK_gdbserver.exe aus der Atollic Lite
Entwicklungsumgebung)
Über eine Batchdatei konnte ich den Zugriff auf das JFlash Tool
auf ST-LINK_CLI.exe umleiten, und so funktioniert auch das Flashen/Erase
über das Menü.
Allerdings hat CoIDE scheinbar Probleme mit Leerzeichen in Pfadnamen
beim Aufruf externer Programme. Unter Windows 7 wird aber alles nach
"C:\Program Files" installiert.
Unter Windows 7 sollte man daher CoIDE am besten gleich nach C:\CooCox
installieren.
Den Inhalt der Batchdatei und die Einstellungen hab ich mal angehängt.
Eine leere Datei config.jflash muss man noch anlegen, sonst meckert die
IDE.
@echo off
if "%4"=="-auto" goto flash
if "%4"=="-erasechip" goto erase
goto error
:flash
set file=%2
c:\ST-LINK\ST-LINK_CLI.exe -c SWD -P %file:~5,-1%" %3
goto end
:erase
c:\ST-LINK\ST-LINK_CLI.exe -c SWD -ME
goto end
:error
echo flasher.bat : Error, no valid command found !
:end
Mal ne Frage: ich habe CooCox 1.25 mit einem J-Link laufen, und das
funktioniert sowiet auch. Zumindest kann ich debuggen
Wenn ich aber das Programm nur flashe, dann wird es nicht automatisch
gestartet. Ich muss immer erst auf Debuggen gehen und dort das Programm
manuell starten.
Ziehe ich den JTAG Stecker ab und mache mein Board einmal stromlos, dann
läuft das Programm von alleine los.
Gibt es ne möglichkeit, das mein Programm nach dem Flashen automatisch
gestartet wird? Jedesmal den Debugmodus anwerfen ist bischen
umständlich. Evtl. wird da von der JTAG Schnittstelle die Resetleitung
gesetzt oder so...ich weiss es nicht genau. Aber evtl. hat jemand das
Problem ja schon gelöst?
achso...die JTAG Verbindung ist etwas...nunja...wacklig. Manchmal bricht
ohne erkennbaren Grund die Verbindugn ab usw.
Ich weiss aber nicht, inwiefern das evtl auch an meinem JLink Clone
liegt
Ich schätze den J-Link haben Sie kurz vor Veröffentlichung des
letzten Release noch schnell eingebaut. Das Tab "Download" in der
Config ist dort (noch ?) leer. Bei den anderen Programmern kannst du da
auswählen dass vor dem debuggen ein Download durchgeführt wird, und das
debuggen startet danach dann auch sofort.
Zumindest ist das bei meinem Signalyzer Lite so (CoLink als Programmer
ausgewählt).
WOW....ich habe dank
Beitrag "Re: STM32 Eclipse Entwicklungsumgebung" es
endlich geschafft, ein hex File zu erzeugen!! Nach soviel EclipseFrust
und Flucherei freu ich mir gerade ein zweites Loch in den Ar...
Ich habe aber noch ein Problem, was ich in
Beitrag "Re: STM32 + Eclipse -> Hilfe" schon beschrieben
habe. Woran könnte es liegen, das ganze nicht für ein C++ Project
funktioniert? Da fehlt bei mir der GCC Linker Eintrag. Oder muss ich ein
C Projekt erstellen und alles manuell auf die C++ Tools umstellen?
Und ich habe das LinkerScript einfach aus dem oben erwähnten Beitrag
entnommen. Wenn ich C++ benutze, hat das darauf Auswirkungen? Ich sehe
da Einträge wie Stack&Heapsize um die ich bisher noch nie kümmern
musste. Gibt es da eine verständliche Erklärung, was in dem Linkerscript
überhaupt passiert? Ich versteh da momentan ehrlich gesagt nur Bahnhof
> Gibt es da eine verständliche Erklärung, was in dem Linkerscript> überhaupt passiert? Ich versteh da momentan ehrlich gesagt nur Bahnhof
Linkerscripts sehen sehr kryptisch aus wenn man nicht weiss was das
alles bedeutet.
Wenn man weiss was ein compiler macht und eine Idee ueber die Struktur
der Hardware hat ist's wie ein Groschenheft.
hier mal ein Anfang zum lesen
http://www.delorie.com/gnu/docs/binutils/ld_6.html
Ju
danek für den Link...werde mich da mal durchwühlen.
habe heuet wieder zeit mit eclipse verbracht. nochmal ein neues projekt
mit der sourcery c++ toolchain angelegt, und siehe da...aufeinmal habe
ich da auch den linker eintrag bei den project optionen.
jetzt gehts aber weiter...jetzt geht es los mit fehlenden syscalls und
fehlenden impelementierungen von delete usw.
ich habe nur gesehen das die syscalls mit der "newlib" zusammenhängen
und wohl mehr für printf usw benötigt werden(was ich nicht brauche)
habe dann bei der projekt konfiguation eingestellt, das er mir das nicht
dazu linken soll, und dann verschwinden diese fehlermeldung auch.
aber bei dem destruktor einer klasse kommt dann die besagte delete
fehlermeldung.
werd mich morgen weiter damit beschäftigen. denn auch wenn ich bischen
zuversichtlicher bin, das ganez noch mit c++ ans laufen zu bekommen, so
macht sich eine mischung von gefährlichem halbwissen + und er wusste
nicht was er da tut bei mir breit
> ... so> macht sich eine mischung von gefährlichem halbwissen + und er wusste> nicht was er da tut bei mir breit
So ging es mir auch.
Irgendwie gab es immer eine fertigte Toolchain mit Makefile Templates
und Linkerscripten und irgendwelchen anderen Programmen oder Scripts im
Hintergrund die es einem Programmierer leicht gemacht haben schnell mal
eben irgendwas fuer irgendeine Arch zu compilieren.
Bis dann der Punkt erreicht war wo es nichts vorgefertigtes mehr gab.
Da kam das boese erwachen und ich bekam den Eindruck ueberhaupt nichts
ueber C-Programmierung zu wissen.
Kilometerlange Manuals haben dann Licht in das Dunkel gebracht und das
1/2-Wissen in 3/4-Wissen verwandelt, die Praxis macht dann den Rest.
Da fuehrt kein Weg dran vorbei und es ist ein Genuss wenn man die volle
Kontrolle hat.
Ju
Hallo,
ich habe mir inzwischen mehrfach alles durchgelesen und stehe vor dem
gleichen Problem, wie es hier beschrieben wird:
Beitrag "Re: STM32 Eclipse Entwicklungsumgebung"
Ich habe mir auch schon wie vorgeschlagen selber ein Projekt erstellt,
nur scheint es mir, als würde Eclipse mein cs-make überhaupt nicht
aufrufen. Ändere ich das cs-make in make oder gmake ab in den
Projekteinstellungen, so kommt als Fehlermeldung auch, dass es jeweils
nicht in PATH enthalten ist - also scheint Eclipse cs-make über PATH
doch zu finden, sonst wäre die Fehlermeldung ja eine andere.
Für Tipps bin ich dankbar, ich stehe gerade ziemlich auf dem Schlauch.
Hallo Christoph,
bei mir hat geholfen, die datei gmake.exe aus dem bin - verzeichnis von
codesourcery zu duplzieren und die Kopie dann make.exe zu nennen.
Gruß Thilo
P.S.
ich habe außerdem zusätzlich Yagarto installiert. Hier sind einige Tools
drin, die in codesourcery nicht richtig funtionieren. (z.B. rm.exe)
Siehe hier:
http://forum.chibios.org/phpbb/viewtopic.php?f=2&t=225
Gruß Thilo
Thread beobachten
Seitenaufteilung abschalten