-
Thread
kompilierter code ist unter Linux größer als Win!
Hallo leute, Ich habe bis jetzt immer unter Windows mit WinAvr (avr-gcc (GCC) 4.1.2 (WinAVR 20070525)) und dem Programmers Notepad code für einen attiny 2313 kompiliert. Unter Linux mit der neuesten AVR-GCC Version und der gleichen makefile/code erzeugt mir das jedoch
kann ich die Makefile (erstellt aus einem WinAvr template) generell nicht unter linux benutzen? AVR-GCC funktioniert augenscheinlich wunderbar, optimierungs-switch und auch jegliche anderen Einstellungen der Makefile werden korrekt übergeben. Werde nacher noch folgendes versuchen: - gleiche Version
-
Thread
Fehlermeldung ISE
/14.4/ISE_DS/ISE//lib/lin/libboost_iostreams-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin/libboost_program_options-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin/libboost_regex-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin/libboost_system-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin/libboost_thread-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin/libboost_zlib-gcc41-mt-p-1_38.so.1.38.0 /opt/Xilinx/14.4/
-
Thread
Unix Programmierung
apt purge manpages-de Die manpages haben nichts mit Fehlermeldungen zu tun. Die Übersetzungen für gcc sind für z.B. gcc 11 im Paket gcc-11-locales, das aber bei Ubuntu sowieso für alle gcc-Versionen ab 10 kaputt zu sein scheint. Das kann man sehen, wenn man mal https://packages.ubuntu.com/impish/all/gcc-11-locales/filelist mit https://packages.ubuntu.com/impish/all/gcc-9-locales/filelist > ein paar Werkzeuge für die Kommandozeile (Unix funktioniert ohne IDE). > Na gut, make brauchst du erst nächste
-
Thread
unions structs bildfields
als compiler nutze ich avr-gcc
, and objects described in the library clause (clause > 7). > > Man kann mit dem avr-gcc alles nutzen, was in "clause 7" steht? Ob er (bzw. die avr-libc) das vollständig untestützt, kann ich nicht sagen. Ich vermute mal, nicht. Aber zumindest wird gcc per Default im "hosted"-Modus betrieben
-
Thread
Rücksprungadresse auf dem Stack schwachsinnig?
Sonst haste 2 mal reti im Programm und der Prozessor würde nur noch Amok laufen. ( Compiler gcc ?) Jogibär
gleichzeitig Bin leider nicht der Crack im__attribute__ Zeugs. Der KOMPLETTE Assemblercode VOM gcc wäre mir lieber. Jogibär
-
Thread
avr-gcc linker Problem
Hallo, ist es normal das avr-gcc auch Funktionen mit eincompeliert die ich in meinem Code gar nicht benutze? Das ist natürlich sehr ärgerlich, weil ich mir einige Libs geschrieben hab (LCD, UART, usw) aus denen ich nur selten alle
kann der Linker unbenötigten Code wirklich nicht weglassen? Ich benutzte beim compelieren die Optimierung s aber auch mit zB 3 ist es nicht anders. Vielen Dank Gruß Philipp
-
Thread
PIC Port C vor Variablen initialisieren
> kommt das Zitat? ... aus aktuellem mplabx help. hat mich auch gewundert, dass sieht nach avr/gcc aus und funktioniert sogar in xc8 - im simulator überprüft. mt
Apollo M. schrieb im Beitrag #5810219: > ass sieht nach > avr/gcc aus und funktioniert sogar in xc8 Auch für PIC16? Muss ich gleich testen...
-
Thread
Array nicht in RAM
die map file im Anhang. Als Entwicklungsumgebung benutze ich Code::Blocks, zusammen mit dem AVR-GCC und avrdude zum upload. avr-gcc --version (WinAVR 20090313) 4.3.2 Habe mal ans Ende der if's einmal LEDs umschalten gehängt, LED ist dauerhaft eingeschaltet. Hm... ins Makefile habe ich keinen
verwendest auch einen ATmega8 ja? Warum eigentlich avr-g++ fürs linken? Nehm da doch auch mal den avr-gcc.
-
Thread
Struktur Variablen hintereinander im Speicher ablegen?
Dafür hat jeder Compiler was eigenes. Beim GCC (in dessen Forum du dich ja befindest) heißt das __attribute__((packed)). Ist aber generell keine gute Idee, da es erstens unportabel ist und zweitens das Alignment ja aus gutem Grund existiert
andere Optimierungs-Optionen, bei denen das evtl. anders ist. Es ist halt auch prozessorabhängig. > Da das ausserdem ein Array von 128 dieser Strukturen betrifft, ist das > doch ne riesen speicherverschwendung
-
Thread
In einem Assembler Programm für Division auf C ausweichen!
allemal. Wie auch immer. Nochmal zum Mitmeißeln: Die Divisions-Routinen kommen aus der Bibliothek des GCC, dort liegen sie in Assembler vor. Die kannst du problemlos herauskopieren und einbauen, evtl. ist aber etwas Anpassung nötig.
Hochsprachcompiler gibt. Wenigstens Gugel solltest du allerdings bedienen lernen, wenn du da mal "avr-gcc register passing" eintippst, kommst du im dritten Link auf: http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna das dir das ABI von AVR-GCC (sogar auf deutsch) beschreibt. Das zugehörige
-
Thread
return uart_rx() | (uart_rx() << 8);
Falk B. schrieb im Beitrag #4871653: > Premature optimization is the root of all evil. Mit Optimierung hat das nix zu tun, eher mit "Know your Language!"
Johann L. schrieb im Beitrag #4871869: > Mit Optimierung hat das nix zu tun In der Vorstellung mancher Menschen schon: "Wenn ich möglichst wenig Code schreibe, dann ist das optimal. Also quetsche ich möglichst viele Anweisungen in eine Zeile, anstatt
-
Thread
Zählvariable in for-schleife springt direkt auf Abbruchbedingung
gesetzt. Dann springt er in die Schleife und i ist direkt 8. (Mein Kubus besteht aus 8 Punkten). Optimierungen sind aus, ich arbeite mit CodeBlocks(GCC) MfG Chaos
gcc erkennt das Semikolon-vor-Schleife-Problem (mit hochgedrehten Warnungen) leider nur bei if und else, nicht bei for und while.
-
Thread
Chip45 Bootloader-Debugging, Mega128 mit AVRStudio und JTAG
Flash aber tatsächlich ab F800. Ich dachte zuerst, es handelt sich dabei um folgendes Problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087 Das sollte doch behoben sein? Oder habe ich irgend etwas übersehen? Etwas ratlose Grüße, Bernhard
Controllertyp und Taktfrequenz. Das erklärt halt nicht, warum ein Teil des Codes bei eingeschalteter Optimierung nicht übersetzt wird, eine Endlosschleife, in der einiges passiert. Womit hast Du denn das Paket übersetzt? Gruß, Bernhard
-
Thread
Dry made easy
etwas hinterher. Deswegen brauch clang etwas mehr boilerplate. Der angehängte Code ght nun für gcc >= 8.1 und clang >= 9.0.
etwas hinterher. Deswegen brauch clang etwas mehr boilerplate. Der angehängte Code ght nun für gcc >= 8.1 und clang >= 9.0.
-
Thread
Delay mit Timer
[[AVR-GCC-Tutorial/Die_Timer_und_Zähler_des_AVR]]
lucas schrieb im Beitrag #4423589: > Die Delay Routinen die in der Lib vom Gcc mit dabei sind. > Das haut bei mir irgendwie nicht hin. Dann benutzt du sie entweder falsch (z.B. keine Konstante übergeben), du hast F_CPU falsch oder gar nicht definiert oder du hast die Kompiler-Optimierungen
-
Thread
Shift-Operator und Performance
promoted werden muss. In dem Falle wär's kein Ersatz. Jedenfalls bekomm ich es momentan mit avr-gcc nicht hin, einen 8-Bit Shift erzeugen zu lassen (4.5.1). Es muss aber gehen, sonst gäb es im gcc keine Pattern dafür. Möglicherweise ist's irgende Optimierung die sich wieder mal selber ins Knie schiesst. In dem Falls wäre die Sequenz in avr-gcc ok (natürlich mit r25 und nur für O2+, da die Sequemz 2 Byte länder ist als ne Schleife. Wobei letztere allerdings den Eingabewert zerstört und er nicht wiederverwendbar ist. Wenn also ne Kopie nötig
-
Thread
XC32 Inline Funktionen
files. [/pre] Ich empfinde das als höchst unsauber und habe zum Vergleich mal in den Abschnitt der gcc Dokumentation geguckt (https://gcc.gnu.org/onlinedocs/gcc/Inline.html). [pre] By declaring a function inline, you can direct GCC to make calls to that function faster. One way GCC can achieve this
count_b (void) { return fun(); }[/c] > [...] und habe zum Vergleich mal in den Abschnitt der gcc > Dokumentation geguckt > (https://gcc.gnu.org/onlinedocs/gcc/Inline.html). Im Endeffekt das gleiche in Grün: Um Inlinen zu können, muss gcc die Definition kennen: Entweder klassisch, indem er
-
Thread
8 bit vs. 16 bit
Auch AVRs tun sich nicht wirklich leicht mit Daten auf dem Stack, > insbesondere wenn man wie der GCC nur einen Stack verwendet. Die haben halt damals beim Entwurf nicht über den Tellerrand in Richtung GCC geguckt, sondern sich ausschließlich auf die Kommentie- rung durch die Haus- und Hoflieferanten
Das Problem einer 8-bit-Architektur gegenüber der 16-bit-int-Forderung > von C dürfte eher der AVR-GCC-Implementierung denn der 8-bit-CPU > anzulasten sein. Mir ist klar, dass GCC hier ganz spezielle Probleme hat, weil das im maschinenunabhängigen Teil einfach nicht vorgesehen ist, es aber dort realisiert
-
Thread
AVR: OCRx1 Werte automatisch berechnen
Falk Brunner schrieb im Beitrag #3201008: > [[Festkommaarithmetik]] Übrigens beherrscht avr-gcc Festkommaarithmetik und Typen wie accum oder short fract etc. Wäre bestimmt ein Update von "Festkommaarithmetik" wert!
gibt optimierte ALgorithmen für (saturierte) Operationen. Insgesamt gibt es 16 Typen http://gcc.gnu.org/wiki/avr-gcc#Fixed-Point_Support
-
Thread
LCD Atmega8535 fehler beim Programm erstellen mit AVR-Studio
> gcc plug-in: Error: Object file not found on expected location http://www.mikrocontroller.net/articles/WinAVR#gcc_plug-in:_Error:_Object_file_not_found_on_expected_location Alle Einstellarbeiten sollten
andere LCD Library, die RW nicht benötigt, z.B. den lcd-routines.c/lcd-routines.h Code aus dem [[AVR-GCC-Tutorial]].
-
Thread
Dividieren durch Schiften Gesperrt
die Compiler sich so verhalten wie von mir beschrieben. Relevant dürfte hier ja vor allem der gcc sein. Unter http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Integers-implementation.html#Integers-implementation steht: [pre]Signed `>>' acts on negative numbers by sign extension.[/pre] Zum Vergleich
auch n:0. Das einzige, was bei gcc sicher einen arithmetischen Shift zu erzeugen in der Lage wäre, wäre ein nicht portierbares __builtin_ashr oder so, das es jedoch nicht gibt. Gleiches gilt für rotate, daß sich zwar auch für avr-gcc
-
Thread
Arduino Codegröße
minimale Codegröße optimiert. Wie sieht dein Programm aus? Spaghetticode oder viele Funktionen? [[AVR-GCC-Codeoptimierung]] Hinter der Arduino-IDE steckt der avr gcc, also sind viele der Vorschläge machbar, wenn gleich nicht immer sinnvoll.
> etwas zu komprimieren? soweit ich weiss ja. https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung preferences.txt
-
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
Keine Warnung wenn Prog. Speicher voll?
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Optimize-Options.html#Optimize-Options beschreibt mögliche Parameter für die Optimierung. -Os -fweb -frename-registers -ffast-math dürfte so ziemlich den kompaktesten
-
Thread
Inverse Kinematik auf dem ATMEGA8-16
2; % use pow(x,2) or x*x ? AVR-GCC? q3 = -acos((L12^2+L23^2-p13sq)/(2*L23*L12))+pi; % acos(x) in AVR-GCC? % q2 b1 = atan2(p13(3),sqrt(p13(1)^2+p13(2)^2)); b2 = acos((L12^2+p13sq-L23^2)/(2*L12*sqrt(p13sq))); q2 = -(b1+b2); %
, also haut mich nicht, wenn ich was falsch mache) q1 = atan2(y,x); % tan(x) function in AVR-GCC? atan2(y,x) ? p011 = [x;y] p011sq = p01(1)^2+p01(2)^2; p011 = p011/p011sq*L01 % q3 p01 = [p011(1); p011(2); H01;]; % cos(x) sin(x) in AVR-GCC?
-
Thread
PIC 18f452 Hilfe Bei 1. C programm mit sdcc
Beim MCC18 wird lediglich _eine_ der vielen Code-Optimierungen nach einiger zeit deaktiviert, nicht alle. "Procedural abstraction", soweit ich das noch in Erinnerung habe. Alle anderen Optimierungen bleiben verfügbar. Grüße, Chris
bei "-O2" (optimize for speed) aber etwas langsamer als bei "-Os" (optimize for size). Welche Optimierungen in den jeweiligen Stufen durchgeführt werden steht im User Manual des GCC.
-
Thread
Overhead struct-pointer
.] } [/c] Muß ich für diese "Verschönerung" einen Preis bezahlen oder optimiert der Compiler (GCC für ARM Cortex M3) die konstanten Zeiger-Dereferenzierungen immer weg? Viele Grüße W.T.
#5193596: > Muß ich für diese "Verschönerung" einen Preis bezahlen oder optimiert > der Compiler (GCC für ARM Cortex M3) die konstanten > Zeiger-Dereferenzierungen immer weg? ich kenne zwar ARM nicht, aber auf x68 wird es sogar mit dem Referenz teilweise besser, eine Verschlechterung konnte ich
-
Thread
Auf element außerhalb array zugreifen
> > int main(void) { > array[42] = 5; > 42[array] = 5; > *(array+42) = 5; > } GCC 7.3.0 (MingW) warnt übrigens mit -Wall sehr wohl "subscript out of bounds", das nur der Vollständigkeit halber. Daß er ohne -Wall nicht warnt, bedeutet nicht, daß er es nicht für unerwartete Optimierungen
eine GCC-Erweiterung ist.
-
Thread
Array-Speicher nach LCD-Ausgabe wieder freigeben
buffer überschreibt, sondern alles einzeln > ablegt... Das tut er ja. Allerdings ist der avr-gcc eigentlich ein Compiler für eine Von-Neumann-Architektur. Mit Harvard tut er sich schwer (getrennte Speicherbereiche für Flash/ROM und RAM). Deshalb kopiert der Startup Code beispielsweise erstmal den
"); DOG_writetext(Buffer,1,0);[/C] Habe ich was falsch verstanden? Ich meinte mich auf AVR-GCC-Tutorial und die obigen Ideen berufen zu haben, kann aber sein, dass ichs falsch verstanden habe?
-
Thread
Assoziativität Links-Rechts
> parallel ausführen würde. Hmm ... Das geht nur bei "echten" Funktionen ( "attribute(pure)" im GCC ). Da kann der GCC z.B a()+a() durch 2*a() ersetzen. Automatisches Parallelisieren von Funktionen gibts afaik aber eh nur bei Sprachen, bei der Funktionen schon per Definition keine Seiteneffekte
keine Seiteneffekte hat. Was dem Compiler auch ohne Kenntnis des Codes dieser Funktion bestimmte Optimierungen in aufrufendem Code ermöglicht, die sonst nicht möglich wären. Mit Parallelisierung hat das nichts zu tun.
-
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
FLTK statisch linken
Normalerweise ist das ganz einfach, wenn man alles statisch linken will. Man macht einfach "gcc -s" statt "gcc", fertig. Solange man die Libs mit -lirgendnelib angegeben hat, und nicht mit libirgendnelib.so oder libirgendnelib.a, nimmt es dann jenachdem ob man -s angegeben hat oder nicht die .
> Normalerweise ist das ganz einfach, wenn man alles statisch linken will. > Man macht einfach "gcc -s" statt "gcc", fertig. Maja, nicht ganz. Man muss schon auch von sämtlichen verwendeten Libs eine statische Version installiert haben. Und in manchen Fällen, wie es z.B. oft bei openssl gemacht
-
Thread
C Tutorial
im wiki gibts en butes tutorial zu gcc(avr)
jede Millisekunde kaempft. zum >>=2. Ja, der Compiler sollte zumindest bei eingeschalteter Optimierung aus >>=2 und /=4 den gleichen Maschinencode erzeugen. Aber man muss sich ja nicht darauf verlassen, wenn man's "besser weiss". avr-gcc 3.4.1 mit OPT=S macht es (s.u.) Ist halt das Problem mit
-
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
Studio 4.12 mit GCC 3.3.1
falschen Zeile, oft sogar öffnet sich eine andere Datei.... Frage: läuft das Studio nicht mit dem GCC 3.3.1? oder sind die von mir verwedeten Optionen nicht korrekt: Compiler: avr-gcc -g -Wall -O2 -mmcu=atmega64 -c -o dateiname.o dateiname.c Linker: avr-gcc Datei1.o Datei2.o -Wl,-Map=Datei.map
Regel zur Folge, dass das Ergebnis ziemlich vom Quellcode abweicht. Wenn Du das ganze ohne Optimierung compilierst (also mit -O0), dann sollten solche Abweichungen nicht auftreten. Gruß, Michael
-
Thread
avr-gcc nutzt kein "Store Indirect and Post-Inc."
Hallo, ich verstehe gerade den avr-gcc nicht. Ich habe einen Attiny841 und möchte folgendes ausführen: [c] // highest_byte_in_value wird berechnt, ist dann 0 bis 3. switch (highest_byte_in_value) { case 3 : base64_buffer[current_buffer_element
schrieb im Beitrag #5646369: > Erst mal frischen Compiler besorgen: > http://blog.zakkemble.net/avr-gcc-builds/ Gemacht, der Code wird tatsächlich etwas schlanker. Nur das "Store Indirect and Post-Inc." wird immer noch unelegant umgangen. Compiliert habe ich hiermit: [code] avr-gcc-8.2.0-x64-linux
-
Thread
Optimale Maschinensprache
ARM v5 thumb (4) MIPS16 (5) AVR8 (6) MIPS32 (7) i86-64 Basis ist eine für die versch. Arch. gcc-compilierte bare metal Library ohne float-Gerechne (dann sähe das alles wieder anders aus).
Maschinendefinition. Mit welcher ISA/Maschinensprache sie ausgestattet sein sollte, um dem Ziel der Optimierung (Preis,Leistung,Strom,...) möglichst nahe zu kommen.
-
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
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
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
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
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
warning: differ in signedness, -fsigned-char
laß mich raten ;-)) der neue AVR GCC ;-)) Du ließt strings aus dem ROM mit unsigned char obwohl es const char sein sollte. Der aktuelle GCC meckert das an.
lcd_char (*lcd_string++); // string an LCD Ausgabe } } [/c] nu kannste [c] lcd_puts ("WIN_AVR GCC"); [/c]
-
Thread
Datentypkonvertierung uint16_t zu double
: > Compiler: ARM Yagarto Ist der nicht völlig veraltet, mit dem letzten Update von 2012 und der GCC Version 4.7.2? Von ARM selbst gibt es eine GCC Distribution der Version 6.3.1 und die wird laufend aktualisiert: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
Compiler: ARM Yagarto > Ist der nicht völlig veraltet, mit dem letzten Update von 2012 und der > GCC Version 4.7.2? Never touch a running system. :)
-
Thread
GCC ARM: writeback of base register is UNPREDICTABLE
Beitrag von "let" http://www.mikrocontroller.net/topic/91547 In der Rowley Umgebung wird bei Optimierung bekanntlich der Fehler "Warning: writeback of base register is UNPREDICTABLE" erzeugt, wenn ISR Routinen verwendet werden, die mit Schlüsselwörtern des GCC bezeichnet sind. Der erzeugte Code
Jetzt die Frage: Kann jemand, leicht verständlich sagen, wie man das Ganze umbauen muss, damit Optimierungen wieder funktionieren? Und wie sieht dann eine ISR aus, bzw wie wird sie installiert? Gruss, Christian
-
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
STM32 Eclipse+GCC Laufzeitunterschied Debug/Release
version 3.5.2 (Galileo) and CDT version 6.0.2. * Atollic ARMTools Lite, Build 10.1 - built with GCC version 4.4.1 GDB version 7.1 Newlib version 1.17.0 Testweise mit Keil probiert. Dort laufen Release und Debug korrekt.
Vorkehrungen gegen 'wegoptimieren' enthält. Diese werden von ARMs Compiler scheinbar nicht bei Optimierung verworfen. GNU-Compiler verwirft bei eingeschalteter Optimierung schon. Ansonsten: die Compileroptionen angeben, die bei "debug" bzw. "release" an den GNU Compiler übergeben werden, hilft evtl
-
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
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
Buchempfehlung GCC, Makefile & Co
zurückgeworfen sind. Sieht dann zwar etwas hübscher aus im Buch, aber das war es dann auch... Zudem wird GCC ständig weiterentwickelt. Wenn du in einem GCC-Buch was suchst zu "Transactional Memory in GCC" wirst wohl nicht viel finden, weil ein Buch zu langsam ist und schwerlich mithalten kann mit der Entwicklung
ist zu beachen: Diese Mailinglisten sind nicht für Fragen zu C oder C++ etc. sondern für Fragen zu GCC (Schalter, Optimierungen, Probleme mit configure, ...) [1] http://gcc.gnu.org/ml