-
Thread
weitere Zeigerfrage
volatile sein, bzw. auf ein volatile zeigen (wie macht man das??) um dem Compiler vor irgendwelchen Optimierungen abzuhalten. MfG Falk
ti_register_t ti_registers[] PROGMEM = { > {PORTA, "porta"}, PORTA ist kein Zeiger. > Der GCC weigert sich aber, das zu kompilieren, da der Initialisierer > nicht konstant ist ("../src/ti.c:103: error: initializer element is not > constant"). Der Fehler bezieht sich auf PORTA, DDRA und PINA
-
Thread
Multiplizieren geht schief
Wahrscheinlichkeit brauchst du ihn auch gar nicht, sondern hast vielleicht nur vergessen, die Optimierung des Compilers einzuschalten.
Überschreiben wieder auf 0 gesetzt werden, etwa wenn ein MUL verwendet wurde. Siehe ABI http://gcc.gnu.org/wiki/avr-gcc#Register_Layout > wenn der Compiler da was wegoptimiert Es ist Assembler-Code, der Compiler bekommt ihn nie zu sehen. > es scheint als ob der Fehler von ausserhalb kommt
-
Thread
überflüssiges extern?
verwenden. Was Prototypen betrifft, z.B. -Wstrict-protoypes -Wmissing-prototypes aktivieren falls GCC zum Einsatz kommt.
Funktionsdefinitionen. In C gibt es diese Möglichkeit allenfalls als Spracherweiterung, wie bspw. beim GCC.
-
Thread
USB Mass Storage + Virtual COM Port, SD Card als Bibliothek für "Arduino"-Ähnliche?
Tastern, UART basteln/zusammenklicken, d.h. in kürzester Zeit mit niedrigstem Aufwand und keinerlei Optimierung :-) Welche Hardware/IDE-Kombination (Arduino und Konsorten) bietet Bibliotheken zu diesem Zweck?
hab noch einige PIC18Fxx rumliegen, würde dir aber die PIC24/dsPIC empfehlen, da ist die Toolchain GCC basiert und die CPU ist deutlich stärker
-
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
GCC inline assembler
benutzen. Es ging ja darum das der GCC 19 Takte benötigte für eine einfache Speihceroperation die 8 Takte braucht. @Albi, Hm, wenn machbar würde ich solche Tricks eben vermeiden. Einfach um den Source übersichtlich zu halten.
r25 2077 0b6c 0895 ret [/avrasm] Scheint das man das also generalisieren kann und der GCC damit immer besseren Code erzeugt. Besonderst das letzte ASM geht manuell gecodet nicht besser zu machen. Gruß Hagen
-
Thread
Einzelne Bit in Bitfeld in for Schleife ansprechen
wir hier C++ haben, könntest du auch den [] und = Operator überladen. Nur leider liefert der AVR-GCC ja die C++ stdlib nicht mit.
/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung [c] bool outputs[13]; // einfach, schnell, ein paar Bytes "verschwendet" uint16_t outputs; // Zugriff über Bitmasken, minimaler RAM-Bedarf, etwas
-
Thread
Object Oriented Forth
Hab' vor Jahren mal eines für ein ST7735 1,8" TFT geschrieben. Hat einen Tag gedauert. Inklusive Optimierung.
Stackmaschinen mies aus. Der Punkt ist halt schlussendlich in der klassischen embedded Entwicklung der: GCC oder nicht GCC (oder dito LLVM). GCC ist aber klar auf Registermaschinen ausgelegt und 'kennt' die Forth-Denke nicht. Also bleibt praktisch gesehen Forth nur noch allenfalls fuer paralleles Multiprozessing
-
Thread
Reihenfolge der Structs im Speicher durcheinander
würfelt der Compiler mir die Stukturen beim optimieren durcheinander. Ich habe versucht die Optimierung für den Bereich auszuschalten. #pragma GCC optimize ("O0") (ARM GCC Compiler) Leider funktioniert das nicht. (Weiß nicht warum.) Ich habe auch versucht die Strukturen in eine weitere zu verpacken
ich dem Linker für einen Codeabschnitt sagen kann, das er die Variablen nicht optimieren soll? (ARM GCC)
-
Thread
Wie lange dauert ein Funktionsaufruf?
Oftmals spart das sogar Zeit. Einfach deshalb weil die Optimierung des Compilers mit kleinen Programmstücken besser klarkommt.
Funktion auslagerst und diese Funktion konsequenterweise als "static" deklarierst, dann wird zumindest GCC diesen ausgelagerten Code bei der Codeerzeugung gleich wieder einlagern und garkeine separate Funktion erzeugen.
-
Thread
Kolibri OS, vergrößerung der Community. Programmierung mit C
auf 6 Disketten a 1,44MB. Die VGA-Grafik brauchte wohl nur eine Diskette - aber da war noch was mit gcc/gdb, das brauchte 4 Disketten. https://en.wikipedia.org/wiki/MuLinux
tatsächlich lausig bis garnicht dokumentiert ist, ist das Verhalten der Compiler bezüglich der Optimierung...
-
Thread
Boost.preprocessor library
Okay dann hast du da andere Erfahrungen gemacht. Nun, wenn du dir so sicher bist dass der Fehler im GCC liegt, kann dir hier vermutlich auch keiner helfen. Nun gut, du hast ja auch keine konkrete Frage gestellt.
Im Prinzip ginge es auch mit C Mitteln ohne constexpr, dann müsste man sich aber auf die Optimierung des Compilers verlassen, dass die Berechnungen zur Compilezeit stattfinden.
-
Thread
Anfängerfrage: LED Toggle in C - ATtiny13/ATmega8
definieren, und du musst die Optimierungen an machen ( mindestens -01)
Wurst sein. Ja, dass ging aus deiner Aussage jetzt nicht so direkt hervor ob du das auch tust. >(Im GCC kann ich ja unter Symbols die Frequenz selber angeben) Wenn du das auch machst ist alles Ok.
-
Thread
Senden einer Infrarotsequenz
Ich würde rein gefühlsmäßig bei sowas auch die Array-Variante vorziehen. Dachte nur nicht, dass der GCC die 64 Bit Sachen so vermasselt. Wie gesagt, bei 32 Bit sieht es definitiv besser aus.
Sind ja keine > Rechenoperationen, die hier durchgeführt werden. Das 64Bit-Paket wurde beim AVR-GCC mit der heißen Nadel dazugestrickt, d.h. völlig ohne jegliche Optimierung. Jeder 64Bit-Operator ruft ganze Orgien von MOV/PUSH/POP und sehr lange Funktionscalls auf. Ich hab mal testweise ein
-
Thread
C -> Port Bitset
geschweiften Klammer! Dann geht dein > Beispiel auch ohne die geschweiften Klammern beim "if". bei gcc nicht nötig, da impliziert durch die {} klammer und sowieso schon alles ugly. mt
>> Immer ein "do-while(0)" um die geschweiften Klammer! > > bei gcc nicht nötig, Bei jedem C-Compiler nötig! Siehe http://c-faq.com/cpp/multistmt.html
-
Thread
m16c Complier
den NC30. Irgendwann hab ich auch mal was gelesen, das sich ein paar Leute drangemacht haben den gcc für den m16c anzupassen, was daraus geworden ist kann ich dir aber leider auch nicht sagen, hab schon lang nicht mehr nachgeschaut. Gruß Peter
An dem gcc für m16C wird wohl noch gearbeitet, aber konkrete Ergebnisse gibts da noch nicht. @Peter: Wie ist das mit Eclipse? Hört sich interessant an. Ich habe mal auf deren Seite geschaut, aber es sieht
-
Thread
Datenrekorder auf SD-Karte mit mega88
FOR A PARTICULAR PURPOSE. Compiling C: ../../Logger/MrData/spi.c avr-gcc -c -mmcu=atmega8 -I. -gdwarf-2 -DF_CPU=3686400UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./../../Logger/MrData/spi.lst -std=gnu99
alle optimierungen abdrehen
-
Thread
Beschränkung bei den Schiebebefehlen?
Ja, avr-gcc verhält sich "interessant". Er macht die Schieberei nur in 16 Bit und setzt die restlichen Bits auf den gleichen Wert wie Bit 15. Das passt zu dem von dir beschriebenen Verhalten. Eine Lösung, wie
danke dir. genau das wollte ich verhintern. interessant ist auch, das avr-gcc 0x0000000F * 0x00001000 genauso behandelt, 0x0000000F * var (wobei var gleich 0x00001000 ist) mir richtig berechnet. kenntst du zufällig den exponent befehl auswendig, sodaß ich ne zahl hoch ne zahl
-
Thread
Kleines Makro, inline asm so richtig?
ihr wisst ja selber was der compiler daraus macht... Ja, ein SBI - normalerweise. Hast du die Optimierung ausgeschaltet? Oder wofür soll das Makro sonst gut sein?
ne optimierung ist auf default 0s ((BYTE) |= (1<<(BIT)) daraus macht er mit sicherheit kein sbi... er setzt ne odermaske über ein geshiftetes bit, also minimum 2 befehle macht er daraus!
-
Thread
MPLAB IDE Lizenz Warnung
Machenschaften. Wie Lehrmann Michael auch schon aufführte werden bei der LITE-Version bestimmte OPtimierungen eingeschränkt. Falls jemand noch was Produktives weiß bitte posten, ansonsten wende ich mich mit meinem Problem mal an ein nicht so AVR-lastiges Forum. Gruß Michl
eine Möglichkeit, wie man an einen vollwertigen C30-Compiler kommen kann. Da der C30 Compiler ein GCC Compiler ist, gibts den Quellcode auf der Microchip-Seite frei zum Runterladen. Im Netzt gibts genug anleitungen, wie man den Quellcode compiliert (der muss vorher gepatcht werden). Microchip verlangt
-
Thread
Aus Programm heraus in den Bootloader springen
Naja, ich bin bei mir knapp an der 64kB-Grenze. Gut, wenn ich beim Kompilieren Optimierungen einschalte wird es auch weniger. Respekt, wenn du in der Regel mit nem AtMega8 auskommst. Wieviele Zeilen C-code haben dann deine Programme so? Wäre es denn arg schwer, den bootloader so
ich habe den Ansatz mit dem Sprung in den Bootloader weiterverfolgt und dabei einen Thread im gcc Forum gefunden: http://www.mikrocontroller.net/forum/read-2-416971.html da ich das auch mit gcc mache und Ergebnisse nicht allgemeingültig sind poste ich meine Lösung in den gcc Thread.
-
Thread
string buffer löschen
Parametern? Denn diese liegen auf dem Stack. Alle Variable global zu machen hat auch nachteile in der optimierung. Sollte man also nicht machen.
Variablen können in Registern gehalten werden, was >Geschwindigkeitsvorteile bringt. Da wir uns hier im GCC-Forum befinden, müsste der Compiler grundsätzlich von Registern ausgehen, heutzutage. Vor nicht alzu langer Zeit sah das anders aus.
-
Thread
C++17, alignment-check template Interface reduzierbar?
Ich kann das ganze so noch nicht mal mit dem gcc9.2 auf einem x86-64 Rechner kompilieren. error: size of array is not an integral constant-expression char for_sizeof[(char *)&(TV::value.*MPtr) - (char *)&TV::value]; Ich würde dir aber aus
M.K. B. schrieb im Beitrag #6177085: > Ich kann das ganze so noch nicht mal mit dem gcc9.2 auf einem > x86-64 > Rechner kompilieren. > > error: size of array is not an integral constant-expression > char for_sizeof[(char *)&(TV::value.*MPtr) - (char *)&TV::value]; > > Ich würde
-
Thread
Warum dauert Dateisuche eigentlich so lange?
lahmgelegt, keine Ahnung was das Filesystem da war. Bei mir (Win10) etwas läuft der clang-cl und der gcc Compiler im Vergleich zum MS cl deutlich langsamer (2-3x). Ich weiss aber, das der unter Linux deutlich schneller ist. Offensichtlich liegt es an irgendwelchen libc Optimierungen, die unter Windows
Dateien unter Windows zumindest nicht 100%ig. > Bei mir (Win10) etwas läuft der clang-cl und der gcc Compiler im > Vergleich zum MS cl deutlich langsamer (2-3x). Ich weiss aber, das der > unter Linux deutlich schneller ist. Offensichtlich liegt es an > irgendwelchen libc Optimierungen, die unter
-
Thread
Projekt Schaufelraddampfer
schreiben, wie ich will und muss mich nicht dem C Compiler ausliefern. Hab' mir mal Eclipse und den AVR GCC installiert, das ist keine schlechte Programmierumgebung, aber um anzufangen brauchst Du erstens Durchsetzungs- und auch Leidensbereitschaft, zweitens ist meiner Meinung nach im GCC die Anwendung von
Und das ist das eigentlich Schöne: Ich hab' die Wahl. Die hab' ich mit den Inline Verrenkungen des GCC nicht wirklich.
-
Thread
optimale avr-gcc compiler optionen
Hallo avr-gcc Entwickler! welche avr-gcc compiler optionen verwendet ihr in einem Makefile? Mein Fragestellung war, wie ich den cocoOS "cooperative task scheduler" - http://www.cocoos.net/ so verwenden kann
Uwe S. schrieb im Beitrag #2039842: > Hallo avr-gcc Entwickler! > > welche avr-gcc compiler optionen verwendet ihr in einem Makefile? > > Mein Fragestellung war, wie ich den cocoOS "cooperative task scheduler" > - http://www.cocoos.net/ so verwenden
-
Thread
Overhead Funktionsaufruf über Pointer
zu 15% mehr Geschwindigkeit bekommen bei ca. 95% Codegröße. Übrigens, ein e200z4 (PowerPC VLE, GCC 4.8.0) ist bei gleicher Taktfrequenz ca. 1,6x so schnell (bei 1,75-facher Codegröße). Jörg
ineffizienter machen? Passieren kann das m.E. eigentlich nur aus zwei Gründen: Du hast einen Bug gefunden oder gcc kennt deine Cache-Grössen nicht (oder eben falsch). Schon mal mit l1-cache-size=xxx gespielt?
-
Thread
String Übergabe an asm-funktion
nach dem Aufruf der Funktion befindet er sich in Registern r24 und r25. Y-Pointer (r28,r29) wird vom gcc verwendet, also habe ich versucht die Adresse von data in X-Pointer zu laden: mov 26, 24 mov 27, 25 Und dann so zu speichern(work = r20): in work, ADCH /*Hier haengt sich das Programm auf*/ st
) Ja, das müsste funktionieren. > >>Eine richtige Idee, warum... > Ja, eben warum benutzt gcc doch diesen X-Pointer, in der asm Ausgabe > die mit -S erzeugt wird kommt er jedenfalls nicht vor. Ich glaube, X nimmt GCC nur selten. Vorzugsweise nimmt er Z. > >>was ist an dieser Funktion
-
Thread
[ARM / Cortex-M0(+)] delay-Funktionen "avr-libc style"
das Ergebnis mit "inline": Danke fürs Testen! Ein bisschen mysteriös ist es schon, dass der GCC den Gleitkommaausdruck (wie er aus dem Präprozessor dann rausfällt) ohne Optimierung trotzdem zur Compilezeit ausrechnet, die inline-Funktion jedoch nicht. Naja, lässt sich dann wohl nicht ändern
nehmen. Ich hatte übrigens gar nicht damit gerechnet, dass der Compiler diese Ausdrücke ohne Optimierung jemals zur Compilezeit umsetzt, daher hatte ich den Fall „Optimierung ist aus“ gedanklich für so ein Vorhaben ausgeklammert. (Wer nicht optimiert, dem ist die Ausführungszeit ja sowieso egal
-
Thread
DSPs mit viel RAM samplen
Hersteller nicht unbedingt billig sind! Die Leute bei Analog Devices benutzen glaub auch einen GCC für Ihre DSPs. Ich weiß aber nicht, ob der auch frei zu bekommen ist. Diverse Optimierungen lass sich die meisten Hersteller gut bezahlen. Die andere Quelle, die mir noch einfällt ist Texas Instruments
Hi, der GCC fuer den Blackfin bzw. den SHARC von Analog Devices ist kostenlos (jeder GCC muss kostenlos sein, dafuer gibt's ja die Gnu Public License). Die offizielle Distribution kommt von blackfin.uclinux.org
-
Thread
Atmel oder PIC
Debugger etc... ohne irgendwelche Demo/Eval Einschränkungen. Du kannst aber auch mit Eclipse + AvrGcc (C-Compiler) arbeiten, es gibt ein AVR-Plugin für Eclipse..
etc... ohne > irgendwelche Demo/Eval Einschränkungen. > > Du kannst aber auch mit Eclipse + AvrGcc (C-Compiler) arbeiten, es gibt > ein AVR-Plugin für Eclipse.. MPLAB, die Einschränkungen des Compilers (gcc...) im Eval-Modus (nicht alle Optimierungen) sind in vielen Fälle vernachlässigbar. MPLAB
-
Thread
AVR gcc mit 64-Bit-Werte mit int64_t
compilieren kommen weder Fehler noch Warnhinweise. Wo liegt das Problem. Habe auch schon die Compiler-Optimierungen durchprobiert. Gruß Alexander
referenzierten Quellen — die zu deiner Toolchain-Distribution passen — besorgen. Die Datei liegt dort in ./gcc/libgcc2.c Für die aktuelle, offizielle Version 4.7: http://gcc.gnu.org/viewcvs/trunk/gcc/libgcc2.c?content-type=text%2Fplain&view=co Zur libgcc gehort jedoch mehr als nur diese eine Datei.
-
Thread
GCC generiert 2 Jumptables bei Switch
richtig gefunden. Ich hab in der main() eine Schleife in der eine Switch-Anweisung steht. Der avr-gcc (GCC) 4.1.3 20070724 generiert daraus 2 Jumptables. Das ganze wird für nen Atmega8 kompiliert Hier 3 Ausschnitte [c] uint16_t t = ...; switch (t) { case 0x01: set_act_date(); break
unabhängig von der Anzahl der unterschiedlichen Werte von t, wenn der Compiler bei Switches keine Optimierung durch berechnete Sprünge kann.
-
Thread
Was macht ein AVR bei einer Division durch Null?
-Kompiler gefallen, wenn man ihm einen Quelltext > gibt, der eine Division durch Null erzeugt? GCC gibt eine Warnung. Wenn er es merkt.
http://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/config/avr/lib1funcs.S?content-type=text%2Fplain&view=co Für die nicht zwingend saturierenden Fixed-Point Divisionen sind m.W. ebenfalls so, daß diese auf den Maximal
-
Thread
WinAVR Hexfiles corrupt?
Hi Georg, Du hast vollkommen recht, nach der Optimierung bleibt von dem Blinken nicht mehr viel übrig... Dank Dir für die schnelle Antwort. Aber seit wann optimiert GCC denn schon so? Als ich die Programme geschrieben hab (gut ok ist auch schon anderthalb
Damals hat's funktioniert, war aber schon inkorrekt. Seit Version 4 ist GCC nochmal was aggressiver beim Optimieren, weil durch die interne SSA-Darstellung einige neue Optimierungsalgorithmen anwendbar sind. Zudem war früher mal in GCC eingebaut, daß leere Schleifen nicht
-
Thread
AVR-GCC: Disassembler-Ansicht unvollständig
Ich fange gerade an mein ATMega32 mit AVRStudio in Verbindung mit WinAVR zu programmieren. Als Optimierung ist -Os eingestellt. Wenn ich nun meinen Quellcode compiliere sagt gcc, dass der Code 906 Bytes groß ist. Wenn ich jetzt in die Disassembly Ansicht gehe, geht mein Code aber nur bis 0x1C4 das würde
Funktion lokal benutzen darf. Auch bei Risen-IR-Funktionen habe ich es übrigens nie geschafft, dass gcc mehr als 18 Register pusht. Gruß, Stefan
-
Thread
Problem mit STM32F103 und RAM-Größe
erstmal schauen, was er mit Compiler-Optionen erreichen kann. Da helfen zum Beispiel entsprechende Optimierung-Flags wie zum Beispiel -Os. Auch FLTO (in Verbindung mit gcc) kann einiges an RAM-Bedarf optimieren. Natürlich ist es sinnvoll, String-Konstanten auch als solche zu definieren, das wurde oben
Dazu kommt das der gcc den M0 grob vernachlässigt und deutlich schlechter optimiert als bei >= M3. Der Keil Compiler holt da mehr raus, bis 32k Codesize lief der auch in der kostenlosen Testversion.
-
Thread
Präprozessor: Variable Anzahl von "nop"s?
Instruktionen je nach Prozessortakt konfigurierbar >machen. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 MFG Falk
incunabulum) >1 µs ist hier sichtbar langsamer verglichen mit 6 nop-Commands = ca. 500 >ns. Optimierung eingeschaltet? >Daher meine Idee, mir ein entsprechendes Makro zu schreiben.... Die gibt es schon, siehe Doku der libc. MFG Falk
-
Thread
Unbenutzte Funktionen beim kompilieren
Hallo Ich benutzte avr-g++ und avr-gcc zum Kompilieren und avrdude um Programme auf einen atmega328p zu übertragen (auf einem Arduino Uno, aber ohne Arduino-IDE). 1. Ich laß, dass beim Kompilieren alle Funktionen die in einer Headerdatei
Variablen sowie globale Variablen bereits entfernt. Das geht manchmal auch zu weit! Drum kennt GCC das __attribute__((used))
-
Thread
STM32 - CoreMark
Interessant wäre auch der Coremark für -Og (debuggerfreundliche Optimierung), die es seit 4.8 gibt.
_; -I.; folgendes Ergebnis: STM32F407VG GCC4.8.3 -Og text 13892 data 44 bss 8220 168 MHz 5WS-I-D-P 258,397933 CoreMark 1,54 CoreMark/MHz Zum Vergleich: STM32F407VG GCC4.8.3 -O3 17648 44 8220 168
-
Thread
rfm12lib lässt sich nicht coimpilieren
Hallo , ich versuche in Codeblock 10.5 mit dem avr-gcc 4.3.2 die RFM12lib (http://www.das-labor.org/wiki/RFM12_library) zu compilieren und bekomme bei folgender Zeile : [c] //non-inlined version of rfm12_data //warning: without the attribute, gcc will
Aber wie gesagt, ich denke der Compiler kennt die C99 uintxx_t Typen nicht...also gcc mit '-std=c99' aufrufen oder <stdint.h> einbinden...
-
Thread
KS0108 GLCD Routinen
avr-gcc -v sagt mir: gcc version 3.3 20030512 (prerelease)
gcc version 3.3.1 muss wohl aber daran liegen. in meiner avr-gcc dokumentation ist PRG_RDB() deprecated und man soll statt dessen pgm_read_byte() verwenden
-
Thread
GCC: Variable wird trotz 'KEEP' im Linkerscript wegoptimiert?
Hallo, für die Programmierung eines STM32 verwende ich Atollic Truestudio, also GCC drunterliegend und bastle mir gerade die Option Bytes direkt ins ELF bzw. HEX File. Hierfür habe ich das Linkerscript wie folgt modifiziert: [c] ... MEMORY { ... OPT_BYTES (r) : ORIGIN
belegen muss, wenn ich doch > im Linkerscript die Sektionen schon mit KEEP markiert habe Davon weiß GCC aber nix. "used" wirkt auf Compiler-Ebene. "KEEP" wirkt auf Linker-Ebene. Wenn globale Optimierungen aktiviert sind, dann kann GCC nicht referenzierte Objekte / Funktionen entsorgen. Gleiches
-
Thread
Atmel Studio 6 - Buildproblem
funktioniert auf Eclipse ja nicht aber auf Atmel Studio >6 :( Dann hattest du bei Eclipse evtl. die Optimierung nicht eingeschaltet, beim AVR STudio aber schon. Und bumm fliegen einem Warteschleifen die für den Compiler keinen Sinn machen um die Ohren. Wegoptimiert. Code zeigen!
auf Eclipse ja nicht aber auf Atmel Studio >>6 :( > > Dann hattest du bei Eclipse evtl. die Optimierung nicht > eingeschaltet, beim AVR STudio aber schon. Und bumm fliegen > einem Warteschleifen die für den Compiler keinen Sinn machen > um die Ohren. Wegoptimiert. > > Code zeigen! das ist
-
Thread
pgmspace.h bringt AVR Studio zum Absturz?!?
> int main(void) { while(1){} } Also echt nix Spezielles. AVR Studio Version 4.12 + AVR-GCC Version 1.4.4 verwende ich, sonst nix Spezielles. Die build Datei wurde beim Standard belassen (ATMEGA32, -o0 Optimierung, 16 MHz als Angabe für Taktfrequenz). HALLO? Bin ich blöd? PS: Notfalls versuche ich AVR Studio und AVR-GCC zu aktualisieren, aber das Problem wird mir nicht klar.
-
Thread
-Wignored-qualifiers
: type qualifiers ignored on function return type [-Wignored-qualifiers] [/CODE] Unter http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html finde ich dazu die Erklärung [code] Warn if the return type of a function has a type qualifier such as const. For ISO C such a type qualifier has no effect
sondern nur named casts, also reinterpret_cast, static_cast, dynamic_cast, const_cast ... Dafür beim GCC mit -Werror=old-style-cast compilieren ;-)
-
Thread
LCD Ansteuerung, was tun
Nabend, habe den Beispielcode von http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung verwendet und auch so die Verdrahtung vorgenommen. Debuggen funktioniert einwandfrei. Jedoch wird mir immer noch kein Test sondern nur viele dunkle Balken in der ersten
initialisiert. Der Compiler meckert nicht zufällig über eine nicht definierte F_CPU oder fehlende Optimierung für die delays? Poste mal deinen kompletten Code. Die RW Leitung liegt auch wirklich an GND?
-
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
Problem bei Erstellung eines Arrays
Hallo zusammen, ich arbeite mit einem STM32F4 und CooCox (mit neuster GCC Version). Ich habe ein etwas größeres Programm (hier die gekürzte Fassung!!!) geschrieben, in dem ich ein Array V_f[16] innerhalb einer Funktion erstelle. [c]void estimator_qmethod(float a1, float
funktioniert das wie gewohnt. Beim Kompilieren erhalte ich keine Warnungen. Ich habe keinerlei Code-Optimierungen an. Hat jemand eine Idee woran das liegen könnte? Falls ihr mehr Informationen braucht, stelle ich die gerne bereit! MfG Peter
-
Thread
AVR C Projekt mit Assembler-Code LCD
Da steht es.. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial AVR-GCC-Tutorial Wenn du auf Optimierung bist und ein Grafik LCD (ohne Display, das sagt schon das D aus) solltest du die eingebettete ASM Variante nehmen. Wenn du aber nur ein pobloges
Hallo Jens hab ich zwar noch nie gemacht aber im AVR-GCC-Tutorial steht eine ziemlich ausführliche Anleitung. Sebastian