-
Thread
GCC inline assembler
benutzen. Es ging ja darum das der GCC 19 Takte benötigte für eine einfache Speihceroperation die 8 Takte braucht. @Albi, Hm, wenn machbar würde ich solche Tricks eben vermeiden. Einfach um den Source übersichtlich zu halten.
r25 2077 0b6c 0895 ret [/avrasm] Scheint das man das also generalisieren kann und der GCC damit immer besseren Code erzeugt. Besonderst das letzte ASM geht manuell gecodet nicht besser zu machen. Gruß Hagen
-
Thread
Mengendeklaration in C
"Man könnte dem gcc nun bestimmt beibringen, Compile-Time-Konstanten grundsätzlich um Flash abzulegen und über "LPM" etc. darauf zuzugreifen." Hmm. Bereits das folgende (banale) Beispiel dürfte zeigen, wie
, warum ein AVR-Compiler sowas nicht können soll. Daß die Handhabung von Flash-Variablen im AVR-GCC etwas umständlich ist, ist also ganz alleine eine Sache des AVR-GCC und nicht der AVR-Architektur. Aber auch bei µCs mit von Neuman Architektur braucht man trotzdem noch extra Specifier, um die
-
Thread
ATTiny2313 Speicher reicht nicht aus
Hi, i.A. werden Source größe und Laufzeit Optimiert, dafür einfach mal auf die GNU-GCC seite gehen und nach Optimierungstufe gucken (AVR-GCC nutzt die gleiche Opti.) grüüüße
-Geschwindigkeit, wobei -O3 afair i.d.R. den schnellsten Code erzeugt. -O0 bedeutet gar keine Optimierung.
-
Thread
Arduino Präprozessor Pin Change Interrupt und Version automatisch zuweisen
www.microchip.com/webdoc/avrassembler/avrassembler.wb_preprocessor.html Options for the C compiler avr-gcc Machine-specific options for the AVR http://www.nongnu.org/avr-libc/user-manual/using_tools.html http://public.beuth-hochschule.de/~kempfer/skript_c/Kap10.html Mit "trickreich
irgendwie kann. Ansonsten wäre das nun ein guter Grund, mal Linux auszuprobieren. Dort fühlt sich gcc sowieso mehr zuhause und läuft auch viel schneller.
-
Thread
[AVR|C] Codeschloss Projekt - wie den Code verbessern
mit denen du auf IO-Variablen zugreifst. Tipp #1: bis() und bic() sind "anders" als im [[AVR-GCC-Tutorial]] unter http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#IO-Register_als_Parameter_und_Variablen beschrieben. Die beiden anderen Funktionen, die mit IO-Registern arbeiten, hast du besser
beim Aufruf des Kompiliers noch etwas verbessern kann, oder Sachen untüpisch sind. Aktuell: avr-gcc -mmcu=attiny2313 -Os -o name.out name.c LG: jan
-
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
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 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
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
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
Seltsames Compilerergebnis
kann diese Optimierung Fliesskomma-Rechenoperationen ein Vielfaches beschleunigen. Deshalb steckt das im GCC drin. Beim AVR ist das ein nur selten erwünschter Nebeneffekt - den man mit irgendeinem -fno-loop-unrolling oder so auch abschalten kann. Generell ergibt alles andere als -Os beim GCC/AVR wenig Sinn.
-
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
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
pgmspace.h bringt AVR Studio zum Absturz?!?
> int main(void) { while(1){} } Also echt nix Spezielles. AVR Studio Version 4.12 + AVR-GCC Version 1.4.4 verwende ich, sonst nix Spezielles. Die build Datei wurde beim Standard belassen (ATMEGA32, -o0 Optimierung, 16 MHz als Angabe für Taktfrequenz). HALLO? Bin ich blöd? PS: Notfalls versuche ich AVR Studio und AVR-GCC zu aktualisieren, aber das Problem wird mir nicht klar.
-
Thread
Datentypen und Berechnungen
Hm, ohne Optimierung wird der Code viel länger: uint8_t test2(uint8_t a, uint8_t b) { 92: df 93 push r29 94: cf 93 push r28 96: 00 d0 rcall .+0 ; 0x98 <test2+0x6>
von test2 nur ein 8-Bit Wert returniert. Dies ist so sein das ABI geändert wurde, irdendwo zwischen GCC Version 4.2 und 4.3 wenn ich mich recht entsinne: Es gibt keine Promotion von 8-Bit Werten zu 16-Bit Werten mehr.
-
Thread
Präprozessor Ausgabe in Datei ausgeben
InitEvents(); // Port directions InitPorts(); SPIBitBangedShiftData0(0xAA); [/c] WinAVRs gcc schluckt das ganze soweit. Warum die Funktion als Makro? Schon mit niedriger Optimierung weiss gcc, dass er gewisse Dinge nicht wirklich kompilieren muss und die Bit-Schieberein selbst erledigen
umleiten. Das kopiere ich mir für verschiedene Fälle heraus und lasse das kompilieren. In der Doku von gcc hab ich folgendes gefunden: [pre]-o file Write output to file. This is the same as specifying file as the second non-option argument to cpp. gcc has a different interpretation of a second non-option
-
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
Ab wann C statt ASM ?
Nutzt du die kostenlose Toolchain des GCC -> WinAVR GCC genannt und Atmel-AVR-Studio so kannst du - C programmieren lernen - findest viele Beispiele zu eigentlich allen Themen wie Timer, SPI, I2C, UART und ADC - hast eine ausreichend gute
wichtigsten, du erfüllst noch einen guten Zweck weil du die freie Arbeit der Entwickler vom WinAVR GCC damit indirekt unterstützt ;) Gruß Hagen
-
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
-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
"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
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
ARM Programmgröße
oder Thumb zwischen 1KB und 20KB Code liegt. Letzterem Wert nähert man sich schnell, wenn man die GCC-newlib verwenden, also printf, malloc, ... Andere ARM-Umgebungen sind in dieser Frage u.U. deutlich sparsamer als WinARM/GnuARM/Yagarto. Jenseits dieses Grundballasts ist der Code insbesondere im
sieht so aus, als ob IAR bei ARM und Thumb verschiedene Backends (Codegeneratoren) verwendet. Bei GCC ist es das gleiche Backend für beide Modi.
-
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
Initialisierung von globalen Variablen in Codesourcery
0x000144b0 0x0 c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.3\libgcc.a(_divdi3.o) .ARM.extab 0x000144b0 0x0 c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.3\libgcc.a(_udivdi3
0x000144b0 0x8 c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.3\libgcc.a(_divdi3.o) .ARM.exidx 0x000144b8 0x0 c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.3\libgcc.a(_udivdi3
-
Thread
Alseits beliebt GCC plugin error
[pre] % avr-gcc -Os -mmcu=atmega168 -o main.elf main.c i2c_master.c In file included from main.c:2: /usr/local/lib/gcc/avr/4.2.2/../../../../avr/include/avr/delay.h:36:2: warning: #warning "This file has been moved
implicit declaration of function 'i2c_stop' In file included from i2c_master.c:18: c:/avr/winavr/lib/gcc/../../avr/include/avr/delay.h:36:2: warning: #warning "This file has been moved to <util/delay.h>." [/c] Compilieren läßt es sich aber und HEX wird erzeugt. Peter P.S.: Wenn ich die Optimierung
-
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
Taktiken zum Debuggen bei Release Builds
ReleaseWithDebugInfo-Builds erstellen. Das ist genau das was du hier willst, einen Release-Build (mit Optimierungen, ohne Asserts), der Debug-Symbole hat sodass du einen Stacktrace bekommst. Ich denke das ist hier die erste Strategie.
aber nicht sagen. Evtl. verbessern sich auch die Ausgaben, wenn Debug-Infos aktiviert sind. Beim GCC etwa ist garantiert, dass bei Aktivierung / Deaktivierung von Debug-Info der gleiche ausführbare Code generiert wird. Wenn das bei deinem Compiler nicht der Fall ist ist das natütlich blöd... Evtl
-
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
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
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
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
_delay_ms(xxx) Fehler unter Linux-Code::Blocks
avrlibc funktionieren seit Anfang der Zeitrechnung nur mit Konstanten (und nur mit eingeschalteter Optimierung). Oliver
funktionieren seit Anfang der > Zeitrechnung nur mit Konstanten (und nur mit eingeschalteter > Optimierung). Und es gibt auch auf beiden Systemen eine Warnung bei der Kompilierung...
-
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
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
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
Wie lange dauert ein Prozessschritt?
Wenn Optimierungen eingeschaltet sind, wird der Compiler die Berechnungen nicht zwangsläufig zwischen den Zuweisungen an PORTA durchführen. Die Initialisierung von Erg greift auf volatile Variablen zu und wird deshalb
Andreas B. schrieb im Beitrag #1973049: > Wenn Optimierungen eingeschaltet sind, wird der Compiler die > Berechnungen nicht zwangsläufig zwischen den Zuweisungen an PORTA > durchführen. Die Initialisierung von Erg greift auf volatile Variablen > zu und
-
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
avr-gcc verdoppelt code von Funktionsaufruf
) asm("nop"); }[/c] ---- Schachtle ich das Unterprogramm eine Ebene tiefer, so erzeugt der gcc ein 152 Byte langes Programm ----[c] #include "avr/io.h" #include "avr/portpins.h" static void init_display() { DDRA|= _BV(PD1) | _BV(PD0); DDRA|= _BV(PD1); DDRA|= _BV(PD0); DDRB|=
statische Funktionen lassen sich problemloser optimieren. Trotzdem ist es komisch, daß die Optimierung -O1 in 2 Situationen besser abschneidet als -Os Andreas
-
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
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
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
Benötigter Speicherlatz auf verschiedenen Kontrollern
War die Code-Optimierung im AVR-Studio eingeschalten? Diese ist nämlich unsinnigerweise defaultmässig auf Off [Optimizaton: -O0], ich empfehle mindestens [Optimization: -O1] zu verwenden. (Höhere Optimierungsstufen
Ok, danke. Die Optimierung habe ich als AVR-Neuling noch nicht gekannt. Das hat etwas gebracht. Danke! Kresley
-
Thread
Bit Array in C
kennen diese Spielchen alle. Und noch ein paar mehr, von denen DU noch nie gehört hast. Dreh die Optimierung deines Compilers auf und wenn es möglich ist, eine Division durch etwas Besseres zu ersetzen, dann macht das der Compiler. So etwas ist eine (triviale) Standardoptimierung seit über 45 Jahren. Wenn
_t div(int8_t x) { return x/4; } uint8_t udiv(uint8_t x) { return x/4; } [/c] Mit gcc Optimierung -Os übersetzt gibt es das: [code] 00000000 <div>: 0: 87 fd sbrc r24, 7 2: 8d 5f subi r24, 0xFD ; 253 4: 85 95 asr r24 6: 85 95
-
Thread
Bug in AVR Studio und GCC ?
Hallo, ich habe folgendes C Programm geschrieben und mit WINAVR kompiliert. Als ich die Cof Datei im AVR Studio geöffnet habe und debuggen wollte mit dem JTAG ICE habe ich bemerkt dass die laufvariable int i nicht hochgezählt wird. Obwohl dass Programm funktioniert. # include <io.h> # include <iom16.h> //ATmega8-Deklarationen int i; void main(void) { DDRD=0xFF; //Alle PORTB-Pins auf Ausgang while(1) { for (i=0;i<0xF000;i++) //Warteschleife, abhängig von AVR-Taktfrequenz {}; PORTD++; } } Im Disassembler Mode habe ich gesehen dass
-
Thread
Was passiert bei einem Überlauf
und das mischen von C mit Assemblercode ist auch nicht Standard sondern z.B. eine Besonderheit von GCC und anderen. Da aber die Hauptfrage ja war: "Die geht doch dann auf 0 und sonst nichts, oder?" und man diese mit Ja beantworten muss, spielt das alles garkeine Rolle.
Konstrukt auflösen, weil vielleicht alles zur Compilezeit bekannt ist oder sonst eine andere beliebige Optimierung. Und dann kommt bei dem SREG nur nur zufälliges Gemüse raus. Die einzige Möglichkeit ist es sowohl das add als auch das lesen des carry bits im inline-assembly auszuführen.
-
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
Anfänger in C und welcher PIC (evtl. uno32) ist geeignet ?
hilfreich/ ansiehst. Aber ich sehe hier nirgends ein PIC-Äquivalent zum [[AVR-Tutorial]] oder [[AVR-GCC-Tutorial]]. Und Leute wie PeDa oder Johann L. scheint es in der PIC-Fraktion auch nicht zu geben. Ich lese da immer nur Spinner, die jaulen als ob ich sie persönlich beleidigt hätte, wenn ich sage
hilfreich ansiehst. Aber > ich sehe hier nirgends ein PIC-Äquivalent zum AVR-Tutorial oder > AVR-GCC-Tutorial. Und Leute wie PeDa oder Johann L. scheint es in > der PIC-Fraktion auch nicht zu geben. Ja, ein Tutorial vermisse ich auch. Habe selber mal drüber nachgedacht eins zu schreiben. Ich meinte
-
Thread
Ungleichmäßiger Takt mit ISR
auf internen Oszylator mit 8MHz (CKSEL=0100 SUT=10). Verwendetes Programm wie angehängt. Code optimierung -00. Für eine PID Reglung möchte ich eine konstante Zykluszeit haben die unabhänig von der Laufzeit des Programms ist. Zumindestens solange die Ausführung des Programms kürzer als die Zykluszeit
Hoppla, wenn Du für gcc etwas bezahlt hast, dann hast Du was falsch gemacht - nur spenden lasse ich durchgehen ;-) Viele Grüße, Stefan