kurze frage zur Init.

öhm schrieb:
> Soweit ich weiß, steht da am Anfang sowieso
> überall 0 drin.

Ist nicht garantiert! Wird aber oft|meistens vom Compiler so gemacht.

öhm schrieb:
> Aha. Wenn es also nicht garantiert wird, dass da immer 0 drinsteht. Dann
> ist wohl guter Stil, dass man vorher alles auf 0 setzt, richtig?

Es IST garantiert für alle Variablen mit "static storage". Das sind alle 
globale, und alle statisch lokale Variablen.

öhm schrieb:
> Programmiersprache C. Logo ;)
>
> Aha. Wenn es also nicht garantiert wird, dass da immer 0 drinsteht. Dann
> ist wohl guter Stil, dass man vorher alles auf 0 setzt, richtig?

Das kommt drauf an, wie schon gesagt.
Globale Variablen werden auf 0 initialisiert. Und das ist auch 
garantiert.
Wenn du selber sie mit 0 initialisierst, dann ist das ok. Allerdings 
läuft man auch schon mal Gefahr, dass man vor lauter 0-initialisierten 
Variablen diejenigen, die eben nicht mit 0 initialisiert werden schon 
auch mal übersieht.

Codemässig macht es allerdings keinen UNterschied. Schreibst du keine 
Initialisierung hin, dann ergänzt sie der COmpiler stillschweigend.


Bei globalen Variablen. Bei funktionslokalen Variablen sieht die Sache 
anders aus.

Steel schrieb:
> Wage ich zu bezweifeln, dass das bei jedem Compiler bzw. Zielsystem so
> ist. Ich hab hier mindestens ein Gegenbeispiel.

Dann ist dieses "Gegenbeispiel" schlicht kaputt, denn der Standard 
verlangt diese Null-Initialisierung.

öhm schrieb:
> ? Hatte ich bis jetzt keine Probleme mit. Genügt doch einfach:
> #ifndef ATMEGA32_CONFIG_H_
> #define ATMEGA32_CONFIG_H_
>
> in die *.h zu setzen.

Include-Guards haben rein gar nichts mit "in einer 2. C-Datei 
inkludieren" zu tun. Sie verhindern nur das mehrfache Einbinden 
innerhalb ein und der selben C-Datei.

öhm schrieb:
> Arbeite mit meinem globalen struct in 3 verschiedenen *.c files und
> alles läuft ohne probleme.

Und das liegt wiederum daran, wie dein Compiler/Linker sowas handhabt. 
"läuft ohne probleme" heißt hier nicht "korrekt so".

Peter II schrieb:
>> Arbeite mit meinem globalen struct in 3 verschiedenen *.c files und
>> alles läuft ohne probleme.
>
> dann hast du 3 mal diese Variable mit 3 Verschienden Adressen.

Kommt auf den Compiler/Linker an. Der GCC z.B. legt aus historischen 
Gründen mehrfache Definitionen gleichen Namens auf die selbe Adresse.

Beim avr-gcc muss man etwas aufpassen mit der Initialisierung von Daten 
im static storage:

Siehe PR18145 und die Anmerkung dazu in den 4.7 Release Notes:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145
http://gcc.gnu.org/gcc-4.7/changes.html

PR18145 war teilweise auch schon vor 4.7 implementiert, etwa in 
WinAVR-20100110 (avr-gcc 4.3.3).

Steel schrieb:
> Stefan Ernst schrieb:
>> Dann ist dieses "Gegenbeispiel" schlicht kaputt, denn der Standard
>> verlangt diese Null-Initialisierung.
>
> Im ebmedded Bereich hält sich nunmal nicht jeder Compiler strikt an den
> Standard.

Mag sein.
Allerdings ist das Ausnullen eines Speichers oder Speicherbereiches beim 
Programmstart trivial und verschlingt jetzt auch nicht massig Code.
Von daher würde ich dann schon sagen
> Dann ist dieses "Gegenbeispiel" schlicht kaputt

öhm schrieb:

>

1

> main.c:

2

> #include "1.h"

3

> 

4

> int main(void)

5

> {

6

>    dummy = 3;

7

> }

