-
Thread
Tiny2313 Probleme beim Compilen
Exception caught (code = 0xc00000fd, addr = 0x4217b3) Build succeeded with 0 Warnings... Message: gcc plug-in: make() Target successfully built gcc plug-in: PlugInUtility::getExternalHeaderFiles Dependency directory does not exist (F7) Build: Build started 9.11.2008 at 12:55:23 make: Interrupt
Exception caught (code = 0xc00000fd, addr = 0x4217b3) Build succeeded with 0 Warnings... Message: gcc plug-in: Error: Object file not found on expected location C:\Users\Tollerteppich\Desktop\AVR-Studio\Servotester\default\Servotester.elf gcc plug-in: PlugInUtility::getExternalHeaderFiles Dependency
-
Thread
SDCC 3.6.0 RC1
bisher keine Files hinterlegt. https://sourceforge.net/projects/z80gcc/
Christian J. schrieb im Beitrag #4974581: > Hier steht was davon, dass der GCC für Z80 portiert werden soll, Die Chance, dass der gcc jemals ein Z80-Backend bekommen wird, schätze ich als äußerst gering ein. Für den LLVM stehen die Chancen ein wenig besser, siehe z.B. https
-
Thread
WinAVR vs. Atmels Toolchain
Jörg Wunsch schrieb im Beitrag #1924050: > AVR-GCC ist ein GCC, der für das "target" AVR konfiguriert worden ist. Ist was über die Atmel-Strategie bezüglich avr-gcc bekannt? D.h. werden sie, wie es bisher mit WinAVR war, auf (gepatchte) FSF-Quellen
Aus der Unwissenheit heraus gefragt ... Würde es Sinn machen nur einen aktuelleren Compiler bzw. GCC einzusetzen. Ich habe allerdings trotz Hinweise auf der GCC-Webpage keine GCC binaries für Windoof gefunden...
-
Thread
Sehr schneller Absolutbetrag AVR
Kriegsfuß. Deshalb hier zur Diskussion: Das ist optimal. Nun schreibs mal in C hin und staune ;-) Optimierung aber einschalten. MfG Falk
[avrasm] sbrc x, 7 neg x [/avrasm] besteht? Ich denke, das ganze lade-speicher kramsel vom gcc kann man eh nicht groß verändern. Habe auch festgestellt, dass der gcc durch bestimmte "programmiertechnische" Kniffs dazu gebracht werden kann, tatsaechlich nur etwa doppelt so großen Code zu erzeugen
-
Thread
einfache pin abfrage problem
Compiler erkennt, daß sie nichts >>tut, wird sie sowieso komplett wegoptimiert. Sofern man die Optimierung nicht abschaltet (-O0). Ist sie eingeschaltet und man möchte aus irgendwelchen Gründen dennnoch mit einer Zählschleife verzögern, dann hilft 'volatile int i'.
Bzgl. der Optimierung muß ich muß Heinzi beipflichten. @Friedrich: Keine Angst ich verstehe das schon als Scherz. Allerdings als einen, der es durchaus Wert ist, sich mit ihm zu beschäftigen. >>> kleines schleifenräzel
-
Thread
Wieviel mehr an Strom braucht man für 64 Bit fähige Mikrocontroller?
der aktuelle Prozessor zu deiner Anwendung passt. Und auch wieviel Zeit die Entwickler in die Optimierung stecken duerfen. Olaf
der aber erstaunlicherweise immer ausgereicht hat. Der Keil-Compiler war sehr geschickt in der Optimierung.
-
Thread
Warnung in GCC
Hallo Gemeinde, ich habe ein kleines Problem mit dem GCC. Er spuckt mir die drei Warnungen aus. ../Hupe_GCC.c:2145: warning: passing arg 2 of `Seconds2BCD' discards qualifiers from pointer target type ../Hupe_GCC.c:2149: warning: passing arg 2 of `Int2BCD' discards qualifiers from pointer target type ../Hupe_GCC.c:2150: warning: passing arg 2 of `Int2BCD' discards qualifiers from pointer target type Als globale Variable ist volatile uint8_t tx_buffer[7]; // buffer for data paket to external display
-
Thread
Welches Programmiergerät für AVR und AVR32
sogar freie Software. Die Linux-Unterstützung für die AVRs ist exzellent: Eclipse + AVR-Plugin + avr-gcc + avrdude alles freie Software und alles aufeinander abgestimmt, kein umständliches Gefrickel, keine Einschränkungen, installieren und läuft out of the box.
kostenlosen Versionen, wo nur die höheren > Optimierungsstufen abgeschaltet sind. Ja, komplett ohne Optimierung, also ungefähr das Äquivalent von gcc -O0 wo der Code doppelt so groß und halb so schnell wird weil zwischen jeder zweiten Instruktion erst nochmal ne komplett unnötige Runde Spilling und Filling
-
Thread
Komplizierte 32-Bit-Rechnung möglichst effizient
ist und ich >eine Vereinfachung übersehen habe. https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
definieren, wenn es keine zusätzliche Einschränkung der Zahlenbereiche der Variablen gibt. Aber der GCC muss fast alles als 32 Bit rechnen, wo eine handoptimiere ASM-Variante deutlich sparen kann. Aber dennoch gilt mein Link oben zum Thema Optimierung! Wenn es auch so ausreichend schnell ist, so what!
-
Thread
Arduino Uno struct in PROGMEM lesen ?
Konstanten kann der Optimizer super gut optimieren. Den Zugriff über Variablen weniger. Wenn man die Optimierung deaktiviert, dann brichts auch mit Konstanten ins Essen. Hier schalte ich partiell die Optimierung per volatile ab. a funktioniert trotz falschem Zugriff, dank Optimierung richtig b funktioniert
Beitrag #7509025: > Du hast das Problem des TO nicht verstanden! > Natürlich liegt es an der Optimierung, dass er "versehentlich" richtige > Daten bekommt, wenn ihm Konstanten verwendet. Wenn ein Programm mit/ohne Optimierung funktioniert, und ohen/mit nicht, liegt es niemals an der Optimierung
-
Thread
Division durch 2er Potenz wird nicht schneller - warum?
>Ich verwende AVR Studio4 mit der Optimierungsstufe Os. Ich vermute mal, dass Du dich auf avr-gcc beziehst -- dann wäre der Bereich gcc das richtige Unter-Forum, da gibt es eher Experten... Und Option 0s, das ist doch bei gcc wohl Optimierung auf kompakten Code, wenn ich mich recht erinnere.
stört und -O1 oder -O2 in den Speicher reinpasst, dann kann man das auch verwenden. Mit #pragma GCC optimize ("O2") ... #pragma GCC reset_options lässt sich das ab GCC 4.4 auch innerhalb vom Code umstellen.
-
Thread
Benutzt hier jemand die Cortex-M4-FPU?
Bauform B. schrieb im Beitrag #6150758: > # DO NOT USE Mit -march=armv7e-m+fp baut der GCC FPU-Befehle auch in > reine > # DO NOT USE Integer-Funktionen ein. Also evt. auch in > Interrupt-Routinen! Nur wenn man ohne Optimierungen kompiliert. Du kannst die FPU auch beim Betreten der
r7 streut der GCC überall hin, selbst wenn r7 nicht verwendet wird. Weiss der Geier wieso. Aber das stört ja nicht, bei dem CPU Takt können die paar ns nichts ausmachen.
-
Thread
Mein Erster, aber welcher?
entwickelt hat, schon. Diese Logik verstehe ich jetzt nicht... Und klar, wenn man schon so irre ist es mit GCC etc. aufnehmen zu wollen dann muss es natürlich Pascal sein.
Der Arduino (also der AVR auf dem Board) wird in echtem C programmiert, übersetzt wird mit dem avr-gcc. Lediglich die IDE ist jede von Processing. Für die Visualisierung auf dem PC wird dann Processing benutzt.
-
Thread
gcc 4.0.0 erzeugt schlechteren Code
Hallo! Ich hab einen Codevergleich zw. gcc 3.4.1 und 4.0.0 gemacht. Hier zuerst der Code aus 3.4.1: void wait (uint16_t zeit) { f6: 9c 01 movw r18, r24 f8: 01 c0 rjmp .+2 ;
Sieht nach Optimierung für Laufzeit statt Codegrösse aus. Schon mal nach einem Schalter dafür gesucht - immerhin hat der gcc davon eine ganze Menge?
-
Thread
codeblocks meckert bei _delay_ms()
Vergessen, die Optimierung einzuschalten?
Optimierung ist an , verschieden schon probiert auch aus...alles dasselbe Desaster... Will mir einfach nicht in den Kopf.... aber es ist nun mal so... ;) Gruss und Dank Gerhard
-
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
Rust - ist das hier um zu bleiben?
Rust-Frontend kommt offiziell in die GCC https://www.golem.de/news/programmiersprache-rust-frontend-kommt-offiziell-in-die-gcc-2207-166831.html
Achja, falls das hier manchen nicht klar ist: GCC + Rust gibt es in zwei Varianten. 1) Rust-Frontend in GCC. Darum ging es hier im Gespräch hauptsächlich. 2) GCC als codegen backend von rustc. Beide werden aktiv entwickelt und beide sind wichtig
-
Thread
Slight Optimization oder Size Optimizations
Beitrag #1979288: > Kann mich jemand aufklären? Du hast Code geschrieben, der abhängig von der Optimierung seine gedachte Funktion nicht mehr erfüllt. Beispielsweise Zeitschleifen, die mit Optimierung nicht mehr (oder nicht lang genug) warten.
Markus schrieb im Beitrag #1980005: > Die Frage war eigentlich warum es mit Slight Optimierung funktioniert > und mit Size nicht, obwohl beide brauchbaren gut optimierten Code > liefern. Ca 30% weniger. Dazu müßte man erstmal wissen, was Du mit "Slight Optimization" meinst. Im GCC-Manual
-
Thread
PROGMEN Array in Schleife verarbeiten
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmspeicher_.28Flash.29 Wenn es ein AVR + GCC ist, was mir meine *Glaskugel* sagt... *Zaunpfahl wink*
Alex schrieb: > War es so gemeint wegen der automatischen Optimierung? Was meinst du mit "automatischen Optimierung"? Bei der Schleifen-Variante führt kein Weg an den Flash-Funktionen vorbei.
-
Thread
Art der if-Auswahl nur Geschmackssache?
Zitat von einem unserer Informatiker: "Code soll für einen selbst übersichtlich und lesbar sein. Optimierung macht der Compiler".
und c auf 32 Bit erweitert werden > und eine 32 Bit Multiplikation ausgeführt werden. Der AVR-GCC macht das schon seit geraumer Zeit besser, zumindest bei Controllern mit Hardwaremultiplizierer. Johann, der auch hier im Forum aktiv ist, hat's gerichtet: https://gcc.gnu.org/ml/gcc-patches/
-
Thread
STM32F303: Empfehlenswerte Compilerargumente
durchgesetzt hat. Die m-Optionen sind ja selbsterklärend - die erstere berücksichtigt bei den Optimierungen, daß verteilte Datenzugriffe aufs Flash langsamer sein können.
https://stackoverflow.com/questions/4274804/query-on-ffunction-section-fdata-sections-options-of-gcc
-
Thread
Kaputt optimiert - was mache ich falsch?
anpassen, denn da liegt dein Hund im Pfeffer oder der Hase begraben oder sowas: solange du die Optimierung ausschaltest, ist der generierte Code langsam genug für das Display. Mit Optimierung hälst du einfach mal das vorgeschriebene Timing nicht mehr ein. Was glaubst du, warum schon zig Programmierer
anpassen, denn da > liegt dein Hund im Pfeffer oder der Hase begraben oder sowas: solange > du die Optimierung ausschaltest, ist der generierte Code langsam genug > für das Display. Mit Optimierung hälst du einfach mal das > vorgeschriebene Timing nicht mehr ein. Aua, ich muss dringend mal wieder einen
-
Thread
sqrtf() ist immer 1 - STM32F401
wird dann aber nicht in r0 zurück gegeben, sondern im FPU Register s0 ¹. Funktioniert auch mit Optimierungen. Das funktioniert so mit dem GCC-ARM-Embedded, welcher u.a. bei der STM32CubeIDE mitgeliefert wird, und auch einzeln hier bezogen werden kann: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads Bei manchen anderen (alten) GCC Distributionen klappt es so nicht. 1: AAPCS https://github.com/ARM-software/abi-aa/blob/2a70c42d62e9c3eb5887fa50b71257f20daca6f9/aapcs32/aapcs32.rst#procedure-calling
-
Thread
Erfahrungen eines Einsteigers
festgehalten habe sind ja auch schon eine Zeit her) und mir einfach mal mit -S zeigen lassen was denn gcc aus dem Original Code macht. Was mir so auf die schnelle auffällt. Wenn ich OCR1A und OCR1B mit den gleichen Werten bestücke (kommt in diesem Program öfters vor) lädt gcc zweimal die Register r24 und
nur wüsste warum, irgendwas habe ich da wohl man unbewusst > verbockt. Hat einer einen Tipp? Optimierung einschalten vielleicht? Ich habe mein Beispiel mit -O2 übersetzt. Ohne Optimierung arbeitet der gcc halt stur nach den Anweisungen, wie sie im Quellcode vorkommen. Schön fürs Debugging, weniger
-
Thread
AVR-GCC: Was ist denn an diesem Code so schlimm?
delay.h: 1.: Parameter müssen konstant und zur Compiler-Laufzeit bekannt sein. 2.: Die Compiler-Optimierung muss eingeschaltet sein. Steht alles auch in der libc-Dokumentation. Übrigens: Falsches Forum...
www.nongnu.org/avr-libc/user-manual/index.html Warteschleifen http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 Die Idee mit der mehrfachen Schleife ist prinzipiell OK. Eine andere Lösung statt Zeitvertrödeln wäre ein Timer.
-
Thread
AVR-GCC: Compilerfehler?
Hallo erstmal, ich hab jetzt mit dem AVR-GCC angefangen, aber wenn ich mir so das Ergebnis anschaue, dann kommen mir Zweifel. Ich hab mir 2 Warteschleifen geschrieben, in der .lst-Datei sehen die dann so aus: void lcd_delay_5ms() { uint16_
Danke. Solche "Optimierungen" hätte ich nicht erwartet. mfg werner
-
Thread
Zugriffe auf Strukturen, Unions etc
sollten sich die C- und C++- Frontends in dieser Hinsicht gar nicht unterscheiden, praktisch aber hat GCC 3.4 aus AVR-Sicht ein paar Eigentümlichkeiten (teilweise auch Rückschritte in der Optimierung im Vergleich zu früheren Versionen), die sich ebenso eigentümlich noch dazu zwischen C und C++ unterscheiden
Frontend produziert wohl etwas anderem Zwischencode und die Instruction-Templates der entsprechenden Optimierung greifen da nicht.
-
Thread
Probleme mit Codeoptimierung/Timer_Wait
Variable nie gelesen wird und damit ungenutzt ist und er sie damit rausschmeisst (bei aktiver Optimierung). >http://www.wer-weiss-was.de/theme9/article92054.html >An volatile-Variablen werden keine Optimierungen ausgeführt, da der >Compiler annimmt, daß sich der Inhalt jederzeit ändern kann, z.
zu der "register" noch eine Bedeutung hatte, existierte "volatile" noch garnicht. Weil mangels Optimierung unnötig. Als die Optimierung kam und "volatile" nötig wurde, wurde "register" unnötig.
-
Thread
avrgcc: verteilte Array-Initialisierung
const Name __flash1 NameTable[] = Named Address Spaces? Was haben die damit zu tun? https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#AVR-Named-Address-Spaces-1
Ursache für die fehlende initReadSensors_Schd_NameTableEntry_ctor() ist Linker-Optimierung. Wenn ich die Option -flto entferne, sind sie im Objekt enthalten. Gibt es eine Möglichkeit, dem Linker mitzuteilen, dass er eine Funktion von der Optimierung ausnehmen soll?
-
Thread
32-Bit Arithmetik mit dem AVR
Hi! Kann es sein, dass der GCC es noch nicht so ganz drauf hat mit 32-Bit Arithmetik im AVR? cplex_data ist eine 32-Bit Variable, seconds, minutes und hours sind 8-Bit Variablen. Das ganze ist für eine Binär-Uhr und soll das Ausgaberegister
wird nämlich die generische GCC MathLib gelinkt, die ist natürlich gross und langsam.
-
Thread
C++ in C Umschreiben
überschrieben werden, weil sie abstrakt (ohne Code) sind. Inline hat eher etwas mit Performance-Optimierung zu tun, das kannst du erst mal außen vor lasen.
wo die C/C++ Grenze verlaufen soll. Oder auch das ganze Ardiuno- und Wire-Zeugs portieren. Mit GCC kann man gemischte C/C++ projekte machen.
-
Thread
Welche Programmiersprache auf µC
+ Compiler in Form des g++ frei Haus kommt. http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/
return printf("Hello, Word!"); } [/c] ...compiliert und linkt ohne Fehlermeldungen mit VC und GCC.
-
Thread
SWAP in GCC
Geht mit inline Assembler: http://www.roboternetz.de/wissen/index.php/Inline-Assembler_in_avr-gcc#swap_Nibbles
in den Fällen zur Laufzeit durchgeführt wird, in denen es eigentlich nicht nötig wäre. Es gibt bei gcc einen Trick, um auch diese Optimierungen zu ermöglichen. Der geht so: [C] static inline unsigned char swap (unsigned char x) { if (__builtin_constant_p(x)) x = (x << 4) | (x >> 4)
-
Thread
Assembler und gcc
überhaupt schlägst, dürfte an den teilweise für den AVR nicht mehr so guten ,,besonders schlauen'' Optimierungen liegen, die GCC 4.3 offensichtlich vorrangig für unsere Desktop-Maschinen mit ihren registermäßig verkrüppelten Prozessoren vornimmt: um die Variable i nicht in einem Register führen zu müssen
movw r30, r24 _SCAN(SCAN_SIZE) ret [/avrasm] Übersetzt wird das dann zB per [pre] avr-gcc -mmcu=atmega8 -c -Os scan.c -DSCAN_SIZE=100 -o scan.o avr-gcc -mmcu=atmega8 -c scan-asm.S -DSCAN_SIZE=100 -o scan-asm.o avr-gcc -mmcu=atmega8 scan.o scan-asm.o -o scan.elf avr-objdump -d scan.elf
-
Thread
Struct als Argument (C++)
Die Optimierungs Algorithmen von GCC und G++ sind a auch logischerweise die selben...
Niklas Gürtler schrieb im Beitrag #5666196: > Die Optimierungs Algorithmen von GCC und G++ > sind a auch logischerweise die selben... Besonders die, die mit Templates zu tun haben...
-
Thread
Wie verhält sich enum ++ beim Überlauf?
muss ich das wohl abfangen :( Langsam wirds eng auf dem 2313.. Weiß jemand, was ich da zur Optimierung alles tun kann? (okay- ist eigentlich nen anderes topic wert..)
Braucht auf dem AVR zwei Bytes (sizeof(int) == 2), aber man kann es beim GCC (dessen Forum das ja hier ist) mittels __attribute__(packed) auch auf ggf. ein Byte reduzieren.
-
Thread
Laufzeitoptimierung
ich wär mir da nicht so sicher), wie auch immer das läuft darauf hinaus, daß beim Debuggen (ohne Optimierung) was anderes als Ergebnis rauskommt, als beim späteren Programm mit Optimierung. Sowas bewusst zu programmieren halte ich für fahrlässig, zumindest wenn es später weiter verwendet wird.
der debug als auch release version constant folding aktivieren. Während dem debuggen stört diese optimierung nicht, da der code nicht umsortiert wird. Meiner Erfahrung nach führt der gcc schon ohne optimierung constant folding automatisch aus.
-
Thread
Aufwandschätzung für Cross-Assembler
absolut nicht vollwertig), denn er kannte keine > bedingte Assemblierung, er kannte keine Makros GCC-Preprozessor :)
vollständige Kontrolle über den Code zu haben. > Auch wenn er vielleicht nicht optimal ist. Eine Optimierung muss nicht eine der "verrückten" Transformationen sein, die der GCC bei -O3 macht. Z.B., der MSP430 hat Konstantengeneratoren, die, je nach Adressierungsmodus -1, 0, 1, 2, 4 und 8 erzeugen können
-
Thread
Balkenanzeige der Temp auf LCD Anzeige
Könnte mir jemand beantworten was diese Fehlermeldung bedeutet? c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: Thermometer.elf section .text will not fit in region text c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: region text overflowed by 460
Könnte mir jemand beantworten was diese Fehlermeldung bedeutet? > > c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: > Thermometer.elf section .text will not fit in region text > c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: > region text overflowed
-
Thread
Schokolade aufteilen ist doch einfach! Oh wait (Programmierknobelaufgabe inside!)
Lösung gibt?! Auch ein Aspekt, ja. Aber in meiner Lösung rührte der TLE daher, dass ich eine Optimierung gemacht habe die dann doch keine war :)
Ist an euren Algorithmen grundlegend was anders als bei mir oder "beschränken" sich eure Optimierung auf effizienteres Ausschließen von unmöglichen Fällen. Eine offensichtliche Optimierung, die ich bei mir sehe ist die Teilmengen effizienter zu generieren. Ich hätte da noch ein Aufgäbchen, die
-
Thread
PIC oder AVR, was ist besser
gut arbeiten, aber nicht unter Linux. Ab PIC24 basieren die C-Compiler von Microchip auch auf dem GCC. Microchip bietet die nur für Windows an. Technisch könntest Du den auf Linux portieren (und dabei den Lizenzmanager rauswerfen), aber die Lizenz der Bibliotheken (kein GNU) verbietet Dir das. (*)
Microchip Verfügbar ist. Na gut, aber wenn ich als Hobby-Fummler auf der anderen Seite auch Optimierung haben kann, dann gehe ich doch da hin, oder?
-
Thread
STM32F4xx: Fragen zum startup
UART2 zu machen, und mit einem Timer die Zeit messen für x Durchläufe. Bitte daran denken, dass der GCC je nach Optimierung evtl. Deinen Code auf nix zusammenstutzt, da alle Variablen nicht wirklich verwendet werden. Deshalb alles irgendwie zusammenzählen, und dann am Ende z. B. via UART ausgeben. volatile ist nicht hilfreich, da es den GCC von Optimierungen abhält. Bitte noch von "Template" nach "fpu-demo" oder so umbenennen. Ich würde es dann so zusammenbauen, dass "Auspacken", "make" zum Bauen für Linux genügt - es gibt hier immer
-
Thread
WinAVR optimiert Wertzuweisung weg?!
Bug in avr-gcc/WinAVR? Oder habe ich einfach irgendwas falsch gemacht...
weil etwas (anscheinend) funktioniert, ist es noch lange nicht richtig ;) Frühere Versionen des gcc (3.xx) waren bei der Optimierung an dieser Stelle zurückhaltender, da ging das auch ohne volatile. Die aktuellen gcc's nutzen die C-Sprachnorm da gandenloser aus, und dazu gehört eben auch das wegoptimieren
-
Thread
AVR clock prescaler (CLKPR) und gcc-Codeoptimierung
Bit (CLKPCE) auf 1 alle anderen auf 0, im zweiten Zugriff stellt man den Teilungsfaktor ein. Mit avr-gcc code sieht das etwa so aus: [c] CLKPR = (1<<CLKPCE); CLKPR = 1;[/c] Sofern man Code-Optimierung benutzt (gcc Schalter -Os), funktioniert das auch wie erwartet, verwendet man keine Optimierung
prescalers wird einfach nicht geändert. Den Grund dafür kann man im Assemblerlisting finden. Mit Optimierung erhält man: [avrasm] ldi r24,lo8(-128) ; tmp44, out 70-32,r24 ; ,, tmp44 ldi r24,lo8(1) ; tmp46, out 70-32,r24 ; ,, tmp46[/avrasm] Ohne Optimierung wird daraus: [avrasm]
-
Thread
Mit dem ATMEL STUDIO 7 klarkommen Gesperrt
sehenden Paste & Copy Code, fehlerfrei zu compilieren ? *volatile* hilft auch nicht. Es ist ein *GCC C Executable Project*. Bernd_Stein
Bernd S. schrieb im Beitrag #7400808: > Was läuft jetzt wieder falsch ? Hast du die Optimierung des Compilers deaktiviert?
-
Thread
Tester für Spezialversion des AVR Bootloaders optiboot gesucht!
EEPROM-Unterstützung hat unsere Version nicht und mit AVR-GCC 5.4 sind noch 34 Bytes frei.
ATtiny von Anno 2014 wie t1634, t841 oder t167, die nach meiner Erinnerung nicht alle von älteren arg-gcc Versionen unterstützt wurden. Außerdem unterscheiden sich die avr-gcc Versionen durch unterschiedliche Optimierung, was natürlich für die Assembler-Quelle keine Rolle spielt. Die Optimierung ist aber
-
Thread
STM32: Arrays und Performance
Gut, dann kau ich das einmal neu durch. Das liegt sicher nicht am GCC. Ich habe hier nen STM32F411 auf 100MHz. GCC 6.2.1 [pre] signed: | O0 | Os | O1 | O2 | O3 ------|--------|--------|--------|--------|------- 8bit | 88.10s | 28.82s |
Beitrag #4923916: > Irks: IIRC deaktiviert -ffreestanding etliche interne Builtins und > Optimierungen, Laut GCC-Doku ist ffreestanding dafür gedacht: "A freestanding environment is one in which the standard library may not exist, and program startup may not necessarily be at main." Genau deswegen
-
Thread
arduino oder GCC Programmierung
sowas, aber libstdc++ ist eine binäre (vorcompilierte) Library (und eins der "missing pieces" beim AVR-GCC, das hat nie jemand bis zu Ende gebracht). Durch all den Template-Kram kann man bei C++ zwar auch mehr in Headerfiles unterbringen, aber das Argument der Compilezeit bleibt dabei natürlich.
Debug unterscheidet sowieso nur Microsoft. ich meine nicht nur das -g, sondern Profile die auch Optimierung und defines anders setzen. Die Optimierung macht debuggen schwieriger.
-
Thread
IRMP - Infrared Multi Protocol Decoder
Das mit F_CPU habe ich mir schon gedacht. Benutze GCC und habe in den Optionen Atmega8+12MHz eingestellt. Sollte dann also passen, danke!
Grundlagen: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Ausg.C3.A4nge
-
Thread
C und LCD Frage.
Bibliothek anpassen oder eine andere nehmen. Z.B. die hier. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#LCD-Ansteuerung MfG Falk
Anfängerfehler wo ich z.B. noch was vergessen haben könnte einzustellen? Ich hab auch irgendwo hier im GCC- Tutorial gesehen das man die Optimierung des Codes einschalten sollte. Aber wo schaltet man die im AVR-Studio ein...hab nämlich bisher noch nirgens was gefunden. MfG Matthias (FlascheGlühweinaufmach