Code verstehen?

[Vinz (Gast)]

Hallo miteinand,

bin noch relativer Neuling auf dem gesamten Gebiet. Toolchain habe ich 
am laufen und auch schon eine LED (habe mir das RN-board + Mega32 
geholt) zum leuchten gebracht.
ABER: nun  will ich mal ein bisschen mehr als das ... z.b. USART, ADC, 
PWM etc.
Die diversen libs habe ich schon gefunden.
Nur verstehe ich die leider meistens nicht (wenn man sich mal dran setzt 
und die diversen h und c files kapieren möchte).
Wofür stehen diese ganzen _ oder ? Und die sind meistens in 
irgendwelchen kryptischen Bezeichnungen ... bsp.: iom32.h  --- #ifndef 
_Assembler .
Außerdem gibt es diese SFR (spezial funktion registers) mit einem Haufen 
wilder Zusatzbezeichnungen und wiederum lauter _ -> vgl. ebenfalls 
iom32.h. Was soll das?

Hoffe mir kann jemand unter die Arme greifen

[Karl H. (kbuchegg)]

Um eine Library zu verstehen sind die *.h und *.c wirklich
kein guter Weg. Das macht man nur dann, wenn keine vernünftige
Doku zur Verfügung steht.

Aber hast du schon mal ins Tutorium auf dieser Site geschaut?

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

Ein paar Blicke ins Assembler Tutorium können auch nicht
schaden:
http://www.mikrocontroller.net/articles/AVR-Tutorial

[johnny.m (Gast)]

Wenn es um die AVR-libC geht: Da ist eine Doku dabei, die auch afaik mit 
WINAVR zusammen "installiert" wird...

[Jörg W. (dl8dtl) (Moderator)]

> Wofür stehen diese ganzen _ oder ?

Erst einmal sind das ganz normale gültige Zeichen in Bezeichnern der
Sprache C (also Namen von Makros, Funktionen, Funktionsparametern,
Variablen, ...).  Namen die mit einem oder zwei Unterstrichen beginnen
haben aber per Dekret (des C-Standards) eine Besonderheit: sie sind
reserviert "for the implementation", d.h. für den Compiler und die
Standardbibliothek.  Damit verhindert man, dass diese Namen mit
gültigen Namen in der Applikation kollidieren können (da Applikationen
selbst derartige Namen nicht von sich aus benutzen/erfinden dürfen).

Um's mal anschaulich zu machen, stell dir vor, ein Headerfile der
Systembibliothek (sagen wir, <foo.h>) hätte folgenden
Funktionsprototypen deklariert:

int dosomething(int x, int y);

Jetzt kommt eine Applikation und schreibt

#define x 800 /* X-Aufloesung */
#define y 600 /* Y-Aufloesung */

#include <foo.h>

...

Was passiert dann?  Nach dem Präprozessor sieht das dann für den
Compiler so aus:

int dosomething(int 800                   , int 600                   );

...was offensichtlich kein sinnvoller oder gültiger Funktionsprototyp
mehr ist.  Daher muss foo.h stattdessen schreiben:

int dosomething(int __x, int __y);

Da die Bezeichner __x und __y "reserved for the implementation" sind,
darf die Applikation sie selbst in keiner Weise bereits definiert
haben.  Damit lässt sich das Ganze ordentlich compilieren, egal was
die Applikation an legalen Makros bereits selbst definiert hat.

Aber wie andere schon schrieben: ich würde nicht mit dem Studium der
Headerfiles der Systembibliotheken beginnen.  Bibliotheken schreibt
man so, dass sie unter allen möglichen Randbedingungen gut
funktionieren, dass sie möglichst flexibel sind, ggf. verwenden sie
allerlei Compilertricks (inline asm, beim GCC irgendwelche
__attribute__-Dinge), um spezielle Ziele zu erreichen (und sei's nur
optimaler Code), das erschwert alles das Verständnis.  Das Ziel einer
Bibliothek ist ja eine gute Benutzbarkeit.

Nimm dir Beispielcode.

[Oliver (Gast)]

Und nimm dir das Datenblatt des Prozessors. Da steht drin, was welches 
Bit in welchem Register bedeutet. Das, die avr-libc Doku und das 
avr-gcc-Tutorial hier oben rechts ist alles, was man braucht.

Oliver

[wulf (Gast)]

> und das avr-gcc-Tutorial hier oben rechts...
...hier oben links ;-)

[Vinz (Gast)]

coole Sache ...

bin dabei das alle mal abzuchecken! Vielen Dank für die schnellen und 
guten Antworten!

Schönes WE

Vinz