8

>

>
>
> Was ist da schon wieder falsch?

du meintest

1

   test.dummy = 3;

eine Variable 'dummy' existiert schlicht und ergreifend nicht.
Wohl aber eine Variable namens 'test'. Und weil dieses 'test' vom Typus 
'struct testS' ist, hat es auch einen Member namens 'dummy'. Daher 
test.dummy
Und in 1.c muss selbstverständlich noch ein #include auf 1.h rein. Woher 
soll denn der Compiler beim compilieren von 1.c sonst wissen, was ein 
struct testS ist?


Abgesehen davon:
Ja, genau so macht man das.

öhm schrieb:
> Noch eine Frage:
>
>
> Sehe auch öfters ein typdef bei den structs. Ist das im embedded Bereich
> sinnvoll?

Das eine hat ja mit dem anderen nichts zu tun.

Wenn es dir zu blöd ist, dauernd 'struct testS' schreiben zu müssen, 
dann deklarierst du dir eben mit einem typedef einen neuen Datentyp, zb 
myTestS, der ein anderen Name für ein 'struct testS' darstellt

1

typedef struct testS myTestS;

Jetzt hast du einen neuen Datentyp vereinbart, den du in weiterer Folge 
benutzen kannst. Zb um damit Variablen zu definieren oder deklarieren 
...

1

myTestS test;

... ohne dauernd 'struct' schreiben zu müssen.

> Wenn ja, wie würde dann die Syntax für mein oberes Beispiel aussehen?

Schön langsam sind wir an einem Punkt angelangt, andem ich dich fragen 
muss, ob denn dein C-Buch zu diesen Themen überhaupt nichts zu sagen 
hat? Wenn ja (was ich mir nicht vorstellen kann), dann schmeiss es weg 
und kauf dir ein Ordentliches, dein Lehrbuch taugt nichts.

Viel wahrscheinlicher ist es allerdings, dass du gar kein Buch hast. Und 
in dem Fall muss ich dich fragen: Warum nicht? Wenn du denkst du kannst 
eine Programmiersprache wie C durch Erfragen von anlassbezogenem 
Achtelwissen in Foren erlernen, dann bist du schief gewickelt.

öhm schrieb:

> Ich möchte ja das globale struct initialisieren. Denke es müsste so
> sein:
.... initialisieren .....

>

1

> 1.c:

2

> 

3

> struct testS test;

4

> 

5

> void Init ()

6

> {

7

>   test.dummy = 0;

8

> }

9

>

Das hier ist streng genommen keine Initialisierung mehr. Das ist eine 
Zuweisung!
Vor Aufruf der Funktion Init() hat test.dummy den Wert 0. Als globale 
Variable wird sie automatisch auf diesen Wert initalisiert. Dann rufst 
du Init auf und weißt test.dummy einen Wert zu (der in diesem Fall 
ebenfalls 0 ist).

Initialisierungen gibt es immer nur ein einziges mal. Variablen werden 
initialisiert (wenn überhaupt), wenn die Variablen erzeugt werden, wenn 
sie geboren werden. Initialisierungen werden daher immer bei der 
Definition der Variable angeführt. Alles andere danach kann dann nur 
noch eine Zuweisung sein.

In C gibt es ein paar kleinere Feinheiten, die auf dem Unterschied 
Initialisierung-Zuweisung aufbauen. Von daher ist es wichtig, diesen 
Unterschied zu kennen! Zum Beispiel können 'const' markierte Dinge nur 
initialisiert werden, nicht jedoch zugewiesen.

1

  const int i = 5;      // ist ok. Das ist eine Initialisierung

2

3

  const int j;

4

  j = 8;                // ist nicht ok. Das ist eine Zuweisung

öhm schrieb:

> Und in dieser Init() würden dann alles auf die Startwerte gesetzt
> werden.
> Ansonsten müsste ich in jeder der drei files die initialiserung extra
> durchführen...  Das das problem.

Die Frage ist halt, inwiefern diese Initialisierungen für diese 'Module' 
eine Privatangelegenheit sind, oder ob main() (im Grunde) davon wissen 
muss, dass hier Initialisierungen durchzuführen sind.

