Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

[NumberFive]

wenn ich PicNick jetzt richtig verstehe Sieht er ein Problem wenn die länge im AVR codiert werden muß weil ich erstmal die nachricht zu sammen bauen muß damit er weis wie lang sie ist richtig ?

Also bleibt nur Frameing richtig ?

also doch wieder mein A und mein E ok das ist nicht schön aber das ist ja genau das.

So nun zu meinem Vorschlag:

Schicht 1:
ENQ chr(5)
<to define>
ETB = chr(23)
wenn 5 oder 23 oder FF in der nachricht ist muß ein FF vorran gestellt werden.

Das ist dann unters Level weiter runter gehts nicht.
Ok ist dem vorschlag von ragnar sehr änhlich nur eben anders rum
die Daten werden nur mehr wenn ich in den daten steuerbyte habe.

Währe das was auf das wir uns erstmal fest legen können und so die Schicht ein Beschliessen ?

Gruß

[PicNick]

Klingt mal nicht so schlecht.
Bei der Auswahl der Zeichen sollte man aber schon mal überlegen: Es sollten Zeichen sein, die möglichst selten als Datenbytes vorkommen. Das ist bei transparentan binärdaten schwer zu gewährleisten
ABER: Ein bißchen was weiß man schon:
32 - 127 ist das ASCII Bereich, dem sollte man ausweichen
< 32 wird häufig in binärzahlen auftreten, FF ist bei negativen binärzahlen sogar SEHR häufig (denk dir ein 32-Bit Long mit dem Wert -1, das sind gleich 4 stück drin)
Am ehesten wohl Zeichen 128 - 175, das sind Muster, die nicht gar so zwangsläufig vorkommen.
Mögliche Steuerzeichen:
STX Framestart
ETX Frameend
PFX Prefix
Wenn Kontrollsumme, dann 8-Bit BCS mit einfachem XOR (exclusive Prefixes und STX/ETX)
Wenn wir sowas als Basis-Form festlegen, die jedes Level-0 Modul können muß, haben wir auch die Möglichkeit, auf diesem Level zu Beginn Negotiation-Messages auszutauschen ( a la TELNET) und damit Kommunikations-Varianten auszuhandeln.
Wenn es wer nicht weiß: Zu Beginn schickt einer eine Message mit der Protokoll-description, die er gerne anwenden würde. Darauf schickt der andere die Variante zurück, die er auch erfüllen kann (sozusagen der Mengendurchschnitt).
Dann geht's auf diese Art eben weiter.

Hat den Vorteil, daß man nicht irgendwas auf ewig in Stein meißeln muß, was uns später aus irgendeinem Grund dann auf den Senkel geht.


(Alte Designer-Weisheit: Keine Standard-entwicklung ohne gleich ein Escape festzulegen)

[PicNick]

Ach ja: Ich würde noch festlegen, daß immer der µC der ist, der sie Verbindung aufbaut (der wird wohl auch öfter auf- und abgedreht werden)
D.h. der PC spielt immer den Host

[marvin42x]

Für mich sieht das gut aus. Die letzten Ergänzungen von PicNick halte ich für sehr sinnvoll.
Das macht auf mich einen tragfähigen Eindruck.
Netter Gruß

[Vogon]

... die möglichst selten als Datenbytes vorkommen.

Dann lasst es uns doch so machen ?

... SLIP geht den einfachstmöglichen Weg einer solchen Verbindung, indem einfach die Oktets eines IP-Pakets über das serielle Kabel gesendet werden. Das Ende des Pakets wird mit dem speziellen END-Zeichen Nr. 192 (Oktalcode 300) gekennzeichnet. Falls dieses Zeichen innerhalb des zu sendenden Pakets auftritt, wird stattdessen die Sequenz 219/220 (Oktal 333+334) und für das Zeichen Nr. 219 selbst die Sequenz 219/221 (Oktal 333+335) übertragen. Das Zeichen Nr. 219 wird ESC-Zeichen genannt.

[PicNick]

@Vogon: jaja, alle stuffen ein bißchen anders. Es ist für einen µC aber ungünstig, bereits gespeicherte Zeichen rückwirkend zu ändern. Vermutlich wird der Bursche ja in eine Ringbuffer speichern, und da ist das ein unnötiges gewurstel, womöglich am Wrap-Point.
Ist ja klar:
du kriegst ein 0xDB oder 0xDC , kann ja sein, also speichest du und machst einen Pointer-advance (ev. mit Wrap) Kommt jetzt ein 0xDC und vorher war ein 0xDB, mußt du 0xDB auf 0xC0 ausbessern und wirfst 0xDC weg. wenn nicht, gelten beide
war vorher aber KEIN 0xDB, ist das 0xDC vielleicht der Prefix von 0xDD, das aber erst dann kommt oder auch nicht

detto für 0xDD : war ein 0xDC, wird es ein 0xDB und 0xdd fällt weg.

Diese ganzen (meisten) neueren Protokolle sind aus dem Hochmut entstanden, daß alles vorher alter Schwachsinn von senilen Deppen sein muß, also muß was Neues her.

[PicNick]

