Hallo, hier aus dem Thread "Opensource 2-Draht Hausbus" ausgegliedert
eine Projektankündigung mit Bitte um Mithilfe:
>
> Es gibt ja nun Protokolle auf verschiedene Ebenen. Bitaustausch und
> Timings finden auf unterster Ebene statt und werden sozusagen mit dem
> physikalischen Medium zusammen ausgetauscht. Das interessante sind deine
> Protokolle höherer Ebenen und DIE sollten allgemein sein. Und natürlich
> solltest du erst mal ein solches Schichtenkonzept vorsehen. Wer alles in
> einer Schicht abhandelt und bei jeglichen abstrakteren Aufgaben, gleich
> wieder auf das letzte Bit achten muss, der macht ein extrem
> festgezurrtes, nicht erweiterbare und schlecht wartbares Protokoll.
Ja, und das ist auch genau mein Ansatz - ich werde die Spezifikation
sehr streng nach dem Modell ISO/OSI trennen, bei layer 2 anfangen (der
weder von irgendeiner Physik unterhalb noch irgendwelchen konkreten
Anwendungen oberhalb abhängt). Dort wird das framing definiert sowie ein
Framegenerator und ein Frameparser implementiert. Layer 3 (Adressierung)
wird angesprochen, aber ausser der Vorgabe, wie ein Knoten in einem Bus
angesprochen wird, nicht spezifiziert (also Adressvergabe,
KOnfliktarbitrierung etc nicht festgenagelt). Dann folgt Sequenzierung
und das Format der Nutzdaten (immer noch losgelöst von konkreten
Anwendungsfeldern), und später folgen dann Anwendungsprofile (also z.B.
Home Automation, Sensorik, Alarmanlagen, ZK etc), wobei ich selber mich
aus naheliegenden Gründen auf die Bereiche beschränke, in denen ich
eigene Erfahrungen habe.
Aus dieser Strategie folgt zwingend, dass keinerlei Timingvorgaben an
sich im Protokoll spezifiziert sind; das Protokoll muss es nur leisten,
möglichst vielen (von der Physik, der Netzwerktopologie und der
Anwendung gegebenen Vorgaben gerecht werden zu können.
Über weitere Gedanken und Input (sowohl hier im VOrfeld als auch später
bei der Basisspec und konkreten Spezifikation von Applikationsprofilen)
freue ich mich sehr!
@Mods: Diesen Post bitte nicht verschieben!