Grundsätzlich: Je weniger du in main() wissen musst, zum Beispiel auch 
darüber, dass du eine Funktion aufrufen musst, die erst mal eine gültige 
Ausgangssituation herstellt, ... desto besser. Eine Funktion die man 
nicht aufrufen muss, kann man auch nicht vergessen aufzurufen.

Werd mal etwas konkreter, was diese Strukturen angeht. Was beschreiben 
die? Gehören die in irgendeiner Form zusammen? Gibt es da 
Abhängigkeiten?

Denn
> In meiner main würd ich halt gern schreiben:
genau das möchte man nämlich eigentlich nicht 'gerne' tun.
Manchmal muss man diese Krot schlucken, weil es nicht anders geht. Aber 
gerne macht man das nicht.

öhm schrieb:
> Und in dieser Init() würden dann alles auf die Startwerte gesetzt
> werden.

Wenn es globale Variablen sind und du es zur Laufzeit nie neu
initialisieren musst: nimm eine Initialisierung statt einer
Zuweisung.  Das spart massig Code.  Deine Zuweisung kann der
Compiler nicht optimieren, die wird einzeln Tippeltappeltour
durchlaufen.  Bei einer Initialisierung dagegen speichert er nur
die Initialwerte als kompletten Block irgendwo ab und lädt die
entsprechenden RAM-Bereiche beim Start davon.  Das ist also effektiv
genau ein memcpy(), was da ausgeführt werden muss.  (Objekte, die
komplett nur mit Nullen vorbelegt werden müssen, müssen nicht einmal
kopiert werden, sondern sie werden mit etwas wie memset() auf Null
gesetzt.)

Wenn du wirklich auch zur Laufzeit wieder ganz von vorn anfangen
können musst, würde ich mir überlegen, wie man den Controller dann
durch einen vollständigen Reset schießen kann.

Stefan Ernst schrieb:
> Peter II schrieb:
>>> Arbeite mit meinem globalen struct in 3 verschiedenen *.c files und
>>> alles läuft ohne probleme.
>>
>> dann hast du 3 mal diese Variable mit 3 Verschienden Adressen.
>
> Kommt auf den Compiler/Linker an. Der GCC z.B. legt aus historischen
> Gründen mehrfache Definitionen gleichen Namens auf die selbe Adresse.

Ja, uninitialisierte Variablen werden in den "common" Block gelegt. Ist 
wohl eine uralte Unix-Tradition aus der Zeit vor ANSI-C. Daher empfiehlt 
sich bei GCC auch die Verwendung von -fno-common, um das zu verhindern. 
Damit bekommt man dann Fehlermeldungen wenn derselbe Variablenname in 
mehreren Quelldateien global definiert wird.

öhm schrieb:
> Ich möchte alle Startbedingungen auf einen Blick in einer Datei haben,
> da an diesen Werten hin und wieder gedreht werden muss.

Ein möglicher Ansatz ist deiner, wobei er praktisch die doppelte
Anzahl von Namen verursacht.

Ein anderer wäre es, sämtliche globalen initialisierten Variablen
in einer eigenen C-Datei abzulegen, in der dann auch die Initialwerte
stehen.

Die Resetwerte der einzelnen SFRs sind im jeweiligen Manual aufgeführt 
und haben nichts mit der C-Initialisierung zu tun. Nicht alle SFRs 
werden beim Powerdown-Reset auf 0 gesetzt, siehe TWSR beim ATmega168.

öhm schrieb:
> Darf ich immer davon ausgehen, dass beim Programmstart alle timer,
> interrupts etc register mit 0x00 beschrieben sind?

Nein.


> Oder gibt es hier  auch Ausnahmen?

Ja. Steht im Datenblatt des verwendeten Controllers. Evt. wurstelt der 
Compiler da noch was rum, sollte dann aber irgendwo im Manual des 
Compilers beschrieben sein.

öhm schrieb:
> Ah, ich sehe grad im Datenblatt, dass unter jedem Register die "initial
> values" eingetragen sind. Danke!
>
> Wie war das nochmals:
>
>    X  =   undefined
>   N/A =  ?

