Author
|
Topic: Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen (Read 10267 times)
|
|
DK2JD
Neuling
 Offline
Posts: 33
mcHF hat ein sehr gutes Konzept!
|
 |
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #60 on: 01. October 2015, 16:16:39 »
|
|
@DF4KD
Hallo Hans,
vielen Dank für Deine schnelle Hilfe.
Bei dem Plugin war ich mir nicht mehr sicher, aber es ist installiert.
O.K. Java ist inzwischen bei 1.8.0_60
Das mit dem Git muss man etwas probieren.
Nach 2 Fehlern war der Link dann richtig.
Ich bekomme vom Eclipse jetzt 18 Fehler und eine Warning angezeigt.
Alle sehr ähnlich und alle in main.c:
Description   Resource   Path   Location   Type
Symbol 'uint16_t' could not be resolved   main.c   /mchf-eclipse   line 776   Semantic Error
Symbol 'uint16_t' could not be resolved   main.c   /mchf-eclipse   line 778   Semantic Error
Type 'EXTI_Line0' could not be resolved   main.c   /mchf-eclipse   line 594   Semantic Error
Type 'EXTI_Line0' could not be resolved   main.c   /mchf-eclipse   line 613   Semantic Error
Type 'EXTI_Line1' could not be resolved   main.c   /mchf-eclipse   line 627   Semantic Error
Type 'EXTI_Line1' could not be resolved   main.c   /mchf-eclipse   line 636   Semantic Error
usw.
Sind die Fehler bekannt oder muss ich da noch etwas tun?
vy73 Werner.
|
| « Last Edit: 01. October 2015, 16:22:29 by DK2JD » |
 Logged
