Author
|
Topic: Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen (Read 10271 times)
|
|
DF8OE
Administrator
 Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
 
|
 |
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #30 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
|
| « Last Edit: 05. September 2015, 07:55:40 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! <<<<
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #31 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)) * 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
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #32 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 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
|
|
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! <<<<
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #33 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
|
|
|
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #35 on: 07. September 2015, 12:42:27 »
|
|
@Harald
Sowas lässt mi keine Ruhe 
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  Ich denke, wir können alle zusammen mächtig vorankommen...
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! <<<<
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #36 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
|
|
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 #37 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.
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #39 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
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #40 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.
|
| « Last Edit: 07. September 2015, 16:27:34 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! <<<<
|
|
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #42 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
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #43 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
|
|
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! <<<<
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #44 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
|
|
Logged
|
|
|
|
|
|
|
Makefile.txt
