-
Thread
Speicher sparen
Das fällt unter 'Optimierung'. Und bei Optimierung sind generelle Tips genauso schwierig zu geben wie sie dann doch nicht greifen. Optimierung muss man sich fast immer im Einzelfall ansehen. So auch hier: Es kann gut sein
prüfen, DANN ggf. einen größeren Controller wählen. http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung MFG Falk
-
Thread
MegaLoad für avr-gcc
Uff, ist das lange her. A) Da musst du evtuell mit der Optimierung des AVR-GCC spielen. Das Teil ist damals für die Version 3.x optimiert worden (und der war etwas "sparsamer" als der aktuelle 4.x). Obwohl 130 Bytes schon heftig ist. Zusätzliche Optionen kannst
Jetzt habe ich das Problem mit dem aktuellen AVR-GCC gefunden. Beim AVR-GCC 3.x wurde im main() noch der Stack inititialisiert. Darum hatte ich aus Platzgründen die Initialisierung aus der gcrt1.S entfernt. Seit AVR-GCC v4.x wird der Stack nicht mehr
-
Thread
Wechsel von Hardware zu Embedded SW vorbereiten
Die GCC von TI ist nicht nur eine IDE sondern eine Comunity und nein nix Parameter, den Richtigen Launchpad anhängen, die GCC findet ihn meist sogar selber und schlägt dir dann Projekte vor. Aber es gibt
Patrick L. schrieb im Beitrag #6958706: > Die GCC von TI ist nicht nur eine IDE sondern eine Comunity und nein nix > Parameter, den Richtigen Launchpad anhängen, die GCC findet ihn meist > sogar selber und schlägt dir dann Projekte vor. Klingt
-
Thread
Fernbedien RC5 Empfänger
Interrupts globale Variablen ändern. Der Keil C51 optimiert diese daher grundsätzlich nicht weg. Die Optimierungen des GCC sind jedoch vorrangig auf größere CPUs ausgelegt, d.h. Mikrocontroller typische Programmabläufe fallen da etwas hinten runter. Rein formal entspricht das aber dem C-Standard, daher wird
würde daher am liebsten sämtliche Variablen als volatile definieren, allerdings wird dann die Optimierung ausgeschaltet. Es hilft also nichts, man muß beim GCC immer ein wachsames Auge haben und bei derartigen Effekten darauf prüfen. Auch wenn ulkige Effekte nach einem Compilerupdate auftreten, liegt
-
Thread
Glühwürmchen in Rotkohlglas gefangen
und _c in eine Funktion ausgelagert -- Zeug für Bootloader-Support entfernt -- Kleinigkeiten, um GCC bei der CSE-Optimierung zu helfen. -- Sortierung von _b gegen _c in eigener Funktion Dann, soweit ich sehen kann, können alle Daten im RAM ebensogut uninitialisiert sein nach RESET? Hab mal die
noinit.ld: [pre] SECTIONS { .nirvana : { *(.init4) } } [/pre] Beim Link-Aufruf (avr-gcc als Linker) gibt man zusätzlich als Optionen an [pre] avr-gcc ... noinit.ld -Wl,--section-start,.nirvana=0xa00000 [/pre] > Nungut, ich selber bin mit der Simulation auch unzufrieden. Die Waves
-
Thread
Neue AVR-Studio mit AVR-GCC Integration
Bitte diskutiert das mal außerhalb des GCC-Forums weiter (am besten mit Atmel Norwegen selbst).
Irgend eine Fehlermeldung? dwarf-2 oder coff? Simulator und gcc-Parameter auf Controller eingestellt?
-
Thread
AVR-gcc: Optimierungslevel lokal ändern?
A. K. schrieb im Beitrag #4229727: > https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html > und unter "optimize": > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes Die Beschreibung
Ich glaube, der AVR-gcc kennt so ein Attribut nicht: https://gcc.gnu.org/onlinedocs/gcc/AVR-Function-Attributes.html#AVR-Function-Attributes
-
Thread
Wird if Schleife ignoriert, wenn sie nie eintritt?
Es würde dich noch mehr wundern, wenn du wüsstest, wieviel Aufwand die Compilerbauer in die Optimierungen gesteckt haben und immer noch stecken, und was die alles können. Ungennutzen Code entfernen ist allerdings eine der Basis-Optimierungen überhaupt, das gibt es schon seit ewigen Zeiten. Oliver
if-Abfrage komplett heraus? Mal was zum Thema: Wenn der Compiler mit einer entsprechenden Optimierungs-Option (-O bzw. -O2) gestartet wurde, kann er solche if-Abfragen schon wegoptimieren- sowohl wenn debug == true oder debug == false gesetzt wird. Allerdings musst Du ihm schon etwas unter die
-
Thread
AVR-GCC: Code wird totoptimiert
Mikrooptimierung Karl K. schrieb im Beitrag #4229190: > folgendes Codefragment optimiert mir der AVR-GCC kaputt: Wenn du kaputten Code schreibst, brauchst du dich nicht beschweren, wenn das, was dabei rauskommt, nicht funktioniert. Den GCC trifft da keine Schuld. Wenn du eine Funktion (den GCC) mit
machen musst und dich jenem Code näherst, denn du auch mit "volatile" erhältst. > Wie kann ich den GCC davon abhalten, den Codeteil kaputtzuoptimieren? GCC passend für deine Interpretation von C umschreiben.
-
Thread
Attiny45, timer tut nichts?
rffb.o.d rffb.c -o rffb.o Linking: rffb.elf avr-gcc -mmcu=attiny45 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=rffb.o -std=gnu99 -MMD -MP -MF .dep/rffb.elf.d
Um das Thema nochmal aufzuwärmen. Es handelt sich um einen Bug im alten GCC. Mit GCC 4.8 funktioniert nun der folgender Code. [CODE] #include <avr/io.h> #include <avr/interrupt.h> int main(void) { DDRB |= (1 << PB0) | (1 << PB1); PORTB |= (1 << PB0)| (1 <<
-
Thread
made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA
Die Cygwin Version von SF habe ich auch erst benutzt. Es gibt aber eine minimal neuere GCC Version von Altera. Die cygwin Version auf SF ist die "gcc version 2.9-nios-010801-20030718", die letzte Altera Version für den Nios I ist "gcc version 2.9-nios-010801-20041001" (GNU Tool 3.2). Den
Björn F. schrieb im Beitrag #2517975: > Wie schon gesagt, mit dem gcc > 4 mag er den Code nicht übersetzen. > Übersetzt ist das ganze also mit gcc 3.4.4 unter Ubuntu 10.04. Den alten > gcc muss man allerdings aus dem Hardy Repository installieren. Entschuldigung,
-
Thread
GCC Tutorial
einem Editor schreiben, und dann von GCC compelieren lassen, also wäre dann GCC ein reiner Compiler ? oder kann ich in GCC auch editieren?? Sorry ich blick echt nicht wie ich das Ding aunfassen soll. Die Infos unter AVR GCC hier auf
/wiki/wiki.phtml?title=AVR-GCC_Tutorial&action=edit
-
Thread
AVR (8-Bit) / C++ Toolchain
Atmel Studio 7, da ist GCC für C/C++ integriert, sowie viele Programmer zum Übertragen auf den Chip.
Jeder avr-gcc ist ein gcc, und kann daher so viel C++, wie ein gcc halt so kann. Die üblichen verfügbaren avr-gcc-toolchains machen auch alles mit. Es braucht ein paar paar zusätzliche Funktionen für new, delete
-
Thread
Go-Compiler für MSP430
Mal ganz blöd gefragt: Für den GCC gibt es ein Go-Frontend und ein MSP430 Backend. Lassen die sich nicht miteinander verheiraten, so dass nur noch Bibliotheken fehlen?
Εrnst B. schrieb im Beitrag #6269573: > Für den GCC gibt es ein Go-Frontend und ein MSP430 Backend. > > Lassen die sich nicht miteinander verheiraten, so dass nur noch > Bibliotheken fehlen? Meines Wissens nach ist der GCC nicht so modular aufgebaut
-
Thread
AVR-GCC: Problem mit volatile und delay loop
hallo, ich glaube ein problem mit volatile in verbindung mit delay loops (z.b. _delay_us()) im avr gcc gefunden zu haben. der angehaengte code tut nicht das, was er meiner meinung nach tun sollte - das delay stimmt einfach nicht immer. mit der mit 'nicht ok' markierten zeile funktionierts nie, mit der 'ok' markierten zeile funktionierts, wenn ich die optimierung auf s schalte - ohne optimierung funktionierts nie... nicht funktionieren heisst: an nen logic-analyzer angeschlossen sieht man, dass das delay scheinbar beliebig (auf jeden fall viel zu lang
-
Thread
Compiler - Optimierungsflags
Alternativ zeige den C-Code und lasse Forenteilnehmer einen Blick drauf werfen. Beim neueren GCC 4.1.1 ist ein typ. Beispiel für "unerwartete" Effekte, dass dort aus GCC Sicht unnütze Schleifen wegopimiert werden { int i; for(i=0;i<1000;i++); } als Primitiv-Warteschleife streicht der 4.1.1 GCC bei eingeschalteter Optimierung zusammen zu { }
-
Thread
Programmgeschwindigkeit bim XMEGA viel kleiner als Taktfrequenz?
>ich war erstaunt, dass der Unterschied zwiscehn C und Assembler trotz >Optimierung und so einfachem Programm solch riesige Unterschiede bringen >soll... In Assembler bist du, so wie du das Programm geschrieben hast, nicht schneller.
Befehle, sondern Register. Die findest du im Datenblatt. Aber viel wichtiger: Deren Namen unter AVR-GCC findest du im entsprechenden Header File im WinAVR inc Verzeichnis. ioxYZ.h
-
Thread
DCF Funktion frisst unglaublich viel Speicher
Irgendwas mach ich dann falsch, ich brauch da knapp 300 Bytes... Wenn ich dein Projekt mit avr-gcc -Os übersetzte, ergeben sich für das dcf77-Modul rund 320 Bytes, sowohl für avr-gcc 4.3 als auch für die ältere 3.4, für die das Projekt wohl geschrieben wurde. Ein Byte rechne ich mit 8 Bit. Löwe
Eine Sache die bei dieser Diskusion nicht beleuchtet wurde ist die Verwendung des GCC Compilers. Er ist gut, aber er ist auch eine Eierlegendewollmilchsau. Ich meine damit, dass die Optimierung noch besser geht. Wer vielleicht mal etwas Zeit hat sollte sich den IAR Compiler angucken
-
Thread
16-Bit Ergebnis aus 8-Bit-Variablen berechnen?
Woran kann ich erkennen, wie groß "int" im GCC-Compiler ist? Ich Kompiliere immer mit der Optimierung: "-0s" könnte das zu Problemen führen? habe es so probiert: 16-bit-variable = (uint16_t)(rechnung); Die Rechenergebnisse sind noch
Erik H. schrieb im Beitrag #2027614: > Woran kann ich erkennen, wie groß "int" im GCC-Compiler ist? sizeof(int) sagt es dir. Aber im WinAVR ist siezof(int) gleich 2. Also 16 Bit > Ich Kompiliere immer mit der Optimierung: "-0s" könnte das zu Problemen > führen? Kann. Aber
-
Thread
Kann man diesen C-Code vereinfachen?
t inout[9] = { 0, 1, 2, 0, 3, 0, 0, 0, 4 }; Output = inout[Input]; Ansonsten würde ich die Optimierung dem Compiler überlassen.
https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung "Die goldene Regel lautet: 90% der Rechenleistung werden in 10% des Codes verbraucht. Diese 10% muss man finden und zum richtigen Zeitpunkt optimieren
-
Thread
Frage bezüglich LIBS
Abend miteinander! Ich bin gerade dabei mit AVR Studio ein GCC Projekt zu schreiben. Es handelt sich dabei um ein kleines Program was im Grunde nur Werte von der Seriellen Schnittstelle UART bekommen soll und diese 1:1 als PWM Frequenz auf dem OC1A vom TINY2313
hast Gleitkomma-printf() aktiviert, obwohl du es gar nicht brauchst... Außerde solltest du die Optimierung des Compilers einschalten. Aus mir nicht wirklich verständlichen Gründen ist die Voreinstellung für ein GCC-Projekt in AVR Studio hier ein Level 0, also keine Optimierung.
-
Thread
Benötige hilfe bei ATmega8 Timer
mit dieser Fuseeinstellung, oder? Mit was arbeitest du - AVR Studio+WinAVR, WinAVR allein, AVR-GCC? Hast du daran gedacht F_CPU in den Compileroptionen zu setzen? Stimmt der Wert, besonders die Anzahl der Nullen :) Was macht dieses Programm (mit -Os Optimierung übersetzen): [C] #include <avr
Stefan B. schrieb: > Mit was arbeitest du - AVR Studio+WinAVR, WinAVR allein, AVR-GCC? Hast > du daran gedacht F_CPU in den Compileroptionen zu setzen? Stimmt der > Wert, besonders die Anzahl der Nullen :) Ich arbeite mit AVR Studio+WinAVR. ÖÖÖÖHM, F_CPU setzen? Nein, habe ich
-
Thread
Impulse erzeugen
Anzahl Takte entspricht. >1ter Ansatz waren "delays" Guter Ansatz. hast du aber auch die Optimierung eingeschaltet? Sonst sitmmen deine Zeiten hinten und vore nicht. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 >Funktioniert zwar einigermaße die Zeiten
Danke @falk Optimierung ist eingeschaltet Vieleicht hab ich bei der Genauigkeit einfach ein wenig zu viel erwartet. 1 us --> 1,1 4,24 us --> 4,5 us bei der Frequenz macht sich das allerdings sehr schnell bemerkbar
-
Thread
PID-Regler: Wie schnell ist schnell genug?
Routine nochmal auf zwei anderen Boards laufen lassen. [code] STM32L031 @ 32 MHz (Cortex-M0+) gcc 6.3.1 -Os: 38,6 µs gcc 6.3.1 -O3: 39,5 µs gcc 7.2.1 -Os: 39,3 µs gcc 7.2.1 -O3: 39,8 µs Keil: 24,3 µs LPC1549 @ 72 MHz (Cortex-M3) gcc 7.2.1 -0s: 19,3 µs gcc 7.2.1 -O3: 9,5 µs [/code]
Die Keil Version ist mit dem mbed Online erstllt, der ist beim M0 immer noch deutlich besser als der gcc. Ist jetzt nicht ganz das PID Thema aber man sieht das die Compiler Optimierung hier auch noch eine Menge ausmachen kann. Die Testroutine ist die PID Funktion aus dem ersten Post die 1000x aufgerufen
-
Thread
Bootloader Atmega644 Interrupts und die Probleme
geht :). Vielen Dank für die hilfe und ein schönes Wochenende Gruß Daniel PS: hab die Optimierung auf (-O2) jetzt gestellt und es geht.
Daniel H. schrieb im Beitrag #2416754: > PS: hab die Optimierung auf (-O2) jetzt gestellt und es geht. Die delay routinen und viele libs sind auf -Os optimiert. -O0 verursacht bei mir oft Probleme, mit -O2 wäre ich auch vorsichtig.
-
Thread
Wie viel RAM benutzt meine Applikation?
linker den RAM verbrauch kennen? Hallo Peter II, Beim zusammensetzen des Programms muss doch der GCC irgendwie wissen, wie viel RAM gesammt verbraucht wird. Denn wenn ich die Optimierung -Os wegfallen lasse, meldet er mir, dass der RAM des Boards nicht ausreicht. Vllt. sollte ich noch sagen, dass ich den arm-none-eabi-gcc benutze, samt Eclipse auf Linux. Gruß, Heinz
-
Thread
Inline Funktionen und Codeoptimierung
uint8_t u08; #define screenx 16 #define screeny 16 u08 volatile gdata[screeny][screenx]; avr-gcc Version: 3.4.1 Compiler Optimierungen: OPT = -O2 -ffast-math -fweb -frename-registers -Winline -mtiny-stack
make: *** [all-gcc] Fehler 2
-
Thread
Zu blöd für if-Anweisungen?
Funktionsblöcke werden nicht ausgeführt, egal welchen Wert ich für usiValue eingebe. Ich verwende AVR-GCC und AVR-Studio 3.56 zum simulieren. Es kann davon ausgegangen werden, dass alle verwendeten Variablen deklariert und richtig initialisiert worden sind. if (usiValue > 2) { /
noch realitätsnah ist, bleibt auch anzuzweifeln, da sich durch (nachträgliches) Einschalten der Optimierung ja z. B. das Timing des Programmflusses ändern würde. Du könntest die Variable `volatile' deklarieren und damit den Compiler anweisen, auf diese Variable keine Optimierung durchzuführen. Aber
-
Thread
Black Magic Probe auf ST Link v2 clone "baite"
ja, das ist ein normales Verhalten wenn man optimierten Code debuggt. Da ist es besser die Optimierung auszuschalten, beim gcc kompilieren mit -O0. Da kann auch Segger nicht zaubern und das hat nichts mit Gefrickel zu tun.
ja, das ist ein normales Verhalten wenn man optimierten Code debuggt. Da > ist es besser die Optimierung auszuschalten, beim gcc kompilieren mit > -O0. Danke, klar, macht absolut Sinn. Mal sehen wie ich dem Arduino zusätzliche Parameter mitgeben kann. Ich komme beruflich zwar aus der SW-Ecke
-
Thread
Liste aller Buildin-Befehle für den Cortex M4 von STM32
diese built-ins austauschen. Benutze doch bitte die üblichen Begriffe. Builtins sind sowas: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html Was du suchst, sind die Assembler-Instruktionen. Willst du die per Inline-Assembler nutzen? Sicher, dass das mit gutem C-Code nicht genauso gut geht?
weitestgehend unbekannt. Dann befasse dich damit erstmal genauer. Ohne diese kannst du solche Optimierungen vergessen.
-
Thread
CubeMX und HAL - I2C hängt sich auf
dem Rechner!! Und so viel Overhead frisst das auch nicht , es sei denn man nutzt nur O0 Optimierung.
genauso ausgeführt wird. Ist bei uns in der Firma übrigens auch Codierungs Richtlinie geworden für den GCC.
-
Thread
komisches verhalten AVR avr-gcc
dachte ich an watchdog oder stack pointer ... konnte ich schon aus"debuggen". schalte ich die optimierung von s auf 2 oder 1 herunter dann geht die applikation ein stück weiter ressetiert sich aber später dann doch... ich versteh das ganze nicht, es sieht so aus als ob entweder eine pointer operation
gesetzt ) wird nie erreicht. letzendlich ist es einfach sehr komisch dass der gcc bzw. linker einfach codeteile wild hin und her schiebt und dadurch probleme auftreten können ... danke
-
Thread
Inline-Assembler: Label-Sprungadresse in Z-Register laden - wie?
Oliver schrieb im Beitrag #2246191: > Inline-Assembler im gcc ist nunmal Krampf, und ist > für mehr als drei zeilen ungeeignet. Anders: inline-Assembler im GCC ist genial und unwahrscheinlich gut mit dem Compiler integrierbar, aber das hat seinen Preis.
Und: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Assembler-Dateien http://www.rn-wissen.de/index.php/Avr-gcc/Interna#Registerverwendung Vorteil der extra Datei: Man kann sie auch simulieren!
-
Thread
GPS Daten Umrechnen und ausgeben (float to string)
<UDRE))); UDR = nmea[ucCount]; ucCount++; } [/c] kann es sein das hier die Optimierungen von GCC eine rolle spielen?
Claudio H. schrieb: > kann es sein das hier die Optimierungen von GCC eine rolle spielen? Nein. Aber es kann sein, dass du C lernen solltest. Mach dir eine Funktion [C] void uart_putc( char c ) { while (!(USR & (1<<UDRE))) ; UDR = c;
-
Thread
GCC kompiliert falsch?
? Wie hast du das festgestellt? Der Anzeige eines Debuggers darfst du bei eingeschalteter Optimierung nicht mehr alles glauben.
Das ist die Kompiler-Zeile: [code] arm-none-eabi-gcc -c -mcpu=cortex-m3 -O0 -gdwarf-2 -mthumb -funsigned-char -fomit-frame-pointer -fno-inline -Wall -fverbose-asm -MD -MP -MF .dep/FW_Update_USB.o.d -I . -I\WinARM\yagarto\arm-none-eabi\include -I./lib
-
Thread
Byte Array shiften
+) { _rol_array(p); //p+=11; } [/c] das funktioniert mit auskommentierter Zeile wenn gcc Optimierung -Os ein, wenn Optimierung aus muss der Pointer inkrementiert werden. Ich habe auch probiert die funktion _rol_array() mit Returnwert zu versorgen, aber das klappt auch nicht so recht:
der Funktion durch 'st %a+, r0' manipuliert, daher wohl der Unterschiedliche Effekt bei mit/ohne Optimierung. Aber auch wenn ich den return Wert verwende wie er hier rauskommt ist der nicht richtig. Kann man auf einen Blick sagen das ist def. falsch oder ist das eher ein Randbereich des gcc?
-
Thread
dereferencing type-punned pointer - was ist das?
2) Code umschreiben (Unions wie beschrieben) 3) GCC optimieren lassen und evtl. inkorrekten aber dafür dann evtl. schnelleren Code bekommen
werden. -fno-strict-aliasing unterdrückt keine Warnungen, sondern schaltet die entsprechende Optimierungen ab, d.h. solche, die unter der Annahme von strict-aliasing korrekt sind. Ohne die Option bleiben die Optimierungen eben aus, und damit auch Warungen, die damit im Zusammenhang stehen. Ich schätze
-
Thread
AVR Studio Debuggen von C
Hallo, also ich habe die Version 4.14 vom AVR Studio runtergeladen und versuche gerade GCC zu Debuggen. Das meiste funktioniert für den ATTINY 85 ziemlich gut, es gibt aber ein paar Sachen, die überhaupt nicht funktionieren: - nicht für jede Variable, die berechnet wurde wird ein Wert
vielleicht daran: >also ich habe die Version 4.14 vom AVR Studio runtergeladen und versuche >gerade GCC zu Debuggen. Weshalb nutzt du nicht 4.19? MfG Spess
-
Thread
"Wait"-Befehl in GCC?
µC-Programmier-Anfänge mit BASCOM gemacht. Nun habe ich mir gedacht, einmal auf das AVR Studio 4 (mit GCC -> WinAVR) umzusteigen. Nun möchte ich für eine Modelleisenbahn ein Blinklicht für eine Ampel programmieren. Die Ampelphasen kennt ja jeder... Nur, welchen Befehl gibt es und WIE kann ich den BASCOM
Erfahrung in der hardwarenahen Programmierung hast,würde ich dir empfehlen mal einen Blick in das AVR-GCC Tutorial hier auf der Seite zu werfen,da sind die Grundlagen in deutscher Sprache erläutert.
-
Thread
C18 oder HiTech
könnte, in der kostenlosen Version nicht zur Verfügung steht, würde ich den C18 wählen. Höhere Optimierungen wie sie der GCC durchführt beherrschen beide Compiler nicht. Vor allem werden Zwischenergebnisse nicht wiederverwendet: [c] x = i/2; y = i/2; z = i/2; [/c] Oder [c] col1 >>= 8 - bits;
Michael G. schrieb im Beitrag #2163791: > Höhere Optimierungen wie sie der GCC durchführt beherrschen beide > Compiler nicht. Vor allem werden Zwischenergebnisse nicht > wiederverwendet:x = i/2; > y = i/2; > z = i/2; > Odercol1 >>= 8 - bits; > col2 >
-
Thread
Zeiger auf eine Methode einer Klasse -> Funktionszeiger
verwendet, es bekam damals eine mir nicht ganz verständliche und etwas martialische Warnung des Compilers (gcc 2.95) - funktioniert hat es aber. Mit gcc 3.3 sieht diese weniger schlimm aus, sollte dem mal nachgehen... Das Konstrukt muss dann so aufgerufen werden, dass es an ein Objekt 'angebunden' ist. Statische
, ob du dann die 4 ns nicht an anderer Stelle (auf Grund schlechterer Optimierung) verlierst ;-)
-
Thread
SPI Master Code Optimierung
Hallo Forum, ich habe das Problem dass mein AVR-GCC nicht das macht was ich will: Hier der Code: [c] //slave.h: typedef struct { const uint8_t slaveSelectPin; volatile uint8_t * slaveSelectPort; const uint8_t outputSignalPin; volatile
das noch rausreißen können, aber das kann ich mir angesichts der Komplexität der notwendigen Optimierung schwer vorstellen.
-
Thread
C Verständnisproblem Variable sich selbst zuweisen
Dummy wird nur geschrieben um einen > Speicher zu leeren -> Dummy. Wie soll das gehen? Beim AVR-GCC wird das knallhart wegoptimiert, da nicht volatile: [c] void test() { uint8_t Dummy = Dummy; } 22: 08 95 ret [/c]
auch benutzt wird. Sonst macht das keinen Sinn. Bei eingeschalteter Optimierung sieht das Ganze allerdings anders aus. mfg.
-
Thread
Assembler aus Hex-Dump
hex_dump.hex > hex_converted.asm (http://rn-wissen.de/wiki/index.php/Assembler-Dump_erstellen_mit_avr-gcc) Dazu hätte ich ein paar Fragen. Ist als Architektur "avr" richtig?? Ich habe auch schon Beispiele gesehen bei dehnen avr4 oder avr2 standen? Gibt es eine vergleichsweise bequeme Möglichkeit
herauszufinden, aus wo welche Sections beginnen? http://rn-wissen.de/wiki/index.php?title=Avr-gcc/Interna#Speicherverwaltung
-
Thread
leere funktion in c code ändert verhalten (attiny13)
> CFLAGS=-mmcu=attiny13 -Os -c -Os Keine Optimierung. Die leere Funktion wird nicht entfernt.
Kurt schrieb im Beitrag #4926937: >> CFLAGS=-mmcu=attiny13 -Os -c > > -Os Keine Optimierung. -Os steht für Größenoptimierung, nicht für keine Optimierung. > Die leere Funktion wird nicht entfernt. Kann sie auch gar nicht, da der Compiler nicht weiß, ob die Funktion von irgendwo
-
Thread
Billiger einstiegs-DSP?
Leistung ja schon. :-) Auch da ist der Compiler von Renesas umsonst (beschraenkt auf 256kb) und gcc ist auch moeglich. > Aber da der gcc prima mit dem Blackfin > funktioniert... Wie gut ist der gcc denn dann eigentlich aus der Sicht des DSP-Entwicklers? Ich koennte mir vorstellen das er als
gut auf verschiedenen Plattformen. Gebe zu, ich bin inzwischen schon solch ein GCC-Nazi geworden, dass ich keine von GCC nicht unterstuetzte Plattform mehr anfasse... Gruesse, - Strubi
-
Thread
GCC: variable may be used unitialized
unbegrenzt, und es hängt auch vom Optimierungsgrad ab. Vielleicht nochmals die Doku studieren: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized Ansonsten kann ich mich nur Felix anschließen.
Abbruchbedingung weniger Unterschied besteht, als es von Nutzersicht aussieht? Oder daß bei der Optimierung das eine in das andere überführt werden kann (in einer Richtung ist das klar... aber in Gegenrichtung? ) ? Oder stehe ich auf dem Schlauch?
-
Thread
[Newbie] Code größe bei Unterschiedlichen Programmen
WinAVR? Es liegt zu 100% an der Toolchain (WinAVR, avr-toolchain) und dessen einstellungen ( Optimierung ). Der Editor ist dabei ziemlich egal.
Im Endeffekt kann es sich nur unterschiedliche Versionen des gcc Compilers oder um unterschiedliche Parameter handeln mit denen dieser Compiler aufgerufen wird. Der Vergleich mit verschiedenen IDEs ist also völlig sinnfrei. Ich entwickle z.B. für AVR ausschließlich
-
Thread
Erste Schritte mit ARM SAMD20
von diesen Registern. Ob das bei den Cortex-M3 und -M4 besser aussieht weiss ich nicht. 7. Der gcc lässt Optimierungs-Wünsche offen. -Os läuft am schnellsten, schneller als -O2 und -O3. Gucke ich in den Assembler, sehe ich meist auf Anhieb Möglichkeiten zu kleinen Verbesserungen. Wen das interessiert
Der braucht nach wie vor rund 300 CPU-Takte. Es gibt immer mehrere Wege ans Ziel. :-) > 7. Der gcc lässt Optimierungs-Wünsche offen. Dabei würde es mich wundern, wenn nicht zig verschiedene GCC Versionen im Einsatz wären. Mein Atmel Studio hat gerade Atmel ARM GNU Toolchain 4.8.4.1443 drunter
-
Thread
Registerattribut
neue HW in den GCC einfügt, hat sich dort auszukennen. Bernhard
ich lieber meinen eigenen Compiler. Das geht schneller, auch wenn ich am Anfang nicht soviele Optimierungen drauf haben werde wie der gcc.