|
PC: ACER Predator G3620. 12GB, HD7890
STM32F4 Discovery, Eclipse Mars
DK2JD P24
|
|
|
DF4KD
schon länger dabei
Offline
Posts: 55
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #61 on: 01. October 2015, 17:29:14 »
|
|
@DK2JD
Hallo Werner,
mein letzter Versuch war mit Andreas' 219.23 Version. Möglicherweise hat Andreas seitdem am Makefile geschraubt. Ich hatte mit 219.23 vom 16.Sep keine Fehlermeldungen, nur 16 Warnings (ähnlich wie siehe weiter oben) die bei einer Aufräumaktion eigentlich wegzubekommen sein sollten.
Versuch mal, falls nicht gesetzt:
Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros, etc. -> Providers -> CDT GCC built-in compiler settings Cross ARM, deaktiviere "Use global provider shared between projects"
und add in Command to get compiler specs: ${COMMAND} ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD "${INPUTS}"
Ansonsten weiß vielleicht einer der SW Spezialisten was da los ist.
73, Hans
|
|
Logged
|
|
|
|
DK2JD
Neuling
Offline
Posts: 33
mcHF hat ein sehr gutes Konzept!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #62 on: 02. October 2015, 06:50:22 »
|
|
@DF4KD
Hallo Hans,
ich glaub da fehlt noch eine Installation. Ich bekomme folgende Fehler:
"Program "make" not found in PATH"
Ich habe GNU Tools auf dem Rechner, die z.B. Atmel auch benutzt.
Die habe ich in den "Path" aufgenommen und getestet. Aber die Fehlermeldung kommt noch immer.
Aber Groß- und Kleinschreibung ist doch unter Windows normal kein Problem!?
Meine Commands sind wie folgt:
${COMMAND} ${cross_toolchain_flags} ${FLAGS} -c ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
Wo finde ich die Definitionen für z.B. FLAGS und OUTPUT_FLAGS ?
Es ist schon ein paar Jahre her, dass ich mit Eclipse gearbeitet habe, aber langsam kommen die Erinnerungen wieder.
Nachtrag: Jetzt habe ich den Builder auf "Internal Builder" umgestellt und jetzt läuft der Build,
aber mit den ursprünglichen 18 Fehlern, wie oben beschrieben.
73 Werner.
|
| « Last Edit: 02. October 2015, 08:09:37 by DK2JD » |
Logged
|
PC: ACER Predator G3620. 12GB, HD7890
STM32F4 Discovery, Eclipse Mars
DK2JD P24
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #63 on: 02. October 2015, 07:40:19 »
|
|
Ich fürchte, dass wenn Ihr die Software mit gnuarm und eclipse-git herunter ladet, dann wird es auch über die eclipse internen Strukturen gebaut. D.h. Eclipse sucht sich die Dateien selber zusammen und compiliert die dann irgendwie.
Wenn Ihr das makefile verwenden wollt, müsst ihr das umstellen. Oder ihr checkt das git auf der Kommandzeile aus, in ein Verzeichnis, und importiert dieses dann als "Bestehendes Makefile" Projekt in Eclipse.
Eclipse erkennt dann trotzdem, dass da ein git im Hintergrund ist, und zeigt Euch geänderte Dateien.
Der Vorteil dieser Makefile Struktur wäre, dass man seine Toolchain wo auch immer hin installieren kann, man muss sie nur in dem Makefile eintragen. Das habe ich im Branch wip/cleanup auch schon mal so angeändert, dass man den Pfad einfach als
CROSS_COMPILE=/pfad/zu/gcc/bin/arm-none-eabihf-
engeben kann (der letzte - muss da hin, damit im makefile dann ein gcc, as, ld, size... angehangen werden kann)
Mit "make CROSS_COMPILE=/pfad/zu/gcc/bin/arm-none-eabihf-" kann man dann bauen. Das gilt für Windows und Linux User.
Linuxer könne auch vorher einfach export CROSS_COMPILE=... machen und können make einfach so aufrufen. Bei Windows weiß ich nicht wie das geht. Ist zu lange her.
73!
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #64 on: 02. October 2015, 08:26:56 »
|
|
Hallo,
auch wenn ich vielleicht trivial bin:
'make' ist Bestandteil jeder Linux-Distri. Das ist NICHT Bestandteil der gcc-toolchain.
Wer das Ganze als 'Makefile-Projekt' unter Windows übersetzen will, braucht daher zusätzlich zur toolchain
z.B. 'csmake.exe' aus der MINGW-Kollektion (SourceForge).
Das muss natürlich per PATH gefunden werden können, also in jedem cmd-Fenster testhalber aufrufbar sein.
Die Fehlermeldung, dass uint16_t nicht definiert ist, lässt schließen, dass gcc die Standard-Includes
(sys/_types.h in stddef.h) nicht includiert.
vy 73,
Harald
|
| « Last Edit: 02. October 2015, 08:36:41 by hbtron » |
Logged
|
|
|
|
DF4KD
schon länger dabei
Offline
Posts: 55
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #65 on: 02. October 2015, 08:42:43 »
|
|
Ja wenn alles so einfach wäre....
Ich denke das da irgend ein Einstellung nicht passt. Es heißt zwar das man verschieden Eclipse Version parallel haben darf, aber vieleicht ist da ja doch der Hund begraben. ich hatte vorher eine ältere Version zu Androidentwicklung drauf. Die habe ich auch immer noch. "Mars" hatte ich einfach neu installiert, wo wie oben beschrieben und vom Git die Daten holen lassen. Das hat auf Anhieb gepasst. Eben nochmal nach eventuellen Änderung suche lassen und dann clean und build. Ging mit 16 Warnings:
"__packed" redefined usb_conf.h /mchf-eclipse/usb line 81 C/C++ Problem
assignment discards 'volatile' qualifier from pointer target type audio_driver.c /mchf-eclipse/drivers/audio line 567 C/C++ Problem
assignment discards 'volatile' qualifier from pointer target type audio_driver.c /mchf-eclipse/drivers/audio line 574 C/C++ Problem
conflicting types for 'USBH_OTG_BSP_TimeInit' usbh_bsp.c /mchf-eclipse/drivers/keyboard/usb line 362 C/C++ Problem
implicit declaration of function 'USBH_OTG_BSP_TimeInit' [-Wimplicit-function-declaration] usbh_bsp.c /mchf-eclipse/drivers/keyboard/usb line 257 C/C++ Problem
passing argument 2 of 'memcmp' discards 'volatile' qualifier from pointer target type ui_si570.c /mchf-eclipse/drivers/ui/oscillator line 74 C/C++ Problem
passing argument 2 of 'VCP_fops.pIf_Ctrl' from incompatible pointer type usbd_cdc_core.c /mchf-eclipse/usb/usbd/class/cdc/src line 547 C/C++ Problem
passing argument 3 of 'arm_mean_f32' discards 'volatile' qualifier from pointer target type audio_driver.c /mchf-eclipse/drivers/audio line 1068 C/C++ Problem
passing argument 3 of 'mchf_hw_i2c_ReadRegister' discards 'volatile' qualifier from pointer target type ui_si570.c /mchf-eclipse/drivers/ui/oscillator line 280 C/C++ Problem
passing argument 3 of 'mchf_hw_i2c_WriteBlock' discards 'volatile' qualifier from pointer target type ui_si570.c /mchf-eclipse/drivers/ui/oscillator line 105 C/C++ Problem
passing argument 3 of 'mchf_hw_i2c_WriteBlock' discards 'volatile' qualifier from pointer target type ui_si570.c /mchf-eclipse/drivers/ui/oscillator line 156 C/C++ Problem
Unused declaration of variable 'demod_mode' codec.c /mchf-eclipse/drivers/audio/codec line 25 Code Analysis Problem
Unused declaration of variable 'errno' syscalls.c /mchf-eclipse/syscalls line 12 Code Analysis Problem
Unused declaration of variable 'test_a' audio_driver.c /mchf-eclipse/drivers/audio line 65 Code Analysis Problem
Unused declaration of variable 'test_c' audio_driver.c /mchf-eclipse/drivers/audio line 94 Code Analysis Problem
Unused static function 'wd_reset' main.c /mchf-eclipse line 906 Code Analysis Problem
und mit 7 Infos:
expected 'const void *' but argument is of type 'volatile uchar *' mchf-eclipse line 22, external location: c:\program files (x86)\gnu tools arm embedded\4.9 2015q2\arm-none-eabi\include\string.h C/C++ Problem
expected 'float32_t *' but argument is of type 'volatile float *' arm_math.h /mchf-eclipse/cmsis line 6148 C/C++ Problem
expected 'uchar *' but argument is of type 'volatile uchar *' mchf_hw_i2c.h /mchf-eclipse/hardware line 21 C/C++ Problem
expected 'uchar *' but argument is of type 'volatile uchar *' mchf_hw_i2c.h /mchf-eclipse/hardware line 22 C/C++ Problem
expected 'uint8_t *' but argument is of type 'uint16_t *' usbd_cdc_core.c /mchf-eclipse/usb/usbd/class/cdc/src line 547 C/C++ Problem
previous implicit declaration of 'USBH_OTG_BSP_TimeInit' was here usbh_bsp.c /mchf-eclipse/drivers/keyboard/usb line 257 C/C++ Problem
this is the location of the previous definition mchf-eclipse line 250, external location: c:\program files (x86)\gnu tools arm embedded\4.9 2015q2\arm-none-eabi\include\sys\cdefs.h C/C++ Problem
.
Übers Wochenende bin ich leider unterwegs. Wir können aber gerne mal unsere Einstellungen von Projekt vergleichen (am besten übers Tel, E-Link, SKYPE). Mich würde auch interessieren was da schief gelaufen ist.
73, Hans
|
|
Logged
|
|
|
|
DG3NEO
schon länger dabei
Offline
Posts: 96
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #66 on: 02. October 2015, 09:41:02 »
|
|
@ DK2JD, DF4KD
Ich verfolge euer Thema auch sehr interessiert.
Für die STM32-Entwicklung mit dem STM32F746-Discovery habe ich OpenSTM32 (http://www.openstm32.org/) under Windows7 (64) installiert, welches auch auf Eclipse aufsetzt. Nach dem Import mittels Git (Danke für den Tipp) bekomme ich auch erst mal 32 Errors angezeigt.
Eure Ergebnisse wären daher auch für mich nützlich und wichtig.
Danke!
vy 73
DG3NEO, Thomas
|
|
Logged
|
JN59MN
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #67 on: 02. October 2015, 10:07:56 »
|
|
Das ist allgemein ein Qualitätsproblem der Software...
Ich habe gerade angefangen den SI570 Treiber in etwas zu verwandeln, was man als Treiber bezeichnen kann und bin auch darüber gestolpert, dass die #includes bunt gewürfelt und unvollständig sind.
#include <stdint.h>
sollte das Problem mit uint32_t lösen. Aber uint32_t wird leider selten verwendet, stattdessen werden double long extra chilli genutzt...
Wenn Bei Euch mit dem Makefile die stdints nicht gefunden werden, dann habt Ihr nicht die Toolchain sondern nur den reinen Compiler installiert. Bitte noch mal nachbessern 
Ich nutze immer die Toolchains von Linaro und fahre damit sehr gut. In einem anderen Thread hatte ich auch schon auf Probleme hingewiesen, die entstehen können, wenn man einfach nur "irgendeine" Toolchain installiert. Daher rege ich noch mal an, ein wenig auf die Automatismen zu verzichten und stattdessen die Brötchen beim Becker und die Wurst beim Metzger zu kaufen.
Für den kompletten Bau des Systems braucht man die Linaro oder gnuarm Toolchain:
gcc-arm-none-eabi 4.9-2015.02 oder gcc-arm-none-eabi-4_9-2015q1
Die noch sehr weit verbreiteten 4.9-2014.11 oder 4_9-2014q4 haben einen Bug bei der Einbindung von vorkompilierten libs, wenn selbige nicht vorher auch mit exakt diesem Compiler gebaut wurden.
Und zu Mingw: Lasst es!
Installiert eine Basis-Version von cygwin und setzt einen Pfad auf C:\cygwin\bin oder c:\cygwin\usr\bin. Damit wäre das Makefile ohne Spezialbehandlung 1:1 zu den Linuxern kompatibel und die cygwin Linux-Tools (make, rm, mkdir...) sind 10x schneller als die mingw tools.
Wenn man die Toolchain + cygwin installiert, ist die Eclipse Version auch völlig Wurst, denn man greift auf die externen Tools zurück. Das klingt natürlich komplizierter, ist es im Endeffekt aber nicht, weil die ganzen Tools unabhängig für sich funktionieren. Man kann bei extern installiertem Linaro gcc und cygwin sogar das MS-Studio als Programmierumgebung nehmen, wenn man es mag.
Die Komplikationen, die hier beschrieben werden entstehen ja nur, weil Java zu Eclipse, Eclipse zu gnuarm, gnuarm zu libmath.a und so weiter kompatibel sein müssen...
Ich überlege gerade, ob es nicht Sinnvoller wäre eine kleine VM zu bauen, die alles mitbringt...
73!
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DF4KD
schon länger dabei
Offline
Posts: 55
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #68 on: 02. October 2015, 11:19:30 »
|
|
Obacht, ich spreche von Windows !!
Bei mir wurden nur die "GNU Tools for ARM Embedded Processors (arm-none-eabi-gcc)" installiert, und zwar hier "C:/Program Files (x86)/GNU Tools ARM Embedded/4.9 2015q2/bin".
Es wurde nix anderes installiert, schon gar keine extra toolchain. Sowiet ich sehen kann sind in den Project Properties auch keine Verweise irgendwo anders hin. Also muß in dem installierten Packet alles drin sein, sonst würde es bei mir, bis auf die Warnings, nicht laufen.
WO sich allerdings das "make.exe" (oder wie auch immer) versteckt habe ich bisher auch noch nicht finden können.
Vielleicht findet ja ein anderer Win User den Weg hierher.
Spezielle Installationen kommen bei mir nicht in Frage auch wenn ich gelegendlich, wegen Android und Raspi, mal mit Linux arbeite. Ich kenne Windows und weiß das man mit viel probieren hinterher nur noch den Tip bekommt das ganze System wieder neu aufzusetzen....Dann nehme ich lieber CooCox als separates Tool..
Angebot an Werner steht natürlich trotzdem. Wäre doch gelacht...
73, Hans
|
|
Logged
|
|
|
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #70 on: 02. October 2015, 14:17:33 »
|
|
Hallo Hans,
ich gebe Ulrich vollkommen recht, die GCC-Toolchain muss natürlich komplett sein (Executables, 2 Libs (libgcc und newlib) sowie alle Includes.
Schau doch mal in deinem GCC-Installationsverzeichnis, dort muss sich ausser dem Verzeichnis 'bin' mit den .exe noch arm-none-eabi/.. , lib/... und evtl. share/ (Letzteres ist unnötig) befinden. Wenn nicht, fehlt das Allermeiste.
Mit cygwin gebe ich Ulrich auch vollkommen recht, aber das ist auch nicht jedermanns Sache. Nein, auf keinen Fall MINGW installieren, ALLENFALLS csmake.exe - oder besser die cygwin-Tools (aber was von den gefühlten 500 Tools ??).
Wenn dein Eclipse kein 'make.exe' anmahnt, dann nimmt es an, dass es sich um ein 'gemanaged'-es Programm OHNE Makefile handelt. Dann stehen alle Optionen wieder in Eclipse (entweder global oder im Projekt). Dafür wäre die VM natürlich die beste Lösung, da dann alle Pfade gleich sind. In der VM müssten sich die User aber letztlich doch mit Linux anfreunden, da man ja zum Betreiben eines Winxx in einer VM auch eine Lizenz von Billie bräuchte.
Ich fürchte, ich habe mit meinen Makefile nur Unheil angerichtet - das war nicht beabsichtigt.
Ich bin kein Eclipse-Fan, aber ich habe es nach 2 Tagen Arbeit hinbekommen, mit openocd und mars ein paar Testzeilen auf einem Discovery-Board zu debuggen (mit Makefile). Gut, nicht sehr überzeugend, wenn man gewohnt ist, mit Lauterbach-Debuggern zu arbeiten - aber immerhin.
Am Rande für die Code-Puristen: ich habe unter http://stm32f4-discovery.com/ eine sehr schöne Sammlung von Beispielen zum STM32F407 gefunden, alles steht unter der Opensource-Lizenz und alles ist bestens dokumentiert - auch kein Durcheinander mit PLL-Einstellungen, Peripherie (USB mit beiden Ports gleichzeitig !!
das ist das, was Andreas gesucht hat). Alles ist dort mustergültig kommentiert. So stelle ich mir eigentlich Software vor.
vy 73
Harald, DL4SAI
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #71 on: 02. October 2015, 14:38:20 »
|
|
Ich bin kein "professioneller Programmierer". Ich habe viel mit C und C++ auf dem Atari ST gelernt, und viel danach im Mikrokontrollerbereich angewendet. Natürlich bekommt man auch ohne Ausbildung und Lehrer aus den angebotenen Beispielen ein Gefühl dafür, wie ein "ordentliches Programm" aussieht und wie nicht. Der Code bzw. die Struktur der Firmware ist wirklich kein guter Stil und sehr verwirrend und zusammengestückelt.
Da dieses Projekt nicht vom Start an bei uns lag (und auch nicht bei Clint - der hat die Basis von Chris übernommen) stehen wir alle jetzt vor einem "gewachsenen Komposthaufen". Damit will ich nichts schlechtmachen - die FW läuft ja! Nur ist die Art und Weise des Aufbaus eben nicht so, wie sie sein könnte und sein sollte.
Also muss man sich daran machen, Stück um Stück aufzuräumen.
Dabei muss vom Alten nichts wirklich zerstört werden - es wird "nur umgeräumt". Und dabei bekommen wir noch den Vorteil einer höheren Zukunftssicherheit.
Leider treffen auch hier mal wieder philosophische Welten aufeinander - zumindest machen Marketing/IT-Fachleute weiß, das es solche sind. Ich rede von den Diskussionen um Windows und Linux. Die objektiven eindeutigen Vorzüge der Freiheit geraten dabei unter die Räder - so wie sie es in unserem konsumorientierten Leben auch tun.
Wir als Funkamateure haben in der Vergangenheit oft selbst nachgedacht, selbst entschieden, selbst erforscht und selbst gebaut. Ich hoffe, dass das auch heute noch gilt...
Eine VM oder gar eine von USB-Stick bootende minimalistische Distri mit der man an der FW mit einer einheitlichen Umgebung arbeiten kann wäre schon was Feines. Mit einem 8GB-Stick hätte man das System, das alles zum Arbeiten beinhaltet, keine Festplatte benötigt und eine 1GB Partition auf der man seine Ergüsse speichern kann.
Damit müsste keiner sein vorhandenes System irgendwie verändern oder etwas neu installieren.
Aber es würde eine Umgewöhnung bedeuten - den Umgang mit etwas Neuem erforschen und lernen. Etwas, was im heutigen Zeitalter der Bequemlichkeit zunehmend unbeliebt wird.
Dumm ist nur:
Schon die Benutzung von git ist mit Lernen verbunden - da beißt die Maus keinen Faden ab. Und Billie wird einen Sch*** tun, dass das irgendwann mal mit "klick-und-gut" funktioniert. Um seine Kunden abhängig zu halten, darf man ihnen auf keinen Fall auch nur einen Millimeter Freiheit freiwillig anbieten
Also müsste man den Umgang mit git eigenständig erarbeiten und lernen. An diesem Punkt hakt gerade der bislang aktivste Firmwareentwickler des mchf. Und er hakte da schon länger. Nur war es bislang einfacher, die Stimmen und Rufe um git einfach zu ignorieren. Jetzt wird es interessant, weil der neue Bootloader etwas mitbringt, was im alten Paket nicht vorhanden war (und die Touchscreenfunktion habe ich auch schon in meinem lokalen Arbeitsbranch in der Mache). Offenbar rührt sich ohne Druck - woher der auch kommt und wie er auch aussieht - nichts. Die Bequemlichkeit bleibt Sieger. Nur wie lange noch 
vy 73
Andreas
|
| « Last Edit: 02. October 2015, 14:50:14 by DF8OE » |
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
DF4KD
schon länger dabei
Offline
Posts: 55
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #72 on: 02. October 2015, 15:22:30 »
|
|
Hallo Harald,
alle Ordner sind prallvoll. Die werden bei der Installation des GNU Tool ARM Embedded erzeugt. In den Projektproperties ist sogar eingetragen das make benutzt werden soll.
Und - bei mir geht es ja auch - hoffe ich, denn ich habe noch keine HW um das erzeugte Binäry auszuprobieren, hi.
-
-
-
Und ich gebe zu - ich habe etwas übersehen. Ich habe gerade nochmal meinen Rechner abgesucht und das/ein make.exe gefunden. Und zwar wurde es vor "Jahren" zusammen mit WINAVR installiert (man kann sich ja nicht an alles erinnern).
Nebenbei habe ich auch noch einen Link gefunden der sicher einigen weiterhilft...auch wenn Einigen mingw nicht gefällt.
http://hertaville.com/gcc-arm-toolchain-stm32f0discovery.html
73, Hans
|
|
Logged
|
|
|
|
DK2JD
Neuling
Offline
Posts: 33
mcHF hat ein sehr gutes Konzept!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #73 on: 03. October 2015, 13:49:09 »
|
|
@DF4KD, @all
Hallo Hans,
ich habe inzwischen Eclipse das 2. Mal neu aufgesetzt. 
Die erste Installation mit dem Installer hat mir nicht gepasst. Das Eclipse war über den ganzen Rechner verteilt.
C:\ ist bei mir ein SSD. Wenn ich nicht aufpasse läuft mir das über.
Die 1. Neuinstallation über ZIP hat am 2. Tag den Geist aufgegeben. Alle guten Dinge sind 3.
Ich habe jetzt den Tool Chain + Path, die Pfade, Preprozessor Includes und Build Commands eingestellt.
So viel muss man ja nicht mal bei Microsoft einstellen  .
Zwei Dinge bereiten mir noch Probleme:
1. Wie ist "Task Repository" einzustellen? Local oder Eclipse.org.
2. Woher kommt die Variable $(INPUTS)" im Build Command?
Beim Bauen ist diese Variable leer und ich erhalte folgenden Fehler:
Programm "" not found in PATH
Wozu brauchen wir die Build Commands wenn wir einen Makefile haben?
vy 73, Werner.
|
| « Last Edit: 04. October 2015, 08:02:49 by DK2JD » |
Logged
|
PC: ACER Predator G3620. 12GB, HD7890
STM32F4 Discovery, Eclipse Mars
DK2JD P24
|
|
|
DF4KD
schon länger dabei
Offline
Posts: 55
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #74 on: 05. October 2015, 11:16:18 »
|
|
@DK2JD
zu 1. Local
zu 2. Nach ich hoffe/denke aus dem Makefile, ich kann aber falsch liegen
Bei C/C++ Build->Settings->Tollchain mal nachschauen ob alles drin ist..
vy 73, Hans
|
|
Logged
|
|
|
|
|
|
|
