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
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
Wenn es um die AVR-libC geht: Da ist eine Doku dabei, die auch afaik mit WINAVR zusammen "installiert" wird...
> 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:
1 | int dosomething(int x, int y); |
Jetzt kommt eine Applikation und schreibt
1 | #define x 800 /* X-Aufloesung */ |
2 | #define y 600 /* Y-Aufloesung */ |
3 | |
4 | #include <foo.h> |
5 | |
6 | ...
|
Was passiert dann? Nach dem Präprozessor sieht das dann für den Compiler so aus:
1 | int dosomething(int 800 , int 600 ); |
...was offensichtlich kein sinnvoller oder gültiger Funktionsprototyp mehr ist. Daher muss foo.h stattdessen schreiben:
1 | 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.
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
coole Sache ... bin dabei das alle mal abzuchecken! Vielen Dank für die schnellen und guten Antworten! Schönes WE Vinz
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.