-
Thread
PowerLED PWM mit RC5 Fernbedienung
external in RC5.h wird nicht richtig interpretiert. Macht aber auch nix, der AVR ist auch ohne Optimierung nicht voll.
abschalten, um ein RC5 Signal >zu erhalten. Da fehlt ein volatile bei rc5_data. Mit (ganz) früheren gcc-Versionen funktionierte das auch so mit eingeschalteter Optimierung, die neueren optimieren gnadenlos alles weg. Oliver
-
Thread
Atmel Debug - welche uCs können welche Schnittstelle?
Doppelt Flash ist etwas übertrieben aber beim AVR-GCC braust man 40-50% mehr Flash zum Debuggen. Warum? Debuggen kann man am besten wenn alle Optimierungen abgeschaltet sind. Das bedeutet aber auch 40% größeres Programm.
Maria wrote: > Warum? Debuggen kann man am besten wenn alle Optimierungen abgeschaltet > sind. Das bedeutet aber auch 40% größeres Programm. Naja, das ist Ansichtssache, es ist vlt. manchmal übersichtlicher ohne Optimierungen zu arbeiten. Aber generell macht es schon
-
Thread
Ansteuerung Schrittmotor mit ATmega8 macht Probleme
F_CPU eintragen, die gewünschte Zeit beim Aufruf angeben, sicher stellen, dass die Compiler-Optimierungen an sind und die Zeiten stimmen. Egal bei welcher Taktfrequenz. >>> [[AVR-GCC-Tutorial]] <<< [C] #define F_CPU 8000000UL #include <util/delay.h> #define STEP_DELAY 10 ....
MyAVR-Workpad Plus? Das ist kontraproduktiv. Wenn du richtig programmierst, brauchst du die Optimierung nicht abzuschalten. Du willst die Optimierung behalten! Also musst du richtig programmieren.
-
Thread
Asm in AVR GCC?
" "brne delay3" "ret" "dec r17" "brne delay2" "dec r16" "brne delay1" "ret" ); } // gcc plug-in: Error: Object file not found on expected location C:\Tests\gcc\default\qwerty.elf
http://www.nongnu.org/avr-libc/user-manual/inline_asm.html und dann den entsprechenden Eintrag im gcc Manual lesen: http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Constraints.html Wenn du dir danach etwa die Frage beantworten kannst, was einen "early clobber" von einem "clobber" unterscheidet und
-
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
C++ für Mikrocontroller
vorhanden und getestet ist und der Vorteil durch C++ den Aufwand nicht wettmacht. Das ist z.B. bei gcc anders.
und zuletzt mit > avr-strip die Symbole entfernt. Wie bist Du zu Deinem Ergebnis gekommen? arm-gcc, nicht avr-gcc! Ist es nicht so, daß der avr-gcc gar keine Exceptions und keine RTTI unterstützt? arm-gcc hat diese beiden Dinge sicher mit dabei, weshalb das Abschalten dieser sich auch bemerkbar
-
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
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
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
Technik für zyklisches erhöhen eines Wertes: if versus modulo
veraltet sein. Das hat dann aber mit Hochsprachenprogrammierung nichts mehr zu tun. Solch Optimierungen kann der Compiler.
werden sporadisch auftretende Additionsfehler elegant unter den Teppich gekehrt ;-) Anmerkung: Optimierungen durch den Compiler müssen deaktiviert werden.
-
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
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
Probleme mit for-Schleifen
und ersetze sie durch eine primitive Leerschleife etwa int i; i=1; while (i++); Am besten Optimierung des Compilers abschalten, oder ein asm volatile ("nop"); in die Schleife, damit sie nicht wegoptimiert wird. Optimierung Abschalten ist eh mal zum Testen sinnvoll, wenn Problem auftreten.
alles nicht hilft, muss man sich mal das Assembler-Listing ansehen. (Wie man das erzeugt steht im AVR-GCC Tutorial.)
-
Thread
Ada oder MISRA-C, aktuell und in Zukunft
mit der > Compilerunterstützung aus? Gemischte Projekte sind kein Problem. Compilermäßig sind GCC und Clang/LLVM voll unterstützt. Standardmäßig nutzt Rust den LLD, also den LLVM-Linker, wobei der GCC-Linker ebenso unterstützt wird und ursprünglich für Cortex-M sogar der Standardlinker war. Wie
Strubi schrieb im Beitrag #5900480: > Müsste eine gcc 3.x gewesen sein. Also vor ewigen Zeiten... Strubi schrieb im Beitrag #5900480: > Ich hätte auch erwartet, dass der > Compiler erkennt, dass das mit genau einem Wrapper (index -> Pointer) >
-
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
Anfängerfrage QuickWatch oder Step by Step
wo findet man die Optimierung?
Michael B. schrieb im Beitrag #5241062: > wo findet man die Optimierung? Ich verwende nicht das Studio 7, aber auch dort müsste es unter 'Project' zu finden sein.
-
Thread
C Compliler für EFM32 von Energy Micro
ein bisschen was mit inline-Funktionen & Assembler basteln, aber an sich gehts schon. Wie gesagt, GCC braucht halt etwas Anpassungsarbeit. > Pragmas Die GCC-spezifischen Pragmas logischerweise (die sind ja immer Compiler-spezifisch) > kompakten Code? Und wie, die Optimierungen sind krank... > Wohl eher doch nicht. Wohl doch! > Also: GCC oder nicht - es kommt drauf an, was man machen will. Eher wie faul man ist...
-
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
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
Seltsames AVR Studio / WinAVR Verhalten
Variablen zerhaut. avr-size ist dein erster Freund ;-) http://www.mikrocontroller.net/articles/AVR-GCC#Tipps_.26_Tricks
gleichen Argumenten auch immer das gleiche Ergebnis liefern wird. Deshalb kann der Compiler diese Optimierung machen.
-
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
GCC: Adresse einer bestimmten Codestelle
sondern im ELF-File als Label auslesbar sein. Eine erste Idee war, das "Label as value"-Feature des GCC zu verwenden, einen Pointer damit zu beschreiben und diesen dann während des Programmablaufs im z.B. Simulator auszulesen: [C] void *ptrLabel; int main(void) { // Label-Adresse in Pointer
z.B. durch eine (Pointer-)Variable. - wenn möglich ein Konstrukt, das nicht nur speziell für den GCC verwendbar ist. Irgendjemand eine Idee? Schönen Tag noch, Thomas
-
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
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
GCC ARM Cortex-M3: Merkwürdiger Assembler Code von C++-Routinen
(ich verwende Sourcery G++ Lite): arm-none-eabi-gcc -o test1.o -c -DSTM32F10X_MD_VL -DUSE_STDPERIPH_DRIVER -Wall -mcpu=cortex-m3 -mthumb -g3 -gdwarf-2 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -fno-inline -ffunction-sections
Hallo, ohne -fpack-struct wird daraus bei mir (Sourcery gcc version 4.6.1): [code] movs r3, #17 str r3, [r0, #0] [/code] mit -fpack-struct erhalte ich das selbe Ergebniss wie du.
-
Thread
"-=" Will nur einmal, aber nicht 3 mal.
Hallo, ja, hab ich, deshalb hab ich ja auch gefragt. AVR-gcc ist version 4.3.2 . Standart in Arduino 1.0.5
Hast du Optimierungen beim Übersetzen an, dann schalt sie doch testweise mal aus...
-
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
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
Register reservieren in avr-gcc
Hallo, ich möchte einzelne Register in avr-gcc fest verwenden. Dazu gibt es eine Syntax im Wiki-Artikel [[AVR-GCC-Codeoptimierung]]. Die habe ich auch schon vor Jahren erfolgreich verwendet. [code]register uint8_t more_flags asm("r2");[/code]
Funktionen, die für -mcall-prologues verwendet werden. Ist das garantiert? Auch für die Zukunft? Der GCC an sich verwendet diese Register ja schon.
-
Thread
Unterschied zwischen memcmp und strcmp – Wann was nehmen?
GCC, x86-64: [c] #include <string.h> extern unsigned char s1[], s2[]; int f(void) { return memcmp(s1, s2, 8); } int g(void) { return 0 == memcmp(s1, s2, 8); } [/c]
Das Wichtige oben waren die *gleichgroszen* Blöcke. Selbst ohne Optimierung, also byteweisem Vergleich, geht es u.U. schief, z.B.: [c] char buffer1[] = "Hallo"; char buffer2[] = "Hallo\0Welt"; strcmp(buffer1, buffer2) // ok, true memcmp(buffer1, buffer2,
-
Thread
STM32F4 mit gcc-arm-none-eabi
Zusammen, ich versuche ein STM32-E407 Development Board von Olimex mit STM32F407ZGT6 CPU mit der GCC ARM Embedded toolchain (gcc-arm-none-eabi-4_9-2015q4) zu programmieren. Compiler und Linker (beides gcc) rufe ich mittels Makefile auf. Debugging mittels GNU gdb (GNU Tools for ARM Embedded Processors
welches sich ebenfalls in dieser Struktur unter /Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/ befindet (Danke an Steffen Rose). Die CFLAGS habe ich aus dem Artikel ARM GCC hier im Forum (https://www.mikrocontroller.net/articles/ARM_GCC) aus dem Kapitel Compiler & Linker Flags --> "Ohne Optimierungen
-
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
Variablenfreigabe for-Schleife
deklararierten Variablen hinter der for-Anweisung fortgesetzt worden ist. Entsprechend gab es auch mal eine GCC-Version, die das so implementiert hat, aber meiner Erinnerung nach war das damals wirklich nur in C++ implementiert, der C-Compiler vom GCC hatte das nie als Erweiterung -- außerdem ist das alles
nein, ist ja nicht so das ich mir das ausgedacht habe. Es gibt auch noch > mehr Compiler als den GCC. Nun ja, hier ganz oben drüber steht: >Forum: GCC Aber gut, ich verbessere mich: Das Verhalten ist in C immer eindeutig definiert. Das gilt natürlich nicht für Compiler, die eine C-ähnliche
-
Thread
[C] Struktur ist zu groß
gcc 4.7.2 x86-64: 14 gcc 4.8.1 ARM: 14 gcc 4.7.2 AVR: 14
Es gibt in GCC eine Warnung -Wpadded.
-
Thread
C++ Speicherfehler finden
;-) Naja, gdb zum Beispiel wird dann ziemlich böse. In der Regel reicht aber die Debug-Option von gcc schon, damit es scheppert.
ich noch mitbekommen und oben auch geschrieben. Aber hat er in den letzten Jahren auch bei der Optimierung/Codegenerierung zugelegt? Mein letzter Stand ist der, dass er dabei mit dem GCC etwa gleichauf war. XTerminator schrieb im Beitrag #2517151: >> Den Intel-Compiler würde ich als den aktuell
-
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
etwas akademische Frage zu C
ersten Mal im Draft N1516 vom 4.10.2010, also relativ spät auf. Vermutlich wurde das Verhalten des GCC erst daraufhin geändert.
PORTB = 1; } [/c] Das Inkrement wird hier trotzdem als 16-Bit-Operation ausgeführt (AVR-GCC 6.2.0). Es würde aber nichts gegen so eine Optimierung sprechen. Vielleicht kommt sie ja in Version 7 :) Edit: Auch die Abbruchbedingung i<=255 statt (i<256) ändert nichts daran.
-
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
IVEL bei mega32 lässt sich nicht setzen
HelpUrl: Installed Packages: AVRGCC - 3.4.1.95 AVR Toolchain 8 Bit Version: 3.4.1.830 - GCC 4.6.2 Package GUID: a3796ad3-98fe-4e60-bd15-57100d343560 Company: Atmel HelpUrl: AVR Toolchain 32 Bit Version: 3.4.1.348 - GCC 4.4.3 Package GUID: a3796ad3-98fe-4e60-bd15-57100d343560 Company
GELÖST .... zum debuggen hab ich die optimierung auf null -O0 gesetzt/ausgeschalten. übers disassembly sieht man jedoch im code, dass das setzen des flags nicht innerhalb von 4 zyklen passiert bei optimierung -O2 beschränkt sich das setzen
-
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
LPC2134 Startup Code bzw. "Blink Beispiel"
hatte ich zwar hauptsächlich mit dem Keil gearbeitet, aber ich hatte dann das Ganze auch noch mit dem GCC (Yagarto, Version hab ich vergessen) durchgezogen. Ein Linkerscript war dazu überhaupt nicht nötig. Guck dir einfach die "cccgcc.bat" an, dazu die zwei "compile_gcc.xcl" und "link_gcc.xcl". Sicherlich
obendrein ist der Code des GCC selbst bei heftigster Optimierung noch immer um 10..20% größer als der vom Keil. W.S.
-
Thread
Verständnisfrage zum #include beim "Auslagern" in .c und .h
\atmel studio\6.2\GccApplication3\GccApplication3\MyTWI.c 43 1 GccApplication3
: Severity Code Description Project File Line Error undefined reference to `TWI_init' GccApplication3 C:\Users\Ichich\Documents\Atmel Studio\7.0\GccApplication3\GccApplication3\Debug/.././GccApplication3.c 18 Error undefined reference to `TWI_Flags' GccApplication3 C:\Users\Ichich
-
Thread
40 Bit in 5 Bytes abbilden mit Bitfeld
jetzt geklärt wäre, noch was anderes: Mathias G. schrieb im Beitrag #4801393: > } __attribute__((gcc_struct)) tx_data; ... ich glaube nicht, daß das Attribut gcc_struct auf ARM irgendwas (geschweige denn, was Sinnvolles) tut. Das würd' ich weglassen.
auch probiert - bringt nicht wirklich was. Ich habe es auch mal ausprobiert: Mit arm-none-eabi-gcc 6.2.0 und __attribute__((packed)) und ohne das gcc_struct-Attribut (das auf dem ARM sowieso keine Bedutung hat) ist die Struktur 7 Byte groß, d.h. es verbleiben keine ungenutzten Bits.
-
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
Leon3 c Code Optimierung und Messung
kann, da weder gettimeofday, noch clock() etwas bringt? Die Auflösung ist immer zu hoch. Gibt es Optimierungen beim GCC die speziell für Sparc bzw. Leon3 sind. Was sollte ich beim Programmieren beachten, dass meine Software schneller ausgeführt wird. Kleine Funktionen "inline" kennzeichnen bzw. Variablen
ein Betriebssystem nicht eine Laufzeitumgebung, sprich linux ? , whatever ... Gaisler bietet ein gcc cross compiler + Toolchain(bcc), von der Sache mit allem was das Herz begehrt :D Für Geschwindigkeit würd ich den LEON3 Instruktion- Data Cache auf max, fahren + geeignetem caching Algorithmus parametriern
-
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
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
uint32_t => float (32) ohne cast!
Johann L. schrieb im Beitrag #5111439: > macht avr-gcc -Os man sollte die Funktionen aber schon aufrufen.
Johann L. schrieb im Beitrag #5111439: > Dieses "Type Punning per Union" wird zwar von GCC unterstützt (steht > irgendwo im Kleingedruckten), konformes C ist es aber nicht. Seit C99 schon, und das ist doch default beim GCC.