-
Thread
Error 2 R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in.
avr\lib\avr51\libc.a(cmpsf2.o)||In function `__lesf2':| c:\winavr-20100110\bin\..\lib\gcc\avr\4.3.3\avr51\libgcc.a(_lt_sf.o):c:\avrdev\gcc\build-avr\avr\avr51\libgcc\..\..\..\.\gcc\fp-bit.c|1287|first defined here| ||=== Build finished: 1 errors, 1 warnings ===| [/code] Mfg Philipp
/avr/bin/../lib/gcc/avr/4.4.4/avr5/libgcc.a(_mul_sf.o) [..]/x-chains/avr/bin/../lib/gcc/avr/4.4.4/../../../../avr/lib/avr5/libc.a(fp_powsodd.o):../../../libm/fplib/fp_powsodd.S:69: relocation truncated to fit: R_AVR_13
-
Thread
Fehler im gcc, im Chip oder im Hirn?
Interrupts? 'volatile' vergessen? Warum struct, wenn Du eh nur einen Member hast? Ansonsten, welche gcc Version? Ist das im Simulator oder auf realer HW? Welcher µC?
/avr-gcc/ Hier ist der zugehörige Thread: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631
-
Thread
AVR-spezifische Optimierung wirkt nicht in Member-Funktion
, Bit nicht. Tja, da kann ich dich nur dafür beglückwünschen, dass es dir gelungen ist, die Optimierung vom GCC auszuhebeln. Nobody is perfect, auch der nicht.
/gcc.gnu.org/bugs/#need
-
Thread
avr-libc: relocation truncated to fit
8k Eine weitere Möglichkeit zur Umgehung bestimmter libgcc-Funktionen wäre die Funktionen in den gcc-optabs umzubenennen; das geht schmerzfrei im AVR-Teil. Dann wäre immer noch eine __addsf3 in libgcc, aber avr-gcc würde Aufrufe zu zB __avrlibc___addsf3 ausgeben, falls zB nicht -mno-avr-libc gesetzt
> Eine weitere Möglichkeit zur Umgehung bestimmter libgcc-Funktionen wäre > die Funktionen in den gcc-optabs umzubenennen; das geht schmerzfrei im > AVR-Teil. Ehrlich gesagt: lieber wäre es mir, wenn wir die Autoren der avr-libc- Funktionen davon überzeugen könnten, das wirklich dem GCC-Projekt
-
Thread
'volatile' und Cache
>> - Muss der Compiler einen Lesezugriff auch dann ausführen lassen, wenn >> er ihn bei der Optimierung als sinnlos erachtet? (Z.B., weil die >> Variable nur gelesen wird, aber nichts weiter geschieht.) > > Ja. Bei > volatile char a; > a; > muss ein Lesezugriff erfolgen. Jein. Bei GCC ist das der Fall: Implementation defined, C90 6.5.3, C99 6.7.3 http://gcc.gnu.org/onlinedocs/gcc/Qualifiers-implementation.html#Qualifiers-implementation Was den Cache angeht, gibt's in GCC Builtins wie __builtin___clear_cache. Die Implementierung dürfte allerdings stark
-
Thread
eigene "printf-Funktion" mit variabler Argumenten Liste
Da wirst du wohl den Hersteller /deines/ Compilers fragen müssen (der ja ganz offensichtlich kein GCC ist).
in dem Header stdarg.h abgearbeitet. Kann es sein das ein Complier nur in der von dir genannten Optimierung darüber fällt und sich etwas ungeschickt ausdrückt.
-
Thread
Flugsteuerung Lage/Motoransteuerung/Servos
anfangen. Wenn ihr C schon könnt gehts für AVR hier los: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial Ansonsten zuerst C lernen: http://openbook.galileocomputing.de/c_von_a_bis_z/ Viel Erfolg
setze ich aktuell alles auf STM32F1xx oder STM32F2xx auf. Auch hier sind PWM Stufen mit Extras und Optimierung auf Power-/Motor-Control drin. Ein 72MHz STM32F10x sollte für Euch erst einmal passen. Auf einigen bezahlbaren Entwickler-Kits ist oft auch schon mal eine Motorstufe mit drauf, aber meist nur
-
Thread
mega8 Flash Verwirrung
beim überfliegen des Codes kann ich keine entsprechenden entdecken. Auf was steht die Code optimierung?
hohe Speicherdarf nicht nachvollziehbar In den lcd-routinen wird _delay_ms() benutzt, ohne Optimierung zieht das die float-libs mit rein. Oliver
-
Thread
Bilineare Interpolation mit Festkomma
Mit avr-gcc (WinAVR 20100110) 4.3.3 und Optimierung -Os wird bei mir sowohl das Schieben um Acht Bits als auch die Multiplkation mit 256 zu Highbyte kopieren und Lowbyte löschen umgesetzt... (und bei der Division
Egal was für eine Optimierung. Der GCC scheint garnicht so blöd... [c] thomas@quark:~/workspace/injektor test/Release$ diff div.lss shift.lss thomas@quark:~/workspace/injektor test/Release$ gcc -v Using built-in specs
-
Thread
Einfach-Messdatenerfassung
sind einige Optimierungen abgeschaltet. fchk
anderen Herstellen (z.B. Microchip) gibt es keine > Größenbeschränkungen, dafür sind einige Optimierungen abgeschaltet. jeder machts etwas anders.
-
Thread
ATMega32 + LCD + Timer0
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Datenaustausch_mit_Interrupt-Routinen
Bin einen Schritt weiter: Habe die Optimierung von -fexpensive... auf -O3 zurückgestellt. Jetzt habe ich am LCD keinen Schotter mehr, sondern eine schnelles Flackern von "Hello World". Zusätzlich ist mir dieser Artikel aufgefallen: http
-
Thread
Inline Assembler Code Probleme
Die Inhalte der Arrays sind nur Beispielhaft. 16bit sind schon nötig, und ich nutze AVR Studio4 mit GCC und programmiere einen ATMega8 mit 10MHz. Die Optimierung ist auf -0s eingestellt. Das ganze steckt in einer main. Die Arrays werden in der main auf der Ebene der Deklaration der PortIO über Funktionen
-
Thread
Optimierung des neuen AVR Studios schlechter
eigentlich 2) Assembler und die übersetzen genau das, was im Source steht. Womit compilierst Du also? GCC (WinAVR)? Gleiche Version wie damals? WinAVR ist nicht Bestandteil des AVR-Studio. Gruß aus Berlin Michael
Hast du überhaupt unter Projekt die Optimierung angeschaltet? Das hat bei mir dann auch erstmal für Erstaunen gesorgt... Mit freundlichen Grüßen, Valentin Buck
-
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
DIY Board mit BF532
einfach zu hoch, wenn man den Chip voll ausnutzen und komplett selber programmieren will. Mit der GCC/Eclipse-Umgebung und dem ICEbear-Debugger lief das auf dem Blackfin exzellent, allerdings hatten wir mit dem ersten Debugger von Analog (Gnice) keinen Spass (miese Software, kein Support). Wenn man sich in die Blackfin-Assemblersprache reinkniet, kriegt man erstaunliche Optimierungen hin, aber zugegebenermassen ist das Teil nichts für Anfänger. Nur meine 50 Cent :-)
-
Thread
Komisches Verhalten im Programm
Wenn ich die Optimierung auf -O0 stelle erscheint bei mir immer eine Ordnersuche wo steht Please browse to the present location for files originally found at c:/avrdev/gcc/gcc-4.3.3/gcc/config Was bedeutet das?
-
Thread
Interpretation AVR-GCC *.lss File
sind bei eingeschaltetem Optimierer mehr oder weniger sinnlos im Assemblercode verteilt. Ohne Optimierung passt das, mit nicht. für den Rest: s.o. Oliver
es die meisten Infos enthält. [1] http://rn-wissen.de/index.php/Assembler-Dump_erstellen_mit_avr-gcc
-
Thread
Assembler in C-Code integrieren
integrieren: > asm volatile ("sbi PORTB, 3"); Schau mal ins Listing, der Compiler macht genau das (Optimierung -Os). Assembler ist hier völlig unnötig. Peter
zu integrieren: > asm volatile ("sbi PORTB, 3"); Macht das der Compiler nicht automatisch? Der gcc optimiert einzelne Bits setzen / löschen zu sbi / cbi. Du kannst nicht einfach PORTB usw hinschreiben, das ist etwas komplizierter. Hier das Inline-ASM Manual http://www.nongnu.org/avr-libc/user-manual
-
Thread
unerklärliche Code-Optimierung
Platine: }; [/c] Der Compiler haut mir die 'while-Schleife' komplett raus (auch ohne Optimierung!). Unverschämtheit ;-) Wie bekommt man das weg?
Mit welchem Compiler arbeitest du? Falls mit dem GCC: Wenn du die Option -Wall aktivierst, erhältst du für die Zeile mit dem while eine Warnung, die dich auf deinen Fehler hinweist: warning: comparison is always false due to limited range of
-
Thread
Problem durch Optimierung -Os
handelt und den Speicher reserviert. Dummer Gedanke, der dann durch den Erfolg beim Verzicht auf Optimierung auch noch gefördert wurde. Bezüglich Warnungen war dar Hinweis darauf, dass ohne Optimierung die Funktionen aus dem Header 'delay.h' nicht funktionieren würden das einzige. Beim Compilen mit -Os
interessieren, hätte > der Compiler ein 'Warning' ausgeben müssen? Kompilierst du mit -Wall -Wextra (falls gcc, sonst halt entsprechende Optionen bei deinem Compiler)?
-
Thread
Compiler für µP.
Die Compiler sind immer spezifisch für den Prozessor-Typ aufgebaut, der freie GCC hat halt dann die passenden "submodule" wie ich es mal nennen möchte ist aber nicht Code begrenzt. Die µC-Hersteller bieten auf ihren Internetseiten entweder eigene Produkte an, oder "kastrierte
lernen, da gibt es fuer eigentlich jeden uP einen Compiler > fuer. Dann kommst du in den Genuss des GCC, den es für n>>1 Architekturen gibt. PIC und 80C51 ausgeschlossen, dafür gibt's den SDCC. http://gcc.gnu.org/install/specific.html
-
Thread
ATmega läuft nicht los obwohl Quarz schwingt
Sinus Schwingung bei 8MHz Quarz sehen) - Programm herunterbrochen auf ein reines Pin Toggeln. - Optimierung ausgeschalten. Trotzdem läuft das Programm nicht los. Jedoch lässt sich der Controller programmieren und auch die Fuses setzen/auslesen. Daraufhin habe ich die internen Oszillatoren ausprobiert
Aber 2000000 ist für einen int schon zu groß, wird also in einem arithmetischen Ausdruck beim AVR-gcc auf jeden Fall also mindestens ein long sein.
-
Thread
Welche Arm-Entwicklungsumgebung? - kommerzielle Nutzung
allerdings niemand -- auch nicht Robert. > evtl. könnte es sein das IAR oder Keil etwas besser als GCC > optimiert, aber selbst dabei wäre ich mir nicht sicher, könnte man mal > untersuchen. Getan. Das Ergebnis ist zwar schon älter, aber immerhin haben sich /beide/ toolchains (Keil bzw RVCT, GCC
eine echte Alternative und dann gibt's noch ein paar mehr. Ausser Keil und IAR bauen fast alle auf GCC auf und haben somit in der Compiler Optimierung keine echten Unterschiede. Jetzt kommts noch darauf an wie gut der Debugger ist, wie gut hardware U-Link / J-Link mit den Compilern arbeiten. Die IDE
-
Thread
Atmega 16MHz delay-Funktion
älteren waren im Argument etwas beschränkt: Siehe: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29
Hm, warum das jetzt zu langsam läuft weiß ich auch nicht. - F_CPU scheint zu stimmen - Optimierung ist an - Die Fuses sind ok Gem. Julian ist es einen Versuch wert, nicht 1000 ms zu warten sondern lieber in einer Schleife tausendmal 1 ms. Sonst fällt mir nicht nehr viel dazu ein.
-
Thread
Schiebeoperatoren
unsigned int pos) { x = (x >> pos) | (x << (32 - pos)); return x; } [/c] Resultierender Code (gcc mit Optimierung -O2): [pre] rotate.o: file format elf32-littlearm Disassembly of section .text: 00000000 <rotate_right>: 0: e1a00170 ror r0, r0, r1 4: e12fff1e bx lr
-
Thread
avr-gcc: den Zugriff auf register variablen optimieren?
Nachtrag: http://www.mikrocontroller.net/topic/wie-optimiert-man-systematisch-avr-gcc Oliver
avr-gcc-3.4.x: [pre]warning: volatile register variables don't work as you might wish[/pre] avr-gcc-4.5.x: [pre]warning: optimization may eliminate reads and/or writes to register variables warning: call-clobbered
-
Thread
C18 oder HiTech
könnte, in der kostenlosen Version nicht zur Verfügung steht, würde ich den C18 wählen. Höhere Optimierungen wie sie der GCC durchführt beherrschen beide Compiler nicht. Vor allem werden Zwischenergebnisse nicht wiederverwendet: [c] x = i/2; y = i/2; z = i/2; [/c] Oder [c] col1 >>= 8 - bits;
Michael G. schrieb im Beitrag #2163791: > Höhere Optimierungen wie sie der GCC durchführt beherrschen beide > Compiler nicht. Vor allem werden Zwischenergebnisse nicht > wiederverwendet:x = i/2; > y = i/2; > z = i/2; > Odercol1 >>= 8 - bits; > col2 >
-
Thread
MPLAB IDE Lizenz Warnung
Machenschaften. Wie Lehrmann Michael auch schon aufführte werden bei der LITE-Version bestimmte OPtimierungen eingeschränkt. Falls jemand noch was Produktives weiß bitte posten, ansonsten wende ich mich mit meinem Problem mal an ein nicht so AVR-lastiges Forum. Gruß Michl
eine Möglichkeit, wie man an einen vollwertigen C30-Compiler kommen kann. Da der C30 Compiler ein GCC Compiler ist, gibts den Quellcode auf der Microchip-Seite frei zum Runterladen. Im Netzt gibts genug anleitungen, wie man den Quellcode compiliert (der muss vorher gepatcht werden). Microchip verlangt
-
Thread
Code Optimierung (Geschwindigkeit) AVR, C
: Bei den Optimierung 0,1 und s ist das Programm zu langsam. Bei der Optimierung 2 werden irgendwelche Abfragen wegoptimert (wahrscheinlich busy waits) die dazu führen, dass der µC nicht mehr schlafen geht. Als Kandidat
sollte ein Programm mit allen Optimierungsstufen (O0,O1,O2 und Os) laufen. Die Delay Routinen von GCC gehen ohne Optimierung nicht - das ist aber eine Ausnahmen. Wenn es mit Optimierung nicht geht, ist das oft so etwa wie ein Fehlendes volatile oder ein Wartescchleife die abhanden kommt. Bei einem
-
Thread
Geeigneter Cortex M3 für Projekt gesucht
es da denn mit der Unterstützung ähnlich wie bei der STM32 Beischreiibung aus? Sprich wenn ich mit GCC und Eclipse arbeiten möchte? Gruß Carsten
Die IDE zum LPCxpresso basiert auf Eclipse und verwendet auch den gcc Compiler (in angepasster Form? Zumindest die Standard Libraries sind angepasst, nennt sich dort redlib). Ob man ein eigenes Eclipse mit GCC so einfach verwenden kann weis ich nicht. Den das Problem
-
Thread
Atmel oder PIC
Debugger etc... ohne irgendwelche Demo/Eval Einschränkungen. Du kannst aber auch mit Eclipse + AvrGcc (C-Compiler) arbeiten, es gibt ein AVR-Plugin für Eclipse..
etc... ohne > irgendwelche Demo/Eval Einschränkungen. > > Du kannst aber auch mit Eclipse + AvrGcc (C-Compiler) arbeiten, es gibt > ein AVR-Plugin für Eclipse.. MPLAB, die Einschränkungen des Compilers (gcc...) im Eval-Modus (nicht alle Optimierungen) sind in vielen Fälle vernachlässigbar. MPLAB
-
Thread
RC Empfänger auswerten, Signal modifizieren und wieder ausgeben
ich habe mich verrannt und hoffe jemand hat eine Creative Idee. Das ganze soll und ist mit AVR und GCC gelösst werden. Die bisherige Bastellösung sieht so aus (Sampelt nur einen Servo vom Empfänger): [c] #include <avr/io.h> #include <avr/interrupt.h> #include "usart.h" #define MAX_CHANNELS
Ausgänge zu setzen, etc. Dann alle Daten in den Feldern löschen, und wieder von vorn. Mit etwas Optimierung solllte die Schleife mit 62 Zyklen machbar sein. Wenn dir die Verzögerung von einem Frame bei den Kanälen, die du nur durchreichen willst, zu viel ist, kannst du die auch direkt in der Schleife
-
Thread
EEPROM Schreibfrequenz auf eine Adresse
Montag das asm File dann wirst es ja sehen. Übrigens verwende ich den Codevision Compiler und nicht den GCC
Micha schrieb im Beitrag #2146235: > Dein Hex funktioniert. Unterschied könnte noch die Optimierung sein. Was hast Du? -O, -Os, -O2? Welchen Optimierungsgrad hat Peter benutzt?
-
Thread
LDO Regler ADP3339 überbrücken(?)
immer eine Warnung geworfen wird: irgendwas mit 'delay.h' funktioniert nicht richtig, wenn keine Optimierung eingeschaltet ist. Ich habe dann mal die Optimierung auf 'Grösse' eingeschaltet, und das Ding laufen lassen. Die Warnung war zwar weg, aber dafür spielte das Display verrückt! Die Optimierungsstufen 'Geschwindigkeit' und 'Mittel' brachen das gleiche Ergebnis. Erst ohne Optimierung zeigte die Kiste wieder was an, weil dann das Displaytiming wieder stimmte! Die haben da so lange dran rumgebastelt, bis das auch ohne Optimierung funktionierte! Naja. Also. Das Display.
-
Thread
Optimierung Fehlerhaft?
hatte. Ich muss jetzt noch mal korrigieren, der Code Funktioniert beim Debuggen, mit und ohne Optimierung, nur wenn ich alles auf den uC spiele, wird die letzte Abfrage nicht ausgeführt. Ich habe jetzt mal alles Angehängt. VG Stefan
der Simulation Daten vor. Auf dem µC ist das anders. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#ADC_.28Analog_Digital_Converter.29 "In der praktischen Anwendung wird man zum Programmstart den ADC erst einmal grundlegend konfigurieren und dann auf verschiedenen Kanälen messen. Diese
-
Thread
Code braucht extrem viel Speicher
In http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 steht "Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt und die Wartezeiten stimmen nicht mehr mit dem Parameter überein." Aber am Ende ists sowieso wurscht: in der Realität wird wohl keiner
-
Thread
Frage zu Programm Optimierung (Größe)
von mir: http://pastebin.com/BaS1BAEE Und die LCD Lib von hier. Im Makefile habe ich auch die Optimierung auf Größe gestellt, aber erhalte wie erwähnt, die 7,3 Kb.... Daher auch meine Frage ob jemand weiß, wie ich das Programm noch optimieren kann. Weil laufen tut es, aber ich finde es doch sehr komisch
Float braucht etwa 1kB. Beim AVR-GCC: double = float Sprintf ist recht teuer und mit float nochmal deutlich teurer. Peter
-
Thread
short != int16_t
Bit, also -128 .. +127 > einstellen. Ich glaube sogar, das war die Default Einstellung. Bei avr-gcc kann man das auch so einstellen, vor allem, weil der Compiler hier ein paar Defizite bei der Optimierung hat. Es wird aber trotzdem selten verwendet, da es mehr Probleme verursacht als es löst. Es ist
-
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
WINAVR Portpins setzen
Peter schrieb im Beitrag #2126567: > Mir wäre es auch lieber der GCC würde das auch ohne Optimierung machen. Ohne Optimierung ist nur für Programme möglich, wo die Ausführungszeit völlig egal ist. Auch andere Compiler werden da nicht besser sein. In der Regel ist
. Leider ist das oft keine Optimierung und bewirkt sogar > etwas mehr Code. Das Umsortieren führt aber nicht dazu, daß der Code mit Optimierung nicht mehr läuft. Es mag ein paar ganz bestimmte Spezialfälle geben, bei denen der gcc
-
Thread
rfm12lib lässt sich nicht coimpilieren
Hallo , ich versuche in Codeblock 10.5 mit dem avr-gcc 4.3.2 die RFM12lib (http://www.das-labor.org/wiki/RFM12_library) zu compilieren und bekomme bei folgender Zeile : [c] //non-inlined version of rfm12_data //warning: without the attribute, gcc will
Aber wie gesagt, ich denke der Compiler kennt die C99 uintxx_t Typen nicht...also gcc mit '-std=c99' aufrufen oder <stdint.h> einbinden...
-
Thread
Evaluation neuer Mikrocontroller: ARM? Gesperrt
ausgeführt werden. Auch der TCPIP-Stack verbraucht viel Speicher. Klar könnte man da gewisse Optimierungen vornehmen, das würde aber alles auf Kosten von Performance gehen - und das dürfen wir uns auch nicht erlauben.
keine Wünsche übrig läßt. Nach 60 Tagen ist die Codegröße auf 256kB begrenzt, oder man nimmt gleich GCC http://www.kpitgnutools.com/index.php und befindet sich dann im erlesenen Kreis der GCC-Nutzer.
-
Thread
Optimierung im code ein- und ausschalten
Ein gangbarer Mittelweg ist u.U. -O1. Auf Funktionsebene lässt sich Optimierung mittels Pragma/Function-Attribut umstellen -- entsprechende GCC-Version vorausgesetzt. http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas
Danke für die Tips! Ich habe die Funktion mit #pragma GCC optimize("-Os") übersetzt, jetzt geht es. Was ich mich nur frage, warum GCC ohne Optimierung einen so extrem umständlichen Code produziert?? Registerverschwendung und Codegröße maximal!
-
Thread
ARM Cortex & GCC: Worauf achten für "optimalen" Code?
:) Wo ich nun eher Anlaufschwierigkeiten habe ist der GCC, beispielsweise wie die Variablen bzgl. Speichermanagement gehandhabt werden, wie Parameterübergabe stattfindet, etc. Ich komm leider momentan mit der in der LPCxpresso-IDE mitgelieferten GCC-Hilfe
A. K. schrieb im Beitrag #2111097: >> ist. Wie ist das beim GCC & ARM? Wenn ich vier 8-Bit-Variablen (char) >> anlege, packt der GCC das automatisch in ein 32-Bit-Wort, oder verwendet >> er vier Mal ein 32-Bit-Wort? > > Register: jede einzeln in ein Register
-
Thread
avr-gcc: -fsplit-wide-types ja oder nein?
Neuere Versionen von avr-gcc kennen den Schalter [pre]-fsplit-wide-types[/pre] der bei angeschalteter Optimierung automatisch aktiviert wird. Durch [pre]-fno-split-wide-types[/pre] kann der entsprechende Optimierungs-Pass in gcc deaktiviert werden. Mit interessiert nun, welche Ergebnisse bei euch mit bzw. ohne diese Optimierung erzielt werden, und welche Verbesserungen mit/ohne diese Optimierung in "echten" Projekten beobachtet
-
Thread
Optimierungs-Bug mit Registern?
Semantic eines "volatilen Registers" per se irgendwie widersprüchlich. Weil das so ist, wirft der gcc dazu auch eine warning: >warning: optimization may eliminate reads and/or writes to register variables Die gcc-Doku sagt dazu folgendes: >The volatile modifier does not inhibit all optimizations
output parameter. Die GCC Hilfe (oder Google) sollten mit den Details helfen. Kann nicht garantieren dass es funktioniert, ist halt so eine Idee. Frage: Wie verhinderst Du eigentlich, dass der GCC das R2 register von sich
-
Thread
AVR-GCC generiert unnötigen(?) ISR overhead
schnelle SPI interrupt routine zu schreiben und hab mir zu dem Zweck mal das listing (lss) vom avr-gcc angeguckt. Ich verwende einen ATmega168P. Optimierung -Os Hier der C-Code: [c] uint8_t rxd; uint8_t txd; ISR(SPI_STC_vect) { rxd = SPDR; SPDR = txd; } [/c] und hier das Resultat
andere wollen die Welt und den ganzen Rest auf Hex umstellen, und meine Nerd-Spielwiese ist eben avr-gcc. Von Assembler bis C++ ist da alles dabei /und/ adäquat, man kann sich in Testing oder Profiling vertiefen. Wenn ich was im Simulator praktisch finde, bastel ich daran weiter, und neue (Optimierungs
-
Artikel
UsbDisplay
Die 8/08 Version hat noch keine Massefläche und ist noch völlig ungeprüft! Außerdem wäre eine Optimierung für eine bestimmte gängige Gehäusegröße und einige Bohrungen zur Befestigung sinnvoll. Aufbau der Hardware. Die aufgeführten Bauteile kosten etwa 70 EUR bei Reichelt. Aus einer DSS (Doppelseitigen
mir diese Simple behandlung. Die Magie geschieht über das Attribut __attribute__((interrupt)) Laut GCC Manual ist dies genau für Interrupt Handler gedacht. Der Compiler speichert nur die Register auf dem Stack, die tatsächlich benötigt werden. Dies ist performanter als per se alle Register zu speichern
-
Thread
PIC mir C Programmieren
im Vergleich ist. Aber das der nur 60Tage läuft stimmt nicht ganz. NAch 60Tagen wird nur die Optimierung zurückgefahren was bedeutet das der Zielcode etwas größer wird. Der Compiler bleibt aber funktionsfähig. Diese geringere Optimierung spielt für den Hobbyisten keine Rolle. Es ist nicht gravieren
#2091289: >>Der läuft ja nur 60 Tage... > > Der läuft länger. Nach 60 Tagen gehen ein paar Optimierungen > nicht mehr. Dadurch wird der Code größer. Nach meinen Erfahrungen > aber auch schneller;) Es handelt sich auch nicht um alle Optimierungen sondern nur um höhere Optimierungsstufen. Programmiert
-
Thread
micrium ucos 2 unter eclipse auf einem cortex-M3 STM32F107VC
Hallo, hab seit heute das RTOS von micrium am laufen. Ich verwende eclipse als IDE, yagarto gcc arm und einen olimex jtag adapter (arm-usb-osd) zusammen mit OpenOCD und dem Gnuarm und Zylin plugin für eclipse. Nach einigem frickeln läuft das micrium demo super auf dem Board von ebay Bild vom
Flash hat wollte ich es auch nutzen. Also bin ich auf eclipse um den gcc verwenden zu können. Der gcc scheint etwas grösseren code zu bauen als der Keil aber dafür gibts keine Beschränkungen. Gruss Michael