Hallo, ich hätte ein paar Fragen zu statischen Bibliotheken (also xxx.a Files): 1. Wenn man die Lib erzeugt (also das xxx.a File) ist das ja schon compiliert und nicht veränderbar. Wenn ich nun z.B. eine Lib zur Ansteuerung eines LCD (oder anderer Hardware) schreibe, müsste ich mich da ja schon auf einen Port festlegen. Z.B. die 8 Datenleitungen an Port D, Steuerleitungen an Port C usw. Die Routinen würden aber an anderen Port genauso funktionieren. Wie kann man erreichen, daß das konfigurierbar bleibt? Im Hauptprogramm könnte man ja definieren, an welchen Ports was hängt, aber die Lib ist ja schon compliliert? Oder kann man statische Bibliotheken für solche Zwecke gar nicht nutzen? 2. Wie sieht es mit evtl. leicht unterschiedlichen Portpins, I/O-Adressen, etc aus, je nachdem welchen µC ich verwende? Ich bräuchte ja dann für jeden µC, bzw. Gruppe von µCs die gleich sind, eine eigene Lib? Vielen Dank für Eure Hilfe! Gruß, Marcus
Hardware abhängigen Teil von Hardware unabhängigem Teil trennen. Nur Hardware unabhängigem Teil in Lib packen. Lohnt es sich nicht es auf zuteilen, brauchst Du auch keine Lib.
Marcus S. schrieb: > Oder kann man statische Bibliotheken für solche Zwecke gar nicht nutzen? Kannst du schon, aber dann kannst du die Port- und Pinadressen nicht mehr fest in die Bibliotheksroutinen reincompilieren. Du musst sie also (als Zeiger und Bitnummern) an die Funktionen übergeben, was diese natürlich zwangsläufig weniger effizient macht.
Gast
#2527216
Marcus S. schrieb: > Oder kann man statische Bibliotheken für solche Zwecke gar nicht nutzen? Ja und nein... In eine vorkompilierte lib kannst du nur hardwareunabhängige Dingen packen. Alles hardwareabhängige (und dazu gehört im Prinzip auch der verwendete Prozessor) muß hardwareabhängig neu compiliert werden. Oliver
Die Granularität der Bibliotheken macht sich and deren Binärkompatibilität fest. Wenn die Bibliothek also nicht alle Möglichkeiten abdeckt — etwa weil ein SFRX bei zu verwendendem Derivat A an einer anderen Stelle liegt als bei Derivat B oder anders verwendet wird oder werden muss — dann braucht's eine andere Ausprägung der Bibliothek, d.h. sie muß mit anderen Optionen generiert werden. Um solche Abhängigkeiten gering zu halten, d.h. die Granularität der Biblioteken möglichst grob zu belassen (also möglichst wenige Lib-Ausprägungen), kann man Callbacks einsetzen. In wie weit Callbacks bei so hardwarenahen Dingen sinnvoll sind, ist dann im Einzelfall zu entscheiden. ZB könnte man Callbacks für die Ein/Ausgabe einsetzten und hätte damit nur noch die Granularität, die etwa durch nicht-binärkompatible Hardware erzwunden wird. Ein Callback könnte etwa "Output Byte" sein. Bei 4-Bit anbindung gibe die Funktion 2 Nibbles aus, ansonsten ein Byte. Aber die LCD-Routinen wissen nix davon und müssen Callback-Aufrufe u.U paranoid behandeln, d.h. etwa IRQ deaktivieren um Gliches zu vermeiden. Oder die Callback-Implementierungen müssen sich darum kümmern. Wie das geschieht, legt das Lib-ABI fest. Eine weitere Option wäre das nicht als Bibliothek zu haben, sondern als Quell-Repository.
Liebe Antworter, vielen Dank für Eure (schnellen!) Antworten und Vorschläge. Werde mir dieses Sachen mal ansehen. Danke & Gruß, Marcus