N/A
  not available ... (Information) nicht verfügbar
  not applicable ... macht in dem Zusammenhang keinen Sinn.


Es mag noch andere Verwendungen für diese Abkürzung geben, aber das sind 
wohl die beiden häufigeren in unserem Metier.

W.S. schrieb:
> Karl Heinz Buchegger schrieb:
>> Globale Variablen werden auf 0 initialisiert. Und das ist auch
>> garantiert.
>
> Und bittesehr von WEM? Wer garantiert einem da was?

Im C-Standard

6.2.4 $3

> An object whose identifier is declared with external or internal
> linkage, or with the storage-class specifier "static" has static
> storage duration. Its lifetime is the entire execution of the
> program and its stored value is initialized only once,
> prior to program startup.

sowie 6.7.8 $10

> [...]
> If an object that has static storage duration is not
> initialized explicitly, then:
> — if it has pointer type, it is initialized to a null pointer;
> — if it has arithmetic type, it is initialized to (positive
>   or unsigned) zero;
> — if it is an aggregate, every member is initialized (recursively)
>   according to these rules;
> — if it is a union, the first named member is initialized (recursively)
>   according to these rules.

Daß bei Nichteinhaltung des Standards alles möglich ist, ist ja wohl 
klar und bedarf kaum des Aufhebens.

W.S. schrieb:

> Leute, wir sind hier bei Mikrocontrollern, gelle?

Und?
Deswegen gelten die C-Regeln nicht mehr, oder wie ist das?

Wenn deine Compiler das nicht tun, dann sind sie keine C-Compiler 
sondern compilieren irgendwas was so ähnlich aussieht wie C, es aber 
nicht ist. Wenn deine Compiler/Linker einen Schalter haben, der in der 
Runtime die geforderte 0-Initialisierung abschaltet, dann ist das nett, 
kann aber kaum zur allgemeinen Regel erhoben werden.
Wenn ich mich nicht mehr darauf verlassen kann, was mir als 
C-Programmierer im C-Standard zugesichert wird, worauf kann ich mich 
dann überhaupt verlassen?

Ich muss euch beiden Recht geben. Der Standard garantiert, dass globale 
Variablen mit Null initialisiert werden. Doch es gibt im 
Mikrocontrollerbereich Compiler, die in einigen Punkten vom Standard 
abweichen, weil diese bei Mikrocontrollern kontraproduktiv oder nicht 
sinnvoll sind. Also kann man sich erst zu 100% darauf verlassen, nachdem 
man das Handbuch des Compilers gelesen/überflogen hat (was man ja so 
oder so tut, bzw. tun sollte).

Schon nur aus Gründen der Übersichtlichkeit und Verständlichkeit des 
Codes initialisiere ich globale Variablen mit dem gewünschten Wert (auch 
wenn das Null ist), wenn der Variable zwingend diesen Wert zugewiesen 
werden muss. Ansonsten initialisiere ich die Variable nicht. Mache ich 
grundsätzlich mit allen Variablen so.

Karl Heinz Buchegger schrieb:
> Und?

Ach, Karl Heinz, das war einfach nur ein typischer W. S.  Der Thread
war zwar schon lange durch, aber er muss natürlich auch noch was dazu
sagen. Ob er das überhaupt weiß und ob es richtig oder falsch ist,
spielt dabei eine nur sehr untergeordnete Rolle …

be stucki schrieb:
> Doch es gibt im Mikrocontrollerbereich Compiler, die in einigen Punkten
> vom Standard abweichen, weil diese bei Mikrocontrollern kontraproduktiv
> oder nicht sinnvoll sind.

Die Initialisierung globaler Variablen ist jedoch ein derart
grundlegendes Prinzip von C, dass eine Toolchain, die das nicht
macht, sich auch nicht "C" nennen darf. Selbstverständlich hat eine
derartige Initialisierung in aller Regel auch im Umfeld von
Mikrocontrollern ihre Berechtigung und ist keineswegs kontraproduktiv.
(Einzelne Ausnahmen kann man sehr selten mal gebrauchen, siehe das
".noinit"-Feature in der avr-gcc/avr-libc-Toolchain, für Variablen,
deren Wert einen Reboot überleben soll, und deren initiale
Wertzuweisung an anderer Stelle als beim Startup erfolgen soll.)

