Gibt es einen inhaltlichen Unterschied zwischen Treibersoftware und einer programmierschnittstelle (API)?
:
Verschoben durch Moderator
Eine API ist eine Schnittstelle zwischen verschiedenen Softwarekomponenten. Es kann eine API zwischen Treiber und Firmware geben oder zwischen zwei Firmwaremodulen oder zwischen einem Webservice und dem entsprechenden Client. Oder oder...
:
Bearbeitet durch User
Felix U. schrieb: > Eine API ist eine Schnittstelle zwischen verschiedenen > Softwarekomponenten. Es kann eine API zwischen Treiber und Firmware > geben oder zwischen zwei Firmwaremodulen oder zwischen einem Webservice > und dem entsprechenden Client. Oder oder... ist VISA eine API (Kommunikation Treiber und Hochsprache)?
Unterschied schrieb: > ist VISA eine API (Kommunikation Treiber und Hochsprache)? VISA hat sicherlich eine API aber besteht aus mehr als der API.
Ich erkläre es dir mal an einen Beispiel. Ich habe ein Brother QL-560 (Ein Etikettendrucker). Der wird mit Treiber-CD und Software zum Erstellen von Etiketten ausgeliefert. Ergo kannst du damit Etiketten bedrucken ;) Willst du aber (wie ich) diese Etiketten aus deiner eigenen Software bedrucken, wird es sehr schwer. Die Lösung ist das "Entwicklerpaket" was Brother anbietet. Da ist eine DLL drin. Die Installierst du. Dann deklarierst du in deiner Software via API diese DLL. Oder Importierst sie einfach je nach Entwicklungssystem. Und nun hast du die "besondere Funktionen" zur Verfügung die der Hersteller dir anbietet. Und diese DLL in meinen Fall, übernimmt den Aufbau des Etikett und druckt es aus. So einfach ist das ;)
gute Erklärung. Also ich habe einen herstellerspezifischen treiber. Ich habe mir eine Bedienoberfläche mittels Winforms gebastelt (c#). Wenn ich Commands (z.B SCPI) an ein Messgerät schicke, z.B. wenn ich an meiner Bedienoberfläche "test starten" drücke, wäre VISA API zwischen .net und Treiber?
also, wenn ich mir das in Schichten vorstelle: -------- 3. Software. Hochsprache Bedienoberfläche z.B. Winforms ---------- 2. Software: API z.B. VISA ------ 1. Software: Treiber ------- Hardware: Steckverbing, z.B. USB ------ oder kann man das USB TMC Protokoll schon als Teil-Software anerkennen?
Ich weiß nur wie ich es unter Visual-Basic mache.
Ich Binde im Menü Projekt die DLL ein. Dann ist der erste Befehl der
Hauptform #include "name_des_workspace" z.b. #include "bpac" .
In der passenden Sub mache ich dann folgendes.
Dim objDoc As bpac.Document ' den objekt eine kurze Tipform zuweisen
;)
objDoc = CreateObject("bpac.Document") ' ein Befehl des Objekt
ausführen.
Bei meiner eigenen Dll geht es einfacher. ;)
#include "my_dll"
Und in der Sub.
sin_grad = my_dll.winkel_in_grad(45) ' Weil MS den Sinus-Wert nur in
Raduis ausgibt ;)
Aber das ist nur wie es in VB geht. Andere Entwicklungssysteme = Andere
Syntax aber gleiches Vorgehen. Einbinden, anmelden, nutzen.
ja verstehe ich. Aber das ist ja schon die konkrete Umsetzung als Code. Mir geht es um den Informationsfluss. Welche Schichten aneinander grenzen usw.
Kleiner Hinweis am Rande. Du kannst auf die Weise sogar jede Software einbinden die VBA unterstützt. Also Excel, World, Corel etc.. Ich persönlich habe mal eine Software unter VB geschrieben die Daten von einer AS400 holt, analysiert und das Ergebnis via Excel als Tabelle und Diagramm ausgibt. DLL mit API-Schnittstelle sind MEGA MÄCHTIG. ;)
Unterschied schrieb: > gute Erklärung. Wenn du das mit der Zitierfunktion verstanden hättest, wüßten wir auch alle, was du für eine gute Erklärung hältst. Ich habe in diesem Thread bisher keine gute Erklärung gesehen. Die Frage ist aber auch von der Art "Ist ein Apfel eine Birne?" API = "Application Programming Interface" ist im Prinzip ein Vertrag zwischen zwei Software-Modulen, wie sie ihre Dienste bereitstellen. Also z.B. welche Funktionen aufrufbar sind, mit welchen Parametern und was diese Funktionen jeweils tun. Die API für sich ist lediglich Dokumentation. Eine API kann existieren, ohne daß es eine einzige Zeile Code gibt, die diese API implementiert. "Treibersoftware" ist wie der Name sagt, Software. Also existierender Code. Damit dieser Code überhaupt zu etwas nütze ist, muß er seine Dienste gemäß irgendeiner (mehr oder weniger) standardisierten API bereitstellen. Wenn es ein Autovergleich sein darf: die API ist die Festlegung, daß es drei Pedale gibt, von denen das rechte das Gaspedal ist. Ferner, daß das Auto nach rechts fährt, wenn man das Lenkrad nach rechts dreht. usw. usf. Ein Auto (jedes Auto) implementiert diese API. Der Treiber wäre alles das, was der Hersteller zwischen die API (Bedienelemente) und die Auto-Hardware (Motor, Getriebe, Lenkung) bauen muß, damit die API für sein Auto funktioniert. Der Begriff "Treiber" wird vergleichsweise unscharf verwendet. Meist meint man damit eine Software-Komponente, die als Teil eines Betriebssystems läuft und/oder eine API zum Zugriff auf eine Hardwarekomponente implementiert. Die Grundidee besteht darin, daß sich viele Hardwarekomponenten ähnlich genug sind, daß man sie mit der gleichen API ansprechen kann. Wenn man jetzt zwischen der Anwendungssoftware und der spezifischen Hardware eine Zwischenschicht einzieht, die zur Anwendung hin immer das gleiche API bereitstellt, zur Hardware hin aber spezifisch für die jeweilige Variante ist, dann nennt man genau diese Zwischenschicht einen Treiber. Die Applikation kann man dann unverändert mit jeder Hardware benutzen, für die man einen Treiber hat.
das ist eine gute erklärung Axel Unterschied schrieb: > -------- > 3. Software. Hochsprache Bedienoberfläche z.B. Winforms > > ---------- > > 2. Software: API z.B. VISA > > ------ > > 1. Software: Treiber > > ------- > Hardware: Steckverbing, z.B. USB > > ------ habe ich denn Recht. lese beim hersteller : VISA is an application programming interface (API) for instrument control. It allows you to programmatically send commands and receive data from instruments and other test and measurement devices (such as sources and switches).
Keysight’s I/O offerings are bundled into a single product called the Keysight IO Libraries Suite. It contains everything you need to get started controlling your instrument. The IO Libraries Suite is included with each instrument and I/O interface that you purchase from Keysight. An I/O library is software that runs on your computer to establish communication with an instrument. This communication could be over GPIB, USB, LAN, RS-232, VXI, or some other physical medium. If you write software, or use prewritten software, to control your instruments they will probably use one of the I/O libraries mentioned below. Instrument drivers, which provide a higher-level interface to the instrument, use I/O libraries internally to send and receive information from the instrument. ------- Die IO libraries fungieren also als API und software, also bei mir schicht 2 und 3?
Unterschied schrieb: > VISA is an application > programming interface (API) for instrument control. Also genau das selbe wie mein Brother-Zeug. Du musst aber drauf achten das es das Instrument was du hast auch unterstützt. Die Protokolle sind nicht immer "Norm-Gerecht" und in vielen Fällen Streng geheim. Die Hardware-Schnittstelle ist in 99% aller Fälle inzwischen USB. Die sicherste Methode ist, wenn auf den Instrument auch VISA drauf steht (und die nicht die Kreditkarten-Firma meinen)
Axel S. schrieb: > Ich habe in diesem Thread bisher keine gute Erklärung gesehen. Doch. Es gab eine, die es genau auf den Punkt gebracht hat: Cyblord -. schrieb: > API zu Treiber verhält sich wie Lenkrad zu Auto.
Unterschied schrieb: > macht das sinn, sich das als schichten vorzustellen Nein. nicht wirklich. Diese ganze Schichten-Sache ist nur reine Theorie mit der Hoffnung sich die Praxis vorzustellen. Anders gesagt : Man versucht ein "Aufbau" der einzelnen Programmteile und deren Reihenfolge und Rechte darzustellen. In der Praxis reicht er völlig aus, wenn man weiß was man braucht, und wie man es handhabt. Wobei die Reihenfolge relativ wichtig ist. Viele Entwickler schreiben super Programmen (inkl. ich fg) ohne sich da wirklich ein Kopf wegen zu machen. JA, ich weiß wie das alle funktioniert. Aber nur weil ich neugierig bin, und gerne hinter die Kulissen schaue, nicht weil ich es für die Arbeit wirklich wissen muss. Als Entwickler machst du folgendes. Du suchst das Modul (meist eine DLL) bindest sie in deine Software ein per Befehl und nutzt dann die Zusätzlichen Funktionen laut der Anleitung. Und glaube mir, bei einen großen Modul schafft deine Gehirn nicht, alle Befehle die das Modul bereitstellt sich mit allen Parametern zu merken. Falls du unter MS-Visual(irgendwas) arbeitest drück mal die F2-Taste ;)
Na klar ist ne Schichtenstruktur wichtig. Jede Schicht ist von den anderen unabhängig, macht genau ihr Ding und kann jederzeit ausgetauscht werden. So kann ich mit der selben API mein Boot oder gar nen Schweigstill- Heli steuern, wenn die Treiber funzen. ;-P mfg
~Mercedes~ . schrieb: > Na klar ist ne Schichtenstruktur wichtig. Klar ist die wichtig. ~Mercedes~ . schrieb: > und kann jederzeit ausgetauscht werden. Auch das ist richtig. Aber Ich muss nur wissen DAS ich sie austauschen kann. Nicht wie das ganze funktioniert. Davon abgesehen. In der Praxis ist das mit den "ich kann alles mit einer machen" nur mit den DLL von MS selbst halbwegs brauchbar machbar. Bei allen anderen ist es besser die DLL in sein Installationsverzeichnis zu kopieren. Windows sucht nämlich zuerst DA. Und das hat sein Grund ;) Das Wort kompatibel lernst du sonst erst richtig kennen. Andere OS gehen z.T. einen anderen Weg. Sie legen "offenen" DLL die zum System gehören in ein Ordner wo keiner was drin zu suchen hat. Die DLL die zu einer Software gehören müssen in das Verzeichnis der Software. Das führt zu mehr Speicherverbrauch aber viel stabileren Software. Selbst wenn du gewisse DLL dann halt x-mal drauf hast. DLL = alles was man als API verwenden kann. Davon abgesehen: Wenn ich Funktionen einer API aufrufe dann NIEMALS !!!! direkt sondern immer in einer eigenen Funktion / Sub . Der Grund ist einfach. Wenn der Hersteller der DLL einen Aufruf ändert (Variablen Typ austauscht) habe ich die Popokarte und müsste Tagelang mein Prg ändern. So ändere ich nur die Funktion/Sub und das war's. ;)
Geil!! In ne extra Funktion den Auftruf einbinden ne geile Idee! Im Windows würd ich die DLL sowiso dynamisch einbinden. da hat man dann auch noch die Chance, durch die notwendigen Zeiger kryptische DLL-Routinennamen gleich vernünftig umzubenennen. Und wenn dann mein Lieferprogramm dann befiehlt: "Liefer bitte mit Heli!" dann wird die richtige DLL geladen, genau bei : "Liefere mit Fahhrad!" dann wird als Transportschicht halt die Fahrrad-DLL geladen. mfg
~Mercedes~ . schrieb: > Im Windows würd ich die DLL sowiso dynamisch einbinden. > da hat man dann auch noch die Chance, durch die notwendigen Zeiger > kryptische DLL-Routinennamen gleich vernünftig umzubenennen. Was am Anfang der Hauptgrund für mich war. Also dann aber MS mal den Typ einer zur übergebenen Variabel von Integer auf Double änderte und ich das nur in der Funktion ändern musste, war ich sehr glücklich über meine Idee.
Noch besser wäre ne Klasse zur DLL-Verwaltung. Zumindest in C++. Dann hätte man den ganzen Kram an zentraler Stelle. Und man könnte ne Menge automaich machen lassen. Ob es sowas schon gibt? mfg
~Mercedes~ . schrieb: > Ob es sowas schon gibt? Keine Ahnung. Ich schreibe fast nur unter Visual-Basic für Windows und auf diesen basierenden Sprachen wie z.b. B4x, für Android + Raspberry / Arduino. Wäre aber für die C-Leute keine schlechte Idee.
Hmmm. ;-P In C++ wirds ja so gemacht: Library laden Wenn geladen die von der DLL exportierten Subs Zeigern zuweisen Die Subs über die Zeiger aufrufen. ... Wenn man fertig ist, Zeiger auf NULL setzen, Library entladen. Wie sieht es in VB aus? mfg
~Mercedes~ . schrieb: > Wie sieht es in VB aus? Da muss man die im Projekt via Projektmanager einbinden. Und im Projekt-Code pro Form einfach #include "name_der_workgroup" machen. Es geht auch zur Laufzeit, habe ich aber selbst nie gemacht. Hier mal ein Link zu einen Forum wo das einer mal gemacht hat. Im Prinzip auch über einen Klasse. https://www.vb-paradise.de/index.php/Thread/120770-Problem-mit-DLL-zur-Laufzeit-laden/ Wenn man das innerhalb einer Form macht und nicht in der Global.bas dann kann man die Form bequem in andere Projekte einbinden. Ich habe irgendwann mal beschlossen mir eine eigene DLL zu schreiben (Was kinderleicht war, wenn man VB selbst coden kann). Da sind meine Standard-Aufrufe und Funktionen drin, und 2 Aufrufe mit Fenster weil mir die offz. Msg-Box für richtige Anfragen zu mickrig war, und nur feste Button-Texte hatte. Die binde ich in jede Anwendung ein, und spare mir viel Code. Der Trick ist, die ist in einen anderen Verzeichnis und wird immer in im Setup-Programm in der neusten Version zu gemischt. Klar wird die Größer aber Speicherplatz auf der Platte interessiert mich schon seit langen nicht mehr wirklich. Die neuste Funktion ist übrigens : sin_grad = my_dll.Winkel_in_grad(Sin(winkel_wert)) Hat mich 3 Stunden Nerven gekostet bis ich raus gefunden habe,das MS in der Math-Libary nur Sin in Radius berechnet. Und damit ich nicht jedes mal die Umrechnungsformel suchen muss, gibt halt eine DLL-Funktion dafür von mir.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.