Bibliotheken erstellen

[Ralf (Gast)]

Hi,

bin jetzt nicht sicher, ob das hier rein gehört oder unter
"PC-Programmierung".

Gibt es ein Dokument, welches beschreibt, wie man Bibliotheken für
µC-Hardware schreibt? Beispiel:

- Es soll eine Lib für ein Display erstellt werden.
- Das Display ist entweder an IO-Ports angeschlossen, oder liegt im
Datenspeicher-Bereich (memory-mapped).
- Wird es über IOPorts angeschlossen, muss man ja irgendwo festlegen,
welche Port(pin)s welche Funktion haben.
- Ist es im Datenspeicher-Bereich angeschlossen, muss die Adresse
angegeben werden können.

Das bedeutet, die Grundfunktionen sind in der Lib enthalten, die
Ansteuerungsart usw. wird z.B. in einer Header-Datei festgelegt.

Und wie löst man es, wenn man z.B. mehrere Displays angeschlossen hat?
Okay, der Fall ist unwahrscheinlich, aber es können ja auch andere
Peripherie-Einheiten sein...

Ralf

[A.K. (Gast)]

Eine Library packt eine beliebige Anzahl bereits übersetzter(!)
Programmteile (*.o/*.obj) in ein Paket zusammen. Wenn die Eigenschaften
des Code erst durch diverse #defines festgelegt werden, also
beispielsweise die Port-Pins an denen das LCD dranhängt, dann ist dir
mit einer Library nicht gedient.

Wenn Du also beispielsweise bestehenden Code für Text-LCD für mehrere
angeschlossene Displays nutzen willst, ist Code, der für ein einziges
Display geschrieben wurde, zunächst nutzlos, egal ob als Source, Object
oder Lib. Den Code wird Du unweigerlich selber anpassen müssen.

[Hubert.G (Gast)]

Suche mal unter Peter Fleury, der hat einige Libs z.B. für LCD, UART
usw. da kannst du dir ansehen wie man so was macht.

Schöne Feiertage wünscht
Hubert

[Ralf (Gast)]

Okay,

bezogen auf die IO-Port-Steuerung wird das schwieriger, aber was ist,
wenn ich bei memory-mapped die Displays als Variablen im Datenbereich
übergebe? Könnte doch klappen, wenn ich diese Variablen in der Lib als
extern definiere, oder?!?

Ralf

[A.K. (Gast)]

Ja klar. Die Adressen, die Bitnummern, die Unterscheidungen zwischen
I/O- und mem-mapped, mit und ohne R/W, 4bit und 8bit. Kann man alles
parametrisieren. Ist dann kompiliert ja nur 3mal so gross wie nötig.

[Unbekannter (Gast)]

Die Lösung heißt:

Indirektion und Abstraktion.

D.h. Du baust Deine Libs so, dass sie nicht wissen, wie die Bytes zum
Display kommen. Dazu verwendest Du eine struct, z.B. ähnlich wie ein
File-Descriptor, in der die benötigten Callbacks für die
Display-Routinen hinterlegt werden können.

Zusätzlich kannst Du für bestimmte Architekturen die Callbacks schon
vorgefertigt in der Lib mitliefern. Also z.B. für Memory-Mapped oder
Port-Zugriff.

Der Trick besteht darin, dass Deine Lib keine statischen oder globalen
Variablen verwenden darf. Dann kannst Du mit der Lib auch mehrer
Displays problemlos bedienen.

Schau Dir an, wie eine normale C-Laufzeitbiblithek organisiert ist:

Du hast FILE-Pointer, und Funktionen wie "fprintf" und "fputs" etc.
Zusätzlich hast Du dann für die häufig gebrauchten Zugriffen auf
Standard-Kanäle die Funktionen "printf" und "puts".

Dabei wird aus einem printf("bla") einfach nur ein fprintf(stdout,
"bla") und aus einem puts("Hallo") wird ein fputs("Hallo",
stdout) usw.

Also jede Schicht in so eine Lib löst ein Problem mit einer
Indirektion. Die Kunst besteht nun, die Indirektionen und Abstraktionen
an den richtigen Stellen zu wählen. Dafür braucht es einiges an
Erfahrung und das ist erfahrungsgemäß das schwierigsten am Schreiben
eine Lib.

[Ralf (Gast)]

Mhm... Werd mir mal Gedanken machen, ich glaube, ich habs zumindest zum
größten Teil verstanden...
Mal sehen, da wird der Schädel zwischen den Jahren wieder ordentlich
rauchen...

Frohe Weihnachten!

Ralf