-
Thread
RISC-V mit GateMate FPGA
APB-Bridge, UART, I2C, SPI usw. mit 50Mhz, ziemlich auf Kante genäht, aber auch ohne irgendwelche Optimierungen im Design.
mit minimalem Platzbedarf ist man mit anderen Architekturen besser beraten. Bei der gezielten Optimierung auf f_max hat sich bisher bei mir herausgestellt: - Lokalen MMR-Bus (memory mapped register) mit Write-Delay-Pipes versehen. Wenn die Architektur unmittelbar zurücklesen koennen muss, muss man
-
Thread
C Übergabe mit Zeiger
es ein Bug von AVR Studio? Wenn dann wäre es ein Bug im Compiler (und nicht in der IDE), also dem GCC, und das ist (wenn auch nicht ganz ausgeschlossen) eher unwahrscheinlich. Such mal hier im Forum nach Bug und GCC. Fast jeder behauptet erstmal, das muss ein Bug im Compiler sein,... und praktisch
jedes Mal stellt > sich raus, das es doch kein Bug im GCC ist. Ja klar im Compiler. Ich weiß garnicht das AVR-Studio gcc nutzt. Ehrlich gesagt kann ich es mir auch nicht vorstellen, aber an was liegt es dann? > Mit welchen Compiler flags compilierst
-
Thread
Codegröße verkleinern
Routine einen kompilierten Code von ein paar Bytes bekomme, erhalte ich für denselben Sourcecode mit avr-gcc kompiliert, mehrere KBytes. Trotz der eingeschalteten Optimierung im makefile mittels der s Option. Ich habe einige Hindeutungen auf ein Tool namens avr-size im /bin Verzeichnis gelesen welches den
irgendwas.hex ("text"). Kleiner machen kann man damit aber nichts. Und warum schreibst du nicht ins AVR-GCC-Forum?
-
Thread
GCC versus BASCOM - Pegelunterschiede
Korrekt erspäht. Ich lief damals von den PICs über. Ausschlaggebender Grund war die Verfügbarkeit des GCC für die ATMEL µCs. Der Kommentar war noch falsch, für das Pollin Eval Board muss es heissen: DDRD = ( (1 << PD5) | (1 << PD6)| (1 << PD7) ); /* PD5, PD6 und PD7 als Ausgänge */ Hier sind
ist riesengross. Nö. Alle Werte sind zur Compilezeit bekannt: F_CPU, U2X_BIT und BAUSRATE. GCC faltet die Konstanten fleissig und zuverlässig auch bei abgeschalteter Optimierung. > Es ist viel sinnvoller, UBRR als Konstante vom Compiler ausrechnen zu > lassen und dann nur diese Konstante
-
Thread
AVR: float nach uint/Vorkomma und uint/Nachkomma
, avr-gcc unterscheidet nicht zwischen double und float!?!
gerri schrieb im Beitrag #3044245: > D.h. im Klartext, avr-gcc unterscheidet nicht zwischen double > und float!?! Das ABI lesen: http://gcc.gnu.org/wiki/avr-gcc#ABI
-
Thread
C - Zwei Zahlen zu einer Mappen
Ohne konvertierung zu Double hatte es ja auch geklappt. 2. Was meinst du mit Kommandozeilen? avr-gcc main.c -c -o main.o -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -I. -mmcu=atmega328p -DF_CPU=8000000 avr-gcc lib/lcd.c -c -o lcd.o -std=c99 -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -I. -mmcu=atmega328p -DF_CPU=8000000 avr-gcc lib/simpleprog.c -c -o simpleprog.o -std=c99 -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -I. -mmcu=atmega328p -DF_CPU=8000000 avr-gcc lib/ds18b20.c -c -
-
Thread
Linker-Problem
=gnu99 -DF_OSC=3686400 -MD -MP -MF .dep/main.o.d main.c -o main.o Linking: main.elf avr-gcc main.o --output main.elf -Wl,-Map=main.map,--cref -lm /usr/lib/gcc/avr/3.4.3/../../../../avr/lib/crts8515.o(.init9+0x0): In function `__bad_interrupt': ../../crt1/gcrt1.S:104: undefined reference
ffreestanding noch compilieren und linken, aber dann vermasselst du dir eine ganze Reihe an möglichen Optimierungen.
-
Thread
Crossworks mit optimiertem Code
Thumb-Code, nicht wahr? Vielleicht versteht ja Crossworks auch nur die Debuginfos nicht, die Dein gcc erzeugt. > Ich verwende den GCC zum > kompilieren und Crossworks nur zum Debuggen. Warum? Was nutzt denn Crossworks als Compiler, ist das nicht auch gcc?
mal, die einzelnen Optimierungsschritte selektiv abzuschalten, d.h. mit -fno-... anzugeben: http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Optimize-Options.html#Optimize-Options Gute Kandidaten wären solche wie -fno-reorder-blocks und -fno-schedule-insns. *Nach* der -O... Option.
-
Thread
if condition schöner schreiben?
Zweifelsfall auch besser. Natürlich sollte man sinnvolle Algorithmen verwenden. Wenn man das tut, ist Optimierung auf der Ebene "wie-kodiere-ich-das-am-besten-von-Hand" in sehr vielen Fällen komplett unnötig.
Der GCC erlaubt auch: [c] switch(i){ case 0 ... 3: case 8 ... 11: case 16 ... 19: case 24 ... 27: doSomething(); break; } [/c] Paddy schrieb im Beitrag #4884829:
-
Thread
Fehler im Compiler oder bei mir ?
Wenn die Optimierung eingeschaltet ist, kann der Compiler eine ganze Menge machen, was für den Menschen nicht auf den ersten Blick verständlich ist. Möglicherweise steht in R0 ja genau der Wert der an der Stelle benötigt
Compiler erzeugte Code etwas schlechter ist als ein von Hand optimierter. Nachtrag: Welche Optimierungs"stufe" hast du überhaupt aktiviert. Vielleicht kann das der Compiler sogar noch verbessern.
-
Thread
Assembler-Programmieren PIC16F1934/6/7
simpler Programmierung kommt heutzutage kein schlechter Code heraus, weil man die tatsächliche Optimierung dem Compiler überlassen kann. W.S.
Haben sie, deren 16. Die PIC30 waren erkennbar so konzipiert worden, dass heutige C Compiler wie GCC keine Verrenkungen benötigen. Das ist schon aus Faulheit (Sparsamkeit) sinnvoll, denn nur dann kann man effizient auf bestehenden Compilern wie GCC aufbauen. Was Microchip ja auch getan hat. > Erzeugter
-
Thread
Flash CRC Berechnung optimieren/schneller
Ich hab mal schnell was zusammengestrickt, ich komme auf 55 Takte/Byte Die Lib in crc16.h des AVR-GCC ist inline-Assembler (23 Zyklen) und braucht mit Loop-Overhead zusammen 41 Zyklen. Die CRC-CCITT ist mit 17 Zyklen etwas kürzer.
Ok, hier die kleine Optimierung, wenn man die Schleife um die CRC in ASM per Hand gestaltet. Macht 33 Takte/Byte. Die eigentliche, trickreiche CRC-Berechnung braucht 23 Takte, habe ich einfach kopiert. Die Variante in C
-
Thread
Ist das ein Bug im Compiler?
K. schrieb im Beitrag #3857496: > Virtuelle Maschinen > sind da ungemein praktisch. für einen GCC aber etwas übertrieben. Bei mir gibt es in jede Projekt ein Batchfile, das setzt einfach die passenden Umgebungsvariable zum GCC. schon kann ich mehrere Projekte mit unterschiedlichen GCC verwenden
abgeben dass immer etwas verlässliches herauskommt, aber soweit ich weiß > - und wie man sieht! - tut GCC das nicht. Doch, gerade GCC _tut_ es :-) Und das wird auch im Kleingedruckten zugesichert: "Most frequently reported non-Bugs" https://gcc.gnu.org/bugs/#nonbugs >> [...] To fix the code
-
Thread
Verhindern der wegoptimierung von for(;;) beim GCC
// clever runden #define BAUD 19200L uint8_t i=0; char c; char s[10]; char input[10]; char gcc[] PROGMEM = "Boot up Ready, OS Compiliert am "__DATE__" um "__TIME__" mit GCC Version "__VERSION__"\r\n"; void uart_puts (char *s); int uart_putc(unsigned char c); uint8_t uart_getc(void); void
nichts anderes passieren. Es sei denn, es ist ein volatile-Fehler. Die kann man einfach mit der Optimierung -O0 rauskriegen. Peter
-
Thread
Makefiles im C-Projekt
richtig? Nein, nicht wenn man es richtig macht. Du beziehst dich wohl auf LTO, was keine Optimierung des Linkers ist sondern des Compilers. GCC zum Beispiel zerlegt den globalen Call-Tree in Teilbäume, die parallel compiliert werden können. Einfach mal die LTO-Optioen anschauen.
Bruno V. schrieb im Beitrag #7637296: > Ich kenne AVR-GCC nicht. Kennst du einen gcc, kennst du alle. gcc ist gcc ist gcc ist gcc. > Wer macht dabei den dependency-Kram, also dass > nur die nötigen Schritte erfolgen? Niemand. Wer braucht schon solch
-
Thread
ATMega88 Umwandlung IAR -> GCC
www.atmel.com/products/AVR/mc/) Allerdings hänge ich gerade bei der Umwandlung der IAR-Befehle in gcc-Befehle. Wie müsste die folgende Zeile für den GCC aussehen? [c]__flash const uint8_t sineTable[SINE_TABLE_LENGTH * 3] = { . .(hier stehen die Tabellendaten) . .[/c] Wenn ich die zu
oben), _keine_ RAM-Adresse (das wäre ZL bzw. R30 :( ), also vermutlich besser 0x1e + 0x20 = 0x3e beim GCC benutzen, sorry falls ich verwirrung gestiftet haben sollte -hth, Jörg
-
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
__flash und memcpy
address space '__flash' to address space 'generic'" Wie macht man es richtig?? Compiler: avr-gcc
{ *(uint8_t *) dst++ = *(const __flash uint8_t *) src++; } } [/c] Compiler avr-gcc 4.7.2 Optimierung: -Os
-
Thread
Attiny Speicher zu knapp
Ist hier beschrieben http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmspeicher_.28Flash.29
stimmt was du da erzählst dann benutzt du einen miesen Compiler oder machst böse Dinge (keine Optimierung, nicht-konstante Delays usw.). Denn auch mit dem GCC kann man den Code aufblähen aber dann hat man definitv etwas falsch gemacht. gruß cyblord
-
Thread
[ASM] PowerPC springt nach 0x0
dann schmiert er auch nicht ab. Für den Compiler gilt also ab 5 case Auswertungen eine andere Optimierung? Desweiteren habe ich die switch-case durch ein if-else-if ersetzt. Damit gehtn auch alle meine 7 erfolgreich - auch weil anderer ASM code erzeugt wird. Welche Gründe gibt es denn hierfür
schmiert er auch > nicht ab. > > Für den Compiler gilt also ab 5 case Auswertungen eine andere > Optimierung? Ja. Ab 5 oder 4 (hängt wiederum von was anderem ab) case-Labels verwendet gcc Sprungtabellen, wenn die case-Werte "dicht" sind. Das müsste in deinem Code erkennbar sein, indem zB der Startwert
-
Thread
AVR: Problem mit eeprom_read_byte()
Programm läuft wenn ich mit Optimierungsstufen "s" oder "3" kompiliere. Ich brauche es aber ohne Optimierung, da mir ansonsten die eingebauten Warteschleifen wegopitmiert werden. Die sind aber notwendig, da der Mikrocontroller einen Flachbildschirm ansteuern muss, der da nicht mitziehen würde.
>Ich >brauche es aber ohne Optimierung, da mir ansonsten die eingebauten >Warteschleifen wegopitmiert werden. Die sind aber notwendig, da der >Mikrocontroller einen Flachbildschirm ansteuern muss, der da nicht >mitziehen würde.
-
Thread
Vorstellung und gleich eine Frage
/articles/AVR-GCC-Tutorial#EEPROM > aber irgendwie mag er entweder nichts ins > eeprom schreiben, oder aber nicht auslesen Wie könnte man wohl rausfinden, welches der beiden Szenarien zutrifft? Du musst dringend
oder verlierst du den Inhalt nach dem ein / ausschalten ? @ Karl Heinz, warum sollte man immer die GCC Lib verwenden ? ich seh dafür keinen Grund.
-
Thread
Attiny2313 macht Probleme
kompilereinstellungen wegoptimiert werden. Können sie nicht. Die _delay_ms Routine, die mit dem GCC mitkommt, wird 100% sicher nicht wegoptimiert.
Wie schalte ich die Optimierung bei AVR Studio 4 ein?
-
Thread
Optimieren? Thermostat mit Tiny26
avr-gcc -c -mmcu=attiny26 -I. -g -Os -Wall -Wstrict-prototypes -std=gnu99 thermo_little.c -o thermo_little.o thermo_little.c:22:17: lcd.h: No such file or directory thermo_little.c: In function `printFormat
der Rest ja noch, um verschiedene Profile im EEPROM zu verwalten. Auf jeden Fall wäre ohne die Optimierung von Jörg nicht mehr soviel drin gewesen.. Gruß Andreas
-
Thread
Arduino RAM sparen mit PROGMEM und strcpy_P()
verändert werden darf und somit darf der Compiler/Linker das auch annehmen und entsprechende Optimierungen durchführen.
aber er ist offenkundig noch immer zu doof dazu. Der arm-gcc kann diesbezüglich einiges besser, als der avr-gcc. Vermutlich hat es damit zu tun, dass AVR spezielle Befehle für den Zugriff auf den Flash Speicher brauchen, die gängigen ARM Controller aber nicht
-
Thread
Hilfe! AVR spinnt / macht was er will.
den Stack nichts mehr übrig. Besser man macht es so: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Array_aus_Zeichenketten_im_Flash-Speicher Gruß Jadeclaw.
unsigned char Buffa3[512];" ? Wurde doch schon gepostet: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Array_aus_Zeichenketten_im_Flash-Speicher
-
Thread
LCD EA W204B-NLW
versaubeutelt" werden. Deswegen habe ich mich da auch noch nicht ran getraut. Was hat das mit der Optimierung immer auf sich und wo find ich die im Atmel Studio 6.1? Danke
nehmen muss??? Vielen Dank Das kann ich dir nicht ausführlich erklären, aber bei diesem link http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html wird es erklärt. Leider alles Englisch.
-
Thread
GCC Inline Assembler Multiplikationen
8x8 sind zumindest im avr-Backend beschrieben. Sie sind daher für alle O-Stufen gültig. http://gcc.gnu.org/viewvc/trunk/gcc/config/avr/avr.md?revision=152958&view=markup > Ich dachte, errechnet dann 8bit x 8bit -> 8bit und konvertiert danach > erst in 16bit?! Das wäre der Fall mit -mint8 wo
in der Schublade liegen? Wobei ich jetzt gar nicht weiss, wie z.B. eine 32 : 8 Division intern vom GCC gerechnet wird!? Als 32 : 8 oder 32 : 32? Gruß Dirk
-
Thread
Speicherverwaltung Atmega8 was geht wohin? --> C
überdenken. Ja. >Was habe ich noch vergessen? http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung >PS. Ich kann kein Assembler, ich weiss das damit fähige Leute sehr >optimierten Code erzeugen können. Lohnt sich zu 99% nicht, der AVR-GCC ist meist schon ganz gut. MfG Falk
übernehmen das man irgendwo gelesen hat. Peter Dannegger schrieb im Beitrag #2478718: > Beim AVR-GCC ist leider die Standardeinstellung, daß er heimlich > inlined. Ist ja nicht schlimm solange noch ausreichend Platz vorhanden ist.
-
Thread
Popelige Rechnung oder doch nicht?
LDI R31,0x00 Load immediate --- C:\home\tools\hudson\workspace\avr8-gnu-toolchain\src\gcc\gcc\config\avr\libgcc.S 1: 0000001E 02.c0 RJMP PC+0x0003 Relative jump 1: 0000001F 05.90 LPM R0,Z+ Load program memory and postincrement
RJMP PC-0x0009 Relative jump --- C:\home\tools\hudson\workspace\avr8-gnu-toolchain\src\gcc\gcc\config\avr\libgcc.S 1: 00000043 97.fb BST R25,7 Bit store from register to T
-
Thread
64 Bit float Emulator in C, IEEE754 compatibel
Maxim B. schrieb im Beitrag #5916664: > Ich finde es nicht normal, daß in GCC double wie float behandelt wird. Nicht GCC allgemein, sondern das ist eine Konfiguration von AVR-GCC. Derjenige, der damals die GCC-Portierung für den AVR vorangetrieben hat, sah offenbar zum damaligen
in Ticks: von ~11500 auf ~7000 - 84 Byte eingespart Ist als V1.1.4 released. Die push/pop-Optimierungen via gcc-prologue habe ich da noch nicht drin. Die möchte ich in Summe in ein Release einsteuern, wo ich in Summe nochmal doppelte Code-Stellen rauswerfe.
-
Thread
PINx-Register
Weitere Basics findest du hier: [[Kategorie:Avr-gcc_Tutorial]]
optimiert, um ihn derart austricksen zu können. Geringste Änderungen des Codes oder der gewählten Optimierung können dafür sorgen, dass es doch wieder nicht funktioniert. Die korrekt Lösung wäre das Einfügen einer Wartezeit von genau einem Takt zwischen den beiden Zeilen und dem weiteren Code. Also
-
Thread
IAR-Compiler
umgesetzt. Aber der Asm-Code führt nicht die mit dem C-Code programmierte Funktion aus. Stell ich die Optimierung aus klappt es. Danke für Eure Antworten, Grüße Timo //--- Includes: #include<inavr.h> #include<io8515.h> //--- Macros: #define ClearBit(ADRESS,BIT) (ADRESS&=~(1<<BIT)) #define SetBit(ADRESS,
wert! Der Editor wird z.B. von UltraEdit um Längen geschlagen. Der Compiler ist wohl nur ohne Optimierung brauchbar... Also wohl GCC. Leider ist die Doku zum GCC nicht so sehr berauschend. Zumindest fand ich nix, mit dem ich innerhalb von einer halben Stunde ein lauffähiges HEX-File und OBJ-File machen
-
Thread
Zugriff auf SP *vor* Funktionsaufruf
__builtin_frame_address könnte helfen: http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Return-Address.html
man es mit Assembler machen. Eine Möglichkeit hatte ich im letzten Post adressiert. Wenn man den GCC durch den eines anderen Herstellers ersetzt, ergeben sich natürlich völlig neue Mögllichkeiten.
-
Thread
cannot read spec file 'device-specs/specs-atmega4808'
" ignoring duplicate directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/include-fixed" ignoring nonexistent directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/../../../../avr/sys-include"
\Atmel\ATmega_DFP\1.3.300\include c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/include c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/include-fixed c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0
-
Thread
[AVR] (Fehlerhafte) Codeoptimierung bei 32bit-Variablen
wegzuoptimieren (nach meinen kurzen einblicken in das Listung zu urteilen ;) ). Version des AVR-GCC ist 4.3, irgendwo meine ich mal gelesen zu haben, dass es da Probleme geben könnte ... Kommt nun wirklich der GCC einfach nicht mit den 32 bit klar, oder ist da sonst irgendwas von mir falsch? Grüße
oder aus den Quellen kompilieren? Gefällt mir eigentlich beides nicht ;) Das betrifft aber nur den GCC selber, also keine der andren Tools in der Toolchain? Chris
-
Thread
vom C code zur *.hex file
... und dann machst vermutlich gleich Bekanntschaft mit der Optimierung. Wenn in den Compilereinstellungen die Optimierung ein ist (und das ist sie und soll auch so sein) wird dir folgende Codezeile mit sicherheit "wegoptimiert": [c] for(x=0;x<=62;x++); //Int-Wert
. was muss ich damit machen? zu dem von dir genannten punkt: wie verhindere ich denn diese optimierung?
-
Thread
Atmel Studio 6 ignoriert Code
>und wenn dann der >Rest wegoptimiert wird, hilft mir das recht wenig. Einfach die Optimierung abschalten.
verwendet wird und der Linker sie rauswirft, etwa mit --gc-sections und -fdata-sections. Bei neueren avr-gcc wirkt -fdata-sections nämlich auch auf PROGMEM-Daten, was früher[tm] nicht so war.
-
Thread
Leisungsvergleich ARM AVR
die beim ARM zusammen auf 4 bytes erfolgen können. Somit könnte der AVR-Code bei entsprechender Optimierung auf dem ARM um ein vielfaches schneller laufen.
Dirk K. schrieb im Beitrag #3640847: > Optimierungen (-O2) Wie sieht dein Px-Auswerte-code denn inzwischen aus? Du hattest auch if-while-Verschachtelungen...
-
Thread
ARM Cortex gegen AVR
(nicht für Einsteiger) AVR (8Bit): + Einfach (für Einsteiger) + freie Compiler Toolchain (AVR-GCC: Eclipse mit Plugin oder AVR-Studio) o Peripherie/Schnitstellen - Speed/Rechenleistung (falls das wichtig ist)
an. > Ist wohl schon zu lange her, dass ich mich darüber geärgert habe ;-) Nimm einen modernen GCC und deklariere die Variable als "__flash". Den Rest macht der Compiler für dich. Kein #include, kein pgm_read_xxx() mehr.
-
Thread
AVR-ISR Assembler ohne Flags zu benutzen
persönliche Meinung. P.S. Es gibt auch effiziente Ringbuffer-Implementationen, die solche Optimierungen bzgl. Bufferlänge = Zweierpotenz gar nicht brauchen.
dass sie problemlos auf ein paar Register verzichten > könnten warum haben "die Wichser" beim gcc dann -ffixed-<register> erfunden?
-
Thread
Nicht genutzte globale Variablen werden wegoptimiert
Hallo GCC-Gemeinde, ich bin gerade auf ein sehr merkwürdiges Problem gestoßen. Und zwar werden globale Variablen, die ich in meinem Programmcode nicht explizit verwende, nicht richtig initialisiert, d.h. mit
nicht probiert, das wäre aber eh eine mehr oder weniger unbefriedigende Lösung. Ach ja: Die Optimierung ist natürlich aus, hier meine GCC-Argumente aus dem Makefile: [code] C_FLAGS = -mcpu=cortex-m3 -mthumb -O0 -gdwarf-2 \ $(patsubst %,-I%,$(INC_DIRS)) -I. \ -std=gnu99 \
-
Thread
WinAVR Register Doppelbelegung?
oder ob es da zu handfesten Kollisionen kommt. Ist euch da irgendetwas bekannt ob GCC solche Bugs erzeugen kann? Hätte mal jemand Zeit drüber zu schauen?
die Dinger sowieso nicht lesen, und die Zuordnung des Quellcodes zum Objektcode ist bei guter Optimierung schlicht nicht mehr möglich, verwirrt also eher.
-
Thread
AVR gcc: Funktionsparameter werden überschrieben
mitverfolgen, wie der Wert kaputt geht. (von 0x0795 über 0x07ab zu 0x00ab) Kompiliert wurde mit [code]avr-gcc -funsigned-char -funsigned-bitfields -O3 -fpack-struct -fshort-enums -g2 -DDEBUG -Wall -c -std=gnu99 -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -MT"$(@:%.o=%.o)" -mmcu=atmega88 [/code] Ich bin
stets mit der Option -O0 zu debuggen. Es sei denn, das Problem tritt nur bei einer bestimmten Optimierungs-Stufe auf.
-
Thread
ADC Channelauswahl
und y und sonstigem Schnickschnack. Aber: All das steht doch auch so im ADC-Teil, der im [[AVR-GCC-Tutorial]] verlinkt ist. Inklusive einer funktionierenden Routine, die einen beliebigen Kanal (und damit auch 2 verschiedene hintereinander) abfragen kann. Hast du da schon mal reingeschaut? [[AVR-GCC-Tutorial
, wo du Zeitprobleme hast * und dann, wenn feststeht, dass du in einem bestimmten Bereich Optimierungen brauchst, dann fang mit Optimierungen an. Premature optimization is the root of all evil
-
Thread
STM32: Compilierter Code unterschiedlich groß und Breakpoint nicht setzbar
man die durch eine neuere ersetzen? Gerade für C++ würde ich das machen. Die Cortex-M0 werden von gcc auch stiefmütterlich behandelt und optimieren schlecht.
Habe es gecheckt, das ist die CrossWorks Version, die enthält gcc 10.3, ist also frisch. Ist die Optimierung im debug build auch aus?
-
Thread
Wittig W2000 mit Sourceforge.net
ist sie komplett. Vielen Dank für eure Mithilfe! Sorry, ich in blutiger Linux-Anfänger. Mit Gnu-Gcc Make usw. hab ich schon einiges gemacht und das ist zum Glück unter Linux gleich... PS: Warum ist die TomCat.flash Datei um 400kb kleiner als die von Welec? Da fehlt doch noch ein ganzes Stück Code
Ich habe gerade die Datei: cdk-nios-gcc_all_3.1-20040330_i386.deb.zip in die Google-Group gestellt. Link Google-Group: http://groups.google.com/group/welec-dso Link Google-Group Files: http://groups.google.com/group/welec-dso/files
-
Thread
Probleme bei Debugging von GCC mit AVR Dragon
Möglichkeit, die DWEN-Fuse wieder zurückzusetzen. Scheinbar gibt es ein Problem mit dem Objektfile beim GCC. Ich habe die Option -gdwarf-2 gewählt. Dann sollte doch das generierte .elf File verwendet werden, oder? Ich habe das Makefile und die Compiler-Meldungen für ein kleines Testprogramm angehängt.
Ich findeschon das er verwandt ist: Ich habe Probleme beim debugging von GCC mit AVR Dragon - Kommunikation wird nicht mehr aufgebaut
-
Thread
avr-gcc: Fehler? Reihenfolge der Funktionen ist wichtig
Prozessor ist ein ATtiny48, die avr-Tools habe ich unter einem ziemlich aktuellen Ubuntu installiert (gcc 4.5.3), kompilieren tu ich mit avr-gcc -mmcu=attiny48 -c source.c dann linken usw. Im Prinzip ist mir die Anordnung der Funktionen ja egal, allerdings habe ich Probleme mit der Ausführung von
> Zeigen, Oha, nicht schlecht, in die Richtung geht's: avr-gcc -mmcu=attiny48 -c start.c avr-gcc -o start.elf start.o avr-objcopy -j .text -j .data -O ihex start.elf start.hex sudo avrdude -c avrispmkII -p t48 -P usb -e -U flash:w:start.hex Zur Sicherheit
-
Thread
Probleme bei selbstgebauter Uhr (DEM 16217 | STK500)
Datenflussanalyse wird bei dieser Variablen zu falschen Schlüssen kommen, also spar dir jegliche Optimierung auf dieser Variablen. Alles andere sind Folgeerscheinungen davon und bei manchen Compilern so, bei anderen wieder nicht. volatile hat damit zu tun, eine Variable von der Optimierung des Compilers
Datenflussanalyse wird bei dieser Variablen zu falschen Schlüssen > kommen, also spar dir jegliche Optimierung auf dieser Variablen. > > Alles andere sind Folgeerscheinungen davon und bei manchen Compilern so, > bei anderen wieder nicht. > > volatile hat damit zu tun, eine Variable von der Optimierung