-
Thread
Microcontroller ATmega8 macht nicht was er soll
bedeuten. http://www.mikrocontroller.net/articles/Bitmanipulation Auch die ersten paar Kapitel vom Gcc-Tutorial AVR-GCC-Tutorial sind als Ergänzung zu deinem Skript sicherlich hilfreich. > Muss ich jetzt etwa wenn ich sage DDRB = 0xFF; alle ausgänge erst > ausschalten indem ich sie auf 1 setze
auch richtig gebrannt wurde. Ach, da fällt mir noch was ein. Da du _delay_ms verwendest: Die Optimierung des Compilers ist auf -Os gestellt?
-
Thread
delay.h defekt
- Compiler optimierung geändet/ausgeschaltet Nicht ausschalten, einschalten.
Also Optimierungen hab ich alle ausprobiert -O0 bis -O3 und -Os Variablen sind jetzt alle volatile. Christian H. schrieb im Beitrag #1739309: > anzeige_7seg_zahl(startcounter); > _delay_ms(1000); > startcounter
-
Thread
Probleme mit der Case switch anweisung
Und es gibt durchaus auch eigene Fehler, die erst bei eingeschalteter Optimierung auffallen (vergessenes volatile ist da wahrscheinlich der Spitzenreiter). Insofern ist die Geschichte nicht unglaubwürdig, nur die Schlußfolgerung daraus ist falsch ("keine Optimierung einschalten
für solche Funktionen ggf. den Weg wählen, wie er solche Anwendungen dokumentiert ist, z.B. beim AVR-GCC bzw. WinAVR mit ISR() arbeiten.
-
Thread
Sicherheitsrelevante Software
Ich schrieb im Beitrag #1733019: > Der AVG-GCC ist betriebserprobt. Ich weiss, dass er in Firmen teilweise > für Anwendungen mit SIL4 verwendet wird. *grmpf* Nachdem ich gestern auch selbst noch auf die Erprobtheit des GCC verwiesen hatte, wurde
definitiv aufgetreten. Somit kann ich derzeit leider keine Hinweise für die Fehlerkorrektur des GCC geben. :-(
-
Thread
Programmoptimierung
bitte nächstes mal einen etwas besseren Threadtitel! Was hat das ganze den Bitte mit Programm"optimierung" zu tun?
drin bin. Karl heinz Buchegger schrieb im Beitrag #1732937: > Für solche Sachen sollte das AVR-GCC-Tutorial deine erste Anlaufstelle > sein Das erwähnte "irgendwo" schliesst das AVR-GCC-Tutorial mit ein. Dort habe ich schon viele Lösungen für Probleme gefunden. Karl heinz Buchegger schrieb
-
Thread
Visualisierung von geloggten Daten
Hallo Zusammen! Diesmal im Anhang nur wenige Änderungem: - kleine Optimierung zur Verbesserung der Geschwindigkeit, - Druckfunktion nun fast brauchbar, Allerdings steht jetzt der nächste große Schritt ins Haus: die Integration der Konvertierung von Fremdformaten. In der
provozieren sollen. Zum Selbstcompilieren: Du kannst die "c.bat" hierfür benutzen, es sollte die GCC verfügbar sein (das bin-Verzeichnis im Suchpfad) und die Umgebungsvariable "lib" sollte auf das lib-Verzeichnis der GCC zeigen. Mich richtig mit "make" zu beschäftigen, hab ich bisher noch nicht die
-
Thread
WinCC Outputgrößen bei Optimierung
sich die Outputgrößen irgendwie nicht so verhalten wie ich es erwartet hätte, nämlich so: - Ohne Optimierung: Output: 7,05kB - mit -O/-O1 : 7,15kB - mit -O2 : 7,64kB - mit -O3: 7,75kB - mit -Os: 7,63kB Was ich nicht verstehe, ist, dass -Os so einen großen Output liefert, gerade im Vergleich zum
Versuch mal zusätzlich: > > -fno-inline-small-functions hmmm, ich dachte das wäre längst in gcc? Sind nur ein paar Zeilen das. FYI: [pre] Index: avr-protos.h =================================================================== --- avr-protos.h (Revision 160067) +++ avr-protos.h
-
Thread
Frage zum ODM100 OLED Bausatz von ELV
von Anfang an ging, aber egal, jetzt gehts ja. Hat schon jemand den ODM100 Displaytreiber auf AVR-GCC portiert? Bin schon gespannt auf erste Projekte. So long Remo
ODM100.c Source Code für das Display gibt es doch eh bei ELV zum Download. Der Müsste doch mit dem AVR-GCC laufen. Wennst die RTC ansprechen willst hätte ich noch Code dafür... http://www.mikrocontroller.net/topic/183980#new
-
Thread
2 Bytes zusammenfassen/ rechtsschieben
Hallo zusammen, Ich bin von Assembler auf C, mit dem GCC Tutorial bin ich zwar weit gekommen aber jetzt komme ich nicht mehr weiter. Ein ADC ( ADS7822 ) liefert den µC 2 'zerstückelte' Bytes, welche ich entsprechend aufbereiten möchte damit ich diese problemlos
den Optimizer gilt (wie immer): Das Ergebnis darf sich nicht von dem unterscheiden, was man ohne Optimierung erhalten hätte. Er ist an die "As If" Regel gebunden. D.h. auf einem AVR ist daher grundsätzlich jegliche Berechnung erst mal mindestens 16-Bit (es sei denn, Optimizer, eh schon wissen)
-
Thread
Disassembler Anzeige bei AVR Studio
bei Adresse Null an! Das sieht irgendwie total durcheinander aus. Kann das vielleicht mit der Optimierung zu tuen haben? Wobei die auf -Os steht. Hab mal die ersten Zeilen eingefügt ----UNKNOWN_FILE------------------------------------------------------------- 0: File not found +00000000: 940C0038
Aber was soll denn der Default Handler machen? Er weiß ja nichts von deiner Hardware. Also sind die gcc Leute den Weg des geringsten Widerstands gegangen und haben das einzig Sinnvolle getan, was sie tun können: Sie lassen das komplette Programm neu starten. Das gibt dir zum einen die Chance, den Fehler
-
Thread
Open source Autoradio
/E/Daten/Etechnik/SuperH/sh7262/Dokus/gcc: l insgesamt 31M 348K 2010-05-24 14:29 asp_cq_frksh2a_gcc-20100409.tar.gz* 929K 2010-05-24 15:20 cq_gnu_resources20100424.tar.gz* 217K 2010-05-24 15:19 cq_sh7262_gcc.zip* 28M 2010-05-24 14
start.elf start.bin [olaf] ~/sources/SH2A/test1: sh2a-gcc --version sh2a-gcc (GCC) 4.5.1 Meine Test-LED blinkt. :-) Olaf
-
Thread
8 bit vs. 16 bit
Auch AVRs tun sich nicht wirklich leicht mit Daten auf dem Stack, > insbesondere wenn man wie der GCC nur einen Stack verwendet. Die haben halt damals beim Entwurf nicht über den Tellerrand in Richtung GCC geguckt, sondern sich ausschließlich auf die Kommentie- rung durch die Haus- und Hoflieferanten
Das Problem einer 8-bit-Architektur gegenüber der 16-bit-int-Forderung > von C dürfte eher der AVR-GCC-Implementierung denn der 8-bit-CPU > anzulasten sein. Mir ist klar, dass GCC hier ganz spezielle Probleme hat, weil das im maschinenunabhängigen Teil einfach nicht vorgesehen ist, es aber dort realisiert
-
Thread
ATTINY13: Noch ein CLKPR Unfall - bei HVSP Programming
möchtest. Für Vorteiler 1 müsstest du als zweiten Schritt eine 0 schreiben. Funktioniert aber im AVR-GCC nur dann, wenn du die Optimierungen einschaltest, sonst wird der Code u. U. zu langsam für die vier- Takte-Zeitforderung. Besser ist daher: [c] #include <avr/power.h> ... clock_prescale_set
Jörg Wunsch schrieb im Beitrag #1717346: > Funktioniert aber im AVR-GCC nur dann, wenn du die Optimierungen > einschaltest, sonst wird der Code u. U. zu langsam für die vier- > Takte-Zeitforderung. Besser ist daher: > #include <avr/power.h> > > ... > clock_prescale_set
-
Thread
C-Compiler selbstgeschrieben.
Maschine) nicht wirklich schwer. Das ist straight-forward. Richtig schwer wird es dann, wenn Optimierungen gemacht werden sollen, die über die einfachsten Formen der Optimierung (Constant-Folding, Common Subexpression Elimination, Multiplikationen durch Shift ersetzen, Divisionen durch & u. dgl.) hinausgehen. Sobald Optimierungen über mehrere Statements bzw. mehrere Funktionen hinweg greifen sollen, wirds aufwändig. Mehrere Statements gehen noch, indem man eine Funktion als ganzes als einen Baum darstellt, aber darüber
-
Thread
zugriff auf arrays optimieren
@Lars R.: Du solltest mal die Optimierung beim AVR GCC einschalten! Du wirst sehen, dass er dann viele deiner tollen "Handoptimierungen" von selber macht! Bei dem was du da schreibst, hast du entweder die Optimierung nicht an, oder beziehst
Hallo Klaus, > @Lars R.: > > Du solltest mal die Optimierung beim AVR GCC einschalten! [...] Ist diese Antwort ernst gemeint, soll ich nun lachen?!? Ich aktiviere grundsätzlich die Optimierungsstufe -Os beim avr-gcc. Ich habe auch extra noch angemerkt
-
Thread
NIXIE Uhr mit vielen Funktionen in C mit ATTiny2313
eine Kleinigkeit am Sourcecode ändern, aber der Zielcode wird immer zu groß. Trotz maximaler Optimierung über Compilerflags komme ich mit dem Original Source nicht unter 100.5% Textsegment Größe (2058 Bytes). Ich nutze AVR Studio 4.1.8 Build 684 Aber auch unter Linux mit dem avr-gcc 4.7.2 komme
Kurze Rückmeldung: Die Version 4.1.2 des avr-gcc hat's gebracht: 2026 Bytes YES! Danke! Lothar
-
Thread
ganz einfache c frage (break, verschachteltes for)
Ist das nicht C++? Der gcc übersetzt das.
Schleifen schon etwa eine Verzehnfachung des Durchsatzes erreichen! Und mit ein paar anderen Optimierungen zusammen ergab sich nochmals eine Steigerung um 10%. Auch heute gibt es Simulationen und andere Berechnungen mit einem gigantischen Rechenleistungsbedarf, so dass auch dort schon minimale Optimierungen
-
Thread
CP/M auf ATmega88
ohne Übertaktung. Mit 8-bit + Übertaktung sind ca. 2MHz 8080 Speed drin.. Und noch weitere Optimierungen des Codes kommen on Top. Peter
Hallo Frank, das wars ... neuer GCC und schon läufts... gruß Hans-Werner
-
Thread
ATtiny24 - Codegröße, Flashgrenze erreicht
[[AVR-GCC-Codeoptimierung]]
kleinen Code zu bekommen, sind Pauschaltipps oft unbrauchbar. Man muss schon recht gut wissen, wie GCC arbeitet, um den Code klenier zu bekommen, wenn er denn unnötig groß ist. Und es ist natürlich abhäbngig vom Code und von der GCC-Version. Wenn man wirklich sowas machen muss, weil es von "oben"
-
Thread
Basic-Interpreter auf einem AVR
Print und mit -O3 und nicht mit -Os. Wenn es um speed gehen soll dann sicherlich mit allen optimierungen und nicht der size. lg roman
@Roman Also die Optimierung ist doch mal ne Erwähnung Wert :-)) Ich werd das mal übernehmen und in mein unverständliches Kauderwelsch an Präprozessor-Anweisungen mit integrieren :)) Was mir zum Thema Speed-Optimierung
-
Thread
AVR-ASM: .def Cassensitive?
avr-as (der zur gcc-Toolchain gehörige Assembler) ist case-sensitiv. Der unterscheidet also zwischen led und LED.
236kB nach Optimierungen Und nun bitte schließen, das eigentliche Problem ist gelöst, daher möchte ich nicht, dass hier ein Krieg über ASM und C ausbricht.
-
Thread
Wie sinnvoll ist ein union bei 32Bit Arm CPUs?
Allerdings sollte man anfangs mal kontrollieren, ob der betreffende Compiler die entsprechende Optimierung auch wirklich drin hat, insbesondere bei 32-Bit Datentypen. Würde ich nicht bei jedem Compiler blind drauf wetten.
defined WORDS_BIGENDIAN /* autoconf */ || defined __BIG_ENDIAN /* armcc */ /* don't know what the GCC predefine is. Couldn't find any */ typedef union { uint32_t w; struct { uint8_t b3; uint8_t b2; uint8_t b1; uint8_t b0; } b; } uint32_whb_t
-
Thread
Matlab Compiler
m-File s-Functions zu schreiben. Diese werden dann mit deinem eigenen Compiler (kann man auswählen z.B. gcc, vc++, ...) kompiliert und in mex-Files gepackt. (im Prinzip wie dlls) Um viellicht doch noch ein Mal auf den Matlab-Compiler zurückzukommen: Das ist eine extra Toolbox, die nicht ganz billig ist
MATLAB-Code kompilieren. Ich habe das in meiner Bachelorarbeit benutzt... Ist im Hinblick auf Optimierung aber nicht der Hit. MfG Marius
-
Thread
Allg. Frage zum Optimierer
Stellen kann man Schiffbruch erleiden. Beispielsweise weil die "__delay_xx" Schleifchen erst mit Optimierung ihre wahre Kunst entfalten.
einzuschalten oder eher nicht ? Es muss auch sichergestellt sein, daß das RAM ausreicht. Ohne Optimierung legt gcc lokale Variablen auf dem Stapel ab, was flott zu merklichem (dynamischem) RAM-Verbrauch führen kann. Weil der Verbrauch dynamisch ist -- also erst zur Laufzeit entsteht -- ist er nur schwer
-
Thread
Syntaktische Analyse mit Flex/Bison
Karl heinz Buchegger schrieb im Beitrag #1694036: > Wenn nicht, hol dir die gcc-Sourcen Der nicht. Früher hatte GCC mal Bison verwendet, aber seit GCC wirklich brauchbare Fehlermeldungen bei syntaktischen Fehlern auswirft tut er das nicht mehr.
Beitrag #1694044: > Karl heinz Buchegger schrieb im Beitrag #1694036: > >> Wenn nicht, hol dir die gcc-Sourcen > > Der nicht. Früher hatte GCC mal Bison verwendet, aber seit GCC wirklich > brauchbare Fehlermeldungen bei syntaktischen Fehlern auswirft tut er das > nicht mehr. Ah. ok. Danke Hab
-
Thread
Volle Adressierbarkeit (256k) im Programmspeicher bei Mega 2560 ?
immer mehr Laufzeit-Fehler (mit wachsender Programmgrösse). Nachdem ich mal porbeweise die Optimierung ganz ausgeschaltet habe, hängt der Mega 2560 sich nach den ersten Befehlen auf. Bevor ich nun in den Code einsteige, habe ich was prinzipielles nicht beachtet, was man bei der Programmierung
kann passen in einen 16-Bit Zeiger (auf Funktionen) nur 64KW (=128KB) und mehr als 16 Bits reserviert GCC keinem Zeiger, egel welchem.
-
Thread
C++ mit AVR-Dude
die Optimierung ist in beiden Fällen im Makefile auf s. Und natürlich will ich Optimierung. Oder muss ich die Optimierung noch irgendwo anders "anschalten"/auswählen ???
fuchs[3] = 77; if (fuchs[3] == 5) { fuchs[3] = 5; } return 0; } ^D $ avr-gcc -Os -xc -mmcu=atmega1281 -o foo.elf foo.c $ avr-size foo.elf text data bss dec hex filename 264 0 0 264 108 foo.elf $ avr-gcc -Os -xc++ -mmcu=atmega1281
-
Thread
AVR-gcc. Optimierung ignoriert Vergleich mit volatile Variable
zurück zum if-Vergleich. Bei der Optimierung -O0 ist alles OK, bei -O2 funktioniert es auch nicht. Die Deklaration des bt_rx_rdptr Zeigers als volatile bringt keine Änderung (ist auch nicht sinnvoll, da der USART-Rx-Interrupt sie auch
vorherige Zeichen aus dem Ringpuffer. Ich finde keinen Fehler im C-Code und vermute ein Bug im gcc. Kann ich als Workaround die Optimierung für diesen Bereich gezielt abschalten ? AVR-GCC-Version : 4.4.3 , avr-libc 1.6.8 Zielprozessor : ATMega128A Host: Ubuntu-Linux 8.04 Gruesse aus
-
Thread
MMC karte adressieren 32bit will nicht
ich hatte mal ein ähnliches problem, da war der compiler schuld. versuch mal ne andere optimierung (-O0 / -O2 / -Os). hatte schon code/avr-gcc versionen, da ging 32bit code mit -O2 nicht und sogar auch schon, dass es mit -O0 nicht ging aber mit -O2. vielleicht startet auch der watchdog nach
Schreibe in Deinen Code rein: [c] typedef unsigned long int uint32_t; [/c] Dann sollte Dir der gcc sagen, woher er die andere Definition hat (mit der es dann kollidiert).
-
Thread
Am Port klappern
reinzukommen mit assembler die ersten gehversuche zu machen. zu deinem problem, google man nach gcc inline-assembler.
lss-File an, was der Compiler aus der Zeile [c]PORTB &= ~(1 << DDB4);[/c] mit eingeschalteter Optimierung macht. Oliver
-
Thread
Taktfrequenz des Mikrocontrollers
das > LED auch eine Sekunde. Das heisst der Controller taktet mit 8Mhz? Yep. (Sofern du Optimierungen eingeschaltet hast) > Mich würde auch interessieren, wie der Zusammenhang von Delay und > Taktfrequenz ist. Wie wird das berechnet? _delay_ms ist so gebaut, dass genau bekannt ist, wie es
für eine Beschaltung die ich dir vorgeschlagen habe: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung Dieser Code hier sollte bei dir funktionieren: http://www.mikrocontroller.net/articles/Erweiterte_LCD-Ansteuerung Viel Spass! Hoffe ich konnte ein wenig weiterhelfen
-
Thread
C32 Compiler für PIC32
können. Nur kann man GCC natürlich auch ohne Microchips Hack verwenden, mit voller Optimierung und völlig legal. Wie das dann allerdings mit Integration in die Entwicklungsumgebung, Debugging und der rechtlichen Seite der Library
Interessant... Hat da jemand Erfahrung ob der GCC mit MPLAB und ICD2/3 problemlos läuft und wie das mit der rechtlichen Seite der Library aussieht? Der GCC Compiler ist kostenlos, oder? Gruß chris
-
Thread
Ausdruck optimieren auf Laufzeit
Andreas Ferber schrieb im Beitrag #1670589: > Compiler die Optimierung selbst nicht durchführen. Bei welchen Werten treten denn verschiedene Ergebnisse auf? Immerhin führt GCC genau diese Optimierung durch, in beiden Vorzeichenvarianten (x86 und avr). Weder Shift
C bleibt es aber undefined). Trotzdem bleibt (warum auch immer): >> Immerhin >> führt GCC genau diese Optimierung durch, in beiden Vorzeichenvarianten >> (x86 und avr). > Prinzipiell schon, aber er erweitert dazu den Wert auf 16 Bit (x ist > jeweils int8_t, kompiliert mit avr-gcc -O6
-
Thread
Auswahl des richtigen µc
external interrupt - Spannungsversorgung 5-12 Volt - Ideal wäre als passende Programmiersprache avr-gcc optional: Ethernet Interrupt management Ist jmd. ein passender Controller eingefallen ? Habe Liste um Liste durchforstet und leider nixs gefunden. mfg Jan
Zeitkritisch) lasse ich den STM32 mit nur 8MHz laufen und der macht 5000 Main-Zyklen/Sek. (Bei Kompiller Optimierung 7500). In jedem Fall solltest Du solch eine Sekunden-Ausgabe der Zyklen drin haben, dann siehst Du sofort wenn irgendwo eine "Warteschleife" eingebaut wurde die das System ausbremst.
-
Thread
ATmega8: sprintf & float liefert nur "?"
avr-gcc -mmcu=atmega8 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=10000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT LIB_TWI_Master.o -MF dep/LIB_TWI_Master.o.d -c ../LIB_TWI_Master.c avr-gcc -mmcu=atmega8 -Wl,-u,vfprintf -Wl,-Map=sprintf_float_test.map sprintf_float_test.o LIB_PCF2119x.o LIB_TWI_Master.o -lc -lprintf_flt -lm -o sprintf_float_test.elf avr-objcopy -O ihex -R .eeprom
-
Thread
Einregister- vs. Mehrregistermaschine
Stackmaschinen meistens voneinander abhängig, so dass eine einfache superskalare Ausführung mit Optimierung der Befehlsanordnung durch den Compiler, wie in den ersten entsprechenden Generationen von RISC-Maschinen und PC-Prozessoren (P5x), nicht in Frage kommt. Man muss also gleich zu einer sehr tief
konzipiert ist. Damit müssen beispielsweise Leute kämpfen, die GCC (oder PCC) x87-Code beibringen wollen. Ich zog es vor, den Codegenerator komplett wegzuwerfen und neu zu schreiben.
-
Thread
C Programm funktioniert nicht
dann denselben Effekt wie exit(0) haben muss. Ansonsten ist des Pudels Kern sicher die Optimierung; ein optimiertes C-Programm zu debuggen, ist meistens zwecklos. Wenn alle Stricke reißen, schau mal ins Assembly (beim gcc zu erzeugen mit 'gcc -S').
fprintf( "%s Test ist jetzt, \t ", test); }; for(;;); }; [/c] Schlägt die Optimierung mit absoluter Sicherheit zu, da der Text im Körper der if-Anweisung niemals erreicht werden kann. Mit meinem AVR-GCC ergibt das folgendes Assembly: [avrasm] main: /* prologue: frame size=0
-
Thread
AVR: PORTB |= 0b00001111; atomar?
Assembler-Befehl, und damit > atomar durchführen kann. In diesem speziellen Fall vielleicht, /wenn/ die Optimierung beim Compiler richtig gesetzt ist. Und z.B. beim Zugriff auf PORTF beim ATmega128 fliegst du dann plötzlich auf die Schnauze, weil SBI damit nicht geht, dein Compiler dir das aber nicht sagt (warum
Es ist aber nicht verboten, C entsprechend zu erweitern (siehe z.B. die MMX-Intrinsics beim x86-GCC), nur hat für AVR das eben niemand konsequent getan, und deshalb muss man mit Unzulänglichkeiten wie der Nicht-Atomizität (bzw. der Nicht-Garantie der Atomizität) bei Bitoperationen auf PORTx leben.
-
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
Volatile in ISR und main() geht nicht
bei array's notwendig? DOCH!!! Auch wenn es OFT ohne geht, ist es NICHT sicher! Hab ich auf dem GCC schon erlebt, dass erst das volatile das korrekte Ergebnis liefert (UART TX Interrupt). MfG Falk
bedeutet ja schliesslich: keinerlei Annahmen über den Inhalt einer Speicherzelle machen und lokale Optimierungen auf dieser Speicherzelle aussen vor lassen. Natürlich ist es unwahrscheinlich, dass der Compiler es schafft ein komplettes Array in CPU-Registern zu halten und damit eine Optimierung aufzubauen
-
Thread
Variablenfreigabe for-Schleife
deklararierten Variablen hinter der for-Anweisung fortgesetzt worden ist. Entsprechend gab es auch mal eine GCC-Version, die das so implementiert hat, aber meiner Erinnerung nach war das damals wirklich nur in C++ implementiert, der C-Compiler vom GCC hatte das nie als Erweiterung -- außerdem ist das alles
nein, ist ja nicht so das ich mir das ausgedacht habe. Es gibt auch noch > mehr Compiler als den GCC. Nun ja, hier ganz oben drüber steht: >Forum: GCC Aber gut, ich verbessere mich: Das Verhalten ist in C immer eindeutig definiert. Das gilt natürlich nicht für Compiler, die eine C-ähnliche
-
Thread
FLASH -> Waitstates?
vermutlich auch für die 96MHz oder 120MHz, nur das hier > zusätzliche oder andere Methoden der Optimierung benutzt werden. Sind > wir uns soweit einig ? Wenn du mit Optimierung erweiterte Hardware-Mechanismen wie einen Branch Cache meinst, ja.
> Ich habe überhaupt noch nie gesehen, dass diese Konstruktion vom > Compiler erzeugt wurde. GCC erzeugt mit -Os die PC-relative Variante, ansonsten bei eingeschalteter Optimierung oft MOV32. > beizeiten ändern wird. Bei Sprungadressen muss der Linker die > Platzhalter letztlich mit echten
-
Thread
C programmieren wie die grossen Jungs
falsch man "programmieren" kann und es doch noch irgendwie funktioniert... Aber solbald man die Optimierung im Compiler einschaltet und der Compiler "XYZ ist nicht definiert" aus dem Standard ernst nimmt, kracht es.
gcc entschliesst sich bei [C] int main() { for( unsigned char i = 0; i < 10; ++i ) Ziffer[i] = '\0'; foo( Ziffer ); } [/C] das i zu eliminieren und das ganze mittels Z-Pointer und
-
Thread
Speicher voll durch Multiplikation
für AVR? (Linker Option: -lm), die ist für AVR optimirt und wesentlich schlanker als die generische GCC Math-Lib (welche unsinnigerweise meistens defaultmässig dazugelinkt wird)
fällt mir noch was ein. Nachdem der TO die Projekt Einstellungen anscheinend nicht kennt: Die Optimierung ist aber eingeschaltet?
-
Artikel
ASM vs C
workarounds belegt werden müssen, oder mit neuen Generationen von Derivaten neue Möglichkeiten der Optimierung gegeben sind. Von solchen Optimierungen, die in neuere Compilerversionen einfliessen, kann man auf diese Weise quasi kostenlos profitieren. Ein Beispiel dafür: POVRay (mehrere Megabyte C++ Sourcecode) compiliert für P4 mit GCC 3.4.0 bringt gegenüber GCC 3.3.1 eine Leistungssteigerung von knapp 7%. Um diese 7% per Assembler-Optimierung zu erreichen würden wohl einige Tage Arbeitsaufwand nötig, sofern es überhaupt gelingt.
-
Thread
Prozessor 100% voll, Problem?
Peter Stegemann schrieb: > Die Optimierung ist schlechter, als man denkt - Nö, nur die default Einstellungen sind schlecht. Man sollte beim AVR-GCC folgende Schalter noch hinzufügen: [c] -Os -lm -fno-inline-small-functions -Wl,
Objektcodes produzieren liegt in der Natur der Sache. Und auch, dass eine neuere Version insbesondere vom GCC auch mal etwas mehr Code produziert, weil 99% der Renovierungen bei den GCC-Versionen nicht spezifisch für den AVR durchgeführt und getestet werden. Viele Optimierungen sind nur für Highend-Architekturen
-
Thread
gcc Optimierung nicht ganz nachvollziehbar
generieren in denen ich verschiedene Funktionen aufrufen kann. Soweit so gut. Stelle ich die Optimierung des gcc ab (-o0), dann funktioniert der Code auch wie gewünscht. Aktiviere ich die Optimierung läuft der Code bei o2, o3 und os nicht mehr wie gewünscht, was für mich nicht ganz verständlich ist
sollte mal ins Forensystem was einbauen, so dass man schon beim Tippen der Begriffe "Compiler" und "Optimierung" automatisch bei einer passenden Erklärung von "volatile" landet. ;-)
-
Thread
At Mega 16 Problem mit dem Toggeln von Ports
Ein paar *volatile* Kennzeichnungen fehlen z.B. bei SCHRITT mehr siehe AVR-GCC-Tutorial Interrupts > include <util/delay.h> > #define F_CPU 16000000UL //Frequenz > #include <avr/io.h> //Deklaration Out of Order includes. delay muss F_CPU bereits kennen.
zu ändern. Das Programm dürfte in dieser Form mit einer eingermassen aktuellen Version von avr-gcc auf einem Mega128und auf einem Mega16 nur ohne Optimierung laufen. Wie schon gesagt wurde, fehlen da einige volatiles. Die älteren gcc-Versionen ( < 2003 ???) waren da toleranter, und signal.h lässt
-
Thread
gezielte Optimierung einzelner Funktionen mit gcc?
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas
848: b9 cf rjmp .-142 ; 0x7bc <__vector_11+0xb2> } [/avrasm] das mit avr-gcc 4.3.3 Keine Ahnung warum der gcc bei -O3 einen Code dermaßen zerrupft - super unschön. Zumal mit schlechter lesbarer Nachhilfe die Optimierung viel besser ist: -O3 / Os [avrasm] act_pos_buf
-
Thread
USB IR Remote Receiver (V-USB + IRMP)
werden (Key Suppression). Default ist keine. Siehe USB_IR_Remote_Receiver_DLL_help.htm AVR: Optimierung der IR Code Erkennung für die PowerOn Funktion, Bugfix wenn eine Taste länger als 255 Wiederholungen gedrückt war mfg Portisch
einfach so 1:1 in Hugos Originalsourcen kopiert werden und lassen sich dort mit einem "make" von avr-gcc übersetzen, ein kleines aus V-USB übernommenes Makefile ist vorhanden. AVR Studio benutze ich nicht, für meine Zwecke war das bislang nie nötig, ich verwende hier einen Debian-PC mit avr-gcc V4.3.5