-
Thread
Programmablauf simulieren, vorm Compilieren
du sie mit Add Watch ins Watch-Fenster bringst. Hilfreich ist es ggf., die Übersetzung ohne Optimierung durchzuführen, sonst sind manche von dir definierte Variablen gar nicht vorhanden: wegoptimiert.
sie mit Add Watch ins Watch-Fenster bringst. > > Hilfreich ist es ggf., die Übersetzung ohne Optimierung durchzuführen, > sonst sind manche von dir definierte Variablen gar nicht vorhanden: > wegoptimiert. Da habe ich mich missverständlich ausgedrückt - meinte; mitten im Programmschreiben, mal eben
-
Thread
AVR Studio zeigen keinen Source-Code mehr an
halt doch recht gut). Unabhängig davon: heute hatte ich den Eindruck, daß C-Programme (mit AVR-GCC bzw. WinAVR compiliert) sich unterschiedlich verhalten, je nachdem, ob sie ohne Optimierung (-O0) oder mit Optimierung (-O2 oder -Os) compiliert werden (natürlich abgesehen von der Code-Größe bzw. geringfügigen
-
Thread
lpc2129 GCC ISR-Verwaltung
Welche ENTRY/EXIT Macros? GCCs gibt es viele. GCC hat nach wie vor einen Bug bei Routinen, die via Compiler als Interrupt-Handler deklariert werden. Tritt nicht immer auf, steckt aber nach wie vor drin. ARM und verschachtelte Interrupts: http://
Beim arm-elf gcc zumindest bis Version 4.1.x (habe mit 4.2.0 noch nicht viel gemacht) betrifft meines Wissens Code, der mit Interwork-Option compiliert wird und bei dem ISR mit dem interrupt function-attribute versehen
-
Thread
frage zu rjmp beim GCC/ATmega162
Hi ich frage mich erstens warum Inline-ASM für sowas wie ein Pin-Toggle anwenden? Der GCC macht aus PORTA^=1<<5; 254: 8b b3 in r24, 0x1b ; 27 256: 90 e2 ldi r25, 0x20 ; 32 258: 89 27 eor r24, r25 25a: 8b bb out 0x1b, r24 ; 27 was mindestens
Hmmm ich habe folgenden Compileraufruf gemacht: avr-gcc -S -Wall -O2 -mmcu=atmega162 -c main.c und es kommt tatsächlich ein Listing main.s heraus. Leider ist die Zuordnung C-Quelltest -> Assembler nicht zu erkennen. Hab ich da wohl noch ne Option vergessen
-
Thread
uC: Adresse von Empfangspuffer an andere Funktion übergeben
true; [/code] und lesen [code] if (Daten_gueltig) { ... = Daten; } [/code] Ohne Optimierung funktioniert das auch so. Mit Optimierung kommt der Kompiler womöglich auf die Idee, die Daten in einer anderen Reihenfolge zu lesen. Z.B. Daten_gueltig wird gesetzt, bevor Daten den korrekten
gelesen. Wie die Memory-Barrier genau realisiert wird, hängt vom Prozessor und vom Kompiler ab. Bei GCC sollte es das folgende tun (Makro definieren!): [code] asm volatile ("" : : : "memory"); [/code] Jürgen
-
Thread
Was macht bitte der GCC da?? Compilerbug?
Hallo an alle, Ich benutz das WinAvr 20070525 Packet mit dem GCC 4.1.2. Optimierung: s Ich hab eine Funktion geschrieben. Sie ist zwar noch nicht fertig, aber egal. [c] void sht_raw_to_physical(sht_val *temp, sht_val *hum) { char tem[2]; temp->_int -
-
Thread
-Wuninitialized geht nicht
Hallo, leider kann ich unter raspbian mit codeblocks und gcc 4.6.3 diese Warnungen nicht aktivieren. Meine Suche im inet brachte das Ergebnis, dass man entweder -O oder die anderen Optimierungen nutzen muss. Bei mir geht es trotzdem nicht. Hat jemand einen
Funktionen > als auch in der main Funktion. [c]void main(void) { int a; a++; }[/c] $ gcc -Wall -Wno-main x.c x.c: In function ‘main’: x.c:4: warning: ‘a’ is used uninitialized in this function Ungefähr so?
-
Thread
AVRGCC code zu gross...
1.: Compiler-Optimierung eingeschaltet? Wenn nicht, dann ist es normal, dass der Code sehr groß wird. 2.: Floats lassen sich in vielen Fällen geschickt vermeiden. Wenn der Speicherplatz wirklich knapp wird, dann versuchen
Ach ja, 3.: Es gibt hier ein extra GCC-Forum, da sind solche Fragen i.d.R. besser aufgehoben...
-
Thread
Entwicklung eines "Debug Tool's"
>Nein, aber Codevision und Imagecraft. Beide eine reine Katastrophe ! Dann probier doch mal AVR-GCC! Mit GCC ist der Standardlinuxcompiler, mit dem auch fast alle Linux-C(++)-Programme compiliert sind. Ist also im PC-Bereich ziemlich verbreitet und mit dieser guten Grundlage ist dann auch ein IMHO
als >Pascal/Delhpi ... Und warum? Delphi erzeugt ziemlich schnellen code. Und führt auch viele Optimierungen durch(weißt dich z.B. auf unnütze/vergessene initalisierungen von Variablen hin, etc.) Hermann
-
Thread
Wieso vor allem AVR µCs bei Bastlern?
programmieren. Für mich war das Umstiegskriterium von PIC auf AVR aber auch die Verfügbarkeit eines GCC.
was jeder Assembler kann), also habe ich mir dann lieber eine Plattform gesucht, für die es einen GCC gibt. Dass ich dadurch mal recht aktiv in die ganze Toolchain-Entwicklung um den AVR-GCC herum selbst einsteigen würde, war eher nicht so geplant. ;-)
-
Thread
Auf High-Word eines signed long long int zugreifen
Daumenregel: Wenn man mehr Zeit in die manuelle Optimierung und entsprechend komplexere Pflege eines Programms reinsteckt, als man kumuliert zur Laufzeit wieder rausholt, dann ist man schwer auf dem Holzweg.
Und hier (gcc 4.2) ist f1 besser, mit -O2: .f1: lis 0,0x1233 ori 0,0,65535 cmpw 7,3,0 ble 7,L..8 lwz 9,LC..1(2) addi 3,9,4 blr .f2: lis 0,0x1233
-
Thread
LSB <----> MSB tauschen in c
Hmm, jetzt habe ich die Optimierung (auf Größe wohlgemerkt) im Compiler aktiviert, und plötzlich braucht mein Code 50 Bytes und Detlefs 42. Aber ich habe festgestellt, daß mein Code unnötig umständlich war, diese Version benötigt nur 29 Bytes bei aktivierter Optimierung: [C] char i,out; for(i=0;i<8;i++) { out >>= 1; out |= (byte & 0x80); byte <<= 1; } [/C]
-
Thread
Programm der Übersichtlichkeit halber in Funktionen ordnen versus Programmspeicher
Funktionen können auch ge-inline-t werden. Dann entfällt der Aufruf-Overhead. Der GCC macht das u.a. dann automatisch, wenn dein Haupt-Init und deine Sub-Inits alle in derselben .c-Datei stehen und die Sub-Inits alle mit /static/ deklariert sind. Dann erhältst du das gleiche Ergebnis
4. Genau da optimieren. 5. goto 2. Am Anfang der Programmentwicklung vermeintliche "Optimierungen" anzustellen, geht nach hinten los: Der Sourcecode wird sowas von unwartbar, daß man ihn später zur Optimierung, da wo sie wirklich gebraucht wird, nicht mehr anfassen mag.
-
Thread
Organisation von Projekten mit hochkomplexer Hardware
da. Was gemacht wird um es auf eine neue Architektur zu bringen ist: 1) die Architektur in den gcc zu bringen (moderater Aufwand, aber am Anfang braucht man noch keine Optimierung und so) 2) die architekturabhängigen Teile im Kernel zu ändern (Startup-Code und Taskswitching, dass kann relativ
Hallo, der gcc selbst ist ja "neutral". Der seetzt den C99 Standard auf den Maschinenbefehlssatz um und berücksichtigt dabei die Eigenheiten der CPU. Der ARM11 ist ohne C Compiler und unterlegtes OS ohnehin witzlos
-
Thread
GCC: 8bit x 8bit -> 16bit ?
>wie groß ist int? bei int main wird ja ein int zurückgegeben. Beim AVR GCC afaik 16bit.
die Frage wie man allgemein effizient die extended > mul-Ergebnisse in C abgreifen kann Auf avr-gcc 4.7 warten.
-
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
Evaluation neuer Mikrocontroller: ARM? Gesperrt
ausgeführt werden. Auch der TCPIP-Stack verbraucht viel Speicher. Klar könnte man da gewisse Optimierungen vornehmen, das würde aber alles auf Kosten von Performance gehen - und das dürfen wir uns auch nicht erlauben.
keine Wünsche übrig läßt. Nach 60 Tagen ist die Codegröße auf 256kB begrenzt, oder man nimmt gleich GCC http://www.kpitgnutools.com/index.php und befindet sich dann im erlesenen Kreis der GCC-Nutzer.
-
Thread
Tasten entprellen
habe auch andere Inline-Assembler gesehen (bspw. von IAR), und ich kann dir versichern, dass das, was GCC hier anbietet, sehr viel besser und durchdachter ist. Es gestattet, Inline-Assembler-Code zu schreiben, der erstens der Optimierung des Compilers nicht im Weg herum liegt und der zweitens zukunftssicher
100 Jahre brauchen, bis er das sehr viel komplexere C beherrscht. Selbst wenn man das mal auf avr-gcc runterbricht...
-
Thread
AtMega8 und g++ Optimierung: PIN einlesen wird wegoptimiert
Hallo, ich steuere ein Display mit dem Atmega8 an, der Code ist in C++ geschrieben. Unter anderem gibt es folgende Methode mit der "PROBLEMZEILE". [code] unsigned char readByte() { unsigned char byte; DDRD=0x00; //PortD as input PORTD=0xFF; //PortD with internal Pull-Up PORTB |= (1 << WRB); // Read //Dummy read after setting address PORTB |= (1 << RDB); PORTB &= ~(1 << RDB); PORTB |= (1 << RDB); // really read PORTB |= (1 << RDB); PORTB &= ~(1 << RDB); byte = PIND; //PROBLEMZEILE PORTB |= (1 << RDB); return byte; } [
-
Thread
"while(1)" will nicht so wie Ich
Kann mich täuschen, aber welche Optimierung ist denn beim Compiler drin? O0 (also keine) mag die delay-Funktionen (zumindest bei mir) nicht. Mit Os gehts wie's soll.
dadurch habe ich mich verwirren lassen. Ich hätte geschrieben: [c] DDRD = 0b00001111; /* falls GCC-Erweiterungen OK sind */ DDRD = 0x0f; /* sonst */ [/c]
-
Thread
union mit Struct und Array
Ach so, ich nutze den GCC unter Atmel Studio 6 Ingo
aber nicht im Array bzw. umgekehrt (sofern das wichtig ist), ausgelöst durch Füllbytes/Compiler optimierung.
-
Thread
Warum doppelbedeutung static?
Compiler hat mit Adressvergabe grad garnix am Hat, das macht immer noch der Linker / Lokator, im Fall der GCC also ld.
was heißt hier "schon", Windows/Microsoft ist jetzt nicht gerade ganz vorne bei der C++ Entwicklung. GCC und Clang sind da weiter...
-
Thread
LCD 16x2 an ATMEGA 8
weglassen: #ifndef F_CPU #define F_CPU 3686400 #endif In dieser Anleitung steht auch das die Optimierung beim Compilern eingeschaltet werden muss. Wo kann ich dies machen??? http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung
sehen...(lcd-routines.h, lcd-routines.c, LCD Beispiel 1) http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung
-
Thread
STM32F4 GCC erzeugt kein DSP
: 32 ± (32 x 32) = 32 MLA, MLS Was läuft hier falsch? Was muss Ich anders machen? Oder ist der GCC derzeit nicht in der Lage DSP zu erzeugen? Grüße vom Bodensee (es regnet), Jan
für den entscheidenden Hinweis. Hab mich in den ganzen Dokus total verannt und war kurz davor den gcc auszuchecken um zu gucken was der so treibt. Grüße vom Bodensee, Jan
-
Thread
Atmega88P, Blinklicht in AtmelStudio 7 simulieren
nicht so lange warten zu müssen. Gruß Dennis [1] http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
kannst Du? Dieter F. schrieb im Beitrag #4622157: > In solchen Fällen schalte ich die Compiler-Optimierung komplett aus und > das Debug-Level auf Maximum. Dennis S. schrieb im Beitrag #4622425: > OHNE die > herablassende Art. Die kennst Du noch nicht :-) gute Nacht
-
Thread
[S] uC - klein, 5V, 2 ADC, 2 DAC, kostenlose Toolchain
Reset ist so ne Sache) IOs - USI taugt als SPI oder I²C und unterstützt eine Software-UART - AVR-GCC ist gratis (und optimiert gratis, anders als die XCCs von Micrchip) - Gibts überall EDIT: Mit V-USB ist sogar USB drinnen (damit is der Chip aber ziemlich beschäftigt)
Reset ist so ne Sache) IOs > - USI taugt als SPI oder I²C und unterstützt eine Software-UART > - AVR-GCC ist gratis (und optimiert gratis, anders als die XCCs von > Micrchip) > - Gibts überall > > EDIT: Mit V-USB ist sogar USB drinnen (damit is der Chip aber ziemlich > beschäftigt) Ja, mit PWM-DAC
-
Thread
Warnmeldung bei Pointerinitialisierung
Nee, aber in den Zielpointer casten. ptr_double_var = (uint8_t *) &double_var; Mit AVR-GCC ist double und float in der Größe gleich und 4 Bytes groß. Es ist "Zufall", dass dein Programm funktioniert.
const Werten maskiern. Das Problem ist das double nicht gleich double ist. >Stefan: >Mit AVR-GCC ist double und float in der Größe gleich und 4 Bytes groß. >Es ist "Zufall", dass dein Programm funktioniert. die andere Vorredner haben schon recht! Du könntest das auch mit einer Union lösen:
-
Thread
Beepfunktion bläht hex um ~4kb auf
_delay_ms(1000/hz*2); i_beep++; } } [/c] bläht die Hexdatei bei eingeschalteter Optimierung um ~4kb auf. Woran liegt das?
(Gast) > _delay_ms(1000/hz*2); Böse, böse. >bläht die Hexdatei bei eingeschalteter Optimierung um ~4kb auf. Woran >liegt das? _delay_ms() braucht KONSTANTE Parameter OHHE Berechnung. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 MFG Falk
-
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
Interpreter mit LLVM IR oder C als Zwischensprache?
Zwischensprache? Natürlich. Direkt LLVM-IR einzusetzen ist nur dann sinnvoll, wenn du damit Optimierungen ausdrücken kannst, die in C nicht (oder nicht so einfach) möglich wären. Bei deinem Kenntnisstand ist das wahrscheinlich nicht der Fall. Und C ist portabler als LLVM. (Was dir wahrscheinlich
generierten Codes alles im RAM passieren kann. Bei C muss ich erst eine C-Datei schreiben, diese mit gcc (z.B.) in eine Objektdatei übersetzen, die übersetzte Datei als dll/so-library linken und dann ausführen. Das sind viele Dateisystemzugriffe. Oder geht das Kompilieren und Ausführen auch in C komplett
-
Thread
Mein erstes Programm mit C
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
<util/delay.h> // Funktionen zum warten // Achtung, damit delay richtig funktioniert muß mit Optimierung compiliert werden int main(void) { DDRB = 0xff; // alle B pins als ausgang konfigurieren PORTB = 0xff; // erstmal alles abstellen DDRC = 0xff; PORTC = 0xff; while
-
Thread
ATMega32 Absturz bei Zeicheneingang
Hallo, jetzt wird es noch merkwürdiger: schalte ich die Optimierung von s auf 3 dann wird der Code größer, schneller (Ich habe jetzt mal eine LED in der main blinken lassen) und stürzt nicht mehr ab. :-o Mit optimierung 2 stürzt er am schnellsten ab. neue Main
kommen und dann kann ich Daten schicken wie ich will, der AVR ignoriert sie und nix stürzt ab. Optimierungen -Os und -O2 probiert. Also ich würde sagen an der SW liegts definitiv nicht. Bricht die Versorgung vielleicht zusammen durch irgendeinen Schluss von Datenleitung nach Vcc oder Masse?
-
Thread
Atoi für Unsigned
; } [/c] Microsoft: AE=-60 c=196 Nicht OK Digital Mars: AE=-60 c=196 Nicht OK Linux GCC: AE=-60 c=196 Nicht OK
main(void) { printf("isprint('AE')=%d\n", isprint('Ä')); } [c] => isprint('AE')=0 (GCC, x86, Linux) Andreas
-
Thread
Problem mit _delay_ms()
dass AVR Studio (etwas unsinniger Weise, wie viele Leute denken) Makefiles mit abgeschalteter Optimierung generiert. Finde einfach die Projektoptionen, wenn du schon AVR Studio benutzt. Das ist ungefähr so, wie wenn du mit dem Auto mit angezogener Handbremse fährst und statt im Handbuch nachzugucken
fange von vorne an. Ähm *nicht*! Lies die Doku zu den Funktionen in der Doku der avr-libc und im [[AVR-GCC-Tutorial]].
-
Thread
Ist AVR Ada tot?
um. Was de facto dann bedeutet, daß Optimierungen obsolet sind. Man muss also eine etwas dickere Hardware vorhalten. Johannes O. schrieb im Beitrag #2250630: > Ich kann mich schwach an was erinnern, dass die Nasa vor einiger Zeit > mal nach
können. AVR-Ada (soweit ich es verfolgt habe) scheint dagegen den Weg zu wählen, sich (wie AVR-GCC auch) um die Hardware selbst nicht zu kümmern, d. h. diese bleibt komplett in der Verwaltung des Anwenders. Es ist also eher ein Pendant zum AVR-GCC mit einer anderen Sprache als Grundlage denn das
-
Thread
Dynamische Strukturen avr-konform
> AVR gcc unterstützt keine Objektorientierung ! So'n Quatsch. Davon abgesehen, dass man objektorientiert auch in C programmieren kann, ist C++ sehr wohl (mit Einschränkungen) unterstützt.
Wegen Comilerschaltern einfach mal in der Doku nachsehen und im Fall des Falles kann auch alle Optimierung ausgeschaltet werden.
-
Thread
Makefile und flags für Raspberry 4 64bit
CPU nicht am Anschlag ist ("top" betrachten) sollte das völlig egal sein. Die wichtigsten Optimierungen kommen eh durch das "-O3", und das ist ja drinnen geblieben.
Wo hast Du das her? > Wie kann ich das lernen (um das Compiling verbessern zu können)? https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/AArch64-Options.html#g_t-march-and--mcpu-Feature-Modifiers -march=native oder -mtune=native würden den Compiler erkennen lassen, auf welchem System er läuft, und
-
Thread
Arm Cortex im DIP Gehäuse Gesperrt
> FYI: Die einen hassen ihn, die anderen lieben ihn: den GCC. Mit den > R8C/M16C tut der sich etwas schwer. Jaein. Du kannst dir den gcc einfach wie fuer jedes andere Zielsystem uebersetzen und nutzen. Das hab ich damals auch so gemacht. Er tat sich etwas
Olaf schrieb im Beitrag #5217087: > Jaein. Du kannst dir den gcc einfach wie fuer jedes andere Zielsystem > uebersetzen und nutzen. GCC setzt bestimmte Eigenschaften eines Targets voraus. Eine ausreichende Anzahl Register beispielsweise. Hat man die nicht, muss
-
Thread
Problem: LCD mit ATTiny
0 bytes (0.0% Full) (.data + .bss + .noinit) [/pre] Evtl. liegt es an der Optimierung?! Ich verwende -Os, also Size, irgendwo hab ich gelesen, dass -O3 beispielsweise Riesencode erzeugt. Aber selbst mit -O3 komme ich dabei gerade auf 604 Byte: [pre]AVR Memory Usage ------------
uC's angeht und im Programmieren mit C habe ich auch noch nicht so viel Erfahrung. Das mit der Optimierung kannte ich vorher auch noch nicht, ich hab einfach mal drauf losprogrammiert :-). Danke für den Tip Gruß Robert
-
Thread
STM32 startet im HardFault
aber ich hatte mal Probleme mit meinem in C geschrieben Startupcode für den STM32F4. Sobald die Optimierung -O2 oder größer an war, ist der Startupcode gecrasht. Lag im Endeffekt daran, dass der Startupcode in C geschrieben war und mit float abi hard compiliert war. GCC hat dann die Kopierschleife, die
"ldr sp, =_estack /* set stack pointer */" übersprungen; nach Chiperase oder Änderung der Optimierung hält der Controller hier an. Weitere habe ich nicht getestet, kann das aber gerne noch machen falls es hilft.
-
Thread
Autodetect Arraygröße bei Definition
gcc frisst auch ein Array, das kein String ist: [c] #include <stdio.h> int main(void) { const int foo[] = {123, 456, 789}; int le = sizeof foo / sizeof foo[0]; for (int i = 0; i < le;
Tom K. schrieb im Beitrag #3453945: > gcc frisst auch ein Array, das kein String ist: Nicht nur gcc. Es ist völlig legitim, bei der Definition eines Arrays die Größenangabe wegzulassen. Die Größe des Arrays ergibt sich dann aus der Anzahl
-
Thread
Problem mit LCD an ATMega 644
www.pollin.de/shop/downloads/D810058B.PDF) Die anleitung aus dem http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial passte nicht ganz da auf dem Board andere Ports für die Kommunikation vorgesehen sind, daher habe ich Codes hoffentlich korrekt angepasst. Leider bekomme ich immer noch kein bild, das der
Warteschleifen gearbeitet wird, müssen diese auch funktionieren. D.h. bei _delay_us und _delay_ms muss Optimierung eingeschaltet sein usw. Die Zeiten an sich müssen mit dem Datenblatt übereinstimmen. Die LCD-Library aus dem AVR-GCC-Tutorial hat z.B. auch einen Kommentar zur Länge des EN-Pulses... 3/ Die Befehle
-
Thread
MSP430 MSGCC Performance
Hig-Teil einzeln zu vergleichen, das spart sicher eine Menge Rechenzeit. Aber eigentlich müsste der GCC doch auch das gleiche machen. Komisch.
Ist "divisor" dabei eine 2er-Potenz? Ist Optimierung eingeschaltet? Generische Division dauert halt etwas, vor allem wenn auch noch 32bit auf 16bit Prozessor. Anonsten rück mal den erzeugten Assembler-Code raus (gcc -S).
-
Thread
Bitweises vergleichen von Variablen
Es > wird nicht schaden, alle globalen Variablen "volatile" zu machen. Doch: die fehlende Optimierung kann man schon als Schaden ansehen, das ist einfach lausig. Selbst solche Variablen, die volatile sein müssen, cachet man u. U. besser in einer separaten (lokalen) Variable, bspw. innerhalb
nicht verallgemeinert habe, finde ich sehr bedauerlich. Wo siehst Du ein Problem durch "fehlende Optimierung" beim obigen Code? Gruß Fred
-
Thread
Takte pro Befehl
Bestfall vom Compiler automatisch durch memmove ersetzt, im schlechtesten Fall behindern sie die Optimierung.
fehlenden Semikolons nicht compiliert und nur ein Element weniger als das erste kopiert, erzeugt GCC ansonsten identischen Code.
-
Thread
Wie effizient arbeiten PCs?
Beispiele: Flash, mehrere Websites parallel, HTML 5 mit mittlerweile 3D Javascript Grafiksachen. 3. Optimierung: früher wurde mehr Software wirklich in C hard gecoded. Heute nimmt man vermehrt auch interpretierte Sprachen, da sie einfach flexibler sind (z.B. beim Debuggen oder um systemübergreifend sein zu
einfach Leute die glauben, je komplexer ein System ist um so besser, und dass sich Komplexität zur Optimierung immer lohnt. Somit werden die Programme teilweise 10 mal so groß, was jede Optimierung wieder eliminiert. Lies mal "The Art of Unix Programming" (gibts auch online) und Du liest eine informierte
-
Thread
Zehntel springt von 4 wieder auf 2. Warum?
Jens N. schrieb im Beitrag #5748429: > Optimierungen der Debugger sich nicht 100% an die Reihenfolge hält. Das kann man dem Compiler verbieten. Wenn alles läuft, werden die Optimierungen wieder eingeschaltet.
Philipp M. schrieb im Beitrag #5749059: > Besser noch, -Og: -Og ist relativ neu, hat nicht jede avr-gcc Version.
-
Thread
Avr Studio 4 und die neue AVR Toolchain - So funktionierts!
an. Es steht hier im Normalfall "-gdwarf-2". Hiermit wird das Format Dwarf Version 2 erzeugt. Die GCC-Entwickler erlaubten sich aber ab einer bestimmten GCC-Version auch Erweiterungen aus den Versionen 3 und 4 mit einzubringen...das bracht dem AVR Studio 4 das Kreuz! Man muss ZUSÄTZLICH folgendes
und dem Studio 4.19 funktioniert es. Danke für dem Tipp Andi. --- Der Thread sollte nach GCC verschoben werden, dort sinkt er langsamer nach unten.
-
Thread
Liest hier jemand von SEGGER mit? Ich hab da mal ne Frage Emulation fehlerhaft?
Montag. PS: Der Code auf dem ich aufbaue beruht darauf: https://github.com/0xc0170/kinetis_klxx_gcc/blob/master/gpio_demo_frdmkl05z/main.c In der main() habe ich bisher lediglich das Toggeln mit PTOR durch ein abwechselndes PSOR und PCOR aller drei Farben ersetzt, das läuft auch wunderbar, auch
J-Link mit der J-Link Software (J-Link GDB Server) an Stelle des OpenOCD zu verwenden um von allen Optimierungen gebrauch machen zu können. Johannes - J-Link Development / Support
-
Thread
Bibliothek: MAX 7219 / 7221 an AVR (GCC)
Hallo, ich habe eine kleine Bibliothek geschrieben um einen MAX 7219 mit einem AVR Mikrocontroller anzusteuren. Wer Interesse daran hat kann sie sich runterladen und sie ohne Einschränkungen benutzen. Getestet wurde sie mit einem 7219er jedoch sollte sie auch mit einem 7221er funktionieren. Die meisten Funktionen dienen dazu eine Zahl auf einer bis zu 8-Stelligen 7-Segment Anzeige, die gemäß des Datenblatts angeschlossen wurde, darzustellen. Die Funktion "max7219_send" kann jedoch mit beliebigen Parametern aufgerufen werden und dazu benutzt werden die angeschlossenen LEDs völlig individuell