-
Thread
Funktion aus Interrupt aufrufen
Hallo, ich versuche grade, mit GCC ein kleines Programm für ARM (LPC2378) zu compilieren. Das Programm verfügt über eine Interruptfunktion namens tick, die von einem Timer (Timer0) periodisch alle 1 ms aufgerufen wird. So, der Interrupt
Das habe ich schon gefunden. Das Problem wird aber nicht behoben, wenn die die Optimierung auf "none" umstelle. Dann läuft das Programm ebenfalls nicht. Was ich mich aber frage - wie dumm ist der GCC denn, dass er aus einem Interrupt heraus keine andere Funktion aufrufen kann? das
-
Thread
Günstiges und einfaches Mini-Controller Board, was würdet ihr heute nehmen?
int main(void) {' >> main.c > echo ' printf("Hello World!\n");' >> main.c > echo '}' >> main.c > gcc -o main main.c > ./main Noch einfacher: [pre] gcc -xc - && a.out #include <stdio.h> int main(void) { printf("Hello World!\n"); } ^D [/pre] Da die erste Zeile sowieso immer gleich
Beitrag #7993214: > die Zertifizierung für > sicherheitskritische Systeme, und höchste Compiler-Optimierung sind auch für gewerbliche Hersteller in den wenigsten Fällen notwendig. ciao Marci
-
Thread
NUCLEO-L432KC Blinky Projekt mit 11kB Speicherverbrauch
Optimierung -Os Striping Symbols -s -Wl,--gc-sections und -ffunction-sections -fdata-sections -flto Bin ich auf 5704 statt 11048bytes Keil Compiler vom Kollegen liefert 4008bytes
erstmal der größte Brocken der Libraries dazu gepackt. GCC ist ein bisschen größer, aber trotzdem noch in Ordnung. Bisher war das um die 30% mehr Speicher.
-
Thread
warning: internal error: out of range error
/winavr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr6\libc.a(dtoa_prf.o): In function `dtoa_prf': (.text+0x6): warning: internal error: out of range error c:/programme/winavr/bin/../lib/gcc/avr/4.3.2/../../../../avr
Ich fürchte jetzt muss jemand ran, der gcc-avr für >128KB und die binutils von innen kennt.
-
Thread
Komisches Verhalten des Optimierers
Zumindest korrekt... schon mal nicht unwichtig :o) > Ich arbeite mit Rowley Crossworks und die Optimierung ist auf Size > gestellt. Rowley basiert wohl auf GCC? Ich hatte ähnlichen Ärger mit neuen gcc 4.3.x für AVR: Schleifen wurden aufgerollt trotz -Os, -fno-unroll-loops et. al. blieben erfolglos
ist die Wahrscheinlichkeit größer, daß das Problem bald gefixt wird. Hier wäre dann http://gcc.gnu.org/ml/gcc-help die richtige Anlaufstelle. Das Anrollen der Schleife passiert wahrscheinlich im Target-unabhängigen Teil. Wo genau, siehst du mit Ausgaben per -fdump-tree-all. Falls der böse
-
Thread
C Neuling benötigt Schubs in die richtige Richtung Gesperrt
Hinweise. Gruß Torsten Nachtrag: auch wenn ich CodeBlocks verwende, so wird dort von mir der GNU GCC Compiler genutzt.
eher Java und .NET?), C++ hat sich wegen der tollen IDE durchgesetzt (welche soll das nochmal sein, gcc + vim?), etc. pp.
-
Thread
Atmel Studio erzeugt aus C Assembler Code? Gesperrt
so richtig? Das ist nicht nur bei Atmel Studio (Version 6 oder höher) so, sondern bei allem, was gcc verwendet, da der gcc das (wie die meisten C-Compiler) so macht. > Und wenn ja, wie oder wo kann ich mir in Atmel Studio das erzeugte > Assembler File ansehen? Wenn du dem Compiler die Option
Ende die Buchstaben so auf dem Papier stehen wie ich diese eingetippt habe. Und es mag sein, das GCC das non plus Ultra bei den C-Compilern ist. ...hmm...von mir aus..., aber es stellt sich für mich jetzt nur die Frage, wenn doch der GCC aus C-Code ein Assembler Code erzeugt, warum programmiert man
-
Thread
C-Code mit AVR-Studio-Simulator debuggen möglich?
Stel die Optimierung mal auf '1' oder '2', bei 's' kommt der Debugger gerne mal aus dem Tritt. Und dass dein Programm nicht besonders sinnvoll ist, ist dir hoffentlich auch schon aufgefallen ;) hth. Jörg
} hab da extra noch das r++; in die schleife geschrieben geht aber immer noch nicht. die optimierung hatte ich auch schon auf 1 und 2 umgeschalten. geht auch nicht. was kann das dann noch sein? bin froh um jede hilfe? gruss raphael
-
Thread
mega 32 compilerfehler
unnötigen Schritt zuviel. Also kann man den auch wegoptimieren... Und noch lustiger wird es beim gcc-4.x mit Tail-Call-Optimierungen, besonders in rekursiven Funktionen. Da kann man dann in C fast schon so wie in LISP programmieren, und trotzdem gibt's kein Stack-Overflow. ;-)
mehreren Quellecodezeilen zuzuordnen. Das ist der wohlbekannte Pferdefuss bei eingeschalteter Code-Optimierung des Compilers. Weshalb in solchem Kontext auch immer der Tip gegeben wird, bei Nutzung des Debuggers die Code-Optimierung durch den Compiler abzuschalten. Was bei Controllern freilich bisweilen
-
Thread
Stromverbrauch von Webdeployments
Schon etwas älter, aber nett zum Durchblättern, wenn man sich für HTTP(s)-Server-Optimierung interessiert: http://nabstreamingsummit.com/wp-content/uploads/2022/05/2022-Streaming-Summit-Netflix.pdf
Huebi H. schrieb im Beitrag #7566445: > Ruhig auch mal den ICC von Intel, anstatt des gcc ausprobieren. Das liegt auch an Patenten, die gcc nicht zur Optimierung verwenden kann, bzw. warten darf bis diese ausgelaufen sind.
-
Thread
for(; ;) - Schleife
Und weil ältere Compiler mit wenig Sinn für Optimierung einzig daraus wirklich eine Schleife ohne sinnlosen Test gemacht haben.
Rolf, Du schreibst also ne Schleife in ne schlecht lesbare Rekursion um. Und was macht der AVR-GCC daraus ? Er formt es wieder in ne Schleife um ! Weg mit all den überflüssigen PUSH, POP, CALL und RET. Wow, hätte ich dem GCC nicht zugetraut. Nur das Inlinen von spi_out2 in spi_out packt
-
Thread
Variable nicht initialisiert
Aus dem gcc-Manual: [c] #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wuninitialized" foo(b); /* no diagnostic for this one */ #pragma GCC diagnostic pop [/c] Geht
auch schon wieder viel programmspeicher beim initialisieren. Atmel Studio 6.2 (projekt fur AVR), GCC 4.8.1, optimierung ist abgeschaltet Lokal ohne Initialisierung: [c] #include <stdint.h> int main(void) { uint64_t a0; uint64_t a1; uint64_t a2; uint64_t a3; uint64_t a4; uint64
-
Thread
Linken usw in der Eingabeafforderung
8 MHz, platzsparende Optimierung): Compiling C: test.c avr-gcc -c -mmcu=atmega128 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./test.lst -std=gnu99 -Wundef -MMD -MP -MF .dep/test.o.d test.c -o test.o Linking: test.elf avr-gcc -mmcu=atmega128 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=test.o -std=gnu99 -Wundef -MMD -MP -MF .dep
-
Thread
verschachteltes Makro
. http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Function-Attributes.html
zu halten. Eine modulinterne Funktion ("static"), die nur einmal gerufen wird, expandiert der GCC bei eingeschalteter Optimierung immer inline.
-
Thread
LCD C-Code so groß?
Optimierung nicht eingeschaltet oder floatingpoint verwendet?
auch? F_CPU ist in den Projekteinstellungen, falls du das meinst. Wie gesagt jetzt mit der Optimierung ist der Code nur noch 356Byte groß
-
Thread
code Optimierung bei 32 bit Variablen
sagen können. Was für eine Platform? 8Bit, 32Bit? Schuss ins blaue: Der Compiler wird das mit Optimierungen schon gescheit machen.
hallo, avr-gcc ist der compiler und die plattform atmega 8 bit. @ Peter auf die idee bin ich noch nicht gekommen, das vorher klarzumachen und die schleife dann einfach laufen zu lassen... probier ich gleich
-
Thread
2.2'TFT ILI9340 und Arduino
überhaupt nicht vorschlagen. Der Thread ist eine Hilfestellung für die Inbetriebnahme und die Optimierung des Displays. Wenn Du genau hinschaust, findest Du einige Ergebnisse: 1. beschleunigtes Kurvenzeichnen für Analogsignal 2. Hinweise zur Optimierung der SPI am Arduino DUE 3. Link auf das schwer
nur mit Kanonen auf... Nein halt, anders rum... Mit Spatzen auf Kanonen geschossen. Nimm normales GCC, das können dann die Laien in ihrer ArduinoDingens kompilieren und man hat auch was fürs GCC.
-
Thread
HEX Größe verzehnfacht durch if Abfrage
> es. Wenn ich die if Abfrage auskommentiere funktioniert es auch. Nur > zusammen nicht. Optimierungen sind an? Wenn du summe änderst, aber nicht nutzt, schmeißt der Optimierer die Änderung logischerweise raus. Ergo ist sqrt dein Problem.
Marian B. schrieb im Beitrag #3741610: > Optimierungen sind an? Wie schauts mit der Antwort auf die Frage aus?
-
Thread
avr-compiler erkennen
http://www.google.de/search?q=avr-gcc+predefined+macros
OPTIMIZE__ 1 #define __STRICT_ANSI__ 1 #define __VERSION__ "4.3.2" [/c] Es wurde also mit avr-gcc 4.3.2 erzeugt. Optimierung war aktiviert (auf Größe), der µC gehört zur Familie 4 (ATmega8, ATmega88, ...), er verfügt über Multiplikationsbefehle, MOVW und die erweiterte Version von LPM, arbeitet
-
Thread
Zähler: erzeugte exe viel zu groß
dem GCC hineinbekommen kann? Wo kommt die riesige Codelänge her? Vielen Dank für Eure Beiträge.
Das Standard-Makefile vom gcc packt wohl tausend libs dazu. Schau mal, was man da entfernen kann. Markus
-
Thread
FIFO Implementierung (Array vs Pointer)
aus einer Modulo-Operation mit 2^N schon selber eine einfache AND-Operation machen, die manuelle Optimierung ist dann überflüssig. Ähnlich ist es mit 256 Bytes, auch hier sollte man die Optimierung eher dem Compiler überlassen. Wobei Rechnungen mit "unsigned char" als "int", also mit Vorzeichen durchgeführt werden, und diese AND-Optimierung dann nicht so einfach ist. Es kann also sinnvoll sein, explizit nach "unsigned" zu casten: index = (unsigned)(index + 1) % BUFSIZE; Optimierung von Datentypen lässt sich recht ubersichtlich
-
Thread
PIC24 @ 80MHz und Timer1 zu langsam?
40MHz/55/2=363kHz. Kommt also in etwa hin. Der Assemblercode ist ziemlich ineffizient, sind die Optimierungen an?
edit: Hab die Option für Code-Optimierung gefunden. Ist schon auf Maximum.
-
Thread
Überlauf bei Multiplikation verhindern
. Walter ist mir bisher nicht als jemand aufgefallen, der exzessiv Zeit in unsinnige Mikro- Optimierung steckt. :) Andernfalls hast Du natürlich Recht.
Headroom" hat bis zum Überlauf. Weiters gibt es compilerspezifische Built-ins, siehe etwa http://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html Allerdings _verhindern_ die keinen Overflow (wie von dir gewünscht), sondern lassen ihn lediglich erkennen. Einen Overflow verhindern geht nur
-
Thread
Suffix für uint8_t
dem mit & vergleichen. Oder, wenn es so zeitkritisch ist, Assembler nehmen. Hast du die Optimierung an? Welche?
A. K. schrieb im Beitrag #4414555: > lässt GCC deshalb 2 Indizes parallel laufen, einer mit 32 fürs Zählen > und einer mit 64 Bits fürs Adressieren, weil i negativ sein kann: Das war Unsinn. Komplizierter als mit 64-Bit Variablen ist der Code
-
Thread
Warum ausgerechnet "PIC"?
@Dominik Ein Compiler ohne Optimierung? (Ich meine in dem Fall, dass man nicht alle 60 Tage reinstallieren möchte...) Beim WinAVR brauche ich die Optimierung dringend! Dabei geht es weniger um die Code-Größe als mehr die Geschwindigkeit
@MSE Tja wollte zwar gestern schon antworten aber der Server war ja down. Die Optimierung vom C18 wird natürlich nicht komplett abgeschaltet - der schaltet da nur die Optimierung auf die PIC18 Serie ab - also das mit dem "Erweiterten Befehlssatz". Viel ändert sich dadurch am Code aber
-
Thread
-Os Optimierung: Programmcode wird nicht ausgeführt
Ich habe folgende Situation. Wenn ich das Atmega-Programm (C) nur mit einer anderen oder gar keinen GCC Optimierung compile, funktioniert alles wunderbar. Wird jedoch die Optimierung auf -Os geschaltet, spring das Programm nicht an die gewünschte Stelle. Das sieht ca so aus #define KURZ 0x00 #define
-
Thread
ARM Cortex & GCC: Worauf achten für "optimalen" Code?
:) Wo ich nun eher Anlaufschwierigkeiten habe ist der GCC, beispielsweise wie die Variablen bzgl. Speichermanagement gehandhabt werden, wie Parameterübergabe stattfindet, etc. Ich komm leider momentan mit der in der LPCxpresso-IDE mitgelieferten GCC-Hilfe
A. K. schrieb im Beitrag #2111097: >> ist. Wie ist das beim GCC & ARM? Wenn ich vier 8-Bit-Variablen (char) >> anlege, packt der GCC das automatisch in ein 32-Bit-Wort, oder verwendet >> er vier Mal ein 32-Bit-Wort? > > Register: jede einzeln in ein Register
-
Thread
Compiler für dsPic33FJ64
Rudolph R. schrieb im Beitrag #4138113: > Wenn der Unterschied so gross wäre wie dem GCC für AVR bei dem der Code > zwischen -O0 und -O3/-Os ganz erheblich anders ist, das würde mich schon > stören. Du bekommst in der freien Version -O1. Schön sieht das ganze in Assembler allerdings
. Vergleiche machen erst ab -O1 Sinn. Nebenbei: Wenn Du flink bist, kannst Du die volle Optimierung nutzen. 60 Tage Evaluierung der PRO Version ist möglich.
-
Thread
Division fehlerhaft
im Beitrag #3697934: > daß der Kompiler einfach Sachen nach Gutdünken > wegoptimiert Für die Optimierung gibt es ja Regeln und eine ist die "as if" Regel. Die *Funktion* des Codes muss nach der optimierung so sein *als ob* der Compiler nichts getan hätte. Das der Code nicht immer das macht was der
würde ich zum Testen des Programmes erzwingen > wollen, daß nichts optimiert wird Einfach die Optimierung ausschalten. Grüße
-
Thread
Debugger springt in's Nirvana
und b) Weil du das Tutorial nicht gelesen hast. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Zugriff_auf_IO-Ports Oliver
Wie ja schon weiter oben erwähnt wurde, hast du vermutlich mit Optimierung kompiliert. Da passen dann Sourcecode und Assemblerprogramm nicht mehr 1:1 zusammen, mit eben solchen Effekten. Schalte mal in den Projektoptionen die Optimierung aus, dann klappts auch mit dem
-
Thread
AVR TSIC Auswertung => riesen Programm
Darf ich noch ketzerisch ein "Optimierung aktiviert?" einwerfen?
-Os meinst, dann muss ich sagen die ist aktiviert... Gibt es sonst noch Möglichkeiten eine Optimierung zu Aktivieren?
-
Thread
40Bit Datentyp selber basteln
AVR IAR C/C++ Compiler??? Nein, auf keinen Fall. Meine Assemblerdatei läuft nur mit dem AVR-GCC. Sie benutzt dessen Registerzuweisung und Funktionsnamen. Peter
ist auf Codegröße optimiert, nicht auf Laufzeit. Die Laufzeit ist zwar auch schneller als die AVR-GCC Lib, aber der IAR wird bestimmt besser optimiert sein. Peter
-
Thread
Programmoptimierung
bitte nächstes mal einen etwas besseren Threadtitel! Was hat das ganze den Bitte mit Programm"optimierung" zu tun?
drin bin. Karl heinz Buchegger schrieb im Beitrag #1732937: > Für solche Sachen sollte das AVR-GCC-Tutorial deine erste Anlaufstelle > sein Das erwähnte "irgendwo" schliesst das AVR-GCC-Tutorial mit ein. Dort habe ich schon viele Lösungen für Probleme gefunden. Karl heinz Buchegger schrieb
-
Thread
Bit setzen in C Gesperrt
bei Baud vs. Bit/s, und jetzt das hier... bist du irgendwie auf dem Troll-Trip? Hans, ist die Optimierung eingeschaltet? Dass ein Compiler wie Keil eine so einfache Ersetzung nicht hinbekommt kann ich mir nicht vorstellen. Andere Compiler (z.B. AVR-GCC) schaffen das auch ohne dass man ihnen explizit
leistet. Und das hast du ganz alleine geschafft? Nicht schlecht. Ich deinstalliere sofort den GCC.
-
Thread
Attribute used im gcc
--includedir=/usr/lib/gcc/riscv32-unknown-elf/8.5.0/include --datadir=/usr/share/gcc-data/riscv32-unknown-elf/8.5.0 --mandir=/usr/share/gcc-data/riscv32-unknown-elf/8.5.0/man --infodir=/usr/share/gcc-data/riscv32-unknown-elf
without-isl --disable-libsanitizer --disable-default-pie --enable-default-ssp Thread-Modell: single gcc-Version 8.5.0 (Gentoo 8.5.0-r1 p2) COMPILER_PATH=/usr/libexec/gcc/riscv32-unknown-elf/8.5.0/:/usr/libexec/gcc/riscv32-unknown-elf/8.5.0/:/usr/libexec/gcc/riscv32-unknown-elf/:/usr/lib/gcc/riscv32-
-
Thread
mal wieder Busy-Flag
übrigens nur /mit/ Optimierung korrekt funktionieren.
Dich aber nicht stört, daß Code 1000% größer ist und 1000% länger braucht, dann schalte ruhig die Optimierung aus, statt einfach das Datenblatt zu lesen und das richtige Timing zu implementieren. Der AVR-GCC macht es einem doch sehr leicht, korrekte Timings zu implementieren mit den Macros der Delay.h
-
Thread
Warum kann der Compiler nicht erkennen, daß Variable in ISR geändert wird?
den Code ziemlich direkt wie er dastand, ohne sonderlich eindrucksvolle statement-übergreifende Optimierung. Weshalb volatile auch nicht ernsthaft benötigt wurde. Als die Compiler besser wurden, weil es genug RAM dafür gab, änderte sich das und es kam volatile.
Absichtlich, oder zu faul zum optimieren? ??? Wo landendenn globale Variablen beim C compiler? (Ohne Optimierung!) ???
-
Thread
Frage zu IR-Remote+LED-Strips an AVR
offiziellen 50us Maximalpause vorhanden ist. Aus Interesse habe ich mir vor einiger Zeit mal den vom AVR-GCC erstellten Assembler Code (zu finden in der *.LSS Datei im Kopilerordner) für eine ISR angesehen... Je nach Optimierung des Compilers kann man für das Pushen / Pullen der uC Register auf den Stack
50us Maximalpause vorhanden ist. > >>Aus Interesse habe ich mir vor einiger Zeit mal den vom AVR-GCC >>erstellten Assembler Code (zu finden in der *.LSS Datei im >>Kopilerordner) für eine ISR angesehen... > > Und was hast du gesehen? Wieviele Takte wurden benötigt? > >>Je nach Optimierung des
-
Thread
WinAVR+Eclipse->region text is full
Eclipse3.3"+"CDT4"+"avr-eclipse"+"WinAVR": [pre] Building file: ../y1.c Invoking: Compiler avr-gcc -Wall -g -O2 -Os -c -mmcu=atmega88 -DF_CPU=16000000 -o"y1.obj" "../y1.c" Finished building: ../y1.c [/pre] Linkerausgabe aus "PN"+"MFile"+"WinAVR": [pre] Linking: x.elf avr-gcc -mmcu=atmega88
hallo, hat vielleicht gar nicts damit zu tun, aber: >avr-gcc -Wall -g -O2 -Os -c -mmcu=atmega88 -DF_CPU=16000000 -o"y1.obj" "../y1.c" was bewirkt die zweimalige angabe der optimierung .. *grübel* bye kosmo
-
Thread
AVR-GCC Inline-Assembler: const Pointer / Arrays etc. als Operanden
http://www.rn-wissen.de/index.php/Inline-Assembler_in_avr-gcc
kannst du natürlich genauso machen. > Das möchte ich gern in Inline-Assembler übernehmen Um was GCC-generiertes in Inline-Assembler zu übernehmen, ist ein Disassembly ne schlechte Vorlage. Besser ist, die Compiler-Ausgabe selbst zu verwenden, evtl. nach Hand-Optimierung.
-
Thread
AtmelStudio 7 - Long variable übergeben
Schau mal hier, https://gcc.gnu.org/wiki/avr-gcc was bei einem 8-Bit-Prozessor mit GCC long bedeutet (oder versuche mal "long long" :-) )
Dieter F. schrieb im Beitrag #5193791: > Schau mal hier, > > https://gcc.gnu.org/wiki/avr-gcc > > was bei einem 8-Bit-Prozessor mit GCC long bedeutet (oder versuche mal > "long long" :-) ) was meinst du damit? eine 10 passt doch wohl in 32bit rein.
-
Thread
Fehler im gcc, im Chip oder im Hirn?
Interrupts? 'volatile' vergessen? Warum struct, wenn Du eh nur einen Member hast? Ansonsten, welche gcc Version? Ist das im Simulator oder auf realer HW? Welcher µC?
/avr-gcc/ Hier ist der zugehörige Thread: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631
-
Thread
TÜV-SÜD-zertifizierte MPLAB-Tools
Der XC32 ist ja anscheinend GCC-basiert. Heißt das jetzt etwa, dass der ARM GCC und G++ für sicherheitskritische Dinge nutzbar ist, und man dort dann auch aktuelle Sprachstandards nutzen kann (C18, C++17)?
Programmierer schrieb im Beitrag #6117665: > Der XC32 ist ja anscheinend GCC-basiert. Heißt das jetzt etwa, dass der > ARM GCC und G++ für sicherheitskritische Dinge nutzbar ist, und man dort > dann auch aktuelle Sprachstandards nutzen kann (C18, C++17)? GCC? Bist du
-
Thread
C Compiler ISR
://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html#ARM-Function-Attributes https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes https://gcc.gnu.org/onlinedocs/gcc
Prolog / Epilog wird ausgegeben von "riscv_expand_prologue" bzw. "riscv_expand_epilogue". https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/riscv/riscv.c?view=markup
-
Thread
Deklaration von external memory
Datendefinition. Vergiss diese Erbsenzählerrei! https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung > Ich würde gerne >mal eine Baustelle (hier Datendefinition) endgültig abschließen um mich >dann in Ruhe der nächsten zu widmen, ohne am Schluss des
Thomas P. (topla) > Vergiss diese Erbsenzählerrei! > > https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung Ja, ist vielleicht ein Geburtsfehler bei mir. Ich mag auch vorzeigbares Innenleben, bei Geräten wie bei Software. > Ach was, du malst nur den Teufel
-
Thread
AT90USB162 Endpoint Interrupts funktionieren nicht
Nur mal so: Compiler-Optimierung hast du eingeschaltet, ja?
#6879140: > Interesant, mit "optimize most (-O3)" geht es wieder. Muss eigentlich mit jeglicher Optimierung zum Laufen zu bekommen sein, nur -O0 (Optimierung ausgeschaltet) ist fragwürdig. Ich denke, du hast da noch irgendeine andere Sache drin. Marvin K. schrieb im Beitrag #6879135: > Ich habe
-
Thread
ATmega16 + ATmega32 in C Programmieren
Du kannst mit AVR Studio einfach ein Projekt anlegen und wählst AVR.GCC als Compiler aus. Den Rest (einschliesslich makefile) macht avr-studio für Dich. Einfache Beispiele findest Du hier im avr-gcc tutorial (siehe links auf der linken seite)
Die Spalte links, wo steht "AVR-GCC-Tutorial"
-
Thread
MSP430 IAR: String1 in String2 Kopieren??
Sollte wohl genauer lesen ;) Ich wollte für mein Projekt mal diese String-Funktionen benutzen (GCC). Als ich sie zugelinkt hatte, war das Programm gleich ziemlich aufgeblasen, dann hab ich mir das Vergleichen der Strings selber geschrieben, hat viel weniger gebraucht. Vielleicht muss man dem GCC
AVR und dem MSP430 > Compiler. Ich arbeite nur mit den MSPs. Das könnte sein. Ich benutze den gcc für AVR. Ob und wie der Linker diese Optimierung machen kann, hängt beim gcc auch davon ab, wie diese Libraries aufgebaut werden. In der AVR Version kann er es offensichtlich.
-
Thread
Minimalbeispiel zur Darstellung effizienter Schleifen
Ja, Schleife ist sinnlos -> weg damit. Macht quasi jeder optimierende Übersetzer so. Für GCC: Option -O0 (Oh-Null).
. Ergebnis der Optimierung: ret Effizienter geht es kaum noch, man könnte nur noch inlinen und sämtliche Aufrufe von main() rauschmeißen [was aber wohl kein Compiler machen würde, weil ne leere Main ja nicht gerade üblich
-
Thread
Fehlermeldung Bedeutung
was bedeutet folgende Fehlermeldung: p:\winavr\bin\..\lib\gcc\avr\4.1.2\..\..\..\..\avr\bin\ld.exe: region text is full (vario.elf section .text) es gibt diese wenn ich da rechnen will: pow(variable,0.12938); zu anspruchsvoll für 8-Bit mikrocontroller? ach
0.12938); >zu anspruchsvoll für 8-Bit mikrocontroller? ach ja verwende avr studio. Optimierung eingeschaltet? Welcher AVR ist es denn? MFG Falk