-
Thread
Mikrocontroller Rechenleistung reicht für aktuelles Projekt nicht?
math-Aufrufen. Innerhalb von 10 Sekunden wurden 73501 Berechnungen durchgeführt. Mit einigen Optimierungen ist da wohl noch einiges mehr drin.
erwähnten SAM3X @84Mhz messe ich 6120 Durchläufe/s vom orginalen Code ohne besondere ARM-spezifische Optimierungen.
-
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
Gesucht: Sehr schnelle hex2bin Routine
Kleiner Nachtrag: Der einfachste Weg bezüglich Assembler wäre, diese Funktion vom GCC mit -O3 compilieren und sich das Ergebnis als Assembler Listing ausgeben zu lassen. Vorrausgesetzt Du verwendest GCC nicht schon als C-Compiler.
Pointers und der Zählvariable, der Registerbreite etc. evt. sogar langsamer. Wobei ich auch diese Optimierung dem Compiler überlassen würde. Den tatsächlichen Unterschied dieser Optimierung wird man nicht merken und nur schwer messen können.
-
Thread
Ideen für FPGA-Projekte?
ansich eine schöne (mips-alike) Architektur, aber das Ding flog in die Ecke, u.a. wegen einigen Bugs im GCC, die eine saubere Portierung verhinderten. - ZPU: Ziemlich robust für einen freien Core, gut verifizierbar, allerdings kein Support in GCC 4.x (nur alte 3er Toolchain) Wie die Board-Supply-Packages
minimaleren Ecke sieht's halt mau aus. D.h. 'fett' sollte es gerade eben nicht, aber trotzdem 32 bit, GCC und JTAG-Debugger und DSP-Extensions. Das schafft die ZPU-Architektur mit Bravour und hat dabei den kompaktesten Code für einen 32-Bitter. Grüsse, - Strubi
-
Thread
strtok discards volatile qualifier
den Puffer für UART darstellt. Ich verwende das UART Beispiel für den Interruptempfang aus dem GCC-Tutorial: [c]#define UART_MAXSTRLEN 10 volatile uint8_t uart_str_complete = 0; // 1 .. String komplett empfangen volatile uint8_t uart_str_count = 0; volatile char uart_string[UART_MAXSTRLEN
volatile zu informieren. Nun aber: Kurz und bündig verhindert volatile, das der Compiler bei Optimierungen annimmt, das der schon mal z.B. in ein Register aus einer Variablen geladene Wert nach einigen anderen Schritten immer noch gültig ist. In Deinem Code wird aber genau genommen, durch die Variable
-
Thread
Eclipse Kompilierung LCD Buchstabensalat
probehalber ruhig großzügig gewählt) ersetzen. Beutzen eigentlich beide 'Versionen' den gleichen gcc?
am WE mal versuchen - bin für jeden Tip dankbar. Und ja beide Versionen benutzen den gleichen gcc. Ist ja auch nur einer auf dem System installiert. Jörg
-
Thread
Denkbare Möglichkeiten: Prorgamm "spinnt"
es für meinen Arbeitgeber ist. Dennoch wäre ich um Hilfe dankbar. Prozessor: Atmega8 Compiler: GCC Programmiersprache: C Randaten: Atmega Flash-Speicher ist nach dem compilieren zu 80-<90% voll (also noch Luft) Atmega SRAM nach dem compilieren zu 12% voll. Auch während der Programmlaufzeit
geprüft nach folgender Methode: http://www.rn-wissen.de/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc Sonst finde ich im Programm auch keine verschachtelten Funktionen. Arrays verwende ich im Programm nicht, außer einem im EEPROM. Diesen Programmteil/das Modul benutze ich aber in anderen Programmen
-
Thread
Quick&dirty - schnelle Problemlösungen selbst gebaut Bilder
Die Optimierung wäre jetzt noch der Konsum von Kaffee.
trivialen API. Klar kann ich mich von Hand durch den Code wühlen, aber es geht auch einfacher: * Code im GCC mit -finstrument-functions übersetzen * trace.c von https://balau82.wordpress.com/2010/10/06/trace-and-profile-function-calls-with-gcc/ klauen und mit einlinken * Das Skript readtracelog.sh von der
-
Thread
ATmega48 Programmspeicher zu klein?
Peter Dannegger schrieb im Beitrag #3570763: > Dann hast Du die falsch Math-Lib gelinkt oder Optimierung aus. Das bei dir nur 49.4% belegt sind ist sehr wunderlich. Wie kann ich den überprüfen welche Math-Lib ich gelinkt habe bzw. wie kann ich sie dann ändern? Mit der Optimierung habe ich auch
Welches AVR-Studio benutzt Du denn? In den Compileroptionen muß ein -lm stehen. Die Optimierung sollte -Os sein.
-
Thread
USB bei VMBOx Frage
auch mit allen MSP430 IDEs und Debuggern verwenden, einschließlich CCE 4.0 und dem sowieso freien GCC+GDB.
Compiler und dem NoIce mit Olimex JTAG Tiny arbeiten. Es ist ein altes Design mit einer keinen CPU. Der GCC Compiler liefert dafür viel zu großen Code. Er passt überhaupt nicht rein trotz scharfer Optimierung. Der Compiler und NoIce selber geht in der VM, nur der Olimex JTAG Tiny läßt sich nicht sicher
-
Thread
LED Tisch mit Berührungs-/Gegenstandserkennung
cyblord ---- schrieb im Beitrag #3661103: > avr-gcc unterstüzt den 841 in der aktuellen > Version. Wo finde ich Referenzen darauf? Auf der Homepage von avr-libc [1] ist davon noch keine Rede. Mein Eclipse mit aktueller Toolchain avr-gcc 4.9.0 und
Die Toolchain wird ja inzwischen von Atmel > gepflegt und dort findet man auch den aktuellen avr-gcc. Link? cyblord ---- schrieb im Beitrag #3661125: > Müsste schon eine 5 davor sein. Da erzählst du mir aber was neues. avr-gcc wird parallel mit dem eigentlichen gcc entwickelt und da ist 4.9
-
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
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
EEMEM landet aber im RAM
von EEMEM im ROM landet und beim Start vom versteckten init-code ins RAM kopiert wird. Ist die Optimierung nicht angeschaltet oder hat das Array einen vorgeladenen Wert, den du uns nicht zeigst? Den so muss er den Inhalt eigentl. nicht kopiert, sondern nur mit 0 initialisiert werden.
Keine Ahnung, ob es jetzt am Studio 6.0, am WinAVR/GCC liegt, ich mache es jetzt so: [c]EEMEM uint8_t static t[1024];[/c] Der Speicherverbrauch fürs EEPROM wird zwar jetzt nicht mehr angegeben, ist mir aber auch wurscht.
-
Thread
triviales Problem mit include - aber ich sehe es nicht
P.s.: Optimierung ist ausgeschaltet (None -O0)
Aufruf "gcc -v ..." hilft auch.
-
Thread
Erster eigener Assembler Code zu kompliziert gelöst?
PB1 ); } else { ASSIGN_BIT( PB4, PB3 ); } } } [/c] generiert der AVR-Gcc auch Code, der mittels Bitbefehlen die Logik abwickelt [avrasm] 00000022 <main>: 22: 84 e1 ldi r24, 0x14 ; 20 24: 87 bb out 0x17, r24 ; 23 26: b0 9b sbis 0x16
hinter den Bit-Bezeichnungen verstecken. > > Macht man das ganze klasssisch [...] Solche Optimierungen sollten bei einem guten Compiler eigentlich niemals nötig sein. Wenn ich optimieren will, schreibe ich gleich Assembler, da brauch ich nämlich nicht erst darüber rumrätseln, was der Compiler
-
Thread
C - Zwei Zahlen zu einer Mappen
Ohne konvertierung zu Double hatte es ja auch geklappt. 2. Was meinst du mit Kommandozeilen? avr-gcc main.c -c -o main.o -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -I. -mmcu=atmega328p -DF_CPU=8000000 avr-gcc lib/lcd.c -c -o lcd.o -std=c99 -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -I. -mmcu=atmega328p -DF_CPU=8000000 avr-gcc lib/simpleprog.c -c -o simpleprog.o -std=c99 -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -I. -mmcu=atmega328p -DF_CPU=8000000 avr-gcc lib/ds18b20.c -c -
-
Thread
C++: Framework oder nicht? (keine GUI)
ineffizient ist, denn die bietet ja durchaus Dinge wie std::vector<T>::reserve zur Performance-Optimierung. > >> Das ist natürlich besonders bekloppt. > Wenn man die Projekte auf sourceforge und co. so betrachtet, gewinnt man > schnell den Eindruck hier sind nur Bekloppte unterwegs wenn es nach
das die Software unnötig auf? Nein. Wenn Du es richtig machst, bindet ein guter Compiler wie der GCC am Ende nur das ein, was Du auch benutzt. > Bieten mir diese Frameworks Features, die mir die Arbeit an obigen > Punkten erleichtern Ja, unbedingt. Das ist der Grund dafür, warum es überhaupt
-
Thread
p2align funktioniert nicht
steht es etwa anders da? Gibst du den Code so direkt zum Assembler, oder ist das Code der ausm avr-gcc kommt?
scheinen die avrgas Makros nicht mächtig genug, oder > irre ich mich da? Das müsste dann eine Optimierung im avr-as sein, die es aber bislang nicht gibt. Evtl. geht auch ein 2-schrittiger Link: 1) Relocatable Link: Die Tabelle wird ohne --relax gelinkt und unkritischer Code mit --mrelax
-
Thread
DSP in bastlerfreundlichen Gehäusen
schrieb im Beitrag #3537544: > einerseits gibt's den Compiler nicht umsonst Wenn du auf Teile der Optimierung verzichten kannst ist der XC16 gratis.
Basteln, da alle Pins auf 100mil-Anschlüssen liegen und der Preis extrem günstig ist. Mit dem ARM gcc, eclipse und den STM-Tools klappt die Programmierung ohne Probleme. Debugging habe ich noch nicht ernsthaft versucht, soll aber auch funktionieren. Grüße, Kurt
-
Thread
minimalistische Berechnung einer Sinusschwingung
Leistungskurs Physik am Gymnasium. Jo mei, tatsächlich geht es in diesem Beitrag wahrscheinlich um die Optimierung eines digitalen Berechnungsverfahrens bezüglich begrenzter Hardwareresourcen einer Sinusschwingung. Der Threadstarter hat vermutlich das Feder/Masse System nur erwähnt, um die Grundlage darzustellen
is machine // and possibly compiler dependent // this code runs on a Intel PC compiled with GCC union shifter { int16_t part[2]; int32_t value; } sr; sr.value=AMPLITUDE; // initial excursion ( mass position ) of the spring int32_t q=0; int n; for(n=0;n<2000;n+
-
Thread
Erste Schritte mit ARM SAMD20
von diesen Registern. Ob das bei den Cortex-M3 und -M4 besser aussieht weiss ich nicht. 7. Der gcc lässt Optimierungs-Wünsche offen. -Os läuft am schnellsten, schneller als -O2 und -O3. Gucke ich in den Assembler, sehe ich meist auf Anhieb Möglichkeiten zu kleinen Verbesserungen. Wen das interessiert
Der braucht nach wie vor rund 300 CPU-Takte. Es gibt immer mehrere Wege ans Ziel. :-) > 7. Der gcc lässt Optimierungs-Wünsche offen. Dabei würde es mich wundern, wenn nicht zig verschiedene GCC Versionen im Einsatz wären. Mein Atmel Studio hat gerade Atmel ARM GNU Toolchain 4.8.4.1443 drunter
-
Thread
XC16 Optimierung
lösen. Kann es sein, dass der ineffiziente Code ein Produkt der in der Free Version fehlenden Optimierung ist? Gruß
Richtige™ Architektur (ARM) benutzen, gratis den GCC downloaden & verwenden und dessen Optimierung geniessen.
-
Thread
Frage zu ARM Instruction
Pipeline-Länge an, aber grundsätzlich sollten gleich bedingte Anweisungen hintereinander kommen, ist die Optimierung abgeschaltet? movne r1, #0 strne r1, [r2] ldrne r2, [pc, #60] moveq r1, #1 streq r1, [r2] ldreq r2, [pc, #60]
instructions soak up 1 cycle. Oh, übersehen. Lothar schrieb im Beitrag #3528248: > ist die Optimierung abgeschaltet Liegt wohl am volatile, das hält ihn vom optimieren ab...
-
Thread
Ich suche einen "etwas anderen" C-Compiler Gesperrt
movne r1, #65536 ; 0x10000 88c8: 03a01801 moveq r1, #65536 ; 0x10000 Wenn ich seh was gcc (-O2) so macht - ist die Antwort Ja Inline Assembler ist schlecht, weil der Compiler Probleme mit der Optimierung bekommt.
heinz schrieb im Beitrag #3526502: > Wenn ich seh was gcc (-O2) so macht - ist die Antwort Ja Welche Version? > Inline Assembler ist schlecht, weil der Compiler Probleme mit der > Optimierung bekommt. Dafür gibt es die entsprechenden Constraints, geht,
-
Thread
C sorgt oft für Verwirrungen
#3525277: > Oder ist das in der Release anders? Da musst du schon deinen Compiler befragen. GCC kann auch im Debugmodus (fast) alle Optimierungen aktivieren. Andere Compiler können das ggf. nicht.
Der Unterschied war auch zu merken, aber so wie der gcc hat er sich dennoch nicht verhalten. Naja, ist nicht schlimm. Der VC C++ 2008 Express hat mir die Optimierung sogar verweigert, weil sie sich (laut Fehlermeldung) mit einer anderen Optimierung nicht
-
Thread
avr-gcc: interner Compilerfehler? Was tun?
oder die Optimierungen zu ändern, darauf bin ich selber auch gekommen, aber danke trotzdem.
Vielleicht ist es ja der da: http://gcc.gnu.org/PR58545
-
Thread
Was ist die Ausgabe?
syntaktisch zu einem C-Programm macht, ist die 1. Zeile laut C-Standard *undefiniert*. Früher kannte GCC mal -fwritable-strings o.ä., aber das gibt es schon lange nicht mehr.
...und hier die Ausgabe mit GCC: [pre] til-hoff.c:2:1: warning: data definition has no type or storage class [enabled by default] str[2] = 'd'; ^ til-hoff.c:2:1: warning: type defaults to 'int' in declaration of 'str' [-Wimplicit-int
-
Thread
C Frage an die Könner
wird nicht optimiert, sondern ausgerechnet. Beim Kompilieren. Kann man so gesehen auch als Optimierung betrachten ;-)
wird nicht optimiert, sondern ausgerechnet. > > Beim Kompilieren. Kann man so gesehen auch als Optimierung betrachten > ;-) Da es mehr oder weniger schon vom Compiler ausgerechnet werden /muss/ würde ich nicht von Optimierung sprechen.
-
Thread
AVR-Studio 6 kompiliert fehlerhaft
Bei den Delay Funktionen muss man aufpassen, dass die Optimierung eingeschaltet ist - sonst gibt das viel zu lange Wartezeiten. Mit Optimierung kann es passieren das einige variablen ganz wegoptimiert werden und mit den Debug Funktionen schwer zu fassen sind
beim Debuggen immer Optimierungen ausschalten! Und wenn ein Breakpoint nicht greift, dann hat GCC ganz einfach die Zeile wegoptimiert. Wenn Du in ein Projekt reinschreibst: unsigned char counter; counter = 1; counter
-
Thread
Probleme mit UART bei Atmega 32
geh noch weiter runter in der Baudrate > (2400, 4800). Klasse! Mit 4800 geht es auch ohne Optimierung....Das erklärt auch, warum das Problem erst heute auftrat, obwohl das in der Vergangenheit schon funktioniert hat....unglaublich....
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART
-
Thread
µC von 0 auf lernen. ASM oder C?
PIC gibt es GCC basierende Compiler. (Wobei es ja auch geschmackssache ist ob jemand gcc favorisiert oder nicht. Nicht für jeden ist das der Nabel der Welt) 2. Die freien Compiler von Microchip sind -nach ablauf
wenn Wilhelm am Internet teilnehmen kann, dann hat er sicherlich > auch eine Plattform, auf der der GCC läuft. Es geht nicht um *auf*, sondern *für*... Auf einem AVR läuft auch kein GCC, aber der GCC kann AVR-Code generieren. > Wenn er wirklich keine Plattform hat, der arme Mensch... Es gibt ja auch
-
Thread
Unterprogrammaufruf in ISR
gesichert werden müssen (z.B. weil sie nur den Aufruf enthält) erfolgen auch keine PUSH'es. Wenn man Optimierungen (insb. LTO) einschaltet und die ISR nur einen Funktionsauruf enthält, wird die aufgerufene Funktion vom Linker in die ISR kopiert und der "Aufwand" entfällt komplett. Da der Cortex außerdem Interrupt-Prioritäten
wenn die Funktion in einem > anderen File (.c) steht. Das geht ganz wunderbar, wenn man einen neuen GCC nimmt (>= 4.7.3) und mit -flto kompiliert & linkt. Ulrich schrieb im Beitrag #3507926: > Der größte Punkt ist das man einmal die zusätzlichen > Register braucht. Was für Register braucht man für
-
Thread
STM32F10x USB VCP unter Coocox
da ich den USB-VCP im Bootloader nutze und ich unbedingt nicht mehr als 32KB haben wollte (Bei Optimierung -O0). Bei Start wird der Bootloader mit USB immer initialisiert und mit einer definierten Sprungtabelle nutzt diese initialisierte USB Verbindung auch die eigentliche Applikation. Und der Bootloader
einem Projekt mittels speziellem Linker-Script speichermäßig geteilt. Daher kompiliere ich das mit GCC und makefile direkt mit Eclipse. Jedoch die Funktionalität im Code von ST ist unverändert - nur anders strukturiert.
-
Thread
Programm von mega32 auf mega328P convertieren
installiert wurde?) Das Ergebnis ist gleich (riesig). Ich habe die *.C-Datei mal in das Verzeichnis von 'avr-gcc' kopiert und den Aufruf von diesem Verzeichnis gestartet. Ergebnis: avr-gcc: error: CreateProcess: No such file or directory Warum kann man im AVR-Studio unter Custom Options/External Tools/avr-gcc
4.5er Version! Also: direkten Verweis auf 'avr-gcc-4.7.2' -> jetzt geht's!
-
Thread
Prüfungsfrage
Beitrag #3497942: > Basierend auf was wird eine Reihenfolge festgelegt? Auf Basis vom Quellcode des GCC. Es kann sich aber in der nächsten Version wieder ändern. Im schlimmsten fall ist es sogar abhängig von den Speicheradresse der internen GCC Strukturen - ist aber auch egal. Das das verhalten nicht
schrieb: >> Basierend auf was wird eine Reihenfolge festgelegt? > > Auf Basis vom Quellcode des GCC. Es kann sich aber in der nächsten > Version wieder ändern. Im schlimmsten fall ist es sogar abhängig von den > Speicheradresse der internen GCC Strukturen - ist aber auch egal. Das > das verhalten
-
Thread
XC8 für Pic18 Arithmetik
Stefan schrieb im Beitrag #3498676: > avr-gcc:
propaganation. Da a immer 1 ist, wird X gleich mit 64 geladen, also 1<<64. Auch der C18 Compiler da gcc macht dasselbe. Ob X8 es mit nicht abgeschalteter Optimierung auch macht, mòglicherweise.
-
Thread
Shift vs. Union - Was ist effizienter?
kaputtoptimiert. Mit konstanter Regelmäßigkeit folt auf "das ist kaputt in GCC" oder "Optimierung muß für dieses Modul und GCC deaktiviert werden" falscher, d.h. nicht standardkonformer Code. - Type Punning und und Strict Aliasing - Falsche Verwendung von float / double -
Interesse besteht, habe mal mit angehängtem Code und verschiedenen Compilern experimentiert: 1. ARM, gcc 4.8.3, -Ofast -mthumb -mcpu=cortex-m0plus Generiert sehr ähnlichen Code für alle drei Fälle, immer Shifts und bitwise ORs. Wenn man -Os als Optimierung verwendet, generiert der gcc erstaunlicherweise
-
Thread
AVR-GCC Array(Pointer) einer Funktion übergeben
volatile sein? Wer weiss? Gibt es denn Potential, dass der COmpiler in diesen beiden Members mit der Optimierung daneben hauen kann?
irgendwie weiter } break; } [/c] Ich weiß eben nicht genau, ob der Compiler sowas per Optimierung zerwürgt...
-
Thread
[GELÖST]arm-elf-gdb springt bei Breakpoint in falschen Code
Optimierung war in der Tat eingeshaltet (-Os), aber auch mit -O0 ändert sich nichts.
mit dem Problem beschäftigt. Richtig lösen konnte ich es zwar nicht, nach einer Neuinstallation (gcc, newlib, binutils, gdb), jetzt mit arm-none-eabi anstatt arm-elf, hat alles wieder funktioniert. Da arm-elf als Target im neuesten gcc-Release sowieso nicht mehr verfügbar ist, empfiehlt sich ein Umstieg
-
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
Ist Atmel Studio 6.1 OK fuer ARM-Cortex SAM MCUs?
aber auch eingeschränkt. Die kostenlose Variante kann lediglich kompilieren mit sehr limitierten Optimierungen. Will man Optimierung einschalten, kostet es was und zwar nicht wenig. Will man noch mehr Optimierungen, kostet es noch mehr (in der Pro Version). Natürlich je Arbeitsplatz
Controller Code zu erzeugen. Entweder ich kaufe mir einen Proficompiler (z.B von IAR) oder ich verwende den gcc. Ein Controllerhersteller liefert mir also entweder einen eingeschraenkten Compiler mit, oder es ist nur der gcc. Wenn mir ersteres nicht gefaellt dann installiere ich mir halt selber den gcc oder
-
Thread
AVR PWM Time Unbekannte Befehle.
(_BV(x) entspricht dabei (1<<x)). Die ersten beiden Varianten erzeugen bei eingeschalteter Optimierung und passenden Parametern (wie hier im Beispiel Register im "unteren" Speicherbereich) die SBI bzw. CBI Prozessorbefehle."
Vermutung zur Gewissheit. Dazu gibt es hier ein Tutorial: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR Oliver
-
Thread
Pollin Display 12232, in ASM klappts, in C nicht
WinAVR > und Gnu Plugin drauf hat. Wenn ich die C Datei kompiliere bekomme ich folgendes (mit AVR-GCC): AVR Memory Usage: ----------------- Device: attiny2313 Program: 362 bytes (17.7% Full) (.text + .data + .bootloader) Data: 1 bytes (0.8% Full) (.data + .bss + .noinit)
Grad nochmal kontrolliert, die Fuse ist auf interner 8MHz, mit längster Anlaufzeit. Die Optimierung stand aber auf -O1 habs nun auf -Os versucht, jedoch auch erfolglos. Ich hab nun nochmal versucht, nachzuverfolgen, ob er die _delay_ms aufruft, jedoch verschluckt er sich irgendwo in meiner
-
Thread
Umstieg von Arduino auf "klassische" IC Programmierung
optimieren, das noch nicht mal funktioniert. Das ist Unsinn. http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung >Mich stört >auch, dass ich eigentlich nicht weiß, was in diesen Labraries vor sich >geht und "es einfach funktioniert". Das ist der Sinn der Sache
kann ich optimieren? Was spare ich dadurch ein? Zeit? Geld?(Plus) Welchen Aufwand kostet die Optimierung? Zeit? Geld? (Minus) Dann stellst du fest, dass sich gerade für kleine Stückzahlen vermeintliche Optimierungen von ein paar kB Flash und ein paar Euro für ein Evalboard nicht lohnen! Extrem
-
Thread
GCC und LDS/STS auf Attiny10
Ich kämpfa gerade mit avr-gcc 4.7.2 und einem Attiny 10. Der Compiler weigert sich, die kurzen 8-bit LDS und STS für den Speicherzugriff zu nutzen, sondern erzeugt stattdessen einen indirekten Zugriff über das Z-Register. Das ist
ganze Reduced-Core-Kram liegt derzeit einzig und allein bei denen. Den patchen sie selbst in den GCC rein, und meines Wissens ist er nach wie vor in einem reichlich halbbackenen Zustand.
-
Thread
C++ auf Mikrocontrollern
, siehe [[STM32#GCC]] und [[ARM GCC]].
Compiler noch kein C++11 >> unterstützt :-(. > Ja, richtig. Den STM32 kann man auch wunderbar mit dem GCC > programmieren, siehe STM32: GCC und ARM GCC. Ja, richtig. Bei privaten Projekten nutze ich den GCC auch. Beruflich bin ich aber leider gebunden :-(. Mein aktueller C Code ist auf jeden Fall
-
Thread
Ist Arduino verpönt?
und Großes vorhat sollte dieser jemand den qualvollen Weg über Assembler (für die Struktur) und AVR-GCC nehmen. -SE
Großes vorhat > sollte dieser jemand den qualvollen Weg über Assembler (für die > Struktur) und AVR-GCC nehmen. Das ist ja gerade das Problem: Die Einstiegshürden auf dieser Ebene werden nicht niedriger. Da würde ich schon eher mit einer Arduino-Entwicklung anfangen und, sobald es läuft, zwecks Optimierung
-
Thread
LCD EA W204B-NLW
versaubeutelt" werden. Deswegen habe ich mich da auch noch nicht ran getraut. Was hat das mit der Optimierung immer auf sich und wo find ich die im Atmel Studio 6.1? Danke
nehmen muss??? Vielen Dank Das kann ich dir nicht ausführlich erklären, aber bei diesem link http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html wird es erklärt. Leider alles Englisch.
-
Thread
AVR-Programm muss effizienter werden
besser geeignet ist schon die richtige von diesen Möglichkeiten wählen, wenn man nicht gerade die Optimierung ausschaltet, oder nur eine handvoll cases hat. Der ist ja nicht doof. :)
Die Optimierung ist schon beeindruckend, welches O Level ist das? Im Grunde kann man dann auch durch brutales ASM nicht weiter per Hand optimieren. Allerdings stellt sich mir dort die Frage, ob der Switch wirklich