Noch ein Zusatz, betrifft nicht unbedingt Level-0:
Da wir ja nie direkt ins IP-Netz gehen, verzichten wir a priori auf die network-order bei >8Bit feldern. also immer im Intelformat (LSB-->MSB)
Floats immer im IEEE754 (?stimmt die Nummer), das ist das übliche PC-Format, etwas umständlich, aber verbreitet.
Frage an die älteren Herren: Wie ist denn das bei BCD ? Die sind ja MSB-->LSB , denk ich ? (is selten, hab' ich verdrängt). Was is denn da für ein Vorzeichen üblich ?

(Die Floats sin bei PIC's anders, deshalb der Hinweis)

[PicNick]

Heute hab' ich meine Plauder-Tag:
Bei der ganzen Stufferei gibt's noch die Möglichkeit, ganze Kontroll-Zeichen-Gruppen zu stuffen. Also z.B
Kontrollzeichen sind potentiell ALLE Zeichen 0xA0-0xAF
d.h. jedes Zeichen mit "A" im high-Nibble muß gestuffed werden.
Der Vorteil liegt (läge) darin: Beim Programm code kann muß man nicht einzeln mit STX, ETX und PFX vergleichen, sondern nur einmal das obere Nibble checken (am µC besser für die Performance)

[ragnar]

Frage 1: Framing oder Länge
Soll das Ende der Nachricht durch eine 'End of Frame' Kontrollzeichen
oder nach einer beim Beginn übertragenen Länge erkannt werden ? Meiner
Meinung nach total egal. In beiden Fällen kann die Nachricht dynamisch
und ohne puffern empfangen und gesendet werden (obwohl ich das nicht
empfehlen würde ...).

Mir persönlich gefällt der Framing-Ansatz besser.


Frage 2: Maximale Länge der Nachrichten
In beiden obigen Fällen (und bei uCs mit wenig Speicher sowieso) brauchen
wir eine maximal mögliche Nachrichtenlänge. Ich würde mal 128 Byte vorschlagen.


Frage 3: Codierung von Kontrollzeichen
Welche Möglichkeiten gibt es ?

Ein Kontrollzeichen mit Bytestuffing:
X => Kontrollzeichen, XX => Datenzeichen X
Problem: Nur Startzeichen kann eindeutig erkannt werden,
alle anderen Zeichen könnten mehrdeutig sein.

Escapezeichen für alles:
XY => Escapezeichen mit 'Parameterzeichen'
abhängig von Y ist XY entweder Daten- oder KOntrollzeichen
Immer eindeutig, aber Kontrollzeichen immer 2 Bytes lang.

Mischform:
A, B, C => direkte Kontrollzeichen
XY => Escapesequenz, entweder Daten (A, B, C oder Kontrollzeichen)
Genau ein Kontrollzeichen(Escapezeichen) zur Darstellung der
Datenbytes. Alle anderen Kontrollzeichen 1 Byte. Eindeutig.

Da wir im Vergleich zu den Steuerzeichen wohl eher kurze Nachrichten
haben fallen reine Escapezeichen wohl aus. Ich schlage deshalb die
Mischform vor. Ich glaube jetzt erstmal nicht, daß wir eine ganze
Gruppe an Kontrollzeichen definieren müssen, ist mir aber letztendlich
egal. In der Mischform ganz einfach (3 bit, 7 Kontrollzeichen, 1 Escapezeichen):
0xA0 - 0xA6 sind Kontrollzeichen
0xA7 ist ein Escapezeichen, vom nachfolgenden Datenbyte werden 0x08 abgezogen.
Datenbytes 0xA0 - 0XA7 werden als 0XA8 - 0XAF übertragen.

Am Anfang sollte eigentlich erstmal zwei Escapezeichen reichen:
0xA0=StartFrame und 0XA1=StopFrame.


Frage 4: Protokollinitiierung
Die Idee, das genaue Protokoll in einer Initiierungsphase festzulegen
finde ich eigentlich gut. Das ganze würde ich aber noch etwas schieben
bis wenigstens ein mögliches Protokoll implementiert ist. Dieses erste
Protokoll würde ich auch erstmal ganz einfach gestalten: ohne Handshake,
Acks, CRCs, bidirektional und ohne timeouts. Ausserdem würde ich bei
dem 'Handshake' nicht darauf vertrauen, daß es einen 'Slave' und einen
'Master' gibt, sondern beide können versuchen, die Verbindung aufzubauen.
Eventuell will ich ja auch mal zwei uCs oder zwei Rechner verbinden.


@NumberFive: Click unten auf die Uhr, dann wirst du wieder Benachrichtigt.

@PicNick: Little/Big Endian Probleme würde ich sie erstmal an den
Anwender (Schicht 4) weiterschieben. Dann können wir als Konvention
immer noch network order für große Zahlen verwenden.

ciao,
Ragnar

[Vogon]

Ich habe noch keine richtige Vorstellung zum Timeout.
Wenn Zeichen verlorengehen, bei einer IR oder Funkverbindung ist damit zu rechnen.
Das sollte die Übertragung aber nicht aus dem Tritt bringen.
Beim Wikipedia-lesen zu SLIP habe ich das gefunden:

Eine Modifikation des Protokolls sendet das END-Zeichen auch zu Beginn jedes Pakets. Dies macht die Übertragung robuster gegenüber geringem Leitungsrauschen zwischen den Paketen.