-
Thread
Variable ändert Wert bei Portzugriff
Also Speicher >= 100% ergibt immer komische Effekte. Hat es einen teiferen Sinn, dass Du die Optimierung ausschaltest?
rausgelöscht habe. Im Prinzip ist ja ein Portregister auch nur ein Bereich im Speicher, das der gcc den überschreibt obwohl er es nicht tun sollte?
-
Thread
Ausführungszeit ISR
Beim AVR-GCC dauert ein leerer Interrupt 23 Zyklen: [c] ISR( foo ) { } [/c] Bei 24 Zyklen ist also gerade noch Zeit für ein NOP.
kann man die Frage nicht beantworten - die Laufzeit des Kompilats hängt von vielen Faktoren ab (Optimierung eingeschaltet usw.). Das erfährst Du am einfachsten, wenn Du Dir den Assemblerquelltext des übersetzten C-Schnipsels anschaust. Beim (vermutlichen) gcc-avr steckt der in der *.lss-Datei. Dort
-
Thread
Compiler optimiert einfach Bitmanipulation nicht
OMG! https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung Das gilt nicht nur für Software, auch für so ziemlich alles anders. Mal eine Überlegung. Bei 10 MHz dauert ein Takt = 1 ASM Befehl beim AVR 100ns. Bei
Compiler? Ohne testfall ist das lesen aus dem Kaffeesatz. Evtl. eine Änderung analog zu https://gcc.gnu.org/r192198
-
Thread
Assembler statt C code in start up routinen
ah ok, also prinzipiell wäre es aber möglich (kein optimierung, etc..)?
mitkommt oder bei der Generierung von Libs erst mithilfe des Compilers erzeugt wird: Das ABI von avr-gcc sieht vor, daß in R1 immer der Wert 0 steht. avr-gcc geht davon aus, daß dieser Wert in R1 steht. Wie also bekommt man den Wert 0 in R1 hinein? Nach dem PowerUp stehen in den Registern R0-R31 eines
-
Thread
GCC [STM32] -> wie sehen wie ein struct realisiert wird?
Abhängigkeit des Optimize?) > Stuffing-Bits einführt, etc. Wenn das Layout von Datentypen von Optimierungs-Optionen abhängt, dann ist das ein Compiler-Bug. Bzw. das Layout von Strukturen ist nicht von Optimierungs-Einstellungen abhängig. Optionen wie -f[no-]pack-struct, -f[no-][un-]signed-char etc
als Optimierung. Zur Frage: GCC-Schalter zur Ausgabe des Layouts (in welcher Form auch immer) kenne ich keine.
-
Thread
7-Segment-Ansteuerung
Gerhard O. schrieb im Beitrag #7335374: > Der gcc 5.4.0 braucht übrigens nur 498 bytes > Der gcc 7.3.0 braucht 586 bytes für das selbe Programm Mit gcc-12 (oder 13) und etwas Kosmetik in C++ (was Du ja oben verwendet hast: Arduino) sind es dann
Wilhelm M. schrieb im Beitrag #7335477: > Gerhard O. schrieb: >> Der gcc 5.4.0 braucht übrigens nur 498 bytes >> Der gcc 7.3.0 braucht 586 bytes für das selbe Programm > > Mit gcc-12 (oder 13) und etwas Kosmetik in C++ (was Du ja oben verwendet > hast: Arduino) sind
-
Thread
Was heisst das bitte : --max-allocs-per-node 100000
--max-allocs-per-node 100000: Gibt an, wie viele Teilergebnisse in Berechnungen in manchen Optimierungen berücksichtigt werden sollen. Größere Werte führen üblicherweise zu besserem (schnellerem, kleinerem) Code, aber SDCC braucht mehr Zeit und Speicher während des Kompilierens. 3 Optimierungen sind
Erfahrungswerte interessieren, um wieviel schneller ein (Alltags-) C-Code durch gute Registerwahl/-optimierung wird. Mich wundert etwas, das der Akku A mit bei der Optimierung betrachtet wird, weil dessen Verwendung bei den Arithmetikbefehlen 'unausweichlich' ist. > statt die > Register af, bs, de
-
Thread
Prüfungsfrage
Beitrag #3497942: > Basierend auf was wird eine Reihenfolge festgelegt? Auf Basis vom Quellcode des GCC. Es kann sich aber in der nächsten Version wieder ändern. Im schlimmsten fall ist es sogar abhängig von den Speicheradresse der internen GCC Strukturen - ist aber auch egal. Das das verhalten nicht
schrieb: >> Basierend auf was wird eine Reihenfolge festgelegt? > > Auf Basis vom Quellcode des GCC. Es kann sich aber in der nächsten > Version wieder ändern. Im schlimmsten fall ist es sogar abhängig von den > Speicheradresse der internen GCC Strukturen - ist aber auch egal. Das > das verhalten
-
Thread
Arduino Libraries zu STM32 Portieren
aussieht, hast du ja nun selber herausgefunden. > 4.) > Was Seegen und Fluch zu gleich ist, mit den GCC Compiler lassen sich die > verschiedensten CPU Hersteller unterstützen. Was auch immer das mit Arduino zu tun hat. Die Arduino-Leute haben schlicht gar keine Aktie an gcc. Sie nutzen den gcc nur
Somit haben > alle IDE's irgendwelche Probleme. Und wenn es der Compiler ist, der bei > vielen IDE's GCC heißt. Der GCC ist mit Sicherheit die letzte Fehlerquelle - nicht nur bei Ardunio.
-
Thread
Macht GCC 4.2.1 fuer AVR hier einen Fehler?
richtiges Ergebnis auf dem AVR. Die Funktion fällt also nur im Verbund der gesamten Applikation und GCC 4.2.1 auf die Nase. Was kann denn sowas sein? Problem mit dem Stack? Zu viel Optimierung von Seiten GCC? Gruß Jürgen
> Was kann denn sowas sein? Problem mit dem Stack? Zu viel Optimierung von Seiten GCC? gcc 4.2's Verhalten bei undefined behavior (UB) ist anders als bei der 3er Serie. So werden signed int operation jetzt defaultmässig so optimiert als ob es keinen Überlauf gäbe
-
Thread
Honeywell Rondostat HR20E per AVR steuern und konfigurieren
, also sprich GCC 4.2.2 sowie avr-libc 1.6.0." Es hat nicht jeder Windows ...
Optimierung macht ist ... (Das ist klar, man sagt mach mal und Optimiere nichts). Aber das aus einer Funktion die nur einen Wert einer Variablen Meldet 40 Befehle werden... Mit Optimierung ist es wie es sein
-
Thread
Double gegen Integer
Dennis H. schrieb im Beitrag #6167517: > macht gcc/cc von sich aus Gebrauch von AVX/SSEx ? Muss er halt nachschauen, wie sein gcc configuriert ist. Üblicherweise erstellt der generischen (ARM64)-Code. Wer aber auf dem level optimiert, soellte
auf einer HP Z440 Workstation mit 8 > Kernen. > (deshalb auch unter PC Programmierung gepostet). GCC ist mit 7.4.0 schon > etwas altbacken ist halt bei der LTS dabei Mach mal das Ubuntu nicht schlechter als es ist: gcc in Version 8.3 ist auch bei der 18.04 LTS als Paket zu haben.
-
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] Tiny 44 - Rundungsfehler?
schneller ist als / ob ich spassenshalber mal Ports setzte in beiden Fällen und die Zeit messe ob der gcc deiner Meinung ist?
Links-Schieben. > ob ich spassenshalber mal Ports setzte in beiden Fällen und die Zeit > messe ob der gcc deiner Meinung ist? Assembler Listing ansehen reicht.
-
Thread
llvm für avr
und hat bei den Dependencies herumgezickt.) Unten ein besserer Vergleich des Codes von oben. GCC 4.9.3 entfernt ein unnötiges Compare im Vergleich zu GCC 4.8.1 (-2 bytes). Interessanterweise erzeugt LLVM für die erste Schleife besseren Code, während GCC bei der zweiten SChleife besser ist. GCC
r24,1 sbiw r24,0 brne .L5 ldi r24,0 ldi r25,0 ret .size main, .-main .ident "GCC: (GNU) 4.8.1" [/code] GCC 4.93 > avr-gcc -Os -c -S hello.c -std=c99 -o hello_gcc_t85.s -mmcu=attiny85 [code] .file "hello.c" __SP_H__ = 0x3e __SP_L__ = 0x3d __SREG__ = 0x3f __tmp_reg
-
Thread
AVR Problem avr/io.h: No such file or directory
deaktivirien. Path zum avr-gcc eintragen, z.B. C:\WinAVR\bin\avr-gcc.exe Path zum make eintragen, z.B. C:\WinAVR\utils\bin\make.exe AVR Studio 4.19
/avr-gcc[/pre]verwendet, dann gehört[pre]/foo/bbar/baz/avr/include[/pre]zu den Standard-Systemincludepfaden. Der Pfad muss nicht extra angegeben werden. Wenn man[pre]/dingens/bummens/bin/avr-gcc[/pre]verwendet
-
Thread
Warnung / Fehler nach casten von char a[] zu uint_32*
attribute versehen, dass es an die richtige Bytegrenze gelinkt wird. Näheres verrät die Doku zum GCC
Doku zum GCC > > Falsch. Minimalbeispiel ist angehaengt! Standarteinstellung verstehe ich als: [code]gcc main.c[/code]. Damit läuft der Compiler mit Warnung durch. Kein Abbruch (-Werror fehlt ja...) und vor
-
Thread
Atmel Studio 7 Simulator Debug
Probiere es halt aus. Und ansonsten empfiehlt sich für alle AVRs eher die Option s zur Optimierung. Oliver
GCC 5. Hier mal ein ganz knappes Beispiel mit einem GCC-ARM: https://godbolt.org/g/yEku3P Das Beispiel ist natürlich etwas konstruiert und in der Realität hat man eher nicht so knappe (und überflüssige
-
Thread
String besteht nur aus 0xFF - Linkerproblem? AVR Studio 7
nicht) in uint8_t. Schalte in der Compiler-Konfiguration die Warnings auf -Wall und die Optimierung auf -O0 (keine Optimierung). Jetzt solltest Du das Programm noch einmal compilieren und testen. Sollte funktionieren.
\ATmega_DFP\1.0.90\gcc\dev\atmega2560" Finished building target: UART-Test.elf "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock
-
Thread
switch Case läuft nicht im AVR Simulator
Kalkulation ist allerdings alles andere als perfekt. Zumal er diese Entscheidung möglicherweise vor der Optimierung trifft.
Arr[i]() müssten in direkte umgewandelt werden -- ggf. Arr[i] inlinen -- weiter optimieren GCC 4.3 ist noch nicht so weit. Johann
-
Thread
Ersatz für XC32-Compiler?
Zonk schrieb im Beitrag #6081858: > Irgend einen schönen GCC oder so? Das ist ein GCC! Geh zu Microchip und bring uns den Quelltext. http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v2.20-full-install-release-notes.html PS: Dann versuch auch ich
Im "chipkit core" ist ua. eine uneingeschränkte pic32 gcc toolchain enthalten.
-
Thread
Programm von mega32 auf mega328P convertieren
installiert wurde?) Das Ergebnis ist gleich (riesig). Ich habe die *.C-Datei mal in das Verzeichnis von 'avr-gcc' kopiert und den Aufruf von diesem Verzeichnis gestartet. Ergebnis: avr-gcc: error: CreateProcess: No such file or directory Warum kann man im AVR-Studio unter Custom Options/External Tools/avr-gcc
4.5er Version! Also: direkten Verweis auf 'avr-gcc-4.7.2' -> jetzt geht's!
-
Thread
LPC2103 63MIPS?
sondern die Einfachheit der Programmierung von größter Bedeutung. Langsammer Prozessor -> viel Optimierung erforderlich -> viel Zeit erforderlich Schneller Prozessor -> weniger Optimierung erforderlich für gleiche Performance -> weniger Aufwand bei gleichem Endergebnis und weiteres Potenzial bei Bedarf
Compiler (Version) angegeben werden. 2. Dann sollte sichergestellt werden, daß immer die beste Optimierung für Geschwindigkeit gewählt wird. 3. Da der C32 teilweise sehr "wild" optimiert, sind Memory Barriers (asm volatile ("":::"memory"); // in GCC) nützlich, damit man auch wirklich sicherstellt, daß
-
Thread
inline vs -O0
Mit meiner Lösung bin ich sehr zufrieden. Wollte allerdings noch testen wie sich das Ganze ohne Optimierung verhält. Allerdings compiliert mir mein Code mit -O0 garnicht erst: undefined reference to *** Aktueller avr-gcc. Hab auf die schnelle nichts gefunden. Aber inline müsste doch auch ohne
muss sich dieses Hinweises nicht annehmen (so, wie früher auch "register" nur ein Hinweis war). GCC inlinet die entsprechende Funktion, sofern sie seiner Meinung nach klein genug ist, /und/ sofern die Optimierungen zugelassen sind. Die Idee dabei ist einfach, dass jemand, der ausdrücklich keine
-
Thread
In ISR Inlining einer selten benutzten Funktion vermeiden um pushs zu sparen
er es aber in "offensichtlichen" Fällen nicht. Und die nächste Frage, ob gcc so implementiert ist, dass er das tut; offenbar nicht. Leider kann ich die letzte Frage nicht beantworten. Aber hier treibt sich doch einer herum :-) der am gcc zugange ist. Interessant wäre mal
vor die ISR zu setzen. Dazu musst du Shrink-Wrapping im AVR-Backend implementieren. Diese Optimierung gibt es bislang nicht bzw. entsprechende Hooks sind für avr nicht implementiert, d.h. wenn du wirklich darauf angewiesen bist, dann bleibt dir nur Assembler (oder C++ für die GCC-Quellen).
-
Thread
Mikrocontroller in C++ oder C Programieren
sein liebstes syntaktisches Konstrukt in C++ sei: "}" Zum Experimentieren ist übrigens http://gcc.godbolt.org/ wirklich gut geeignet. Wer dort allerdings den neueren avr-gcc (> 6.2) drin haben möchte, muss sich das lokal aufsetzen. VG
daher kann es gut sein, dass der Compiler es doch nicht ohne weiteres frisst. Die Info war aus dem GCC Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171#c13 Bei GCC Version 4.7 funktioniert es aber noch reibungslos bei mir. Ist aber zugegebenermaßen auch hoffnungslos veraltet. Eventuell
-
Thread
Schiebeoperation mit int16_t-Variable
> ich möchte eine Division durch 4 mittels Schiebeoperation durchführen, > da der Compiler (Optimierung -Os), das wohl nicht automatisch macht, Was, zumindest beim gcc, im Übrigen nicht stimmt. Der Compiler achtet nur darauf, nicht den gleichen Fehler zu machen und bei negativen Zahlen in die
erhebt sich die Frage, warum sie dann ein int16_t ist und kein uint16_t. Denn dann klappts beim gcc auch wieder mit dem einfachen Schieben. Ich bleibe dabei: Solche Low-Level Optimierungen überlässt man sinnigerweise dem Compiler. Der kann das besser.
-
Thread
C Programm zu langsam
- Alternativ manuelles Loop-unrolling etwas mehr bringen - Vielleicht auch mal die Code-Optimierung auf max. einstellen.
der Compiler, wenn Optimierungen einschaltet sind.
-
Thread
AVR-GCC nutzt 16 Bit für uint8_t Variable
GCC geht ganz natürlich davon aus, dass die zugrundeliegende Maschine mit "int" optimal umgehen kann. Was bei fast allen Zielmaschinen auch stimmt, nur eben bei AVR nicht. Pech. Dafür hat GCC hundert
im Wörterbuch nachschlagen, trotzdem ist für mich in dem Satz keine Info enthalten, was diese Optimierung nun tatsächlich tut. >> Dass der gcc aber jedes char grundsätzlich erstmal als int behandelt, >> kann ich noch nicht so recht glauben. > > Er muss. So ist Artihmetik in C nun einmal definiert
-
Thread
Speicherfresser Atmega
Hallo Markus, wie sieht den dein Makefile und die optimierungs Optionen aus ? CFLAGS += ... _
richtig, ich hatte nicht auf den Namen geschaut. Mehr ist dann auch nicht mit automatischen Optimierungen machbar. Evtl. spielt man mal mit dem avr gcc 4.7.
-
Thread
newlib fuer AVR?
Am einfachsten generiert man die newlib in-tree, d.h. * in GCC_SRC: ln -s NEWLIB_SRC/newlib * Falls libgloss gewünscht: in GCC_SRC: ln -s NEWLIB_SRC/libgloss * configure-build-install GCC Zunächst stellt sich aber die Frage, was du mit newlib überhaupt
, haben, abgesehen vom Host-OS, eine merklich kleinere Bandbreite. > und wörtlich behauptet avr-gcc sei tot, während Microchip/ATMEL Über die Politik der genannten Konzerne kann ich nichts sagen. avr-gcc ist GNU-Software, deren Copyright bei der FSF liegt. Mein Einblick in GCC und avr-gcc beruht
-
Thread
GCC: -ffunction-sections verändert Programmlogik - warum?
Eine Frage zur Wegoptimierung von ungenutzten Funktionen durch den Linker: Ich wollte die Optimierung zum Entfernen von unbenutzten Funktionen aktivieren (vgl. http://www.mikrocontroller.net/articles/GCC:_unbenutzte_Funktionen_entfernen) Auf dem ATXMEGA256A3 hat sich die Codegröße danach von
Optimierung nicht unterscheiden. Nein Marcel, sorry fürs Noch-nicht-Beantworten der Mail, ich habe da auch keine Idee, ohne dass man den Kram komplett analysiert.
-
Thread
C Best Practice für konstante globale Variablen
config.h nenne. Das sind keine Variablen, und zwar mit Absicht, damit sie kein RAM belegen. Beim arm-gcc sorgt das Schlüsselwort const schon dafür, dass kein RAM belegt wird. Aber beim avr-gcc geht das nicht so einfach, deswegen #define. Was nicht konstante Variablen angeht: Diese vermeide ich wo immer
sollte aber Wartbarkeit sein. Code zu warten, bei https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
-
Thread
c code optimierung ev. assembler?
Stefan Ernst schrieb: > Du solltest mit den "Optimierungen" als erstes mal bei deinem > Programmierstil beginnen. Warum sind z.B. alle Variablen 16 Bit groß, > obwohl bei den meisten 8 Bit reichen würde? > Damit ist das hier auch wirklich kein Wunder
Entschuldigung angenommen: int auf AVR-GCC sind 16 Bit! Doku lesen.
-
Thread
GCC 4.1.1. schlechte Optimierung
Noch was vergessen, die Kommandozeile: avr-gcc.exe -xc -Os -mmcu=attiny26 -Wall -g disptime.c Peter
nicht alle überblicken, da er sich ja > immer nur auf eine Compilation-Unit konzentriert. Bei GCC 4 nicht mehr notwendigerweise, man kann ihm auch mehrere compilation units gemeinsam vorwerfen.
-
Thread
List File bei AVR-GCC/WIN AVR
mal mit was ganz einfachem begonnen: LED an Portpin einschalten In Assembler ein Zweizeiler. Im AVR GCC nach Compilieren an die 100 Byte. Entsetzen nach Ansicht des Assembler-Files, was da an Bytes völlig sinnloserweise zwischen SRAM, Registern und Stack hin- und hergeschaufelt wird. Optimierung ist
mit was ganz einfachem begonnen: LED an Portpin einschalten > In Assembler ein Zweizeiler. Im AVR GCC nach Compilieren an die 100 > Byte. > Entsetzen nach Ansicht des Assembler-Files, was da an Bytes völlig > sinnloserweise zwischen SRAM, Registern und Stack hin- und > hergeschaufelt wird. Optimierung
-
Thread
WinAVR Bug: Crash wegen Codegrösse
Hallo Zusammen, Hallo GCC-Compiler-Experten, Ich habe wohl einen Bug am avr-gcc entdeckt: Ich arbeite an einem grösseren System (Atmega 2560 / WinAVR 20071221). Die Codegrösse (binär) liegt bei ca 135kB. Bisher lief über
immer wieder Probleme damit. Ich habe auch Festgestellt das es auch von Version zu Version des AVR-GCC anders ist :-), ja nach dem wie gepatcht wurde. Bosonders ärgerlich ist dieses Problem wenn man viele "Daten" im Flash hat die mehr als 64Kbyte belegen, da bekommt der AVR-GCC dann Probleme. CA Dirk
-
Thread
PIC32MZ vs. Atmel
gibt es, und die Compiler kannst du auch kommerziell nutzen, > natürlich hast du dann keine Optimierung. Wie siehts denn bei dieser ominösen Optimierung überhaupt aus? Bei den PIC30/33 verwendet Microchip ja den GCC und glaub irgendwie nicht recht, dass das beim PIC32 anders ist. Insofern sollte das Thema Optimierung wohl nicht so zentral sein. Weil man unter Linux in der Lage sein sollte, ggf. auch direkt den offiziellen GCC zu verwenden.
-
Thread
Eigener Bootloader stm32f103
Test zeigt eine um 25% reduzierte Größe für ein gerade hier > rumliegendes Cortex-M0 Binary. Mit GCC erstellte Cortex-M Binaries enthalten eine Menge Null-Bytes, d.h. relativ wenig Entropie. Wäre eigentlich mal interessant zu testen ob man durch clevere manuelle Assembler-Optimierung Null-Bytes und
einen Report zu erstellen... Oder bevor ein neuer PR erstellt wird mal die Entwickler fragen in gcc-help@gcc.gnu.org. Vielleicht gibt es ja schon nen PR dazu. Die Internals sagen nicht viel zu MEM_ALIAS_SET und wie die für arm umgesetzt sind. https://gcc.gnu.org/onlinedocs/gccint/Special-Accessors.html
-
Thread
Bitmanipulation optimieren
Nein. Es ist Zeitverschwendung und ein großer Irrtum. http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung Die einzige Mikrooptimierung ohne nennenswerten Aufwand ist eine direkte Zählung mit Schrittweite 4. Das spart aber gerade mal zwei Shiftbefehle und damit
Beitrag #3052998: > Sven P. schrieb im Beitrag #3052915: >> PORTC ist volatile, daher ist die Optimierung eigentlich nicht ganz >> legal. > > Genau deshalb besteht an der Stelle ja Optimierungspotenzial von Hand: --> Einfach eine Zwischenvariable verwenden.
-
Thread
debuggen in Codeblocks klemmt
Auch mal ohne Optimierung kompilieren.
Dumdi D. schrieb im Beitrag #4338540: > Auch mal ohne Optimierung kompilieren. unter dem Menüpunkt "Settings compiler" compiler flags ist eine größere Liste möglicher Einträge. Angehakt ist da momentan nichts. Was sollte da ggf. angehakt werden? "Produce
-
Thread
PIC32 RAM löschen
Holli schrieb im Beitrag #2879842: > - Er bietet diverse Optionen zur Code Optimierung Das wäre m. E. das einzige wirklich interessante, da der freie mips-elf-gcc im Vergleich zu den anderen, vom GCC bedienten Plattformen relativ große Kompilate erzeugt.
viel, wenn dahinter tatsächlich der gcc stecken sollte.
-
Thread
C++ / Threads
implementiert (hat/oder noch immer macht) daß da automatisch Memory Barries gesetzt werden was z.B. GCC nicht tut.
das es klar ist. Wohlgeordnet in C muss nicht so in Maschinencode übersetzt werden. Gerade mit Optimierung darf der Compiler da auch umsortieren.
-
Thread
Optimierung bei delay.h
Nabend Ich habe auch ein Problem bezueglich der Optimierung der Schleifen. Habe nun gut ne Stunde gesucht, bis ich rausgefunden habe, dass meine Delayschleifen beim Initialisieren des LCD's vom Compiler wegoptimiert werden. Nein, ich verwende keine eigene
Prinzipiell der Code aus dem LCD AVR-GCC Tutorial lcd.h: [code] #ifndef F_CPU #define F_CPU 16000000UL /* Quarz mit 16 Mhz */ #warning "F_CPU not defined. Define default Value 16Mhz" #endif //Default Port Definitions #ifndef
-
Thread
Wieso gibt es keine gute Programmiersprache?
nicht zu Potte kamen hats schonmal eines meiner Projekte verzögert. Da ist es mir lieber was zum GCC zusammenzugoogeln. Und GCC Supportfirmen gibts wie Sand am Meer, musst nur mal gidf.de aufrufen.
Daniel A. schrieb im Beitrag #4786453: > Das passt nicht Zusammen. avr-gcc ist soweit ich weiss gratis. Wenn man > auf einer noch supporteten Version ist, [...] Das war einfach ein reales Beispiel, in diesem Fall mit dem GCC. GCC ist gratis, der Bug war schon längst gefixt
-
Thread
WINAVR GCC Entfernt bei Optimierung einfach Funktionen
keinerlei hinweise auf derartiges gefunden... Wer weiss warum die markierte funktion bei allen Optimierungs Optionen (ausser 0) einfach weg ist? Wenn ja dann bitte eine möglichkeit wie ich es erfolgreich verhindern kann!! danke! [c] int main (void) { BYTE channel=3; WORD data=0; BYTE
habe. aber scheinbar war das ja auch nicht genug. ich dachte da eher an jemanden der wirklich mit GCC vertraut ist und etwas mehr weiss als die manuals hervorbringen und mir diese eine simple frage beantworten kann: !! Warum Strippt/kombiniert der GCC Compiler mit der Option Os, O1, O2, O3 mir einfach
-
Thread
ATTINY 2313 - Passt da überhaupt ein Programm drauf?
Boris B. schrieb im Beitrag #1859331: > PS: Als Optimierung habe ich Os gewählt, das sollte ja eigentlich > kleinen Code produzieren, oder? "0" ist gänzlich ohne Optimierung "s" sollte gute Ergebnisse liefern Gruß, Magnetus
@Magnus Müller das ist ein O keine 0 -Os benutzt er, also Optimierung s, nicht -0s bzw. -O0s
-
Thread
Wieso generiert der Compiler Chaos?
wildesten Effekte. Ausserdem verhält sich das Programm unterschiedlich, je nach eingestellter Optimierung, aber auch mit 'O0' funktioniert das Programm nicht richtig. Ich benutze keine delays, die sich ja je nach Optimierung anders verhalten können, der Code wird mit 0 Warnungen compiliert. Ich kann
vermuten: ___________________________________________________ Build started 3.3.2008 at 14:57:38 avr-gcc.exe -mmcu=attiny861 -gdwarf-2 -std=gnu99 -Wall -DF_CPU=8000000UL -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT CD1.o -MF dep/CD1.o.d -c ../CD1.c avr-gcc.exe
-
Thread
AVR führt Programm nicht aus, wenn zusätzliche Funktionen definiert sind
Das ist exakt das, was ich mit avr-gcc übersetzt habe.
Das Programm ist nur ein Test, dementsprechend _wirklich_ vollständig oben abgebildet. Die Optimierung habe ich zumindest nicht bewusst ausgeschaltet, ich habe den Schalter -Os von avr-gcc verwendet. Dass die Funktion test() nicht ausgeführt wird, ist Absicht. Du sprichst von "Wegoptimierung",
-
Thread
XMega-Assembler: Welche Register darf ich verwenden?
GCC benutzt man sinnvollerweise dessen Constraint-System, um ihm eine maximale Integration in die Optimierung zu ermöglichen. Dann legst du die Register auch gar nicht mehr selbst fest, die du benutzt
data space Das Rückschreiben hier ist verdächtig. Ich glaub du hast nicht wirklich mit Optimierung übersetzt.