-
Thread
Minimalbeispiel zur Darstellung effizienter Schleifen
Ja, Schleife ist sinnlos -> weg damit. Macht quasi jeder optimierende Übersetzer so. Für GCC: Option -O0 (Oh-Null).
. Ergebnis der Optimierung: ret Effizienter geht es kaum noch, man könnte nur noch inlinen und sämtliche Aufrufe von main() rauschmeißen [was aber wohl kein Compiler machen würde, weil ne leere Main ja nicht gerade üblich
-
Thread
BCD auf C: was mache ich falsch?
wenigen Fällen ist ein Algorithmus kürzer UND schneller. https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Wie
Falk B. schrieb im Beitrag #4365754: > https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung > > https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Wie Ich habe das gelesen... Also, die Variante ohne Schleifen hat auch Recht
-
Thread
Polling / Kommunikation optimieren
hält (lieber Stack nutzt) und so die > Verknüpfungen/Schleifen evtl. schneller werden? Der AVR-gcc macht das eigentlich sehr gut.
zweitens würde ich in diesem Fall noch eine dritte Anweisung erwarten, nämlich out, drittens macht GCC daraus normalerweise (angenommen, | statt & war gemeint) ein sbi PORTA, PA1. Vielleicht Optimierungen aus? > Deshalb lade ich beim Funktionsbeginn den Portzustand in Buffer > Variablen, die ich
-
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
arm gcc Arrayzugriff
Welche GCC-Version kommt zum Einsatz? Mit welchem Programm wird das Programm auf den µC geladen? Ist es zufällig das stm32vldiscovery? Steht ein Debugger zur Verfügung? Marco Weinrich schrieb im Beitrag
Hallo Roland, ich benutze den gcc Version 4.5.2 unter Linux. Einen Debugger besitze ich keinen, und auf dem Board sitzt ein STM32F103RBT6.Flashen tue ich mit stm32flash. Wie schalte ich die Escalation ab? (bin noch Arm-Anfänger)
-
Thread
Schon wieder volatile -_O
weiterkam. Alle Variablen sind global (außer die in der Regelung und in der Filterung). OHNE Optimierung funktioniert die Regelung wie erwartet auch OHNE volatile bei den Filter-Variablen. MIT Optimierung hilft kein "volatilisieren" der globalen Variablen, nur der lokalen in der Filterung... >
kennen. Vielleicht mal ""stromregler() { return FIXED_DEBUG_WERT; }" Oder aber: .lss mit/ohne Optimierung vergleichen.
-
Thread
Bosch BMP280: Umrechnungen vereinfachen?
Implementierung. Das ist ist nun nicht soo wild. > > Und falls doch, gibt es etliche mögliche Optimierungen für den Fall, daß > die Zahl der Schiebebits>1 ist, so daß eigentlich nur selten wirklich > geschoben wird. Leider optimiert der GCC bei Schiebeoperationen mit >16 bit schlecht bis gar nicht
ist deine Formulierung falsch. Es ist nicht auf dem AVR langsam, sondern in C, zumindest wenn der GCC als Compiler verwendet wird. Daraus kann man ganz zwanglos den logischen Schluß ziehen, daß C im Allgemeinen oder zumindest der GCC im Besonderen schlicht die falsche Wahl ist, wenn man einen AVR8
-
Thread
ATmega16 + ATmega32 in C Programmieren
Du kannst mit AVR Studio einfach ein Projekt anlegen und wählst AVR.GCC als Compiler aus. Den Rest (einschliesslich makefile) macht avr-studio für Dich. Einfache Beispiele findest Du hier im avr-gcc tutorial (siehe links auf der linken seite)
Die Spalte links, wo steht "AVR-GCC-Tutorial"
-
Thread
AtmelStudio 7 - Long variable übergeben
Schau mal hier, https://gcc.gnu.org/wiki/avr-gcc was bei einem 8-Bit-Prozessor mit GCC long bedeutet (oder versuche mal "long long" :-) )
Dieter F. schrieb im Beitrag #5193791: > Schau mal hier, > > https://gcc.gnu.org/wiki/avr-gcc > > was bei einem 8-Bit-Prozessor mit GCC long bedeutet (oder versuche mal > "long long" :-) ) was meinst du damit? eine 10 passt doch wohl in 32bit rein.
-
Thread
Fehlermeldung Bedeutung
was bedeutet folgende Fehlermeldung: p:\winavr\bin\..\lib\gcc\avr\4.1.2\..\..\..\..\avr\bin\ld.exe: region text is full (vario.elf section .text) es gibt diese wenn ich da rechnen will: pow(variable,0.12938); zu anspruchsvoll für 8-Bit mikrocontroller? ach
0.12938); >zu anspruchsvoll für 8-Bit mikrocontroller? ach ja verwende avr studio. Optimierung eingeschaltet? Welcher AVR ist es denn? MFG Falk
-
Thread
Umgang mit Volatile Variablen im Code, beispiel "atoi"
Frage: Die beiden Variablen Volatile oder ist es nicht notwendig? Theoretische Frage: Wenn die Optimierung ausgeschaltet ist, hat das Volatile auch keinen Sinn mehr oder?
> Mit der Optimierung hat das nichts zu tun. Mmmh. Naja. So richtig korrekt ist auch nicht. Natürlich geht es darum, ob man dem Compiler erlaubt davon auszugehen, dass sich ein Wert nicht geändert haben kann oder
-
Thread
avr-compiler erkennen
http://www.google.de/search?q=avr-gcc+predefined+macros
OPTIMIZE__ 1 #define __STRICT_ANSI__ 1 #define __VERSION__ "4.3.2" [/c] Es wurde also mit avr-gcc 4.3.2 erzeugt. Optimierung war aktiviert (auf Größe), der µC gehört zur Familie 4 (ATmega8, ATmega88, ...), er verfügt über Multiplikationsbefehle, MOVW und die erweiterte Version von LPM, arbeitet
-
Thread
Wann ist bei einem AVR der Flash-Speicher genau voll?
enthalten, oder muß ich bei kompilierten 32768-256=32512 Byte aufhören zu programmieren? (oder Optimierungen suchen, hab schon vieles in's EEPROM ausgelagert)
sparen kann und zum generellen verständnis wo was gespeichert wird empfehl ich dir mal das AVR GCC Tutorial - da steht einiges drin wo wann was gespeichert wird. gruß, auch sven
-
Thread
Fehler im gcc, im Chip oder im Hirn?
Interrupts? 'volatile' vergessen? Warum struct, wenn Du eh nur einen Member hast? Ansonsten, welche gcc Version? Ist das im Simulator oder auf realer HW? Welcher µC?
/avr-gcc/ Hier ist der zugehörige Thread: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631
-
Thread
C++ Codeoptimierung Tastatureingabe
Programm ohne jeglichen Kommentar. > Schon lange her, dass ich das mal erleben durfte. Ok Optimierung Nr.1 :)
eigentliche Funktionalität wird tatsächlich in völlig identischen Code > übersetzt. Beim mir ist er mit gcc-trunk wenige Instruktionen kürzer. Aber das ist auch völlig egal. Dieses Gequatsche, man müsste als Programmierer die Optimierungen des Compilers erledigen, ist doch einfach nur Blödsinn. Die Compilerbauer
-
Thread
ARM Cortex & GCC: Worauf achten für "optimalen" Code?
:) Wo ich nun eher Anlaufschwierigkeiten habe ist der GCC, beispielsweise wie die Variablen bzgl. Speichermanagement gehandhabt werden, wie Parameterübergabe stattfindet, etc. Ich komm leider momentan mit der in der LPCxpresso-IDE mitgelieferten GCC-Hilfe
A. K. schrieb im Beitrag #2111097: >> ist. Wie ist das beim GCC & ARM? Wenn ich vier 8-Bit-Variablen (char) >> anlege, packt der GCC das automatisch in ein 32-Bit-Wort, oder verwendet >> er vier Mal ein 32-Bit-Wort? > > Register: jede einzeln in ein Register
-
Thread
Attribute used im gcc
--includedir=/usr/lib/gcc/riscv32-unknown-elf/8.5.0/include --datadir=/usr/share/gcc-data/riscv32-unknown-elf/8.5.0 --mandir=/usr/share/gcc-data/riscv32-unknown-elf/8.5.0/man --infodir=/usr/share/gcc-data/riscv32-unknown-elf
without-isl --disable-libsanitizer --disable-default-pie --enable-default-ssp Thread-Modell: single gcc-Version 8.5.0 (Gentoo 8.5.0-r1 p2) COMPILER_PATH=/usr/libexec/gcc/riscv32-unknown-elf/8.5.0/:/usr/libexec/gcc/riscv32-unknown-elf/8.5.0/:/usr/libexec/gcc/riscv32-unknown-elf/:/usr/lib/gcc/riscv32-
-
Thread
WinAVR+Eclipse->region text is full
Eclipse3.3"+"CDT4"+"avr-eclipse"+"WinAVR": [pre] Building file: ../y1.c Invoking: Compiler avr-gcc -Wall -g -O2 -Os -c -mmcu=atmega88 -DF_CPU=16000000 -o"y1.obj" "../y1.c" Finished building: ../y1.c [/pre] Linkerausgabe aus "PN"+"MFile"+"WinAVR": [pre] Linking: x.elf avr-gcc -mmcu=atmega88
hallo, hat vielleicht gar nicts damit zu tun, aber: >avr-gcc -Wall -g -O2 -Os -c -mmcu=atmega88 -DF_CPU=16000000 -o"y1.obj" "../y1.c" was bewirkt die zweimalige angabe der optimierung .. *grübel* bye kosmo
-
Thread
neuen Datentyp (10-bit) zur Speicheroptimierung erstellen
nicht mal 8 Bit um mehr als 1 Bit am Stück schieben. Er kann auch 4 Bit und 8 Bit am Stück und GCC weiss das. ;-) Solange die Shiftcount konstant ist, und der Datentyp nicht zu breit, gibt GCC sich respektable Mühe, effizienten Code auszuwerfen.
A. K. schrieb im Beitrag #5517177: > GCCs Optimierung der Shifts für AVR betrifft 16-Bit Daten. Das ist > hierfür breit genug. > > Ein besserer µC ist dafür freilich von Vorteil. Wenn der Dividieren > kann, dann geht auch die erwähnte und sparsamste
-
Thread
MSP430 IAR: String1 in String2 Kopieren??
Sollte wohl genauer lesen ;) Ich wollte für mein Projekt mal diese String-Funktionen benutzen (GCC). Als ich sie zugelinkt hatte, war das Programm gleich ziemlich aufgeblasen, dann hab ich mir das Vergleichen der Strings selber geschrieben, hat viel weniger gebraucht. Vielleicht muss man dem GCC
AVR und dem MSP430 > Compiler. Ich arbeite nur mit den MSPs. Das könnte sein. Ich benutze den gcc für AVR. Ob und wie der Linker diese Optimierung machen kann, hängt beim gcc auch davon ab, wie diese Libraries aufgebaut werden. In der AVR Version kann er es offensichtlich.
-
Thread
"extern" bei unterschiedlichen .c macht Probleme
Variablen hinterlegt. Normalerweise hat er aber bei derart einfachen Konstanten und aktivierter Optimierung keinen Grund dazu.
> Normalerweise hat er aber bei derart einfachen Konstanten > und aktivierter Optimierung keinen Grund dazu. Darauf verlasse ich mich dabei natürlich, dürfte bei einem anständigen Compiler auch keine so abwegige Annahme sein.
-
Thread
MikroC for PIC32
kostenpflichtigen Lizenz machen konnte, ohne Ärger zu kriegen. Zumindest beim früheren ebenfalls auf GCC basierenden C30 waren sie da nicht sehr phantasievoll vorgegangen.
mir einwandfrei. die player brauchen ca. 25-35% rechenzeit bei 128kbit. hat also nichts mit der optimierung zu tun.
-
Thread
Assemblerbefehle ROL /ROR in C?
zu verwenden, dann sollte es auch nicht mehr so schwierig sein ihm ror beizubringen (Peephole-Optimierung?).
Was soll der Compiler anderes als LSR aus einer Zeile mit >> machen? Ob die "peephole"-Optimierung ein ROR aus dem ganzen Konstrukt bastelt, kann ich nicht beurteilen*. Kann man das (als Normalsterblicher) beim GCC in irgendeiner Weise beeinflussen? Nach dem Motto Code-Fragment wird von Hand
-
Thread
AVR-GCC Inline-Assembler: const Pointer / Arrays etc. als Operanden
http://www.rn-wissen.de/index.php/Inline-Assembler_in_avr-gcc
kannst du natürlich genauso machen. > Das möchte ich gern in Inline-Assembler übernehmen Um was GCC-generiertes in Inline-Assembler zu übernehmen, ist ein Disassembly ne schlechte Vorlage. Besser ist, die Compiler-Ausgabe selbst zu verwenden, evtl. nach Hand-Optimierung.
-
Thread
Warum springt er nicht in die while-schleife?
gelesen ODER er hat keine bekommen, weshalb er hier nachfragt. Oder er hat sie nicht eingeschaltet. gcc warnt bei sowas: [c] int main() { int i = 0; while (i < 100); { i++; } } [/c] [code] Ausgabe von gcc bei aktivierten Warnungen: kaputtelooop.c: In function ‘main
Typisch C/C++: Jeden Mist muss man extra einschalten, egal ob Warnungen oder Optimierungen, und ganz fies, viele Warnungen werden ohne eingeschaltete Optimierungen nicht gefunden. C/C++ ist einfach nur Steinzeit. Viele andere Systeme machen es vor, wie man brauchbare Compiler baut
-
Thread
Hilfe nötig für vereinfachung einer c Funktion
Ich wäre dankbar wenn jdm erfahrenes einfach Tipps geben kann oder eine Optimierung meiner Lösung durchführt? Programm soll Macher auf einem esp laufen
Beitrag #6797532: > Ich wäre dankbar wenn jdm erfahrenes einfach Tipps geben kann oder eine > Optimierung meiner Lösung durchführt? Immer noch? Tipp und Optimierung hab ich doch schon gegeben! Aber gut, etwa so: [code] #include <stdio.h> #include <string.h> void convert (char* from, char*
-
Thread
STM32: Umstieg von IAR auf den neuen CUBEIDE
also ich würde beim IAR bleiben, da der gcc Compiler ja wohl nicht so optimal ist. Debuggen kanst du das Program ja mit verschiedenen Debuggern wenn du .elf File erstellst. Also ich wundere mich manchmal schon, was für ein Overhead aus dem gcc
embedded-studio/ Sascha schrieb im Beitrag #6576830: > also ich würde beim IAR bleiben, da der gcc Compiler ja wohl nicht so > optimal ist. Die Unterschiede sind was die Compiler Optimierung angeht tatsächlich heutzutage gar nicht mehr so groß.
-
Thread
AVR-GCC: Ist > schneller als >=?
Bartli schrieb im Beitrag #2463072: > wie man an gcc's Assembleroutput rankommt gcc -S -o asm_output.s quellcode.c Vermutlich wolltest Du es selber wissen :-)
Bist du das jetzt extra im gcc Manual nachschlagen gegangen?
-
Thread
TÜV-SÜD-zertifizierte MPLAB-Tools
Der XC32 ist ja anscheinend GCC-basiert. Heißt das jetzt etwa, dass der ARM GCC und G++ für sicherheitskritische Dinge nutzbar ist, und man dort dann auch aktuelle Sprachstandards nutzen kann (C18, C++17)?
Programmierer schrieb im Beitrag #6117665: > Der XC32 ist ja anscheinend GCC-basiert. Heißt das jetzt etwa, dass der > ARM GCC und G++ für sicherheitskritische Dinge nutzbar ist, und man dort > dann auch aktuelle Sprachstandards nutzen kann (C18, C++17)? GCC? Bist du
-
Thread
Encoder auswerten, Assembler Code unverständlich
Alos für mich sieht das mal wieder nach einer Verschlimmbesserung des AVR GCC aus. Mit meinem Alteisen von 2006 kommt ganz normaler Assembler raus. Optimierung -Os [c] #include "avr/io.h" #define ENCODER_PIN PINA #define INC0_PHASE_A (1<<PB4) #define INC0_PHASE_B
Ja ich hab Optimierung Os. Ich hab bereits mit der WinAVR Version 20071221 getestet. Die liefert jedoch den gleichen Code...
-
Thread
AVR für wenig Geld im LAN
Unterschiede zeigen. Wenn die Dateien sich komplett unterscheiden, vermute ich eher, daß Du eine andere GCC-Version verwendest als Kurt und/oder andere Optimierungs-Einstellungen.
>> Wenn die Dateien sich komplett unterscheiden, vermute ich eher, daß Du >> eine andere GCC-Version verwendest als Kurt und/oder andere >>> Optimierungs-Einstellungen. Wie kann denn ein Programm so von der Version und den Optimierungen abhängen?
-
Thread
16Bit x 16Bit = 32Bit schnelle Multiplikation für 8Bit AVR in C
Filter reicht es aus. Da hier die Geschwindigkeit im vordergrund steht. Verbesserungen und Optimierungen sind erwünscht. Gruß Alex.
, nur noch ein Schönheitsfehler: result ist uninitialisierte Eingabe von asm, eigentlich sollte gcc das anwarnen. Die korrekte Out-Constraint ist hier "=&r" und nicht "+r".
-
Thread
Intrinsic Funktion _bittest langsamer?
Ok, Standard ist gcc, deshalb habe ich es mal angenommen, weil du keinen Comnpiler nennst. Was ist mit dem Assembler-Code?
absdf and ;; negdf respectively, so they can never be disabled entirely. [/pre] (aus ggg-4.7.2/gcc/config/i386/i386.md)
-
Thread
LED Würfel ATTINY13
für das eine Bit auch den passenden Befehl, anstatt Read-Modify-Write. Das ist allerdings eine Optimierung. Geht also schön schnell, funktioniert aber nicht wie vom TO erwartet. mfg.
PINB & (1<<PINB4)) ) { ... } [/code] Siehe auch: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Digitale_Signale
-
Thread
Programmabsturz eines Consolenprogramms unter Windows - wie Fehler finden?
aus der Textdatei die Audiodatei in 3 neue Dateien im Waveformat. Unter Linux kompiliere ich mit gcc 4.7.3 bzw. cross-kompiliere für Windows mit dem i686-w64-mingw32-gcc 4.6.3. Das Programm läuft anstandslos unter Linux und in der VirtualBox unter Windows 7. Es stürzt ab auf mehreren anderen Windows
Gerhard Z. schrieb im Beitrag #4059353: > habt ihr parat, wie ich dem gcc mitteile, dass er den Stack vergrößern > soll? das sollte keine Option vom Compiler sein. Beim starten eine threads kann man die Stackgröße mitgeben. Aber wie es beim Hauptprogramm geht kann ich
-
Thread
C komisches Verhalten
setzte ich mich auch gerade mit diesem Problem auseinander. Mir ist dabei aufgefallen, dass der AVR-GCC teilweise wenig nachvollziehbare Optimierungen macht. z.B. wird für unterschiedliche AVRs ohne verständliche Gründe ganz anderer Code erzeugt, der mehr oder weniger Taktzyklen benötigt.
Compare) > auswerten kann. Len muss vorher um eins korrigiert werden. > Probiere das 'mal mit AVR-GCC aus. Du wirst Dich wundern..
-
Thread
Geany, C, GCC4.7, eigenes makefile: Will for-Schleife nicht kompilieren!
Hallo, diese for-Schleife wird vom gcc mit folgenden Fehlermelungen beworfen: gcc -Wall -c "menue.c" (im Verzeichnis: /home/ranger/Projekte/Mal_sehn_obs_geht) menue.c:9:1: error: expected identifier or ‘(’ before ‘for’ for(i=0;i<8;
> diese for-Schleife wird vom gcc mit folgenden Fehlermelungen beworfen: Und das zurecht. HTH
-
Thread
Anfänger in C: Welche Bücher/ Software ist gut ?
codevision oder imagecraft (für die Schleichwerbung bekomm ich kein Geld!) aber the one and only ist AVR-GCC. Der ist Open-Source und KOSTENLOS!
nicht viel zu konfigurieren. Einfach runterladen, installieren (bin-install.exe), und probieren ob avr-gcc.exe und der ganze andere Kram aufrufbar ist. Kompilieren: avr-gcc -o test.elf -Os -Wall -mmcu=at90s8515 test.c ^^^^^^^^^^^ ^^^ ^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^ |Ausgabedatei
-
Thread
Möchte jemand für mich ein PIC-Assemblerprogramm schreiben?
Gibt es für PIC24 keine richtige freie Entwicklungslösung. MPLABx kommt mit irgendwie kastriertem gcc daher (da geht dann nach einer gewissen Zeit die Optimierung aus oder so). Zeig mir wie ich mit ähnlichem Komfort wie bei AVRs für den PIC optimierten C Code programmieren kann und ich geb ihnen
Gibt es für PIC24 keine richtige freie Entwicklungslösung. MPLABx > kommt mit irgendwie kastriertem gcc daher (da geht dann nach einer > gewissen Zeit die Optimierung aus oder so). Korrekt. Der Freeware-Compiler disabled die höchste Optimierungsstufe bzgl. Size Optimisation, soweit icht weiss. Und
-
Thread
Einzelbits in Byte Namen zuweisen und auswerten
Mapping vom Kommunikationsstrukturen / Messages auf Bits und dergleichen. Zu Packed siehe: https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes
Man kann das Ganze ungeheuer kompliziert betrachten. Man kann aber auch einfach auf avr-gcc testen und dann die gültige Bitorder anwenden: [pre] To determine the compiler is avr-gcc, you need to test for 2 macros __GNUC__ and __AVR__ [/pre] Die avr-gcc Entwickler sind recht konservativ
-
Thread
MMC/SD/SDHC card library von R.Riegel "verkleinern"
Die Lib ist denke ich vielen hier bekannt. Hast Du die Optimierung eingeschaltet?
Jetzt komm ich mir blöd vor... welche Optimierung meinst du?
-
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
Absolut Ahnungsloser benötigt Hilfe
Ahh , das krieg ich hin : Meldung : -------- begin -------- sh: avr-gcc: command not found make: *** [gccversion] Error 127
der nötige Compiler, der ist nur nicht im PATH eingetragen. Daher die obige Ausschrift ("avr-gcc: command not found"). Die gute Nachricht dieser Meldung ist aber: ein "make" ist offenbar bereits da. Damit muss man nur noch rausfinden, wo der AVR-GCC genau ist. Vermutlich ist es [pre
-
Thread
Wie kommt es, dass es Arm SoCs für unter 10 € gibt, aber keine x86 SoCs zum gleichen Preis?
, mit dem Befehlssatz befasst sich doch der Compiler. Die, die tatsächlich taktgenaue Assembly-Optimierung betreiben, lassen sich von der einfacheren (als x86) ARM-Assembly auch nicht schocken. x86 schrieb im Beitrag #4968008: > Die Compiler sind ebenfalls hochoptimiert. Und ARM-Compiler nicht?
vor 20 Jahren für x86 optimiert wurde macht doch heute keinen Unterschied mehr für ARM - solche Optimierungen sind heute standard in allen guten Compilern...
-
Thread
Kompilieren dauert zu lange!!
nur 20 Zeilen sind, dann dauert es so 15 Sekunden bis das Programm läuft. Ich verwende den GNU GCC Compiler und weiß einfach nicht woran es liegen könnte. Alle Optimierungen sind schon von Codeblocks automatisch deaktiviert und ich kann nur mehr auf euch zählen... Es tut weh wenn das so lange
int argc, char *argv[]) { printf("Hello, world!\n"); return 0; } [/c] Erstes Mal: $ time gcc -Wall -o Prog x.c real 0m0.869s user 0m0.080s sys 0m0.048s Zweites Mal: $ time gcc -Wall -o Prog x.c real 0m0.068s user 0m0.060s sys 0m0.012s Auf hundert Zeilen erweitert
-
Thread
[AVR] ADC Register lesen avrgcc
in der Reihenfolge ... Ich wollte nur sicher gehen, dass das so passt und dass mir irgendeine Optimierung nichts versaut :) [c] uint16_t adc_val = ADCL | (ADCH << 8); [/c]
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#16-Bit_Register_.28ADC.2C_ICR1.2C_OCR1x.2C_TCNT1.2C_UBRR.29
-
Thread
C Compiler ISR
://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html#ARM-Function-Attributes https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes https://gcc.gnu.org/onlinedocs/gcc
Prolog / Epilog wird ausgegeben von "riscv_expand_prologue" bzw. "riscv_expand_epilogue". https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/riscv/riscv.c?view=markup
-
Thread
STM32F405 int64_t lehren
Mein Nucleo F411RE läuft auch mit u/int64_t ohne irgend eine lib mit gcc. Auch ohne mathlib.
Os -flto --specs=nano.specs --specs=nosys.specs -nostartfiles -Wl,--gc-sections -Tsrc/STM32F401XE/gcc_linker.ld -lm -Wl,-Map=build/hello_world.map Ich verwende den offiziellen gcc von Arm auf Launchpad.
-
Thread
Attiny mit komischem verhalten
vergessen raus zunehnem :-) Die LEDs sind per 1k Widerstand angeschlossen wie im AVR TUT. An der Optimierung sollte es nicht liegen die is aus ;-D
Hannes wrote: > _delay_ms(1000) kannst Du vergessen. Dem geht nicht. Das muß dann schon aber ein GCC ganz tief aus der Mottenkiste sein. Ab WINAVR 20071221 und neuer geht das. Peter