-
Thread
Ingenieure entwickeln besser Software
allgemeine Implementierung ab. Oder aber LP: Wenn man nicht weiß, dass ein Problem der linearen Optimierung vorliegt, wird auch nicht zu einer bestehenden Implementierung des Simplexalgorithmus greifen. Ein gutes Beispiel ist auch die Sortierung von Objekten. Mittlerweile hat jede Programmiersprache eine
bei beiden Initialisierungen der Compiler "auf die Finger >hauen". Selbst mit -Wall meckert der gcc nicht. Wieso sollte er? Beim ersten wird 5.6 als int angesehen und das Komma mit allem danach sowieso abgeschnitten und beim zweiten castet der compiler den float nach int, von sich aus. Höchstens
-
Thread
Einfachste USART ansteuerung funktioniert nicht.
> > Das passt nicht zu deiner Formel. > > Gruß > Gast Also ich jab mich strikt ans avr-gcc tutorial aus dem Forum gehalten. Werd diese Änderung am donnerstag durchführen. @USART-GAST hab mir gedacht, wenn ich die fuses per hand setze (16 Mhz siehe oben) dann dann nichts schiefgehen.
Dein Originalcode läuft hier einwandfrei, nur angepasst auf 16MHz. Compiliert mit AVRStudio4, Optimierung -Os.
-
Thread
Microcontroller Board welches wofür?
und peripherie. Es gibt einen freien Compiler ohne Codeeinschränkung (nur mit etwas schlechteter Optimierung nach 60Tagen) und massig Libs sowie Demobeispiele zentral von Microchip selbst die du ohne Einschränkung frei verwenden kannst. Egal ob Privat oder Kommerziell. Bei Atmel-AVR gibt es wesentlich
Diese sind natürlich wie alle Leistungsfähigen Controller voll auf C ausgelegt. Die Compiler hier sind GCC abkömmlinge. Für den ersten Einstieg würde ich aber bei 8 Bit reinschnuppern, dann mich steigern. Vorteil bei MC ist das du mit einem einfachen Programmiergerät (PicKit3) ALLES was an Pics die letzten
-
Thread
Attiny2313 macht Probleme
kompilereinstellungen wegoptimiert werden. Können sie nicht. Die _delay_ms Routine, die mit dem GCC mitkommt, wird 100% sicher nicht wegoptimiert.
Wie schalte ich die Optimierung bei AVR Studio 4 ein?
-
Thread
neu AVRDUDE 5.11
Einen alternativen als den Default-Compiler gibt man einfach beim configure an mit: [code] env CC=gcc-mingw32 ./configure [/code] (mal in der Annahme, dass der Cross-Compiler "gcc-mingw32" heißen würde) > oder war eine komplette Umgewöhnung auf Linux gemeint? das wär ein > bischen heftig für
suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for bison... bison
-
Thread
schnelle dezimale Division auf AVR & Co.
a *= 2' in 'a <<= 1' übersetzen, je nach dem, was die jeweilige CPU besser kann - aber solche Optimierungen scheint der AVR-GCC nicht zu machen. Also bleibt für die optimale Lösung wohl wirklich nur ein paar Assembler-Routinen ... ... da werd ich mich bei Gelegenheit mal dran machen ... Gruß - Karl
selbst diese Kapriolen brauch man in neuen Compilerversionen wie gesagt nicht mehr zu machen weil avr-gcc sie beherrscht.
-
Thread
avrdude: doofes 0xFF schreiben unterdrücken? (beim Bootloader brennen)
suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for bison... bison
Punkten oder so...? (im ChangeLog und NEWS sehe ich auch leider keinen Hinweis auf die 0xFF Optimierung. ?)
-
Thread
Warum verbraucht eine Variable so viel Speicher?
; } [/c] Compiliere ich ihn nun ohne Optimierung, gibt's eine Warnung: [pre] /usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:94:3: warning: #warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as
ignoriert, ich glaube, dem ist nach menschlichem Ermessen nicht mehr zu helfen. Schalte ich die Optimierung ein, dann bekomme ich: [pre] /usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h: In function 'delay': /usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:152:28: error: __builtin_avr_delay_cycles
-
Thread
Funktionsaufruf bei Optimization -O1
rausfinden, mit > recht unschönen Folgen für Laufzeit und Speicherverbrauch. "-fwhole-program" beim gcc, mit einigen Einschränkungen
Vorkentnisse == 0 && Einarbeitungfähigkeiten == 0 Die Grundlegende Frage wird von jedem Anfänger-Optimierungs Tutorial beantwortet... eigentlich direkt von dem das man bei google zuerst findet, würde man die schlagworete der frage bei google mal eingeben. P E I N L I C H . http://lmgtfy. com/?q=gcc
-
Thread
Blinklicht zu hohe Frequenz
- Optimierung beim Compiler aktiviert? - Wie viel schneller ist denn eine "viel höhere Frequenz"?
Das Ganze gibt es hier auch auf deutsch: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29
-
Thread
Problem AM-Empfänger konstruieren
nicht gesucht. Den Tiny-Code schreibe ich dir heute abend um. Compilieren mit [pre] avr-gcc -mmcu=atmega8 -Os -g -Wall -Wextra -std=c99 -o rfm12_rx.elf rfm12_rx.c avr-objcopy -O ihex rfm12_rx.elf rfm12_rx.hex [/pre]
ASM-Code ja meinen Build-Button habe. Ich hab nun deinen Code einfach nur reinkopiert in ein neues GCC-Projekt. Und wo genau muss ich jetzt deinen Befehl eingeben? Ich hab mich eben durch die Compile-Anweisung im GCC-Tutorial gekämpft aber irgendwie bin ich noch genauso schlau wie vorher. Gruß
-
Thread
GCC: Arg unzulängliche Optimierungen?
ist doch recht schlimm. > nur mal wieder ein Beispiel für die die vielen arg unzulänglichen > Optimierungen. da braucht man doch eigentlich kein fortgeschrittene KI? avr-gcc ist ein Open-Source Compiler, du kannst mithelfen ihn zu verbessern. Wenn solche Änderungen trivial für sich sind, mach eben
anstatt nur rumzumotzen ;-) Die Funktion horcht auf den Namen lshrsi3_out und findet sich in http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr.c?content-type=text%2Fplain&view=co happy hacking
-
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
AVR-ASM: Simulierter call
@Charly B. Das ist aber mit Sicherheit nicht der gas aus den gcc-binutilities.
Insgesamt hat die Optimierung 220 Byte Programmspeicher gebracht.
-
Thread
Watchdog auf xMega deaktivieren
den Wert im WDT.CTRL-Register zú ändern. Nun kannst du zwei verschiedene Wege gehen. 1. die Optimierung vom GCC erhöhen -> lässt keine direkte Aussage zu in welcher Zeit die Zeilen abgearbeitet werden ! 2. Inline ASM -> den Assemblercode solltest du so proggen, das du die 4 CPU-CLK hast um das
-
Thread
Verschiedene Bits effizient auslesen
Die Optimierung steht bereits auf -Oo, leider mit dem selben Ergebnis. mfg
Michael K. schrieb im Beitrag #2309843: > War tatsächlich (wieder) ein Problem mit der > Optimierung. Es gibt tatsächlich weder jetzt noch wieder Probleme mit der Optimierung. Es gibt nur fehlerhaften Code, die der Optimierer dann anders versteht, als der Programmierer. > Selbst mit -O0
-
Thread
GCC Optimierung, unterschiedliche Codelänge
Mit ein und demselben Sourcecode wird je nach Controller unterschiedlich langer Binärcode generiert. AVR-Studio 4.18, Build 716, Optimierung -0s Atmega 168p 1022 Bytes Atmega 644p 1006 Bytes Anders herum wäre es das erwartete Ergebnis, da der 644 mehr Interrupts hat. Aber so? Ohne Optimierung betragen die Codelängen (168:644) 4938 : 4940 Was zwar tendenziell besser passt, aber der 644 hat 5 Interrupts mehr als der 168, sodaß die Interruptvektortabelle 20 Bytes länger ist. Warum entsteht bei im Grunde gleichen Controllern unterschiedlicher Code? Hierbei handelt es sich um einen Bootloader
-
Thread
Frage zur Projektorganisation bei defines
testproject/ports.h [/pre] Dann den Bibliotheksstamm in den Suchpfad aufnehmen (Option -I beim gcc). Dann findet die 'display.h' ihre 'ports.h', egal wo sie liegt. Und wenn dann übersetzt wird, landen die Objektmodule etwa da: [pre] /eda/projects/testproject/main.o /eda/projects/testproject/display.o
Erstmal danke für eure Antworten! Ja sorry es geht natürlich um AVR-GCC, ich habe gar nicht realisiert dass dieses Unterforum ja nur GCC heißt. Die Quelldateien mittels -I einzubinden habe ich bereits versucht. Auf diese Weise kann ich die Header auch korrekt einbinden
-
Thread
R_AVR_13_PCREL allerdings auf eigene Datei
aber macht nichts. Ich habe sie jetzt einfach mal mit -mmcu=atmega16 -std=c99 compiliert, ohne Optimierung (damit sie möglichst groß werden). Ich kann das Problem leider in keiner Weise nachvollziehen, weder mit einem ältlichen GCC 4.3.4 noch einem halbwegs aktuellen 4.5.1. Hast du dir diesen
akzeptablel ist, d.h. ist die Priorität A: Codegüte oder B: Interlinkfähigkeit zwischen verschiedenen avr-gcc Versionen. B würde bedeuten, Optimierungen wie die obige nie machen zu können/dürfen. A wird zum Problem, wenn eine Library unabhängig von avr-gcc distrubutiert wird. Hier müsste dann eine Versionierung
-
Thread
"ARM eCross EABI Toolchain für Windows und Linux" Gibt es Erfahrungen?
entwickeln auch selbst am Compiler mit. Zumindest am ARM Backend. Die GCCs enthalten also oft Optimierungen die erst später in das offizielle GCC Release aufgenommen werden. Vorschlag falls du das installieren willst: Wähle die minimale Installation, lasse die Pfade eintragen aber keine Menüeinträge
die es interessiert, es gibt auf de mbed.org Homepage eine Anleitung, wie man das mbed-Modul mit dem GCC und Eclipse nutzen kann. Hier der Link: http://mbed.org/cookbook/Using-mbed-with-gcc-and-eclipse
-
Thread
NIOS und SoftCores allgemein als DSP-Ersatz
BF561. Thema Code-Wiederverwertung ist ein Knackpunkt, aber bei vielen kein Thema mehr, die mit GCC entwickeln und ihren Code von vornherein cross-platform designen. Insofern ist die Wahl des Prozessors und der Toolchain kein grosses Thema mehr bei mir. Die Frage ist nur, ob man auch den kompletten
> Thema Code-Wiederverwertung ist ein Knackpunkt, aber bei vielen kein > Thema mehr, die mit GCC entwickeln und ihren Code von vornherein > cross-platform designen. Insofern ist die Wahl des Prozessors und der > Toolchain kein grosses Thema mehr bei mir. Die Frage ist nur, ob man > auch den
-
Thread
64/128 Bit Softcore
z.B. Krypto) hinreichend nützlich zu sein. Zumindest die 32- und 64-bittigen RISC V-Kerne werden von GCC schon unterstützt, ob das auch für 128 Bit zutrifft, weiß ich nicht. Hat natürlich dann wieder nichts mit Multicore zu tun.
Bitfeld von parallelisierten/verzögerten Opcodes ausgespuckt, ein Assembler wäre schon zu aufwendig, und GCC-RTL bekäme die 1-Zyklen-Optimierung nicht mal hin. Es läuft also immer öfter auf hybriden Ansatz raus, bei dem Pipeline, Operationsablauf und ALU wie auch zugehöriger Default-Mikrocode für den jeweiligen
-
Thread
Probleme nach dem Optimieren "-O1"
Welchen Parameter sollte ich setzen um das GCC Listing (C-Code/Assembler) sehen zu können?
sucht, der Findet... [code]-Wa,-ahlms=$(addprefix $(OBJDIR), $(<:.c=.lst))[/code] als Parameter dem GCC mit übergeben, dann macht der die Datei. Ich muss erst noch testen, dass ich das Problem von damals wieder "reinprogrammiere".
-
Thread
[AVR] USART mit Interrupt (STK500/ATmega8515)
Hallo Hansi, Hab gerade einfach mal die Optimierung auf -O0 gestellt (vorher -Os), dann sollte das ja eigentlich nicht passieren. Aber leider kein Erfolg. - Leider gibt es auch massenweise Tutorials die ähnlichen Code präsentieren. Bin noch relativ
alten makefile war unter der Linker-section diese Zeile zu finden: [code] $(QUOTE)$(AVR_APP_PATH)avr-gcc.exe$(QUOTE) -mmcu=atmega8515 -o$(OUTPUT_FILE_PATH_AS_ARGS) $(OBJS_AS_ARGS) $(USER_OBJS) $(LIBS) [/code] im neuen sah diese zeile dann so aus: [code] $(QUOTE)$(AVR_APP_PATH)avr-gcc.exe$(QUOTE)
-
Thread
MCURSES - Mini Curses Bibliothek für Mikrocontroller
sich in der Prozedur smed(). Das derzeitige Rahmenprogramm ist für eine Linux-Plattform (bzw. mehr gcc und dessen Filesystem-Zugriffsroutinen aus der stdio.h) geschrieben. Ich habe versucht, die plattformspezifischen Dinge in entsprechenden Funktionen zu "kapseln". Folgende Funktionen/Prozeduren wären
nach "Real-Time" Er hat auch einige Datentypen auf "uint_fast8_t" umgestellt. Diese Art der Optimierung ist mir noch recht fremd. Der Typ von Wuhanstudio scheint ziemlich professionel zu sein. Er mach viel mit FPGAs: https://github.com/wuhanstudio
-
Thread
Verständnisfrage ==
if( *p ) f( p ); } [/C] Wenn du nicht glaubst, dass sei eine Schleife, dass zieh es mal durch GCC.
Es bleibt eine Rekursion, auch wenn es einen Compiler gibt, der das im Zuge seiner Optimierung durch eine Schleife ersetzt.
-
Thread
PGM_P Verwirrung
__attribute__((progmem)) in typedef wird nicht unterstützt in avr-gcc, es ist ein *nicht-dokumentiertes* Feature. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342#c9 http://savannah.nongnu.org/bugs/?33716 Am besten verzichtest du auf das ganze prog_char, prog_void
PROMEM wie es im Compiler dokumentiert ist -- nämlich nur für Variablen im static Storage. http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attributes
-
Thread
#define mitten im code
Gähn. Na dann erzähl doch mal, mit was für Compilern du so arbeitest. MSC und gcc können es ja wohl kaum sein, die sind schon lange nicht mehr so dämlich.
#2275184: >> Oder die oft verwendete Definiton von pi:#define PI (4 *atan(1)) > pi wird z.B. beim gcc als zahl definiert... Beim gcc wird pi gar nicht definiert. Höchstens die von dir verwendete libc tut das, und wenn sie es in math.h tut, ist das auch noch ein Verstoß gegen die ISO-Norm. >> oder
-
Thread
Objektorientierung mit avr gcc
letzte Mal (genau wegen dieser Thematik) in den gcc-Eingeweiden rumgewühlt hab, hab ich da nichts gefunden. >> Da braucht man avr-g++ (oder "avr-gcc -X c++"). > > avr-gcc -x c++ Richtig. War ein Tippfehler.
Hardware-Treiber als Template Argument übergeben. Das Beispiel oben verlinkte Beispiel erzeugt mit einem avr-gcc 4.3.4 und aktivierten Optimierungen insgesamt 1610 Byte. Es ist allerdings schon die Luxus Variante mit Stream Operatoren zur Ausgabe von belieben Zahlen, virtuellen Funktionen usw. Um den Ansatz
-
Thread
Yet another CRC32 Code
Gießkanne Inline-Assembler Hacks verteilen, oder das Übel an der Wurzel > packen. Inzwischen verfügt GCC über die entsprechende Optimierung, die übrigens Änderungen an ganzen 4 Codezeilen erforderte. Den Code von http://www.mikrocontroller.net/topic/225796?reply_to=2560350#2557218 übersetzt avr-gcc
Die Optimierung ging upstream als SVN 184509 von 2012-02-23 GCC-Version ist 4.7.0 (experimental) Über den Atmel-Fork kann ich nichts sage; da musst du Atmel fragen.
-
Thread
AVR-GCC seit 2007 verschlechtert (Speicherbedarf)
Operatoren verhunzen) Auf den ersten Blick sehe ich auch sonst keine besonderen Verbesserungen in der Optimierung im .s File. Frage: Was ist der Hauptgrund warum der neue AVR-GCC scheinbar ohne Gegenleistung soviel mehr Speicher statt weniger frißt? Was kann man tu Per anschauen des generierten Assembler-Code
Feinheiten (Compiler-Schalter und Codeorganisation) dazu http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Optimierung_der_Gr.C3.B6.C3.9Fe http://www.mikrocontroller.net/topic/66690 das meiste wie hier hatte ich schon selbstverständlich gemacht. Der Autor kam aber auch schon damals (
-
Thread
AVR Studio 5/Debug: No Source Available
Andreas H. schrieb im Beitrag #2272628: > Dein Source Code wurde wahrscheinlich vom gcc wegoptimiert. Setz mal > optimization level auf none ... Zumindest ein main() sollte aber auch bei aggressivster Optimierung immer übrigbleiben. Thomas Burns schrieb im Beitrag #2268128: > Was
Andreas H. schrieb im Beitrag #2272628: > Dein Source Code wurde wahrscheinlich vom gcc wegoptimiert. Nö, der Compiler optimiert kein Sourcecode. Die Quellen tastet der Compiler nicht an. Falls Optimierung eingestellt ist, einen Debugger verwenden, der Debug-Format wie DWARF 4 für
-
Thread
AVR-GCC Inline-Assembler: const Pointer / Arrays etc. als Operanden
http://www.rn-wissen.de/index.php/Inline-Assembler_in_avr-gcc
kannst du natürlich genauso machen. > Das möchte ich gern in Inline-Assembler übernehmen Um was GCC-generiertes in Inline-Assembler zu übernehmen, ist ein Disassembly ne schlechte Vorlage. Besser ist, die Compiler-Ausgabe selbst zu verwenden, evtl. nach Hand-Optimierung.
-
Thread
Disassembly, mapfile, PROGMEM
eine Variable jetzt nur im RAM oder auch im ROM > liegt? http://www.rn-wissen.de/index.php/Avr-gcc/Interna#Sections
sich über die verwendeten (oder nicht-verwendeten) Schalter im Klaren ist. Es ist auch keine Optimierungs-Option, sondern beeinflusst die Datenablage.
-
Thread
strings aus dem programmspeicher von AVRs lesen
abgewöhnen; wird in zukünftigen avr-lic-Versionen wahrscheinlich deprecated. Einfach deshalb, weil avr-gcc das nicht unterstützt.
als WON'T FIX geschlossen. Erstens gibt es quasi keine avr-gcc Entwickler und die Resourcen sind sinnvoller in /wirklichen/ Bugs, Optimierungen oder neuen Features wie Built-Ins investiert anstatt ein was zu implementieren, das undokumentiert ist, lediglich
-
Thread
SOUNDRX - Datenübertragung/Bootloader PC -> µC über PC-Soundkarte
unbedingt merken. Ich werde das mal hier hinzufügen: http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung
Neue Version 1.4.0 ist online. Änderungen: - Optimierung der Schaltung: Pullup-Widerstand am Transistor wegoptimiert, übernimmt nun der ATmega. - Optimierung des Bootloaders: Der Bootloader wurde von der Größe her auf unter 1KB reduziert
-
Thread
externe Konstante im Flash
(&K_AdresseZusatz); [/c] Hätt' ich auch selber drauf kommen können. Naja, taste mich noch ran an GCC.
beeinträchtigt wird. Jetzt ist bei AVR aber die native Wortgröße kleiner als int, und da dieser Fall in GCC eine Ausnahme darstellt, sind solche Optimierungen da nicht so umfassend.
-
Thread
Wurzelfunktion für 16bit Fixed Point Werte
erwischt habe. 50 Ticks für ne 16-bit signed-Multiplikation ist immer nocht stolz. Du hast Optimierung aktiviert? > Johann L. schrieb im Beitrag #2256412: >> Ich hab nicht auf's Interface geschaut, ist das avr-gcc ABI? >> Wär sinnvoll... > > Als Neuling kann ich damit auch net so viel anfangen
Beitrag #2257503: > 50 Ticks für ne 16-bit signed-Multiplikation ist immer nocht stolz. Du > hast Optimierung aktiviert? Nein Optimierung ist nicht aktiv. Die Multiplikation ist allerdings auch eine Assembler Routine (32bit = 16bit*16bit). Die Zeit zum Aufrufen (Registerzuweisungsgeplänkel von gcc) ist
-
Thread
Floatingpoint Berechnung DSP vs. ARM CM3
Laufzeitfunktionen ab. Die kann man in Assembler effizient handoptimieren - oder beispielsweise beim GCC auch als generischen C Code erhalten, wenn sich niemand dafür fand.
der richtigen Compiler-Option bzw. Library zu fassen kriegt. Das beispielsweise kann einem beim avr-gcc blühen.
-
Thread
Wert an Variable per Referenz übergeben
Ein paar Richtlinien zu avr-gcc: http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung
Funktion in einen Pointer zu laden und über diesen Pointer zuzugreifen. Ein globaler Pointer als "Optimierung" für Zugriff auf die immer gleiche bekannte Variable ist wohl immer Unfug.
-
Thread
[ARM7, IAR] Codeerzeugung unsigned short -> short
für die Sign extension b) wenn er sie eh verwirft, warum macht er sie dann? Der Code ist mit Optimierung auf High -> "speed" und jeglichen Optimierungen aktiviert entstanden. Ein weiterer Punkt: Viele static void Funktionen, welche 2-3 Mal in der Datei vorkommen und selbst nur 2-3 Instruktionen enthalten, werden nicht geinlined sondern über 2 branches (bl, bx) angesprungen. Was soll das? Vom GCC bin ich da inlining gewöhnt und programmiere deswegen auch auf dem µC sehr modular - solange es nur ein Einzeiler ist, der nicht allzuoft verwendet wird und in der gleichen Datei vorkommt erwarte ich
-
Thread
GCC - Division durch 1024 o. ä.
Hallo Gruppe Hab mal ne Frage. Kriegt der GCC Compiler aus dem AVR Studio (oder auch ganz allgemein) es eigentlich mit, wen man durch zB 1024 dividieren möchte ? Ich meine löst er das Problem dann selbstständig durch BitSchieben, wenn es mu glatte 2er Potenzen geht, oder würde er das "zu Fuß" rechnen ? Gibt es eine Prüfung / Optimierung, die solche Fälle abfängt ? Grüße Torsten
-
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
MMC/SD/SDHC card library von R.Riegel "verkleinern"
Die Lib ist denke ich vielen hier bekannt. Hast Du die Optimierung eingeschaltet?
Jetzt komm ich mir blöd vor... welche Optimierung meinst du?
-
Thread
Inline-Assembler: Label-Sprungadresse in Z-Register laden - wie?
Oliver schrieb im Beitrag #2246191: > Inline-Assembler im gcc ist nunmal Krampf, und ist > für mehr als drei zeilen ungeeignet. Anders: inline-Assembler im GCC ist genial und unwahrscheinlich gut mit dem Compiler integrierbar, aber das hat seinen Preis.
Und: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Assembler-Dateien http://www.rn-wissen.de/index.php/Avr-gcc/Interna#Registerverwendung Vorteil der extra Datei: Man kann sie auch simulieren!
-
Thread
GCC kompiliert falsch?
? Wie hast du das festgestellt? Der Anzeige eines Debuggers darfst du bei eingeschalteter Optimierung nicht mehr alles glauben.
Das ist die Kompiler-Zeile: [code] arm-none-eabi-gcc -c -mcpu=cortex-m3 -O0 -gdwarf-2 -mthumb -funsigned-char -fomit-frame-pointer -fno-inline -Wall -fverbose-asm -MD -MP -MF .dep/FW_Update_USB.o.d -I . -I\WinARM\yagarto\arm-none-eabi\include -I./lib
-
Thread
Structs in eeprom minimalcode durchschauen
Dann wirds Zeit das AVR-GCC-Tutorial zumindest überaschlagsmässig mal zu durchforsten.
Bei 10 Einträgen lohnt es nicht, sich da einen Kopf wegen Optimierungen zu machen. Im Allgemeinen: ja, die gibt es. (*) Wie suchst du denn in einem Telefonbuch nach "Meyer"? Du schlägst es in der Mitte auf und liest Huber. Meyer kommt alphabetich nach Huber,
-
Thread
Fehlermeldungen im AVR Studio
Die "register" Anweisung stammt aus grauer Vorzeit in der die Compiler noch (fast) keine Code-Optimierung beherrschten, Du kann diese Anweisung getrost weglassen, die heutigen Compiler erledigen die Code-Optimierung für Dich! ...und hier noch etwas weiterführende Literatur: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial Gruß Markus