Title: Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 18. August 2015, 10:23:02
Hallo liebe Mitbauer,
gestern ist mir die Portierung der CooCox-Konfigurationen und der Firmware-Sourcen von Clint zur Benutzung mit Eclipse gelungen.
Die Firmware lässt sich nun unter Eclipse bauen (gibt es für Linux / Mac und Windows).
Ich hoffe, dass damit die Türen für eine grössere Zusammenarbeit vieler Programmierer an EINEM Sourcecode ganz weit offen stehen - denn Eclipse unterstützt github von Haus aus (mit einem Plugin namens egit - von eclipse.org).
Github Repository von DF8OE (https://github.com/df8oe/mchf-github)
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DC3AX on 24. August 2015, 21:38:17
Hallo,
habe mir gerade mal das repo geforked und gecloned. Importiert und gebaut. Scheinbar ist das ganze nicht kompatibel mit einem aktuellen Linaro 4.9.3 gcc. Die syscall.c steht der newlib im Weg, die math.a und libm.a sind mit incompatiblen Compiler-Schaltern gebaut worden.
Am Code gibt es, wie Du schon gesagt hast, ein paar Optimierungen. Ist zwar Möglich das ohne Hardware ins Blaue hinein zu Optimieren, aber fraglich, ob es auf dem Ziel dann läuft. Aber wir fangen ja gerade erst an. ich schau mal weiter herum.
Gruß
Ulrich |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DB6KT on 25. August 2015, 05:45:32
was für packete brauch ich denn für eclipse - nutze Arch - sind einige im AUR und auch im community mehrere vorhanden. Bitte mal hier listen.
Die Abhängigkeiten werden ja eigentlich beim bauen selbst aufgelöst (aber eigentlich macht auch den Satz kaputt - ;D )
73 de Tom |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DC3AX on 25. August 2015, 20:51:36
Bzgl. der Probleme mit dem gcc:
Es ist semi-optimal ein neues Projekt mit einem alten Compiler zu starten, zumal man ja auch auf eine der neuesten SOCs setzt. Gerade bei HF/VPU/NEON/SIMD... ist es wichtig die letzten Patches der Hersteller nicht ganz außen vor zu lassen. Außerdem ist die Code-Größe und die Ausführungsgeschwindigkeit je nach Alter des Compilers deutlich beeinträchtigt.
Der gcc-4.8 ist definitiv jung genug, aber die bereits gefundenen Probleme, dass der Code nicht läuft oder bei mir nicht einmal compiliert, liegen an einem Linker-Problem, vermutlich in einer Version 4.9.2 oder 4.9.3 aus q3 / q4 2014.
Wer also mit einem Linaro-4.9-2014.xx den Code bauen will, hat etwas Pech.
Ich habe heute einige Projekte, die mit dem 2014er Release nicht zu bauen waren, mit dem gnuarm 4.9-2015q1
https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q1-update getestet und es funktioniert sehr gut. Auch der mcHF lässt sich damit problemlos übersetzen.
Der Compiler ist unter dem Link einfach herunter zu laden, für alle Betriebssysteme. Linuxer entpacken die Datei einfach irgendwo, verschieben das komplette Verzeichnis dann als sudo nach /opt/.
in Eclipse dann Project->Properties dort C/C++ Build -> Tools Path und im Feld Toolchain folder:
/opt/gcc-arm-none-eabi-4_9-2015q1/bin eingeben.
Project Clean -> Build -> Fertig :)
Der Bug liegt vermutlich im Linker, der bestimmte Teile vorkompilierter Libraries nicht korrekt behandeln kann. Das fällt natürlich nur in Projekten auf, in denen solche vorhanden sind. Also nicht wundern, wenn man mit dem beschädigten linker seinen eigenen kleinen Projekte immer problemlos bauen konnte. Aus Zeitmangel habe ich noch nicht nach einem CVE tracker im gcc gesucht.
73
Ulrich |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 26. August 2015, 07:10:22
Hallo Ulrich,
auch ich vermute die Probleme im Linker. Die beiden Libraries, die beim mcHF unter "Libs" liegen, werden vermutlich nicht korrekt berücksichtigt.
Ich vertrete wie Du die Ansicht, dass sich hier mit einem moderneren Konzept noch einiges an Rechenpower sparen (und damit für andere Aufgaben wie digitale Betriebsarten) einsetzen lässt. Schon beim Betrachten der Audiobearbeitung sehe ich nur C - soweit das Auge reicht. Hier würden ein paar Zeilen Inline-Assembler vermurlich schon ware Wunder bewirken. Leider ist Clint davon nicht zu überzeugen - es müsste jemand "vormachen"... Clint redet von "optimierten Keil-Funktionen" - ich kann mit Diskussionen nicht das Gegenteil beweisen. Aber ich erninnere mich, dass eine einfache Schleife, die bis 1000 zählt, als C-Compilat Faktor 10 und höher langsamer war als das gleiche in Assembler, mit optimierter Wahl der jeweiligen Arbeitsregister...
Mir schwebt vor, die gesamte Firmware so schnell es geht auf den RTOS-Kernel, den es ja für den STM32F4 gibt, umzustellen, solange sie noch so "klein" ist wie jetzt. Dadurch würden das Taskscheduling sauberer funktionieren und man müsste bei Erweiterungen nicht immer an hundert anderen Stellen gleichzeitig drehen, damit etwas neues läuft.
Ein anderes Problem ist, dass ST Microelectronics die neueren Bibliotheken nicht mehr für "freie Software" verwendbar anbietet, so dass man hier wohl auf "Kommerz" ausweichen müsste, wenn man die nutzen will. Da wäre meine Priorität aber eindeutig auf der "Freiheit"...
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DC3AX on 26. August 2015, 07:51:23
Hi!
Also ich gehe aus der Erfahrung davon aus, dass die Nachteile bzgl. der Lesbarkeit von Assembler bei einem Open-Source Project die geringfügigen Vorteile der Geschwindigkeit bei weitem übertreffen. Der Vorteil von Assembler ist bei einem modernen gcc wirklich nicht mehr so hoch und die Cortex-M Kerne sind extra so konzipiert, dass kein Assembler mehr benötigt wird. Nicht einmal eine startup.s muss sein, sie existieren in vielen Toolchains einfach nur, weil die Entwickler den Code vom ARMv5 kopiert haben.
Auch Function-Header, Function-Init und Function-Exit Prozeduren wurden so optimiert, dass dort kein Overhead mehr entsteht.
Mit Keil haben die Optimierungen auch nur am Rande was zu tun, das ist in der Compiler-Branche ein ständiges Nehmen und Geben. Der gcc 4.9.1 baut für mein Cortex A9 Tablet einen 20% kleineren Kernel mit 10..15% Performance-Gewinn im Vergleich zu einem gcc 4.6.2
Ich habe damals bei der Portierung von NutOS auf STM32 auch viele Tests gemacht, in dem ich mir die vom gcc erzeugten lst Files angesehen habe. Da besteht kaum bis kein Optimierungspotential.
Natürlich führt schlechter C-Code zu einer gewissen Machtlosigkeit des Optimierers. So kann man im mcHF code statt mehreren separaten IIC Treibern einfach einen einzigen nehmen, der eine Datenstruktur mitführt, auf welchem Bus er arbeitet. Das halbiert den Code, da der Cortex Pointer liebt.
Ein echtes RTOS muss nicht sein, wenn man den DSP Teil sauber an einen Timer hängt. Ein passendes RTOS muss man sich sehr gut aussuchen, denn erstens sind die alle nicht ganz ohne und auch die Lizenzen sind da immer wieder in der Schwebe. NutOS ist unter BSD Lizenz, die CMSIS und der ST Kern ist aber bereits abgesegnet. Ich werfe dass dann mal ins Bewerber-Rennen (www.ethernut.de)
Das mit den "Nicht mehr für freie Software verfügbar" bräuchte ich mal als Link schwarz auf weiß, sollte es mit den Lizenzen von ST Probleme geben, kann ich mal telefonieren.
Gruß
Ulrich
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 30. August 2015, 02:53:07
Hallo Andreas,
das ganze Projekt schaut sehr interessant aus. Zum "Einstieg" habe ich mich mal versucht das ganze zu kompilieren. Dummerweise war mein Eclipse (Windows) auf einem gaaaanz alten Stand (Indigo). Hatte ich damals zur Androidentwicklung eingesetzt. Indigo lässt sich auch nicht mehr per auto upgrade/update auf einen neuen Stand bringen. Also, neuinstallation.
Und zwar so:
Mars installiert, gcc-arm-none-eabi-4_9-2015q2-20150609-win32 installiert, dein Projekt als zip runtergeladen und importiert.
Das ging alles soweit ohne Probleme.
Dann:
1. Project clean, dann build-all ODER build-project -> 3 Errors, 18 Warnings (siehe unten).
2. dann nochmal build-project und nur noch -> die gleichen 3 Errors, 2 Warnings (unten markiert mit <-> )
3. nächster Tag, neuer Start,
4. Project clean, dann build-all -> Errors sind weg, 18 Warnings (wie vorher)
5. nochmal build-all (ohne vorher clean) -> nur noch 2 Warnings (unten markiert mit <-> )
6. alles von vorne, -> 4 -> 5....
Any Idea? Compiler Schalter? Reihenfolge? Was mich stört ist das die Errors verschwunden sind, ohne zu sagen wohin. Sollte eigentlich mit deinen Ergebnissen in Übereinstimmung zu bringen sein sonst ist da immer etwas Ungewisses...
73, Hans
------------------------------
Description Resource Path Location Type
Errors (3 items)
Symbol 'NULL' could not be resolved usbd_cdc_core.c /mchf-eclipse/usb/usbd/class/cdc/src line 197 Semantic Error
Symbol 'NULL' could not be resolved usbd_cdc_core.c /mchf-eclipse/usb/usbd/class/cdc/src line 202 Semantic Error
Symbol 'NULL' could not be resolved usbd_cdc_core.c /mchf-eclipse/usb/usbd/class/cdc/src line 203 Semantic Error
Warnings (18 items)
"__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 572 C/C++ Problem
assignment discards 'volatile' qualifier from pointer target type audio_driver.c /mchf-eclipse/drivers/audio line 579 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 'Codec_Mute' [-Wimplicit-function-declaration] mchf_board.c /mchf-eclipse/hardware line 739 C/C++ Problem
implicit declaration of function 'EVAL_AUDIO_Mute' [-Wimplicit-function-declaration] usbd_audio_out_if.c /mchf-eclipse/usb/usbd/class/audio/src line 274 C/C++ Problem
implicit declaration of function 'memcmp' [-Wimplicit-function-declaration] ui_si570.c /mchf-eclipse/drivers/ui/oscillator line 74 C/C++ Problem
implicit declaration of function 'ui_si570_calc_startupfrequency' [-Wimplicit-function-declaration] mchf_board.c /mchf-eclipse/hardware line 808 C/C++ Problem
implicit declaration of function 'ui_si570_init_temp_sensor' [-Wimplicit-function-declaration] ui_menu.c /mchf-eclipse/drivers/ui line 1769 C/C++ Problem
implicit declaration of function 'UiDriverSaveEepromValuesPowerDown' [-Wimplicit-function-declaration] mchf_board.c /mchf-eclipse/hardware line 762 C/C++ Problem
implicit declaration of function 'USB_OTG_BSP_mDelay' [-Wimplicit-function-declaration] usb_core.c /mchf-eclipse/usb/otg/src line 1916 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
<-> No break at the end of case usbd_audio_out_if.c /mchf-eclipse/usb/usbd/class/audio/src line 203 Code Analysis 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 '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 static function 'mchf_board_watchdog_init' mchf_board.c /mchf-eclipse/hardware line 572 Code Analysis Problem
Infos (5 items)
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
------------------------------
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 30. August 2015, 07:40:12
Das muß an den Eigenschaften der Maschine "Windows" draunter liegen.
Unter anderem wegen solcher nicht nachvollziehbaren Setlsamkeiten, die man meistens nur durch viel Probiererei und selten zielgerichtet finden und beseitigen kann, habe ich die Windows-Welt vor über 15 Jahren verlassen - das muß ich mir nicht antun.
Das Zauberwort für jeden Windowsianer heittt ja bekanntlich "Neuinstallation" und der häufigste Tipp der Microsoft-Hotline lautet "Haben Sie es schon mal mit einer Neuinstallation versucht?"
Ich schlage daher mal ausgehend von dieser Tatsache vor:
1) Den Ordner mit dem Projekt komplett löschen und neu herunterladen / importieren.
oder, wenn das nichts ändert
2) Eclipse komplett lösche und neu installieren
oder, wenn's ganz dicke ist
3) Eclipse auf einem Rechner installieren, auf dem noch nie ein Eclipse war
Mehr fällt mir dazu leider nicht ein :-\
vy 73
Andreas
PS:
Diese Zeile
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
sieht mir so aus, als wenn hier eigenmächtig nahc "eigenen Definitionen" gesucht wurde und nicht die vorgegebenen benutzt wurden. Verbiete deinem Eclipse, wen er eine vorgegebene Definiition nicht mag, einfach ungefragt andere zu benutzen! Wenn Du so vorgegangen bist, wie ich es weiter oben beschrieben habe (also mit "import exisiterendes Projekt") dann sollten aber alle Schalterstellungen zu meinen identisch sein - es sei denn, wie Windows und die Linux Variante sind zueinander nicht 100% kompatibel... |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 30. August 2015, 10:25:01
Hmm, na ja, die letzte Lösung ist ja auch "das Letzte", und wird wohl nicht passieren.
Lösung 2 könnte ich ja mal versuchen, leuchtet aber nicht so richtig ein, was bei Windows ja auch nicht unbedingt sein muß.
Lösung 1 habe ich mal gemacht:
zuerst hatte ich ja das Zip File aus der git runtergeladen und zu Fuß kopiert/installiert.
Jetzt habe ich alles per Eclipse runterladen lassen und siehe da - etwas ist anders.
Clean->build-all-> 16 Warnings-> buils-all-> keine Meldungen
Ich spiele mal weiter rum . . . . .
73, Hans
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 30. August 2015, 10:33:06
16 Warnungen sind korrekt und kommen auch bei mir. Allerdings immer und immer wieder - reproduzierbar. Ich kann so oft "clean" machen wie ich will, es entstehen stets 16 Warnungen. Und das ist auch richtig so, denn der Quelltext wurde ja nicht verändert. Solange der nicht verändert wurde und die Bau-Umgebung auch nicht, darf die Anzahl der Warnungen oder gar Fehler nicht unterschiedlich sein.
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 30. August 2015, 10:36:49
| Ja, nach clean, und NUR nach clean, kommen die Warnings. Wenn man nach dem ersten build-all nochmals einen build-all startet (ohne vorher clean zu machen) sind alles Warnings weg.... |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 30. August 2015, 10:55:28
Ja logisch!
Eclipse prüft, was neu gebaut werden muß. Da sich die Quellen seit dem letzten build-all ja nicht verändert haben (keine einzige), muss ja nichts neu kompiliert werden (folglich entstehen keine Warnings). Und gelinkt werden muss auch nichts neu (weil ja alle Objektdateien unverändert sind). Also auch kein Linker-Arbeitsschritt, bei dem Warnings anfallen können.
Resultat (logischerweise): keine Warnings.
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 30. August 2015, 11:01:14
&$%& ja klar, schade, und ich dachte schon. Hoffen wir mal das sich einige der Warnungen nicht beim nächsten Compiler update in Fehler wandeln....
Schönen Sonntag noch, 73 Hans |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 30. August 2015, 11:42:41
Es sind wirklich reine "Warnungen". Wenn wir endlich eine echte gemeinsame Plattform haben, wo nicht alle meine Änderungen mit der nächsten Release von Clint wieder "weggeblasen" sind, werde ich alle Warnungen durch Änderungen der betreffenden Stellen eliminieren.
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 30. August 2015, 11:50:57
Würdest Du bei der Firmware-Weiterentwicklung mitmachen wollen?
vy 73
Andreas |
Title: Wer macht mit bei Firmware-Erweiterungen?
Post by: DF8OE on 31. August 2015, 07:36:27
Hallo liebe OMs,
nachdem der Bau der Firmware nun mit Eclipse und CoIDE möglich ist, möchte ich durchstarten, auch wenn es noch keine Zusammenführung mit den Änderungen von Clint gibt. Ich denke, dass (wie so oft) erst Tatsachen die Notwendigkeit einer gemeinsamen Github-Quelle aufzeigen werden...
Daher suche ich Mitstreiter, die an der Firmware mit bauen und evtl. einige Codeschnipsel beitragen können. Meine Idee für die erste Erweiterung ist die Aktivierung des Touchscreens. Dieser wird via SPI angebunden und ich würde es gut finden, wenn durch "Antippen" einer Stelle auf dem Spektrum / dem Wasserfall die Abstimmung dorthin springt - Feintuning kann man dann ja wieder mit dem Tuningknopf machen. Auch wäre es evtl denkbar, durch waagerechtes Streichen über Spektrum oder WF "stufenlos" über den überstrichenen Bereich abzustimmen...
Bitte meldet euch, wenn ihr Interesse habt!
Vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: dg0nf on 31. August 2015, 07:49:57
Moin Andreas!
Ich würde zwar rein theoretisch mitmachen, aber leider habe ich im Moment wieder mal ein Zeitproblem, so dass ich erstmal andere Prioritäten setzen musste. Sollte meine Zeit es wieder zulassen, bin ich dabei, wenn auch sicherlich nicht so extrem aktiv. Wenn es aber darum geht, mal irgendwas auszuprobieren, das geht eigentlich immer irgendwie.
73, Helge (DG0NF) |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 31. August 2015, 10:02:06
Das ist schon mal gut 8). Auch ich habe ein Zeitproblem, da der Lottogewinn mal wieder asugeblieben ist. Sprich: Ich muß meine Zeit auch in Dinge verteilen, die eigentlich nicht ganz so "wichtig" sind, aber Geld bringen...
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 31. August 2015, 12:27:53
Hallo Andreas,
grundsätzlich würde ich mitmachen. Allerdings muß ich mich erst wieder einarbeiten da ich schon seit einigen Jahren "raus" bin (sicher schon gemerkt bei meinen Eclipse Fragen). Auch habe ich noch keine HW. Die ist aber schon angepeilt wird aber noch ein paar Wochen dauern, wegen wichtiger Zeitplanung (Urlaub, hi).
Wir werden dann wahrscheinlich zu zweit (DK8SJ und ich) versuchen etwas beizutragen...
73, Hans (DF4KD)
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 01. September 2015, 20:03:05
Zunächst: dieses Projekt fasziniert ! Wer einmal den ui_driver.c quer gelesen hat, weiß, wieviel Arbeit
darin steckt. Hoffentlich geht Alles mit rechten Dingen zu: Ich hatte keine Lust bei Yahoo etwas
über mich preis zu geben um an die Quellen zu kommen, ich habe die Quellen aus dem GIT von Andreas geholt.
Auch Inbetriebnahme-Doku usw. muss man wohl bei Yahoo holen. Material ist für mich kein Problem, allerdings
wären die Leuiterplatten-Gerber-Daten für ein echtes Open-Source-Projekt auch interessant, aber das gehört in eine andere Rubrik.
Ich habe zwar nicht die Absicht, die Firmware zu ändern, aber ich wollte mich, bevor ich das
Projekt als Pseudo-Rentner in Angriff nehme, von der Qualität der Sourcen überzeugen.
Da ich aber kein Freund von GUI's bin (ich habe mich 1998 von OS/2 verabschiedet, seitdem
ist Linux das OS meiner Wahl und das hauptsächlich auf der Kommandozeile) habe ich mir die Mühe gemacht, ein Makefile zu schreiben.
Leider funktioniert es nicht:
Wenn -nostdlib gesetzt ist , beschwert sich ld über fehlendes memset() und _impure_ptr_ sowie
über fehlende Funktionen, die innerhalb der Projekt-lib/libm.a (Funktion sqrt()) aufgerufen werden.
Wenn -nostdlib weggelassen wird, hagelt es beim Linken Fehler, die die VFP-Register betreffen.
Die Version des gcc ist sicher nicht das Problem (ich habe 9.3q1 und 9.3q2 versucht), sicher auch nicht das
Windows oder Linux. Ich habe harte Pfade zum gcc im Makefile eingetragen. Schon beruflich muss
ich 4 GCC-Versionen auf meinem Arbeits-PC vorhalten, da bleibt mir kaum Anderes übrig.
Wenn Interesse besteht, stelle ich das Makefile gerne zur Verfügung (wohin posten ?) . Der Kompiliervorgang zeigt jedenfalls jede Menge Warnings, die hauptsächlich den Vergleich signed/unsigned betreffen. Auch fehlende Funktionsdeklarationen werden angezeigt - so etwas würde ich weder beruflich noch privat stehen lassen.
Im Gegensatz zu Eclipse kommen bei einem Makefile-Projekt nachvollziehbar immer die gleichen Warnungen bzw. Fehler.
Die fraglichen Linker/Compiler-Optionen sind:
CFLAGS = -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -ffunction-sections -fdata-sections -O3 -flto \
-DARM_MATH_CM4 -DSTM32F407VG -DSTM32F4XX -D__FPU_USED -D__FPU_PRESENT -DUSE_STDPERIPH_DRIVER -D__ASSEMBLY__ -c -W -Wall
LDFLAGS := -nostdlib
LIBS := -Llibs -larm_cortexM4lf_math -lm
Die Defines habe ich dem Eclipse firmware.coproj entnommen.
Hat jemand eine Idee ?
vy 73,
Harald, DL4SAI
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 02. September 2015, 06:26:13
Hallo Harald,
ich habe im Prinzip erst "an der Oberfläche" der Firmwaresourcen gekratzt - aus Zeitmangel. Ich arbeite seit 15 Jahren ausschliesslich unter "Linux". Vieles mache ich auf der Konsole - weil es dort wesentlich einfacher und schneller geht. Aber ich nutze auch die GUI - eben je nach Aufgabenstellung.
Das Problem dürfte im Linker liegen. Es war mir praktisch auf Anhieb gelungen, mit dem gcc die einzelnen Quellen zu kompilieren - aber der Linkvorgang (auch wegen der beiden externen Libs) schlug auf Anhieb fehl. Hier musste etwas Handarbeit folgen. Genauso dürfte das mit dem Erstellen des makefiles aussehen. Ich werde mir diese "Baustelle" aber nicht vornehmen ::)
Sicher wäre es ein Ziel, die Warnings zu eliminieren. Aber selbst darin liegt zumindest bei ein paar schon ganz schön viel Arbeit. Ich zögere im Moment mit der Investition von Zeit, da ich das nur tun würde, wenn es eine gemeinsame Basis gibt.
Zum Thema "Open-Source":
Chris hat eine "eigenwillige Lizenz" gewählt. So eine Mixtur aus "Frei" und "unfrei" (z.B. sind die Platinen-Gerbers nicht frei und auch der Sourcecode des Bootloaders nicht). Das ist halbherzig - aber da können wir nichts dran ändern. Fakt ist auf jeden Fall, dass so weite Teile, wo wir "richtig was ändern können", definitiv offfen sind und daher Änderungen realisiert werden können.
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 02. September 2015, 07:12:21
Hallo Andreas,
ok, dann werde ich mich mal auf die Suche machen, woher diese libarm_cortexM4lf_math.a
und libm.a im Verzeichnis lib stammen und ob ersichtlich ist, wie sie zustande gekommen ist.
Meistens stammt so etwas aus Beigaben zu einem Eval-Board von ST und ist dann bereits
in die Jahre gekommen...
vy 73.
Harald
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 02. September 2015, 07:58:34
Das ist bestimmt so eine "Leiche". In den Originalsources, die auch Clint mit "CoIDE" bearbeitet, sind noch viele andere Leichen. So auch zwei Bibliotheken, die bisher jedem FW-Update getrotzt haben aber niemals eingelinkt wurden. Auch waren einige C-Dateien zwar mit im Ordner - aber funktionslos. Haben nur "in der Luft schwebenden Code" erzeugt, der keine Verwendung hatte (und auch keinen Zukunftsbezug). Nach Entfernen dieser Kröpfe war die FW schon mal rund 50kb kleiner und auch schneller - warum auch immer. Ich würde es sehr gerne sehen, wenn hier aufgeräumt und geordnet werden würde...
Ich bin gerade dabei, die Unterschiede zwischen dem alten Display und dem neuen in Sachen "SPI-Belegung" herauszubekommen. Mit einer Ansteuerung auf SPI-Basis hätten wir auf einen Schlag jede Menge freier GPIOs, die man für andere Aufgaben dringend gebrauchen könnte. Leider ist der Code nur teilweise dokumentiert, und vieles ist "seltsam". So habe ich z.B. herausgefunden, dass sich die Pinbelegungen für die Signale SDI, SDO, CS und CLK für den SPI-Bus geändert haben. Wäre ja auch nicht weiter schlimm - einfach ein paar Pins umdefinieren und dann sollte das wiedr laufen. Um kompatibel zu bleiben, könnte man ja zunächst auf "alte Version", dann auch "neue Version" testen und wenn beides fehlschlägt parallel-Ansteuerung nutzen. Nur liegt im Quellcode LCD_SCK auf GPIO-B, und der ist überhaupt nicht zum Display hin verdrahtet. Also wird der Clock entweder gar nicht gebraucht, oder die Namensgebung stiftet Verwirrung, oder, oder oder ::)
Die frei werdenden GPIOS könnte man für die Nutzung der Tocuhfunktion verwenden (den vorhandenen SPI-Bus zum rf-Board nutzen plus eine Leitung für den Interrupt bei anliegenden TP-Daten). Da hier keine Riesenmengen an Daten anfallen, dürfte ein SPI-Bus für alle zukünftigen Devices zuzügl. TP-Funktion völlig ausreichen. Nur müsste man wie gesagt durch den COde soweit durchsteigen bzw. ein altes DP haben. Bevor ich hier stundenlang suche, würde ich einfach mal frech den SCK-Pin trennen und schauen, ob das DP immer noch läuft ;D Ich verwende unterschiedlichste Methoden für ein effektives Weiterkommen - auch sowas "stumpfes" gehört dazu. Nur habe ich kein altes DP :(
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 02. September 2015, 08:57:18
Hallo Andreas,
eigentlich sollte ich jetzt Geld verdienen, aber es lässt mir keine Ruhe.
zum Display bzw. Port-Problem:
Das Bild des Display bei hotmcu.com zeigt, dass man das Interface auf der
Display-Platine mit den 3 0-Ohm-Rs einstellen kann. Das bezieht sich auf die B-Variante.
Wenn 16-Bit gewählt ist, verstehe ich nicht, warum auf dem UI R30, R31 und R32 bestückt sein sollen.
Rein gefühlsmässig würde ich sagen, dass die Display-Ansteuerung über SPI ein zu großer Kompromiss in Bezug
auf die Update-Geschwindigkeit ist. Aber es würde nach Software-Änderung ja auch das 8-Bit-IF funktionieren.
SPI-FIFO und schneller SPI-CLK wären zwar eine Diskussion wert, aber dann während Runtime wohl ausschließlich
für das Display.
Mit 8-Bit-IF wären SPI mit ein paar CS + Interrupt für den Touch und anderes frei, wenn ich nichts übersehen habe.
Überhaupt fehlt wenigstens ein 'Options-Schieberegister' am SPI, das man im Anlauf in der FW auswerten
könnte, um kompatible Software zu alten Hardware-Konfigurationen schreiben zu können.
Ich weiß, hinterher ist man immer schlauer...
vy 73
Harald, DL4SAI
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 02. September 2015, 09:08:19
Ja Harald, so ist es...
Viele Dinge lassen sich ganz einfach durch I2C-GPIOs lösen, weil es einfach nicht auf Geschwindigkeit ankommt. Aber wir brauchen dringendst ein paar Beinchen für solche Signale wie IRQs - und die müssen direkt am STM sein. Evtl. wäre schon eine Änderung der Buttons der richtige Weg...
Von den 17 Buttons müssen drei so bleiben, wie sie sind, weil sie auch solche Dinge wie "In den Bootloadermodus wechseln" bewirken. Wären also 14 Buttons "übrig". Zur Zeit belegt ein Button einen Port ??? Mit einer Matrix 3x5 ließe sich die Menge der Ports immerhin auf 8 reduzieren, also 6 wichtige Ports gewonnen 8) Und die SW dafür wäre sehr einfach geschrieben.
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 02. September 2015, 15:01:22
Hallo Andreas,
wenn man alles für ein Redesign in Frage stellt, wäre vielleicht zu überlegen, für
die 14 Tasten einen PCA8575DB (im SSOP24, RM 0.65) zu spendieren.
Dieser hat einen Interrupt-Ausgang (on Input change), der kommt erst, wenn eine Taste
gedrückt oder losgelassen wird. Die Programmierung ist zwar nicht so trivial, spart aber jede Menge Ports.
Man könnte den PCA8575 am I2C des EEprom anschließen, damit die Ansteuerung des Si570 und
des Temp.-Sensors nicht geändert werden muss.
Mit schnellem SPI wäre ich vorsichtig, den bekommt man sicherlich im Empfänger zu hören.
Wenn man das in der jetzigen Hardware zum Laufen bringt, wäre es sicher richtig, das erst
mal zu testen. Der Touch hat wohl einen Interrupt-Ausgang, da könnte man eine (langsame) extra SPI
anwerfen, sobald 'getoucht' wird.
Bezüglich Bootloader: ich habe ganz übersehen, dass das Binary nicht an Adresse 0 gelinkt wird, sondern
ab 0x08010000 (deine .map).
Aber eigentlich müssen doch alle, die das Gerät bauen, für das erste 'Flashen' den eingebauten Bootloader über
USART1 oder 3 nutzen oder eine Hardware mit Single-Wire-Debug besitzen. Der Bootloader über USB-OTG als
Device ist doch reiner Luxus. Ich habe so etwas letztes Jahr für NXP Cortex-M3 gebaut (komerziell, absoluter
closed Source, mit Code-Read-Protection).
Aber Bevor ich hier dumme Fragen stelle, warte ich erst mal deinen 2. Artikel im FA ab.
vy 73,
Harald DL4SAI
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 02. September 2015, 15:13:43
Ja, den GPIO I2C kenne ich...
Ich werde das mit dem SPI und dem Display mal testen. Ich denke, das geht doch einfacher als zunächst angenommen. Es bewahrheitet sich mal wieder, dass man erst die Informationen sammeln sollte und dann loströten ;D
Schraube Deine Erwartungen an den zweiten Artikel nicht allzusehr in Detailinfos. Wären diese auch nur halbwegs vollständig, würden sie den Rahmen selbst eines Mega-Artikels bei Weitem sprengen. Deswegen habe ich mich ja auch zu einem Buch entschieden - da bestimme ich selbst den Platz.
Außerdem sind viele Dinge, die für Verbesserungen angedacht werden können, so komplex, dass sie den technischen Background vieler OMs ebenfalls übersteigen würden. Der artikel sollte auch in der zweiten Ausführung eine möglichst breite Zielgruppe von Lesern ansprechen 8)
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 04. September 2015, 13:56:15
Hallo Andreas,
ich habe herausgefunden, dass 'libarm_cortexM4lf_math.a' eine umbenannte 'arm_cortexM4lf_math.lib' ist.
Woher diese stammt (Fa Keil ??), ist mir nicht ganz klar.
Die libm.a im Verzeichnis libs besitzt die gleichen Funktionen, die die libm.a der gcc-toolchain mitbringt.
Die 'richtige' libm.a liegt wohl im Verzeichnis 'arm-none-eabi/lib/armv7e-m/fpu/libm.a' der Toolchain.
Das sollte man dem Linker irgendwie klar machen können (-L...)
Vielleicht kannst du wenigstens diese 'Krücke' entsorgen.
Ich bekomme aber beim Linken mit meinem Makefile noch 2 Fehler, die wirklich im Code liegen:
usb/otg/src/usb_core.o: In function `USB_OTG_ActiveRemoteWakeup':
usb_core.c:(.text.USB_OTG_ActiveRemoteWakeup+0x32): undefined reference to `USB_OTG_BSP_mDelay'
usb/usbd/class/audio/src/usbd_audio_out_if.o: In function `MuteCtl':
usbd_audio_out_if.c:(.text.MuteCtl+0x2): undefined reference to `EVAL_AUDIO_Mute'
collect2: error: ld returned 1 exit status
Beim ersten Fehler hat jemand das Macro umbenannt und den Kommentar noch stehen gelassen:
USBH_OTG_BSP_mDelay() gibt es in /drivers/keyboard/usb/usbh_bsp.c. Das müsste eclipse
eigentlich auch anmeckern.
Für das 2. Macro finde ich überhaupt keine Definition.
Kommt dir das irgendwie bekannt vor ?
vy 73,
Harald, DL4SAI
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DC3AX on 04. September 2015, 14:27:21
Hallo Andreas, hallo Harald,
vielleicht ist es wirklich am Besten, wenn wir uns zunächst auf die bestehende Hardware konzentrieren und abgesehen von den zwingend notwendigen Änderungen darauf verzichten, die Software und die Hardware gleichzeitig zu ändern. Schon garnicht in einem Thread in diesem Board.
Wie ich zuvor schon geschrieben habe, sind die Einstellungen von verschiedenen Eclipse Versionen unter verschiedenen Betriebssystemen und verschiedenen Add-Ons (x-gcc, y-gcc, bla-avr, blubb-stm) nicht übertragbar. Um das Ganze wirklich portierbar zu machen, ist ein Makefile das Einzige was funktioniert.
Ich würde gerne am Makefile mitarbeiten, daher wäre es schick, wenn man das schon mal irgendwie einchecken oder anderweitig herum reichen könnte. Ich würde allerdings ein normales Arbeiten auf github bevorzugen, wo jeder forken kann und man sich trotzdem gegenseitig die Änderungen oder Fortschritte zuschubsen kann.
Das lib-chaos ist sicherlich leicht zu beheben, das signed-unsigned und die anderen warnings wird man recht leicht los, wenn man das makefile mit den entsprechenden compiler-options so scharf schaltet, dass Warnings im Release Code mit Errors gleichgesetzt werden. Man kann sauberes Programmieren auch ein wenig erzwingen ;)
Nachtrag:
Ich hatte den USB-Loader immer für die Einfachste Option gehalten, weil man ohne Programmieren von Treibern auch dann die Firmware flashen kann, wenn man reiner Anwender ist. Extra noch einen Loader für die Serielle schreiben ist auch nicht die Lösung, da das wieder ein Serielles Kabel oder alte Rechner resp. Notebooks verlangt.
Mal schauen was da geht...
73!
Ulrich |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 05. September 2015, 06:46:59
Hallo Ulrich,
ich hatte die Portierung der Einstellungen auf meinem alten Eclipse Luna durchgeführt. Erst später habe ich dann bemerkt, dass es inzwischen "Mars" gibt.
Du schriebst, dass die Einstellungen schon bei kleinsten Änderungen nicht mehr passen.
Dann habe ich wohl grosses Glück gehabt oder der Zufall war auf meiner Seite - denn bei mir passten die in meinem github hinterlegten Einstellungen und Sourcen SOFORT auf Eclipse Mars ;)
Auch gelang es mir reproduzierbar, mit den Anweisungen aus dem vierten Post in diesem Thread Eclipse auf verschiedenen Umgebungen zu installieren und das Projekt erfolgreich zu bauen.
Dass man das Plugin gnuarm braucht (das gleich eine Reihe anderer Plugins nach sich zieht), ist ja logisch. Man will ja auch für einen Arm-Prozessor bauen...
Ein Makefile ist sicher eine gute Sache. Aber wenn man sich umblickt und einfach nur realisiert, wie viele Leute auf Linux und dort rein auf der Konsole arbeiten, wird das Feld schon recht dünn.
Eine große Community bekommt man aber nur hin, wenn man möglichst wenige (im Idealfall keinen) "aussperrt". Und da die meisten eben mit einer GUI-IDE arbeiten, ist Eclipse, da für alle Welten verfügbar, sicher eine gute Lösung.
Ich würde mich auch freuen, wenn wir zunächst gemeinsam an der Verifizierung arbeiten, ob man das Projekt z.B. auch mit Windows und Eclipse mit den Dateien aus meinem Guthub bauen kann. Aber erstens habe ich keinen Rechner mit Windows auf dem ich einfach mal probieren kann und zweitens hat auch mein Tag nur 24 Stunden Zeit und dummerweise muß ich einen recht erheblichen Tag davon sinnfreie Dinge tun (== Geld verdienen). Das Projekt ist also auf die konstruktive Mitarbeit vieler angewiesen!
Der erste Teil einer Arbeitsteilung wäre z.B., dass sich jemand bemüht, ein Makefile zu erstellen. Damit hätten wir wieder mehr potentielle "Mitbauer". "noch gesucht" probiert mal, ob er auf einem Windows Eclipse installieren kann und mit den Dateien von meinem Github das Projekt bauen kann. Ein weiterer "Unbekannt" tut das unter OS-X. Damit wären wir schon einen grossen Schritt weiter!
Ich habe mir mal die "Warnings" gestern genau angesehen. Zu etlichen gibt es bereits Bugreports auf Sourceforge beim gcc. Ich frage mich, wie man darauf kommst, dass diese "warnings" aufgrund unsauberer Programmierung entstanden sind. Noch vor Monaten waren es über 50 Warnings - da hat Clint mit seinem CoIDE die "echten Schnitzer" wohl schon grösstenteils gefunden und eliminiert.
Ich für meinen Teil vertrete die Ansicht, dass das Verhältnis für den Zeitaufwand zum Suchen der Ursache für eine solche Warning in einem gesunden Verhältnis zur blossen Tatsache, dass ich eine Zeile nun NICHT mehr sehe, stehen muß. Vorrangig ist doch, dass das gebaute Binary lauffähig ist - und das ist es.
Einige Warnings stammen auch daher, dass die verwendeten Libs Variablennamen benutzen, die "unüblich" und daher reserviert sind. Daher kommen einige "redefined..."
Wer meint, die Libs seihen zu verbessern: Kein Ding! Wir alle freuen uns, wenn es jemand geschafft hat, das auf anderen Libs aufzubauen. Spannend wäre dann noch, ob die FW dadurch Vorteile hätte wie:
- weniger CPU-Last
- schnellere Abarbeitung zeitkritischer Abläufe
- kürzerer Code
Wenn eines oder mehrere davon eintreten, wäre das ein grosser Fortschritt. Wenn nicht, war das ganze ABM.
Konkret werden Leute gesucht, die verifizieren, ob sie das Projekt auf "ihrem PC" mit Eclipse nun auch bauen können - und wenn nicht, sollte wir herausfinden, WARUM NICHT. Wenn die Lösung einfach ist, editiere ich einfach meinen Eintrag (4) und dann gelingt es vielleicht immer mehr?!
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 05. September 2015, 07:20:32
@Harald
Eclipse meckert in der Tat nicht. Der alte CoIDE auch nicht - aber der neue. Und in der Yahoo-NG habe ich irgendwann mal gelesen, dass man die Funktionsaufrufe, die "ins Leere" gehen, einfach auskommentieren soll (habe ich aber nicht getestet, da bei mir wie gesagt keine Fehler kommen).
Die libm.a, die bei mir passt, liegt in
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/
Ich frage mich nur, ob es sinnvoll ist, diese anstatt der im Projektordner vorhandenen zu benutzen. Hier kommt ins Spiel, dass je nachdem, auf welcher Plattform man den Eclipse benutzt, sich die Pfade zu den Libs ändern und eine Voreinstellung für alle nicht existiert. Deswegen bin ich dafür, die libm.a aus dem Projektordner libs/ weiterzubenutzen.
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 06. September 2015, 19:05:51
Hallo Andreas,
nachdem ich heute einmal nach deiner Anleitung eclipse mars installiert habe, und - nein, der
gcc-arm-none-eabi kommt nicht in den $PFAD! - die Einstellungen in Eclipse so zurecht
geschustert habe, dass sie wohl stimmen, habe ich mich mal an die Arbeit gemacht, die
Warnungen alle gerade zu biegen.
Beim Einrichten von Eclipse dürften ziemlich alle User Probleme bekommen, die mehrere gcc-Varianten vorhalten. Es sei denn, sie sind Eclipse-gurus. (Vögel und bugs verstecken sich in Bäumen !!)
Die meisten Warnings betreffen fehlende Funktions-Deklarationen im Kopf der C-Sourcen. Ohne diese kann kein C-Compiler der Welt irgendwelche Fehler finden. Auch der feine Unterschied zwischen void func(void) -> das hat keine Argumente, und void func() -> das kann beliebig viele Argumente haben, sollte beachtet werden.
Bei casts float -> int ist mir deine Anzeige der Startfrequenz über den Weg gelaufen:
(Beispiel 73.8 Mhz:)
int vorkomma = (int)roundf(os.fout); -> 74
int nachkomma = (int)roundf((os.fout-vorkomma)*10000); -> 73.8 - 74 -> -0.2 mal 10000...
war wahrscheinlich nicht das, was du wolltest (stimmt aber zufällig für die meisten Frequenzen in der Tabelle).
Ich hätte eher:
int vorkomma = (int) os.fout; /* sollte abschneiden, nicht runden */
int nachkomma = (int) ((float) (os.fout - vorkomma) * 10000); /* dito */
versucht. (Ich bin aber nicht sicher, und kann es aber nicht ausprobieren).
Aber an anderer Stelle geht angeblich der Vergleich zwischen floats schief:
./drivers/audio/audio_driver.c:
if((((ulong)fabs(ads.a_buffer[0])) * DSP_ZERO_DET_MULT_FACTOR) < DSP_OUTPUT_MINVAL)
fabs() ist garantiert falsch, das ergibt double, aber es gibt in der libm.a angeblich 'int isless(float x, float y)'. Wäre einen Versuch wert...
Aufgegeben habe ich aber dann an __packed (mehrfach definiert). Chaos hoch drei...
Meinen ersten Fehler, den ich mit meinem Makefile sehe, sehe ich in Eclipse auch. Ich weiß nicht,
woher USB_OTG_BSP_mDelay() kommen soll. Es gibt USBD_OTG_BSP_mDelay(), USBH_OTG_BSP_mDelay().
Ich gebe aber zu, dass ich auch nicht weiß , was die beiden USB-Anschlüsse in der mchf-Firmware können sollen,
deswegen will ich hier auch nicht herum-tröten.
Nach meinen Recherchen (AN2206 und alle anderen) ist USB im bootloader relevant, da
ja über den USB-Device-Anchluss der Bootloader und später (über Affengriff) wohl der USB-Mem-Stick am USB-Host für ein Update gelesen werden soll. Soweit habe ich das jedenfalls verstanden.
Dafür braucht man in mchf USB üebrhaupt nicht. Interessant wäre aber z.B, ein USB-Device-Port mit
CDC-ACM-Class, dann hätte man am PC ein Terminal für Digi-Betriebsarten...
Noch ein letztes Wort zu libm.a:
Das Verzeichnis in der Toolchain ab arm-none-eabi/ ist zwar die newlib, heißt aber seit mindesten 1998, als ich den ersten gcc selbst übersetzt habe, immer 'lib' und nicht 'newlib'. Das ist in allen Variante, die ich selbst übersetzt oder bei Code-Sourcerey oder Mentor geholt habe, immer 'lib' (Auch bei Hitachi-SH, m68k usw.).
Die richtige libm.a aus 2.9_q1 ergibt etwas kleinere Funktionen (habe ich in der map gesehen) als die
libm.a in libs/. Die Header hierfür werden sich wohl kaum ändern, aber es gibt sicherlich noch andere Gründe,
immer die libm.a der jeweiligem toolchain zu benutzen. Nachdem die FPU des Cortex-M4 ja schon
ein paar Jahre existiert, und diese von ARM ist, sollte das ja wohl zukünftig funktionieren.
Mein Makefile habe ich mal Ulrich geschickt, vielleicht fängt er etwas damit an. Nach Auskommentieren
der fehlerhaften Funktionen kommt ein Binary mit etwas kleinerer Größe heraus, als das von
dir erzeugte. Nur in der map in der Version aus dem deinem github stehen viele 'Discarded
input sections', und bei mir nicht. Warum, verstehe ich nicht.
Wie dem auch sei, ich gebe auf.
Vielleicht kaufe ich mir dein Buch - wenn auf dem Cover kein Eclipse abgebildet ist :-[
vy 73,
Harald Baumgart, DL4SAI
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 07. September 2015, 08:39:19
Hallo Harald,
ich werde in deisem Beirg öfter "springen" - weil es sehr viele Baustellen und Inos gibt, die hier wichtig sind.
Die fehlenden Deklarationen sind leicht zu beheben - da die Funktionen aber so wie sie sind richtig sind, hatte das keine Priorität bislang.
Ich habe zu dieser Firmware bisher nur sehr wenig beigetragen - das meiste kommt von Clint KA7OEI und Chris M0NKA. Diese benutzen beide den CooCox CoIDE. In der Yahoo Newsgroup zum mcHF hat es immer mal wieder Leute gegeben, die gefragt haben, ob es denn irgendjemand gelungen ist, das Ganze auch mit was anderem als mit CoIDE zu bauen. Die meisten Fragen kamen von Linuxianern. Da ich selbst auch einer bin und seit längerem meine php-Projekte und Python-Projekte (auf dem Raspi für die Ansteuerung von 1-Chip-Transceivern) baue, habe ich Eclipse als Basis für meine Erstellung einer Konfiguration genommen. Scheinbar haben das auch schon einige andere vor mir versucht (stand so in der NG), aber bislang ist noch keiner erfolgreich gewesen. Nun ist das Schnee von gestern und es kann plattformübergreifend losgehen.
Zu deinem Verständnis:
Der Bootloader ist Closed Source und von CHris (M0NKA). Er ermöglicht es, dass das Gerät durch einen affengriff in einen Zustand versetzt wird, dass es sich als USB-Cleint (mit der kleinen USB-Buchse in Nutzung) an einem Host meldet. Dieser Host hat jetzt ein Programm (proprietär, von Chris) das die eigentliche Firmware per USB auf das Gerät schubst. Also nix mit "USB-STick" etc. Die zweite (standard-USB)-Buchse ist für spätere Erweiterungen wie CAT, Anschluss einer Tastatur etc. vorgesehen und (noch) nicht in Benutzung.
Die diversen mDelay werden nicht alle benutzt / gebraucht. Sie stammen noch aus einer Zeit, in der Chris die "UR-Firmware" gebaut hatte und da waren sie eben in seinem Code. Seit ca. 1 Jahr hat Clint die FW weiter gepflegt und grosse Fortschritte erzielt. Mit der neuesten CoIDE-Version lässt sich die FW aus den Sourcen nicht bauen - es kommen ähnliche Fehlermeldungen wie bei Dir. Ich hatte sie in einem Crash-Versuch beseitigen können, indem ich die betreffenden Stellen einfach ausdokumentiert habe. Leider konnte ich nicht alle beseitigen. Aber da CoIDE sowieso absolunt nicht meine Welt ist, habe ich mich lieber mit der Konfiguration mit Eclipse beschäftigt.
Ich habe hier (http://www.amateurfunk-sulingen.de/forum/index.php?board=15;action=display;threadid=263) kurz beschrieben, wie man beim Installieren und danach beim Importieren des Projektes vorgeht. Ich habe das in der Zwischenzeit auf 4 verschiedenen Rechnern mit vier unterschiedlichen Linux-Systemen exakt so nachvollzogen (LMDE2, Siduction, Linux Mint 17, Debian Jessie) und alle "Eclipsen" konnten hinterher erfolgreich die FW bauen.
Ein makefile wäre auch eine schöne Sache - aber der Versuch, alle Warnings "gleich mit zu beseitigen" (oder gar echte Codierfehler zu finden) ist einen Schritt zu weit (finde ich). Zunächst sollte sich die FW mit dem makefile
- erfolgreich kompilieren
- und erfolgreich linken
lassen. Wenn das beides funktioniert, kann man "an die nächste Baustelle" gehen.
__packed ist mehrfach definiert - und auch ein "reservierter Ausdruck" (wegen der beiden "_" am Anfang). Habe ich in Bugzilla zum gcc gefunden...
Aber alle diese Dinge sollen / dürfen nicht verhindern, dass man eine Baustelle betritt. Wenn jeder, der bei einem Chaos auf dem Bau mit dem Vorsatz, gleich "alles zu richten" auf den Bau schaut, die Hände über dem Kopf zusammenschlägt und sagt "zu grosses Chaos - kann ich nicht" - hat er sicher Recht. Aber wenn er sich ein kleines Areal vornimmt, dann kann er das mit hoher Wahrscheinlichkeit in Ordnung bringen.
In deinem Fall:
- setz die warn-Levels nicht so, dass Du nun anstelle von warnings errors bekommst. Sowohl die FW mit Eclipse als auch die mit CoIDE gebaute haben diese warnings, aber beide laufen. Belass es so, wie es ist und lebe (zunächst) mit den wanrnigs.
- versuche herauszubekommen, was Eclipse "anders" übergibt (ich vermute, Du kannst schon alle Dateien kompilieren, aber nicht linken - richtig??) und ändere dementsprechend die Linker-Zeile
Wenn es gelungen ist, die Sourcen auch mit einem makefile zu einer funktionierenden FW zu schubsen, dann kommt das makefile in die Sourcen mit rein.
Und dann kann man darangehen, Dinge zu verbessern, Fehler zu finden, Dinge zu implementieren.
Das Projekt steht an einem wichtigen Punkt. Ich meine nicht das "Projekt des I40" - ich meine das gesamte Projekt. Durch die Veröffentlichung in DL sind jede Menge User dazugekommen, die viel "Ahnung" von der FW-Programmierung haben. Bislang hat diesen "Job" nur Clint übernommen - und zwar ALLEINE. Codeänderungen mussten langwierig mit Diskussionen implementiert werden. Clint ist ein reiner "Einzelkämpfer" und kann weder mit github noch mit svn umgehen - und das Wort "Kommandozeile" versetzt ihn mehr in Panik als dass es ihn neugierig macht. Aber Clint hat die FW extrem verbessert - es wäre ein Riesenfehler, ihn auszusperren! Gestern gab es eine neue FW-Release, und mit einem Beitrag habe ich ihn dazu gebracht, dass er die Notwendigkeit einer "geordneten Zusammenarbeit" jetzt als AKUT ansieht (er hat die Release gestoppt und es wird jetzt diskutiert, wie man in Zukunft zusammenarbeitet). An dieser Stelle ist die Chance für alle, hier aktiv beizutragen. Wenn erstmal ein Versioning-System existiert - dann geht alles einfacher...
Häng doch dein makefile mal als .txt hier an einen Beitrag an - so dass andere auch probieren können, was los ist. Klar: irgendwie ist das ALLES logisch - aber manchmal hilft auch Glück & Zufall, die Lösung zu finden.
"Jede Software enthält Fehler. Je mehr Zeilen der Code hat, desto mehr Fehler sind drin." Absolut normal. Aber man kann mit vielen Fehler leben - die Existenz von "Windows" beweist es eindrucksvoll ::)
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 07. September 2015, 09:27:58
Hallo Andreas,
ok, ich habe verstanden.
Das angehängte Makefile muss man in den ersten Zeilen ändern, damit ein einfaches 'make' die Quellen aus deinem github übersetzt. Beim Linken werden, wie gesagt, die 2 echten Fehler angemeckert. Dafür habe ich für mich die Quellen (lokal in einem anderen Verzeichnis) geändert. Das überlasse ich Dir.
Das Makefile muss (ohne .txt) in das Verzeichnis 'mchf-eclipse' kopiert werden und erzeugt Binaries ($(PRJ), .elf ($LPRJ) und .map direkt in mchf-eclipse. PRJ und LPRJ kann jeder ändern (z.B. um verschiedene Versionen zu erhalten).
Weiterhin ist zu beachten:
- PREFIX muss das Directory nennen, in dem die toolchain liegt (mit bin, lib, arm-non-eabi, share)
- GCC_LIB_VERSION bezeichnet das Versions-Verzeichnis im Pfad, über das die libgcc gefunden wird (ab lib/gcc/arm-none-eabi, bei mir 4.9.3)
- CFLAGS: Eclipse setzt bei mir -g3 und -O0 ein. Da aber auf -g normalerweise keine Zahl folgt, nehme ich an , dass -O3 und evtl. -g gewollt war.
- ich habe libs/libm.a umbenannt in 'not_used_libm.a' und die richtige lib der toolchain genommen, das kann man natürlich ändern...
- Die toolchain wird mit dem Makefile nicht über den PFAD des PC gesucht, somit sind hier keine Einträge nötig.
Eigentlich müsste der Linker selbst die richtige libm.a finden. Weil er das nicht tut, habe ich den LIB-Pfad hart angegeben.
Dieses Makefile sollte auch unter Windows funktionieren, wenn man in den Pfadangaben die '/' gegen '\' ersetzt. Ich habe das aber nicht ausprobiert.
make clean, make handy sollten aber auch unter Windows richtig löschen. Das Kommando wird entsprechend eingerichtet.
viel Spaß !
vy 73,
Harald, DL4SAI
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 07. September 2015, 09:38:04
Vielen Dank Harald!
Das Problem mit dem Linken hate ich auch - und habe an der Stelle damals aufgegeben. Ich hatte dann die Object-Dateien mit dem USB-Stick dem CoIDE untergeschoben und mit dem gelinkt - das ging problemlos. Hier hatte ich zunächst mit dem Eclipse weitergemacht.
Ich werde mir ein ein paar freien Stunden (in Minuten ist das wohl kaum zu finden) dein Script ansehen und selbst mal rumprobieren.
Dass die libm.a nicht automatisch richtig gefunden wird, kann ich bestätigen. Obwohl auch ich bei solchen Fehlern zunächst IMMER (!!!) die Ursache "vor dem Bildschirm" suche, darf man nicht aus den Augen verlieren, dass es sich um Linker-Bugs handeln könte und man sich "einen Wolf sucht". Mir ist es nämlich auch unter Eclipse nicht gelungen, die lib automatisch finden zu lassen - obwohl die ja durch die Angabe des Zielprofessors und dessen Eigenschaften eigentlich feststehen sollte... Das hat mich stutzig gemacht...
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 07. September 2015, 12:42:27
@Harald
Sowas lässt mi keine Ruhe 8)
Ich habe mir dein makefile mal angeschaut und ein paar Kleinigkeiten gefixt. Im makefile waren ein paar Kleinigkeiten falsch, und im Quelltext habe ich auch ein paar Zeilen ausdokumentiert, die Fehler hervorriefen. Mit Eclipse lässt sich nun das Binary bauen wie vorher (keine Änderung des Ergebnisses), mit dem makefile auch. Dummerweise läust das Ergebnis aus dem makefile noch nicht richtig ??? Nach dem Einschalten erscheint der gewohnte Splashscreen, dann schaltet sich der mcHF aus. Ein Neustart ist nur nach Abtrennen der Betriebsspannung möglich, danach gleiches Spielchen.
Ich habe auch schon einen Verdacht:
Ich wollte vor zwei Wochen mal die warnings nach und nach dezimieren und habe mit den "einfachsten" begonnen:
Es wurden Funktionen oder Variablen deklariert, die niemals benutzt wurden... Diese Funktionen bzw. Variablen hatte ich einfach mal ausdokumentiert. Komischerweise lief das erzeugte Binary danach nicht mehr: es zeigte das gleiche Verhalten wie das vom makefile gebaute... Als Ursache habe ich die Deklaration der Variablen test_a und test_c in audio_driver.c gefunden. Sie werden zwar nirgendwo benutzt, aber wenn man die Deklaration weglässt, dann zeigt das Binary obiges Verhalten. Das riecht irgendwie nach "unsauberem Platzhalter"....
Ich habe den jetztigen Stand mal in mein Github geschubst. Vielleicht bekommst Du ja wieder Lust ;D Ich denke, wir können alle zusammen mächtig vorankommen...
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 07. September 2015, 13:31:52
Hallo Andreas,
habe ich dich richtig verstanden: wenn test_a und test_c wieder aktiviert sind, funktioniert
das Binary aus dem makefile ?
Oder gibt es doch noch andere Probleme ?
Ich kann das hier mit dem geänderten makefile auch übersetzen, es ist mit gcc 4.9.3 (2015_q1) und der libs/libm.a knapp 300 Bytes kürzer als das mchf-eclipse.bin im Arbeitsverzeichnis deines github (firmware_Target_Flash/Debug/bin/firmware_Target_Flash.bin aus Eclipse hat 172589 ??)
Ich probiere das -wenn ich wieder Zeit habe- auch mal unter Windows (cs-make.exe)
vy 73,
Harald
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DC3AX on 07. September 2015, 15:08:48
Missing Declaration Warning:
Der Cortex bekommt immer R0 als Übergaberegister für den ersten Funktionsparameter und als Return Register reserviert. Alles geht gut, solange also Funktionen mit int fkt(void) oder void fkt(int) oder void fkt(void) nicht korrekt vorwärz deklariert werden. Sobald eine Funktion mit zwei oder mehr Übergabeparametern nicht korrekt bekannt gegeben wird, ist das Ergebnis unvorhersehbar.
Makefile:
Ich meinte nicht, dass es zwischen identischen Installationen auf identischen Systemen Ärger gibt, sondern dass es vor allem zwischen unterschiedlichen Eclipse-Versionen und vor allem unterschiedlichen Betriebssystemen trotz identischer Eclipse Versionen Ärger gibt. Eclipse hat sich zwar deutlich gebessert, aber es gibt leider immer noch Ecken und Kanten.
Gnuarm-Eclipse:
Diese Erweiterung konfiguriert ja auch nur zusammen, was man im Makefile manuell eintragen müsste und sollte. Dadurch, dass die Eclipse-Erweiterungen auch immer mit jeder neuen Eclipse-Version weiter gepflegt werden muss, kommt es da auch gerne zu (vorübergehenden) Problemchen. Ich kann mit den Fehlermeldungen im Konfigurationsfenster leben, aber der Neuling wird verunsichert sein.
Die Erweiterung gnuarm-eclipse ist, wenn man die Freitext-Felder zum gcc in den normalen Feldern von Eclipse selber korrekt ausfüllt, völlig überflüssig. Wenn man laufend neue Projekte kreiert, ist so ein Klick-And-Go Konfigurator sicherlich nett, aber wir haben ein fertiges Projekt und einige wenige wissen, wie man den gcc, ld und as optimal konfiguriert. Da ist cut-and-paste besser und Fehlerfreier als lange Beschreibungen, wer wo klicken und welches Häkchen setzen muss.
Windwos-Linux
Benutzt man unter Windows cygwin mit dann identischem gcc und binutils wie wir linuxer, dann kann man den Makefile problemlos mit / verwenden und der Compile-Vorgang ist 20 bis 30% schneller. Jedenfalls war er das jahrelang, wo ich noch mit der Kombi Win7 + cygwin + winarm gearbeitet habe. Was am meisten bremste, waren die kleinen Dinge, wie make, cp, mv, rm... Nutzte man die cygwin Derivate dieser Progrämmchen, ging alles sehr viel schneller.
Bootloader:
Der STM32 hat einen integrierten Bootloader, der, bei korrekt gesetzten BOOTx Pins, startet und ein neues Image via OTG oder Serieller entgegen nimmt. Keine Ahnung, warum man einen proprietären Bootloader auf einen vorhandenen Bootloader setzt.... Normal reicht ja einer :)
Fortschritte:
Leider hat mich eine Familien-Angelegenheit etwas zurückgeworfen bei dem Projekt. Ich konnte erst gestern anfangen mal den STM und ein paar andere Chips auf die UI Platine zu löten. Mit der Software wollte ich weiter machen, sobald ich überhaupt mal was flashen kann. |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 07. September 2015, 15:30:57
Hallo Harald,
das hast Du falsch verstanden.
Das Binary aus dem makefile habe ich noch nicht zum Laufen bekommen. Fehlersymphtom "nach Splashscreen wird der BS dunkel und nix geht mehr".
Aus gleichem Quellcode (und mit gleichen libs gelinkt) mit Eclipse übersetzt läuft das Binary.
Dokuemntiere ich die beiden Variablendeklarationen aus, dann ist das Binary
Eclipse mit Var-Deklarationen (läuft): 262324 Bytes
Eclipse ohne Var-Deklarationen (läuft nicht): 262324 Bytes
makefile mit Var-Deklarationen (läuft nicht): 261716 Bytes
An den Libs liegt es nicht - das Binary mit der libm.a aus dem libs-Ordner ist identisch mit dem, wenn ich die Toolchain-eigene libm.a nehme.
Ich denke, hier kommt man nur auf folgende Methoden voran:
- Byteweiser Vergleich der beiden Ergebnisse (und ggf. der Zwischenstufen wie Objektfiles)
- ausprobieren (flashen und gucken...)
Kannst Du mir mal dein Binary per Email senden (per Anhang geht nicht, das verbietet die Forensoft)?
va 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 07. September 2015, 15:40:10
Hallo Andreas,
dann wäre es besser, das Makefile wieder zu löschen. Alles was ich nicht zum Laufen gebracht habe,
sollte meinen PC besser nicht verlassen...
Schick mir doch bitte mal deine mail-Adresse an hb@hbtron.de.
vy 73
Harald
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 07. September 2015, 16:08:49
Meine Emailadresse steht in meinem Profil...
Und das Makefile steht kurz vor der Vollendung - so weit war es noch nie.
Ich veröffentliche sehr gerne Dinge, die noch nicht ganz fertig sind. Auf diese Weise kann ein anderer evtl. wie aus der Pistole geschossen sagen: "da mss noch ein xxx rein - dann läufts".
Genauso, wie ich erst mit deiner "Steilvorlage" überhaupt erst dazu gekommen bin, ein Makefile hier zu haben, das bis zum Schluss durchasrbeitet und ein Binary erstellt.
Niemand ist perfekt - und deswegen ist es auch nicht Voraussetzung, dass alles, was (m)einen Rechner verlässt, perfekt ist...
vy 73
Andreas
@Ulrich
Was die Sache mit dem doppelten Bootloader soll, weiß ich auch nicht. Ich war auch schon mal drauf und dran, den Bootloader komplett umzuwerfen...
Nachtrag:
Manchmal hilft es die Substanz zwischen den beiden Ohren zu aktivieren... Wenn man den On-Chip-Bootloader benutzt, kann man den STM mit ein paar falsch gesetzten Bits "bricken". Das gaht nicht mehr, wenn man einen eigenen benutzt, bei dem die kritischen Bereiche nicht überschreibbar sind. |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 08. September 2015, 07:30:04
Die Version mit einem funktionierenden makefile liegt jetzt in meinem github (https://github.com/df8oe/mchf-github).
mny tnx Harald!
vy 73
Andreas
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 08. September 2015, 08:45:15
Hallo Andreas,
sehr schön, dass das funktioniert, und fast keine Warnings mehr :-* Allerdings:
Die CC-Optionen -fdata-sections und -ffunction-sections in Verbindung mit dem komplizierten arm-gccc-link.ld, in dem dann sections gezielt 'discarded' werden, ist wohl DIE Krücke der COIDE, um bestimmte Teile 'Ein' oder 'Aus' zu schalten. So etwas baut niemand 'von Hand'.
Da kommt jetzt die Frage des Debugger-Tools ins Spiel. Da will ich mich nicht einmischen. Die Option -O2 müsste noch einen Geschwindigkeits- und Platz-Vorteil bringen. Allerdings lässt sich das dann noch nur sehr schwer debuggen ! Für den Debugger sollte auch -g wieder eingeschaltet werden (betrifft meines Wissens nur Infos im .elf, das ja zum Debuggen geladen wird). Daher auch meine Unterscheidung PRJ und LPRJ. Letzteres - Lokales_Projekt - wähle ich in meinen Projekten immer gleich, damit ich den Debugger-script nicht bei jeder Beta immer ändern muss.
Ich habe nur noch Bedenken bezüglich der libs/libm.a:
Das ist wie eine Flasche mit Inhalt, aber ohne Etikett. Da kann alles drin sein, auch Wasser. Die Includes hierfür (das Etikett) stehen in der jeweiligen toolchain. Wenn also Erweiterungen in der toolchain gemacht werden, stehen diese auf dem Etikett, sind aber nicht drin >:( Ausserdem ignoriert man alle Verbesserungen, die in die libm.a eingebaut werden. Ich glaube nicht an sehr viel, aber wenn sich dort etwas verschlechtert, falle ich vom Glauben an 'open source' ab.
Ich habe mal mit libs/libm.a übersetzt: 263028 Bytes, libs/libm.a umbenannt nach 'not_used_libm.a': 262612 Byte, also ca. 400 Byte weniger (gleiches Makefile, gleiche toolchain, gleiche Warnings).
Das wäre vielleicht doch noch eine Versuch wert...
vy 73,
Harald, DL4SAI
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 08. September 2015, 09:25:41
Klar könnte man die arm-gcc-link.ld noch analysieren! Kann durchaus "was drin" sein...
Wenn Du irgendwelche Optimierungen setzt (schon =1 reicht), dann läuft die FW nicht mehr auf dem mcHF. Habe ich ausprobiert.
-g kann man ein- oder ausschalten - es wird kein Debugging genutzt. In der FW ist irgendwo ein Schalter, wenn man den beim Kompilieren gesetzt hat, kann man whrend des Lauf Dinge auf der vierpoligen Stiftleiste ausgeben lassen - das ist schon alles.
Mein mcHF arbeitet schon seit längerem mit der libm.a aus der Toolchain. Die Prozesssorlast ist dadurch um ca. 10% gegenüber der originalen libm.a gesunken. Richtig messen kann ich das nicht - es ist eine Schätzung, die ich im direkten Vergleich mit ungünstigen Beteibsmodi (10kHz Bandbreite, AM, Notch+NB an) gemacht habe.
Jetzt wäre es ein weiterer Schritt, herauszubekommen, was das für eine math-lib ist. Ich denke sie ist aus einem Keil Paket eine DSP-lib??!! Aber aus welchem? Gibt es da neuere? Das wäre ein wichtiger Ansatzpunkt!
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron on 08. September 2015, 12:55:29
Hallo Andreas,
bzgl. lib-math mache ich mich noch schlau.
Aber eine andere Frage, die hier ins Forum passt: Hast du einen ST-Link V2 schon mal ausprobiert ? Den gibt es bei digikey für wenige Euro und bei Farnell (allerdings USB isoliert) für etliche Euro mehr.
Damit soll man mit openocd und Eclipse ab leerem Flash einen STM32F4 auf source-level debuggen können.
Die Anleitung ist sehr detailliert und ausgiebig dargestellt. Das geht angeblich auch unter OSX und Windoof.
Das Protokoll für den ST-Link ist im openocd enthalten (Trace geht wohl nicht).
Und mit der Windoof-Beigabe zum ST-Link ::) kann man zumindest mal Flashen...
Wer den SWD/JTAG dabei abhängt, und das Ding 'brickt', muss schon ziemlich dumm hinlangen.
vy 73,
Harald
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 08. September 2015, 15:09:18
Hab ich mir just gekauft - liegt schon bei mir, ist aber noch "originalverpackt" :)
Ich weiß, dass man da ziemlich blöd sein muss. Aber die Schelte, wenn der Hundertbeiner wieder ausgelötet werden muss, dürfte gigantisch sein...
Ich hätte kein Problem damit. Ob man das für den "normalen User" auch so machen sollte - da bin ich skeptisch.
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DC3AX on 09. September 2015, 13:17:17
Also ich arbeite tagtäglich mit dem ST-Link V2 und es ist genial. Data, Clock, Vcc und GND, für den Luxus noch NRES auf die Pins geklemmt und schon geht es los. Flashen, debuggen, semi-hosting (printf ohne UART) geht perfekt mit openocd 0.9.0. Das sollte Bestandteil der gnuarm toolchain sein.
Ich habe mir das übrigens gerade and meine UI Platine geklemmt, nachdem der DFU OTG nicht will. per openocd kann ich den STM32F4 jetzt sehen und dann lade ich gleich mal was ins Flash. Es sollte ja wenigestens ein Logo oder so kommen, bis er merkt, dass das RF Board fehlt.
Mit dem ST-LINK kannst du den F4 nicht einfach mal so kaputt fusen. Da musst du schon sehr präzise deine Befehle eingeben, daher mach Dir da keine Sorgen.
Bei mir sieht das gerade so aus:
https://goo.gl/photos/sL3fFxzwU3Cn9Dr28 (https://goo.gl/photos/sL3fFxzwU3Cn9Dr28)
Nachtrag, wer lesen kann ist klar im Vorteil, nachdem ich gesehen hatte, dass man BAND+ auch noch drücken muss, funktioniert DFU und mit BAND- auch der offizielle Loader.
Aber mit ST-Link braucht man weder das eine, noch das andere.
73!
Ulrich |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD on 25. September 2015, 16:52:53
Hallo, ich bin neu in diesem Forum und interessiere mich für den mcHF!
Von Beruf bin ich Software-Entwickler (C/C++, Windows und Embedded, auch ein wenig Linux).
Ich interessiere mich für die Firmware des mcHF und für Eclipse, da ich vor ein paar Jahren
schon mal mit Eclipse gearbeitet habe. Aus dieser Zeit habe ich auch Erfahrungen mit Subversion.
Ich bin Windows (7, 8 ) 10 Anwender . Zu der "Anleitung" habe ich Fragen:
Wo bekomme ich den Crossassambler "gnu-arm-none-eabi"?
Im Internet gibt es mehrere ähnliche und wie installiere ich diesen?
Wo bekomme ich "openjdk-7-jdk"? Dieses Teil habe ich bei Orakle so nicht so gefunden.
Wozu brauche ich CoIDE, zwei Entwicklungsumgebungen?
Wie spielen Eclipse und CoIDE zusammen?
Mit der Hardware habe ich es nicht eilig. Ich suche erstmal jemanden der mir die großen ICs auflötet.
Ich kenne mich zwar auch mit Hardware und Löten aus, aber besser wäre ein Professioneller.
vy73 Werner, DK2JD.
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 25. September 2015, 17:20:36
Hallo Werner,
Du würfelst hier einige Dinge "durcheinander" - die von der "freien Welt" und die von der "Windows-Welt"...
Da ich seit über 15 Jahren nicht mehr mit Windows arbeite, kann ich Dir die Fragen nicht explizit beantworten.
Nur: der freie Compiler gnu-arm-gcc stammt aus der Linux-Welt - es gibt ihn aber auch für Windows.
Und Oracle ist die "closed-source-Java-Variante" - "open-jdk" die quelloffene. Ich würde IMMER die freie Variante wählen, wenn es eine gibt. Ob es open-jdk auch für Windows gibt, weiß ich nicht. Und dass es Windowsianer sehr schwer haben, mit git umzugehen, habe ich inzwischen auch erkennen müssen. Git ist eben was für die Kommandozeile - des Linuxianers liebstes Spielzeug - und nichts für eine Maus - das liebste Spielzeug der Windowsianer 8)
Kannst Du Dir vorstellen, die Entwicklung auf deinem Linux-Rechner zu machen? Dann könntest Du von vielen Tipps der anderen Linux-Nutzer hier im Forum profitieren. In unserer Gruppe gibt es zur Zeit noch keinen einzigen Windows-Nutzer, der an der Firmware mitbasteln möchte. Wobei das sicher auch geht - nur gibt es hier noch keine "Spezialisten" dafür...
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 25. September 2015, 17:33:25
Hallo Werner,
mach es einfach so wie ich auf der ersten Seite beschrieben habe. Die Fehlermeldungen haben sich ja geklärt.
Eclipse für Windoof runterladen und installieren. Dann den Compiler suchen (am besten Googles du nach der Datei) und installieren. Geht eigentlich ganz klaglos.
73, Hans
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD on 25. September 2015, 18:10:15
Hallo, ich weiß schon wo nach ich suchen muss.
Nur manchmal schreiben die Leute nicht auf was die Software kann.
Allein nur "für Eclipse" ist nicht alles, siehe CoIDE.
Das einzige was mir noch fehlt ist der Cross-Assembler für Arm-Prozessoren.
Mit Raspberry Pi geht das ja auch.
Es hat ja keinen Zweck, wenn ich mit dem falschen anfange.
Das kann ja nicht so schwer sein die paar Zeilen auch noch aufzuschreiben.
Wenn ich die Info bekomme, schreibe ich das auch selbst auf.
Eclips läuft schon länger, das ist nicht das Problem.
Auch die Command line ist kein Problem für mich.
Seit der PowerShell kann man damit was anfangen.
Ich hab Software für Embedded-Computer geschrieben.
Da geht es nicht anders zu wie unter Linux.
Nur man muss es ja nicht übertreiben.
Ich werde bestimmt nicht wegen mcHF auf Linux umsteigen.
Wenn es nicht geht, dann lasse ich es eben.
vy73 Werner, DK2JD. |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 26. September 2015, 06:26:06
Eclipse ist ein Java-basiertes Programm, deswegen brauchst Du für die Installation "Java". Wenn bei Dir Eclipse schon läuft, kannst Du Dir die Gedanken um Java schenken. Dann brauchst Du nur noch den gnu-arm-compiler und das STM32F4-Plugin. Das Plugin installiert man aus der IDE selbst - das geht bei Windows garantiert genauso wie bei Linux. Nur wie Du den gnu-arm-compiler einrichten musst und wo er downzuloaden ist, das weiss ich nicht. Aber wenn Du den Weg gefunden hast, würde ich mich sehr freuen, wenn Du ihn hier aufschreiben würdest. Das wandert dann in die How-Tos.
Ebenso, wenn Du git für Windows installiert hast und damit umgehen kannst. Auch da sind noch "unbeschriebene Blätter"...
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 26. September 2015, 07:25:09
Werner,
wie gesagt, ich habe es unter Windows am laufen. Und zwar mit:
- Eclipse für WINDOWS (eclipse-cpp-mars-R-win32-x86_64.zip) plus Java
- gcc-arm-none-eabi-4_9-2015q2-20150609-WIN32.exe von https://launchpad.net/gcc-arm-embedded
- fehlende Plug-Ins werden angefordert
- natürlich entsprechend konfiguriert
Damit konnte ich die von Andreas in Github eingestellten Sources übernehmen und compilieren. Ob das Ergebniss lauffähig ist kann ich allerdings auch noch nicht sagen weil noch die HW fehlt.
Der irgendwo erwähnt "Cross-Assembler" hatte mich auch verwirrt und muß wohl nur unter Linux nachinstalliert werden.
73, Hans
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 26. September 2015, 08:19:56
Ein Cross-Assembler erzeugt auf einem Prozessor der Art "x" den ausführbaren Code des Prozessortyps "y". Da Du in deinem PC mit Sicherheit keinen Arm-Prozessor hast (sondern einen Intel oder AMD), brauchst folglich auch Du einen Cross-Assembler, da der Code, der für einen x86 bestimmt ist, auf einem Arm-Prozessor nicht lauffähig sein würde. Diesen Cross-Assembler hast Du aber auch schon installiert (Du wusstest nur nicht, dass es einer ist). Er heißt bei Dir gcc-arm-none-eabi-4_9-2015q2-20150609-WIN32.exe 8).
vy 73
Andreas
PS:
Ob Dein Compilat auf dem STM32 lauffähig ist, kann nur ein Test auf demselben zeigen. Ein Beweis wäre, wenn dein Produkt im binären Vergleich mit dem Binary aus meinem Paket identisch wäre... |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DL5HAT on 28. September 2015, 15:41:29
@DF4KD
ich habe eben Java installiert. Die derzeitige Version ist 1.8. Eclipse C/C++ erwartet aber Java1.7. Gibt es irgendeine Möglichkeit die ältereVersion zu bekommen?
73 de Frank |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DC3AX on 28. September 2015, 16:08:50
FAQ hier:
http://java.com/de/download/faq/java_7.xml
dem zu folge hier
http://www.oracle.com/technetwork/java/javase/archive-139210.html
73!
Ulrich |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 28. September 2015, 16:38:50
@DL5HAT
Sorry, ich bin nicht früher an den Comp gekommen. Hier einen Auszug aus meiner Elcipse config an der du alles ersehen kannst.
System ist Win7/64:
x86_64
-showsplash
C:\Program Files\eclipse-cpp-mars-R-win32-x86_64\eclipse\\plugins\org.eclipse.platform_4.5.0.v20150603-2000\splash.bmp
-launcher
C:\Program Files\eclipse-cpp-mars-R-win32-x86_64\eclipse\eclipse.exe
-name
Eclipse
--launcher.library
C:\Program Files\eclipse-cpp-mars-R-win32-x86_64\eclipse\\plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.300.v20150602-1417\eclipse_1611.dll
-startup
C:\Program Files\eclipse-cpp-mars-R-win32-x86_64\eclipse\\plugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar
--launcher.appendVmargs
-product
org.eclipse.epp.package.cpp.product
-vm
C:\Program Files\Java\jdk1.8.0_25\bin\..\jre\bin\server\jvm.dll
.
.
.
Umgebungsvariable Nicht vergessen!:
C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q2\bin
Hoffe es hilft...
73, Hans
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DL5HAT on 29. September 2015, 07:48:50
@DF4KD
erstmal herzlichen Dank. Ich werde Deine Konfiguration ausprobieren und dann Berichten
73 de Frank
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD on 01. October 2015, 06:43:15
@DF4KD
Hallo Hans,
vielen Dank für Deine Starthilfe. Entschuldigung, hatte die Tage wenig Zeit.
Den Crossassembler habe ich geladen. Er ist einen Step (q3) weiter.
Java ist bei Windows eigentlich kein Problem, braucht man eben.
Ich habe noch ein paar Fragen:
1. Wo finde ich das "gnuarm-Plugin" (Bezug "Anleitung ..." Punkt 3)?
2. Verwendest Du eine spezielle Java-Version?
3. Funktioniert der Download der Quellen, unter Windows, so wie von Andreas beschrieben?
4. Welche Windows-Version verwendest Du?
Die Fragen reichen für heute mal. Im Voraus vielen Dank.
vy73 Werner, DK2JD. |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 01. October 2015, 07:51:25
@DK2JD
Hallo Werner,
ich versuche mich mal zu erinnern, hi. Es war für mich auch das erste Mal...
1 das "Plug_in" sollte mit der Installation des GNU ARM Embedded Tools auf deinem Rechner sein.
In Eclipse Help->Install New Software->Add,
dort hatte ich "GNU ARM Eclipse Plug-ins - http://gnuarmeclipse.sourceforge.net/updates" installiert.
2 nein, ich hatte einfach das jdk1.8.0_25 installiert
3 Ja, File->Import->GIT->Projects from Git->Link von Andreas eingeben
4 Win7/64
Hoffe es ist alles richtig, man macht das nicht so oft, und mit der Buchführung hapert's.
73, Hans
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD 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.
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD 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
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD 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.
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DC3AX 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 |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron 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
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD 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
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DG3NEO 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 |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DC3AX 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 |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD 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
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 02. October 2015, 13:31:24
Es ist überhaupt kein Problem wenn die Windows-User ihre Programmierbeiträge unter CoIDE liefern.
Nur muss für ein vernünftiges Versioning sichergestellt sein, dass sie github benutzen, und zwar nicht nur als "git pull" sondern auch als "git commit".
Und genauso wie die Linuxianer die config von CoIDE nicht anrühren sollten die Windowsianer auch die config von Eclipse nicht anrühren.
Für das Cleanup des "Wurschtelcodes" so wie er jetzt vorliegt sollte nur ein ganz kleines Team agieren, damit man sich nicht noch mehr verwurschtelt. Am WE werde ich das mit Astralix klären. Ein vernünftiges Dateisystem (includes und srcs) mit ordentlichem Code kompiliert selbstverständlich auf allen Systemen.
Nur gerade weil ich 1999 in einem Monat dreimal mit der Aufgabe "Neuinstallation weil irgendwas geht nicht mehr und keiner kann die Ursache finden in meinem Windows-System" hatte, habe ich damals konsequent den Umstieg auf Linux durchgeführt und bereue nur eins: dass ich damit so lange gewartet habe. Ich hätte von Atari ST gleich auf Linux und nicht erst auf Win95 umsteigen sollen - das war ein Irrweg. Ich habe seit 1999 diverse Distributionsumstellungen vorgenommen, aber keine weil irgendwas nicht funktionierte und eine Neuinstallation habe ich seit 1999 noch nie gebraucht ::)
Trotzdem bin ich mir sicher dass alles auch irgendwie unter Windows geht...
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: hbtron 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
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE 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 |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD 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 |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD 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 :P.
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. |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD 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 |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD on 05. October 2015, 17:11:19
@all
Hallo,
ich habe den Makefile auf Windows umgestellt. Die Übersetzung mit der Commandline funktioniert.
Der .bin-File ist 259KB groß, .elf-File ca 440 KB.
Ein Problem habe ich noch, die Generierung läuft noch nicht unter Eclipse.
Im Moment läuft nur der "make clean". Aber das ist ein Eclipse Problem.
Für die Umstellung hat mir Hans den Anstoß gegeben mit seinem Link, den er hier veröffentlicht hat -
http://hertaville.com/gcc-arm-toolchain-stm32f0discovery.html.
Hier ist eine Generierung für einen STM32F0, inklusive Beispiel, beschrieben, mit GNU Make und Eclipse bis zum Sourcecode-Debuggen.
Die Umstellung hat nichts mit MinGW zu tun. Sie läuft allein auf GNU make und auf GNU Tools ARM Embedded.
Die Anpassungen am Makefile sind nicht so umfangreich, wie anfangs vermutet.
Ich kenne mich in dem Projekt noch nicht aus. Daher brauche ich noch etwas Hilfe, wie wir diesen geänderten Makefile unterbringen.
Gegen Ende der Woche fahre ich eine Woche in Urlaub, also gibt es eine kleine Zwangspause für mich.
@DF4KD
Hallo Hans, ich glaube nicht, das bei dir der Makefile läuft.
Der kann unter Windows garnicht laufen - er sucht die Sourcen z.B. unter /usr.
Warscheinlich läuft bei Dir der die interne Generierung von Eclipse oder hast Du einen eigenen Makefile?
Der Makefile enthält alles was benötigt wird, dazu braucht man eigentlich kein Eclipse.
vy 73, Werner. |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 05. October 2015, 18:24:36
Gerade einen kleine Test gemacht.
Clean->make all, Ergebnis = mchf-eclipse.bin (265.668 Bytes), mchf-eclipse.elf (1.285.372 Bytes). Das ist allerdings mit Debuginfos...
Ordner ist D:\Daten\Users\..\git\mchf-github-219.23\mchf-eclipse. Ich habe alle Daten auf D:.
Geht doch.
73, Hans
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD on 06. October 2015, 06:49:17
Hallo Hans,
wusste ich es doch, denn ohne eine Anpassung für die "GNU Tools ARM Embedded" und "/usr" läuft der Makefile auf Windows nicht.
Hier die Datei zum Ausprobieren. Der Installation-Pfad für die "GNU Tools ARM Embedded" muss auf Deine Installation angepasst werden.
Probleme bitte an mich.
vy 73, Werner.
PS: Kann man hier keine Dateien .txt hochladen? |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 06. October 2015, 07:21:19
Hallo Werner,
haben wir uns falsch verstanden? Es geht bei mir, und zwar ohne irgendeine Anpassung! Clean->Make all meint das starten aus Windows/Eclipse herraus, NICHT per Befehlszeile.
Ich würde am makefile oder sonstigen Settings die evrl auch unsere Linuxfreunde betreffen nichts ändern. Damit würde man nur noch eine Version in die Welt setzen.
Aber ich schaue es mir nachher nochmal genauer an.
Datei hochladen scheint hier nur zu gehen wenn du vorher keine "Vorschau" machst und/oder nicht nachträglich etwas hochladen willst und/oder ein Umlaut dabei ist und/oder ... Versuch einfach nochmal.
73, Hans
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD on 06. October 2015, 09:57:26
Hallo Hans,
ich habe noch einmal nachgeforscht.
Die von mir geladene Version ist 219.19.
Ich habe gesehen, das Du von einer 219.23 schreibst.
Gibt es eine Update-Möglichkeit? Oder wie komme ich an die neuste Version ran.
Ich habe zwar schon mit SVN und Subversion gearbeitet, aber eben noch nicht mit Git.
Selbst wenn ich die falsche/alte Version geändert habe, habe ich mehr über das System mcHF gelernt als auf anderen Wegen.
Übrigens sind die Änderungen nicht so umfangreich, dass man nicht eine gemeinsame Version für Windows und Linux erzeugen könnte.
Eine Unterscheidung zwischen Windows und Linux ist in meiner Version des makefile enthalten.
73, Werner. |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 06. October 2015, 11:43:52
Die Version, die auch das makefile und die Konfiguration mit eclipse enthält, ist die 219.23. Wenn Du versucht hast mit der 219.19 zu arbeiten sind deine Schwierigkeiten verständlich: die enthält nämlich keinerlei Konfigurationsfile für Eclipse und auch kein Makefile. Die Version 219.23 bekommst Du aus dem Link im Startbeitrag dieses Threads.
Unter Linux geht das so:
cd in/irgendein/Verzeichnis/das/Du/angelegt/hast
git clone git://github.com/df8oe/mchf-github.git
Dann dauert es ein paar Sekunden, und danach hast Du in dem Verzeichnis, in dem Du Dich gerade befindest, eine exakte Kopie meines master-branches.
Ich denke, wenn Du "github for windows" installiert hast, geht das da genauso.
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 06. October 2015, 12:26:54
@all
Ich habe etwas rumgespielt.
Werner hatte irgendwie recht, mein Sytem benutzt nicht das org Makefile, oder doch oder nur einmal!?
Wenn man in den C/C++ Builder settings den External Builder wählt, mit $(cross-make) als build command, und "Generate Makefile automatically" selektiert, wird ein neues Makefile generiert und in die jeweilige Release oder Debug Dir reingeschrieben.
Woher Eclipse allerdings die Einstellungen, Includes, u.s.w. (stehen in C/C++ General->Paths and Symbiols) her hat ist mir schleierhaft.
Ich habe das erst gemerkt als ich von "debug" auf "release" umstellen wollte. Da fehlten nämlich die ganzen Einstellungen und ich mußte sie erstmal alle rüberkopieren. Dann lief "Release" auch - bis auf eine Fehlermeldung deren Grund ich bisher noch nicht finden konnte:
Consolen Output:
der ARM linker bricht
Invoking: Cross ARM C Linker
arm-none-eabi-gcc -mcpu=cortex-m4 -mthu . . . . . ne-eabi/lib/armv7e-m/fpu\libg.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x16): undefined reference to `_exit'
collect2.exe: error: ld returned 1 exit status
make: *** [mchf-eclipse.elf] Error 1
Fällt da jemanden etwas zu ein?
73, Hans
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 06. October 2015, 12:45:22
Das sieht nach einer fehlenden Standard-Lib aus der Toolchain aus...
Schau mal in den Einstellungen für die Libs, ob da bei debug und release alles identisch ist.
vy 73
Andreas
PS:
Um den ganzen Mist mit den Konfigurationen zu ersparen, hatte ich in der Version 219.23 ein lauffähiges Konfigurationsfile für Eclipse mit reingelegt das von Eclipse berücksichtigt wird, wenn man den Ordner "mchf-eclipse" als "existierendes eclipse-Projekt" importiert... |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 06. October 2015, 13:08:54
Ja ja, alles identisch. Ich mußte ja alles von debug nach release kopieren.
Der einzigste Unterschied besteht noch in Symbols, in release gibt es zusätzlich"__FPU_PRESENT" und "__FPU_USED". Bei debug fehlen die zwei, aber debug geht ja.
Leider habe ich noch keine HW, kann also das compilierte nicht ausprobieren, "mchf-eclips.bin" wäre 265.668Bytes groß. Würde das passen?
73, Hans
P.S.
Ich nehme an das beim Import die Daten übernommen wurden (kann ja nicht anders sein).... |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD on 06. October 2015, 13:32:16
Hallo,
so wie Andreas die Version 219.19 beschreibt, ist das nicht die Version die ich habe.
Ich habe nur darauf geschlossen, da es in der Datei history so drin steht.
Aber in der aktuellen 219.23 history steht immer noch 219.19 drin.
Der makefile der Version 219.23 ist identisch mit meinem Original. Er hat sich wahrscheinlich auch nicht geändert.
Hans,
es ist sehr einfach die Funktion des makefiles zu prüfen. Gehe mit Deiner Eingabeaufforderung in das Dir wo sich der makefile befindet.
Eingabe: make clean, danach: make all und Du siehst was abgeht.
vy 73, Werner. |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 06. October 2015, 15:14:03
Was steht in deiner history??
Es muß das hier drinstehen:
##############################
I used mcHF Firmware Source 219.19 from Clint KA7OEI as base.
Changes:
08/19/2015
- added detection of SI570 hardware address (possible addresses 0x50 / 0x55)
- added workaround for malfunction of startupfrequency detection during unattended boots or bootloops
- merging Eclipse and CooCox configuration to one package so that both IDEs can be used
09/07/2015
- created makefile (thanks to DL4SAI)
- commented out of some curious lines which prevent building using makefile
- building is now possible with makefile but there is one issue to find:
firmware binary is 600 bytes shorter than binary generated by eclipse and does only show splashscreen, then ends
09/08/2015
- makefile is now working
09/09/2015
- I merged Clint KA7OEI new released version 219.22. This new version now is named 219.23 and will be the base
for all future firmware developments - I hope...
2-be-continued
DF8OE, Andreas
###############################
Dann ist es die richtige Version - und es steht auch drin, dass es jetzt die 219.23 ist. Steht bei Dir was anderes: bitte genau beschreiben, woher Du das hast. Dann geistern hier noch irgendwelche "Leichen" herum :)
vy 73
Andreas
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD on 06. October 2015, 16:23:23
Hallo Andreas,
leider bin ich auf das Englische Datum reingefallen. Ich schreibe lieber das Internationale, das ist wenigstens sortierbar, z.B. 2015-10-06.
Also bei mir steht genau das von Dir beschriebene drin.
Kleiner Hinweis, das Ablegen von Projekteinstellungen von eclipse in Downloads ist vielleicht etwas heikel.
Die Einstellungen haben sich in Mars gerade wieder etwas verändert.
Es ist ein Unterpunkt in "C/C++ Build" - "Discovery Option" weggefallen.
vy 73, Werner. |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 06. October 2015, 16:36:30
Also ich habe die Einstellungen mit Luna erstellt und dann auf meinem Notebook mit Debian 8 und Mars importiert und alles lief auf Anhieb...
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 07. October 2015, 14:23:04
@Andreas
Ich habe es nun geschafft deine git Sourcen ohne Fehler als Debug und Release in Win-Eclipse zu compilieren. Debug ging ja schon, bei Release fehlte ein Eintrag für den Linker.
Woher die verschiedenen Einstellungen in Eclipse kommen, weiß ich auch nicht. Ich nehme es einfach mal so hin. Unterschiede sind aber trotzdem noch da, für den Release wird ein HEX File erstellt.
Damit ich das richtig anpassen kann, die Frage (damit ich nicht lang rumsuchen muß): was wird gebraucht um, mit welchem Tolol, die Datei später hochzuladen, BIN oder HEX?
Danke schon mal und
vy 73, Hans
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 07. October 2015, 19:38:22
Du brauchst ein .bin - File.
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF4KD on 08. October 2015, 09:15:42
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DK2JD on 08. October 2015, 10:47:11
Hallo Andreas,
ich bekomme in Eclipse.Mars 32/64 eine für mich nicht zu zuordnenden Fehler:
"Orphaned configuration. No base extension cfg exists for ilg.gnuarmeclipse.managedbuild.cross.config.elf.release.563472857"
"Not accessible id=ilg.gnuarmeclipse...cross.GCCBuiltinSpecsDetector"
unter "Properties"-"Preprocessor Include Path, Macros etc.".
Jetzt habe ich herausgefunden das diese Referenz aus Deinem .Settings-File stammt.
Was hat diese für eine Aufgabe und wie könnte das unter Windows ersetzt werden?
73, Werner. |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 08. October 2015, 11:10:21
Die Settings wurden von meinem Eclipse selbst gebaut. Ihr Aufbau ist mir verschlossen, ich kann darüber keine Infos geben.
Aber ich kann bestätigen, dass diese Settings mit jedem Eclipse (egal ob Luna oder Mars), das auf einem Linux-System eingesetzt wird, auf Anhieb laufen.
::)
vy 73
Andreas |
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DL2FW on 09. February 2016, 10:08:45
Hallo Andreas,
kurze Frage:
habe vor kurzem Eclipse neu aufgesetzt (Ubuntu).
Build läuft auch einwandfrei im Masterbranch, nur wenn ich mit dem testing-branch arbeite gibt es Fehlermeldungen bei der Übersetzung der usb_otg.c mit der Meldung: 'USB_OTG_CORE_HANDLE' has no member named 'otg'....
Mach ich da was falsch?
vy73
Michael
|
Title: Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
Post by: DF8OE on 09. February 2016, 12:54:00
Gar nichts. In der Eclipse Konfiguration von "testing" ist noch ein kleiner Fehler. Die von Dir genannte Datei muss vom build ausgeschlossen werden.
Wenn die nächste Testing rauskommt, wird das weg sein.
vy 73
Andreas |
Title: Eclipse Windows & git
Post by: DD4WH on 26. February 2016, 14:49:17
ich versuche mit Eclipse Mars & Windows 8.1 an der firmware zu basteln.
Nun habe ich sehr große Probleme mit git.
Meine Vermutung ist, dass es deswegen so merkwürdige Reaktionen auf meinem Rechner gibt, weil ich mit der git shell versuche, git zu bedienen und GLEICHZEITIG Eclipse auch noch git managt (ohne dass ich das bemerke . . .)
1. Kann das sein?
2. Falls ja, wie kann ich bei Eclipse das automatische git - Management durch Eclipse selber völlig unterbinden?
Ein anderes Problem mit Eclipse habe ich, wenn ich eine andere Version der firmware, welche sich in einem anderen Ordner befindet, öffnen (also in den workspace importieren) will. Dann kann ich diese Version nicht importieren, da mir Eclipse sagt, dass ich schon eine anderes Projekt im workspace habe. Das ist sehr hartnäckig, zur Zeit kann ich daher andere Versionen nicht öffnen/bearbeiten
3. Daher meine Frage: Wie bekomme ich ein Projekt aus dem workspace and ein anderes hinein?
Vielen Dank schon mal im Voraus!
73 de Frank DD4WH
|
Title: Re:Eclipse Windows & git
Post by: DB4PLE on 26. February 2016, 15:58:35
Hallo Frank,
ich versuche mit Eclipse Mars & Windows 8.1 an der firmware zu basteln.
Nun habe ich sehr große Probleme mit git.
Meine Vermutung ist, dass es deswegen so merkwürdige Reaktionen auf meinem Rechner gibt, weil ich mit der git shell versuche, git zu bedienen und GLEICHZEITIG Eclipse auch noch git managt (ohne dass ich das bemerke . . .)
1. Kann das sein?
|
|
Eher nicht, ich habe damit keine Probleme, die kommen sich bei mir nicht in die Quere.
Ich habe sogar 3 Sachen gleichzeitig (naja, mehr oder minder). Eclipse mit Git, Git GUI und git auf der Kommandozeile.
2. Falls ja, wie kann ich bei Eclipse das automatische git - Management durch Eclipse selber völlig unterbinden?
|
|
Kannst Du natürlich machen, bringt aber nichts. Denn Eclipse macht erstmal selbst nichts mit git, es liest lediglich die Informationen von git. Erst wenn Du die "Team" Funktionen nutzt, dann greifst Du aktiv auf git zu und es wird auch mal was in Bezug auf git gemacht.
Auch wenn ich meistens Git GUI verwende, gibt es in Eclipse ein paar nette Sachen, zum Beispiel mal schnell die Historie einer Datei im Editor anschauen, geht da prima.
Ein anderes Problem mit Eclipse habe ich, wenn ich eine andere Version der firmware, welche sich in einem anderen Ordner befindet, öffnen (also in den workspace importieren) will. Dann kann ich diese Version nicht importieren, da mir Eclipse sagt, dass ich schon eine anderes Projekt im workspace habe. Das ist sehr hartnäckig, zur Zeit kann ich daher andere Versionen nicht öffnen/bearbeiten
3. Daher meine Frage: Wie bekomme ich ein Projekt aus dem workspace and ein anderes hinein?
|
|
Eclipse hat da sehr spezielle Sicht. Ein Projekt mit gleichem Namen duldet es nicht im gleichen Workspace. Du hast im Prinzip 2 Alternativen:
- Mach einen anderen Workspace (File->Switch Workspace->Other, Copy Settings nutzen). Nur so kann man stressfrei gleichzeitig 2 Projekt mit gleichem Namen bearbeiten. Du kannst dann sogar 2x Eclipse aufmachen, jeweils mit dem anderen Workspace.
Oder, du löschst das Projekt (Delete Project) im Project Explorer. Und wenn du das andere Projekt in das Workspace Verzeichnis importieren willst (muss man nicht), dann musst Du das Projekt auch aus dem Filesystem löschen lassen (Option bei Delete Project oder per Hand) .
Wenn Du nur auf einen anderen Branch im git schalten willst, dann musst Du nichts davon machen, einfach den Branch mit dem git Tool der Wahl wechseln.
73
Danilo
|
Title: Re:Eclipse Windows & git
Post by: DD4WH on 26. February 2016, 17:37:54
Hallo Danilo,
vielen Dank für Deine Antwort!
> Ich habe sogar 3 Sachen gleichzeitig (naja, mehr oder minder). Eclipse mit Git, >Git GUI und git auf der Kommandozeile.
Genau die drei Sachen habe ich hier auch am Laufen. Habe aber noch nicht richtig verstanden, wie Git GUI mit git commandozeile zusammen arbeitet.
>Kannst Du natürlich machen, bringt aber nichts. Denn Eclipse macht erstmal >selbst nichts mit git, es liest lediglich die Informationen von git. Erst wenn Du >die "Team" Funktionen nutzt, dann greifst Du aktiv auf git zu und es wird auch >mal was in Bezug auf git gemacht.
In eclipse sind bei mir unter Team -> git -> projects die Optionen "automatically share projects located in a git directory", "track each branchs imported projects and restore on checkout" sowie "automatically ignore derived resources by adding them to .gitignore" angekreuzelt. Das ist der default und hört sich für mich auf jeden Fall verdächtig an . . .
>Eclipse hat da sehr spezielle Sicht. Ein Projekt mit gleichem Namen duldet es >nicht im gleichen Workspace. Du hast im Prinzip 2 Alternativen:
>- Mach einen anderen Workspace (File->Switch Workspace->Other, Copy >Settings nutzen). Nur so kann man stressfrei gleichzeitig 2 Projekt mit gleichem >Namen bearbeiten. Du kannst dann sogar 2x Eclipse aufmachen, jeweils mit >dem anderen Workspace.
Vielen Dank, das hat sehr gut geklappt! Nun kann ich endlich wieder in Eclipse arbeiten ;-) Werden dann nur noch im git die branches schalten. Bin heute schon ein gutes Stück weitergekommen mit git, aber es fehlt noch ein bisschen, bis ich in die (hoffentlich) produktive Phase kommen kann . . .
73 de Frank
|
Title: Re:Eclipse Windows & git
Post by: DB4PLE on 26. February 2016, 20:35:08
Genau die drei Sachen habe ich hier auch am Laufen. Habe aber noch nicht richtig verstanden, wie Git GUI mit git commandozeile zusammen arbeitet.
|
|
Direkt arbeiten die garnicht zusammen. Ich benutze git auf der Kommandozeile für die "schwierigen" Dinge [Dinge die in Git GUI nicht direkt übers Menü gehen zum Beispil (git rebase ... , git stash ...]
In Git Gui (nach Rescan) mache ich die Commits, das ist bequem, da kann schön auswählen, welche Dateien man im Commit haben will und auch noch mal anschauen, was man so getan hat.
Und in Eclipse wird eigentlich nicht oft was gemacht.
So kommen die drei gut aus :-)
In eclipse sind bei mir unter Team -> git -> projects die Optionen "automatically share projects located in a git directory", "track each branchs imported projects and restore on checkout" sowie "automatically ignore derived resources by adding them to .gitignore" angekreuzelt. Das ist der default und hört sich für mich auf jeden Fall verdächtig an . . .
|
|
Ich habe Eclipse nach der Anleitung im Wiki installiert (eigentlich umgekehrt, aber egal).
Und keinerlei Einstellungen bei git angepasst (und so die gleichen Einstellungen wie Du).
Und jetzt sollte der produktiven Phase nichts mehr im Weg stehen.
73
Danilo
|
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|