Was genau ist ein Stack? Ich höre es immer wieder, habe auch schon viel gelesen, kann mir aber trotzdem nichts darunter wirklich vorstellen. Z.B. ein CAN-Stack. Wenn ich das richtig verstanden habe, ist ein CAN-STack quasi nur Software (also Hardware unabhängig), eine art API. Man sagt z.B. CAN_INIT(PRIO, NAME) und der stack initialisiert dann den CAN (setzt Baudrate, setzt die IDs). Sendet, empängt NAchrichten, Fehlerauswertung usw.. Aber was ist dann der Unterschied zu einer lib? Also ich könnte ja auch die Funktionen in einer Lib packen und hätte quasi das selbe. Gleiches gilt ja auch für Bluetooth-Stack und weitere.
"Stack" heißen die Teile wohl deshalb, weil sich da in der Regel auch in der Software das ISO-Schichten-Modell einigermaßen abbildet, d.h. du hast eine Applikation, die ruft die Netzwerkschicht, die wiederum ruft die Transportschicht etc. In der Praxis verschmelzen da oft einige Teile, aber eine gewisse Schichtung ist in der Regel dennoch erkennbar.
Jörg W. schrieb: > In der Praxis verschmelzen da oft einige Teile, aber eine gewisse > Schichtung ist in der Regel dennoch erkennbar. Dann kann man sich das doch so ähnlich wie eine library vorstellen? In dieser sind dann noch mal schichten, bis zum versenden der NAchricht (beispeil vom CAN)
Jens schrieb: > Dann kann man sich das doch so ähnlich wie eine library vorstellen? Du vegleichst da Äpfel mit Gewässern. Libraries sind Sammlungen von Funktionen, die man in Programme einbindet. Das hat mit Stacks (aufeinander gestapelte Ebenen der Software-Architektur) gar nichts zu tun. Außer das Libraries Stacks und Ebenen enthalten können - aber eben nicht müssen. So wie man Äpfel in Gewässer werfen kann, muss man aber nicht.
Stefan ⛄ F. schrieb: > Du vegleichst da Äpfel mit Gewässern. Ja mir fällt es auch extrem schwer sich etwas darunter vorzustellen.
Nicht jede Bibliothek enthält einen Protokollstack. Nicht jeder Protokollstack ist in Form einer Bibliothek aufgebaut. Es gibt Bibliotheken, die vollständige Protokollstacks enthalten. Es gibt Bibliotheken, die Teile eines Protokollstacks enthalten. Protokollstacks können ganz oder teilweise in Form von Software(-bibliotheken) implementiert sein. Protokollstacks können aber auch ganz oder teilweise in Form von Hardware oder programmierbarer Logik implementiert sein. Entgegen vielfältiger Darstellungen müssen Protokollstacks nicht dem OSI-Schichtenmodell entsprechen bzw. durch dieses darstellbar sein. Es handelt sich eben um komplett unterschiedliche Betrachtungsweisen.
Jens schrieb: > Dann kann man sich das doch so ähnlich wie eine library vorstellen? So wie man heute Librarys definiert (denke da ans Arduino Umfeld), würde die Library einen CAN Stack enthalten. Du rufst nur noch Init(); Send(xyz); auf, der Rest passiert unter der Haube. Dein Programm hätte dann einen CAN Stack, von dem du aber nix mitbekommst oder irgendwie in eine Zwischenschicht eingreifen könntest. Etwas anders wäre das, wenn du den Stack selber baust. Also eine "Library" für das Hardware Interface an einen Puffer flanschen, da dann irgendein Protokoll drüber bauen, Fehlerbehandlung durchreichen, ...
Andreas S. schrieb: > Nicht jede Bibliothek enthält einen Protokollstack. > > Nicht jeder Protokollstack ist in Form einer Bibliothek aufgebaut. > > Es gibt Bibliotheken, die vollständige Protokollstacks enthalten. Es > gibt Bibliotheken, die Teile eines Protokollstacks enthalten. > > Protokollstacks können ganz oder teilweise in Form von > Software(-bibliotheken) implementiert sein. Protokollstacks können aber > auch ganz oder teilweise in Form von Hardware oder programmierbarer > Logik implementiert sein. > > Entgegen vielfältiger Darstellungen müssen Protokollstacks nicht dem > OSI-Schichtenmodell entsprechen bzw. durch dieses darstellbar sein. > > Es handelt sich eben um komplett unterschiedliche Betrachtungsweisen. Also ein Stack kann demnach auch unterschiedlich sein. (Das macht die ganze sache nicht einfacher). Aber z.B. die Implementierung eines Handshakes, Fehlerbehandlung, allgemein senden/empfangen kann durch ein Stack erstellt werden, was auch nciht in der Applikation aufgerufen werden kann. Dort wird nur z.B. sendeDaten() aufgerufen. Und der STack kümmert sich darum, dass alles richtig abläuft. Heißt auch, dass die Applikation nach sendeDaten() normal weiterlaufen kann (wenn so implementiert) und der Stack dann sendet und überprüft ob gesendet worden ist wenn der bus frei ist
Andreas S. schrieb: > Entgegen vielfältiger Darstellungen müssen Protokollstacks nicht dem > OSI-Schichtenmodell entsprechen Das OSI-Modell ist ja auch nur ein Modell, welches die grundlegende Schichtung in der Kommunikation zu abstrahieren versucht. Es ist kein Dogma. ;-)
Jens schrieb: > Andreas S. schrieb: >> Es handelt sich eben um komplett unterschiedliche Betrachtungsweisen. > Also ein Stack kann demnach auch unterschiedlich sein. (Das macht die > ganze sache nicht einfacher). Das Problem ist, daß du zwei verschiedene Sichtweisen durcheinander wirfst. Stack nennt man es, wenn man die logische Abstraktion in verschiedene Schichten (Layer) hervorheben möchte. Das OSI Modell kann man beispielhaft dafür ansehen, was für Schichten es geben könnte. Aus Sicht des Anwendungsprogramms sind aber alle Schichten unterhalb der Anwendungsschicht ohnehin unsichtbar. Die Dienste und Funktionen der Anwendungsschicht stellt dann irgendein API bereit, für C typischerweise in Form einer C Library, die Funktionen und Datentypen definiert und implementiert. Die tieferen Schichten des Stacks können Software sein oder Hardware, Und wenn es Software ist, kann die in der gleichen Library stecken oder in einer anderen. Oder vielleicht auch in einem Betriebssystem. Oder in der ROM-Firmware des Controllers. Aus Sicht der Anwendung (und des Anwendungsprogrammierers) sind das unwichtige Details. Wichtig ist nur, daß alle Schichten des Stacks da sein müssen. Was die Idee eines Stacks so sexy macht ist, daß man bei geeigneter Unterteilung die einzelnen Schichten komplett unabhängig voneinander implementieren und auch austauschen kann. Man kann bspw. den ganzen Teil des CAN-Stacks oberhalb der Hardware (OSI Schicht 3 aufwärts) unabhängig vom µC implementieren. Oder man könnte den Teil unterhalb austauschen und statt eines physischen CAN Interface die Nachrichten in RAM-Puffern hin und her kopieren und so zwei Prozesse auf dem gleichen Rechner so miteinander kommunizieren lassen, als würden sie im CAN Netzwerk verteilt laufen.
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.