> Schon nur aus Gründen der Übersichtlichkeit und Verständlichkeit des
> Codes initialisiere ich globale Variablen mit dem gewünschten Wert (auch
> wenn das Null ist)

Bei älteren GCC-Versionen war das übrigens wirklich kontraproduktiv:
damit hat man das entsprechende Objekt nämlich aus dem BSS raus und
ins Data reingeworfen, mit dem Effekt, dass dann für die Initialisierung
mit 0 zusätzlich Platz benötigt worden ist.

Außerdem: wenn du dich nicht auf die 0-Initialisierung verlassen
möchtest, woher nimmst du dann die Gewissheit, dass die explizite
Initialisierung (von nicht-"auto"-Variablen meine ich) denn noch
funktioniert? Vielleicht hat der ehrenwerte Tool-Hersteller ja diese
auch als "bei Mikrocontrollern kontraproduktiv" gleich mal weggelassen?
;-)

Jörg Wunsch schrieb:
> Die Initialisierung globaler Variablen ist jedoch ein derart
> grundlegendes Prinzip von C, dass eine Toolchain, die das nicht
> macht, sich auch nicht "C" nennen darf.

Das ist mir bewusst, evt. ist mein Beitrag falsch rübergekommen. Er 
bezog sich nicht nur auf die Null-Initialisierung globaler Variablen, 
sondern dass es "C"-Compiler gibt, die nicht zu 100% dem C-Standard 
entsprechen.

Jörg Wunsch schrieb:
> Bei älteren GCC-Versionen war das übrigens wirklich kontraproduktiv:
> damit hat man das entsprechende Objekt nämlich aus dem BSS raus und
> ins Data reingeworfen, mit dem Effekt, dass dann für die Initialisierung
> mit 0 zusätzlich Platz benötigt worden ist.

Solange ich genug Speicher habe, wäre mir das egal.

Jörg Wunsch schrieb:
> Außerdem: wenn du dich nicht auf die 0-Initialisierung verlassen
> möchtest, woher nimmst du dann die Gewissheit, dass die explizite
> Initialisierung (von nicht-"auto"-Variablen meine ich) denn noch
> funktioniert? Vielleicht hat der ehrenwerte Tool-Hersteller ja diese
> auch als "bei Mikrocontrollern kontraproduktiv" gleich mal weggelassen?
> ;-)

Ich würde mich darauf verlassen, wenn es denn nötig wäre. Ich 
initialisiere alle Variablen, damit ich auch in 2 Monaten auch noch 
weiss, dass der Inhalt der Variable beim Aufstarten zwingend Null (oder 
sonst ein Wert) sein muss, damit mein Programm richtig funktioniert. Es 
gibt solche Fälle, diese versuche ich natürlich immer zu vermeiden.

be stucki schrieb:
> sondern dass es "C"-Compiler gibt, die nicht zu 100% dem C-Standard
> entsprechen.

Selbstverständlich. Auch der GCC ist meines Wissens nicht komplett
C99-kompatibel (von C1x ganz zu schweigen).  Der AVR-GCC ist schon
dahingehend nicht konform, dass sein "double" nur 32 bits groß ist
und damit den Minimalforderungen des Standards an ein double nicht
genügt (48 bits wären ausreichend, es müssen nicht zwingend 64 sein).

Aber das sind alles weit weniger wichtige Dinge als die Initialisierung
globaler und statischer Objekte, die seit jeher ein Bestandteil der
Sprache C war und ist.

Jörg Wunsch schrieb:

> Der AVR-GCC ist schon dahingehend nicht konform, dass sein
> "double" nur 32 bits groß ist und damit den Minimalforderungen
> des Standards an ein double nicht genügt

Noch ne abschweifende Frage dazu: Im GCC double auf 64 Bits zu setzen 
und die entsprechenden Multilibs zu erzeugen ist ja keine große Aktion, 
aber wer würde die limbm-Teil übernehmen mit sin, cos, tan, exp, log, 
etc.?

