Hallo, ich beabsichtige von meinem doch sehr betagten 8051 auf ARM Cortex umzusteigen, die Entwicklung ging mit dem Keil Compiler und Brendes Emulator eigentlich recht komfortabel aber ich bin jetzt doch auf seine (8051) Grenzen gestoßen. (Touch Screen SD Card etc.) Ich habe mich jetzt mal nach einer komfortablen und vor allem bezahlbaren Entwicklungsumgebung umgeschaut und bin auf den MikroElektronika mikroC PRO for ARM http://www.mikroe.com/mikroc/arm/ gestoßen der in Deutschland vertrieben für 252.-€ von http://www.tigal.com/lang/DE vertrieben wird. Die haben auch genau die „Platine“ die mir so vorschwebt (mikromedia for Stellaris/STM32 M3/STM32 M4. Meine Frage: hat jemand von Euch diesen Compiler in Gebrauch und kann dazu etwas sagen? Ich setze ihn nur für private zwecke ein. Gruß Jürgen
:
Verschoben durch Admin
Ach, die haben auch ein Mikro-Pascal im Angebot. Nett, aber kann auch keine SVC's. Mein Rat: Lade dir zu allererst die Demoversion des Keil für Arm herunter. Die ist erstmal gut für 32 K Code (glaub ich..) und es ist ein fähiger Compiler, mit dem man die Features der Hardware auch wirklich benutzen kann. Du kannst ja später dir ne Demo eines anderen Compilers besorgen und mal gegen den dir dann schon bekannten Keil testen. Häufig genug stecken bei anderen Angeboten nur eine IDE plus GCC dahinter. Ich hatte bei der "Lernbetty" hier im Forum diverse Grrrr-Momente mit dem GCC erlebt: keine Pragmas, umständliche Interrupt-Deklarationen, überhaupt keine SVC's (!!!), undokumentierte Seltsamkeiten beim Linken, kurzum mein Rat: Lern als Maßstab erstmal die originalen ARM-Tools kennen und teste dann das, was du dir evtl. kaufen willst. Nebenbei: Es ist ja nicht mehr lange hin bis zur nächsten Embedded, wo man sowas auch mal aus der Nähe sehen kann vor dem Kauf. W.S.
eigendlich wollte ich keine odyssee starten und diverse Compiler "durchprobieren". Selbst wenn der Keil mit Abstand der beste ist wäre für mich einfach zu teuer. ich wollte nur wissen ob jemand besagten Compiler verwendet oder schon benutzt hat und einigermassen einstufen kann in brauchbar oder Finger weg. Jürgen
Wenn du kein C++ benötigst dann würde ich CooCox verwenden. http://www.coocox.org/ Das läuft so outofthebox und ist unlimitiert zu verwenden. C++ wird aber nicht supported. Keil fällt als Privatanwender sowieso flach, ausser man hat einen scheissenden Goldesel im Stall stehen. Und 32kB Code zu erreichen ist bei den ARMs nun auch keine Utopie, v.a. wenn man ein OS und irgendwelche Libraries verwendet. Wenn man sich da einen Compiler aussucht, welcher dieses 32kB Limit hat, dann sollte man schon einen nehmen, bei welchem das Upgrade auf die Vollversion realistisch ist. Den von dir genannten Compiler kenne ich nicht, ich würde dir aber schon empfehlen mal 2-3 verschiedene Compiler bzw. IDEs auszuprobieren. Wie gut die Compiler sind, kann man auf die schnelle sowieso nicht herausfinden, aber ob man mit der IDE klarkommt merkt man schon eher http://www.mikrocontroller.net/articles/STM32 hat noch andere IDEs aufgeführt. Die Keil IDE z.B. ist total unkomfortabel und auf nem Stand von (gefühlt) 1990. Andere (Eclipse-basierte) IDEs bieten da deutlich mehr.
Nicht kommerziell eingesetzt ist Rowley Crossworks auch nicht uninteressant. http://www.rowley.co.uk/arm/index.htm Die "persönliche" Lizenz kostet 150 USD. Crossworks läuft unter Windows, Linux und OS X und neuerdings auch auf Linux/Arm
Ja, Crossworks ist nicht schlecht. Leider aber etwas eigen. Hier ist zwar auch der gcc drunter aber eben nur anders. Programme die mit dem gnu-arm-tool gcc erstellt werden lassen sich problemlos in Keil, LpcXresso, Coocox (etwas umständlich) debuggen. Der verwendete Startupcode ist dafür nicht relevant. Das ist bei Crossworks anders. Wenn man nicht den Crossworks-Startupcode verwendet und deren Libs und Linkerscripts, enden die meisten Versuche in Hardfaults. Jedenfalls beim LPC1769. Ich muss wirklich sagen leider, weil der Debugger sonst wirklich sehr gut ist. Wenn man als Ziel ein Programm hat was nur aus freien Bestandteilen besteht, hat man somit ein Problem. Für mich inakzeptabel.
A. B. schrieb: > Die Keil IDE z.B. ist total unkomfortabel und auf nem Stand von > (gefühlt) 1990. Andere (Eclipse-basierte) IDEs bieten da deutlich mehr. Du findest Eclipse komfortabel? Was daran jetzt genau? Die Startzeiten? Das sonderbare Workspace-Konzept in dem man nicht einfach "mal eben" ein Projekt oeffnen kann? Oder sind es die durch die Bank unfähigen Debugger-Plugins für MCUs die dir das Leben erleichtern?
moin moin, zur Zeit nutze ich das oben angegebene mikroPascal. Gut: - Project aufmachen, Typ einstellen oder - Projectdatei starten, compelieren, flashen..fertig. - kein handtieren mit make, script usw. Schlecht: - Die IDE hat einige ShortCuts die anders belegt sind, als z.B in Delphi. - Der Preis. - keinen direkten Sourcecodes der Libs. Mit Gruß Pieter
>Du findest Eclipse komfortabel Ja, komfortables Codebrowsing, konfigurierbarer Editor, Syntax- und Spelling-Check und noch so vieles.. >Die Startzeiten? Dauert nicht länger als andere IDEs; AVR-Studio, Visual-Studio, Windriver-Workbench, IAR, Keil-uVision etc. brauchen mindestens so lange! >nicht einfach "mal eben" ein Projekt oeffnen kann? Geht doch prima mit Eclipse! Habe alle Projekte aufgelistet im Project Explorer, kann kann auch mehrere Projekte parallel nebeneinader geöffnet haben. Und wenn ich ein neues Projekt beginne kopiere ich einfach ein ähnliches, bereits bestehendes Projekt und benenne es um! Dauert 30 Sekunden! >Oder sind es die durch die Bank unfähigen Debugger-Plugins Einmal richtig eingerichtet läuft der GDB aalglatt
Mgast schrieb: > Du findest Eclipse komfortabel? Was daran jetzt genau? Die Startzeiten? > Das sonderbare Workspace-Konzept in dem man nicht einfach "mal eben" ein > Projekt oeffnen kann? Oder sind es die durch die Bank unfähigen > Debugger-Plugins für MCUs die dir das Leben erleichtern? Ich behaupte nicht, das Eclipse eine super Umgebung für die Mikrocontroller Entwicklung ist(out of the box schon gar nicht...siehe eben die Plugins usw)...ich bin z.B. daran gescheitert das mit einem Codesourcery Compiler zum laufen zu kriegen. Aber vom Editor her ist Eclipse dem von Keil 100mal überlegen.
PS: Bezgl. Startzeiten: das Eclipse länger braucht zum Laden als der VI oder Emacs stimmt.ok! Aber auf nem einigermassen aktuellen System ist das absolut erträglich. Ich habe nicht den Anspruch an eine aktuelle Entwicklungsumgebung, das sie auf nem 486 Grabbelkisten PC blitzschnell startet, was manch einer hier ja anscheinend schon erwartet(siehe auch andere Threads bzgl. Atmel Studio usw.) Ich weiss auch nicht gar nicht genau worauf die ganzen anderen IDEs basieren, aber CooCox benutzt zum Beispiel Eclipse.
A. B. schrieb: > Ich habe nicht den Anspruch an eine aktuelle Entwicklungsumgebung, das > sie auf nem 486 Grabbelkisten PC blitzschnell startet Ist eben Java - und Java IST eben langsam im Vergleich zu jeder im Maschinencode vorliegenden IDE. Geht es euch hier eigentlich um Oberflächensachen, wie bunt, wie in Projekte,Workspaces usw. organisiert? Ich weiß ja, daß ich mit meiner Art, ohne IDE und ohne Debugger zu arbeiten, hier der Exot bin und daß die meisten erstmal drauflos daddeln wollen und sich dann davon überraschen lassen müssen, was zum Schluß an Code herauskommt. OK, beim GCC ist das erwiesenermaßen auch bitter nötig. Aber mir ging es erstmal um die Qualitäten des Compilers und nicht um irgendwelche IDE's. Und ich glaube, der Jürgen wollte genau DAS auch zu allererst wissen. W.S.
Übertreibts mal nicht mit dem Schlechtmachen des gcc. Die vielen verschiedenen gcc die mit den IDEs kommen und den freien wie https://launchpad.net/gcc-arm-embedded unterscheiden sich kaum. Die meisten Unterschiede liegen in Anpassungen der newlib. Wenn man die Funktionen, die aus der newlib kommen und immer mal wieder zu Problemen führen (printf, malloc u.s.w.), durch eigene angepasste Implementationen ersetzt, ist man die Sorgen los. Ich habe bisher noch keinen Fehler im gcc gefunden der definitiv ein Compiler-Fehler war. Ich entwickle und debugge zu 90% unter VC. Das was dabei rauskommt, ist aber zu 90% mit dem gcc unter Linux übersetzt und läuft auch da. Hin und wieder mag der gcc mal was nicht was der VC frisst und umgekehrt. Aber wenn der Code unter beiden Compilern übersetzt ist, läuft er auch auf beiden. Ich wüsste nicht was ein Compiler so viel besser machen kann wie der gcc, dass es einen 4-5stelligen Betrag rechtfertigt. Das lässt sich auch auf den embedded Bereich übertragen. Ob der Keil-Compiler eventuell 10% kleineren Code macht oder nicht, will ich nicht mal wissen. Das größte Optimierungspotential liegt bei einem selbst. Sobald es aber um Assembler oder Assemblercode in C-Dateien geht, ist man mit Keil auf einer einsamen Straße. Das ist nur zu sich selbst kompatibel. Deswegen benutze ich den Keil zwar zum Debuggen, aber nur in Verbindung mit gcc. (und makefiles).
temp schrieb: > Ob der Keil-Compiler eventuell 10% > kleineren Code macht oder nicht, Ja, das willst du nach eigenem Bekunden nicht wissen. Ich aber. Mir haben die kürzlich gesammelten Erfahrungen mit der Lernbetty gereicht, um im Nachhinein die Anschaffung des Keils als genau richtige Entscheidung zu bestätigen. Und: unter den professionellen Tools ist er noch einer der billigeren. Guck auf der nächsten Embedded mal zu IAR oder Green Hills und Konsorten oder zu ARM selber. Das Schreiben der gesamten Lernbetty-Quellen und das Ausprobieren derselben hat mich nicht mal halb soviel Zeit gekostet wie den GCC zum Laufen zu bringen. Wenn ich das auf die Dinge umrechne, die ich beruflich mache, dann hat sich die Anschaffung des Keils schon beim allerersten Projekt voll und ganz bezahlt gemacht. Aber mal zum GCC selber: Erstmal stören die elenden Probleme, die man bei GCC mit dem Linken kriegt und die man auch durch Lesen der Doku nicht in den Griff kriegt - stattdessen ist Probieren angesagt. Stichwort: fälschlich vom Linker eingesetzte Stubs. Zweitens die diversen Dinge, die der GCC eben überhaupt nicht kann und für die man Workarounds braucht, die natürlich wieder Code+Zeit kosten. Drittens die Unterschiede im erzeugten Code. Der Code vom GCC ist lausig im Vergleich zu dem vom ARM. Bei der Lernbetty hab ich fast Faktor 1.5 feststellen müssen. Also mal im Klartext: Das, was der ARM in einen 32 K großen Codespeicher hineinbekommt, erfordert beim GCC fast 48 K. Das ist ne Menge Holz und es macht schon nen preislichen Unterschied, ob man nen 32K Flash Controller einsetzen kann oder auf nen >=64K Flash Controller zurückgreifen muß, den man obendrein mit Faktor 1.5 schneller takten muß für die gleiche Funktionalität. Und nochwas: temp schrieb: > Sobald es aber um > Assembler oder Assemblercode in C-Dateien geht,... ...erschlage ich jeden mit nem nassen Feudel, der auch nur ansatzweise so etwas zu praktizieren beabsichtigt. Assembler gehört in ne separate Assemblerquelle und nicht in ne C-Quelle. Wohlgemerkt, ich hab nix gegen den GCC, aber in seiner arm-none-eabi Ausführung ist er ein recht mäßiger Compiler, der viel Streß verursacht und nicht wirklich gut an die Zielarchitektur angepaßt ist. Im Bastlerumfeld hat niemand was dagegen, aber ihn beruflich einsetzen zu wollen, hätte ich ernste Bedenken. W.S.
W.S. schrieb: > Drittens die Unterschiede im erzeugten Code. Der Code vom GCC ist lausig > im Vergleich zu dem vom ARM. Bei der Lernbetty hab ich fast Faktor 1.5 > feststellen müssen. Stell mal 2 Projekte zum Vergleich hier rein die diesen Unterschied beweisen. Bis dahin: Märchen!!!
Ich würde mir zumindest mal die Tools (Eclipse, gcc + Eigenentwicklungen) und Cortex-M3 von SiLabs ansehen... http://www.silabs.com/products/mcu/Pages/32-bit-mcu-software.aspx http://www.silabs.com/products/mcu/Pages/32-bit-microcontrollers.aspx
Oftmals werden bei solchen Grössenvergleichen Libs mitgerechnet. Und die können sehr unterschiedlich ausfallen, insbesondere wenn man bei gcc die newlib erwischt.
Keil MDK-ARM Pro mit Ulink Pro ... Wer halt einen Esel hat. Ich benutz den in der Firma, gibt meiner Meinung nach nichts besseres. Und jetzt soll bald die neue Version mit besserem Editor rauskommen juhuu
>Wohlgemerkt, ich hab nix gegen den GCC, aber in seiner arm-none-eabi >Ausführung ist er ein recht mäßiger Compiler, der viel Streß verursacht >und nicht wirklich gut an die Zielarchitektur angepaßt ist. Im >Bastlerumfeld hat niemand was dagegen, aber ihn beruflich einsetzen zu >wollen, hätte ich ernste Bedenken. > >W.S. An Deiner Stelle würde ich mit meiner Unwissenheit nicht bei jeder unpassenden Gelegenheit hausieren gehen. Das ist nicht erst langsam peinlich.
A. B. schrieb: > ...ich bin z.B. daran gescheitert das mit einem > Codesourcery Compiler zum laufen zu kriegen. Sollte mittels: http://gnuarmeclipse.livius.net plugin gehen. Damit Yagarto einzurichten war jedenfalls einfacher als die Beschreibung von Yagarto selbst. Ansonsten find ich Rowley ziemlich gut, zumal die meinen Segger J-Link direkt unterstützen. Insbesondere auch Databreakpoints, die gehen via GDB-Server nicht (zumindest hab ich es noch nicht hinbekommen).
Sven S. schrieb: > Und jetzt soll bald die neue Version mit besserem Editor rauskommen > juhuu Welche Version benutzt du und bei welcher Version soll ein neuer Editor kommen? Also bei der 4.50 war das glaub ich, da haben sie schon irgendeien neuen Editor-Core verwendet...aber die Änderungen sind ja eher...marginal.
W.S. schrieb: > Ich weiß ja, daß ich mit meiner Art, ohne IDE und ohne Debugger zu > arbeiten, hier der Exot bin und daß die meisten erstmal drauflos daddeln > wollen und sich dann davon überraschen lassen müssen, was zum Schluß an > Code herauskommt. OK, beim GCC ist das erwiesenermaßen auch bitter > nötig. > > Aber mir ging es erstmal um die Qualitäten des Compilers und nicht um > irgendwelche IDE's. Und ich glaube, der Jürgen wollte genau DAS auch zu > allererst wissen. Nunja...wenn du auf anhieb so Fehlerfreien Code produzierst...dann Respekt. Ich jedenfalls möchte einen funktionierenden Debugger nicht mehr missen...gerade auf embedded Ebene wo man früher nur mit Oszi und irgendwelchen Status LEDs debuggen konnte(zumindest kenne ich das so von PsOC1, da das dortige Debugsystem überhaupt nicht funktioniert hat) und bei anderen Controllern wars ja auch nicht anders. Und was hat bitte eine funktionierende & komfortable IDE Oberfläche mit dem typischen affigen Totschlagargument "muss wohl alles klicki&bunti sein" zu tun? Gerade wenn man zu zweit oder noch mehreren an einem Projekt arbeitet, möchte ich Projekteinstellungen usw nicht missen. Soll da jeder mit seinem eigenen Sammelsurium aus Makefiles und sonstigem rumgewurstel loslegen? Ich maße mir nicht an die Qualität eines Compilers beurteilen zu können. Ich programmiere und wenn die Funktionalität erreicht ist, welche ich erwarte dann bin ich glücklich. Ich wüsste jetzt auch nicht, was an GCC so schlecht sein soll? Ich benutze ihn unter Linux und die Kompilate funktionieren. Viel eher treibt mich dort KDEDevelop zu Verzweiflung, aber das steht auf einem anderen Blatt.
fbi schrieb: > Sollte mittels: http://gnuarmeclipse.livius.net plugin gehen. hmm...muss ich mir nochmal anschauen. Ich hatte es auch nach der Yagarto Anleitung versucht und konnte dann nach langer Zeit auch mal kompilieren, aber das mit dem Debugger hat überhaupt nicht funktioniert. Wobei ich das auch nicht auf Eclipse&Co schieben will, da ich zu dem Zeitpunkt nur nen China-Clone Debugger hatte. Die verhalten sich nicht ganz so wie die Originale. Outofthebox hat CooCox wiegesagt sehr gut funktioniert, aber da ist C++ nicht unterstützt weswegen ich es dann erstmal liegen gelassen habe.
A. B. schrieb: > Ich maße mir nicht an die Qualität eines Compilers beurteilen zu können. > Ich programmiere und wenn die Funktionalität erreicht ist, welche ich > erwarte dann bin ich glücklich. Ich wüsste jetzt auch nicht, was an GCC > so schlecht sein soll? Bitte etwas genauer. Hier geht es um den arm-none-eabi-gcc und es gibt ja eine ganze Reihe Portierungen auf diverse Zielarchitekturen, bei denen der erzeugte Code jeweils besser oder schlechter sein mag. Aber weiter oben hat ja jemand dumm herumgerülpst, ohne auch nur im Mindesten sich zum Lesen zu bequemen, also geb ich hier mal ein konkretes Zahlenbeispiel: Die Basiskomponente der Lernbetty heißt BettyBase und man kann sie in compilierter Form (einmal Arm/Keil und einmal GCC) hier in der Codesammlung herunterladen. Darin enthalten sind 7 Fonts und ein Bild, zusammen 22900 Bytes groß. Der Rest ist Code und kleinere konstante Daten. BettyBase per Arm/Keil erzeugt: 38780 Bytes, dasselbe per GCC erzeugt: 48448 Bytes Zieht man die Fonts+Bild ab, so ergibt das 15880 Bytes bei Keil und 25548 Bytes bei GCC. Das macht ein Verhältnis von 1 : 1.6 aus oder mit anderen Worten: Wo der Keil mit 2 Befehlen auskommt, braucht der GCC rund 3 Befehle. Sowas nenne ich keinen guten Code. OK, er funktioniert, das ist wahr und gut und damit ist die Benutzbarkeit gegeben, aber mehr auch nicht. Zum Basteln ist das allemal ausreichend und auch du wärest damit glücklich. Auch ich finde das in Anbetracht der übrigen Umstände in Ordnung, aber man sollte sich den realistischen Blick bewahren und die Dinge so sehen wie sie sind. Genau deswegen mein Rat ganz weit oben: erstmal den Keil herunterladen und damit anfangen - damit man mal ne Art Referenz bekommt. Dann kann man immer noch je nach Projekt auf den GCC umschwenken oder eben bei kleineren Sachen unterhalb 32K beim Keil bleiben. Hier lese ich jedoch andauernd Beiträge von Leuten, die außer dem GCC noch nie was anderes gehabt haben und dennoch recht überheblich große Töne spucken. W.S.
W.S. schrieb: > BettyBase per Arm/Keil erzeugt: 38780 Bytes, wurde ohne Optimierung erzeugt > dasselbe per GCC erzeugt: 48448 Bytes wurde mit -O3 erzeugt Desshalb kannst du wohl nicht aufgrund der Grösse des Hex-Files auf die Qualität des Compilers/Linkers schliessen. Mit -O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize, -fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone options. wird wohl eher auf Speed optimiert, wenn dir die Grösse wichtig ist solltest du wohl -Os Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size. verwenden. Cheers
W.S. schrieb: > Wo der Keil mit 2 Befehlen auskommt, braucht der GCC > rund 3 Befehle. Das ist eine Milchmädchenrechnung, weil du damit nicht nur den vom Compiler generierten Code, sondern auch die Bibliotheken vergleichst. Wenn du Compiler vergleichen willst, vergleiche die Größe einer ungelinkten Funktion.
Ich habe mir grade mal das zip "LernBetty_R0.03aktualisiert.zip" reingezogen. So wie das makefile gebaut ist wundert's mich nicht. Wenn man -O3 gegen -Os ersetzt landet man schon bei 41k. Wenn dann noch die beim gcc üblichen -ffunction-sections -fdata-sections und --gc-sections beim ld verwendet werden, wird das bin nur noch 34.924 Bytes lang. Ob das so noch funktioniert kann ich nicht sagen, da ich dafür keine Hardware habe.
So, LernBetty_R0.03aktualisiert.zip wollte ich auch mal schnell durchlaufen lassen... ging aber nicht. Verwendet man ein Datei- bzw. Betriebsystem, was Groß- und Kleinschreibung unterscheidet, muss man schon etwas anpassen: klaus@LittlX:~/src/stm32/LernBetty_R0.03/BettyBase$ grep -i Tasten.h * Appfinder.c:#include "tasten.h" BettyWorkMenu.c:#include "tasten.h" cmd.c:#include "tasten.h" Interrupts.c:#include "tasten.h" Interrupts.c~:#include "Tasten.h" main.c:#include "tasten.h" setup.c:#include "tasten.h" Systemtick.c:#include "Tasten.h" Tasten.c:#include "Tasten.h" tasten.h:/* SwissBetty-TV-Fernbedienung: Tasten.h */ (Tasten.h ist nur ein Beispiel). Dies könnte man bei einer zukünftigen Release evtl. noch vereinheitlichen.
Andreas Schwarz schrieb: > Das ist eine Milchmädchenrechnung, weil du damit nicht nur den vom > Compiler generierten Code, sondern auch die Bibliotheken vergleichst. Milchmädchen hin oder her.. Im Grunde ist das egal, denn wenn der Compiler eben auch ne Menge umfänglicher Bibliotheksfunktionen braucht, um lauffähigen Code zu erzeugen, dann ist das Ergebnis halt länger und in aller Regel auch langsamer. Ich hatte schweren Ärger beim GCC-Linker mit Wrapper-Funktionen für den SVC, die ich in Assembler geschrieben habe, weswegen ich mir den erzeugten Code per Reassembler angeschaut habe. Von da her weiß ich, wie umständlich der Code vom Gcc im Vergleich zu dem vom Arm dabei gewesen ist. Ach ja, ich habe wirklich nix dagegen, wenn hier jemand aus der GCC-Riege sich mal hinsetzt und für die Yagarto-Distribution eine vernünftige Dokumentation schreibt, wo man nachlesen kann, wie dort was aufgerufen und benutzt werden muß, damit man ein gutes Ergebnis vom GCC bekommt. Das wäre endlich mal was Nützliches. W.S.
W.S. schrieb: > Milchmädchen hin oder her.. > Im Grunde ist das egal, denn wenn der Compiler eben auch ne Menge > umfänglicher Bibliotheksfunktionen braucht, um lauffähigen Code zu > erzeugen, dann ist das Ergebnis halt länger und in aller Regel auch > langsamer. Das ist gelinde gesagt Blödsinn. Wenn ich mich dazu entscheide z.B. die printf aus der newlib zu verwenden, dann weiss ich auch was für ein Klotz das ist. Dafür hat man dann auch den vollen Umfang aller erdenklicher Formatierungsoptionen. Warum soll das aber großartig langsamer werden? Das eine hat mit dem anderen nicht unbedingt was zu tun. Ohne --gc-sections beim Linken kommt eben einiges an nicht verwendeten Code ins Binary. Das sollte einem aber auch klar sein bevor man meckert. Beim Keil sind diese Optionen sogar in der GUI anklickbar, wenn man auf gcc umschaltet. Dokumentationen zum gcc sind nun zur Genüge vorhanden.
W.S. schrieb: > Genau deswegen mein Rat ganz weit oben: > erstmal den Keil herunterladen und damit anfangen - damit man mal ne Art > Referenz bekommt. Dann kann man immer noch je nach Projekt auf den GCC > umschwenken oder eben bei kleineren Sachen unterhalb 32K beim Keil > bleiben. Hier lese ich jedoch andauernd Beiträge von Leuten, die außer > dem GCC noch nie was anderes gehabt haben und dennoch recht überheblich > große Töne spucken. Naja, Referenz hin oder her...also ich finde 32kB bei ARM Projekten nun nicht unrealistisch, da die Prozessoren grösser sind man somit wahrscheinlich ein OS und verschiedene Libs verwendet etc. Von daher ist das mit dem Keil ja gut und schön, aber kaufen wird man sich den als Privatanwender nicht (können), ausser man hat wirklich zu viel Geld für sein Hobby. Und ob man als Privatanwender nun Bock hat, je nach Projekt zwischen 5 IDEs zu switchen wage ich auch eher zu bezweifeln. Von daher liebe direkt den OpenSource Weg gehen und sich mit Konfiguration von Eclipse und einem GCC rumschlagen, oder halt was fertiges kaufen. Für 200-300€ bekommt man ja fertige Compiler samt IDE welche hier auch schon angesprochen wurden. Die Privatleute welche die (vermeintlich) schlechtere Codequalität des GCC im Vergleich zu Keil, Imagecraft und was es da sonst noch so gibt, bemerken&beurteilen können dürfte sich ziemlich in Grenzen halten. Und ob mein Kompilat bei nem ARM nun 5kB mehr oder weniger hat, interessiert doch da normalerweise keine Sau...Speicher haben die Dinger ja nun massig. (ja ich seh schon was ich damit lostrete, und mir gleich die gute alte Zeit um die Ohren gehauen wird, als man noch jedes Bit sparen musste)
Man lese zuerste den mit "Benchmarking" beginnenden Abschnitt im EULA der ARM Keil Software-Werkzeuge. Solche Forumulierungen gibt es bei anderen Anbietern in ähnlicher Form. Alle Monate (manchmal alle paar Tage) wieder kommt ein "wer hat den Besten"-Thread für Compiler, IDEs, Debugger, Debuginterfaces etc im Zusammenhang ARM-basierten Controllern. Es düfte schon so ziemlich alles geschrieben worden sein aber wie auch immer: Ein Compiler/Toolchain X wird zu einem Vergleichszeitpunkt etwas kompakteren Code als Toolchain G erzeugen und Compiler R die schnellste Laufzeit erreichen - jeweils bei "bestmöglichen" Einstellungen. Aber das kann in ein paar Wochen schon wieder anders sein. Neutrale Vergleiche wird es kaum geben, denn ein Compilerhersteller will zum Kauf der neuen noch "besseren" Version animieren, dabei die Ausgabe seines Produkts mit den ihm bestens bekannten Möglichkeiten seines Produkts hervorheben und die Mitbewerber aus Unkenntnis der möglichen Optionen (siehe auch oben) oder einfach mit Absicht schlechter darstellen. Details zum Test gibt es ohnehin nicht, verbieten ja die EULAs. Wäre ja sonst auch lausiges Marketing.
temp schrieb: > W.S. schrieb: >> Milchmädchen hin oder her.. >> Im Grunde ist das egal, denn wenn der Compiler eben auch ne Menge >> umfänglicher Bibliotheksfunktionen braucht, um lauffähigen Code zu >> erzeugen, dann ist das Ergebnis halt länger und in aller Regel auch >> langsamer. > > Das ist gelinde gesagt Blödsinn. Eher ist das Gegenteil der Fall. Auf Geschwindigkeit optimierter Code ist praktisch immer größer, schon aufgrund vieler wegfallender Sprungmarken, wenn kleine Schleifen etc. linear abgelegt werden. Und es geht bei der Geschwindigkeit ja nicht nur um die reinen Bytes, die gespart werden. Da hängt bei vielen ARMs noch der ganze Rattenschwanz mit Cache mit Waitstates usw. dran. Wenn man dann natürlich wie oben geschrieben mit -O3 optimiert (ich glaube das jetzt mal ungeprüft), darf man sich nicht wundern, wenn der Code größer wird. > tun. Ohne --gc-sections beim Linken kommt eben einiges an nicht > verwendeten Code ins Binary. Das sollte einem aber auch klar sein bevor > man meckert. Beim Keil sind diese Optionen sogar in der GUI anklickbar, > wenn man auf gcc umschaltet. Dokumentationen zum gcc sind nun zur Genüge > vorhanden. Chris D.
So, Leute. Damit wir hier nicht im luftleeren Raum diskutieren mal ein paar Fakten: Codesize für die BettyBase mit unterschiedlicher Optimierung (alle nur übersetzt, nix tatsächlich ausprobiert) Size der erzeugten BettyBasexxx.bin Dateien Arm/Keil: -O0 42144 Bytes -O1 40020 -O2 38780 -O3 38784 -Otime 39796 -Ospace 38780 GCC (Yagarto 4.7.2) -O0 48916 -O1 42612 -O2 42724 -O3 48448 -Ofast 48512 -Os 41380 Zieht man die konstanten 22900 Bytes für Grafik+Fonts ab, dann gibt das für den reinen Code Arm/Keil: -O0 19244 Bytes -O1 17120 -O2 15880 -O3 15884 -Otime 16896 -Ospace 15880 GCC (Yagarto 4.7.2) -O0 26016 -O1 19712 -O2 19824 -O3 25548 -Ofast 25612 -Os 18480 und im Verhältnis: -O0 1 : 1.35 -O1 1 : 1.15 -O2 1 : 1.25 -O3 1 : 1.61 -O(fast) 1 : 1.51 -O(size) 1 : 1.16 ist schon interessant, mal den direkten Vergleich an derselben Quelle zu haben. Gelle? Wenn man sich also vor der Falle -O3 oder -Ofast hütet, dann sieht das Ganze schon ein bissel gelinder aus. Aber wie gesagt, nicht am lebenden objekt ausprobiert. W.S.
Meiner ist länger!!! Mit folgenden Änderungen im Makefile und dem gcc aus den gnu-arm-tools: CPUFLAGS = -mcpu=arm7tdmi-s OPTFLAGS = -Os CFLAGS = -Wall -mthumb-interwork -msoft-float -DGCC -ggdb -Wa,-adhln=$*.lst #hier CFLAGS += -ffunction-sections -fdata-sections INC = -I$(INCLUDEPATH) -I. ASFLAGS = --gstabs -mthumb-interwork -mfpu=softfpa -a=$*.lst LDFLAGS = -Tlpc2220_Base.ld -Map BettyBase.map -eHard_Reset #und hier LDFLAGS += --gc-sections LIBS = --start-group -lgcc -lc -lm --end-group THUMBFLAGS = -mthumb -O0 41860 -O1 36004 -O2 35956 -O3 40576 -Os 34924 -Ofast 40576 minus 22900= -O0 18960 (0.98) -O1 13104 (0.76) -O2 13056 (0.82) -O3 17676 (1.04) -Os 12024 (0.75) -Ofast 17676 Warum im Makefile 2 mal CFLAGS=xxx bei euch steht ist mir unklar. Die Zeile CFLAGS = -Wall -mthumb-interwork -msoft-float -ggdb ist somit Müll, da später sie später wieder überschrieben wird. Beseitigt das bitte mal, das trägt nur zur Verwirrung bei.
Noch ein Nachtrag. Nur zum Beispiel. Die Funktion:
1 | const float FRound[5] = { 10.0, 100.0, 1000.0, 10000.0, 100000.0 }; |
2 | |
3 | float FF_round (float aValue, byte Digits) |
4 | { float f; |
5 | int n; |
6 | n = Digits-1; |
7 | if (n<0) n = 0; |
8 | if (n>4) n = 4; |
9 | f = floor((fabs(aValue) * FRound[n]) + 0.5); |
10 | if (aValue<0) f = -f; |
11 | f = f / FRound[n]; |
12 | return f; |
13 | }
|
aus conv.c wird nirgends im gesamten Code verwendet. Deshalb schmeißt der Compiler sie mit geeigneten Einstellungen auch raus. Ebenso die Konstanten FRound[5]. Bevor nicht geklärt ist ob solche Funktionen beim Keil drin sind oder nicht erübrigt sich jeglicher Vergleich. Außer man argumentiert sich selbst die Welt schön.
W.S. schrieb: > -O(size) 1 : 1.16 Das entspricht ja ungefähr den bekannten Vorurteilen. W.S. schrieb: > -O(fast) 1 : 1.51 Jetzt müsste man nur noch eine Laufzeitanalyse machen, welcher Code denn nun schneller ist, und um wieviel ;) Alles in allem nichts neues. Oliver
temp schrieb: > Warum im Makefile 2 mal CFLAGS=xxx bei euch steht ist mir unklar. Das kann ich dir erklären: Ich selber arbeite mit Keil und habe den GCC hier ausschließlich per Batchfile benutzt, um die diversen -Oxx auszuprobieren. Ich selbst verwende also weder GCC noch Makefile und bin deshalb für diese Frage der falsche Ansprechpartner. Aber Siegfried u.a. benutzen Make und da es offenbar nicht nur für mich, sondern auch für andere einen erheblichen nicht gedeckten Bedarf an Dokumentation gibt, haben die Makefile-Benutzer eben einfach einige alte Files (makefile, Linkersteuerfile, Eclipse-Files...) von anderen Projekten herüberkopiert und drin solange geändert, bis es lief. So pflanzt sich das fort... Wirklich gute Makefiles zu schreiben ist offenbar nicht einfach und sich zwischen den schier unendlichen Optionen des GCC durchzuwursteln ebenfalls. Da wundert es mich nicht, daß man schon seit Jahren von Insidern den Tip bekommt, einfach ein altes File herzunehmen und nur das Nötigste darin zu editieren. btw: das hatte ich wirklich ernst gemeint: "Ach ja, ich habe wirklich nix dagegen, wenn hier jemand aus der GCC-Riege sich mal hinsetzt und für die Yagarto-Distribution eine vernünftige Dokumentation schreibt, wo man nachlesen kann, wie dort was aufgerufen und benutzt werden muß, damit man ein gutes Ergebnis vom GCC bekommt." W.S.
W.S. schrieb: > da es offenbar nicht nur für mich, sondern auch für andere einen > erheblichen nicht gedeckten Bedarf an [make] Dokumentation gibt, Was fehlt dir denn an der make-Dokumentation? http://www.gnu.org/software/make/manual/ Wenn ich was nicht weiß über make dann liegt das bestimmt nicht daran, weil es nicht in der Doku steht, sondern daran, daß ich zu faul bin, sie zu lesen. > [...] und sich zwischen den schier unendlichen Optionen des GCC > durchzuwursteln [ist] ebenfalls [nicht einfach]. Ja, ist eben so. Einerseits wollen Anwender maximale Flexibilität und nach Möglichkeit Feinjustierungen vornehmen, andererseits wird darüber geklagt, daß es die entsprechenden Stellschräubchen und -hebel gibt. Ist wie mit einem A380: Mit dem Wissen und der Erfahrung von einem Tretroller kommt man da nicht weit. In dem Maße, in dem man das Gerät optimal einsetzen möchte, muss man sich auch damit auseinandersetzen. Natürlich kann man auch sagen "mach ich net, mehr als ein Mausclick ist nicht zumutbar". Ist voll okay, aber dann bitte nicht nölen, wenn das Ergebnis suboptimal ist :-) > Ach ja, ich habe wirklich nix dagegen, wenn hier jemand aus der > GCC-Riege sich mal hinsetzt und für die Yagarto-Distribution eine > vernünftige Dokumentation schreibt, wo man nachlesen kann, wie dort > was aufgerufen und benutzt werden muß, damit man ein gutes Ergebnis > vom GCC bekommt. Neben dem Ausloten der Möglichkeiten (etwa LTO) gibt es auch die Möglichkeit, bei schlechtem Code einen GCC-Problembereicht anzulegen und die Entwickler darüber in Kenntnis zu setzen. Allerdings beobachte ich bei den avr-gcc Anwendern teilweise nen ziemlichen Kindergarten: Jahrelang werden bestimmte Macken des Compilers in allen möglichen Foren quer über den Planeten breitgetreten, die wüstesten Hacks erarbeitet und ausgetauscht, Mannjahre in Rants und Flames and Beiträgen investiert, aber kein Schwein macht nen Bugreport — über Jahre hinweg wohlgemerkt...
Johann L. schrieb: > Was fehlt dir denn an der make-Dokumentation? Garnichts. Ich benutze Make nicht, Dafür fehlt es mir an Doku für den arm-none-eabi-ld und zwar massiv. Guck dir mal meinen hier in diesem Forumsteil geposteten Versuch an, Hilfe bei den massiven Problemen zu bekommen, die ich mit diesem Linker hatte. Dieses Mistteil hat unaufgefordert zwischen zwei thumb Funktionen einen arm-stub gebaut, was natürlich voll in die Hose ging. Irgendwas dazu in der Yagarto-Doku (soweit man dieses ascii-File so nennen darf..) war nicht auffindbar. Im Prinzip bräuchte ich nen Parameter "-DoNotInsertArmStubsBetweenThumbCodes", da der Linker offenbar per default alles falsch macht, was man ihm nicht explizit verboten hat. Bin ich vom Keil, von IAR, von Fujitsu und von allen anderen C-Toolchains nicht gewohnt. Johann L. schrieb: > Einerseits wollen Anwender maximale Flexibilität und nach Möglichkeit > Feinjustierungen vornehmen, andererseits wird darüber geklagt, daß es > die entsprechenden Stellschräubchen und -hebel gibt. Es sollte die Toolchain per Default bereits alle soweit richtig machen, daß zumindest lauffähiger Code dabei herauskommt. Meine - allerdings kurzen - Erfahrungen mit dem GCC sind jedoch gegenteilig. Ich habe schlußendlich per ellenlangem Probieren und Reassemblieren eine Art Kochrezept hinbekommen, mit dem es funktioniert. Aber das finde ich intellektuell extrem unbefriedigend. W.S.
W.S. schrieb: > Dafür fehlt es mir an Doku für den arm-none-eabi-ld > und zwar massiv. Guck dir mal meinen hier in diesem > Forumsteil geposteten Versuch an, Hilfe bei den massiven Problemen zu > bekommen, die ich mit diesem Linker hatte. Dieses Mistteil hat > unaufgefordert zwischen zwei thumb Funktionen einen arm-stub gebaut, was > natürlich voll in die Hose ging. Wenn ich das Goorakel nach "arm stubs in thumb mode" frage, ist der erste Treffer "ld and the ARM family": http://sourceware.org/binutils/docs/ld/ARM.html Wenn man den Suchbegriff nicht hat — etwa weil man noch nicht mit den Tools nicht vertraut ist — ist die Lektüre der Doku unverzichtbar. > Irgendwas dazu in der Yagarto-Doku (soweit man dieses ascii-File > so nennen darf..) war nicht auffindbar. Ich selbst betrachte fehlende oder lückenhafte Doku als Bug — nicht nur bei Tools wie GCC oder Binutils, auch bei "normaler" Software. Wie es im Yagarto-Fall konkret aussieht vermag ich nicht zu sagen weil ich mich weder mit diesen Tools noch mit ARM auskenne. Es ist jedoch nicht unüblich, daß spezielle Distributionen nur die Punkte erklären, wo sie von den Standard-Tools abweichen, d.h. von GCC, Binutils etc. Die komplette GCC / Binutils-Doku zu liefern sprengt i.d.R. den Rahmen, und die Eigenheiten der Distro gehen verloren. Neben den Release-Notes der Distro und deren Doku und README gehören also auch immer die entsprechenden Dokumente von GCC et al. zur Lektüre. Ja, es ist viel Holz, aber das gehört zur professionellen Arbeit eben dazu. Zeit, die man durch Nichtlesen der Doku spart, ist nicht etwa gesparte Zeit, sondern man packt dadurch ein Vielfaches an Zeit-Schulden ins Projekt! > Im Prinzip bräuchte ich nen Parameter > "-DoNotInsertArmStubsBetweenThumbCodes", da der Linker offenbar per > default alles falsch macht, was man ihm nicht explizit verboten hat. Bin > ich vom Keil, von IAR, von Fujitsu und von allen anderen C-Toolchains > nicht gewohnt. Häufigerst Fehler mit Linken + GNU-Tools ist, daß der Linker von Hand aufgerufen wird.
Zunächst erst einmal Danke an Euch, die Ihr mit der Codegröße experimentiert und die Ergebnisse hier zur Verfügung stellt. Ich denke, das interessiert viele stumme Mitleser :-) Ich muss selbst auch gestehen, dass ich viele Einstellungen im GCC immer noch nicht kenne (und kannte - danke an temp für die Makefileauszüge) und deshalb sicher auch suboptimalen Code verwende (-Ox ist natürlich bekannt :-) Ist bei uns auch nicht so dramatisch, weil wir bei der Controllerauswahl nicht auf den Euro achten müssen - wir haben also Platz. Und wir machen damit leider einfach zu wenig (vielleicht drei, vier kleinere Controllerprojekte pro Jahr), um wirklich tief in den Compiler einsteigen zu können. Es fehlt die Zeit :-/ Und wie W.S. es schon sagte, wird es so sein, dass viele einfach Makefiles anderer übernehmen, ohne zu verstehen, was da genau passiert. Und so kommt es dann zu echtem Gefrickel. Aber ich denke, als erstes Fazit kann man für einen Großteil der Anwender sagen: der GCC ist auf jeden Fall keine schlechte Wahl Chris D.
Chris D. schrieb: > Aber ich denke, als erstes Fazit kann man für einen Großteil der > Anwender sagen: der GCC ist auf jeden Fall keine schlechte Wahl ... bezüglich der Kosten :-) Bezüglich der Verwendung, hatte ich ähnliche Probleme wie W.S., auch wenn ich es nicht so drastisch formulieren würde.
@ W.S. Unter Beitrag "Re: kann arm-none-eabi-ld mit thumb umgehen?" habe ich dir die Auflösung des Rätsels mit dem ld gepostet. Und es handelt sich nicht um einen Bug.
Hmm... erstmal danke für den Tip. Aber.. wozu ist dann .thumb gut, wenn es nicht zu einem Objektcode führt, der in thumb assembliert ist und dann eben auch als thumb behandelt wird - und man stattdessen .thumb_func schreiben muß? Ich könnte mir allenfalls eine Funktion vorstellen, die als ARM-code ausgewiesen werden soll, aber tatsächlich THUMB-code enthält - aber das wäre doch blanker Irrsinn und ich könnte mir dafür beim besten Willen keinen Anwendungsfall vorstellen. Also, aus welcher Logik kommt das her und wie muß man das begreifen? Bei Keil/Arm ist das eindeutig: wo thumb steht, wird auch thumb draus gemacht und der Linker kann das eindeutig dem Objektfile entnehmen. Da gibt es gar keine Unklarheiten: thumb ist thumb und arm ist arm. Uff, ich fühle mich beim GCC immer weniger zuhause. Es reicht da eben nicht zu sagen "fahr rechts rum!" sondern "fahr rechts rum, fahr aber nicht gradaus, fahr auch nicht links rum und fahr auch nicht zurück und bleib auch nicht stehen!" stressig - zumindest für unsereiner. W.S.
W.S. schrieb: > Aber.. > wozu ist dann .thumb gut, wenn es nicht zu einem Objektcode führt, der > in thumb assembliert ist und dann eben auch als thumb behandelt wird - > und man stattdessen .thumb_func schreiben muß? Eindeutig steht das auch in der Doku: http://sourceware.org/binutils/docs/as/ARM-Directives.html Ich will mir nicht zutrauen zu beurteilen ob es dafür sinnvolle Anwendungen gibt. Allerdings ist es wie bei vielen Sachen: kaum macht man's richtig, schon geht es. Ich verstehe nur nicht, warum du so penetrant Seitenhiebe verteilen musst. Der gcc ist für eine Unmenge vom Prozessoren verfügbar ohne dass man dafür einen 5stelligen Betrag auf den Tisch legen muss. Und die Ergebnisse sind zu mindestens ähnlich zu denen der kommerziellen Compiler. Der Fallstrick mit den .thumb_func Schlüsselwort hat im übrigen nichts mit dem gcc zu tun. Der as und ld gehören zu den binutils. Es steht dir ja frei den Keil zu benutzen. Im übrigen habe ich im Leben noch keine einzige Zeile für einen Arm7 geschrieben. Ich beschränke mich auf Cortex M3 und M0. Trotzdem hat die Suche im Web nach einer Lösung für dein Problem ca. eine Stunde gedauert. Vielleicht hättest du die investieren sollen bevor du in mehreren Threads den gcc geprügelt hast.
temp schrieb: > Eindeutig steht das auch in der Doku: erstmal danke für den Link, aber wenn ich dort folgendes bei ".thumb_func" lese: "This directive is not neccessary when generating EABI objects. On these targets the encoding is implicit when generating Thumb code." dann ist mir jetzt sonnenklar, daß wir hier einen echten Bug entdeckt haben. Der Assembler wird mit echo Assembliere BettyApiGcc ARM-NONE-EABI-AS -mcpu=arm7tdmi-s --gstabs -mthumb-interwork -mfpu=softfpa -a=BettyApiGcc.lst -o BettyApiGcc.o BettyApiGcc.asm if Errorlevel==1 goto ende aufgerufen und in der Quelle steht eindeutig .thumb drin. Deswegen sollte die obige Direktive lt. Doku implizit aktiviert sein - aber sie ist es offenbar nicht, denn wir erhalten einen Objektcode, wo zwar thumb code drin ist, aber selbiger als arm code ausgewiesen wird, wodurch der Linker Mist baut. So. Was machen wir jetzt? - für die Lernbetty-User, die den GCC benutzen wollen, die zugehörigen Files verbessern und das WARUM dazu in die Doku schreiben? - für die Lernbetty-User, die Make benutzen wollen, ein gutes Makefile kreieren und ebenfalls das WARUM dazu dokumentieren? - entdeckte Bugs jemandem zur Kenntnis zu geben, der sich darum kümmern kann? W.S.
W.S. schrieb: > So. Was machen wir jetzt? > > - für die Lernbetty-User, die den GCC benutzen wollen, die zugehörigen > Files verbessern und das WARUM dazu in die Doku schreiben? > > - für die Lernbetty-User, die Make benutzen wollen, ein gutes Makefile > kreieren und ebenfalls das WARUM dazu dokumentieren? > > - entdeckte Bugs jemandem zur Kenntnis zu geben, der sich darum kümmern > kann? Ich würde sagen zu erst nimmmst du mal deine arrogante, besserwisserische Art etwas zurück. Bug hin oder her das interessiert mich nicht mal so sehr. Selbst bei deinem geliebten Keil stehen die .thumb_func Anweisungen in den Startupcodes die für den GCC mitgeliefert werden. Ebenso bei Crossworks und allen anderen die Assembler für den Startupcode verwenden. Die Leute von diesen Firmen sind auch nicht so überheblich und packen jedesmal wenn sie .thumb_func schreiben müssen ein paar gehässige Kommentare mit dazu. Wie die wohl darauf gekommen sind, dass das da hin gehört? Such mal hier im Forum, da findest du auch Treffer. Der einzige Bug den ich sehe ist der in der Doku. Obwohl ich die Unterschiede zwischen arm-eabi und arm-none-eabi noch nicht verstanden habe. Und hier gehts um den none-eabi. Vielleicht ist es ja nichtmal ein Bug. Jedenfalls hast du die Doku ja vorher nicht mal gelesen. Also kann die dich nicht auf den Holzweg geführt haben. Mach ganz einfach nicht so ein Federlesen drum, schreibs rein in deinen Code und gut ist. Daß der as (oder ld) irgendwann mal anders geht wirst du wohl nicht erleben. Vielleicht kommt mal noch ein Kommandozeilenschalter dazu. Es wäre ja extrem gefährlich wenn der as bzw. ld von einer Version zur nächsten völlig anderen Code generiert.
Hallo Jürgen, ich kann von Produkten von Mikroe nur abraten. Schau da mal in die Foren, die brauchen um Fehler in Ihren Produkten zu lösen zum Teil Monate. Ich habe die ~ 250€ jedenfalls bereut. Grüße Jörg
guck mal bei rowley crossworks. Da gibt es eine billige version für privatuser. die benutze ich auch und bin zufrieden damit...
W.S. schrieb: > echo Assembliere BettyApiGcc > ARM-NONE-EABI-AS -mcpu=arm7tdmi-s --gstabs -mthumb-interwork > -mfpu=softfpa -a=BettyApiGcc.lst -o BettyApiGcc.o BettyApiGcc.asm Erste Frage ist, warum arm-none-eabi-as von Hand aufgrufen wird und nicht durch den Treiber, also arm-none-eabi-gcc. Oder rurst du etwa den Compiler (cc1 für C bzw. cc1plus für C++) auch von Hand auf? Der Treiber setzt einiges an Optionen. Häufiger Anwender-Fehler ist, daß die Subtools (foo-as, foo-ld) händisch aufgerufen werden und Optionen oder Pfade nicht stimmen. > [...] denn wir erhalten einen Objektcode, wo zwar thumb code drin > ist, aber selbiger als arm code ausgewiesen wird, wodurch > der Linker Mist baut. > > So. Was machen wir jetzt? [...] > > - entdeckte Bugs jemandem zur Kenntnis zu geben, der sich darum kümmern > kann? Wenn es ein wirklich Fehler ist, und sei es nur in der Doku, dann ist das keine schlechte Option. Keine Software ist fehlerfrei, und kein Entwickler ist unfehlbar -- es sei denn, du benutzt nur Software aus dem Vatikan.
temp schrieb: > Ich würde sagen zu erst nimmmst du mal deine arrogante, > besserwisserische Art etwas zurück. Bug hin oder her das interessiert > mich nicht mal so sehr. Selbst bei deinem geliebten Keil stehen.. Ach nö, das ist nicht die Ebene, auf der ich hier weiter diskutieren will. Was fällt dir eigentlich ein, hier solche Äußerungen loszulassen?? W.S.
W.S. schrieb: > temp schrieb: >> Ich würde sagen zu erst nimmmst du mal deine arrogante, >> besserwisserische Art etwas zurück. Bug hin oder her das interessiert >> mich nicht mal so sehr. Selbst bei deinem geliebten Keil stehen.. > > > Ach nö, das ist nicht die Ebene, auf der ich hier weiter diskutieren > will. Was fällt dir eigentlich ein, hier solche Äußerungen loszulassen?? > > W.S. Wo er recht hat... Und das ist nicht der einzige Thread, wo Du so rüberkommst.
Hach, wäre das schön, wenn du dich einfach verziehen würdest. Wird nur wohl nicht geschehen. :-(
Was ich hier heraushöre - ist das die 250 Euro oder wie viel auch immer für den Keil gut angelegt sind wenn man keine Zeit oder Lust hat sich die umfangreiche GCC Doku reinzuziehen. Ja, und dann noch ewig herumprobieren muss bis man ein akzeptables Ergebnis gefunden hat. Nee, ich spare schon mal und investiere die Zeit lieber in was anderes. Jedem das seine.
Ja :-D
Da ist die Doku dann doch nicht mehr ganz so umfangreich ... ;-)
Ich bin temp jedenfalls dankbar für die angegebenen, mir bislang
unbekannten Optionen - denn mit denen wird der Code offenbar deutlich
kleiner, in der Spitze nur noch 3/4 vom bisher besten Keil-Kompilat.
Das ist schon eine Hausnummer.
Wenn man wirklich viel aus einer Software rauskitzeln möchte, kommt man
am Lesen des Handbuchs nicht vorbei ("Ach?").
Der eine beschwert sich, weil man nicht genug einstellen kann, dem
anderen ist es zu viel. Allen wird man es wohl nicht Recht machen
können.
Chris D.
Chris D. schrieb: > denn mit denen wird der Code offenbar deutlich kleiner, in der Spitze nur > noch 3/4 vom bisher besten Keil-Kompilat. Du meinst GCC erzeugt kompakteren Code als der ARM compiler? Höchst unwahrscheinlich. Was bedeutet "in der Spitze"? Eine einzelne Funktion? Zeig mal die Optionen, die Du bei letzterem verwendet hast. Übrigens kann man sich mit "size", bzw. "fromelf" genauere Informationen zu Code/Daten Segmenten ausgeben lassen. Viele Grüße Marcus
> Was bedeutet "in der Spitze"? Die "beste" Optimierung: Beitrag "Re: ARM C-Compiler" > Höchst unwahrscheinlich. Warum? Wenn die Ergebnisse von oben stimmten, dann eher höchst wahrscheinlich. Nicht vergessen: alle haben das Drachenbuch im Schrank.
Hallo, zuerst mal Danke für die vielen Antworten, ihr haut Euch die Sachen ja ganz schön um die Ohren. Zuerst vorweg ich bin Amateur und betreibe den "Sport" als reines Privatvergnügen. Mir geht es eher darum bequem einzusteigen als das letzte Quäntchen Performance auszuquetschen. Was mir an Mikroe noch gefallen hat ist das Board das ich eingangs erwähnte. Es wird zu 90% das abdecken was ich noch vorhabe. Es geht mir haupsächlich um eine komfortable Bedienoberfläche und Visualisierung mit Speichermöglichkeiten. (SD-Card). Ich hatte dafür auch schon mit Arduino geliebäugelt aber der Aufbau mit dem Umfang wie Mikroe es bietet besteht aus 3 Platinen und schaut ganz schön gebastelt aus. Der 8051 wird auch noch einige Zeit zum einsatz kommen. @Pieter 250.- € ist zwar nicht nachgeschmissen aber bevor ich unzählige Abende damit verbringe bis der Compiler läuft und ich die ersten LED's zum leichten bringe investiere ich das Geld. @Jörg ich werde mal die Foren durchforsten Gruß Jürgen
Wenn du von der 8x51 Architektur kommst dann ist der Übergang zu ARM durchaus ein paar Tests wert. Es gibt ARM Boards für rund 20 Euro oder für das was du dir vorgenommen hast würde auch das folgende Board passen... http://www.steitec.net/ARM-Boards/ARM-LPC1768-Cortex-M3-LCD-Board.html Die Frage nach dem Compiler stellt sich beim Testen noch nicht allzu sehr aber für Hobbyzwecke fällt der Keil dann heraus. Wurde schon genannt... http://www.coocox.org/Index.html Brendes Emulator... lange her :-) >> Emulator eigentlich recht komfortabel aber ich bin jetzt doch auf seine >> (8051) Grenzen gestoßen. (Touch Screen SD Card etc.) Bin mir sicher das man ein solches Vorhaben durchaus mit einem 8x51 Derivat durchziehen kann, das bringt moderne 8x51 Typen noch lange nicht an deren Grenze.
Hat mich doch jetzt auch mal interessiert :-) aus dem gleichen Stall... http://www.mikroe.com/big8051/
@ Bernd, mag schon sein das das ich mit einem leistungsfähigeren 8051 Derivat das auch hinbekommen kann. Aber ich müsste dann das gleiche Geld ausgeben. Mein Keil Compiler ist schon sehr betagt und noch mit einem Dongle an der Paralellschnittstelle, auf einem neuen Rechner läuft das nicht mehr. Ich habe bisher fast ausschließlich den AT89C51ED2 verwendet.Die 2K RAM sind nun auch nicht gerade üppig.Ich habe mir damals dafür extra ein eigenes POD gemacht damit ich die Softhook Restriktionen umgehen konnte. Ich bin auch etwas versessen auf das "mikromedia for STM32 M4 (Mikroelektronika)" Bord weil es wunderbar in eine doppelte Unterputzdose passt. Es also an der Zeit mal was neues zu probieren.
Ich wollte es dir auch nicht ausreden :-) War nur als Hinweis gemeint da es für dich "nur" Hobby ist und die ARM Architektur doch ziemlich weit weg ist von deinem 8051. Die Silabs Chips hingegen bieten einem die gleichen Debug Möglichkeiten wie seiner Zeit der Biceps 51 von Brendes, Emulator sozusagen On Chip. Software gibts für den 8x51 Kern Haufenweise und kostenlos dazu, den Keil in Ehren aber den verwende ich schon ewig nicht mehr für 51er. Wie dem auch sei, ARM ist in jedem Fall interessant und sicherlich der richtige Schritt, für Profis führt da eh kein Weg vorbei und schließlich ist der Einstieg nicht allzu schwer. Dennoch macht man häufig den Fehler eine neue Architektur zu verwenden obwohl ein 8Bit MC noch allemal gut genug ist. Was mich bei deiner Auswahl ein wenig stört, ist die Tatsache keinen Vollzugriff auf die Sourcen zu haben. Gerade im ARM Segment gibt es unglaublich Viele Boards und freie Software. Seis drum, Viel Spaß mit dem Teil und vielleicht schreibst du dann mal deine Erfahrungen damit zusammen und postest dies hier.
Davis schrieb: > Warum? Wenn die Ergebnisse von oben stimmten, dann eher höchst > wahrscheinlich. Nicht vergessen: alle haben das Drachenbuch im Schrank. Aber vielleicht nicht die Möglichkeiten des armcc ausgenutzt... Mir ist es jedenfalls noch nicht passiert, dass GCC kompakteren Code erzeugt. Es wäre hilfreich, die eingestellten Optionen zu sehen. Ich weiß nicht, ob die leicht abgespeckte Keil-Version auch die Option "--translate_gcc" unterstützt. Damit werden, soweit möglich, GCC Optionen in die entsprechenden armcc Optionen übersetzt. Viele Grüße Marcus
Für ASM http://plit.de/asem-51/download.htm In C http://sdcc.sourceforge.net/ mit der Entwicklungsumgebung von Silabs. http://www.silabs.com/Support%20Documents/TechnicalDocs/an198.pdf
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.