-
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
Wieso 8 PWM Kanäle beim ATmega 64
_BV ist ein Makro aus alten Zeiten des GCC. Siehe Doku der libc, ist beim GCC dabei. MFg Falk
Laut: http://www.mikrocontroller.net/articles/AVR-GCC#Tipps_.26_Tricks _BV(x) entspricht dabei (1<<x)
-
Thread
STM32F4: Anfängerfrage: nach NVIC_Init lande ich in hardfault handler
dir gleich mal meinen Code an,. schau bitte selbst ob Du alles hast, meiner läuft. Prüfe auch die GCC Optimizer Einstellungen, Linker, LTO usw. Bei mir lag es daran. Es stürzte nämlich nur bei -O2 ab und nicht, wenn ich die Optimierung ausgeschaltet hatte. Moment... ich suche ..... In dem Code
extrem arrogant ist und sich für Gott hält. Die Libs sind für den Keil und lässt man sie durch den GCC laufen mit Optimierung erzeugen sie Hard Fault etc. da er volatile und static so gut wie nicht benutzt hat. Ich habe alle fremden Libs rausgeschmissen bei mir, alles selbst geschrieben. Die von Uwe
-
Thread
arm-none-eabi-gcc: Verwendung von "immediate offset" erzwingen
RY, [RX, (1<<5 + 1<<2)] STR RZ [RX, (2<<5 + 2<<2)] STR RY, [RX, (3<<5 + 3<<2)] Bisher habe ich gcc aber nur bei Zugriffen wie RCC->CFG dazu gebracht, Zugriffe mit "immediate offset" zu generieren. Egal, wie ich den Zugriff formuliere, der Zugriff erfolgt ohne Offset uns sieht wie folgt aus MOV RY
, 0] MOV RX, LowWord(BBR + 3<<5 + 3<<2] MOVT RX, HighWord(BBR + 3<<5 + 3<<2] STR RY, [RX, 0] GCC ist gcc version 4.6.0 (GCC). Ist das ein Manko von GCC oder hat jemand andere Hinweise
-
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
gcc erfindet befehle?
return 1; } das programm (ich habe den code mal auf die relevanten zeilen reduziert) wird vom gcc (version 3.4.5) mit der optimierung "s" für den atmel ATtiny26 folgendermaßen übersetzt: 1 .file "test.c" 2 .arch attiny26 3 __SREG
GCC ist nicht optimal für 8bit-Prozessoren. Generell geht GCC von mindestens 16bit breiten Maschinen aus - und das sieht man dann gelegentlich auch. Besser wird es mit -mint8, also 8bit "int" Typ, allerdings
-
Thread
Ist C++ bei Mikrocontrollern sinnvoll?
ist die <iostream.h> beim WinAVR nicht dabei oder ist mein gcc V4.1.1 schon wieder zu alt? mag das AVRStudio überhaupt cpp files? Als Endung für Sourcefiles werden nur .c und .s erlaubt.
nach float vs. int abgedriftet. Und wie ich es jetzt verstanden habe gibt es keine iostream.h für gcc, das original Posting ist wohl mit IAR oder anderem erstellt worden. Hätte da auch gleich erwähnt werden können.
-
Thread
Inline Funktionen die Xte
CALL aufgerufen werden würde). Mal findet man __inline__, dann inline, die einen sagen was von Optimierung O2 und wiederum der andere erzählt was von attributen, die das inlinen erzwingen. Alles habe ich in fast jeglicher Kombination ausprobiert. Meistens wird die Funktion aber immernoch mit CALL aufgerufen
vielleicht auch verstehen, wo sein Problem liegt. Ich würde mich freuen, wenn hier mal einer der GCC Spezies unter die Arme greifen könnte ;) Vielen Dank PS: Ich verwende den AVR-GCC
-
Thread
Casten funktioniert nicht
oder nimm zum Testen die Codeoptimierung raus. Nicht oder! Wenn er simuliert, muss er die Optimierung ausschalten. Das ist Grundvoraussetzung.
Testen der ersten. Simulator schrieb im Beitrag #2685962: > Wenn er simuliert, muss er die Optimierung ausschalten. Das ist > Grundvoraussetzung. Damit geht man zwar auf Nummer sicher. Aber ein Muss ist das nicht. mfg.
-
Thread
PGM_P Verwirrung
__attribute__((progmem)) in typedef wird nicht unterstützt in avr-gcc, es ist ein *nicht-dokumentiertes* Feature. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342#c9 http://savannah.nongnu.org/bugs/?33716 Am besten verzichtest du auf das ganze prog_char, prog_void
PROMEM wie es im Compiler dokumentiert ist -- nämlich nur für Variablen im static Storage. http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attributes
-
Thread
24 bit - 3byte Variable in C
} MYTIME_T; MYTIME_T Times[100]; // 100 * 3Byte sizeof(Times) ist somit 300, zumindest mit GCC ;-)
MYTIME_T; > > MYTIME_T Times[100]; // 100 * 3Byte > > sizeof(Times) ist somit 300, zumindest mit GCC ;-) Ist ja hochinteressant. Vielen Dank.
-
Thread
C - Ersatz von switch case.
in Assembler besser löse, weiß ich und das ist auch nicht die Frage) Compiler ist der IAR, Optimierung auf Platzbedarf, Prozessor der STM8S105. Auszug aus meiner bisherigen Lösung: [c] #define clk_reg1_oben PC_ODR_ODR3 #define clk_reg2_oben PC_ODR_ODR2 #define clk_reg3_oben PC_ODR_ODR1 #define
Besonders als Anfänger und C-Einsteiger sollte man seine Zeit und Energie nicht mit Pseudo-Optimierungen verschwenden. Als fortgeschittener und Profi auch nicht. https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
-
Thread
AVR Simulator mit grafischer Benutzeroberfläche für Linux
Mittlerweile kann das Programm auch die "elf"-Objektdateien, welche avr-gcc 4.9.2 erzeugt, einlesen und die Quelltext-Zeileninformationen aus den debug-daten verarbeiten. Das avr-gcc_sample ist das Testprojekt, welches mir zum Evaluieren dient. Es besteht aus einem "C"-Hauptteil
Hallo Ingo, habe mir gleich mal die "avr-gcc_sample.zip" gezogen. In dem c-Skript werden leider nur *.S-Dateien kompiliert und gelinkt: [code]#!/bin/bash # Assembling: main.S avr-gcc -c -mmcu=atmega8 -I. -x assembler-with-cpp -Wa,-adhlns
-
Thread
ARM malloc / Heap - problem lpc2378
Codelesbarkeit. Hab auch nirgendwo ein funktionierendes malloc Beispielprojekt im Netz gefunden was auf GCC basiert...
Definitionen ersetzt usw. Kompiliert einwandfrei durch aber erzeugt mal eben 50kb neuen Code. Wieso der GCC den nicht benutzen Code nicht ausblendet weiss ich nicht. Optimierung geht wegen eines Bugs (laut Rowley FAQ) nicht, sonst sind meine ISRs futsch. Ich erhalte dann ständig die Fehlermeldung: Writeback
-
Thread
Frage zu Rekursion und StackOverflow in C
Vor allem da die Funktion mit einem ordentlichen Compiler dank tail-recursion keinen Stack benötigt (gcc ab -O2 oder -Os.
Aufrufebene etwas Stack, so dass der bei zu großer Tiefe nicht mehr ausreicht (Sofern die Compiler-Optimierung das nicht auflöst).
-
Thread
Linux ist endlich vom C89 Standard weg
Ahnung ob es so etwas auch schon gibt, gefunden habe ich diesbezüglich nichts, zumindest nicht bei GCC: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html Es wäre natürlich viel Aufwand und den ein oder anderen wird es sogar stören, aber es wäre machbar. Noch einfacher wäre es aber, wenn
kann man in einem constexpr-Ausdruck testen, denn dann muss(!) > das UB einem Fehler ergeben. > Der GCC macht das auch (der clang leider nicht???). Ggf. ist es der GCC, der hier falsch liegt.
-
Thread
Switch / Case Anweisung mit Bedingung
müsste merken, dass die letzte Bedingung nur noch wahr sein kann. Witzigerweise schnallt es der GCC hier nicht: [c] extern void a(void); extern void b(void); extern void c(void); #include <avr/io.h> void evaluate(void) { int8_t diff; diff = OCR0A - OCR0B;
> Ist das besser und schneller? Insbesondere ist es unportabel. Peters typische Mikro,,optimierungen'' halt. Genau das, was die Optimierung eines zeitgemäßen Compilers von allein können soll, damit eben nicht so'n kryptisches Zeug da steht.
-
Thread
XOR / pointer - Problem
seh ich auch so... avr-gcc (GCC) 4.2.2 (WinAVR 20071221) zumal es an anderer Stelle im programm funktioniert... [c] char S8_Box[] = { 0x28, 0x0C, 0x09, 0x39, 0x12, 0x16, 0x02, 0x1D}; [/c] macht was es soll...
. alles was ich bisher dazu > gelesen hatte war > http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna Vielleich hilft es, alles zu lesen, etwa den Abschnitt " Frühe Codeausführung vor main()" darin... http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna#Fr.C3.BChe_Codeausf.C3.BChrung_vor_main
-
Thread
Servo ansteuerung! Hab ich was übersehen? [AVR GCC]
5); // Pins B5 als Ausgänge setzen while(1) { Move_Servo(150); } } Compiler: avr-gcc.exe -mmcu=atmega8 -Wall -gdwarf-2 -O0 -MD -MP -MT servo_self.o -MF dep/servo_self.o.d -c ../servo_self.c avr-gcc.exe -mmcu=atmega8 servo_self.o -o servo_self.elf avr-objcopy -O ihex -R .eeprom
Du hast die Optimierungen ausgeschaltet. Dadurch werden die in den delay-Funktionen benötigten Fließkommaberechnungen zur Laufzeit durchgeführt und verlängern das Delay. Deine 4 Mikrosekunden werden also vermutlich in Wirklichkeit
-
Thread
Vergleich von signed und unsigned
int ist (egal ob signed oder unsigned) wird zu int. Das ist auch eines der Probleme, warum der gcc manchmal mit sanfter Gewalt zu Optimierungen gezwungen werden muss und sich als 'Universalcompiler' auf Byteebene manchmal schwer tut. Spezialcompiler für µC nehmen es mit dieser int-Promotion in manchen
Bei GCC nur wenn explizit gefordert mit -Wconversion. Weder -Wall noch -Wextra enthalten das.
-
Thread
Microchip Studio, XC8, AVR-GCC und Speicherbedarf
Meines Wissens nach fehlen bei der kostenlosen Version dem XC8-Compiler die Optimierungen. Oliver
Georg M. schrieb im Beitrag #7458501: > Für den AVR-GCC Compiler muss die Zeile > ... > ersetzt werden. Sollte aber gehen. https://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html#gaea2b6be92ead4673bc487b271b7227fb
-
Thread
volatile oder nicht volatile bei Feldvariablen, AVR GCC
verwendet wenn es sich um Felder handelt auf die man kein Polling macht? In diesem Fall stört die Optimierung doch nicht, oder? Danke für Eure Antworten
Theoretisch müsstest du das Feld wohl volatile machen. In der Hauptroutine kann der gcc durchaus auf die Idee kommen, etwas bereits gelesenes nicht nochmal aus dem Feld zu holen, also würde ich es nicht wagen, volatile weg zu lassen. Wenn du nur wie gezeigt in der Schleife durchläufst
-
Thread
AVR, Pointer auf Flash-Speicher per Assembler
>solche Tabellen immer in die untersten 64 kiB legt? Nein, EIN C-Compiler nicht, aber DER avr gcc. Will man mehr, muss man workarounden ;-) [[AVR-GCC-Tutorial]] -> Variablenzugriff >64kB
> Nein, EIN C-Compiler nicht, aber DER avr gcc. Will man mehr, muss man > workarounden ;-) > > AVR-GCC-Tutorial > > -> Variablenzugriff >64kB Hier wendet sich der Gast mit Grausen... Entschuldigen Sie die Störung, ich bleibe bei Assembler
-
Thread
GCC Compiler Flags während Build
Optionen für bestimmte Mudule setzen wie[pre]modul.o: CFLAGS += -fno-lto[/pre]Ohne modulübergreifende Optimierung ist es schon mal einfacher, ein Modul einzugrenzen.
Eben gefunden auf https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html "... You can invoke GCC with -Q --help=optimizers to find out the exact set of optimizations that are enabled at each level. ..."
-
Thread
Probleme mit volatile struct * und gcc
Hi, ich hab hier ein Problem mit den Optimierungen, die der gcc auf einen Pointer einer Struct anwendet: Zum Patienten: In bus.c wird ein Pointer auf eine Struct definiert: [c] volatile struct frame * bus_frame; [/c] In bus.h wird der
= 1){ bus_frame->isnew = 0; } wdt_reset(); } } [/c] Der gcc generiert mir aus der Schleife folgendes: [avrasm] void bridge_mainloop(void) { 2ba: e0 91 57 02 lds r30, 0x0257 2be: f0 91 58 02 lds r31, 0x0258 2c2: 01 c0
-
Thread
AVR-GCC optimiert TIME & DATE weg
Die beiden unten stehenden Zeilen werden vom Compiler weggeputzt (Optimierung: Os). Es gibt keinen Bezug im Quelltext auf die Bezeichner s1 & s2. Das Schlüsselwort "volatile" hat keinen Einfluss. Wie kann ich den Compiler überreden TIME & DATE im Flash abzulegen? [C
Probiers mal hiermit: [c] #pragma GCC push_options #pragma GCC optimize ("O0") dein code #pragma GCC pop_options [/c] Aber ich muss OldMan eigentlich Recht geben...
-
Thread
Startup Code ohne Interruptvektoren
Zum Beispiel das Erkennen der Resetquelle, Schalten die Diagnose LED usw. Na ja, und was die Optimierung angeht: alle globalen Variablen sind in Registern gehalten, ich habe alle Optimierungsstufen des Compilers ausprobiert, der Code ist einfach geschrieben, damit der Compiler ihn gut versteht und
Also wenn ich http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/AVR-Options.html#AVR-Options richtig verstehe würde -mno-interrupts dafür sorgen dass keine Interrupt Tabelle generiert wird.
-
Thread
casting in C
in double gerechnet - was aber hier vermutlich keinen Unterschied macht, da es sich um Code für AVR-GCC zu handeln scheint.
". Hab ich ja geschrieben: Rolf M. schrieb im Beitrag #6158129: > Double kennt auch der avr-gcc. Aber es ist dort genauso klein wie float.
-
Thread
Atmega32 - GCC: Problem mit long
Hi Ihrs, ich habe folgenden Code: volatile unsigned long seconds = 0; void RTC_Overflow() { seconds++; IO_Write(seconds); } IO_Write gibt den Wert einfach über LED's aus. RTC_Overflow wird jede Sekunde über einen Interupt aufgerufen. Mein Problem ist das sich bei den LED's nichts tut (seconds beibt immer 0). Wenn ich seconds als int deklariere (volatile unsigned int seconds = 0;) klappt alles ohne Probleme. Hat jemand eine Idee wodran das liegen könnte? Früher hatte der selbe Code mal geklappt?!? (Auch Optimierung ausschalten bringt nichts) Gruß Lalle
-
Thread
Speicher-Adressen-Marco - suche Hilfe
xdata[/c] oder auch "global" per Kommandozeile, da daß man den Code nicht anfassen muss:[pre]avr-gcc ... -Dcode= -Ddata= -Dxdata=[/pre] Daß statische read-only Daten bei AVR üblicherweise im Falsh abgelegt werden ist lediglich eine Optimierung — allerdings eine, die aufgrund des sehr begrenzten SRAM bei vielen Anwendungen essenziell ist. Mit avr-gcc 4.7 und neuer gibt es den Address-Space Qualifier __flash gemäß der Embedded-C Erweiterung ISO/IEC TR 18037. Damit könnte das dann auch so aussehen:[c]#define code __flash[/c] Damit werden die "
-
Thread
Arduino: Größe eines Pointers
Joachim B. schrieb im Beitrag #5605937: > habe gerade mal geschaut: > "A little more on the issue: GCC pointers - of all types - are only > 16-bits in length. ..." Aufpassen! Das ist eine Aussage über *diese eine* Implementierung mit dem Namen avr-gcc. Es ist keine allgemeingültige Aussage über gcc
support embedded processors" http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf Beim AVR-GCC gibt es konform dazu 24-Bit Pointer, die Daten in sowohl ROM als auch RAM adressieren können. Ist natürlich zur Laufzeit etwas aufwändiger. https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Named-Address-Spaces.html
-
Thread
XMega Clksystem
Hallo Forum, ich benutze einen AtXMega128A1 Rev.H mit GCC 4.3.2 und Studio 4.17.666 Seit gestern versuche ich, nicht den internen 2MHz oder 32MHz RC Osc zu verwenden, sondern einen externen 16Mhz Oszillator. Ich brauche für Frequenzmessungen einen genaueren
Andere Initialisierungen: keine Chance, er springt immer auf den internen 2Mhz RC Osz. Verwendet AVR GCC 4.3.2 (WINAVR 2090313) mit allen untersch. Optimierungen auf XMega 128A1, BGA, Rev. H Gruß Helmut
-
Thread
Einstieg AT91SAM7S256 **gesuchteHeaderfiles**
eine vorkompilierte GNU-Toolchain mit etwas Zubehoer. Im Prinzip sollte man jeden Code fuer arm-elf-gcc damit uebersetzen koennen. - debuggen: Stichwort OpenOCD. Aktuelle Version nutzen, die in WinARM 20060606 ist inzwischen recht alt. Vgl. auch ww.yagarto.de Martin Thomas
erst aussah, die mmc Routinen die es bei Olimex zum Download gibt liessen sich auch sofort mit dem gcc übersetzen und liefen auf Anhieb (auch wenn nur low Level Block r/w). Die Hinweise zu OpenOCD habe ich inzwischen auch gefunden, das sehe ich mir auch mal an.
-
Thread
Port-Informationen mittel Struktur verarbeiten
> erhalte ich Fehlermeldung nach Art von function has too many arguments > !!! Du verwendest gcc? WEnn ja und die Fehlermeldung ist immer noch da, dann stimmt wahrscheinlich der Protoyp oder der Aufruf nicht mit der Funktion überein. > Daher kam ich auf die Idee mit der Sruktur. Man kan
Angaben zu den Kompilaten der folgenden Beispiele beziehen sich immer auf einen ATmega64 mit "-O2"-Optimierung, bei anderen Controllern und Optimierungen kann das leicht unterschiedlich ausfallen, die Tendenz bleibt aber. [c] #include <stdint.h> #include <avr/io.h> #define MyDDR DDRB #define MyPORT
-
Thread
Wie verarbeitet der GCC die Speicherklasse extern?
Variable. Selbst wenn der Programmierer das selber nicht so gedacht hatte. Das ganze funktioniert beim GCC nämlich auch ohne das "extern" vor der Deklaration. Hier sind die erwähnten Dateien: [c] /*main.c*/ #include <stdio.h> #include "erste_datei.h" int ersteVariable = 13; /*<- 1*/ int zweiteVariable
(.comm) "überlagert" werden — zumindest wenn der Compiler das implementiert, was zum Beispiel bei GCC der Fall ist (-fcommon ist immer noch Default). Wenn man das nicht möchte, compiliert man mit -fno-common, und erst dann meckert der Linker "multiple definition of" an. Definitionen (nicht tentative
-
Thread
Detected loop counting up. Recommend loops count down as detecting zeros is easier
einzige Konsequenz ist, dass die Schleife pro Durchlauf einen Takt mehr benötigt. TI empfiehlt die Optimierung auf "-o2" zu setzen. http://processors.wiki.ti.com/index.php/Compiler/diagnostic_messages/MSP430/1544
unter Anwendung der Regeln von C rauskommen darf, darf er machen was er will. Wobei mit und ohne Optimierung auch verschiedene Ergebnisse rauskommen dürfen, wenn beide in diesem Sinn zulässig sind.
-
Thread
suche Kritik zum Programmierstil ;o)
wegoptimiert werden oder???? sollte das nicht 'volatile asm("nop")' sein??? ich sollte wieder mal die gcc docu mir zu gemüte führen ... 73 de oe6jwf
entsprechent volatile definieren oder, als schlechtere Variante, den asm volatile(" nop") einfügen. Optimierungen sind schon ein Fall für sich. Kann einen manchmal verzweifeln lassen. :-) ciao, Stefan.
-
Thread
32Bit Zahl zusammensetzen
Auch wenn ich von den C-Experten gesteinigt werde: Ich verwende den GCC ausschließlich als AVR-GCC im AVR-Studio, und dort erzeugen die Casts mit Union genau den Code, den ich erwarte. Bei jeder anderen Lösung (sogar mit dem expliziten Typecast zu einem Array of unsigned
Also ich habe AVR-GCC genutzt. Wo erfahre ich denn etwas welchen endian meine Architektur hat?
-
Thread
Ungenutzte Bibliotheksfunktionen aussortieren
der Thread https://www.mikrocontroller.net/topic/443383 macht mich ein wenig stuzig. Wenn eine Optimierung dazu führen *könnte*, dass ein leerer, von mir definierter Callback, einen Usercallback überschreibt dann ist das vollkommen inakzeptabel und der falsche weg. Und somit komme ich wieder zu Funktionszeigern
Da meine Funktionen leer sind, würde *__naked* sinn ergeben, aber das ist auf der x86 Architektur (gcc) scheinbar nicht definiert. Bliebe noch die Möglichkeit *__always_inline* Wie würdet ihr das Problem lösen?
-
Thread
Frage zu einer Codezeile in C
Timmo H. schrieb im Beitrag #4731155: > Tatsache... mein gcc schmeisst mit -Wall zwar kein Fehler aber das > Programm schmiert ab liegt aber mehr oder weniger an deinem System. Der Absturz kommt, weil der String in einer Read-Only-Page im Speicher liegt
Timmo H. schrieb im Beitrag #4731155: > Tatsache... mein gcc schmeisst mit -Wall zwar kein Fehler aber das > Programm schmiert ab Peter II schrieb im Beitrag #4731156: > liegt aber mehr oder weniger an deinem System. > > Der Absturz kommt, weil der String
-
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?
-
Thread
.c Datei kompilieren (krieg ich einfach nicht hin)
############## ## General Flags PROJECT = cdcemu MCU = atmega8 TARGET = cdcemu.elf CC = avr-gcc CPP = avr-g++ ## Options common to compile, link and assembly rules COMMON = -mmcu=$(MCU) ## Compile options common for all C compilation units. CFLAGS = $(COMMON) CFLAGS += -Wall -gdwarf
from ../main.c:4: e:/winavr-20100110/lib/gcc/../../avr/include/avr/signal.h:36:2: warning: #warning "This header file is obsolete. Use <avr/interrupt.h>." In file included from ../main.c:6: e:/winavr-20100110/lib/gcc/../../avr/include/avr/delay.h
-
Thread
Zündkurve verstellen beim 2Takter
jede Umdrehung deinen Winkel individuell festlegen. Man könnte evtl. sogar eine automatische Optimierung nach Schema Klopfsensor anbringen (als "nicht-Bezin-Murkser" weiß ich nicht wie akut das bei nem 2 Takter is).
ich endlich mal auf einen gscheidn Link gestoßen: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR Und hab gleich meine erste Frage: Wie kann ich das TCCR auf Prescale 64 setzen? TCCR1 = ?? Lg
-
Thread
Verständnisfrage ==
if( *p ) f( p ); } [/C] Wenn du nicht glaubst, dass sei eine Schleife, dass zieh es mal durch GCC.
Es bleibt eine Rekursion, auch wenn es einen Compiler gibt, der das im Zuge seiner Optimierung durch eine Schleife ersetzt.
-
Thread
Warum signed int bei delay?
Wert nicht in signed int (bzw. int16_t) darstellen lässt, was hier durchaus der Fall sein kann. Der GCC liefert hier zwar das erwartete Ergebnis, sauberer ist es aber, sich gar nicht erst auf solche implementation-defined Features zu verlassen.
Abfrage erzeugen, ob bei d += TCNT1 ein Überlauf auftritt, und dann sofort zurückkehren. Geniale Optimierung, weil die Funktion dann in einigen Fällen schneller fertig wird...
-
Thread
GCC inlined die ganze Zeit meine Funktionen.
Hallo! Ich habe gerade ein Problem mit meinem GCC, Version ist das neuste WinAVR (vom Juni). Und zwar meint er trotz Optimierung -Os häufig Funktionen inlinen zu müssen, auch wenn das aus meiner Sicht völlig schwachsinnig / verschwenderisch ist. Gibt
C-Files heraus, in das Object-File compilieren. Edit: `-finline-limit=N' Scheint die richtige GCC-Stellschraube zu sein...
-
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
Debug ANSI C Programm, RaspberryPI.
Henrik Wellschmidt schrieb im Beitrag #2983360: > Ich schwöre ... kein Mux! > pi@rpi ~/1wirevz $ sudo gcc -Wall -Wextra -Werror -o /usr/sbin/1wirevz 1wirevz.c -lconfig -lcurl > pi@rpi ~/1wirevz $ Tatsächlich. Auf der pi bekomme ich mit dem aktuellsten Code mit gcc-4.6.3 mit -Wall -Wextra keine Warnung
Rückgabewerte von fgets, chdir und write. Immerhin weis ich jetzt, dass ich in Zukunft den raspian gcc bei Warnungen nicht trauen kann.
-
Thread
Projekt funktioniert nach Neuinstallation von WINAVR nicht mehr
Einziger Anhaltspunkt: Winavr gibt beim kompilieren folgende Warnung aus: c:/winavr-20100110/lib/gcc/../../avr/include/avr/signal.h:36:2: warning: #warning "This header file is obsolete. Use <avr/interrupt.h>." Hatte schon jemand mal dieses Problem? Kann mir jemand helfen? Bernd
Kann z.B. an einer "aggressiveren" Optimierung im neueren WINAVR liegen. Wenn du im Code z.B. Einfachst-Warteschleifen mit Variablenhochzählen hast statt der _delay_Xs() Funktionen, wäre das eine Problemstelle. Auch in der Gegend gemeinsam
-
Thread
CPP Code nach C portieren. endet in Stackoverflow.
wenn ich den Header von void matrix... ins h kopiere. Ansonsten bin ich für offen für jegliche optimierungen! Arc Net schrieb im Beitrag #3939803: > Da könnte es helfen die ins Flash zu legen. Wie macht man dies beim STM bzw. beim ARM-GCC?
Claudio H. schrieb im Beitrag #3939820: > Wie macht man dies beim STM bzw. beim ARM-GCC? "const" davor. Nur müssen die dann schon fertig initialisiert sein. Du brauchst also ein Hilfsprogramm, das den Quelltext davon generiert.