-
Thread
ATMEGA8 läuft zu schnell
jetzt nicht ganz die Antwort, die du erwartet hast :-) http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29
http://gcc.gnu.org/ml/gcc-help/2002-06/msg00133.html Alternativ kannst du auch einen Disassembler bemühen. http://www.mikrocontroller.net/articles/Linksammlung#Disassembler
-
Thread
WinAVR compiliert nicht mehr richtig
attempt to use poisoned "SIG_INTERRUPT0" [/code] Dies wird doch schon seit Ewigkeiten vom avr-gcc bemängelt.
compiliert. Das lief auch immer, bis auf den einen Moment, wo es nicht > mehr ging. Stell ich die Optimierung nun auf -O0 dann klappt es wieder. Nimm mal -Os. Kann auch sein, dass bei -O2 zuviel RAM genutzt wird und nichts mehr für den Stack übrigbleibt. Sinnvoll wären auch mal die avr-gcc-Kommandos
-
Thread
AVR Studio - altes Projekt neu compilieren
g_reichert schrieb im Beitrag #3414403: > Brauche ich jetzt die entsprechende WinAVR-Install-exe, die den GCC > 4.5.1 enthält? Zumindest finde ich bei Google kein Install-Programm auf http://gcc.gnu.org/ für den GCC4.5.1
g_reichert schrieb im Beitrag #3414403: >> Brauche ich jetzt die entsprechende WinAVR-Install-exe, die den GCC >> 4.5.1 enthält? > > Zumindest finde ich bei Google kein Install-Programm auf > http://gcc.gnu.org/ für den GCC4.5.1 Das wirst du dort auch nicht finden. WinAvr heisst die Adaption des
-
Thread
Fragezeichen in C-Code - was ist das?
wird. Warum? Wenn du es genau wissen willst, prüf es doch einfach nach, mit eingeschalteter Optimierung. Oliver
Peter II schrieb im Beitrag #3747096: > was ist an -Os richtiger als -Os - wird sind bei GCC nicht beim µC. Du warst bei -O2 und das ist nun mal was anderes als -Os. http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > Außerdem ist es auch mit -Os auf einen PC nicht gleich. Und nicht
-
Thread
memset führt zum crash
Stelle genau die Exception aufgerufen wird. Versuche mal einen anderen Compiler, zB den neuesten gcc-arm-embedded ( https://launchpad.net/gcc-arm-embedded ), bei dem ist die memset Funktion vielleicht korrekt kompiliert.
Target Flash-Debug :) Ja hoffentlich ist dann auch mit Release Einstellungen kompiliert, also mit Optimierungen. Bringt ja nichts wenn du nur ohne Optimierungen debuggst, aber mit Optimierungen der Fehler auftritt. Mehmet Kendi schrieb im Beitrag #3770044: > Dass es am memset liegen könnte, ziehe also
-
Thread
GCC,AVR: uart-send in if UND else = fehler? (gcc-Anfänger)
>Wird da etwas hin-/weg-optimiert (Optimierung ist ausgestellt)? Bei -O0 wird nichts optimiert. Mit Optimierung dürfte [c] if (RxByte > 0x7F) { uart_putc(RxByte); } else { uart_putc(RxByte); } [/c] auf eine Zeile geschrumpft
schrieb: > hmmm. hört sich sehr seltsam an das... > > hast du ein compilierbares Beispiel samt gcc-Schalter, so daß man das > nachvollziehen kann? Ist RxByte vielleicht signed? > > Johann Ähem, was sind denn gcc-schalter? Ich schicke die Mididaten vom controller-TX in mein Midiinterface und
-
Thread
static char *pointer;
teilbar durch 32 checken also: [c]if(!(timer_counter % 32))[/c] läuft das Programm scheinbar. GCC 4.1.1 mit Optimierung s, ohne Optmierung gibts keinen Fehler. Findet einer den Fehler? Was ist da los?
Theoretisch denkbar wäre natürlich immer noch, dass der GCC 4.3.3 durch andere Optimierung eine race condition (die ich allerdings nicht erkennen kann) verdeckt. Es empfiehlt sich, einen Blick auf den erzeugten Code zu werfen, und diesen nachzuvollziehen.
-
Thread
Assemblerprogrammierung ARM CORTEX
In der GCC Toolchain sind üblicherweise Muster für den Startup Code dabei, in .\share\gcc-arm-none-eabi\samples\startup.
normalerweise" weder as zum assemblen, noch ld zum linken benutzt. Beides übernimmt in der Regel der gcc und zwar mit [code] arm-none-eabi-gcc -x assembler-with-cpp # für den Assembler # und arm-none-eabi-gcc # für den Linker [/code] Dem Linker-Script fehlt quasi der komplette Teil für den RAM,
-
Thread
Objektorientierung mit avr gcc
letzte Mal (genau wegen dieser Thematik) in den gcc-Eingeweiden rumgewühlt hab, hab ich da nichts gefunden. >> Da braucht man avr-g++ (oder "avr-gcc -X c++"). > > avr-gcc -x c++ Richtig. War ein Tippfehler.
Hardware-Treiber als Template Argument übergeben. Das Beispiel oben verlinkte Beispiel erzeugt mit einem avr-gcc 4.3.4 und aktivierten Optimierungen insgesamt 1610 Byte. Es ist allerdings schon die Luxus Variante mit Stream Operatoren zur Ausgabe von belieben Zahlen, virtuellen Funktionen usw. Um den Ansatz
-
Thread
GCC: --fmerge-constants ?
> das Zusammenlegen grundsätzlich nicht Schade.. ist doch eigentlich die einfachste aller Optimierungen. Wundert mich, daß der GCC das nicht kann. Wie kommt das ? Irgendeine Konstruktion mit benannten Konstanten kommt für mich hier nicht in Frage, da das Programm damit zu unleserlich würde. Dann
lieber Speicher. Noch habe ich so grade eben den Platz dazu. Gibt es einen anderen Weg, wie man den GCC dabei etwas auf die Sprünge helfen kann ? Funktioniert -fmerge-constants generell nicht ? Gibt es eine Doku aus der hervorgeht, was der avr-gcc gegenüber dem gcc NICHT macht ?
-
Thread
Besseren Code mit GCC erzeugen
Dem stimme ich zu, auch ich bevorzuge immer den besseren Source vor der Optimierung. Allerdings muß man auch zugestehen das gerade bei solchen Aufgaben wie oben der GCC so ziemlichen Schrott produziert. Sowas habe ich bisher noch von keinem Compiler gesehen, allerdings muß man
von Atmel: Du vergleichst da Äpfel mit Birnen. Bei den obigen Funktionen geht es nicht um die Optimierung von Zugriffen auf Speicherstruktureb sondern auf Register durch den GCC. Der GCC expandiert bei Formeln die Datentypen auf den größten verwendeten Datentyp. Bei einen Rechtsshift von einem uint32
-
Thread
'char* str' oder 'char *str'
ein Leerzeichen einfügen, aber nur konsistent, sonst leidet wieder die Optimierung. Lukas
gemacht"-Antworten, du solltest aber doch insgeheim Lukas glauben, der es auf den Punkt gebracht hat (gcc-Manual, Kapitel Optimierung, Abschnitt Verschiedenes).
-
Thread
* C++ == C++ *
Daniel A. schrieb im Beitrag #4721644: > Ja und ich mit gcc (Gentoo 4.9.3 p1.4, pie-0.6.4) 4.9.3: > [...] > A is not A gcc 4.6.1: A is A gcc 4.7.4: A is A gcc 4.9.2: A is not A Wir können ja eine Strichliste machen, wer rechter hat ;-)
Frank M. schrieb im Beitrag #4721662: > gcc 4.6.1: A is A > gcc 4.7.4: A is A > gcc 4.9.2: A is not A und jetzt bitte noch jerweils mit unterschiedlichen optimierungs optionen. Und selbst wenn: Das Verhalten ist undefined! sprich, wenn
-
Thread
Codevision Compiler oder AVR-GCC?
NAchtrag: Wenn es um Gleitkomma geht macht der CV den GCC allerdings nass. Wobei ich mir hier die Frage stelle ob der CV so gut oder der GCC so schlecht ist ;).
ich gedacht, daß ein Compiler, der speziell für >AVR geklöppelt wurde, besseren Code macht als ein GCC, dessen >Lebenszweck ja in erster Linie 32-Bit Architekturen sind... Theoretisch macht der CV das vielleicht auch. Es hapert an den höheren Optimierungs Routinen. Da werden z.B. Offsets für Array
-
Thread
AVR als EPROM benutzen (C-Optimierung)
[/c] Nur eigentlich wollte ich es ohne asm machen. Jemand eine Idee wie ich den C-Compiler (gcc) dazu bekomme es ohne die unnötigen OR zu machen? Mit nem Union wirds noch 3 Takt länger...
Man kann sich im Compiler-Explorer den generierten Code sofort ansehen: http://gcc.godbolt.org/ Leider unterstützt der Compiler-Explorer nur gcc-4.5.3 für den AVR, für die IA32/IA64 bis zur aktuellen Version 6.2. Ich kann eigentlich jedem nur empfehlen, sich das mal anzusehen
-
Thread
LCD Display trotz Initialisierung schwarz
die lcd-routines.c und lcd-routines.h zusammen mit einer main.c das erste Beispiel alle samt vom AVR-GCC-Turoial um allgemein mein LCD Display zu testen. [c]http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung[/c] Nun zeigt das Display nach der Initialisierung immer noch schwarze
schrieb im Beitrag #3936496: > Im makefile: > > OPTIMIZE = -O0 Das bedeutet 'keine Optimierung' und ist unsinnig. Die _delay_XX() Funktionen laufen gut mit der Optimierung auf Size, also '-Os'. Man sollte dafür allerdings FCPU *vor* dem '#include util/delay.h' definieren.
-
Thread
MikroC Compiler für PIC
ein Teil der Software nicht mehr richtig), probiere vielleicht Deine Projekte erst einmal ohne Optimierung aus.
Frank Bär schrieb im Beitrag #3443695: > Aufgrund der Art und Weise, wie die XC8-Optimierung funktioniert, wage > ich das zu bezweifeln. Ich arbeite mit dem XC32-Compiler, damit konnte ich diesen Effekt beobachten. (Zur XC8-Optimierung ziehe ich meine obige Aussage zurück.)
-
Thread
Frage an die Compilerbauer
der Geschichte: Dem Kompiler keine Knüppel zwischen die Beine werfen, dann klappts auch mit der Optimierung.
Es ist weder Die Compilerversion genannt noch für welches Device übersetzt wurde. Und ja, avr-gcc macht nicht immer den besten denkbaren Code, und das gilt auch für den Code, den er für Multiplikationen erzeugt — auch mit avr-gcc 4.9 oder 5.
-
Thread
Unklarheiten bei einem C Programm
nicht verstanden hat, daß es >> völlig sinnlos ist, Nullen durch die Gegend zu schieben. >Ohne Optimierung ergibt das ein paar verschleierte NOP ;-) Nope, das gibt nicht mal ohne optimierung NOPs, Konstanten löst bereits der C-Präprozessor auf.
setzt er eine 8 ein. Der Compiler bekommt die 3 und die 5 niemals > zu sehen. das schein mein GCC andere Meinung zu sein.
-
Thread
Variablen eine General Purpose Register Adresse zuweisen
(1) Es ist sinnlos, Register volatile zu machen (zumindest für GCC). GCC hat intern überhaupt nicht die Möglichleit, ein Register (GPR) als volatile zu markieren. Wer's nicht glaubt lese gcc/rtl.def :-) (2) 16-Bit-Variablen müssen in _geraden_ GPR-Nummern liegen
die nen Wolf. Oder zwei oder drei. Etwa bei Verwendung von STandard-Bibliotheken, Interrupts, etc. GCC kann globale Register _wegoptimieren_ . So gesehen in GCC 4.x, wo es als tot analysiert wurde (was es im Sinne von C auch war, da es asynchron verwendet werden sollte. Da solche Regs jedoch nicht volatile
-
Thread
static const PROGMEM in eigenes File auslagern
, also wohl GCC und damit auch LTO. (GCC-Versionen ohn LTO gab es natürlich auch, aber die haben eher ein H-Kennzeichen) > Mal ganz abgesehen davon ist es auch nicht "dreckig", wenn man Dateien > inkludiert, die
Compilers oder zusätzlicher Anweisungen an diesen (PROGMEM). Ich kann mir vorstellen, dass ganz ohne Optimierung das knallhart als Variable abgelegt wird. In C++ ist const ja etwas anders, als in C. Vermutlich macht hier aber bereits der gcc einen Strich durch die Rechnung. Aber nur darum geht es. Const
-
Thread
Was macht diese return Anweisung?
R25,0x00) eingespart werden könnte. Schlage es den Compiler-Entwicklern vor. BTW. mit welcher Optimierung arbeitest du? Vielleicht ist diese Optimierung schon drin ;-)
ist, daß sie nicht in einem anderen Sourcefile in einer Weise verwendet wird, in der eine solche Optimierung Probleme bereiten würde, dann und nur dann kann eine Optimierung wie du sie vorhast überhaupt stattfinden.
-
Thread
Compiler-Warnings für nicht initialisierte Variablen EINschalten
enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux Thread model: posix gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) [/c]
tictactoe schrieb im Beitrag #3616587: > Mein GCC warnt aber schon: Mist, ich habe wohl meinen eigenen Beitrag nicht gelesen: Yalu X. schrieb im Beitrag #3614474: > Es muss auch ein gewisser Grad an Optimierung aktiviert sein, damit der > Compiler
-
Thread
2 byte >> 1 word
einer 32-bit Maschine compiliert ein anderes Ergebnis liefert als auf einer 8-Bit Maschine (beide male gcc). Gr & Dank..
ein Compiler dafür entscheidet, > sich nicht daran zu halten, ist das eine andere Frage. Der avr-gcc hält > sich bei der fraglichen Zeile aber dran und rechnet in int. Der OP schreibt doch klar, dass er mit GCC auf dem PC und mit AVR-GCC auf dem Atmega unterschiedliche Ergebnisse bekommt, obwohl
-
Thread
Variableninitialisierung
ist anders, siehe unten. Mir ist wirklich kein C-Compiler bekannt, der selbst bei ausgiebigster Optimierung ganze Anweisungen, mit denen einer Variable ein Wert (0 oder sonstwas) zugewiesen wird, einfach wegläßt. Selbst der knöselige GCC macht sowas nicht. So. Und nun weswegen das Ganze? Wenn am
Beitrag #5288839: >> Mir ist wirklich kein C-Compiler bekannt, der selbst bei >> ausgiebigster Optimierung ganze Anweisungen, mit denen einer Variable >> ein Wert (0 oder sonstwas) zugewiesen wird, einfach wegläßt. Selbst der >> knöselige GCC macht sowas nicht. > > ACK. Ich wüsste nicht, wie ein
-
Thread
Generierten Assemblercode nach C Präprozessor + Compiler
[code] cpp datei.c [/code] Mit -dD bekommst du übrigens beides. Wenn du eine schon vorhandene gcc-Kommandozeile nutzen willst, kannst du statt cpp einfach gcc -E machen und die obigen Optionen anhängen. Nicht vergessen, evtl. ein -o foo.o zu entfernen, sonst schreibt er die Ausgabe da rein. >
Ja, Optimierung steht auf -Os. Ich hatte nur gehofft, dass es noch sowas wie das .s-File gibt, nur halt mit diesen Ausdrücken aufgelöst, soweit wie der Compiler das halt macht. Wegoptimieren dürfte er diese
-
Thread
[rant] Schleifen ohne Seiteneffekte - Jeden Tag steht ein neuer Amateur auf :-(
> > Nein. Tut er nicht. Jedenfalls nicht solange DU ihn nicht durch das > Einschalten der Optimierung dazu zwingst. Es ist nicht garantiert, dass der Compiler erst dann optimiert, wenn Du irgendeine Optimierung einschaltest. Vielmehr muss der Compiler nur ein gewünschtes Resultat erfüllen. Ein Delay über eine sinnlose Zählschleife muss er jedoch nicht garantieren - egal ob irgendeine Optimierung eingeschaltet ist oder nicht. Daher muss ich Dich korrigieren. Richtig ist: Du kannst von Glück reden, wenn er ohne Optimierungs-Option die Schleife tatsächlich in Code umsetzt. Meist ist
-
Thread
Professionelle Entwicklung für AVR-Controller (Linux)
von Mikrocontrollern braucht aber Tricks & Kniffe & Erfahrung. Widerstehe der Versuchung, die Optimierung auszuschalten, nur weil dein single stepping im Debugger nicht geht: du debuggst sonst einen komplett anderen Code. Ohne Optimierung ändert sich das Timing, manchmal so sehr, dass es keinen Sinn
https://www.iar.com/iar-embedded-workbench/certified-tools-for-functional-safety/ Deshalb auch kein gcc. Olaf
-
Thread
Optimierung in eclipse
Hallo Ich versuche mittels eclipse und avr gcc folgendes projekt zu übersetzen: http://www.recursion.jp/avrcdc/cdc-232.html Mit dem beigelegten AVRStudion Projekt File klappts in avrstudio einwandfrei. Der chip ist zu 99.5 % voll wenn ich
läuft auch nicht. Wenn ich es mit dem AVR Studio übersetze hingegen schon. Könnte da eine optimierung im spiel sein? wenn ja, wo kann man diese einstellungen verändern?
-
Thread
CMSIS und GNU Support
dem Timer 3 sondern dem Compare Channel 3. > Code. Es gibt verdammt gut optimierende Compiler - GCC gehört leider > nicht dazu So schlecht ist er nicht. > Momentan mache ich das Erste und mein Code der eigentlich noch kaum was > macht, belegt (ohne Optimierung) bereits über 50kbyte. Du
und drücken den .weak Reset_Handler mit einem eigenen korrekten Reset_Handler beiseite. Ein nackter GCC macht das nicht und deshalb grinsen sich die Damen und Herren Lizenzverkäufer einen ab, wenn andere damit auf die Fresse fliegen, mit GCC keinen Support haben bzw. selber nicht schnallen was fehlt.
-
Thread
Mikrocontroller mit integr. DAC
Die PICs werden leider nicht vom GCC unterstützt. Matthias
Software, distributed under GNU General Public License (GPL)." Das hörte sich für mich so an, als ob GCC für PIC nicht möglich wäre. "GNU-based, open source code" hört sich dann wieder etwas anders an. Was ist denn der Unterschied zwischen GCC und SDCC? Ist der GCC besser oder umgekehrt? Matthias
-
Thread
GCC schmiert ab wenn Optimierung an.
Hallo, an sich ist es ja eher ein schlechtes Zeichen, wenn der avr-gcc (Version 4.1.2 übrigens) RTL-Zeugs ausspuckt, aber was heißt das denn jetzt: avr-gcc -mmcu=atmega128 -Wall -Os -c -g -Wa,-a,-ad,-a=trig.lst trig.c trig.c: In function 'sincos90': trig.c:89: error
@yulu: Danke für das Angebot. Mit avr-gcc 4.2.1 gehts zwar, aber ich komme nach einer weiteren Optimierung ohne die den Fehler auslösende Anweisung aus. Das Problem war glaube ich mal die Multiplikation, denn da ruft er lt. Listing intern
-
Thread
Direkt-Initialisierung in ctor schlechter optimierbar als indirekt?
kompilierbaren Beispielen verlangen. Hast du noch zufällig konkrete Weisheiten über Inlining-Probleme des gcc?? Gcc schrieb im Beitrag #7198439: > Lieber TO, > der GCC erzeugt in allen Fällen genau den selben Code: > exakt 0 Byte. Lieber Gcc, es wäre schön, wenn das deine Fehlermeldung gewesen wäre
etwas zu dessen Lösung beitragen. ..wegen seiner Unschärferelation, oder doch seiner ..Katze..?? Gcc schrieb im Beitrag #7199215: > Da es hier wohl nur einen gibt, der wirklich was davon versteht, scheint > das Problem gelöst. Wenigstens das ist eine gelungene Darbietung: Genau was der gcc sagen
-
Thread
1-Bit Variable
geduldet. Die Mods hatten sich vor einiger Zeit geeinigt, das 'GCC' Forum mehr so als allgemeineres C-Forum anzusehen. Denn so klar ist das nicht, wo da jetzt die Grenze ist, was jetzt GCC spezifisch ist und was nicht. Wenn man es genau nimmt, dann wäre dieses Forum
jeden sich irgendwo eröffnenden Teilaspekt ein neues Forum aufmachen. Daher die Bitte an alle: das GCC im Forumstitel nicht allzu eng zu sehen. Seht es mehr als Forum für Programmierprobleme unter Verewndung von C an. Ob das dann GCC spezifisch ist oder nicht, ist dagegen nicht mehr so ganz der entscheidende
-
Thread
Warum uint8_t in 2 Registern?
tobi schrieb: > Hallo, > > ich habe mir gerade etwas Code angeguckt, der vom GCC prouziert worden > ist. Dabei wunder ich mich darüber, dass adiw genutzt wird um einen > uint8_t zu inkrementieren. gcc ist bekannt dafür manchmal 16 Bit Arithmetik zu benutzen, wenn eigentlich
nicht bedacht. Dann ist klar, dass dort ein Subroutine genutzt werden muss. Gibt es denn eine Optimierung, mit der der GCC wirklich nur 8 Bit Arithmetik betreibt? Habe mich bislang noch nicht wirklich mit den Optimierungen des avrgcc befasst.
-
Thread
undefined combination of operands
Von AVR-GCC 3.4.6 zu 4.1.1 wurden sehr viele Änderungen vorgenommen, die wohl ne Menge Seiteneffekte haben. Insbesondere bei der Optimierung gibts einige Überraschungen (Reordering, manchmal größerer Code).
Peter Dannegger wrote: > Von AVR-GCC 3.4.6 zu 4.1.1 wurden sehr viele Änderungen vorgenommen, > die wohl ne Menge Seiteneffekte haben. Du weißt es ja so genau: welche denn? > Insbesondere bei der Optimierung gibts einige Überraschungen
-
Thread
kompilerdifferenzen zwischen gcc 4.3.3 /4.4.3 oder DAUfehler -- Ich weiß nicht mehr weiter.
Frank Muenzner schrieb im Beitrag #2029691: > wie kann ich gcc zwingen bestimmte statements zu kompilieren bsbw die > nops? 1. GCC umschreiben oder 2. Inline Assembler, z.B [code] #define NOP __asm ("nop") [/code]
stackgröße festgelegt? Anbei das Makefile - vielleicht geht da ja die stackgröße hervor? geht bei gcc mit sicherheit auch - ich weiß rfm.... kann trotzdem mal jemand draufschauen und mir sagen wie ich die optimierung rausnehme? ####################################################################
-
Thread
WinAVR & AVRStudio
Meldungen zu sehen: D@00000000: _delay_ms ---- UNKNOWN_FILE oder auch: ---- D:\projekte_avr\avr_gcc_tutorial\Delay_Test2\default/c:/winavr/lib/gcc/../../avr/include/util/delay_basic.h 105: File not found Vielen Danke für jede Unterstützung Reiner
Windows Pfaden. Also so [code]for /R avr\lib\ %a in (*.a *.o) do bin\avr-strip -g "%a" for /R lib\gcc\avr\ %a in (*.a *.o) do bin\avr-strip -g "%a"[/code]
-
Thread
ATmega2561 Problem mit WinAVR
- keit, sein internes Wissen darüber, was die Funktionen der Standardbibliothek machen, für Optimierungen zu nutzen.
Hallo Zusammen, auch ich habe Probleme von ATmega128 auf 2561 zu gehen. Mit Optimierungen (-Os/-O2) ist alles ok. mit Optimierung (-O1) nicht mehr Warnings, aaaber Funktionspointereien scheinen schief zu gehen, ohne Optimierung (-O0) plötzlich knapp 400 Warnings, z.B.: (.text
-
Thread
Umstieg von Atmega8 auf Atmega168 LCD initialisiert nicht mehr
>Ich nutze avr-gcc (WinAVR 20100110) 4.3.3. Mein Compiler ist noch 4.3.0. >Habe nun make_clean und neu kompiliert. Habe das Verzeichnis geändert >und aus dem neuen Verzeichnis geflasht. >Habe vom festen PC
Optimierungsprobleme in den > Zeitschleifen (Timing). Ganz im Gegenteil, die Delay.h des AVR-GCC benötigt die Optimierung, vorzugsweise -Os. Mit -O0 geht sie total falsch. Peter
-
Thread
Compiler schreiben
jedesmal neu erfinden muss waere doch eine Moeglichkeit einen Freeware-Compiler wie beispielsweise den GCC als Vorlage zu nehmen und 'nur' die Optimierungs- und Assemblierungsphase durch meine eigene zu ersetzen, oder? Dann braeuchte ich mir beispielsweise keine Gedanken ueber Parsing etc. von C zu machen
Der GCC ist für so was "ideal" da er genau für so was vorbereitet ist und Du nur das so genannte "Backend" schreiben müstest. Das "Frontend", sprich Parsing, Code-baum und Teile der Optimierung sind für alle
-
Thread
Mein neuer Lieblingsmikrocontroller
bietet den C30 für privaten Einsatz kostenlos. Es fehlt gegenüber der Vollversion ein bischen Optimierung und ist seitens Microchip eine Gratwanderung, denn technisch ist das der bekannte GCC plus ein herstellerspezifischer Optimierungslauf. Ist verwendbar. Programmierung und Debugging läuft über
den Optimizer-Pass einbindet, wobei meiner Erinnerung nach ohne Vollversion auch ein paar normale GCC Optimierungen dran glauben müssen. Die Lizenzprüfung selbst erfolgt wieder mit einem externen Programm und ist nicht ins GCC direkt eingebunden. Auch hier man damit wohl GPL-sicher, aber möglicherweise
-
Thread
Probleme mit der Case switch anweisung
Und es gibt durchaus auch eigene Fehler, die erst bei eingeschalteter Optimierung auffallen (vergessenes volatile ist da wahrscheinlich der Spitzenreiter). Insofern ist die Geschichte nicht unglaubwürdig, nur die Schlußfolgerung daraus ist falsch ("keine Optimierung einschalten
für solche Funktionen ggf. den Weg wählen, wie er solche Anwendungen dokumentiert ist, z.B. beim AVR-GCC bzw. WinAVR mit ISR() arbeiten.
-
Thread
Fliesskomma ARM7 GCC
im Beitrag #2808298: >> Verwendete GNU Toolchain ist aus dem Paket von >> https://launchpad.net/gcc-arm-embedded > > Wenn ich das recht verstehe, basiert das auf dem arm-embedded Branch von > GCC, nicht auf dem Hauptzweig der GCC-Entwicklung? Das weiss ich nicht. Aber auf deren Seite gibt es
tun. Daraus lassen sich dann ja wieder Konflikt- und Hunk-freie Patches erzeugen. [1] http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
-
Thread
avr-gcc: den Zugriff auf register variablen optimieren?
Nachtrag: http://www.mikrocontroller.net/topic/wie-optimiert-man-systematisch-avr-gcc Oliver
avr-gcc-3.4.x: [pre]warning: volatile register variables don't work as you might wish[/pre] avr-gcc-4.5.x: [pre]warning: optimization may eliminate reads and/or writes to register variables warning: call-clobbered
-
Thread
Bascom - C Umstieg Teil 1 - IDE-Probleme
optimizations disabled; functions from <util/delay.h> won't work as > designed" [-Wcpp] Und die Optimierung einschalten.
die beiden anderen Fehler bestehen: [code] -------------- Build: Debug in test3 (compiler: GNU GCC Compiler for AVR)--------------- avr-gcc -Wall -mmcu=atxmega128a1u -DF_CPU=2000000UL -g -Os -I/usr/include -c main.c -o obj/Debug/main.o avr-gcc -L/usr/lib -o bin/Debug/test3.elf obj/Debug/fuse.o
-
Thread
Compilereinstellung für möglichst kompakten Code (gcc)
in WinAVR-20090313 bzw. WinAVR-20081205 nicht zum Tragen kommt. Die obigen -f Optionen sind für gcc 4.x (also auch für avr-gcc 4.x), die -m nur für avr-gcc. Den kleinsten Code erhalte ich mit avr-gcc 3.4.6, allerdings hab ich noch nicht mit avr-gcc 4.4.0 oder avr-gcc 4.5 verglichen, nur gegen <
Beschreibung > zu deren Verwendung? > > Grüße Chris Erste Hinweise erhält man per [pre] avr-gcc -v --help [/pre] eine auf Optimierung gefilterte Ausgabe mit [pre] avr-gcc --help=optimizers [/pre] Etwas mehr Prosa gibt's direkt bei gcc: http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/
-
Thread
C (MinGW): Unerwartete Bool-Auswertung
Ich kann dein Ergebnis mit dem GCC ("gcc (Debian 8.3.0-6) 8.3.0") *nicht* nachvollziehen (Minimalbeispiel): [code] #include <stdint.h> #include <stdio.h> #include <stdbool.h> volatile bool r; volatile bool s; int main(
schrieb im Beitrag #5974140: > clang schafft es es bis Version 8 nicht, eine Warnung zu generieren. > GCC 5 ebenfalls nicht, GCC 8 wirft eine Warnung Danke fürs Gegentesten. Dann kann ich das Problem wohl auf meinen GCC 5.1.0 zurückführen. Es wird wohl mal Zeit für ein Update. Ich werde mich künftig
-
Thread
gcc komischer fehler: sbrk() Gesperrt
wie gewohnt. void* _sbrk() { return 0; } Was bewirkt diese funktion und weshalb benötigt der gcc diese unbedingt?
stattdessen: [c] puts("Foo!"); [/c] (Man beachte das weggelassene '\n'.) Solche Optimierungen können natürlich durchaus wünschenswert sein, bspw. bringt: [c] i = strlen("Foo!"); [/c] dann die Konstante 4, die der Compiler direkt so benutzen kann. Wenn man all diese Optimierungen
-
Thread
Timer Interrupt STM32F103
also LEDS usw alles raus. Du kannst das im Debugger gut sehen. Ich arbeite mit Embitz 1.0 und dem GCC. Ich empfehle Dir den Code erstmal mit O0 zu kompilieren und dann schrittweise zu optimieren. In meiner Firma sind Optimierungen per Coding Richtlinien ganz verboten und das aus gutem Grund. Ich
Diesen Zirkus hatte ich auch mal. Es lag letztlich daran, dass ich mit > den Optimierungsstufen des GCC Murks gebaut hatte. Schaltete ich die > alle ab lief es wieder. Das liegt in 99% der Fälle nicht an den Optimierungsstufen, sondern an Fehlern im Quelltext. Die Lösung ist dann nicht, die Optimierung