-
Thread
Buchempfehlung C++ und MCUs
treiben muss und die Codegröße nicht weiter ansteigt? Wohlgemerkt mit normalen Mitteln was die avr-gcc Toolchain bietet.
nicht genutzt werden, musst du auch mal erklären. Abgesehen davon, daß der Compiler die bei der Optimierung einfach rauswirft. Das einzige, was bei virtuellen Funktionen in Zusammenhang mit Arduino-AVR wirklich stört, ist die unschöne Platzierung der vtables im SRAm durch den avr-gcc. Irgend etwas
-
Thread
wert mappen, wie casten?
Der Kenner heißt gcc. Mit gewünschter Optimierung kompilieren, und Code anschauen. Mein Prognose, was am schnellsten ist, will ich noch nicht verraten ...
Klaus W. schrieb im Beitrag #6861798: > Der Kenner heißt gcc. > Mit gewünschter Optimierung kompilieren, und Code anschauen. > > Mein Prognose, was am schnellsten ist, will ich noch nicht verraten ... So ist es! Optimiert wird ganz am Schluss - notfalls
-
Thread
RISC-V mit GateMate FPGA
APB-Bridge, UART, I2C, SPI usw. mit 50Mhz, ziemlich auf Kante genäht, aber auch ohne irgendwelche Optimierungen im Design.
mit minimalem Platzbedarf ist man mit anderen Architekturen besser beraten. Bei der gezielten Optimierung auf f_max hat sich bisher bei mir herausgestellt: - Lokalen MMR-Bus (memory mapped register) mit Write-Delay-Pipes versehen. Wenn die Architektur unmittelbar zurücklesen koennen muss, muss man
-
Thread
1-Wire mit _delay_us: Kann das gut gehen, wie lang ist _delay_us wirklich?
mich langsam ob das überhaupt zu Ziel führt. Ein Interrupt im µs-Bereich ist zu schnell, unter C und GCC ist der Atmega dann nur noch in der ISR und hängt da fest. Vielleicht ist ja auch etwas ganz anderes an meinem Ansatz falsch, hab mal die .c & .h angehangen. Atmega32, GCC, Geany, AvrDude, DS1820
Hey, die Optimierung ist an und ich übergebe an _delay_us() nur Zahlenwerte also weder eine Variable noch sonst irgentwas. Die _delay-Funktion geht bei mir auch sonst, allerdings habe ich damit noch nie ein so genaues
-
Thread
if condition schöner schreiben?
Zweifelsfall auch besser. Natürlich sollte man sinnvolle Algorithmen verwenden. Wenn man das tut, ist Optimierung auf der Ebene "wie-kodiere-ich-das-am-besten-von-Hand" in sehr vielen Fällen komplett unnötig.
Der GCC erlaubt auch: [c] switch(i){ case 0 ... 3: case 8 ... 11: case 16 ... 19: case 24 ... 27: doSomething(); break; } [/c] Paddy schrieb im Beitrag #4884829:
-
Thread
pow() Flash-speichersparend ?
in die 200 Bytes zu pressen, indem man ihn in Assembler nachzuprogrammiert. Das wäre aber eine Optimierung von fast 50%, was sicher nicht ganz leicht zu schaffen ist. Wesentlich einfacher ist es wahrscheinlich, das restliche Programm (ca. 3900 Bytes) mit ein paar Optimierungen auf C-Ebene um etwa
Speicheranzeige herbekommt weiß ich nicht. Darum hab ich hier 4.18, die letzte 4er mit direkter avr-gcc Integration.
-
Thread
C++: VS2017 kompiliert viel langsamer als VS2015?
gemacht? Zusatz-Infos: -Ja ich weiss das Windows und das VStudio ganz ganz schlecht sind und mit dem GCC und Linux sowas nicht passiert wäre, leider kann ich die Vorgaben nicht ändern :)
gelöst haben, aber die > Ursache des Problems →VS2017← nicht loswerden. Äh, ja... unter Linux/GCC/Clang baut die Software auch nicht super schnell und zusätzlich ist es eben leider nicht das Kunden-System also was hilft dein Statement?
-
Thread
AVR-GCC Linker linkt unbenutzte Teile
Hallo zusammen, ich bin gerade dabei, den Webserver von U. Radig so zu modifizieren, dass er mit einer von mir dafür abgeänderten Version von efsl (embedded file systems library) läuft und Webseiten von SD_Krate anzeigt. Ich mache daraus ein Projekt für AVR-Studio, d.h. ich habe alle notwendigen Files bereits importiert und efsl benutze ich nicht als Bibliothek, sondern direkt den Quellcode. Nun bin ich gerade an einer merkwürdigen Sache dran. Damit der Code möglichst klein wird, habe ich einige Optimierungen im Compiler, unter anderem -ffunction-sections -fdata-sections Im Linker
-
Thread
Attiny2313 macht Probleme
kompilereinstellungen wegoptimiert werden. Können sie nicht. Die _delay_ms Routine, die mit dem GCC mitkommt, wird 100% sicher nicht wegoptimiert.
Wie schalte ich die Optimierung bei AVR Studio 4 ein?
-
Thread
"Memory Barrier" in C99
sorgen, dass entsprechende Funktionen siese Eigenschaft haben, etwa indem man interprozedurale Optimierungen deaktiviert.
angegeben oder Seiteneffekte beschrieben werden können, firmal existiert also noch nicht einmal eine GCC Memory Barrier wie asm("" ::: "memory").
-
Thread
[AVR GCC] "Speicherfresser" finden?
https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung
Falles du es nicht eh schon machst. Den Compiler auf Codegröße optimieren lassen (gcc -Os) Details: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
-
Thread
PIC Assembler Probleme
So als Tip wegen Optimierung wen die werte des PORT bekant sind bei der ausfürung ein: movlw B’00000000’ movwf PORTC ist wesentlich schneller als: bcf PORTC, 1 bcf PORTC, 1 bcf PORTC, 1 bei erster variante wird
Nochmal was zur Optimierung. Ich kenn diesen Prozessor nicht genau, aber bei anderen PICs gibts auch den ANDLW Befehl. Die Idee ist den Wert 0011xx1100 (0 wo gelöscht werden soll, 1 wo nicht beeinflusst wird) zu laden und
-
Thread
ATMega32 Stack overflow. Wie vermeiden/analysieren?
Hallo, ich bin bei meinem C-Programm (GCC) für den ATMega32 auf ein Problem gestoßen. Es ist immer an der gleichen Stelle hängen geblieben. Das Problem ist sogar mit dem AVRStudio Simulator reproduzierbar. Das ganze liegt wohl an der Stack
von Peter: > c = a + b; > > besser: > > a += b; Die ehutigen Compiler, zu denen auch der GCC gehört, optimieren so etwas ohnehin in "Grund und Boden" ;-) - zumindest insofern die Optimierung nicht abgeschaltet ist! Genaue Auskunft, wieviele lokale Variablen (die bekanntlich auf dem Stack landen
-
Thread
Wie kann ich Bitschieberei beschleunigen
A. K. schrieb: > Auch KHBs und Bernds Versionen werden von avr-gcc 4.3.4 entsprechend > grauenvoll umgearbeitet Hast Du's wirklich ausprobiert oder geraten? Ich hab's gerade mal durch den avr-gcc-4.3.3 laufen lassen, da sieht zumindest meine Version ganz ordentlich
Un bist du sicher das diese "optimierung" an der richtigen Stelle ist?
-
Thread
STM32 Kompilat größer als erwartet
startup/startup_stm32.s Building file: ../startup/sysmem.c Building file: ../src/main.c Invoking: MCU GCC Assembler Invoking: MCU GCC Compiler Invoking: MCU GCC Compiler /home/stefan/Programmierung/STM32_Workbench/Blinker/Release /home/stefan/Programmierung/STM32_Workbench/Blinker/Release arm-none-eabi-as
startup/sysmem.c Finished building: ../src/main.c Building target: Blinker.elf Invoking: MCU GCC Linker arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -specs=nano.specs -specs=nosys.specs -T"/home/stefan/Programmierung/STM32_Workbench/Blinker/LinkerScript.ld" -Wl,-Map=output.map -Wl
-
Thread
AVR: UART + ADC, Feinheiten und Fragen
ich damit gut arbeiten kann. Ich habe mich jetzt durch diverse Tutorials (hier vor allem das AVR-GCC) und Bücher gewurstelt und habe 2 ADC-Kanäle am laufen die über UART an meinen PC gesendet werden. Der Quelltext dazu ist oben als Anhang eingefügt. Da ich diesen Text zu Übungszwecken verwende habe
Strukturierte Programmierung auf Mikrocontrollern]] https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung "Verfrühte Optimierung ist die Wurzel allen Übels!" > sind grobe Fehler drin die man als > "erfahrener" C-Programmierer nicht machen sollte? >#
-
Thread
Merkwürdiges STM32 Verhalten
Optimierungsflags verwendet werden. Findet sich unter Projekt -> Properties -> C/C++ Build -> Settings -> (GCC oder G++ compiler) -> Optimization Wenn das dort auf -Og steht, probier es mal mit -O0 aus. -Og führt im Gegensatz zu O0 schon Optimierungen durch, versucht aber noch gut debuggbar zu sein, aber
Optimierungen abschalten. Der Kompiler hat die Zeile/den Code wegoptimiert.
-
Thread
Assembler-Programmieren PIC16F1934/6/7
simpler Programmierung kommt heutzutage kein schlechter Code heraus, weil man die tatsächliche Optimierung dem Compiler überlassen kann. W.S.
Haben sie, deren 16. Die PIC30 waren erkennbar so konzipiert worden, dass heutige C Compiler wie GCC keine Verrenkungen benötigen. Das ist schon aus Faulheit (Sparsamkeit) sinnvoll, denn nur dann kann man effizient auf bestehenden Compilern wie GCC aufbauen. Was Microchip ja auch getan hat. > Erzeugter
-
Thread
Welchen WINAVR nehmen ?
Sieht bei mir gut aus, ich hab das .lst mal drangehängt. Ist mit -Os und gcc 4.01 für einen Tiny26 übersetzt.
Gut, und welcher Compiler wird dann von der IDE aufgerufen? Wohl wieder dieser Hobby-Frickel-gcc. :-)
-
Thread
Mehrere Anweisungen hinter einem Define
gekommen: Eine Funktion nur als "inline" zu definieren bringt garnichts. Mit eingeschalteter Optimierung wird der gcc sie sowieso inlinen, wenn er der Meinung ist es bringt was. Und andersherum wird er sie nicht inlinen wenn der Code deswegen zu groß wird (z.B. bei mehreren Aufrufen), trotz "inline
(durch optimieren der Operation und wegfallen des Aufrufs&Parameter-Übergabe -Overhead) macht der GCC das nicht immer. Daher muss man sich mit __attribute__((always_inline)) behelfen. In C++11 ist sogar eine Standard-Notation dafür vorgesehen (um Compiler-unabhängig zu sein) aber die unterstützt GCC
-
Thread
Komplexität STM32 vs. PIC32
vermutlich über mehr Register, welchen den "fault" besser eingrenzen. - Die Kompilate von mips-elf-gcc sind - verglichen mit arm-none-eabi-gcc / thumb2 - wesentlich größer. Vielleicht holen hier die Microchip-Ergänzungen für "deren" GCC mehr heraus: [c] 28260 44 1204 29508 7344
void _general_exception_handler (unsigned cause, unsigned status); > - Die Kompilate von mips-elf-gcc sind - verglichen mit arm-none-eabi-gcc > / thumb2 - wesentlich größer. Vielleicht holen hier die > Microchip-Ergänzungen für "deren" GCC mehr heraus: > > [c] > 28260 44 1204 29508
-
Thread
Atmel Studio 6 beim Einzelschritt Debuggen asynchron
Schalte mal die GCC Optimierungen komplett ab.
Habe die Optimierung ganz ausgestellt, bringt aber nichts. Anbei ein kleiner Code-Auschnitt als Screenshot: Der Programmcursor steht am gelben Pfeil, aber es wurde schon die Routine lcd_command(0x01) abgearbeitet
-
Thread
Leisungsvergleich ARM AVR
die beim ARM zusammen auf 4 bytes erfolgen können. Somit könnte der AVR-Code bei entsprechender Optimierung auf dem ARM um ein vielfaches schneller laufen.
Dirk K. schrieb im Beitrag #3640847: > Optimierungen (-O2) Wie sieht dein Px-Auswerte-code denn inzwischen aus? Du hattest auch if-while-Verschachtelungen...
-
Thread
was bedeutet diese Fehlermeldung?
const_int 64000 [0xfa00]) (nil))) 3310_LCD.c:587: internal compiler error: in extract_insn, at gcc-3.3.2/gcc/recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make.exe: *** [3310_LCD.o] Error 1 >
64000 [0xfa00]) > (nil))) > 3310_LCD.c:587: internal compiler error: in extract_insn, at > gcc-3.3.2/gcc/recog.c:2175 > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://gcc.gnu.org/bugs.html> for instructions. Auch hier steht eigentlich alles
-
Thread
Compiler/Linker Fehler
geben folgende Fehlermeldungen/Warnungen heraus: > "make.exe" all -------- begin -------- avr-gcc (GCC) 3.4.3 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
Mglw. hat hier die avr-gcc "FAQ" aus dem Hauptmenue dieser Seite Verwirrung gestiftet. Diese ist stark veraltet. Eine halbwegs aktuelle Einführung in avr-gcc/avr-libc findet sich im wiki (Artikel avr-gcc tutorial).
-
Thread
WinAVR 20090313 Released
Die AVR-GCC 4.3.x erzeugen bei mir alle den selben Code. An der Optimierung wurde also nichts geändert. Wenn Du AVRs benutzt, die der AVR-GCC 4.2.x schon kennt, solltest Du ihn ruhig weiter verwenden. Insbesondere, wenns eng im Flash wird. Der AVR-GCC 4.3.x erzeugt oftmals doch recht seltsamen Code. Peter
-
Thread
Fehler im Compiler oder bei mir ?
Wenn die Optimierung eingeschaltet ist, kann der Compiler eine ganze Menge machen, was für den Menschen nicht auf den ersten Blick verständlich ist. Möglicherweise steht in R0 ja genau der Wert der an der Stelle benötigt
Compiler erzeugte Code etwas schlechter ist als ein von Hand optimierter. Nachtrag: Welche Optimierungs"stufe" hast du überhaupt aktiviert. Vielleicht kann das der Compiler sogar noch verbessern.
-
Thread
8h Timer mit attiny85 - Genauigkeit ohne Quarz
Beitrag #5405579: > Der Compiler IST > kostenlos! Nur gibt es damit halt keine Optionen zur Code-Optimierung. Was nutzt Compiler ohne Code-Optimierung? Das ist Müll.
verfügbarem Flash und RAM. Müll sicher nicht aber es nervt/ärgert einen schon. Die haben da den GCC ja auch nur etwas(?) modifiziert. Wirklich gebraucht, habe ich die volle Optimierung nur, wenn ich einen PIC16F84 mit C vergewaltigt habe. :)
-
Thread
Probleme bei selbstgebauter Uhr (DEM 16217 | STK500)
Datenflussanalyse wird bei dieser Variablen zu falschen Schlüssen kommen, also spar dir jegliche Optimierung auf dieser Variablen. Alles andere sind Folgeerscheinungen davon und bei manchen Compilern so, bei anderen wieder nicht. volatile hat damit zu tun, eine Variable von der Optimierung des Compilers
Datenflussanalyse wird bei dieser Variablen zu falschen Schlüssen > kommen, also spar dir jegliche Optimierung auf dieser Variablen. > > Alles andere sind Folgeerscheinungen davon und bei manchen Compilern so, > bei anderen wieder nicht. > > volatile hat damit zu tun, eine Variable von der Optimierung
-
Thread
Bascom Compiler Geschwindigkeit
zusammencomiliert hat. Zusätzlich bekommt man bei FastAVR noch ein Assemblerlisting, was ggf nötige Optimierungen "von Hand" mächtig vereinfacht. Ausserdem kann man so überprüfen wie sinnvoll der Compiler arbeitet. bye Frank
Na das ist ja wirklich langsam. Der ARM-GCC braucht auf meinem 1.3 GHz G4 Notebook für den MP3-Player-Code (53 Dateien, ergibt 120 kB Flash) nur 30 Sekunden.
-
Artikel
Diskussion:Schnelle 32Bit-Integer Sinusberechnung
Die Routine selbst braucht nochmals 192 Bytes. Macht insgesamt also rund 300 Bytes, bei starker Optimierung (-O2, avr-gcc 4.7.2). Spart bei ganzzahligen Winkeln also eigentlich quasi fast nichts und braucht noch viel mehr Rechenzeit als eine Tabelle mit 360 Einträgen. --Haku (Diskussion) 19:02, 29. Okt
beschrieben ist: Digitale_Sinusfunktion 87.166.170.19 14:41, 1. Nov. 2013 (CET) Ergebnis für 8 Bit AVR-GCC. Der AVR-GCC-Compiler macht aus diesem Code mit 16Bit integer, (nur die Multiplikationen als long) 272 Bytes. Das sind 84Byte mehr als bei einem 32Bit-Arm. Jetzt kann sich jeder selbst ein Bild machen
-
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
Arduino IDE 2.3.2 was dauert so lange ?
Hinter der Arduino-IDE steckt ja ein GCC. Und der ist unter Windows auf dem gleichen Rechner erheblich langsamer als unter Linux. Warum das so ist erschließt sich mir aber auch nicht. Auf meinem Testsystem war damals "nur" der Windows Defender
Betriebssystem komplett neu kompilieren muß, behindert das den workflow doch ganz beträchtlich. Das der gcc unter Windows deutlich langsamer agiert als unter Linux, auch und gerade bei solchen Winzprogramme, die auf einen AVR passen, ist altbekannt. gcc arbeitet beim Compilieren halt mit unzähligen Dateien
-
Thread
Flash CRC Berechnung optimieren/schneller
Ich hab mal schnell was zusammengestrickt, ich komme auf 55 Takte/Byte Die Lib in crc16.h des AVR-GCC ist inline-Assembler (23 Zyklen) und braucht mit Loop-Overhead zusammen 41 Zyklen. Die CRC-CCITT ist mit 17 Zyklen etwas kürzer.
Ok, hier die kleine Optimierung, wenn man die Schleife um die CRC in ASM per Hand gestaltet. Macht 33 Takte/Byte. Die eigentliche, trickreiche CRC-Berechnung braucht 23 Takte, habe ich einfach kopiert. Die Variante in C
-
Thread
Normierungs-Trick oder Float Berechnung?
new Noch einmal, wenn Du 'float' brauchst, dann nimm 'float'. Die ganzen 'int' oder 'long' Optimierungen bringen eventuell ein bißchen mehr Geschwindigkeit, was aber nicht zwingend sein muß. Bei 'long' wir mit 32 Bit gerechnet, bei 'float' jedoch nur mit 24 (für die Mantisse), was durchaus schneller
verwenden. Wenn Du es ganz genau machen willst, kannst Du auch noch mit verschiedenen Compiler-Optimierungs-Einstellungen testen. Entweder systematisch alle Kombinationen einiger weniger Optimierungen ausprobieren, oder mit einem genetischen Algorithmus die beste Kombination aus einer vielzahl (alle)
-
Thread
LCD Display initialisiert nicht
verwende die subroutinen aus dem lcd tutorium Welches? [[AVR-Tutorial: LCD]] (Assembler) oder [[AVR-GCC-Tutorial/LCD-Ansteuerung]] Ich vermute die C Version. Dann wäre deine Pinbelegung die unveränderte aus der Includedatei lcd-routines.h. > wenn ich den strom einschalte sollten ja > eigentlich
beliebte" Probleme: Falsche Taktquelle oder Teiler-durch-8 3. bei Benutzung von delay.h mit Optimierung kompiliert werden Der Praxistest mit genau blinkender LED zeigt im Erfolgsfall, dass alle vier Punkte richtig erfüllt sind. > genau, die c version. sind recht einfache routinen und ich habe
-
Thread
Unterschied zu IAR
Worin liegen Unterschiede zwischen GCC und IAR C Compiler für AVR? - Sind die erzeugten HEX-Files vom IAR besser als die vom GCC? - Ist der C Syntax anders? - Sind die Header Files gleich?
kompakteren Code, wobei ich letztens bei einer zeitkritischen Anwendung feststellen musste, dass ein GCC mit -O3 zwar nochmal weitere 10 % auf die Codegröße drauflegt, aber dafür auch ca. 10 % schneller war als der IAR in seiner schnellsten Optimierung. Das ist natürlich jetzt alles andere als repräsentativ
-
Thread
Mehrere Files linken (Commandline, AVR-GCC)
atmega32 -g (Klappt, kleine Objects erblicken das Licht dieser Welt ;-) Zum Linken rufe ich den AVR-GCC mit den Optionen -mmcu=atmega32 -combine BLA.OBJ Main.OBJ -o GO.ELF auf, der meckert aber: Main.C:(.text+0x6de): undefined reference to `CBlaBla' Schon ein kleiner Hinweis wäre traumhaft
Im Moment benutzt du wegen der Endung der Quelltexte den C++ Compiler compile.bat [pre] avr-gcc -c -Wall -Os -mmcu=atmega32 -g main.c avr-gcc -c -Wall -Os -mmcu=atmega32 -g bla.c avr-gcc -mmcu=atmega32 -combine bla.o main.o -o go.elf [/pre] main.c [C] #include <avr/io.h> #include <stdio.h
-
Thread
Probleme mit Optimierung bei CCE für MSP430
Hallo, kennt sich jemand mit den optimization Einstellungen in CCE aus? Ich habe das Problem, dass mein Programm für einen MSP430f2272 mit level 0 und 1 problemlos läuft, sich aber bei level 2 irgendwo aufhängt (lässt sich nicht durch debuggen finden). Gibt es irgendwo eine Übersicht über die unterschiedlichen Level und was jeweil genau optimiert wird?
-
Thread
GCC-ARM -O3 (nicht-)Performance
auch Pragmas, mit denen man den GCC zu Optimierung nur ausgewählter Code-Passagen anweisen kann. Das habe ich auch gemacht - nichts Wildes, nur z.B. eine oft aufgerufene Funktion mit einem Shellsort, die ich per Pragma auf -O3 gesetzt
Pechtreffer gehabt, während andere da ein glücklicheres Händchen hatten? Wie sind Eure Erfahrungen mit ARM-GCC, -O3 und Cortex-M?
-
Thread
Maximale Programm-Größe laut size-of
Optimierung ist in der Makefile auf OPT = s, also auf Größe optimieren. _delay_ms hab ich auch schon an anderen Stellen wie für die Initialisierung des LCD verwendet, dann müsste die eine Library immer schon dazugelinkt werden. Das ist der ganze Auszug: -------- begin -------- avr-gcc (GCC) 4.1.2 (WinAVR 20070525) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or
-
Thread
Optimieren? Thermostat mit Tiny26
avr-gcc -c -mmcu=attiny26 -I. -g -Os -Wall -Wstrict-prototypes -std=gnu99 thermo_little.c -o thermo_little.o thermo_little.c:22:17: lcd.h: No such file or directory thermo_little.c: In function `printFormat
der Rest ja noch, um verschiedene Profile im EEPROM zu verwalten. Auf jeden Fall wäre ohne die Optimierung von Jörg nicht mehr soviel drin gewesen.. Gruß Andreas
-
Thread
Beispielprogramm Pi_on_2313.c, hex-Datei zu groß
file:///C:/WinAVR-20100110/doc/gcc/HTML/gcc-4.3.2/gcc/Optimize-Options.html#Optimize-Options Kann mir da jemand weiter helfen bitte? mit freundlichem Gruß
> - Anregungen der Experten umsetzen, damit es in den 2313 hinein paßt > - genau die vorgegebene GCC-Version installieren und damit compilieren, > falls die vorgegebene Kommandozeile paßt. > - sich hier durchkämpfen (?): > file:///C:/WinAVR-20100110/doc/gcc/HTML/gcc-4.3.2/gcc/Option- > Summary.html
-
Thread
PINx-Register
Weitere Basics findest du hier: [[Kategorie:Avr-gcc_Tutorial]]
optimiert, um ihn derart austricksen zu können. Geringste Änderungen des Codes oder der gewählten Optimierung können dafür sorgen, dass es doch wieder nicht funktioniert. Die korrekt Lösung wäre das Einfügen einer Wartezeit von genau einem Takt zwischen den beiden Zeilen und dem weiteren Code. Also
-
Thread
AVR: Problem mit eeprom_read_byte()
Programm läuft wenn ich mit Optimierungsstufen "s" oder "3" kompiliere. Ich brauche es aber ohne Optimierung, da mir ansonsten die eingebauten Warteschleifen wegopitmiert werden. Die sind aber notwendig, da der Mikrocontroller einen Flachbildschirm ansteuern muss, der da nicht mitziehen würde.
>Ich >brauche es aber ohne Optimierung, da mir ansonsten die eingebauten >Warteschleifen wegopitmiert werden. Die sind aber notwendig, da der >Mikrocontroller einen Flachbildschirm ansteuern muss, der da nicht >mitziehen würde.
-
Thread
"static const" Objekt "wegoptimieren"?
Dass es in der 1. Version der "port_optimal.cc" "richtig" funktionierte ware pure Freundlichkeit vom GCC, das so zu optimieren.
Wenn man die volle Optimierung vom Kompiler zulässt: Ja, es ist egal, denn der Kompiler wird das gewünschte Optimum (Größe/Geschwindigkeit) rausholen. Wieviel man letztlich braucht, entscheidet der Programmierer, wie "verschwenderisch
-
Thread
[anfängerfrage] wo finde ich die includedateien und wie ordne ich neue zu
sqlite3 (habe ich bereits installiert), > wie kann ich die NEUE hinzufügen, dass ich eben nicht > gcc readFomDb.c ?!sqlite3.h!? -o neuesTool > gesondert aufführen muss reicht das diese in richtigen Ordner abzulegen!? Vielen Dank
okay,... der richtige befehl war: gcc write2db.c -o write2db -lsqlite3
-
Thread
Cordic-Algorithmus in AVR-Assembler
einmal > ganze Register verschiebe. Interessant wäre, das ganze so zu schreiben, daß es auf das avr-gcc ABI passt, d.h. daß man die Funktionen komfortabel von avr-gcc aus aufrufen und in C/C++ Programmen verwenden könnte. Dann enthält das Programm einen Fehler, von dem ich aber nicht weiß, ob er sich
> nennen oder kurz die Konformitätsregeln beschreiben? http://www.rn-wissen.de/index.php/Avr-gcc/Interna#Registerverwendung http://avr-libc.nongnu.org/user-manual/FAQ.html#faq_reg_usage Johann
-
Thread
function c asm bedeutung
geinlinten Funktion, so daß result immer auf 16 Bit expandiert wird -- im Gegensatz zum Makro. (avr-gcc ohne -mint8)
korrekt initialisiert würden. Problem ist der Mittelteil, wo zig Transformationen und Optimierungen geschehen. Die tausenden von Stellen im GCC dahingehend zu erweitern und zu testen ist ne echte Strafe und ein eigenes, auf mindestens 1 MJahr anzulegendes Projekt. Und wenn man damit fertig wäre
-
Thread
Webserver macht einfach nichts mit der 1.39er Source
nicht braucht.(?) Naja. Hier dann mal meine Shellausgabe: [pre] -------- begin -------- avr-gcc (GCC) 4.1.0 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
warning: "ISR" redefined In file included from main.h:16, from 3c5x9.c:49: /usr/lib/gcc/avr/4.1.0/../../../../avr/include/avr/interrupt.h:96:1: warning: this is the location of the previous definition 3c5x9.c:730:7: warning: no newline at end of file Compiling: rtl8019.c avr-gcc -