-
Thread
STM32F030 Problem mit GPIO
wenn man ohne Optimierungen kompiliert dauert das delay vermutlich minuten. Hast du so lange gewartet beim testen?
wie ich das mit OpenOCD mach. Programmierer schrieb im Beitrag #3869183: > wenn man ohne Optimierungen kompiliert dauert das delay > vermutlich > minuten. Hast du so lange gewartet beim testen? Ich hab gcc gesasgt, das er auf Größe optimieren soll ("-Os"). Ausserdem hat ich ihn ne weile neben
-
Thread
if (uint16_t) --blink) == 0 Ok. if(--blink == 0 ) nicht ok?
avr-gcc-4.2.4 -O2 -mmcu=attiny13 --> gleich avr-gcc-4.2.4 -O2 -mmcu=atmega1280 --> gleich avr-gcc-4.2.4 -O3 -mmcu=attiny13 --> gleich avr-gcc-4.2.4 -O3 -mmcu=atmega1280 --> gleich
avr-gcc-4.3.6 -O1 -mmcu=attiny13 --> gleich avr-gcc-4.3.6 -O1 -mmcu=atmega1280 --> gleich avr-gcc-4.3.6 -O2 -mmcu=attiny13 --> gleich avr-gcc-4.3.6 -O2 -mmcu=atmega1280 --> gleich
-
Thread
switch case optimierung
Hi, ich habe ein ATtiny10-C-programm mit einer switch case Anweisung geschrieben. Der Compiler hat es wundervoll mit einem berechneten Sprung optimiert, die einzelnen Sprungziele liegen jeweils 6 Adressen auseinander. Aber was ich nicht verstehe: wie macht er die Multiplikation mit 6? Hier ein Auszug aus der iss-Datei: [c] //********************************************************************* void light_wave(uint8_t Color,uint8_t position) { Color = 4; switch(position) 7a: e6 2f mov r30, r22 7c: f0 e0 ldi r31, 0x00 ; 0 7e: e1 31 cpi r30, 0x11
-
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
Liftsteuerung im C, Interrupt goto Gesperrt
muß es nur nutzen. [c]int main(void) { int a; a = 1; a += "Stuss"; }[/c] $ gcc -Wall -Wextra x.c x.c: In function ‘main’: x.c:6:7: warning: assignment makes integer from pointer without a cast [enabled by default] x.c:7:1: warning: control reaches end of non-void function [
hinweisen und nutzte das nur als Beispiel ohne hier wirklich eine Aussage bezüglich Compiler und Optimierung machen zu wollen.
-
Thread
Organisation von Projekten mit hochkomplexer Hardware
da. Was gemacht wird um es auf eine neue Architektur zu bringen ist: 1) die Architektur in den gcc zu bringen (moderater Aufwand, aber am Anfang braucht man noch keine Optimierung und so) 2) die architekturabhängigen Teile im Kernel zu ändern (Startup-Code und Taskswitching, dass kann relativ
Hallo, der gcc selbst ist ja "neutral". Der seetzt den C99 Standard auf den Maschinenbefehlssatz um und berücksichtigt dabei die Eigenheiten der CPU. Der ARM11 ist ohne C Compiler und unterlegtes OS ohnehin witzlos
-
Thread
Mutex Problem bei ISR
> Letzteres ist etwas Denksport. Würde ich auch so machen (den Denksport). Mit einem modernen GCC muß man da aber aufpassen; der spielt gelegentlich an der Reihenfolge der Speicherzugriffe herum. Herauszufinden, welche Optimierungen man abschalten muß, damit er das bleibenläßt, artet schon fast
Nosnibor schrieb im Beitrag #3857502: > Mit einem modernen GCC muß man > da aber aufpassen Eine gute libc bringt dir atomic Definitionen mit. Die überreden dann den GCC zu passender Arbeit.
-
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
Gibt es eine Programmiersprache mit diesem Schleifentyp?
r21 brne .L3 .L1: ret .size memorycopy, .-memorycopy .ident "GCC: (GNU) 4.7.2" [/avrasm]
und nicht dass das kombinierte so schnell ist ;-) ausserdem: wenn du dir anschaust, welche optimierungen "aktuelle" CPU (seit Jahrezehnten) gerade bei bedingten sprüngen machen, ist nicht mal sicher, ob mehrmaliges hinschreiben, schneller ist als normale schleife...
-
Thread
ARM Einstieg - Fragethread
Toolchain oder ein Heap für malloc() und Co. Fast 2kB für Startup klingt eher nach abgeschalteter Optimierung. So viel Speicher ist selbst für die ST Lib ungewöhnlich. Bei einem "leeren" Projekt versteht sich. Ansonsten schlägt die schon ordentlich zu.
jetzt die Compiler/Linker Flags gemäß dieses Artikels http://www.mikrocontroller.net/articles/ARM_GCC#Code-Gr.C3.B6.C3.9Fe_optimieren hier gesetzt, was jedoch kaum Änderung bringt. Wenn ich im Linker Menü die newlib-nano wähle, sinkt der Speicherbedarf auf [c]Program Memory Usage : 600 bytes
-
Thread
printf-Alternative für AVR
setzen: [c] buf[INT_MAXWIDTH]='\0'; [/c] Aber bei AVR GCC ist das meines Erachtens nach immer überflüssig, auch wenn man nicht mit der Arduino-IDE programmiert und diverse Parameter und Optionen für Compiler und Linker anders setzen kann. Daher habe ich es
y); break; case 3: printf("PLOP %d\n", z); break; } } while(0); } [/c] Mit AVR-GCC 4.7.2 ist sub1 228 Bytes und sub2 112 Bytes groß. Die vermeintliche Optimierung hat die Codegröße also mehr als verdoppelt. Das liegt u.a. daran, dass in sub1 die Variablen x, y und z, die in Registern
-
Thread
Schnelle Assembler Multiplikation
Benutzen Compiler (zb der avr-gcc) sowas eigentlich zur Optimierung von Multiplikationen mit konstanten Werten? Das ersetzen von Multiplikationen mit 2er-Potenzen gehört ja zum Standard. Hier muss natürlich auch erücksichtigt werden
Johannes schrieb im Beitrag #3839179: > Gibt es einen bekannten Algorithmus, Jupp, schau z.B. in die GCC-Quellen. Der macht das nämlich so; irgendwo in der Gegend von expmed.c.
-
Thread
Probleme mit float Berechnung
ja im Debugger. Hab keine Optimierung an!
wissens dürfte er mit volatile deklarierte variablen nicht wegoptimieren, also liegts nicht an der Optimierung. :(
-
Thread
memcpy auf ARM Cortex A9 & Linaro
wie wäre es mit einem #define #define memcpy memmove oder beim gcc Aufruf gcc -Dmemcpy=memmove
, wieviele Parameter der Programmierer des Compilers bei der Optimierung des Builtins berücksichtigt.
-
Thread
LED Würfel ATTINY13
für das eine Bit auch den passenden Befehl, anstatt Read-Modify-Write. Das ist allerdings eine Optimierung. Geht also schön schnell, funktioniert aber nicht wie vom TO erwartet. mfg.
PINB & (1<<PINB4)) ) { ... } [/code] Siehe auch: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Digitale_Signale
-
Thread
Heizungssteuerung Trovis 5575 auslesen
- Adaption: automatische Anpassung der Heizkennlinie (Raumtemperatursensor erforderlich) - Optimierung: Berechnung der optimalen Ein- und Ausschaltzeitpunkte der Heizung (Raumtemperatursensor erfor- derlich)
wie verzögerte Temperaturanpassung, maximale Regelabweichung, PID-Einstellungen (Kp, TN ...), Optimierung / Adaption usw wirken sich am Ende auch auf die effektiv anliegende Vorlauftemperatur aus. Und am Ende hämmern dann oft noch RTR's mit ihrem ganz eigenen Regelverhalten dazwischen. Das alles
-
Thread
Pointer in STRUCT wollen einfach nicht funktionieren! (AVR-GCC)
Hallo Leute, ich werd noch blöde.. :) Ich versuche gerade einen kleinen Modbus Slave aufzubauen und kämpfe gerade mit Pointern die auf structs mit weiteren Pointern ziele sollten.. Klingt kompliziert, ist es aber nur wenn man den Wald vor lauter Bäumen nicht mehr sieht.. :P Die Deklaration meines Structs: [c] typedef struct { uint8_t slave_address; uint8_t function_code; uint16_t *data; uint16_t crc; } modbus_frame_t; [/c] Nun würde ich gerne dieses Struct in meiner Empfangsroutine mit Daten füllen.. Dafür teste ich gerade einen Code wie den folgenden.. Der Compiler
-
Thread
C: "unsigned char"-Vergleich immer mit 16 Bit?
Die Version von Atmels Studio ist irrelevant. Die Version vom Compiler ist wichtig, also vom gcc in WinAVR. Wie schon gezeigt: avr-gcc 4.7.2 macht es besser.
ist und avr-gcc auf C:\avr-gcc-4.7.2-mingw32\bin\avr-gcc.exe make auf C:\avr-gcc-4.7.2-mingw32\utils\bin\make.exe _automatisch_(!) eingestellt wurde. 7. Compilieren und über das kleinere Binary freuen
-
Thread
16x2 LCD Langsamer Displayaufbau
nicht von Hand > dran rumbasteln. egal wie -os -o1 -o2 -o2 ? komisch ich muss im Studio die Optimierung vorgeben und nun lese ich das der das selber macht ?
= variable_23 * 2; [/c] eine Shift-Operation zu machen, ist ja wohl eine der trivialsten Optimierungen, die es gibt. Wenn der Compiler das nicht macht, schmeiß ihn in die Tonne ;) lg Chris
-
Thread
Initialisiertes Char Feld mit Länge 1 und Inhalt '\0'?
sollte dann auch zu den restlichen Char Feldern passen und keine Extrabehandlung erfordern... Der gcc wie nebenan empfohlen: $ m68k-elf-gcc -v Using built-in specs. COLLECT_GCC=m68k-elf-gcc COLLECT_LTO_WRAPPER=/usr/home/holm/cross/m68k/libexec/gcc/m68k-elf/4.6.2/lto-wrapper Target: m68k-elf
without-headers --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local Thread model: single gcc version 4.6.2 (GCC) Optimierung ist -Os -fomit-frame-pointer Gruß, Holm
-
Thread
Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega
einzeln abgearbeitet (in den Puffer geschickt und gewartet bis fertig) und damit kann die Look-Ahead Optimierung von GRBL dann nicht genutzt werden. Lange Rede kurzer Sinn: Mir ist die Look-Ahead Optimierung lieber und ich pfeife auf eine farbige Unterscheidung. Was es noch Neues gibt: Ein Process View
"-flto" bei dem alten WINAVR wird nicht gehen. Entweder raus werfen oder einen neueren GCC nehmen. VG, Uli
-
Thread
8 Bit aus 32-Bit-Variable auswählen
Fragestellung nicht deine Umsetzung. Vielleicht kennst Du schon das Schlüsselwort UNION ? https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html
Der Compiler versteht was ich will wenn die Optimierung eingeschaltet ist. Dann ist der Code kompakter als Assembler!
-
Thread
1µS mit 1MHz erzeugen
dem momentanen "Testsystem" (Atmega8 mit 1 MHz) einen 1µS Zähler zu erzeugen. Hintergrund wäre die GCC _delay_us Funktion zu ersetzen. Der erste Ansatz bestand aus einer Softwarelösung die leider bei 2 MHz aussteigt. Das Ziel ist später einen DS18S20 (One Wire) mit 1.2 Mhz mit maximalen 1 K Bytes
geschrieben sind. Und sie werden optimiert. Das geht sogar soweit, dass die Funktionen nur mit Optimierung das richtige Ergebnis liefern. > Also ggf aufpassen mit dem am preskaler rumdrehen. Könnte ggf das timing > komplett verdrehen. Da wird nicht dran rumgedreht, sondern es wird eine Einstellung
-
Thread
ADC in C unter WinAVR ärgert
sinnvoll sich vorher mal ein paar Grundlagen anzulesen? http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
bekannt, daß bei eingeschalteten Optimierungen die Zeilen nicht mehr passen.
-
Thread
Atmega/C: eine Funktion aus einer Funktions heraus aufrufen
mal ein richtiges Programm, das auch läuft. An dem Extrakt oben lässt sich nur die Qualität der Optimierung erkennen. mfg.
"F_CPU not defined for <util/delay.h>" [-Wcpp] c:\program files (x86)\atmel\atmel toolchain\avr8 gcc\native\3.4.1056\avr8-gnu-toolchain\avr\include\util\delay.h 90 3 GccApplication2 Programm ließ sich kompilieren und übertragen. Die 7-Segment-Anzeigen zeigen weiterhin alte Ziffern, die noch im
-
Thread
AVR-Toolchain optimization + volatile = Problem
wundersame Weise verschwand. Ich verwende den AVR Toolchain von Atmel: [code] C:\avrtoolchain\bin>avr-gcc --version avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.2_939) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty;
übersetzen lässt, erzeugen folgende Compiler mit -Os -mmcu=atmega168 exakt den gleichen Code: - avr-gcc 4.3.3 (WinAVR-20100110) - avr-gcc 4.6.3 - avr-gcc 4.7.2 - avr-gcc 4.8.0 - avr-gcc 4.9.2 Wie in 99% der Fälle liegt das Problem /nicht/ im gezeigten Code — bestenfalls evtl. darin, daß durch das
-
Thread
"einfach" Hobby programmieren.
immer noch so ist, kann ich nicht behaupten. Wie schon gesagt, die Stärke von C ist seine Optimierung, ist aber zugleich seine Schwäche, weil sie einen dazu zwingt, Programme so zu schreiben wie es für den Compiler am bequemsten ist. Da bleibt von der Übersichtlichkeit wie sie beim PASCAL
Endeavour (Das ja 2011 zum letzten mal flog) jeweils drei verschiedene C/C++ Compiler installiert: GCC, Intel und PGI http://www.nas.nasa.gov/hecc/support/kb/GNU-Compiler-Collection_87.html Was so mit C programmiert wird: http://robonaut.jsc.nasa.gov/R1/sub/software.asp > The software for Robonaut
-
Thread
Frage zu Mikrocontroller Programmierung
es schon im Header gemacht wird: http://de.wikipedia.org/wiki/Include-Guard Manche Compiler (GCC) haben sogar eine extra Optimierung eingebaut ein include Guard zu erkennen, und das haeufige Oeffnen des Header-Files zu sparen. ZigZeg
-
Thread
Ausgabe von float oder double über printf [dsPIC33fj]
die Floats roh, der muss das dann interpretieren. Der hat genug Dampf. Oder drehe mal die Optimierungen des XC16 auf: Projekt->Properties->XC16->xc16-gcc->Optimizations->Optimization level Eventuell reichts ja. Das könnte das sein, was dein Kollege gemacht hat.
-
Thread
Bascom - UART / Channel auswählen im Programm
echten" Ausdrücken der Unterschied zu dem Luna? Macht der Compiler überhaupt eine Flussanalyse mit Optimierungen wie z.B. der GCC oder ist das auch nur ein aneinander kopiertes Zeugs?
> Macht der Compiler überhaupt eine Flussanalyse mit Optimierungen > wie z.B. der GCC oder ist das auch nur ein aneinander kopiertes Zeugs? Der kann noch nicht mal Ausdrücke mit mehr als 2 Operanden. Wo bitteschön sollen der/die Entwickler je die Begriffe
-
Thread
Retro Fieber: Z80 oder 68000 ?
zutreffenden Teile werden NICHT compiliert, sondern komplett ignoriert. > Vom system her oder dem GCC? Der gcc (aber auch jeder andere C-Compiler) setzt das, wenn das Zielsystem ein Unix ist. Das ist schon seit 1969 so, da gab es noch keinen gcc. Wenn das Zielsystem aber ein AVR ist, ist unix
Christian J. schrieb im Beitrag #3926160: > Optimierung ist aus, die hat mir nur Murks mal erzeugt. Hältst du das nicht für ziemlich frech? Optimierung abschalten und dann über unoptimierten Code meckern?
-
Thread
Berechnung auf PC und auf Controller unterschiedlich
AvrMelodyBeeper **** make all Building target: AvrMelodyBeeper.elf Invoking: AVR C Linker avr-gcc -Wl,-Map,AvrMelodyBeeper.map -mmcu=attiny25 -o "AvrMelodyBeeper.elf" ./MelodyBeeper.o Finished building target: AvrMelodyBeeper.elf Invoking: AVR Create Extended Listing avr-objdump -h -S
schrieb im Beitrag #3781010: > Sobald ich dies jedoch auf den Controller (Attiny85) lade > avr-gcc ... -mmcu=attiny25 ... Was denn nun?
-
Thread
[AVR] _delay_ms() funktioniert nicht mehr (vom Compiler ignoriert?)
nicht richtig funktionieren wird. :( Von STK500-Besitzer abgesehen, sagt ja niemand, das Du die Optimierung _ausschalten_ sollst. Das ist doch mal ein "RTFM" wert. http://www.groupes.polymtl.ca/inf1995/logiciel/progAvr/avr-libc-user-manual-1.8.0.pdf ;-)
Bei mir kommt mit [code]avr-gcc (GCC) 4.8.2-2[/code] [code]avr-binutils 2.24-1[/code] [code]avr-libc 1.8.0-5[/code] [code]avr-gcc -Os -g3 -o main.elf -mmcu=attiny2313 main.c[/code] unter ArchLinux folgendes heraus: [avrasm
-
Thread
Controller mit FPU
ein AVR rechnet locker mit float- (32Bit) oder auch double-Werten > (64Bit) Ist double beim avr-gcc mittlerweile 64 Bits breit?
A. K. schrieb im Beitrag #3778992: > Ist double beim avr-gcc mittlerweile 64 Bits breit? Das glaube ich nicht, bin mir aber nicht sicher. Für 'echte' double nehme ich IAR.
-
Thread
ext. Interrupt, ASM Problem
Hallo "einzig wahrer Gläubiger" aka c-hater. Bei dem Sch..ssdreck würde halt der GCC die Drecksarbeit machen und man könnte sich auf's Problem konzentrieren. Ich kann übrigens diverse Kisten in ASM dirigieren und weiß deshalb das die "Drecksarbeiter" ihre Arbeit fast immer gut genug
Abhängigkeiten zwischen den Tasks möglichst zu minimieren. Genau das war oben auch die allererste Optimierung: Bei genauerer Betrachtung des Problems war festzustellen, daß es mit nur einem Task lösbar ist. Besser kann man die Abhängigkeiten garnicht verringern als dadurch, sie gleich ganz eleminieren.
-
Thread
memset führt zum crash
Stelle genau die Exception aufgerufen wird. Versuche mal einen anderen Compiler, zB den neuesten gcc-arm-embedded ( https://launchpad.net/gcc-arm-embedded ), bei dem ist die memset Funktion vielleicht korrekt kompiliert.
Target Flash-Debug :) Ja hoffentlich ist dann auch mit Release Einstellungen kompiliert, also mit Optimierungen. Bringt ja nichts wenn du nur ohne Optimierungen debuggst, aber mit Optimierungen der Fehler auftritt. Mehmet Kendi schrieb im Beitrag #3770044: > Dass es am memset liegen könnte, ziehe also
-
Thread
AVR bootloader Probleme
Optimierung steht auf optimize for size, habe aber auch schon alles andere probiert. Falls interesse besteht kann ich das programm mal hochladen
das flag werde ich mal probieren. Heißt also, dass solche Probleme auch mit einer älteren avr-gcc Version auftreten könnten und ich nur das Glück hatte, dass hier keine Sprungtabelle verwendet wurde, oder liege ich da falsch?
-
Thread
Bezüglich Stack, Heap, Ram etc. auf µC
nachzureichen: Ja ich programmiere nur in C und die Entwicklungsumgebung (Rowley Crossworks) verwendet den GCC.
Arrays entsprechende Zugriffe alle paar KB einflechten. > Oder wenigstens in Software? Gibts in GCC im Prinzip, wobei es natürlich Sache der Zielsystemanpassung ist, etwas draus zu machen.
-
Thread
Wie auf C-struct elemente in assembler function zugreifen
berechnen zu lassen und diese in ein "ldr" zu übergeben. Hier ein paar sehr hilfreiche Seiten bzgl. GCC Inline Assembly: http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#ss5.3 http://www.ethernut.de/en/documents/arm-inline-asm.html http://hardwarebug.org/2010/07/06/arm-inline-asm-secrets/ GCC Inline Assembly korrekt zu verwenden ist etwas tricky, es gibt da diverse Fallen durch die Optimierung, zB wenn man sich temporäre- und Input-Register geben lässt und die sich überschneiden könnten.
-
Thread
Probleme Tachosignal Auswertung
werden. Unten habe ich das Programm mal eingefügt. Ich verwende einen ATMega32, AVR Studio 4 und den GCC. Ich möchte das ab einer Windgeschwindkeit von ca. 50km/h der Ausgang PORTD1 aus "high" gesetzt wird und unter 50km/h auf "Low" gesetzt wird. Das Programm scheint auch zu Funktionieren, jedoch
Balou Baer schrieb im Beitrag #3756824: > vielleicht habt ihr ja noch eine Idee der Optimierung für diesen Code um > ihn kompakter oder evtl. "schneller" zumachen. Da deine Windgeschwindigkeit nur dazu benutzt wird, um eine LED zu schalten und der Zahlenwert an sich ja nirgends auf
-
Thread
STM32F4: Umstieg auf Eclipse + GNU Arm Embedded Plugin
leider die Optimierungen flach, die in der Funktion verwendet werden. Gibt es bei 2. einen technischen Grund oder eine Abhilfe?
Hrmmm, in den Optimierungseinstellungen sehe ich, dass man noch den gcc als Treiber für den Linker einstellen muss und dass es auch Möglichkeiten gibt, der Maschinerie zu sagen, dass ein Objekt außerhalb der Projekt-Übersetzungseinheit nicht sichtbar ist... Vielleicht sind
-
Thread
sizeof ergibt 2 für array mit 9 16bit werten
Vergiss das && ! Das ist absolut nutzlos und gefärlich. Seine einzige nützliche anwendung besteht bei gcc beim referenzieren eines labels... [c] void x(){ int r = &&l; goto r; label l: } [/c] http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html Das ist aber leider nicht
Schau mal hier: http://www.atmel.com/webdoc/atmelstudio/atmelstudio.Projects.GCC_projectOptions.html http://www.atmel.com/webdoc/atmelstudio/atmelstudio.Projects.GCC_projectOptions.CompilerOptions.html Rolf Magnus schrieb im Beitrag #3753856: > -Wall -Wexta -std=c99 -pedantic
-
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
Bug im avr-gcc bei Behandlung von SFRs als Bitfields?
Variante ein zweites Mal wiederholt. Kann dazu vielleicht Johann (oder Jörg oder ein anderer avr-gcc-Experte) was sagen? Achja, Compiler ist avr-gcc 4.7.2, Optimierung Os. Gruß und Dank, Frank
Frank M. schrieb im Beitrag #3748189: > Du hast einen neueren avr-gcc 4.7.2? gcc version 4.10.0 20140629 (experimental) (GCC) > Könntest Du den Code aus dem > Ausgangposting da mal durchschicken und hier den Auszug aus der > lss-Datei angeben? lss mag ich
-
Thread
Fragezeichen in C-Code - was ist das?
wird. Warum? Wenn du es genau wissen willst, prüf es doch einfach nach, mit eingeschalteter Optimierung. Oliver
Peter II schrieb im Beitrag #3747096: > was ist an -Os richtiger als -Os - wird sind bei GCC nicht beim µC. Du warst bei -O2 und das ist nun mal was anderes als -Os. http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > Außerdem ist es auch mit -Os auf einen PC nicht gleich. Und nicht
-
Thread
PWM-Pin von AVR deaktivieren
gezeigt, dass man (wenn man die Definitionen der Bitfelder selbst vornimmt) durchaus auch beim avr-gcc schreiben könnte: TCCR0A.com0a0 = 1; Warum auf die Definition der Bitfelder speziell beim AVR verzichtet wurde, lässt sich nur drüber streiten. Ich weiß aber, dass der frühere avr-gcc von 2010
Bei anderen µC Entwicklungssystemen sind sie aber gebräuchlich. Mittlerweile übersetzt der avr-gcc beide Statements aber absolut identisch.
-
Thread
HEX Größe verzehnfacht durch if Abfrage
> es. Wenn ich die if Abfrage auskommentiere funktioniert es auch. Nur > zusammen nicht. Optimierungen sind an? Wenn du summe änderst, aber nicht nutzt, schmeißt der Optimierer die Änderung logischerweise raus. Ergo ist sqrt dein Problem.
Marian B. schrieb im Beitrag #3741610: > Optimierungen sind an? Wie schauts mit der Antwort auf die Frage aus?