Pages: [1] 2 3 ... 7 
|
 |
|
|
Author
|
Topic: Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen (Read 11411 times)
|
|
|
|
DC3AX
Interessent
noch länger dabei
 Offline
Posts: 186
Ich liebe dieses Forum!
|
 |
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #1 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
|
|
 Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DB6KT
OM_nicht_I40
Neuling
Offline
Posts: 17
Thomas - Hainichen - S44
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #2 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 -  )
73 de Tom
|
|
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #3 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
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DF8OE
Administrator
Offline
Posts: 6284
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #4 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
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #5 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
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DF4KD
schon länger dabei
Offline
Posts: 55
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #6 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
------------------------------
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6284
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #7 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...
|
| « Last Edit: 30. August 2015, 07:49:35 by DF8OE » |
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
DF4KD
schon länger dabei
Offline
Posts: 55
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #8 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
|
|
Logged
|
|
|
|
|
|
DF4KD
schon länger dabei
Offline
Posts: 55
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #10 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....
|
| « Last Edit: 30. August 2015, 10:54:53 by DF4KD » |
Logged
|
|
|
|
|
|
DF4KD
schon länger dabei
Offline
Posts: 55
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #12 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
|
|
Logged
|
|
|
|
|
|
|
|
Pages: [1] 2 3 ... 7 
|
|
|
|
|
|
|
