Hallo,
ich kann die Finger nicht raushalten.
Aber spezifizieren mag ich nun nicht...

Ich wollte nur mal einen Ansatz bzw. ein Punkt wo die Meinungen vielleicht noch Auseinanderlaufen untermalen
Und zwar ...
Zitat Zitat von PicNick
Ich halte es nämlich auch für wichtig, eine ZUMUTBARE Library dafür zu entwerfen. Wenn der µC nämlich nix anderes mehr kann als netzwerken, setzt sich das Ganze niemals durch.
Ja das sollte auf jeden Fall auch das Ziel sein und zwar an beiden Enden des Systems.

Und hierbei möchte ich noch zus. Intensionen loswerden.
Eine Kapselung des Protokolls in eine verständliche bis einfache Schnittstelle für den Verwender.
Jedenfalls habe ich die Fahne auf der PC-Seite des Systems hierfür auch schon gehalten.
..und das nicht aus Einfachheits- bis Faulheits- gründen...sondern
Eine Programmierschnittstelle (+Spezifikation) verbaut in einer Bibliothek (Lib) ist sozusagen die Lebensversicherung des Systems.
Das Protokoll + API selbst kann sich dann *ändern wenn es notwendig wird.
Der Verwender des Systems sollte einfach durch kompilieren seines Codes mit der "dann neuen Lib" Standardkonform bleiben ohne eigenen Code ändern zu müssen.

Jedenfalls ist man das als Programmierer/Anwender so gewohnt.
Falls sich wirklich Anwender für einen eventuellen *Standard finden sollten dann sollten diese über alle Versionen erhalten bleiben.
Ich würde als Normal-Modul-Programmierer (nicht API Schreiber) wahre Freudensprünge im Dreieck machen,
wenn ich alles wegen eines Denkfehlers oder einer Erweiterung die eine Änderung des Protokolls zu Folge hatten,
die Kommunikation umtexten müsste.

Diese Schnittstellenfunktionen werden so oder so geschrieben ... nur wenn die nicht in der Lib zur API liegen muß diese jeder für sich anpassen.
In einem Fall wären es [Support "+Punkte"] im anderen [Standard "-Punkte"].

*Änderungen ... gibt’s oft:
... neue Features neue Bugs *isKlar* Workarounds
... andre Encodings (Vielleicht wird mein Unicode nun doch anders Interpretiert)
... mehr Funktionalität (Vielleicht wird alles aufgebohrt ... und man muss explizit den verwendeten Standard im Protokoll mitschicken... um gewohnt verfahren zu können)
... anderes Handling des Protokolls (Vielleicht müssen Commands vorgeschoben oder bestätigt werden)
... schnellere Reglungen (vielleicht ändert sich die Kommunikation grundlegend um Connects/Syncs zu sparen)
... obsolet Commands (manche zuerst als sinnvoll erscheinenden Funktionen des Protokolls werden ersetz / oder erweisen sich als unsicher)
... mehr Sicherheit (vielleicht läuft in naher Zukunft alles Verschlüsselt durch die Leitung)
... weitere Interfaces (feileicht müssen die Adressräume geändert werden weil die vorgesehenen 2 Byte doch nicht reichen)
etc.

*Standard wird nur verwendet wenn es Vorteile bringt.. Vorteile sind verschieden geartet
... Kompatible Zusatzsoftware
... Zeit/Kostenersparnis
... KnowHow-Gewinn
... Funktionsgewinn
etc.

Ist schon wieder ein Roman geworden... *sorry*

Netter Gruß,
Chris