-
Thread
Debug ANSI C Programm, RaspberryPI.
Henrik Wellschmidt schrieb im Beitrag #2983360: > Ich schwöre ... kein Mux! > pi@rpi ~/1wirevz $ sudo gcc -Wall -Wextra -Werror -o /usr/sbin/1wirevz 1wirevz.c -lconfig -lcurl > pi@rpi ~/1wirevz $ Tatsächlich. Auf der pi bekomme ich mit dem aktuellsten Code mit gcc-4.6.3 mit -Wall -Wextra keine Warnung
Rückgabewerte von fgets, chdir und write. Immerhin weis ich jetzt, dass ich in Zukunft den raspian gcc bei Warnungen nicht trauen kann.
-
Thread
GCC Compiler Flags während Build
Optionen für bestimmte Mudule setzen wie[pre]modul.o: CFLAGS += -fno-lto[/pre]Ohne modulübergreifende Optimierung ist es schon mal einfacher, ein Modul einzugrenzen.
Eben gefunden auf https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html "... You can invoke GCC with -Q --help=optimizers to find out the exact set of optimizations that are enabled at each level. ..."
-
Thread
C -> Port Bitset
geschweiften Klammer! Dann geht dein > Beispiel auch ohne die geschweiften Klammern beim "if". bei gcc nicht nötig, da impliziert durch die {} klammer und sowieso schon alles ugly. mt
>> Immer ein "do-while(0)" um die geschweiften Klammer! > > bei gcc nicht nötig, Bei jedem C-Compiler nötig! Siehe http://c-faq.com/cpp/multistmt.html
-
Thread
Problem mit STM32F103 und RAM-Größe
erstmal schauen, was er mit Compiler-Optionen erreichen kann. Da helfen zum Beispiel entsprechende Optimierung-Flags wie zum Beispiel -Os. Auch FLTO (in Verbindung mit gcc) kann einiges an RAM-Bedarf optimieren. Natürlich ist es sinnvoll, String-Konstanten auch als solche zu definieren, das wurde oben
Dazu kommt das der gcc den M0 grob vernachlässigt und deutlich schlechter optimiert als bei >= M3. Der Keil Compiler holt da mehr raus, bis 32k Codesize lief der auch in der kostenlosen Testversion.
-
Thread
Speicher-Adressen-Marco - suche Hilfe
xdata[/c] oder auch "global" per Kommandozeile, da daß man den Code nicht anfassen muss:[pre]avr-gcc ... -Dcode= -Ddata= -Dxdata=[/pre] Daß statische read-only Daten bei AVR üblicherweise im Falsh abgelegt werden ist lediglich eine Optimierung — allerdings eine, die aufgrund des sehr begrenzten SRAM bei vielen Anwendungen essenziell ist. Mit avr-gcc 4.7 und neuer gibt es den Address-Space Qualifier __flash gemäß der Embedded-C Erweiterung ISO/IEC TR 18037. Damit könnte das dann auch so aussehen:[c]#define code __flash[/c] Damit werden die "
-
Thread
CPP Code nach C portieren. endet in Stackoverflow.
wenn ich den Header von void matrix... ins h kopiere. Ansonsten bin ich für offen für jegliche optimierungen! Arc Net schrieb im Beitrag #3939803: > Da könnte es helfen die ins Flash zu legen. Wie macht man dies beim STM bzw. beim ARM-GCC?
Claudio H. schrieb im Beitrag #3939820: > Wie macht man dies beim STM bzw. beim ARM-GCC? "const" davor. Nur müssen die dann schon fertig initialisiert sein. Du brauchst also ein Hilfsprogramm, das den Quelltext davon generiert.
-
Thread
weitere Zeigerfrage
volatile sein, bzw. auf ein volatile zeigen (wie macht man das??) um dem Compiler vor irgendwelchen Optimierungen abzuhalten. MfG Falk
ti_register_t ti_registers[] PROGMEM = { > {PORTA, "porta"}, PORTA ist kein Zeiger. > Der GCC weigert sich aber, das zu kompilieren, da der Initialisierer > nicht konstant ist ("../src/ti.c:103: error: initializer element is not > constant"). Der Fehler bezieht sich auf PORTA, DDRA und PINA
-
Thread
SDCard, Widerstands-Level-Converter, Speed?
mehr Hinweise finden? Wie mache ich das, oder wo finde ich mehr Infos drüber? Bzgl. ASM-Code Optimierung. Habe schon recht viel erreicht.. komme von 372 KB/sec. lesen und mit Code-Optimierung, inlining komme ich auf 486 lesen. schreiben 166 -> 216 KB/sec. http://www.matuschek.net/atmega-spi/
Und hier noch ne dreckige Lösung in Assembler für GCC. Dort wird SPIF nicht abgefragt:)
-
Thread
Projekt funktioniert nach Neuinstallation von WINAVR nicht mehr
Einziger Anhaltspunkt: Winavr gibt beim kompilieren folgende Warnung aus: c:/winavr-20100110/lib/gcc/../../avr/include/avr/signal.h:36:2: warning: #warning "This header file is obsolete. Use <avr/interrupt.h>." Hatte schon jemand mal dieses Problem? Kann mir jemand helfen? Bernd
Kann z.B. an einer "aggressiveren" Optimierung im neueren WINAVR liegen. Wenn du im Code z.B. Einfachst-Warteschleifen mit Variablenhochzählen hast statt der _delay_Xs() Funktionen, wäre das eine Problemstelle. Auch in der Gegend gemeinsam
-
Thread
gcc: variable an funktion übergeben
Moin Leute, ich habe follgende Funktion geschrieben um meinen Servo via PWM zu steuern. [c] void set_servo(int pos) { PORTB |= (1<<PB1); _delay_us( pos );//geht nicht //_delay_us( 1500 );//geht //_delay_us(serv_R);//über #define gesetzt, geht auch PORTB &= ~(1<<PB1); _delay_ms( 15 ); // ist nicht kritisch } [/c] wenn ich set_servo(2000) aus der main rufe, klappt es nicht. Beim debuggen kommt aber die 2000 in pos richtig an. Wenn ich in der set_servo den befehl "_delay_us( 1500 );" verwende anstatt "_delay_us( pos );" geht es Beim flash ist mir aufgefallen
-
Thread
.c Datei kompilieren (krieg ich einfach nicht hin)
############## ## General Flags PROJECT = cdcemu MCU = atmega8 TARGET = cdcemu.elf CC = avr-gcc CPP = avr-g++ ## Options common to compile, link and assembly rules COMMON = -mmcu=$(MCU) ## Compile options common for all C compilation units. CFLAGS = $(COMMON) CFLAGS += -Wall -gdwarf
from ../main.c:4: e:/winavr-20100110/lib/gcc/../../avr/include/avr/signal.h:36:2: warning: #warning "This header file is obsolete. Use <avr/interrupt.h>." In file included from ../main.c:6: e:/winavr-20100110/lib/gcc/../../avr/include/avr/delay.h
-
Thread
Multiplizieren geht schief
Wahrscheinlichkeit brauchst du ihn auch gar nicht, sondern hast vielleicht nur vergessen, die Optimierung des Compilers einzuschalten.
Überschreiben wieder auf 0 gesetzt werden, etwa wenn ein MUL verwendet wurde. Siehe ABI http://gcc.gnu.org/wiki/avr-gcc#Register_Layout > wenn der Compiler da was wegoptimiert Es ist Assembler-Code, der Compiler bekommt ihn nie zu sehen. > es scheint als ob der Fehler von ausserhalb kommt
-
Thread
AT90CAN128 UART Bug? Atmel rausschmeißen?
aufgefallen sein. Poste dochmal nen kompletten Testcode, der den Fehler zeigt. Und da Du nicht den AVR-GCC benutzt, auch das erzeugte Assemblerlisting (mit den Codezeilen). Peter
vergessen: Eventuell kann auch der Compiler was falsch machen (sehr sehr selten) deshalb: alle Optimierungen aus. MfG Joe
-
Thread
Programmierung von ATmega8-16PU macht Probleme
Optimierungsstufe des Compilers schaltet man in den Compiler-Optionen ein (ergibt dann beim Aufruf des gcc -O0, -O1, -O2 oder -O3). Ohne Optimierung kann der Compiler die Delay-Zyklen nicht bestimmen.
Aha, das bei PD0 sieht mir nach Leichtsinnsfehler aus... Sch**ße... Das mit der Optimierung werd ich mal testen. Danke Christian
-
Thread
Aus Programm heraus in den Bootloader springen
Naja, ich bin bei mir knapp an der 64kB-Grenze. Gut, wenn ich beim Kompilieren Optimierungen einschalte wird es auch weniger. Respekt, wenn du in der Regel mit nem AtMega8 auskommst. Wieviele Zeilen C-code haben dann deine Programme so? Wäre es denn arg schwer, den bootloader so
ich habe den Ansatz mit dem Sprung in den Bootloader weiterverfolgt und dabei einen Thread im gcc Forum gefunden: http://www.mikrocontroller.net/forum/read-2-416971.html da ich das auch mit gcc mache und Ergebnisse nicht allgemeingültig sind poste ich meine Lösung in den gcc Thread.
-
Thread
Atmel Studio 6 - Buildproblem
funktioniert auf Eclipse ja nicht aber auf Atmel Studio >6 :( Dann hattest du bei Eclipse evtl. die Optimierung nicht eingeschaltet, beim AVR STudio aber schon. Und bumm fliegen einem Warteschleifen die für den Compiler keinen Sinn machen um die Ohren. Wegoptimiert. Code zeigen!
auf Eclipse ja nicht aber auf Atmel Studio >>6 :( > > Dann hattest du bei Eclipse evtl. die Optimierung nicht > eingeschaltet, beim AVR STudio aber schon. Und bumm fliegen > einem Warteschleifen die für den Compiler keinen Sinn machen > um die Ohren. Wegoptimiert. > > Code zeigen! das ist
-
Thread
Boost.preprocessor library
Okay dann hast du da andere Erfahrungen gemacht. Nun, wenn du dir so sicher bist dass der Fehler im GCC liegt, kann dir hier vermutlich auch keiner helfen. Nun gut, du hast ja auch keine konkrete Frage gestellt.
Im Prinzip ginge es auch mit C Mitteln ohne constexpr, dann müsste man sich aber auf die Optimierung des Compilers verlassen, dass die Berechnungen zur Compilezeit stattfinden.
-
Thread
GCC inlined die ganze Zeit meine Funktionen.
Hallo! Ich habe gerade ein Problem mit meinem GCC, Version ist das neuste WinAVR (vom Juni). Und zwar meint er trotz Optimierung -Os häufig Funktionen inlinen zu müssen, auch wenn das aus meiner Sicht völlig schwachsinnig / verschwenderisch ist. Gibt
C-Files heraus, in das Object-File compilieren. Edit: `-finline-limit=N' Scheint die richtige GCC-Stellschraube zu sein...
-
Thread
Präprozessor: Variable Anzahl von "nop"s?
Instruktionen je nach Prozessortakt konfigurierbar >machen. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 MFG Falk
incunabulum) >1 µs ist hier sichtbar langsamer verglichen mit 6 nop-Commands = ca. 500 >ns. Optimierung eingeschaltet? >Daher meine Idee, mir ein entsprechendes Makro zu schreiben.... Die gibt es schon, siehe Doku der libc. MFG Falk
-
Thread
Handycamera MCA-25 ansteuern - ip webcam mit mega32
sieht so aus als ob der gcc4 irgendwelche probleme hat... ich code/übersetze mit dem gcc3: >avr-gcc --version avr-gcc (GCC) 3.4.3 Bye, Simon
wollte, wenn ich die manpages von apt-get richtig verstanden habe, mit dem Befehl: "apt-get install -s gcc-avr=1:3.4.3" deine Version installieren. Da sagt er mir aber: "E: Version '1:3.4.3' for 'gcc-avr' was not found" .. mit "apt-get install -s gcc-avr=1:*" will er 1:4.0.2-1 installieren (die ich
-
Thread
Beschränkung bei den Schiebebefehlen?
Ja, avr-gcc verhält sich "interessant". Er macht die Schieberei nur in 16 Bit und setzt die restlichen Bits auf den gleichen Wert wie Bit 15. Das passt zu dem von dir beschriebenen Verhalten. Eine Lösung, wie
danke dir. genau das wollte ich verhintern. interessant ist auch, das avr-gcc 0x0000000F * 0x00001000 genauso behandelt, 0x0000000F * var (wobei var gleich 0x00001000 ist) mir richtig berechnet. kenntst du zufällig den exponent befehl auswendig, sodaß ich ne zahl hoch ne zahl
-
Thread
Atmega32 - GCC: Problem mit long
Hi Ihrs, ich habe folgenden Code: volatile unsigned long seconds = 0; void RTC_Overflow() { seconds++; IO_Write(seconds); } IO_Write gibt den Wert einfach über LED's aus. RTC_Overflow wird jede Sekunde über einen Interupt aufgerufen. Mein Problem ist das sich bei den LED's nichts tut (seconds beibt immer 0). Wenn ich seconds als int deklariere (volatile unsigned int seconds = 0;) klappt alles ohne Probleme. Hat jemand eine Idee wodran das liegen könnte? Früher hatte der selbe Code mal geklappt?!? (Auch Optimierung ausschalten bringt nichts) Gruß Lalle
-
Thread
Projekt Schaufelraddampfer
schreiben, wie ich will und muss mich nicht dem C Compiler ausliefern. Hab' mir mal Eclipse und den AVR GCC installiert, das ist keine schlechte Programmierumgebung, aber um anzufangen brauchst Du erstens Durchsetzungs- und auch Leidensbereitschaft, zweitens ist meiner Meinung nach im GCC die Anwendung von
Und das ist das eigentlich Schöne: Ich hab' die Wahl. Die hab' ich mit den Inline Verrenkungen des GCC nicht wirklich.
-
Thread
Reihenfolge der Structs im Speicher durcheinander
würfelt der Compiler mir die Stukturen beim optimieren durcheinander. Ich habe versucht die Optimierung für den Bereich auszuschalten. #pragma GCC optimize ("O0") (ARM GCC Compiler) Leider funktioniert das nicht. (Weiß nicht warum.) Ich habe auch versucht die Strukturen in eine weitere zu verpacken
ich dem Linker für einen Codeabschnitt sagen kann, das er die Variablen nicht optimieren soll? (ARM GCC)
-
Thread
KS0108 GLCD Routinen
avr-gcc -v sagt mir: gcc version 3.3 20030512 (prerelease)
gcc version 3.3.1 muss wohl aber daran liegen. in meiner avr-gcc dokumentation ist PRG_RDB() deprecated und man soll statt dessen pgm_read_byte() verwenden
-
Thread
Senden einer Infrarotsequenz
Ich würde rein gefühlsmäßig bei sowas auch die Array-Variante vorziehen. Dachte nur nicht, dass der GCC die 64 Bit Sachen so vermasselt. Wie gesagt, bei 32 Bit sieht es definitiv besser aus.
Sind ja keine > Rechenoperationen, die hier durchgeführt werden. Das 64Bit-Paket wurde beim AVR-GCC mit der heißen Nadel dazugestrickt, d.h. völlig ohne jegliche Optimierung. Jeder 64Bit-Operator ruft ganze Orgien von MOV/PUSH/POP und sehr lange Funktionscalls auf. Ich hab mal testweise ein
-
Thread
Servo ansteuerung! Hab ich was übersehen? [AVR GCC]
5); // Pins B5 als Ausgänge setzen while(1) { Move_Servo(150); } } Compiler: avr-gcc.exe -mmcu=atmega8 -Wall -gdwarf-2 -O0 -MD -MP -MT servo_self.o -MF dep/servo_self.o.d -c ../servo_self.c avr-gcc.exe -mmcu=atmega8 servo_self.o -o servo_self.elf avr-objcopy -O ihex -R .eeprom
Du hast die Optimierungen ausgeschaltet. Dadurch werden die in den delay-Funktionen benötigten Fließkommaberechnungen zur Laufzeit durchgeführt und verlängern das Delay. Deine 4 Mikrosekunden werden also vermutlich in Wirklichkeit
-
Thread
Was macht ein AVR bei einer Division durch Null?
-Kompiler gefallen, wenn man ihm einen Quelltext > gibt, der eine Division durch Null erzeugt? GCC gibt eine Warnung. Wenn er es merkt.
http://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/config/avr/lib1funcs.S?content-type=text%2Fplain&view=co Für die nicht zwingend saturierenden Fixed-Point Divisionen sind m.W. ebenfalls so, daß diese auf den Maximal
-
Thread
m16c Complier
den NC30. Irgendwann hab ich auch mal was gelesen, das sich ein paar Leute drangemacht haben den gcc für den m16c anzupassen, was daraus geworden ist kann ich dir aber leider auch nicht sagen, hab schon lang nicht mehr nachgeschaut. Gruß Peter
An dem gcc für m16C wird wohl noch gearbeitet, aber konkrete Ergebnisse gibts da noch nicht. @Peter: Wie ist das mit Eclipse? Hört sich interessant an. Ich habe mal auf deren Seite geschaut, aber es sieht
-
Thread
allgem. Frgen Atmega
, was von mehreren Threads/Funktionen aufgerufen oder verwendet wird. Damit der Compiler keine Optimierung durchführt die den Inhaltz beim Threadwechsel zerhacken könnten. Also Felder, Variablen usw. 2.) http://www.mikrocontroller.net/articles/Sleep_Mode Gruß
Timo P schrieb: > 1) ist es möglich, einen codeblock als volatile zu definieren? WINAVR In GCC 4.4 lässt sich für ganze Funktionen die Optimierung individuell einstellen/abschalten (attribute, pragma). Ist aber mit Vorsicht zu betrachten, volatile ist sinnvoller.
-
Thread
Atmel oder PIC
Debugger etc... ohne irgendwelche Demo/Eval Einschränkungen. Du kannst aber auch mit Eclipse + AvrGcc (C-Compiler) arbeiten, es gibt ein AVR-Plugin für Eclipse..
etc... ohne > irgendwelche Demo/Eval Einschränkungen. > > Du kannst aber auch mit Eclipse + AvrGcc (C-Compiler) arbeiten, es gibt > ein AVR-Plugin für Eclipse.. MPLAB, die Einschränkungen des Compilers (gcc...) im Eval-Modus (nicht alle Optimierungen) sind in vielen Fälle vernachlässigbar. MPLAB
-
Thread
Overhead Funktionsaufruf über Pointer
zu 15% mehr Geschwindigkeit bekommen bei ca. 95% Codegröße. Übrigens, ein e200z4 (PowerPC VLE, GCC 4.8.0) ist bei gleicher Taktfrequenz ca. 1,6x so schnell (bei 1,75-facher Codegröße). Jörg
ineffizienter machen? Passieren kann das m.E. eigentlich nur aus zwei Gründen: Du hast einen Bug gefunden oder gcc kennt deine Cache-Grössen nicht (oder eben falsch). Schon mal mit l1-cache-size=xxx gespielt?
-
Thread
Probleme mit volatile struct * und gcc
Hi, ich hab hier ein Problem mit den Optimierungen, die der gcc auf einen Pointer einer Struct anwendet: Zum Patienten: In bus.c wird ein Pointer auf eine Struct definiert: [c] volatile struct frame * bus_frame; [/c] In bus.h wird der
= 1){ bus_frame->isnew = 0; } wdt_reset(); } } [/c] Der gcc generiert mir aus der Schleife folgendes: [avrasm] void bridge_mainloop(void) { 2ba: e0 91 57 02 lds r30, 0x0257 2be: f0 91 58 02 lds r31, 0x0258 2c2: 01 c0
-
Thread
Z80 wie AVT nutzbar? Gesperrt
Wenn es auch C sein darf ... Mit dem Suchterm "GCC Z80" findet man z.B. https://sourceforge.net/projects/z80gcc/ Um die Basis-Routinen für I/O etc. wird man sich, - wie zuletzt von Georg erwähnt -, vermutlich dennoch kümmern müssen und dafür gute
Theor schrieb im Beitrag #5665114: > Mit dem Suchterm "GCC Z80" findet man z.B. > https://sourceforge.net/projects/z80gcc/ Last Update: 2015. Und Dateien gibt's da auch keine. Das war ja mal ein Griff ins Klo. Es gibt zwei nennenswerte offene C-Compiler
-
Thread
Struct per Pointerzugriff befüllen
Beitrag #4368264: > Wie gesagt, memset scheidet aus. warum? hast du es mal gestestet (auch mit Optimierung)? Ich würde erwarten das der Compiler es inline als Schleife baut.
Die (korrigierte) Schleife ist kleiner als memset und passt! Optimierungen sind natürlich an. Die Standardfunktionen sind halt nicht immer das Optimum.
-
Thread
"State Machines": Anzahl States minimieren oder maximieren?
> SomethingElse = 20 > } State_t Mit solchen Lücken, macht man sich fix die Switch/Case Optimierungen kaputt. Es degeneriert zu einer if Kaskade.
Fanboy D. schrieb im Beitrag #5494611: > Mit solchen Lücken, macht man sich fix die Switch/Case Optimierungen > kaputt. Es degeneriert zu einer if Kaskade. Zeig mir doch mal bitte 'nen Beispiel dafür.
-
Thread
Anfängerfrage: LED Toggle in C - ATtiny13/ATmega8
definieren, und du musst die Optimierungen an machen ( mindestens -01)
Wurst sein. Ja, dass ging aus deiner Aussage jetzt nicht so direkt hervor ob du das auch tust. >(Im GCC kann ich ja unter Symbols die Frequenz selber angeben) Wenn du das auch machst ist alles Ok.
-
Thread
Tut gelesen und trotzdem Problem mit Strings im Flash
dann hängt sich der Kontroller auf. Die Beispiele im Tutorial habe ich auprobiert, auch die in der GCC Faq, aber das Ergebniss ist immer das selbe. Beim 8051 gibt es ja das Iram mit 256 Bytes, gibt es das beim AVR auch? Wie schaffe ich es die 4K Ram beim AVR komplett zu nutzen? Mein Buffer im Ram
an diesem Problem aus. Dementsprechend Banane sieht der Code mittlerweile auch aus. Eine "IRam optimierung" gibt es bei dem Originalcode vom AT89C51ED2 leider auch nicht, weil ich da natürlich alles "Datenfressende" in das XRAM verschoben habe. Aber der Hinweis das es eigentlich so funktionieren müsste
-
Thread
volatile oder nicht volatile bei Feldvariablen, AVR GCC
verwendet wenn es sich um Felder handelt auf die man kein Polling macht? In diesem Fall stört die Optimierung doch nicht, oder? Danke für Eure Antworten
Theoretisch müsstest du das Feld wohl volatile machen. In der Hauptroutine kann der gcc durchaus auf die Idee kommen, etwas bereits gelesenes nicht nochmal aus dem Feld zu holen, also würde ich es nicht wagen, volatile weg zu lassen. Wenn du nur wie gezeigt in der Schleife durchläufst
-
Thread
Total den Überblick verloren !
Ich hab mit dem AVR angefangen um C zu lernen ( AVR-GCC kostenlos und goil). Aber wie Andreas sagt habe ich auch erstmal einwenig über asm reingeschnuppert, wie der sich "anfühlt". Das zahlt sich später doppelt aus wenn du beim debuggen auch mal z.B. auf
compiler eigentlic so macht / produziert. Das kann sehr nützlich sein bei der Fehlersuche und Optimierung. Gruß Bernhard
-
Thread
Wie verarbeitet der GCC die Speicherklasse extern?
Variable. Selbst wenn der Programmierer das selber nicht so gedacht hatte. Das ganze funktioniert beim GCC nämlich auch ohne das "extern" vor der Deklaration. Hier sind die erwähnten Dateien: [c] /*main.c*/ #include <stdio.h> #include "erste_datei.h" int ersteVariable = 13; /*<- 1*/ int zweiteVariable
(.comm) "überlagert" werden — zumindest wenn der Compiler das implementiert, was zum Beispiel bei GCC der Fall ist (-fcommon ist immer noch Default). Wenn man das nicht möchte, compiliert man mit -fno-common, und erst dann meckert der Linker "multiple definition of" an. Definitionen (nicht tentative
-
Thread
Zeit für Function call bestimmen
Hi, Ich hab für einen ATmega mit avr-gcc eine AES Implementierung geschrieben. Schalte ich die Optimierung aus (-O0) kann ich debuggen und mittels Debugger die Laufzeit für eine Verschlüsselung bestimmen. Soweit so gut. Nun möchte ich aber die Laufzeit für eine Verschlüsselung mit Optimierung (-O2) bestimmen. Der Debugger funktioniert ja jetzt leider nicht mehr. Meine Idee wäre: Am Mikrocontroller die Zeit zu messen und sie auf dem seriellen Port zurückzuschicken. Sowas in der Art
-
Thread
Micronucleus - USB-Bootloader für ATtiny
recht einfach: 1) Installieren des Bootloaders auf dem ATTiny85 Voraussetzung: - Aktuelle GCC-AVR Toolchain - AVRdude Wechseln in das Verzeichnis /firmware. Wenn kein USBASP verwendet wird, muss das makefile angepasst werden (PROGRAMMER=) Wenn USB nicht an PB3 und PB4 angeschlossen ist
einfach* zu machen, siehe *.inf-Files editieren oder Zadig & Co. Unter Linux alles kein Problem, [code]gcc -lusb ...[/code] und fertig. Ciao, Martin
-
Thread
sprintf verfälscht adc werte
Seiteneffekte beliebigen Speicher und beliebige Register modifizieren können (was aus Gründen der Optimierung aber sonst unerwünscht ist, aber oben im Bezug auf den ADC-Wert der Fall ist). So jedenfalls habe ich es aus einer längeren und sehr interessanten Diskussion vor ca. 2 Monaten in comp.embedded
Ja. Die Optimierungen moderner Compiler, die dem Einen ein Segen sind, werden sonst leicht zum Fluch.
-
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
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
String Übergabe an asm-funktion
nach dem Aufruf der Funktion befindet er sich in Registern r24 und r25. Y-Pointer (r28,r29) wird vom gcc verwendet, also habe ich versucht die Adresse von data in X-Pointer zu laden: mov 26, 24 mov 27, 25 Und dann so zu speichern(work = r20): in work, ADCH /*Hier haengt sich das Programm auf*/ st
) Ja, das müsste funktionieren. > >>Eine richtige Idee, warum... > Ja, eben warum benutzt gcc doch diesen X-Pointer, in der asm Ausgabe > die mit -S erzeugt wird kommt er jedenfalls nicht vor. Ich glaube, X nimmt GCC nur selten. Vorzugsweise nimmt er Z. > >>was ist an dieser Funktion
-
Thread
Unbenutzte Funktionen beim kompilieren
Hallo Ich benutzte avr-g++ und avr-gcc zum Kompilieren und avrdude um Programme auf einen atmega328p zu übertragen (auf einem Arduino Uno, aber ohne Arduino-IDE). 1. Ich laß, dass beim Kompilieren alle Funktionen die in einer Headerdatei
Variablen sowie globale Variablen bereits entfernt. Das geht manchmal auch zu weit! Drum kennt GCC das __attribute__((used))
-
Thread
AVR gcc mit 64-Bit-Werte mit int64_t
compilieren kommen weder Fehler noch Warnhinweise. Wo liegt das Problem. Habe auch schon die Compiler-Optimierungen durchprobiert. Gruß Alexander
referenzierten Quellen — die zu deiner Toolchain-Distribution passen — besorgen. Die Datei liegt dort in ./gcc/libgcc2.c Für die aktuelle, offizielle Version 4.7: http://gcc.gnu.org/viewcvs/trunk/gcc/libgcc2.c?content-type=text%2Fplain&view=co Zur libgcc gehort jedoch mehr als nur diese eine Datei.
-
Thread
gcc erfindet befehle?
return 1; } das programm (ich habe den code mal auf die relevanten zeilen reduziert) wird vom gcc (version 3.4.5) mit der optimierung "s" für den atmel ATtiny26 folgendermaßen übersetzt: 1 .file "test.c" 2 .arch attiny26 3 __SREG
GCC ist nicht optimal für 8bit-Prozessoren. Generell geht GCC von mindestens 16bit breiten Maschinen aus - und das sieht man dann gelegentlich auch. Besser wird es mit -mint8, also 8bit "int" Typ, allerdings