Oder würde das bedeuten, daß der Distributor den Compiler zwingend mit 
newlib verbandeln muß?  Immerhin richtet die newlib die multilibs nach 
gcc aus, nicht wie die avr-libc, wo das hart reingeklöppelt ist :-P

Johann L. schrieb:

> Noch ne abschweifende Frage dazu: Im GCC double auf 64 Bits zu setzen
> und die entsprechenden Multilibs zu erzeugen ist ja keine große Aktion,
> aber wer würde die limbm-Teil übernehmen mit sin, cos, tan, exp, log,
> etc.?

Genau das wäre die Frage.  Es ist ja nicht nur sin, cos und Konsorten,
sondern dann müssten auch sinf, cosf usw. da sein (wofür man natürlich
die bisherigen Implementierungen benutzen kann).

Außerdem sollte das Ganze meiner Meinung nach noch zur Laufzeit
durch den Benutzer auswählbar sein, so ähnlich wie seinerzeit bei
-mint8, also ein -mdouble32 zum Beispiel.  Die meisten Nutzer sind
ja mit der derzeitigen Implementierung durchaus zufrieden, sie gibt
einen relativ guten Gebrauchswert fürs Geld.

> Oder würde das bedeuten, daß der Distributor den Compiler zwingend mit
> newlib verbandeln muß?

Wäre vermutlich beim derzeitigen Stand dann die einzige Variante. Das
passt ja zumindest dahingehend, dass das Gesamtergebnis ohnehin kaum
noch auf Controllern < 64 KiB sinnvoll zu benutzen sein wird. ;-)

Jörg Wunsch schrieb:
> Johann L. schrieb:
>
>> Noch ne abschweifende Frage dazu: Im GCC double auf 64 Bits zu setzen
>> und die entsprechenden Multilibs zu erzeugen ist ja keine große Aktion,
>> aber wer würde die limbm-Teil übernehmen mit sin, cos, tan, exp, log,
>> etc.?
>
> Genau das wäre die Frage.  Es ist ja nicht nur sin, cos und Konsorten,
> sondern dann müssten auch sinf, cosf usw. da sein (wofür man natürlich
> die bisherigen Implementierungen benutzen kann).
>
> Außerdem sollte das Ganze meiner Meinung nach noch zur Laufzeit
> durch den Benutzer auswählbar sein, so ähnlich wie seinerzeit bei
> -mint8, also ein -mdouble32 zum Beispiel.

Gibt's doch bereits, nämlich -f[no-]short-double. Momentan ist implizit 
-fshort-double gesetzt und die no-Version wird ignoriert. newlib 
unterstützt übrigens -f[no-]short-double, d.h. mit der Option ist double 
kurz, ein sin wird als sinf ausgeführt und printf passt sich auch an.

> Die meisten Nutzer sind ja mit der derzeitigen Implementierung
> durchaus zufrieden, sie gibt einen relativ guten Gebrauchswert
> fürs Geld.

Ja, die Sturm-und-Drang-Jahre der avr-Toolchain sind eindeutig vorbei...

>> Oder würde das bedeuten, daß der Distributor den Compiler zwingend mit
>> newlib verbandeln muß?
>
> Wäre vermutlich beim derzeitigen Stand dann die einzige Variante. Das
> passt ja zumindest dahingehend, dass das Gesamtergebnis ohnehin kaum
> noch auf Controllern < 64 KiB sinnvoll zu benutzen sein wird. ;-)

M.E. nicht bei einer smarten Assemblerlösung nebst der Implementierung 
des 64-Bit Move im avr-gcc.

Johann L. schrieb:
> M.E. nicht bei einer smarten Assemblerlösung nebst der Implementierung
> des 64-Bit Move im avr-gcc.

Schon richtig, aber dafür muss erstmal jemand Zeit und Muse haben.
(Mit anderen Worten: es muss jemand 64-bit-double so nötig brauchen
zusammen mit den übrigen avr-libc-Features, dass newlib für ihn keine
Option wäre und er stattdessen gewillt ist, den Aufwand in die
Erweiterung der avr-libc zu spendieren.)