-
Thread
AVR Studio 6 und Bootloader
Oliver schrieb im Beitrag #3138768: > Ohne Optimierung wird der Index von mcucr_write zur Laufzeit > ausgewertet, das dauert halt länger als 4 Zyklen. Nachtrag: Zumindest der gcc 4.3.3, den ich hier auf dem Rechner habe, erzeugt ohne Optimierung auch ohne Array solch umständlichen Code, der schafft die 4 Zyklen ohne Optimierung auch ohne Array nicht. Oliver
-
Thread
OLED Display 128x64 - Fehlermeldung "text will not fit in region text"
> extrahieren, das nennt sich dann u.a. "function level linking". Damit der allseits beliebte gcc und gnu ld das machen muss man ihnen mit den erwähnten Flags -ffunction-sections -fdata-sections und -Wl,--gc-sections unter die Arme greifen. Ob die Flags nun im gcc Spec-File steht, man es auf
Jack schrieb im Beitrag #5204780: > Damit der allseits beliebte gcc und gnu ld das machen muss man ihnen mit > den erwähnten Flags -ffunction-sections -fdata-sections und > -Wl,--gc-sections unter die Arme greifen. > > Ob die Flags nun im gcc Spec-File steht,
-
Thread
Mega88 SPI Soft->Hard Jetzt Flash zu klein,HILFE
ein paar Bytes rausquetschen kannst: http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung
noch eine Kopie behalten, /falls/ die Funktion von außen doch noch aufgerufen wird (hier könnte der GCC-Parameter "-ffunction-sections" helfen, falls der noch nicht im Makefile (oder den AVR-Studioproject-settings) steht). Vielleicht hilft dir noch [[AVR-GCC-Codeoptimierung]], Aber mehr fällt mir auch
-
Thread
Webseite für die Einarbeitung STM32 auf Deutsch
Hardware z.B. Sensoren in meine Simulationen mit einbinden. Das Hilft bei der Visulaisierung und optimierung komplexer Regelungen. Weißt du zufällig wo ich die Cpp bezüglichen Einstellungen für den GCC nachlesen kann? Ich würde mit gern ein genaueres Bild machen was ich Abschalten kann und was ich
/github.com/texane/stlink (zum > Programmieren und gdb-Anbindung) unter Linux, dazu arm-none-eabi-gcc Genauso hatte ich mir das gedacht. Als IDE dachte ich an Eclipse denn dort habe ich bereits arm-none-eabi-gcc zum laufen gebracht.GDB habe ich aber bisher noch nichts gemacht. Das Beispiel für
-
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
Wieso wird alles kompiliert?
ist das ganze > halt viel einfacher. Was nicht benötigt wird, wird auch nicht kopiliert. Der AVR-GCC kann auch eine über alles Optimierung vornehmen: [pre] -Wl,--relax --combine -fwhole-program [/pre] Alle nicht benötigten Daten/Funktionen fliegen raus, alle nur einmal benutzten Funktionen werden
http://www.mikrocontroller.net/articles/GCC:_unbenutzte_Funktionen_entfernen
-
Thread
Lightweight WS2811/WS2812 Library
Hauptprogramm. Die LIB ist die aktuelle aus dem Git. Hier mal die Meldungen beim Compilieren. AVR gcc ist 4.8.3., aktuell aus Opensuse Leap 42.2. [code] -------------- Build: Release in Stripe_ATMega8 (compiler: GNU GCC Compiler for AVR)--------------- avr-gcc -Wextra -Wall -DF_CPU=16000000UL
Label. Das wird durch den Doppelpunkt deklariert "%=" erzeugt einen unique identifier. https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html [code] " lsl %[dat], #1 \n\t" // [ 4] => OK " str %[maskhi], [%[set]] \n\t" // [ 5] => OK " bcs one%= \n\t" // [ 6]
-
Thread
Gleitkommaberechnung
> Warum werden die MUL Befehle denn nicht benutzt? Das kann ich gar nicht glauben. Bsp: avr-gcc, aktuelle Version, ATMega16, Optimierung auf Os j = 58 * i; aa: 89 81 ldd r24, Y+1 ; 0x01 ac: 9a 81 ldd r25, Y+2 ; 0x02 ae: 2a e3 ldi r18, 0x3A ; 58
Mambo-Zambo mit der Hilfsfunktion dient nur dazu, den Compiler an einer Constant-folding Optimierung zu hindern: <c> void foo( int* a ) { *a = 5; } int main() { int i; int j; foo( &i ); j = 5 * i; foo( &j ); while( 1 ) ; } </c>
-
Thread
Pointer in STRUCT wollen einfach nicht funktionieren! (AVR-GCC)
Hallo Leute, ich werd noch blöde.. :) Ich versuche gerade einen kleinen Modbus Slave aufzubauen und kämpfe gerade mit Pointern die auf structs mit weiteren Pointern ziele sollten.. Klingt kompliziert, ist es aber nur wenn man den Wald vor lauter Bäumen nicht mehr sieht.. :P Die Deklaration meines Structs: [c] typedef struct { uint8_t slave_address; uint8_t function_code; uint16_t *data; uint16_t crc; } modbus_frame_t; [/c] Nun würde ich gerne dieses Struct in meiner Empfangsroutine mit Daten füllen.. Dafür teste ich gerade einen Code wie den folgenden.. Der Compiler
-
Thread
Größe eines externen Arrays in C
Elemente\n", (unsigned long)nElemente ); return 0; } [/c] Ausgabe: [pre] klaus@lap7:~$ gcc -Wall main.c source.c klaus@lap7:~$ ./a.out Das Feld hat 3 Elemente [/pre]
Und der angenommene Code-Bloat ist ein viel genanntes Pseudo-Argument, was durch die bessere Optimierung oft (mehr als) wett gemacht wird.
-
Thread
itao nimmt zuviel speicher
makefile eingebunden oder die schlanke integer Mathe-Library? Benutzt du die Optimierungsoptionen des GCC? Kurz: Wie sieht dein makefile aus?
> //unbedingt Kompiler Optimierung einstellen & F_CPU frequenz angeben Hast du den Hinweis in dem Kommentar befolgt (Optimierung aktivieren)? Andere Anmerkung, die mit deinem aktuellen Problem nichts zu tun hat, aber wahrscheinlich
-
Thread
Referenzen in C
mitteilen, etwa wenn sie nur in einem Modul gebraucht wird (static). Vielleicht bringt das schon die Optimierung. Und hast mal den Code angeschaut, den avr-g++ für eine Referenz macht? Ich glaub nicht daß der besser ist als mit Zeigern.
Programmieren ist zwar schön aber das was am ende Rauskommt ist leider selten optimal (was die optimierung angeht). Der Computer kann halt noch nicht denken.
-
Thread
Frage zur Programmierung.
Danke erstmal... Ich arbeite mit AVR-Studio + GCC Habe leider nur Java und PHP gelernt, C basiert nur auf Selbststudium. >Tobias Jenatschke schrieb: > Da steht ja Code drin... wegoptimieren kann er die nicht... >Woher weißt du das? >Comopilier das mal ohne Optimierung (-O0), das sollte helfen. Ich vermute das nur, da es ja direkt im Main funktioniert.... Ich versuch heute abend mal den gesamten Code hier zu rein zu posten...
-
Thread
Welche IDE um Controller zu programmieren/flashen
noch gar keine AVR. Makefiles schreibe ich auch schon länger, als es die AVR gibt. Und der Rest (avr-gcc, avr-gdb, avrdude) ist mit einem Tastendruck in aptitude installiert.
XC32 weder Lizenz-Bedingungen für die einzelnen Lizenzen, noch eine andere Information zu der Optimierung. Free geht nur bis -O1, -O2 ist ab PRO.
-
Thread
uint32_t bit für bit interpretieren - wahrscheinlich typ problem
0x12345678 dann ist ret 0xffff5678. Hat jemand eine Idee wo das Problem liegt? Compiler ist avr-gcc 4.5.3 auf Ubuntu 12.04LTS.
können je nach Compiler, Architektur (8/16/32/64? bit) und eingestellten Optionen (wie packing, Optimierung) variieren. In dem speziellen gezeigten Fall mag es funktionieren. Adib.
-
Thread
LCD-lib ohne R/W
die Lib von P. Fleury verwendet, nach Änderungen in der SW und fehlerfreiem kompilieren mit neuem GCC ergeben sich allerdings Probleme. Ohne Optimierung läuft das Programm einwandfrei, ist aber zu groß für den Kontroller Mega8 (Test mit Mega32). Mit Optimierung geht am Display nichts mehr ausser gelegentlich
restliche Programm etwas dazugekommen. Der Speicherplatz ist voll daher wollte ich es mit dem neuen GCC machen, mit dem alten gehts nicht. Lesen ist nicht wichtig da nur alle 2sec aktualisiert wird und auch nicht zeitkritisch. Wie müsste man denn die Lib umrüsten?
-
Thread
Projekthilfe gesucht - Parallela Cluster (Supercomputing :))
nicht programmieren. Es gibt genuegend Solver (glpk, lpsolve, cplex ...). Da durch solche Optimierungen viel Geld verdient werden kann, wurde schon eine Menge Hirnschmalz investiert.
inkl. Start des Programm sowie Beendigung, gemessen durch unix Time programm. Diesmals mit gnu optimierung, gcc t4.c -std=gnu99 -mtune=pentium-m -mfpmath=sse -Ofast -funroll-loops -march=native -flto Der Grund für iron<60 ist, dass am Ende noch Berichtigungen gemacht werden, und eigentlich die
-
Thread
cpp memory leaks vermeiden
ganze lasse ich auf folgenden Systemen laufen: * Arduino Nano (Atmega328), 2k Ram, 32kFlash gcc version 5.4.0 (GCC) gcc version 7.3.0 (GCC) * Pipico2, 520k Ram gcc version 14.2.0 (GCC) * PC, 16GB Ram gcc version 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04) Der Atmega hat den
landest und wenn nicht, warum nicht. Die Funktion ist ursprünglich hier definiert: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/src/c%2B%2B11/functexcept.cc
-
Thread
delay funktion
schätze, dass der compiler dies braucht, damit die funktion korrekt arbeitet?) Wo kann man die optimierung einschalten? Ich habe das hilfe menue des AVR studio bemüht und optimize eingetippt. Dort kommt aber nur etwas zum stk 500.
A.D. schrieb im Beitrag #1884930: > Wo kann man die optimierung einschalten? > Ich habe das hilfe menue des AVR studio bemüht und optimize eingetippt. > Dort kommt aber nur etwas zum stk 500. Im AVR-Studio gibts ein Dropdown-Menü mit so Sachen wie "-O2
-
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
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
GCC AVR Fehler
Hallo! Ich habe da ein dickes Problem im GCC AVR gefunden. Ich will einen String nach einer Reihe von Schlüsselwörtern durchsuchen. Wenn die Schlüsselwörtern im Ram stehen und unter verwendung von strcasecmp geht das auch wunderbar. Kommen
kennt. Bei Strings[i] geht das dann klarerweise nicht mehr. > Ich habe da ein dickes Problem im GCC AVR gefunden. Wider nix. War doch nur ein Programmierfehler. (Das Umcasten von cliline_ram auf const char* kannst du dir sparen. Das const ist an dieser Stelle die Zusicherung der Funktion, dass
-
Thread
ATtiny85 - bei 3.5kB ist Schluss
abweichen, greift diese Optimierung natürlich nicht mehr.
gibt es leider _flash, usw. nicht. AFAIK schon, denn der Compiler unten drunter ist auch der avr gcc.
-
Thread
_delay_ms macht das programm 3,5 kB groß
Ins blaue geraten: Optimierung abgeschaltet. Kompilier' das Programm mal mit -Os
160bytes ! das geht doch ^^ Prüf aber erst mal in der lst Datei ob die _delay_ms durch die Optimierung nicht komplett verschwinden ist.
-
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
ATMega328, komisches Verhalten bei fast vollem Speicher
der Minimum-Code von hier: http://rn-wissen.de/wiki/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc#Dynamischer_RAM-Verbrauch
könntest dir auch die ersten Zeilen des Assemblercodes angucken bzw. mit dem Ergebnis des neuen avr-gcc vergleichen.
-
Thread
STM32 komisches Verhalten bei include und leerer Funktion
coocox 1.7.7 mit gcc 4.9 hat keine Probleme mit dem Projekt.
demselben Evalboard nicht. Zwischenzeitlich habe ich avon Win7 auf Win10 umgestellt und CoIDE/gcc neu installiert.. Ob das was damit zutun hast? Mich kotzt das hier an..
-
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
Geschwindigkeit?
Schleifendurchlauf. Das ist für eine RISC-CPU ganz o.k. Mit -Os solltest Du etwas besser werden. Andere Optimierungen sollte man nur dann nehmen, wenn man auch weiß warum. Peter
Compilezeit berechnet und als Konstante in > den Code eingefügt werden. sobald irgend eine optimierung angeschaltet ist wird das ersetzt.
-
Thread
C++ Librarysammlung?
jede einzelne Version inkompatibel ist, ja. Die Änderung an std::string ist C++ selbst Schuld, nicht GCC/libstdc++.
einzelne Version inkompatibel ist, ja. Die Änderung an > std::string ist C++ selbst Schuld, nicht GCC/libstdc++. Da stimme ich auch zu.
-
Thread
Einheitliche Regel für in C erstellte Variablen, Typen etc
return count; } [/c] Mal mit drei verschiedenen Typdefinitionen compiliert: [pre] $ avr-gcc -Os -mmcu=atmega328 -S -o default.s test.c $ avr-gcc -Os -mmcu=atmega328 -DTYPE=int -S -o int.s test.c $ avr-gcc -Os -mmcu=atmega328 -DTYPE=int_fast32_t -S -o int_fast32_t.s test.c $ md5sum *.s
Es gibt beim gcc & clang noch __int128_t und bei c23 _BitInt(N) (Wobei es für N eine obergrenze gibt, über der das ib ist.)
-
Thread
Erste schritte mit AVR
. EDIT: Die Wartefunktionen aus <util/delay.h> funktionieren aber nur richtig, wenn sie mit Optimierung (Compiler-Option -O1, -O2, -O3 oder -Os) übersetzt werden. Ausserdem benötigen sie das Makro F_CPU. Letzteres kannst du im gcc-Plugin von WinAVR in den Eigenschaften einstellen. Ansonsten halt Compileroption
einfacher einen kompletten Code zu haben, der nicht von irgendwelchen Einstellungen (ausser der Optimierung) in der Entwicklungsumgebung abhängt. Wenn die Optimierung nicht richtig eingestellt ist, ist es auch nicht weiter schlimm, stimmen die Zeiten nicht, aber blinken sollte es trotzdem. Erst mal
-
Thread
MMC SD library FAT16 FAT32 read write
lol moment bei windows wird das warscheinlich eher c:\WinAVR\bin\avr-gcc.exe heißen... mit optimierung s wird der code jetzt wieder kleiner als mit 2 und der geschwindigkeitsverlust geht auf 10KBytes /sec zurück. also von 165 auf 155KB damit kann ich leben (atmega 168
Der gcc war in dem AVR-GCC package für den Mac. http://www.obdev.at/products/crosspack/index-de.html Das ganze läuft auf nem Atmega8.
-
Thread
Jitter in ISR von Atmega
Ich habe GCC 4.7.2, ebenfalls mit -Os
Der Meister Joda des avr gcc ;-) https://www.mikrocontroller.net/user/show/gjlayde
-
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
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
LDO Regler ADP3339 überbrücken(?)
immer eine Warnung geworfen wird: irgendwas mit 'delay.h' funktioniert nicht richtig, wenn keine Optimierung eingeschaltet ist. Ich habe dann mal die Optimierung auf 'Grösse' eingeschaltet, und das Ding laufen lassen. Die Warnung war zwar weg, aber dafür spielte das Display verrückt! Die Optimierungsstufen 'Geschwindigkeit' und 'Mittel' brachen das gleiche Ergebnis. Erst ohne Optimierung zeigte die Kiste wieder was an, weil dann das Displaytiming wieder stimmte! Die haben da so lange dran rumgebastelt, bis das auch ohne Optimierung funktionierte! Naja. Also. Das Display.
-
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
AVR Studio Bug Breakpoin!
Beitrag #3666072: > Was mache ich falsch? c-hater hat's gut zusammengefasst: einfach die compiler optimierung abschalten, dann klappts auch mit den breakpoints. Tipp: Du solltest auf einheitliche schreibweisen achten... Sec_Kopie, Min_KOPIE... Grüße
Wie kommt ihr eigentlich drauf, dass es an der Einstellung für die Optimierung liegen muss? Ich gehe mal davon aus, dass er GCC verwendet und beim AVR-Studio sollte die Defaulteinstellung "-O0" für die "Debug"-Konfiguration sein. Ich hätte eher die Vermutung, dass aus
-
Thread
AVR Struct Zugriff
nicht, da solcherlei Operationen nicht klar definiert sind. Vielmehr sind läuft es im aktuellen avr-gcc auf denselben Assembler-Text hinaus. Wobei die Variante mit den Flags, die Floh oben vorgeschlagen hat, noch deutlich langsamer ist, da der gcc die Bitoperation standardmäßig auf einen Integer aufweitet
2) y = 2; else if (x & 4) y = 3; } [/c] Ohne Optimierung ist die Variante mit dem Bitvektor, wie oben schon beschrieben, effizienter.
-
Thread
Rechen-Zuweisung von Variable in GCC
irgendwie stehe ich auf dem Schlauch - geb gerne zu das mein C eingerostet ist, aber warum der WINAVR-GCC die folgende Zeile nicht ausführt bzw. anscheinend erst gar nicht compiliert - verstehe ich nicht TimerCnt += 32/8; //_TIME_CONST_US_TIMER_CLOCK (32); // Diese Zeile erscheint in keinster
Dann optimiert dein GCC schlecht. Bei mir kommt raus: Version mit "Var=32/8": [avrasm] .L10: ldi r24,lo8(4) ldi r25,hi8(4) .L9: sbiw r24,1 brne .L9 rjmp .L10 [/avrasm]
-
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
Erkennung Programiersprache
assembler umwandeln. an den PUSH und POP erkennt man dann später eventuell die programmiersprache - gcc hat da zB eine eigene signatur.
avr schrieb im Beitrag #3030373: [Thema was der avr-gcc 4.7.2 alles nicht kann] > -rcall+ret durch rjmp ersetzen Na, dachte ich mir, probier ich das gleich mal mit dem avr-gcc 4.7.2 aus: [c] int ext_f(int x); int f(int x) { return ext_f(x
-
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
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
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
Makros versus Funktionen
Stefan schrieb im Beitrag #3333210: > Aber > dann klappt die Optimierung nicht mehr so gut, oder doch? Funktionen sind Makros grundsätzlich und immer vorzuziehen, falls irgendwie möglich. Makros haben keinen Typ, keinen Scope, bringen die Syntax durcheinander etc. Wenn man inline-Funktionen verwendet klappt die Optimierung genau so gut (wenn der GCC sich trotzdem weigert die Funktion zu inlinen, __attribute__((always_inline)) dranschreiben). Headerfiles mit Tausenden #defines (siehe CMSIS...) sind wie ein Feld
-
Thread
ATTINY13: Noch ein CLKPR Unfall - bei HVSP Programming
möchtest. Für Vorteiler 1 müsstest du als zweiten Schritt eine 0 schreiben. Funktioniert aber im AVR-GCC nur dann, wenn du die Optimierungen einschaltest, sonst wird der Code u. U. zu langsam für die vier- Takte-Zeitforderung. Besser ist daher: [c] #include <avr/power.h> ... clock_prescale_set
Jörg Wunsch schrieb im Beitrag #1717346: > Funktioniert aber im AVR-GCC nur dann, wenn du die Optimierungen > einschaltest, sonst wird der Code u. U. zu langsam für die vier- > Takte-Zeitforderung. Besser ist daher: > #include <avr/power.h> > > ... > clock_prescale_set
-
Thread
Statische Bibliothek erstellen in C++
in das Build-System ein was es besser macht. Nicht den Code unlesbar machen um fragwürdige Optimierungen zu erzielen, das ist fast immer ein Fehler.
Anwendung braucht ungepackt rund 3 Mb, gepackt mit Winrar knapp 800 Kb. Statisches Linken, Optimierung -o3 mfg
-
Thread
Ansteuern von 300 RGB-LEDs
man weiss wie ;-) Bezieht sich deine Antwort auf die im [[Soft-PWM]]-Artikel beschriebenen Optimierungen, oder meinst du etwas darüber hinaus gehendes?
Alexander Horst (hoal) >Bezieht sich deine Antwort auf die im Soft-PWM-Artikel beschriebenen >Optimierungen, Ja. Aber ich bin offen für weitere Verbesserungen. MFG Falk