-
Thread
Umstieg Windows -> Linux sinnvoll? Nicht für den DAU.
passend zu konfigurieren, um so unnötigen Ballast zu vermeiden bzw. wie oben gezeigt bestimmte Optimierungen einzuschalten. Grüße, Chris
einsetzen, wenn ich dafür auch noch Geld bekommen > würde). (BTW: weiss jemand eine gute IDE, wo ich den GCC und GDB drin > integrieren kann?) QtCreator macht eigentlich alles richtig. Mit C++ geschrieben, perfekte GDB und GCC Integration. Läuft auf Linux, Windows, Mac überall wo Qt halt läuft. Und nein
-
Thread
AVR+SD-Card: SD-Card legt manches mal 0.13s "pausen" ein
SPI Bus so hoch wie möglich sein um möglichst rasch zu sein - und nicht nur <50% der Zeit (code vom gcc nach vorgaben aus dem AVR manual). Ich werde versuchen diesen code-teil einmal via assembler so zu optimieren um auf fast 100% duty cycle auf SCK zu kommen. Dann werden wir sehen wie sich das ganze
> Leider muss ich feststellen, daß sich diese Optimierung sich nicht auf > die "Latenzen" der SD-Karte auswirkt. Das war laut Spezifikation auf sdcard.org nicht anders zu erwarten. > Class10 Karte Kartenklassen wirken sich nicht auf den SPI Modus
-
Thread
sbi und cbi in C
Optimierung einschalten. Bei einigen Ports (z.B. PORTF) geht cbi, sbi nicht mehr.
. Bei dem selben Controller und der selben Optimierungs-Einstellung? Kann ich nur schwer glauben.
-
Thread
AVR GCC Timer-irqs <-> main Probleme bei Variablen
Hallo, ich verstehe die Welt nicht mehr, daher, please help. (Ich verwende AVR Studion 4 mit GNU GCC Compiler für AVR Mega; Sprache: Standard "C") Problem: Im hauptprogramm setze ich nach der Initialisierung in der Hauptprogrammschleife sekündlich eine global deklarierte Steuervariable "OneWireFlag
bzw. ein Optimierungsproblem??? Hat einer eine Idee? Mir fehlen dazu die Erfahrungen mit dem GNU GCC. Danke. So, die Programmschipsel hänge ich mal an: Ausschnitt aus dem Hauptprogramm: Aufruf der Subroutine [c] crc=OneWire_ReadRom(); [/c] Die Subroutine (Testversion) [c] U8 OneWire_ReadRom
-
Thread
C Programm zu langsam
- Alternativ manuelles Loop-unrolling etwas mehr bringen - Vielleicht auch mal die Code-Optimierung auf max. einstellen.
der Compiler, wenn Optimierungen einschaltet sind.
-
Thread
Long in char Array umwandeln
sich aus irgendwelchen anderen Umständen ergibt, auch wenn das sich je nach Compiler-Parametern, Optimierung oder anderen Dingen unterschiedlich verhält. Der Compiler-Bauer muß sich schlicht überhaupt nicht drum kümmern und nicht mal drüber nachdenken, was denn in dem Fall passiert. Johann L. schrieb
memcpy(b, a, sizeof a); [/C] Das dürfte aus ISO-C-Sicht die sauberste Variante sein und beim gcc auch nicht langsamer oder umständlicher als irgendwelche union-Verrenkungen oder Pointer-Castereien.
-
Thread
if-Abfragen verpönt?
ersten Moment könnte man denken, dass das hoffnungslos überkompliziert ist. Vorausgesetzt, size ist GCC wahrend der Kompilierung als Konstant bekannt, dann wird GCC diese Funktion jedoch inlinen und automatisch und korrekt Bitmaskierung oder while-Schleife wählen. Mit etwas mehr Trickserei kann man dann
Sam P. schrieb im Beitrag #2889622: > > Nur mal am Rande, für diejenigen, die GCC's Optimierungsfähigkeiten > nicht kennen: Interessiert eigentlich gar nicht. Nicht alles wird mit dem GCC gemacht und wer portablen schnellen Code schreiben will der verläßt sich nicht auf so etwas
-
Thread
Compilter Optimierungen für bestimmte Codeabschnitte deaktivieren
/gcc-4.7.2/gcc/Function-Attributes.html#Function-Attributes
Ich nehme mal an, daß du von GCC sprichst. GCC hat ab Version 4.4 Pragmas mit denen man funktionsgenau die Optimierung steuern kann, man kann die Optimierungsoptionen auch als Funktionsattribute anhängen: http://gcc.gnu.org/onlinedocs
-
Thread
Debug Optionen -G mit Optimierungen -O
Meine Erfahrung ist, dass -g3 mit -O3 bei heutigen gcc-Versionen einwandfrei funktioniert, aber der Nutzwert aufgrund der Optimierungen begrenzt ist. Da werden einzelne Assemblerbefehle den wildesten Quelltextzeilen zugeordnet und scheinbar chaotisch hin
Wie Jörg schon schrieb wird GCC *niemals* die Codeerzeugung vom gewählten Debug-Level oder -Format abhängig machen -- falls doch, ist das ein GCC-Bug. Neurer GCC-Versionen unterstützen -Og, was nur Optimierungen einschaltet, die
-
Thread
sprintf braucht 16ms Zeit kann das sein?
Beitrag #2886694: > Ach so ja: Ich programmiere über AtmelStudio6. Hast du denn nun auch die Optimierung eingeschaltet?
werden also wo ganz anders verbraten. Das sprintf ist völlig unschuldig. Oder hast Du etwa die Optimierung ausgeschaltet? Die muß natürlich -Os sein. Peter
-
Thread
Was ist modernes C? Gesperrt
linkt dynamisch? MS verwendet üblicherweise DLLs als Runtime Libs für die normalen Libfunktionen. GCC meist nicht.
Hat viele C++/C#/whatever Komfortfunktionen und wird vom Compiler in C umgebaut, womit sich dann der GCC befassen darf.
-
Thread
die Betty-Fernbedienung von Pollin als ARM-Eval Board
Segmentänderung für den Startup (bisher .text, jetzt .text.startup) in den asm-Dateien angepasst. 2. gcc Umgebung für BettyApp hier wurden für die neuen APIs die .global Deklarationen in BettyApiGcc.asm ergänzt. Gruß Siegfried
aktuellste Version? - Spricht etwas dagegen, den Ansatz mittels Batch-Dateien zu entfernen, um damit die GCC-basierte Kompilierung auf einen Weg zu reduzieren? Zwei Varianten ARM/GCC sind die Mühe sicherlich wert, aber zwei Varianten im GCC-Bereich bergen die Gefahr, dass es auseinander läuft ohne einen besonderen
-
Thread
Wie effizient arbeiten PCs?
Beispiele: Flash, mehrere Websites parallel, HTML 5 mit mittlerweile 3D Javascript Grafiksachen. 3. Optimierung: früher wurde mehr Software wirklich in C hard gecoded. Heute nimmt man vermehrt auch interpretierte Sprachen, da sie einfach flexibler sind (z.B. beim Debuggen oder um systemübergreifend sein zu
einfach Leute die glauben, je komplexer ein System ist um so besser, und dass sich Komplexität zur Optimierung immer lohnt. Somit werden die Programme teilweise 10 mal so groß, was jede Optimierung wieder eliminiert. Lies mal "The Art of Unix Programming" (gibts auch online) und Du liest eine informierte
-
Thread
PIC32 RAM löschen
Holli schrieb im Beitrag #2879842: > - Er bietet diverse Optionen zur Code Optimierung Das wäre m. E. das einzige wirklich interessante, da der freie mips-elf-gcc im Vergleich zu den anderen, vom GCC bedienten Plattformen relativ große Kompilate erzeugt.
viel, wenn dahinter tatsächlich der gcc stecken sollte.
-
Thread
Goertzel Algorithmus funktioniert nicht
volatile' markiert? stm schrieb im Beitrag #2879205: > hm bist du dir da sicher? In AVR-Studio mit GCC habe ich mal das Problem > gehabt, dass er das nicht gemacht hat. Ich musste da die Divisionen > explizit als Shift-Operationen darstellen!. Ja das macht der GCC nicht nur bei AVRs, sondern auch bei ARM, x86...... Man muss dazu aber auch die Optimierungen anschalten, '-Os' oder '-O2'. Es gibt übrigens noch ganze anderer Optimierungen, die der Compiler macht, die würde man als Mensch nur mit viel viel Aufwand hin bekommen - z.B. Optimierung der ARM
-
Thread
Was macht der Compiler bei Rechnungen mit defines?
auch gar nicht in > der Frage. Sondern ob der Kompiler (10/2) ausrechnet, oder nicht. Ja (bei GCC). > Oder macht das auch der Präprozessor Nein. Der macht Textersatz. Ist "10/2" der gleiche Text wie "5"? Um das Prä-Compilat erzeugen (bzw. nicht löschen zu lassen) geht mit GCC etwa gcc -g3 -save-temps main.c
-
Thread
avr-gcc: implizite Wertebereichserweiterung bei Int-Operationen
keinem Overflow ausmacht, dann hat der Compiler einen Fehler gemacht. Denn nach einer derartigen Optimierung muss EXAKT das gleiche rauskommen (innerhalb dessen, was durch die Sprache definiert wird), wie ohne Optimierung. Und das beinhaltet auch Overflows. > Was muss wirklich sein (casts) Geh deine
darstellen, kann der Compiler bei der Optimierung einfach so tun, als ob der Überlauf nicht stattfindet. Es darf also was anderes (oder sogar beliebiges) dabei herauskommen. Z.b. macht gcc aus sowas: [c] int wrap(int a) { return (a + 1
-
Thread
stm32F4Discovery mit Coocox Beispielen und Quickstart
arm-none-eabi-gcc: error: unrecognized command line option '-Wl' BUILD FAILED
Zu 1. ja, es ist eine freie IDE, der Compiler GCC-Toolchain auch.
-
Thread
STM32F4 GCC erzeugt kein DSP
: 32 ± (32 x 32) = 32 MLA, MLS Was läuft hier falsch? Was muss Ich anders machen? Oder ist der GCC derzeit nicht in der Lage DSP zu erzeugen? Grüße vom Bodensee (es regnet), Jan
für den entscheidenden Hinweis. Hab mich in den ganzen Dokus total verannt und war kurz davor den gcc auszuchecken um zu gucken was der so treibt. Grüße vom Bodensee, Jan
-
Thread
If-Phaenomen
Guten morgen! Schalte mal die Compiler-Optimierungen aus und probier nochmal. Gruß Martin
klappt es auch. Weitere Møglichkeiten findest du hier: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Zugriff_auf_IO-Ports.
-
Thread
sun-tracking mit mikrocontroller
da es nur ein Anfängerkurs war und die Zeit wie immer sehr knapp). Die Vermutung war, das die Optimierung irgendwo die Timings für die Displayansteuerung verhaut. Gruß Kai PS: Wir haben das AVR Studio 5 verwendet.
Kai S. schrieb im Beitrag #2869493: > Vermutung war, das die Optimierung irgendwo die Timings für die > Displayansteuerung verhaut. Die Vermutung ist eher, dass euer C derart mies war. Nichts für ungut.
-
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
Ansi C - Probleme mit Pointer
Kann nicht ernst gemeint sein. Aha, da sieht man mal, wieviel Ahnung du von C hast: [pre] $ gcc -c guenni.c guenni.c:1:1: error: unknown type name ‘inv’ guenni.c: In function ‘main’: guenni.c:3:6: warning: incompatible implicit declaration of built-in function ‘scanf’ [enabled by default]
noch gemacht, weil GLSL noch nicht wirklich praxistauglich war zu der Zeit. Das war Low-Level-Optimierung vom feinsten, Feilschen um jedes Bit und jede Instruktion. Und es war nötig, es lief gerade so eben, total am Limit der damaligen Standardhardware. Heute sehe ich meine eigenen Programme, und sie
-
Thread
Interrupt Fehlerquellen - FIFO Buffer
nicht aber immer wenn ich was mit ner schleife probiere wird das wegoptimiert, auch wenn ich die Optimierung versuche auszuschalten. Wie wird das sauber gemacht? Chrys
Digital umsteigen aber hab noch nie etwas mit solchen CPU's gemacht. Kann da warscheinlich nicht mit avr-gcc draufschreiben oder? Konzept ändern? wenn du irgendeine gute Idee hast hör ich gern zu. Ich hab ziemlich lange darüber nachgedacht und intensiv recherche betrieben und fand einen FIFO-Buffer die
-
Thread
Problem mit avr-gcc und Optimierung
Hallo, die Funktionen in der angehängte Datei werden vom Hauptprogramm aufgerufen (erst Init, und dann die anderen zyklisch). Compiliere ich das ganze mit -O2 landen beim Aufruf von BmpInit() max 9 Bit in den einzelnen Feldern von _C[]. Verwende ich dagegen eine andere Optimierungsstufe, schreibe: [c]volatile uint16_t _C[MS561101BA_PROM_REG_COUNT];[/c] oder greife innerhalb der Funktion auf _C[] zu, wie zB im auskommentierten Teil, funktioniert alles wie es soll. Ich compiliere mit [code]avr-gcc -c -mmcu=atmega644p -I. -gstabs -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
-
Thread
GCC Präprozessor macro '__FILE__' abkürzen
Da würd ich eher mich in der gcc-help@gcc.gnu.org Mailing-Liste anmelden und dann dort fragen. http://gcc.gnu.org/lists.html Falls es nicht geht — absehbar — dann ist __FILENAME__ vielleicht eine sinnvolle Erweiterung. Gibt
An gcc bzw. __FILE__ liegt es nicht: [code] leo@cb:/tmp$ cat file.c const char *s = __FILE__; leo@cb:/tmp$ gcc -E file.c # 1 "file.c" # 1 "<command-line>" # 1 "file.c" const char *s = "file.c";
-
Thread
AVR asm jmp problem
abgelegt. D.h. für OUT bzw. STS müsste das schon richtig sein und STORE kommt damit zurecht. (Und der gcc arbeitet mit den Ports erst mal nur über Speicherzugriffe. Die Umsetzung einiger STS auf OUT geschieht meines Wissens erst ziemlich spät in der Codegenerierung, und ist eher als Teil einer Optimierung
dem Assembler habe ich noch vergessen zu erwähnen, ich arbeite unter Linux und verwende dabei avr-gcc und avrdude um das Programm zu laden. Die Fuse-bits sind folgendermassen gesetzt: low 0xe7 high 0xdf extended 0x00 lock 0x2f Weiter habe ich den Vorschlag von Karl Heinz Buchegger umgesetzt
-
Thread
Variable ändert Wert bei Portzugriff
Also Speicher >= 100% ergibt immer komische Effekte. Hat es einen teiferen Sinn, dass Du die Optimierung ausschaltest?
rausgelöscht habe. Im Prinzip ist ja ein Portregister auch nur ein Bereich im Speicher, das der gcc den überschreibt obwohl er es nicht tun sollte?
-
Thread
avr-gcc - unnützer Assembler-code?
Programmieranfänger mit reinem Assembler oft nicht so kompakt hinbekommen hätte. Nimm bitte die neueste GCC-Version dafür, Johann hat da noch einiges an Mikro-Optimierungen im AVR-Bereich nachgezogen in letzter Zeit.
nicht alles bis zur Trivialität weggestrichen wird. > Nimm bitte die neueste GCC-Version dafür, Johann hat da noch einiges > an Mikro-Optimierungen im AVR-Bereich nachgezogen in letzter Zeit. Sowie ich das verstehe, geht es darum, dem Compiler bei der Arbeit zuzuschauen und
-
Thread
ARM: kompliziert?
der CoIDE ist ein link der es beschreibt. Download: Note: This version has not integrated GCC compiler. Before using CoIDE, you need to set GCC Toolchain first. Click here to see how to set. http://www.coocox.org/CoIDE/Compiler_Settings.html Wenn man denn gar nichts tun will sollte man
anders wie beim SDCC. Die Toolchain beim 32F4 ist im einfachsten Fall so simpel wie beim SDCC. GCC .. kompiliert .c Datei in Objectfile .o GCC .. linked ein oder mehrere .o Dateien in ein .bin Dazu gibt es ein Tool von ST mit dem man die Datei flashen kann. Das mit dem Makefile ist kein
-
Thread
PIC läuft durch String viel zu langsam
ändern. Hoffe das das bei deinem PIC Compiler so ist. Zumindestens ist das der normalfall für den gcc.
topic/269480 Einfach volatile vor die char-Array und vor int count=0; und schon gehts... Optimierung steht zwar schon auf none aber na gut...
-
Thread
China SUPER Bauteile-Schnäppchen Thread
sehr bequem und ich kaufe halt je nach Bedarf die Auffüllpackungen nach. Da würde die Zeit für Optimierungen vermutlich mehr kosten als das simple nachbestellen. Oder täusche ich mich da?
den Abmessungen her halb so großes JPG gemacht (und 70% Komprimierung). Sonst hab ich keinerlei Optimierungen / Anpassungen vorgenommen.
-
Thread
Java: Übergabeparameter wie in C++ beeinflussbar?
schrieb im Beitrag #2831251: >> Eigentlich nicht. >> Das steht eigentlich > > Was nur eine Optimierung für kleine Zahlen ist. Hab ich zuerst auch gedacht. Dem ist aber nicht so. >> Programmierer dann doch verwundert die Augen gerieben > > Wieso? Es folgt *alles* den ganz normalen Java Regeln
?"true":"false"); printf("n2 == n3? : %s\n", (n2 == n3)?"true":"false"); }[/c] Ausgabe:[pre]$ gcc cexample.c $ ./a.out n1 = 10 n2 = 10 n3 = 10 n1 == n2? : false n2 == n3? : true[/pre]Also ist C genauso unlogisch wie Java ;-)
-
Thread
Verständnisfrage Application Note AVR221 PID Controller
verwendet werden, als wären sie mit volatile deklariert oder es wird einfach nicht mit eingeschalteter Optimierung getestet.
ausserhalb eines source-Files gar nichts zu tun. C als Sprache kennt das Konzept "Interrupt" nicht, und gcc als C-Sprach-konformer Compiler daher auch nicht. Für den gcc wird eine ISR nie aufgerufen, weil kein Programmpfad die jemals aufruft. Daher erkennt der gcc auch nicht, daß die ISR Variablen verändert
-
Thread
WinAVR Compiler-Optimierung
Optimierungsstufe -O3. Wie kann das sein? Gibt es eigentlich bald mal ein Update vom WinAVR? Ist AVR-GCC unter Linux besser?
. Die gleicher Version vom GCC liefert unter windows genau das gleiche Ergbniss wie unter linux.
-
Thread
GCC cross compile / libgcc.a verweist in leeren speicher bereich
befehle weiter ein sprungbefehl und der zeigt ins leere. WARUM???? Ich habe diese Probleme mit dem GCC-4.6.3, GCC-4.7.0 und GCC-4.7.1 Was muss ich ändern? Die libgcc liegt als static vor "libgcc.a" Wenn ich den GCC-4.6.3 von codesourcery verwende gibt es kein Problem. Die Makefile und den linkerskript
Möglicherweise hat Dein eigenerzeugter Compiler andere arch- und cpu defaults wie der Codesourcery. GCC-Manual sollte Auskunft geben. Was sagt $ xxx-gcc -v? Bei CS kommt da: arm-none-eabi-gcc -v Using built-in specs. COLLECT_GCC=arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/usr/local/CodeSourcery
-
Thread
Frage zu selbstgeschriebener Funktion - Laufzeit gegenüber Compiler-Variante
hast du wenigsten die Optimierung eingeschaltet? das Problem könnte auch sein das du eine funktion für beides hast. Wenn du es in 2 funktionen zerlegst, dann müsste es schneller sein weil die vergleiche wegfallen.
Mal so nebenbei - arbeitet jemand mit IAR und kann mir sagen, wie ich die Optimierungen einschalte? Oder wie ich einen Release-Build mache?
-
Thread
IRSND läuft nicht (richtig)
c:\program files\atmel\avr studio 5.1\extensions\atmel\avrgcc\3.3.1.27\avrtoolchain\bin\../lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h(89,3): #warning "F_CPU not defined for <util/delay.h>" Ich habe dann mal in delay.h nachgeschaut: #ifndef F_CPU /* prevent compiler error by supplying
Ausserdem solltest Du Dein Projekt besser auf "Release" umstellen, damit dann auch mit der Optimierung -Os übersetzt wird. Gruß, Frank
-
Thread
STM32F4 CoOS
. 6 Posts weiter oben) ======================================================================= GCC HOME: C:\CooCox\gcc\bin compile: [mkdir] Created dir: C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\Debug\bin [mkdir] Created dir: C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\Debug
\arch.o ..\obj\misc.o ..\obj\sem.o ..\obj\hook.o ..\obj\usart.o -L..\.. -lm [cc] c:/coocox/gcc/bin/../lib/gcc/arm-none-eabi/4.6.2/armv7e-m\libgcc.a(unwind-arm.o): In function `get_eit_entry': [cc] unwind-arm.c:(.text+0x144): undefined reference to `__exidx_start' [cc] unwind-arm.c
-
Thread
Optimieren von ungenutzter Variable verhindern
optimiert die Variable raus. Wie kann ich dieses Verhalten am besten unterbinden, ohne jedoch auf Optimierungen zu verzichten? MfG Hexfile
main.c:270: warning: passing argument 1 of 'putnum_uh' makes integer from pointer without a cast avr-gcc -mmcu=attiny85 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=10000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT util.o -MF dep/util.o.d -c ../util.c avr-gcc -mmcu
-
Thread
MC PIC - Warum diese Ungleichbehandlung?
und -Bootloader (20 Einträge) • AVR-Projekte (103 Einträge) • AVR-Tutorial (27 Einträge) • Avr-gcc (12 Einträge) • Avr-gcc Tutorial (10 Einträge) [1] [[Spezial:Kategorien]]
PICs gibt. Die "freien" Versionen werden nach 60-tägiger Testphase > durch die dann wegfallende Optimierung praktisch unbrauchbar. Das ist nicht korrekt. Für PIC32 kann sehr wohl der ganz normale mips-elf-gcc verwendet werden. Es braucht gar nix von Microchip. Es ist nicht bequem, aber es geht. Wer
-
Thread
Kein Programmieren möglich?
muss das in AVR-Studio "eingebunden" > werden? Der ist schon eingebunden. AVR Studio nutzt AVR GCC um aus deinem Programm die HEX Datei zu erzeugen. > > Gut davon mal abgesehn...ich möchte ja jetzt erstmal ein blödes kleines > Programm schreiben, mit dem ich mich in die Atmels einarbeiten kann
so-und-so draufspielen... > Wenns sowas überhaupt gibt. 1. AVR Studio öffnen 2. Projekt erstellen (AVR-GCC Projekt heißt das glaube ich) 3. µC auswählen 3.1 In den Projekteinstellungen die CPU Frequenz wählen (Standard ist meist 1000000) 3.2 In den Projekteinstellungen die Optimierung auf Os stellen
-
Thread
Datentypen / Übergabewerte Funktionen
Hallo, ich bin momentan dabei vom Keil 8051-C51 auf AVR-GCC (Atmel Studio 6) umzusteigen. Hierbei durfte ich feststellen, dass GCC einige Datentypen, die es in C51 von Keil gibt, nicht kennt. So schlagen in C51 einwandfreie Funktionsdefinitionen wie z.B.
z.B. > > "unsigned char i2c_get(bit ack)" > > gnadenlos fehl da Datentyp "bit" bei GCC unbekannt. Das /könnte/ damit zusammenhängen, daß gcc ein C-Compiler ist ;-) Tipp: "bit" ist kein Schlüsselwort in C. Oder erwartest du, daß GCC ungültigen Code akzeptiert? (Vorausgesetzt,
-
Thread
Problem bei einfachen Lauflicht :-(
Wie ist deine Optimierung eingestellt? Ich sehe keinen Fehler. Beschreib mal dein Blitzen! Welche IDE? Ingo
delay_ms(70));} [/c] Kann sein dass man noch unsigned vor den char setzen muss, hab gerade keinen AVR-GCC zur Hand. Mal sehen, vielleicht schlage ich Karl-Heinz ja dieses Mal...
-
Thread
Fliesskomma ARM7 GCC
im Beitrag #2808298: >> Verwendete GNU Toolchain ist aus dem Paket von >> https://launchpad.net/gcc-arm-embedded > > Wenn ich das recht verstehe, basiert das auf dem arm-embedded Branch von > GCC, nicht auf dem Hauptzweig der GCC-Entwicklung? Das weiss ich nicht. Aber auf deren Seite gibt es
tun. Daraus lassen sich dann ja wieder Konflikt- und Hunk-freie Patches erzeugen. [1] http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
-
Thread
GCC Funktion wird manchmal nicht aufgerufen
Hallo, ich habe in GCC eine Funktion geschrieben, die ein Display ansteuert. Also der Funktion übergebe ich die zu adressierende Zeile und Spalte sowie das zu schreibende Symbol. Anschließend steuert die Funktion bei dem
werden immer nur > die ersten beiden Funktionen aufgerufen. und was passiert dann? also der der GCC hier einen fehler hat, ist zu 999.9999% ausgeschlossen.
-
Thread
ATMega - Volatile Funktionen im Interrupt OK?
. Und möglicherweise hat sich auch noch keiner drum gekümmert, weil jeder, den die fehlende Optimierung an dieser Stelle stört, die triviale, naheliegende Änderung an seinem Code macht, die den Vergleich auf int-Ebene ausführt. Wenn du /wiklich/ wissen willst, warum die Optimierung nicht in GCC
und Vergleiche der Fall. > ist denn eine nicht vorhanden optimierung ein Bug? Müsste man das nicht > als Feature Request einreichen? Die Bug-Nummern in GCC bzw. binutils bugzilla beginnen auf PR, kurz für "Problem Report". Dazu zählen auch die "missed-optimization
-
Thread
Display fällt in unregelmäßigen Abständen aus
Hab die Optimierungen mal umgesetzt und werd das ganze bei Gelegenheit mal auf den Käfer packen. Bei der PROGMEM optimierung bin ich mir unsicher, muss ich da nicht pgm_read_byt verwenden um da dann drauf zuzugreifen
nachgelesen und gesehen, dass da ein Adressoperator fehlt, läuft jetzt erstmal mit den ganzen Optimierungen. Mal schauen ob er immer noch zu schwachsinn übergeht oder nicht. Florian
-
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
unterschied zwischen _delay_us und _delay_ms
Das war vor langer Zeit in einer mitlerweile hoffnungslos veralteten version des AVR-GCC. _delay_ms bestimmt eine Wartezeit in Millisekunden _delay_us bestimmt eine Wartezeit in Mikrosekunden (1 Millisekunde = 1000 Mikrosekunden) die Delay-Funktionen arbeiten nur bei Aktivierter Optimierung