-
Thread
C++ auf AVR: new und virtuelle Methoden
Johann L. schrieb im Beitrag #3014835: > Mit den richtigen Optimierungen erzeugt avr-gcc für einen > ATmega32 folgendes: Karl Heinz Buchegger schrieb im Beitrag #3015015: > Das ist fies. Ist ja alles geinlined worden :-) Oha. Johann, welche Optimierungen waren
Roland H. schrieb im Beitrag #3015206: > Oha. Johann, welche Optimierungen waren denn das bitte? avr-gcc 4.8 mit -flto -O2, sollte aber auch mit 4.7 gehen.
-
Thread
memcpy vs for-loop bei AVR
memcpy gibt es unter Umständen so allgemein nicht. Der Compiler kann (und der gcc wird, bei eingeschalteter Optimierung) den memcpy Aufruf durch äquivalenten Code ersetzen und den Gegebenheiten entsprechend optimieren. Also die eigene Implementierung vergleichen mit einer Implementierung
den/ Sourcecode von memcpy gibt es > unter Umständen so allgemein nicht. Der Compiler kann (und der gcc wird, > bei eingeschalteter Optimierung) den memcpy Aufruf durch äquivalenten > Code ersetzen und den Gegebenheiten entsprechend optimieren. Aus [c] #include <string.h> #include <stdint.h
-
Thread
µC über Webinterface ansteuern (Lan und / oder WLAN)
längere Threads. Persönlich ist mir die AVR Lösung zu schwach, du wirst immer viel Zeit in die Optimierung stecken müssen wg wenig RAM. Die 8051er mit denen du gelernt hast sind ähnlich wie die AVR. Es gibt zwar viele moderne Derivate, aber die sind im Hobbybereich weniger stark vertreten.
verwenden. Ich besitze einen Synology, welcher auch Linux als OS nutzt. Per SSH lässt sich da auch gcc installieren und man kann eine per uC realisierte IO-Einheit per USB-Seriell Wandler ansprechen. Ich selbst habe 3 Raspbis im Einsatz. Einer im Wohnzimmer als Interetradio und Weboberfläche für meine
-
Thread
WINAVR keine neue Version mehr?
neue Optimierungen und behobene Bugs. Neue Features wie Link-Time Optimierung (LTO). Beim Umstieg lese man auch die Release Notes! 4.7: http://gcc.gnu.org/gcc-4.7/changes.html 4.6: http://gcc.gnu.org/gcc-4.6/changes.html 4.5: http://gcc.gnu.org/gcc-4.5/changes.html Insbesondere die Teile, die sich auf AVR beziehen!
-
Thread
avr-gcc: Fehler? Reihenfolge der Funktionen ist wichtig
Prozessor ist ein ATtiny48, die avr-Tools habe ich unter einem ziemlich aktuellen Ubuntu installiert (gcc 4.5.3), kompilieren tu ich mit avr-gcc -mmcu=attiny48 -c source.c dann linken usw. Im Prinzip ist mir die Anordnung der Funktionen ja egal, allerdings habe ich Probleme mit der Ausführung von
> Zeigen, Oha, nicht schlecht, in die Richtung geht's: avr-gcc -mmcu=attiny48 -c start.c avr-gcc -o start.elf start.o avr-objcopy -j .text -j .data -O ihex start.elf start.hex sudo avrdude -c avrispmkII -p t48 -P usb -e -U flash:w:start.hex Zur Sicherheit
-
Thread
Umwandlung von zwei uint8_t in uint16_t erzeugt falschen Code?
Christoph U. schrieb im Beitrag #3010114: > Der AVR-GCC 3.3.1.27 mit Optimierung O1 Warum -O1 ? Tritt der Fehler bei -Os auch auf?
Christoph U. schrieb im Beitrag #3010114: > Der AVR-GCC 3.3.1.27 mit Optimierung O1 erzeugt bei mir folgendes 3.3.1.27 klingt nicht nach einer GCC-Version. Bei mir (GCC 4.7.2) wird folgendes erzeugt, wenn ich das für den ATmega1281 compilieren lasse
-
Thread
AVR ATMega 163 "überlastet" mit Programm?
Das Programm ist soweit fertig (ca. 1000 Zeilen Code und recht langsam, da ich wenig Wert auf Optimierung gelegt habe). Im AVR Studio liefert mir das Programm auch die richtigen Ergebnisse. Auf der Smartcard jedoch stürzt das Programm ab. kleine Info: Keccak besteht aus 24 Runden a 5 Funktionen
> da ich wenig Wert auf Optimierung gelegt habe Legt denn Dein Dozent Wert darauf? In einer praktischen Anwendung kommt es häufig darauf an, eine Aufgabe schnell genug zu erledigen. Zum Beispiel darf eine Interrupt Routine meist
-
Thread
IVEL bei mega32 lässt sich nicht setzen
HelpUrl: Installed Packages: AVRGCC - 3.4.1.95 AVR Toolchain 8 Bit Version: 3.4.1.830 - GCC 4.6.2 Package GUID: a3796ad3-98fe-4e60-bd15-57100d343560 Company: Atmel HelpUrl: AVR Toolchain 32 Bit Version: 3.4.1.348 - GCC 4.4.3 Package GUID: a3796ad3-98fe-4e60-bd15-57100d343560 Company
GELÖST .... zum debuggen hab ich die optimierung auf null -O0 gesetzt/ausgeschalten. übers disassembly sieht man jedoch im code, dass das setzen des flags nicht innerhalb von 4 zyklen passiert bei optimierung -O2 beschränkt sich das setzen
-
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
eigene memcpy Funktion mit 2 Zielen
Hast du mal getestet, was gcc mit -Os tut? Ist das wirklich nicht gut genug? Das sollte man ausprobieren, bevor man sich die ganze Arbeit macht. ;)
ich sagen muss, dass der Compiler aus deinen Ansätzen wieder 2x memcpy(..) macht... die einzige optimierung dabei ist dann, dass es nicht mehr inline ist (was eigentlich schon 90% der Optimierung ausmacht). Wäre vollkommen ausreichend, aber irgendwann kommt einfach der Punkt da will mans wissen. in C
-
Thread
Volatile-Zugriffe umsortieren
> Wäre hier Reordering möglich? Nein. Falls doch, ist es ein Compilerfehler wie etwa PR51374 im GCC: http://gcc.gnu.org/PR51374 Wer einen avr-gcc 4.6.2 einsetzt, sollte das auch "live" nachvollziehen können :-)
Statement, wo man das für einen Block > verbieten kann. > Den gibt's. Zwar nicht im Standard, aber gcc tut meist das, was man erwartet: ohne Optimierung übersetzen. Wenn >= gcc 4.4, kann man auch so was machen: [c] ... #pragma GCC push_options #pragma GCC optimize "O0" /* oder "no-wasauchimmer
-
Thread
ARM Einstieg Hilfe bei Controller und IDE Wahl
GCC Make Openocd ST-Discovery F4 - Billiger wirds schwer
einmal nicht viel über C) zu installieren und dann die entsprechende Werkzeugsammlung für den ARM (gcc-arm usw.) zu installieren. Wenn Du Schritt für Schritt vorgehst, solltest Du sehr bald die obligatorische LED zum Blinken bringen können :-) Chris D.
-
Thread
Bits spiegeln in Hardware oder in Software?
errechnet? [c]#define mirror(bits) __builtin_avr_insert_bits (0x01234567, bits, 0)[/c] http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/AVR-Built_002din-Functions.html#AVR-Built_002din-Functions
kann man auch verzweigen, abhängig davon, ob der Wert eine Konstante ist oder nicht. Dazu gibt's bei gcc __builtin_constant_p().
-
Thread
AVR2054 debuggen [erledigt]
Chris schrieb im Beitrag #2990041: > Könntest du den Beitrag bitte ins GCC-forum verschieben. Nein, von daher habe ich ihn hierher geschoben. Du hast, entgegen deiner Auffassung, /kein/ Problem mit dem GCC (daher konnte dir dort auch keiner helfen), sondern eins mit
keinen vernünftigen Grund, warum man das so verkorkst implementieren will, zumindest nicht für den GCC. Man kann die Debuginformationen auch grundsätzlich mit anfordern, ohne dass das die Optimierung beeinflussen würde.) Inwiefern das durch die jeweiligen Atmel-Studio-Projekt-Dateien genauso gehandhabt
-
Thread
µC rechnet falsch oder ich finde den Fehler nicht
Lothar Miller schrieb im Beitrag #2989825: > Welche Optimierung hast du eingeschaltet? Unter Vorbehalt sage ich mal, dass dies das Problem war. Optimierung war auf -O1. Augenscheinlich auf -Os funktioniert es (zumindest UART-Ausgabe von oben gepostetem Code
Ne, so alt nun auch wieder nicht. Das ist die Versionsnummer der Atmel-Toolchain (nicht des avr-gcc). Da ist AFAIK ein avr-gcc 4.5 drin.
-
Thread
16-bit vs. 32-bit Division auf 8-bit AVR
in Summe wenn man den Programmieraufwand dazuzählt. http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung >Macht es eigentlich einen Unterschied, ob man 16-bit durch 16-bit teilt >oder 16-bit z.b. nur durch 8-bit? AFAIk nein. > Oder ist sowieso immer
-
Thread
AVR-GCC Win98 Fehler mit Schalter -Os
Was sagt denn avr-gcc -v ? Oder geht das auch nicht?
Moin, welcher Prozessor sitzt denn im Rechner? Eventuell wurde der GCC mit Optimierungen übersetzt die nicht verfügbar sind (INTEL <> AMD) MfG
-
Thread
Problem mit AVR Studio 6 - ATMega64 funktioniert nicht mehr (speziell Aufruf von Unterfunktionen)
funktioniert hat, auf dem neuen Studio zum laufen bringen. Dazu habe ich ein neues Projekt erstellt (GCC C Executable Project) und dann den Inhalt der alten .c Datei in die neue .c Datei kopiert. Das Kompaillieren und Beschreiben des µC verlief fehler- und warnfrei. Das Problem: Der µC bleibt plötzlich
Die folgenden Punkte habe ich bereits gecheckt: - µC Typ - fuses - clk Frequenz - compiler-optimierung auf "-os" - keine Fehler- oder Warnmeldungen beim kompilieren - richtiges .hex file Ich weiß im Moment nicht mehr weiter. Kann mir jemand bitte helfen? Danke im Voraus. Gruß Matthias
-
Thread
data |= (1<<16) funktioniert nicht
Probiers mal mit (1UL<<16) oder ((long)1<<16) Denn eine einfache Konstante ist beim AVR GCC 16 Bit breit...
Magnus schrieb im Beitrag #3000657: > Aber auch auf 64-Bit-Plattformen selten 64 Bit. Für AVR-GCC war dies der *wichtigste und treffendste Hinweis*.
-
Thread
Debug ANSI C Programm, RaspberryPI.
Henrik Wellschmidt schrieb im Beitrag #2983360: > Ich schwöre ... kein Mux! > pi@rpi ~/1wirevz $ sudo gcc -Wall -Wextra -Werror -o /usr/sbin/1wirevz 1wirevz.c -lconfig -lcurl > pi@rpi ~/1wirevz $ Tatsächlich. Auf der pi bekomme ich mit dem aktuellsten Code mit gcc-4.6.3 mit -Wall -Wextra keine Warnung
Rückgabewerte von fgets, chdir und write. Immerhin weis ich jetzt, dass ich in Zukunft den raspian gcc bei Warnungen nicht trauen kann.
-
Thread
kleine Anfänger-Fragen zu assembler
es immer mal versuchen, denn häufig macht der Compiler halt doch nen Haufen Unsinn oder nimmt Optimierungen, die man nur mit etwas höherem Verständnis durchführen kann halt nicht vor. nur EIN Beispiel: [c] [...] uint8_t i = rand(); // irgend ein Wert halt uint16_t array[21]; uint16_t tmp;
nicht mehr weiter verwendet... ich find den Code eigentlich nicht sooo schlecht ok. r22 hätte der GCC einsparen können. Aber abgesehen davon ist das so mies auch wieder nicht, wie du tust. Es gibt natürlich Fälle, in denen es tatsächlich auf jeden Takt ankommt. Die Erzeugung von Video-Signalen fällt
-
Thread
24 Bit signed effizient verarbeiten
> verwenden oder ist das ganz viel zu unausgereift/böse/nicht portabel? Geht das auch mit avr-gcc? ich hab mal alles unter /usr/lib/avr nach int24 gegrept, aber nix in der Form int24 gefunden...
hunderte oder tausende Datensätze verarbeiten will. http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
-
Thread
_delay_us macht eine ms
Kein Plann schrieb im Beitrag #2971935: > Komisch an der Sache ist, schalte ich die Optimierung ein, funktioniert > das Display nicht und der Pin bleibt auf Low. Und ohne Optimierung bekanntermassen nicht das Delay. Was folgt daraus? Du hast kein Problem mit dem Delay, sondern mit dem
darauf? ;-) Ne, es werden nur 2 Stück ausgegeben. Beide weisen mich darauf hin das Delay nur mit Optimierung funktioniert.
-
Thread
C: int * rückgabewert bei einer Funktion
Versuch den Code zu compilieren. error: conflicting types for 'firstEight'| Ich nutze einen gcc Compiler und die Entwicklungsumgebung Code::Blocks 10.05 Ich habe schon einiges ausprobiert aber leider hilft nichts, ich verstehe das Problem nicht. Vllt kann mir ja jmd auf die Sprünge helfen
GNU GCC Compiler
-
Thread
Komplexität STM32 vs. PIC32
vermutlich über mehr Register, welchen den "fault" besser eingrenzen. - Die Kompilate von mips-elf-gcc sind - verglichen mit arm-none-eabi-gcc / thumb2 - wesentlich größer. Vielleicht holen hier die Microchip-Ergänzungen für "deren" GCC mehr heraus: [c] 28260 44 1204 29508 7344
void _general_exception_handler (unsigned cause, unsigned status); > - Die Kompilate von mips-elf-gcc sind - verglichen mit arm-none-eabi-gcc > / thumb2 - wesentlich größer. Vielleicht holen hier die > Microchip-Ergänzungen für "deren" GCC mehr heraus: > > [c] > 28260 44 1204 29508
-
Thread
funktionen inlinen
Johann L. schrieb im Beitrag #2964773: > In GCC ist -O0 der Default. Aber darum geht es hier garnicht. Sondern > darum, daß unüberlegt und grundlos offenbar falsche Aussagen bemacht > werden. Ja. ok. Momentan ist das beim gcc eben so.
wenigsten jemals -O0 benutzen. Von daher: sei ein wenig nachsichtig, wenn wir nicht für alle Optimierungen auswendig wissen, welche Optimierung unter welchen Nebenbedingung durchgeführt wird und wann nicht. Manche Optimierungen sind so trivial, dass man wohl davon ausgeht, dass der Compiler sie praktisch
-
Thread
Fehlermeldung ISE
/14.4/ISE_DS/ISE//lib/lin/libboost_iostreams-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin/libboost_program_options-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin/libboost_regex-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin/libboost_system-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin/libboost_thread-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin/libboost_zlib-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/
-
Thread
Kann man denn jetz das hi- und low-byte eines uint16_t effizient lesen in c?
AVR-GCC-4.7.2 mit -Os optimierung... liegt wohl wieder am volatile dass GCC da so nen mist baut
Leo B. schrieb im Beitrag #2962266: > Ich nutze den AVR-GCC-4.7.2 mit -Os optimierung... liegt wohl wieder am > volatile dass GCC da so nen mist baut Bist du sicher, daß die beiden Varianten, die du vergleichst, nicht Äpfel und Birnen sind? Sind beide
-
Thread
SRAM auslesen zu langsam.
Gleitkomma! Jain. Nur wird das vom Compiler zur Compilezeit gemacht, nicht zur Laufzeit. Wenn die Optimierung eigeschaltet ist ;-) http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 >Mit einem oder zwei inline nop >bist du besser bedient. Kommt auf das Gleiche
dafür, deinen µC dafür in 32 Bit Arithmetik hineinzutreiben. Es heißt zwar immer 'vorzeitige Optimierung sei die Wurzel allen übels'. Aber auf der anderen Seite muss man seinen µC auch nicht sinnloserweise in Beschäftigungstherapie treiben, in dem man ihm naheliegende Vereinfachungen vorenthält. Und
-
Thread
Buchempfehlung GCC, Makefile & Co
zurückgeworfen sind. Sieht dann zwar etwas hübscher aus im Buch, aber das war es dann auch... Zudem wird GCC ständig weiterentwickelt. Wenn du in einem GCC-Buch was suchst zu "Transactional Memory in GCC" wirst wohl nicht viel finden, weil ein Buch zu langsam ist und schwerlich mithalten kann mit der Entwicklung
ist zu beachen: Diese Mailinglisten sind nicht für Fragen zu C oder C++ etc. sondern für Fragen zu GCC (Schalter, Optimierungen, Probleme mit configure, ...) [1] http://gcc.gnu.org/ml
-
Thread
Multiplizieren geht schief
Wahrscheinlichkeit brauchst du ihn auch gar nicht, sondern hast vielleicht nur vergessen, die Optimierung des Compilers einzuschalten.
Überschreiben wieder auf 0 gesetzt werden, etwa wenn ein MUL verwendet wurde. Siehe ABI http://gcc.gnu.org/wiki/avr-gcc#Register_Layout > wenn der Compiler da was wegoptimiert Es ist Assembler-Code, der Compiler bekommt ihn nie zu sehen. > es scheint als ob der Fehler von ausserhalb kommt
-
Thread
ARM C-Compiler
W.S. schrieb im Beitrag #2954859: > 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
vom GCC bekommt." W.S.
-
Thread
C - Schnelle Datenauswertung auf PC - Multi-Threading?
PC messen? Habe keinen Prallel-Port, nur USB, Ethernet... PC-System ist ein UBUNTU, Compiler GCC. Mit Dank und Grüßen im Vorraus, Tueftler
strings um und keine float um die Daten zu loggen. Den größten Einfluss hatte aber immer noch die Optimierung, nun auf 3 gesetzt. Somit benötigt die FFT über 4096 (rein Rellwertige Float-)Datenpunkte zwischen 70...200 Micro-Sekunden. @Andreas: Andreas Messer schrieb im Beitrag #2945008: > Hast Du
-
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
berechnete defines ausgeben - wie?
Du kannst den GNU C Preprocessor drüberlaufenlassen, wenn du den gcc installiert hast. cpp header.h
sieht du das in Compiler-Dumps, z.B. in .optimized das mit -fdump-tree-optimized erstellt werden kann (GCC). Der Code ist C-ähnlich und direkt verständlich. Noch mehr Dumps bekommst du mit -fdump-tree-all.
-
Thread
Optimierung reduziert Code um 2/3, ist das normal?
schlägt den Compiler bei komplexen Aufgaben IMMER! http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
die Optimierung wegschalte, wird mein Code genauso größer :-) Im Ernst. Kleb jetzt nicht an den 2/3. Du hast einen Fehler gemacht, wenn du bei _delay_ms die Optimierung abschaltest. Das ist keine Frage von Optimierung
-
Thread
C++ für Embedded: ab welchen Prozessormerkmalen?
Entwicklungsumgebungen für Mikrocontroller können kein C++. Meist können sie es allenfalls dann, wenn drunter GCC werkelt.
www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx problemlos. Hinter der 3.4 (Atmel-Version) verbirgt sich GCC 4.6.2 [c] $ avr-gcc --version avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.0_663) 4.6.2 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions.
-
Thread
Array Obergrenzen?
den Stack nützt, läuft evtl. dein SRAM über, sind ja nur 1k. Wars nicht (früher) so, dass beim avr-gcc erstmal Daten vom Flash ins RAM kopiert wurden? Habe allerings schon >6 Jahre nichts mehr mit dem avr-gcc gemacht, kann also sein, dass meine Infos total überholt sind.
Gemeint sind diese Präprozessor Macros: http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
-
Thread
8x8 Bitmuster um 90° drehen
wieder mit displacement. Achso, ich hab mit AvrStudio 6.0.1843, also AVR Toolchain 3.4.0.663 / GCC 4.6.2 und Optimierung -Os compiliert. Gibts für das seltsame Verhalten nen Grund, der sich mir nur nicht erschließt? Gruß, Alex
-
Thread
IR Sender Projekt Irsnd
Buchegger schrieb im Beitrag #2928972: > Ah. Im 4-er > Ich hatte das 6-er gemeint. Ja, 4er, aber mit gcc 4.7.2. Ich kanns einfach nicht glauben, dass der 6er gcc-Meldungen neu sortiert und dann Fehler 2 Fehler 3 Fehler 1 vor die eigentlichen gcc-Meldungen schreibt. Echt wahr?
RunCompilerTask-Aufgabe ist abgeschlossen -- FEHLER. Die Erstellung des Ziels "CoreBuild" im Projekt "GccRadio2.cproj" ist abgeschlossen -- FEHLER. Die Erstellung des Projekts "GccRadio2.cproj" ist abgeschlossen -- FEHLER. Fehler beim Erstellen ========== Build: 0 erfolgreich oder aktuell, Fehler bei
-
Thread
STM32F4Discovery mit CooCox :: GPIO,SDIO,Timer,SoftTimer,USART,printf
bösewicht schrieb im Beitrag #2928427: > Aber, mein gcc scheint nichtmehr zu stimmen!Habe ich wohl selbst > verbockt (wie weiß ich nicht); > Welchen nimmst Du, Thomas Winkler ? \arm-none-eabi-gcc-4_6
Welche Versionen von CoIDE und GCC verwendest Du? Ich empfehle CoIDE 1.5.2 und die letzte GCC 4.6 Version (gcc-arm-none-eabi-4_6-2012q4-20121016) Vielleicht findest Du hier eine Lösung: http://www.coocox.org/forum/topic.php?id
-
Thread
Initialisierung von globalen Variablen in Codesourcery
0x000144b0 0x0 c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.3\libgcc.a(_divdi3.o) .ARM.extab 0x000144b0 0x0 c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.3\libgcc.a(_udivdi3
0x000144b0 0x8 c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.3\libgcc.a(_divdi3.o) .ARM.exidx 0x000144b8 0x0 c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.3\libgcc.a(_udivdi3
-
Thread
ISR viel zu mollig
schrieb im Beitrag #2920217: > Was liefert den der Compiler mit aktivierten > Geschwindigkeits-Optimierungen Pro- und Epilog normaler ISRs sichern / restaurieren /immer/ R0, R1 und SREG, unabhängig vom Optimierungsgrad oder sonstigen Optionen, siehe http://gcc.gnu.org/PR20296 Bjorn Haase dazu
back-end does not easily permit to improve this case Zu Deutsch: Es ist sehr aufwändig, diese Optimierung in avr-gcc einzubauen. I.w. bedeutet es, einen Großteil des avr-Backends von GCC neu zu schreiben, nur um eine handvoll Instruktionen zu sparen. Wenn du dir anschaust, wieviel Entwickler dazu
-
Thread
avr-size: invalid option -- C
nichts geändert. Optionen = wie von AVR Studio vorgegeben + -fno-inline-small-functions + -Os GCC 4.3.3 -> 1018 bytes (99.4% Full) GCC 4.7.2 -> 1048 bytes (102.3% Full) ohne -fno-inline-small-functions GCC 4.3.3 -> 1114 bytes (108.8% Full) GCC 4.7.2 -> 1048 bytes (102.3% Full) ??
G. schrieb im Beitrag #2920069: > GCC 4.3.3 -> 1018 bytes (99.4% Full) > GCC 4.7.2 -> 1048 bytes (102.3% Full) > > ohne -fno-inline-small-functions > GCC 4.3.3 -> 1114 bytes (108.8% Full) > GCC 4.7.2 -> 1048 bytes (102.3% Full)
-
Thread
JTAG lässt sich nicht deaktivieren (ATMega32)
wird. Zur Sicherheit muss man es zweimal hintereinander innerhalb von 4 CPU-Takten setzen, was beim GCC nur funktioniert, wenn man auch die Optimierung eingeschaltet hat. Damit ist das JTD-Bit übrigens eine brauchbare Alternative zur Fuse, wenn man die grundsätzliche Zugreifbarkeit über JTAG noch
-
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
[AVR] Optimierung von 32bit shifts
sind 5 Berechnungen), ich war nur erstaunt, dass der Compiler das nicht selber macht obwohl die Optimierung sonst ganz gut funktioniert. Ich dachte es gäbe irgendeinen mir unbekannten Grund dafür, aber so wie es aussieht liegts wohl am Zusammenspiel zwischen GCC und AVR. Kann vielleicht jemand mein
return [length = 1] [/avrasm] Bis auf das doppelte ANDI *,15 ist das optimal. Wie man die Optimierung direkt in GCC macht ist mir aber nicht klar, vielleicht hat ja jemand ne Idee...
-
Thread
Negative Ganzzahlen von 32bit in 16bit konvertieren
erzählen vom Krieg. >kann! Low-Level Optimierungen überlass ich dem Compiler. Jain. Man muss wie immer wissen was man tut und ob es sich lohnt. [[AVR-GCC-Codeoptimierung]]
dabei ist, daß auf Größe optimiert wird, aber Code erwartet wird, wie er bei Geschwindigkeits-Optimierung erzeugt wird. Erst ab avr-gcc 4.7 verhält sich der Compiler nicht ganz wie erwartet, d.h. bei Optimierung auf Größe mittels -Os erzeugt er Code, der mehrere Instruktionen größer sein kann als
-
Thread
PIC16 Anweisungen wegoptimiert
erzeugt wird ist im Anhang. Nur aus Neugierde: Ist das der erzeugte Code mit eingeschalteter Optimierung?
Buchegger schrieb im Beitrag #2908846: > Oh, ja. Der Programmier-Fehler ist wirklich fies. Der AVR-GCC gibt bei sowas aussagekräftige Meldungen aus. [c] irgendwas // \ [/c] warning: multi-line comment Peter
-
Thread
Funktion für eine LED-Matrix. Optimierung für Interupt ?
eine Variable ist. Das sollte ein define sein, denn dann kann es der Compiler bei eingeschalteter Optimierung berechnen und statt einer echten Schiebeoperation zur Laufzeit eine Konstante einsetzen. DAS ist wichtig! [c] #define MTX_BIT 1 char matrix_buffer[105] = { // 7 Zeilen a' 120 Bit 0x00,0x22,0x08,0x3e
reicht, das Datenblatt des AVRs zu lesen. Oder das hier. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR