www.mikrocontroller.net

Forum: Compiler & IDEs AVRStudio ärgert


Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ein Projekt, das fehlerfrei compiliert wird mit GCC
bei Aufruf "Make all" im Commandfenster. So weit so gut.

Das AVR-Studio macht sich das Makefile ja selber.
Also habe ich nur die C-Dateien und die Includes
in das Studio kopiert und dann Rebuild All geklickt.

Einige Dateien compiliert das Studio durch Aufruf von avr-gcc
einwandfrei. Bis zu diesem Fehler.

../main.c:1087: error: 'UCSRA' undeclared (first use in this function)

In den Datei main.c stehen jedoch diese Includes drin:
#include <stdint.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <avr/sleep.h>
#include <avr/wdt.h>
#include <avr/version.h>

Warum gibts dann den Fehler, wenn der GCC doch im
Commandfenster aufgerufen fehlerfrei arbeitet. Was ist
im Studio anders?

In der path-Variable steht der Pfad auf das WinAVR-
Verzeichnis drin mit \bin und \utils\bin. Einen
direkten Link auf
C:\WinAVR-20100110\avr\include sehe ich nicht.

Offenbar kommt "Make all" im CMD-Fenster damit trotzdem klar.

Warum klemmt es beim Studio. Was kann/muss ich da tun?

Matthias

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falschen Controller ausgewählt?
Nicht alle AVR haben die gleichen Register.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Falschen Controller ausgewählt?
> Nicht alle AVR haben die gleichen Register.

Im Studio habe ich fürs Debugging den 169 eingestellt.
Beim Aufruf des GCC wird mit -mmcu=ATmega169P gearbeitet.
Daran liegt es also wohl nicht.

Matthias

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias W. schrieb:
> Im Studio habe ich fürs Debugging den 169 eingestellt.
> Beim Aufruf des GCC wird mit -mmcu=ATmega169P gearbeitet.
> Daran liegt es also wohl nicht.

ATmega169 != ATmega169P. Bei ersterem gibt es UCSRA, bei zweiterem 
heisst es UCSR0A.

Andreas

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Außerdem: welchen Controller du für das Debuggen eingestellt hast, 
interessiert beim Compilieren nicht die Bohne. Und da du einen Fehler 
beim Compilieren bekommst, wäre es natürlich sinnvoll, den dort 
eingestellten Controller zu kontrollieren.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:
> ATmega169 != ATmega169P. Bei ersterem gibt es UCSRA, bei zweiterem
> heisst es UCSR0A.

Danke für den Hinweis Andreas.

Auf dem chip selbst steht mega169V kein P.
Der Aufruf des GCC im Cmd-Fenster mit Make all
ruft in der Tat den ATmega169 auf, während das
Studio laut den Zeilen definitiv den mega169P aufgerufen hat.
Das habe ich nun geändert.

Die Probleme sind erst verschwunden als ich
4 C-Dateien entfernt habe, die ich ins Studio
einkopiert hatte und somit auch dort übersetzt
wurden. Das Makefile hatte diese jedoch ausgelassen.

Über solche Feinheiten kann man also auch stolpern.

Das Problem was jetzt noch drückt ist die Codegröße.

Der normale Code des 169 ist laut Makefile so groß:
main.elf  :
section            size      addr
.data                56   8388864
.text             13278         0
.bss                357   8388920
.debug_aranges      544         0
.debug_pubnames    4381         0
.debug_info       16600         0
.debug_abbrev      4941         0
.debug_line       16903         0
.debug_frame       2736         0
.debug_str         4257         0
.debug_loc         9646         0
.debug_ranges        96         0
Total             73795

Das Studio meldet:
AVR Memory Usage
----------------
Device: atmega169
Program:   13216 bytes (80.7% Full)
(.text + .data + .bootloader)

Data:        227 bytes (22.2% Full)
(.data + .bss + .noinit)

Build succeeded with 0 Warnings...

Der Code des Datenloggers hat laut Studio:
AVR Memory Usage
----------------
Device: atmega169
Program:   18584 bytes (113.4% Full)
(.text + .data + .bootloader)

Data:        694 bytes (67.8% Full)
(.data + .bss + .noinit)

Build succeeded with 1 Warnings...

Wie soll das denn reinpassen mit 113% full?

Matthias

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Ernst schrieb:
> Außerdem: welchen Controller du für das Debuggen eingestellt hast,
> interessiert beim Compilieren nicht die Bohne. Und da du einen Fehler
> beim Compilieren bekommst, wäre es natürlich sinnvoll, den dort
> eingestellten Controller zu kontrollieren.

Beim Studio habe ich nur die c- und h-Dateien einkopiert
und dabei ja gar keine CPU angegeben. Beim Erstellen der
Projektdatei fragt das Studio ja nach einer CPU.
Wo überall stellt man die CPU im Studio denn ein?

Bei Project configuration options habe ich die CPU
geändert.

Matthias

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wieso klappt das mit dem einfachen Makefile und
bisher gar nicht mit dem Studio (zu groß)?

Matthias

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entweder hast du im Studio mehr Dateien, oder andere Optionen beim 
Kompilieren oder andere Libs beim Linken (Gleitkommaversionen?).

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Entweder hast du im Studio mehr Dateien, oder andere Optionen beim
> Kompilieren oder andere Libs beim Linken (Gleitkommaversionen?).

Da hast Du wohl recht.
Da es an den Dateien nun sicher nicht mehr liegt
können es nur die libs sein.

Leider kenne ich die Möglichkeiten des Studios
nicht so gut um da bewusst geschickt eingreifen
zu können. Es sieht so aus als ob das Makefile
außerhalb des Studios, das ja den kleineren
Code erzeugt ein -lm verwendet. Dies ist beim
Studio nicht der Fall.

Darauf muss man wohl achten, wenn man weiß wie
man es sinnvollerweise tut. Leider kenne ich mich
damit bisher nicht aus. So einfach ist das mit dem
Studio eben auch nicht.

Matthias

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias W. schrieb:

> damit bisher nicht aus. So einfach ist das mit dem
> Studio eben auch nicht.

Ganz im Gegenteil
Alle Möglichkeiten finden sich im Studio zusammengefasst im
Menüpunkt "Project" / "Configuration Options"

Dort wird im Grunde alles eingestellt, was das implizite Makefile (und 
nich einiges mehr) beeinflusst.

Dort gibt es dann in der linken Leiste den Punkt 'Libraries' und unter 
'Available Link Objects' die libm.a

Mit seinem Werkzeug muss man sich eben ein wenig beschäftigen, wenn man 
es sinnvoll einsetzen will. Und das AVR Studio ist dein Werkzeug

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Alle Möglichkeiten finden sich im Studio zusammengefasst im
> Menüpunkt "Project" / "Configuration Options"

danke für den Hinweis. In dem Menü war ich schon ein paar Mal.

> Dort wird im Grunde alles eingestellt, was das implizite Makefile (und
> nich einiges mehr) beeinflusst.

muss da auch im Fenster der Takt angegeben werden?
In der main.h steht ja #define F_CPU 4000000
Das wäre ja dann doppelt angegeben.

> Dort gibt es dann in der linken Leiste den Punkt 'Libraries' und unter
> 'Available Link Objects' die libm.a

Die libm.a mit Add Library nach rechts schieben?

> Mit seinem Werkzeug muss man sich eben ein wenig beschäftigen, wenn man
> es sinnvoll einsetzen will. Und das AVR Studio ist dein Werkzeug

ich arbeite mich ein. Das dauert seine Zeit, weil vieles
für mich Neuland ist. Hinweise und Tutorials sind hilfreich !

Matthias

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst übrigens auch dein eigenes Makefile verwenden lassen, dann
bist du den Kuddelmuddel los.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Du kannst übrigens auch dein eigenes Makefile verwenden lassen, dann
> bist du den Kuddelmuddel los.

Danke für den Hinweis Jörg. Das wird momentan das Beste sein,
denn es gelingt mir zwar nun mit dem Studio etwas zu erzeugen
was angeblich reinpasst (ca. 97% voll). Beim Flashen über den
Bootloader meldet dann jedoch der Verify einen Fehler.

Das mit "Make all" außerhalb des Studios generierte
hex-file arbeitet hingegen einwandfrei.

Meine Anstrengungen sind bisher gescheitert das was das
externe Makefile macht im Studio auch hinzubekommen.

Schade - es war ein Versuch das auch im Studio zum Laufen
zu bringen.

Matthias

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias W. schrieb:
> (ca. 97% voll). Beim Flashen über den
> Bootloader meldet dann jedoch der Verify einen Fehler.

Klar, das avr-size-Kommando, das die 97 % vermeldet, hat natürlich
keine Ahnung, dass du auch noch Platz für einen Bootloader brauchst.

> Schade - es war ein Versuch das auch im Studio zum Laufen
> zu bringen.

Darüber musst du wohl nicht traurig sein. ;-)  Die AVR-Studio-
Variante ist nur ein simpler Ersatz für Standardanwendungen, der
für Leute sinnvoll ist, die nicht selbst ein Makefile schreiben
können oder wollen.  Trifft für dich also nicht zu. :)

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Klar, das avr-size-Kommando, das die 97 % vermeldet, hat natürlich
> keine Ahnung, dass du auch noch Platz für einen Bootloader brauchst.

da bin ich mir nicht so sicher Jörg.
Denn die Ausgabe beim Studio sagt ja:
(.text + .data + .bootloader). Da scheint
also die Größe des Bootloaders durchaus berücksichtigt.

> Darüber musst du wohl nicht traurig sein. ;-)

Ich dachte nicht, daß dies so stressig sein könnte.
Das Studio ist zwar überaus wertvoll,
was den Simulator und Debugger angeht und die
Programmierung über den Bootloader. Die Suchmöglichkeiten
des Editors empfinde ich als stark suboptimal.

Da nehme ich lieber den uralten Ultraedit und
dazu das Make im DOS-Fenster. Das läuft wenigstens
ohne Mucken, so wie vor Jahren schon.

> für Leute sinnvoll, die nicht selbst ein Makefile schreiben
> können oder wollen.  Trifft für dich also nicht zu. :)

So sehr fit bin ich leider nicht im Schreiben
von Makefiles. Mein Wissen darum reicht gerade
mal soweit, daß ich das Muster-Make anpassen
kann, wenn eine Datei wegfällt oder eine neue hinzukommt.
Die Sprache des Make sieht nicht einfach aus.
Auch Leerzeichen statt Tabs kann unerwartet stressen.

Matthias

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias W. schrieb:

> Da scheint
> also die Größe des Bootloaders durchaus berücksichtigt.

War aber nirgends eine section mit dem Namen .bootloader zu
sehen.  Würde außerdem nur funktionieren, wenn du den Bootlader
mit dem Projekt mit linkst und dann alles zusammen flashst.  So,
wie ich dich verstanden habe, war der Bootlader aber schon da
und gehört(e) nicht zum Projekt.

> Die Suchmöglichkeiten
> des Editors empfinde ich als stark suboptimal.

Ich finde all diese IDEs ohnehin stark suboptimal, schon deshalb,
weil man diese mit dem "Fenster im Fenster" nur mit Bildschirmen
ab 1 m² Bildschirmfläche aufwärts benutzen kann ;-), aber ich muss
ja zum Glück auch nicht mit sowas arbeiten.  Ohne Emacs oder zur
Not vi möchte ich auf Dauer auch nicht arbeiten müssen...

> Auch Leerzeichen statt Tabs kann unerwartet stressen.

Ja, das war wohl eine der größten Fehlentscheidungen von "make".  Ist
nun mal leider so und nicht mehr zu ändern.  Hat ja Python auch nicht
davon abgehalten, dann 30 Jahre später nochmal eine Sprache zu
erfinden, in der Leerzeichen (bzw. TABs) syntaktische Signifikanz
besitzen. :-/

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias W. schrieb:
> Jörg Wunsch schrieb:
>> Klar, das avr-size-Kommando, das die 97 % vermeldet, hat natürlich
>> keine Ahnung, dass du auch noch Platz für einen Bootloader brauchst.
>
> da bin ich mir nicht so sicher Jörg.
> Denn die Ausgabe beim Studio sagt ja:
> (.text + .data + .bootloader). Da scheint
> also die Größe des Bootloaders durchaus berücksichtigt.

Überlegen, Nachdenken

Woher soll denn AVR Studio wissen, dass du einen Bootloader auf dem Chip 
hast und ich nicht.

Was bei dir also als 105% Flash Verbrauch angezeigt werden sollte 
(deiner Meinung nach), sind bei mir daher nur 94%

> So sehr fit bin ich leider nicht im Schreiben
> von Makefiles.

Um dir rauszusuchen, welche Compiler Optionen eingschaltet sind, wirds 
ja doch noch reichen.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
>> die Ausgabe beim Studio sagt ja:
>> (.text + .data + .bootloader)
> Woher soll denn AVR Studio wissen, dass du einen Bootloader auf dem Chip
> hast und ich nicht.

gute Frage. Ich habe das Studio nicht geschrieben.
Da ich ein paar Mal über den Bootloader programmiert
habe könnte das Studio das schon wissen.

Vermutlich wird es nicht so sein, weil ja
der Build auch ohne das Aktivieren des Bootloaders
diese Meldung wohl erzeugen wird.

In jedem Fall verwirrt mich diese Meldung.
Das Make außerhalb des Studios gibt das so
in dieser Art (.text + .data + .bootloader) nicht an.

Mich hat diese Ausgabe eher verwirrt als Nutzen gebracht.

> Was bei dir also als 105% Flash Verbrauch angezeigt werden sollte
> (deiner Meinung nach), sind bei mir daher nur 94%

Dieser Satz klingt für mich falsch. Denn bei mir wird
97.9% full angezeigt, bei Dir wären das dann 10% weniger
also rund 87% und die müssten doch sicher reinpassen.

Fakt ist, daß das "Makefile" außerhalb des Studios
ca 13kB produziert mit dem GCC. Dieses hex läuft !

Das "Make" des Studios produziert angeblich 16036byte
(.text + .data + .bootloader) 97.9% full.

Für mich klang das so: passt rein - alles prima.

Daß man da was erkennen kann an einer nicht vorhandenen
Section mit dem Namen .bootloader - sorry, das habe ich
nicht gesehen. Mein Dank geht hier an Jörg, der darauf
aufmerksam gemacht hat.

Also müsste dem Studio noch mitgeteilt werden, daß es
einen Bootloader gibt? Wo stelle ich das ein?

> Um dir rauszusuchen, welche Compiler Optionen eingschaltet sind, wirds
> ja doch noch reichen.

Bitte klarer. Welchen konkreten Hinweis willst Du
hier geben. Soll ich die Compilerschalter alle mal
vergleichen? Bei Studio und Makefile? Ist es das was
Du sagen möchtest?

Matthias

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias W. schrieb:

> Fakt ist, daß das "Makefile" außerhalb des Studios
> ca 13kB produziert mit dem GCC. Dieses hex läuft !

Die Größe des HEX-Files ist nur eingeschränmkt als Mass zu gebrauchen.

> Das "Make" des Studios produziert angeblich 16036byte
> (.text + .data + .bootloader) 97.9% full.
>
> Für mich klang das so: passt rein - alles prima.

Aber nur dann, wenn du keinen Bootloader im Chip hast

> Also müsste dem Studio noch mitgeteilt werden, daß es
> einen Bootloader gibt? Wo stelle ich das ein?

Nirgends.
Das musst du schon selber wissen, welchen Bootloader du in den Chip 
gebrannt hast, wieviel Platz der im µC belegt und wieviel du daher vom 
Gesamtspeicher abziehen musst.

>> Um dir rauszusuchen, welche Compiler Optionen eingschaltet sind, wirds
>> ja doch noch reichen.
>
> Bitte klarer. Welchen konkreten Hinweis willst Du
> hier geben. Soll ich die Compilerschalter alle mal
> vergleichen? Bei Studio und Makefile? Ist es das was
> Du sagen möchtest?

Genau das möchte ich damit sagen.
Im Makefile sieht man sich an, welche Compiler Optionen eingeschaltet 
sind und im AVR-Studio sieht man sich einfach mal im Output Fenster an, 
mit welchen Compiler Optionen der gcc dort aufgerufen wird.
Dann vergleicht man, stellt fest welche Unterschiede es gibt, liest nach 
was es mit diesen Optionen beim gcc auf sich hat, entscheidet ob man die 
beibehalten will (bzw. ob man sich davon etwas verspricht) und sucht 
sich dann im AVR Studio einen Weg diese Option dort ebenfalls 
einzustellen. Wenn alle Stricke reissen, gibt es im AVR Studio immer 
noch den Weg, die Compiler-Optionen auch dort direkt einzugeben.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> War aber nirgends eine section mit dem Namen .bootloader zu
> sehen.

Danke für den wertvollen Hinweis.
Stimmt, da steht nicht von einem Bootloader.
Der Bootloader wurde ja von Atmel draufgemacht.
Das Projekt selbst löscht den Bootloader nicht
und macht auch keinen eigenen drauf.

> Würde außerdem nur funktionieren, wenn du den Bootlader
> mit dem Projekt mit linkst und dann alles zusammen flashst.

Dann müsste die Größenberechnung auch stimmen.
Heute wird die Auslastung zu klein angegeben,
weil der Bootloader ja noch da ist. Vermutlich
versucht das Tool den zu überschreiben - daher
der Fehler mit dem Verify, der nicht klappt?

> So, wie ich dich verstanden habe, war der Bootlader aber schon da
> und gehört(e) nicht zum Projekt.

Ja.

> Ich finde all diese IDEs ohnehin stark suboptimal, schon deshalb,
> weil man diese mit dem "Fenster im Fenster" nur mit Bildschirmen
> ab 1 m² Bildschirmfläche aufwärts benutzen kann ;-),

mit einem Laptop mit 1680x1050pixel geht es schon.
Das ist ok. Die vielen möglichen Fehlerquellen da und dort in
einem Menü stören mich bisher viel mehr.

> Ohne Emacs oder zur
> Not vi möchte ich auf Dauer auch nicht arbeiten müssen...

das verstehe ich.

>> Auch Leerzeichen statt Tabs kann unerwartet stressen.
> Ja, das war wohl eine der größten Fehlentscheidungen von "make".  Ist
> nun mal leider so und nicht mehr zu ändern.

schade.

> Hat ja Python auch nicht
> davon abgehalten, dann 30 Jahre später nochmal eine Sprache zu
> erfinden, in der Leerzeichen (bzw. TABs) syntaktische Signifikanz
> besitzen. :-/

Es ist ziemlich ärgerlich wenn man beim Editor
die Tabs alle durch Leerzeichen ersetzen lässt
und dann plötzlich nichts mehr korrekt durchläuft.

Wer rechnet schon mit sowas . . .

Matthias

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

Danke für die Hinweise Karl Heinz !

Den Bootloader hat Atmel drauf gemacht, nicht ich.
Ich hörte daß er um die 2kB haben soll.

Matthias

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias W. schrieb:
> Der Bootloader wurde ja von Atmel draufgemacht.

Das alles weiß dein AVR Studio aber nicht.

Die Angabe der Auslastung stammt von einem avr-size-Kommando,
und das geht einfach stur von der Flash-Größe des jeweiligen
Prozessors aus.  Selbst die Kenntnis, dass es einen Bootloader
gibt, würde ihm ja nichts nützen, denn in den meisten AVRs kann
man für diesen vier verschiedene Größen einstellen.

Das Resultat vom AVR-Studio-Compilat war vermutlich einfach mal
deshalb zu groß, weil sie standardmäßig ohne Optimierung
compilieren.  Optimierten Code zu debuggen, ist mit AVR Studio ein
ziemlicher Graus -- mit GDB nur deshalb marginal besser, weil er
beliebige C-Ausdrücke zur Laufzeit berechnen kann, sodass man
bspw. auch zwei aufeinanderfolgende Register zu einem Zeiger eines
bestimmten Typs umbiegen kann, der auf eine Struktur zeigt, dessen
x-tes Element man dann haben will usw. usf.

Kurz gesagt, viele Leute kriegen's nicht auf die Reihe, sich wirklich
durch den optimierten Code zu hangeln und debuggen stattdessen den
nichtoptimierten Code.  Viele der "Kasperfallen" der Sprache C kommen
aber erst durch die Optimierung rein (bspw. alles, was sich um
"volatile" herum rankt), sodass man mit dieser Methode letztlich
zweimal debuggt.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Das alles weiß dein AVR Studio aber nicht.

sieht so aus.

> Die Angabe der Auslastung stammt von einem avr-size-Kommando,
> und das geht einfach stur von der Flash-Größe des jeweiligen
> Prozessors aus.

das ist mir nun klar. Verwirrt hatte mich diese
Zeile mit der Summe incl. Bootloader. Da dachte
ich ernsthaft, daß das die Software so ausgerechnet hat.
Mich hat diese Zeile wirklich in Sicherheit gewiegt.

> Das Resultat vom AVR-Studio-Compilat war vermutlich einfach mal
> deshalb zu groß, weil sie standardmäßig ohne Optimierung
> compilieren.

Als De-Optimierbefehl steht im Studio -Os drin.
disables the following optimization flags:
          -falign-functions  -falign-jumps  -falign-loops
          -falign-labels  -freorder-blocks 
-freorder-blocks-and-partition
          -fprefetch-loop-arrays  -ftree-vect-loop-version

> Optimierten Code zu debuggen, ist mit AVR Studio ein
> ziemlicher Graus

vielen Dank für den Einblick. Ist ja klar, daß es da
schwerer wird mit dem Debuggen, wenn Teile gar nicht
mehr da sind.

> Kurz gesagt, viele Leute kriegen's nicht auf die Reihe, sich wirklich
> durch den optimierten Code zu hangeln und debuggen stattdessen den
> nichtoptimierten Code.

verständlich.

> Viele der "Kasperfallen" der Sprache C kommen
> aber erst durch die Optimierung rein (bspw. alles, was sich um
> "volatile" herum rankt), sodass man mit dieser Methode letztlich
> zweimal debuggt.

das klingt nicht so optimal.
Wenn Optimierung auf solche Weise dann zu Ausfällen
von Sicherheitssystemen führt ist es weniger komisch.

Matthias

Autor: Klaus Wachtler (mfgkw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
>> Auch Leerzeichen statt Tabs kann unerwartet stressen.
>
> Ja, das war wohl eine der größten Fehlentscheidungen von "make".  Ist
> nun mal leider so und nicht mehr zu ändern.

alles eine Frage des richtigen Editors :-)

Mit etwas Glück sehen Leerzeichen anders aus als Tabs, und wenn white 
space nach dem letzten sichtbaren Zeichen einer Zeile eine andere Farbe 
hat, spart man sich auch viel Fehlersucherei in C bei einem Makro mit 
Fortsetzungszeilen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welcher Mode ist das, wenn man fragen darf?  (show-trailing-whitespace
habe ich schon lange aktiv.)

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> alles eine Frage des richtigen Editors :-)

Danke für den wertvollen Beitrag Klaus.

Matthias

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Welcher Mode ist das, wenn man fragen darf?  (show-trailing-whitespace
> habe ich schon lange aktiv.)

In meiner .emacs steht dazu (offenbar auch nur geklaut, von einem der es 
geklaut hat):
(custom-set-faces
  ;; custom-set-faces was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
 '(my-tab-face ((((class color)) (:background "Khaki"))) t)
 '(my-trailing-space-face ((((class color)) (:background "Gold"))) t))

;;; Editor behavior: color tabs

(add-hook 'font-lock-mode-hook
          (function
           (lambda ()
             (setq font-lock-keywords
                   (append font-lock-keywords
                           '(("\t+" (0 'my-tab-face t))
                             ("[ \t]+$" (0 'my-trailing-space-face t))))))))



;;; From: Tom Schutter <t.schutter@att.net>
;;; To: Jason Diamond <jason@injektilo.org>
;;; Cc: help-emacs-windows@gnu.org
;;; Subject: Re: [h-e-w] View Whitespace
;;;
;;; Jason Diamond wrote:
;;; >
;;; > Hi.
;;; >
;;; > Is there a Lisp function that toggles whether or not whitespace (horizontal
;;; > tabs, line feeds, carriage returns, and spaces) are "visible"?
;;; >
;;; > Thanks,
;;; > Jason.
;;;
;;; I don't know where I got this from, but it does tabs and trailing
;;; spaces.
;;;
;;; ;;; Editor behavior: color tabs
;;; (custom-set-faces
;;;  '(my-tab-face            ((((class color)) (:background "Khaki"))) t)
;;;  '(my-trailing-space-face ((((class color)) (:background "Gold"))) t))
;;; (add-hook 'font-lock-mode-hook
;;;           (function
;;;            (lambda ()
;;;              (setq font-lock-keywords
;;;                    (append font-lock-keywords
;;;                            '(("\t+" (0 'my-tab-face t))
;;;                              ("[ \t]+$" (0 'my-trailing-space-face
;;; t))))))))
;;;
;;; --
;;; Tom Schutter
;;; t.schutter@att.net
;;;

Matthias W. schrieb:
> Danke für den wertvollen Beitrag Klaus.

Biite! Freut mich, wenn es dir hilft. :-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, jetzt hab' ich's auch geklaut. ;-)

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Biite! Freut mich, wenn es dir hilft. :-)

Wie Du siehst hilfts auch anderen.
So haben mehr was davon. Das ist ja der Sinn solcher Threads !

Matthias

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Danke, jetzt hab' ich's auch geklaut. ;-)

Ich habe für sowas einen neuen Thread angeworfen in der Codesammlung:
Beitrag "EMACS: Konfiguration und Spielereien"

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias W. schrieb:
> Klaus Wachtler schrieb:
>> alles eine Frage des richtigen Editors :-)
>
> Danke für den wertvollen Beitrag Klaus.
>
> Matthias

Damit bin ich irgendwie noch überfordert (kann auch daran liegen, daß 
ich heute einen dicken Kopf habe).

Was es dir zu off topic?
Ohne Ironie ernst gemeint war es wohl nicht?
Zu inhaltslos?

Zumindest heute fällt es mir schwer, zwischen den Zeilen zu lesen 
(zumal, wenn es nur eine ist).
Wenn noch etwas offen ist, bitte klarer formulieren...

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Damit bin ich irgendwie noch überfordert (kann auch daran liegen, daß
> ich heute einen dicken Kopf habe).

komisch, wenn mal ein Lob kommt und
man sich dann fragt, wie das denn sein kann?

> Was es dir zu off topic?
> Ohne Ironie ernst gemeint war es wohl nicht?
> Zu inhaltslos?

Nein. Wie kommst Du da drauf?
Für mich war es eine wertvolle Info.
Ohne wenn und aber.

Matthias

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh, danke.
Ich hatte es als sarkastische Äußerung interpretiert.
Es ist wie gesagt nicht mein Tag heute.
Nur gut, daß ich nicht gleich losgepoltert habe...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.