Title: Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: DF8OE on 05. September 2015, 10:22:16
Die libm.a kann auch vom arm-none-eabi/newlib/armv7e-m/fpu/ genommen werden.
Wie Harald schon vermutet hat, stammt die andere lib aus einem Keil-Paket. Das erklärt auch, warum Clint in der Yahoo-NG immer etwas von "Keil optimiertem Code" geredet hat - ich aber nicht nachvollziehen konnte, was er meint.
Wenn man sich die Definitionsdateien in cmsis anschaut, dann tragen sie Zeitstempel von 2010 bzw. 2011. Zu welcher Version die lib gehört, konnte ich nich nicht rausfinden. Aber es scheint nicht die neueste zu sein. Hat jemand eine Idee, zu welcher Version die gehört?
Ausserdem ist mir aufgefallen, dass einige Header-Files in cmsis sich auf big endian beziehen, die Bibliothek aber ausdrücklich little endian ist ???
vy 73
Andreas |
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: hbtron on 09. September 2015, 19:17:00
Hallo Andreas,
ich habe mal mich bei arm.com angemeldet und durfte die neueste Version der libarm_cortexM4lf_math.a samt Quellen und Doku herunterladen (44 MByte).
Die Funktionen sind zwar 2012 optimiert worden (jetzt Version 1.1.0), wenn ich aber diese Lib samt den dazugehörigen Includes in das mchf-Projekt kopiere und (mit meinem/deinem) Makefile übersetze, bekomme ich ein wesentlich größeres Binary.
Ich hab mal die .maps ge-'diffed' und herausgefunden, dass in den .rodata (Konstanten im Flash) wesentlich größere Tabellen erzeugt werden. Die Codegrößen sind eher kleiner geworden.
Ich würde Dir das mchf-eclipse zwar gerne schicken, aber es sind 4.78 MByte gezippt. Ich weiß - eigentlich sollte ich mir erst ein Buch über git kaufen - aber das fällt mir mit meinen 66 Jahren sehr schwer und bei meinem Abitur war das noch nicht gefragt... Ausser 'git clone' ist bei mir nix im Archiv :-\
vy 73,
Harald DL4SAI
PS: wegen Bootloader (.dfu): geht auch unter Linux (sourceforge: dfu-utils) . Morgen bekomme ich ein Discovery-Board, dann kann ich herumspielen. Das mit dem 'bricken' ist mit STM32F4 nicht mehr die große Gefahr, da man die Bootloader nicht mehr löschen kann. Allerdings sollte man die Startadresse VOR dem 3.Bier eintippen...
|
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: DF8OE on 10. September 2015, 05:52:29
Du arbeitest unter Linux, ist das richtig?? Dann könnte ich mal einen Crashkurs in git starten... Du wärst bei den "Mitarbeitern" sofort dabei 8) Und wenn Du die Bash kannst, dann kannst Du auch git. Es ist die Denkweise, die man erstmal "verdauen" muß...
vy 73
Andreas |
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: hbtron on 10. September 2015, 09:48:08
Hallo Andreas,
Ein Grundkurs in git wäre schon nett, aber den gibt es aber auch schon. Da muss man mit Copy and paste
durch.
Ich denke, da der Weg vom Kopf durch die Tastatur und zurück vom Bildschirm durch die Augen wieder in den Kopf länger ist, als nur vom Bildschirm in den Kopf, würde bei try and fail mehr hängen bleiben.
Und ich muss die Zusammenhänge verstehen, sonst bleibt wieder nur noch 'git clone' hängen...
achso ja, nur Linux (auch zum Geld verdienen) ! Wer meint, dass er Windows braucht, ist selber schuld -
naja, es sei denn, er muss unbedingt an der Börse zocken...
vx 73,
Harald
|
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: DC3AX on 24. September 2015, 08:03:44
Hi!
Also ich habe mir mal meine Toolchains angesehen und folgendes festgestellt:
Ubuntu standard arm-gcc installiert wo immer Ubuntu Pakete auch gerade hin schiebt:
~$ arm-linux-gnueabi-gcc -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/lto-wrapper
Ziel: arm-linux-gnueabi
[...]
gcc-Version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1)
Linaro Bare-Metal Toolchain, von denen ich aktuell 15 verschiedene parallel in /opt/ installiert habe:
~$ /opt/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/gcc-arm-none-eabi-4_9-2015q1/bin/../lib/gcc/arm-none-eabi/4.9.3/lto-wrapper
Target: arm-none-eabi
[...]
gcc version 4.9.3 20150303 (release) [ARM/embedded-4_9-branch revision 221220] (GNU Tools for ARM Embedded Processors)
Wie man an den Variablen COLLECT_GCC und COLLECT_LTO_WRAPPER erkennen kann, wissen diese Toolchains durchaus selbst, wo sie gerade installiert sind.
Daher habe ich das etwas umständliche LIB dingens in dem Makefile mal ausgeklammert. Dafür habe ich bei mir lokal mal den Quasi-Standard implementiert:
CROSS_COMPILE enthält den Link zur Toolchain also wie beim Kernel:
export CROSS_COMPILE=/opt/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-
CC und andere Makefile Variablen werden dann aus dieser gebildet:
CC := $(CROSS_COMPILE)gcc
LD := $(CROSS_COMPILE)ld
dann
~$: make clean && make
Das ganz wirft eine mchf.bin aus, die bei mir augenscheinlich gut funktioniert. Ich gehe daher davon aus, dass diese künstliche Verstrickung zur math lib für hard-float garnicht nötig ist. Ich habe diese Änderungen noch nicht eingecheckt, sondern teste erst mal noch etwas. Abgesehen davon, kann man in dem Makefile (dessen Anfangsbuchstaben eigentlich und für linux untypisch) groß geschrieben werden sollte, noch ein paar Aufräumarbeiten leisten :)
Leider geht die Hardware immer noch nicht, aber das ist ein anderer Thread und hält einen ja nicht von der Software ab.
73!
Ulrich |
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: DF8OE on 24. September 2015, 08:37:55
Das makefile ist keineswegs optimal - das ist mir bewusst. Nur läuft es schon mal - was wichtig ist.
Wenn Du da Verbesserungen durchführen kannst und möchtest --> gerne...
Ich habe noch anzumerken, dass Chris bei seinen Kits den STM mit 512KB verschickt, ich in der Projektgruppe aber den 30 Cent teureren mit 1MB verwendet habe. Wenn die Kompilate wesentlich größer werden, kann das für die Nutzer der kleineren STMs zu einem Problem werden... Ich habe noch keine Messungen durchgeführt, ob die grösseren Binaries mit der neueren Lib irgendwelche Vorteile haben.
Auch würde mich interessieren, ob irgendwer das makefile mit cygwin etc. unter Windows mal probiert hat.
vy 73
Andreas |
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: DC3AX on 24. September 2015, 08:55:56
Hi!
kleiner Nachtrag: Im Makefile sorgt die Zeile
CROSS_COMPILE ?= arm-none-eabi-
dafür, dass es ein default bekommt.
Macht man unter Linux vorher ein export CROSS_COMPILE="opt/bla/blubb..." dann wird eben dieses genutzt.
Bzgl des Flash Speichers mache mich mir zunächst mal keine wirklichen Sorgen. Der Code birgt dermaßen viele Optimierungsmöglichkeiten, dass man sicherlich auch auf den 256kB Chip ausweichen könnte...
Alleine die Frequenzberechnung in double... Merke: Ein Fließkomme schiebt man sich dahin, wo man es gerade braucht... Am besten irgendwo ganz rechts neben den Monitor, aber lasst es nicht in die Kaffeetasse fallen.
73!
Ulrich |
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: DF8OE on 24. September 2015, 09:16:29
Was die Optimierungsmöglichkeiten angeht sprichst Du mir aus der Seele. In der Yahoo-NG habe ich das mal angesprochen, und Clint hat in einem 20cm langen Beitrag geantwortet, warum er keine Optimierungsmöglichkeiten sieht.
Ich hatte vor einem halben Jahr mal angekündigt, dass ich den Touchscreen aktivieren will. Großes Gerede, warum das in diesem Gerät niemals gehen kann. Als Antwort habe ich ein Youtube-Video vom ersten Ergebnis erstellt... Vor 10 Tagen habe ich argumentiert, dass der SPI-Modus für das LCD sinnvoll ist, weil man dadruch 16 freie GPIOs auf einen Schlag erhält. Antwort kam, warum das nicht sinnvoll ist bzw. abzuraten ist. Mein mcHF arbeitet seit 10 Tagen mit SPI-LCD - ich vermisse keine Geschwindigkeit und habe auch keine HF-Störungen. Aber sicher könnte man auch an der Geschwindigkeit noch was optimieren - ich trau mich schon gar nicht mehr, das in die Yahoo-Group zu schreiben...
Gestern sagte Clint, dass man sehr gut bedenken sollte, wofür man den derzeit einzigen freien GPIO ( der zum ehemaligen Dämpfungssteller für RX) verwenden soll. Was für Widersprüche!!!
Mein Problem ist:
der Tag hat einfach zu wenige Stunden für all das, was ich machen muss und machen möchte :P
vy 73
Andreas |
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: DC3AX on 24. September 2015, 15:01:43
Also ich habe mal die ui_si570.c zerlegt...
Also ich möchte auf keinen Fall irgend etwas nieder-reden oder Abwerten! Versteht mich nicht falsch, das Ding an sich ist eine große Leistung... Aber der Code...
In zwei Worten: Kopf -> Tisch
Ein "uchar function(blabla)" ist alleine deswegen doof, weil der gcc immer ein Register (R0 oder R1) als 1. Übergabe-Parameter verwendet und dieses auch gleich wieder als Result der Funktion benutzt.
Eine Funktion "void fkt( int data)" benötigt genau so viel Speicher, wie eine "int fkt( int data)".
Ergo kann man ganz komfortabel folgende Regel beachten:
Positive return values inkl. 0 sind gut, negative sind schlecht.
Aber ich befürchte, dass ein "uchar fkt( uchar)" eine ganze Menge Overhead produziert, der die Bitbreite in dem oben genannten Register laufend korrigiert werden muss.
Der Codeing-Style ist der, den ich von vielen Studienabgängern zu sehen bekommen habe. (Grüße an Oliver und David :) ) Zum Glück konnte ich die bisher immer davon überzeugen, dass es stdint gibt und dass man bits schubst und nicht hoch-multipliziert. Und Funktionen die mehr als 2 Seiten lang sind kann man aufteilen.
Man schreibt keinen Treiber, der zwei Bausteine steuert...
Ach ja... Was solls...
ich habe mal die ui_si570.c zerlegt in eine
mcp9801.c <- initialisiert und fragt den Temperatur-Chip ab.
si570.c <- initialisiert und steuert den SI570
lo.c <- nutzt die beiden obigen Treiber und die Korrektur-Tabelle um den LO zu stellen.
Grundsätzlich wäre es natürlich sehr geschickt und lesbar, wenn man die Header Dateien in ein include Verzeichnis pro Block verschieben würde. Dann wäre auch das Makefile deutlich lesbarer.
Irgendwer hat auch den STM32 code von ST einfach in CMSIS gepackt, das letztere ist aber von ARM und überschneidet sich eigentlich nur in 2 Dateien...
Ich mache mal weiter, bis es ein wenig funktioniert. Aktuell compiliert es natürlich noch nicht durch. Vor allem muss ich mir noch mal die Mathematik hinter dem SI570 zu Gemüte führen, float und long double double... Das sehe ich eher bei Burger King als im mcHF...
73!
Ulrich
|
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: DF8OE on 24. September 2015, 15:58:18
Also ich will nicht für mich in Anspruch nehmen, dass ich der "Programmierer vor dem Herrn" bin. Jeder hat seine "Klaue" - auch beim Programmieren. Und jeder hat eben eine andere Klaue :) Die Firmware ist gewachsen. Angefangen (und damit den Grundstein gelegt hat Chris. Clint hat dann darauf aufgebaut - und schon waren zwei Stile vermischt...
Mir sind da auch schon Dinge aufgefallen, die zumindest was die Codegröße angeht ein Otimierungspotential von mindestens 50% hatten.
Und mir sind Dinge aufgefallen, die mir eine krause Stirn gezaubert haben..
Zum Beispiel:
Es gibt in der audio_driver.c zum Beispiel zwei Variablendeklarationen "test_a" und "test_c". Diese werden zurecht mit Warnings belegt - da die Variablen niemals benutzt werden. Also habe ich die Deklarationen mal ausdokumentiert. Die Warnings sind dann weg und der Code ist ein wenig kleiner. Aber - und das ist der Knaller: Das erzeugte Binary läuft dann nicht mehr!!!
Schon der Kommentar dieser Zeile ist "very strange":
static int16_t test_a[5000]; // grab a large chunk of RAM - for testing, and to prevent "memory leak" anomalies (kludgy work-around - problem to be solved!)
Umphhhffff...... Was ist das?? Wer kommt auf so eine Idee? Und warum?
Aufräumen ist definitiv eine gute Idee. Ich würde das Hauptaugenmerk auf Geschwindigkeitsoptimierungen legen. Klar: wenn man (wie im Falle der Bandumschaltungen) die für jedes Band einzeln erstellte Routine durch eine einzige Funktion mit Übergabeparametern ersetzt, spart man vermutlich KB an Code und verliert 0.05% Performance. Hier wäre der Codegrößenvorteil der Gewinner. Wie immer: abwägen :)
BTW:
Hast Du mal probiert, ob Du in meinem Github mergen kannst/darfst? Im master-branch nicht, den habe ich gesperrt (möchte ja gerne Clint mit ins Boot holen), aber der devel-branch sollte offen sein...
vy 73
Andreas |
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: dl2ki on 24. September 2015, 17:37:56
Hallo,
ich lese hier und auch in der Yahoo-Gruppe seit geraumer Zeit mit. Den mcHF wollen wir im OV mit einigen Leuten aufbauen. Die Kits sind morgen abholbereit und es wird so langsam konkret los gehen.
Von daher bin ich an Informationen "aller Art" zu dem Projekt interessiert, und freue mich, das es bei euch im OV ein derartigen Engagement gibt. Allen Respekt! Bei Andreas hat man den Eindruck, dass die Projektarbeit inzwischen hauptberuflich ausgeübt wird :-).
Bezüglich der Yahoo-Gruppe denke ich, das es eine vielzahl Leute gibt, die schnelle Veränderungen nicht mitgehen wollen, oder auch nicht können. Dieses Phänomän gibt es aber nicht nur hier. Wir leben inzwischen in einer Welt, die in fast allen Lebensbereichen andauernde Veränderung mit sich bringt. Ich denke mal man muss die Veränderungsmüdigkeit" vieler eher in der Summe und unter diesem Aspekt betrachten.
Von daher könnte es sein, das Euer (plötzliches) starkes Engagement dort eher kontraproduktiv gesehen wird. Zudem scheint mir in der Gruppe ein aktiver Moderator zu fehlen, der die Beiträge sortiert, bewertet und vor allen Dingen in zentralen "Dokumenten" zusammenfasst. Derzeit macht die Gruppe eher den Eindruck eines "Gemischtwarenladens".
Wenn dem so sein sollte, wäre es wahrscheinlich konsequenter, die Entwicklung zu trennen, und die Firmware in
einem Fork weiter zu entwickeln. Es scheint auch so zu sein, dass bei Euch das Know-How für eine auf dem mcHF aufbauenden, neuen Hardware vorhanden ist.
Wesentlich scheint mir zu sein, das die Weiterentwicklung der Firmware moderat erfolgt, und zunächst keine Hardwareänderungen vorausgesetzt werden. Ich denke hier z.B. mal an das Stichwort "Firmwareoptimierung" aus dem Beitrag vorab. Es könnten sich dort dann Firmwareentwickler einbringen, die aber auch jemand koordinieren muss. Ob Clint es dann ebenfalls tut ist dann, ohne äußeren Druck, ihm überlassen.
Diese Vorgehen würde diejenigen, die die Geschwindigkeit eben nicht mitgehen können, oder die vielleicht nicht dauernd an ihren Platinen herumlöten wollen, möglicherweise den Anreiz bieten, sich der künftigen Firmware des OV-I40 zu bedienen.
Man muss die Leute langsam heranholen, und des gibt viele, die mit dem Gerät auch so zufrieden sind und es eben nur
benutzen wollen. Auch die solle man dazu holen. Das "Feld" wird sich dann nach einiger Zeit sortieren, wenn die neue Firmware eben für viele interessanter ist, als die bisherige.
Unabhängig davon kann man (im kleineren Kreis), ohne sich an vielen Baustellen zu verzetteln, auch an generell neuen
Lösungen arbeiten. Diese Arbeit würde dann in einem zweiten "Entwicklungszweig" laufen, der dann auch nicht so explizit vorab "beworben" werden muss.
Die in dem FA-Beitrag aufgeführten, "geplanten Erwiterungen", wie z.B.
- Erschließung der Bänder 2200 m, 630 m, 160 m, 6 m und 4 m mit „Huckepack-platine",
- Verbesserung der Senderendstufe hinsichtlich Ausgangsleistung und Konzept,
- Aktivierung der Eingabefunktionen des Touch-Displays,
- diverse Firmware-Erweiterungen,
- Eigenentwicklung einer zusätzlichen HF-Platine um die Bänder 2 m, 70 cm und 23 cm zu erfassen
können sowohl "begeisten", als auch "abschrecken".
Mit einem derartigen Vorgehen wären die "konservativen" und die "progressiven" Leute gleichermaßen bedient. Zudem würde sicher etwas "Druck aus dem Kessel" genommen.
Vielleicht sind ja in meinem Beitrag einige brauchbare Gedanken enthalten um das Projekt "mcHF" zu ordnen.
73, Wolfgang (DL2KI)
P.S. Der Inhalt des Beitrages passt vielleicht nicht in diesen Thread, wurde aber von den vorhergehnden Beiträgen inspiriert. Von daher ggf. einfach nach "allgemeines" verschieben.
|
Title: Re:Firmware-Bibliotheken libm.a und libarm_cortexM4lf_math.a
Post by: DF8OE on 24. September 2015, 18:04:51
Hallo Wolfgang,
Deine Gedanken passen schon in das Thema "mcHF".
Und es wird so passieren: Es wird einen Fork geben. Dann können die zufrieden sein, die keine oder nicht so große Änderungen wollen, und die, die endlich ein Projekt gefunden haben, in dem sie richtig aufgehen, können das auch.
"Open Source" hat schon immer das Potential gehabt über sich hinauszuwachsen - und das sollte sie auch tun. Man kann dran teilnehmen - aber man muß es nicht. Aber wenn man nicht dran teilnehmen will, sollte man denen nicht im Weg rumstehen, die weiter wollen :)
Dementsprechend wird eines der ersten Themen sein, den proprietären Bootloader rauszuschmeissen. Denn den zu kopieren wäre ein echtes Urheberrechtsporblem. Und neue Platinen routen mit den eingepflegten Änderungen - so schwierig ist das auch nicht... Dann gibt es eben ZWEI mcHF - ist doch kein Problem ::)
vy 73
Andreas |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|