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

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ß

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)

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

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ß

Zitat:

---

Zitat von PicNick

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

---

Dann lasst es uns doch so machen ?

Zitat:

---

Zitat von wikipedia

... 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.

---

@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.

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)

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)

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

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:

Zitat:

---

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.

---

Hallo Ragnar,
hier mal meine Ausführungen zu Deinen Fragen.

Frage 1
Eine übertragene Länge macht in höhere Schichten weniger Probleme als Framen
Beim Framen fühlt man sich als Programmierer in alte Zeiten versetzt und muß mit Timeouts auf Daten warten die vielleicht noch kommen werden (oder auch nicht.. mit Überraschungseffekt)
Man muß je nach dem für Speicher (Buffer) sorgen (alockieren und resizen wie bekloppt) ... nene
Lieber eine Lenght zu begin und ein Frame bzw. Endflag.
So merkt man den Müll in der Leitung besser solange es hierführ noch keine expliziten Checks (Checksumme etc.) gibt.
So ne art zweite Sicherung des Pakets
(Datenpacketlänge richtig kein Endzeichen ... Müll dabei)
(Datenpacketlänge zu kurz/ zu lang + Endzeichen ... wieder Müll)
(Datenpacketlänge richtig + Endzeichen ... könnte passen)
(Endzeichen fehlt ... Leitungsprobleme)
Das Endzeichen könnte hierbei auch eine Checksumme sein. So ne Art ECC für Datenpackete. (Kann auch unter ISBN-Checksumme nachgelesen werden)

Frage 2
Generel klingt 128 Byte ganz ordentlich... und könnte vielleicht sogar ausreichend sein. Als max. Paketgröße (right?)

Wie ist das eigentlich mit den Buffern ausgegeangen?
Auch hoffe ich immernoch auf schnelle Bilddaten.
d.H die Untere Ebene kann sich an diese 128 halten. Beim nächsten Layer aber bitte mehr Saft... Buffering etc.
(für verwöhnte programmierer )

Frage 3
Wie wärs mit regexp oder ähnlich:
A = Irgendein Ctrl char
\A = A
\\\A = \A
...ist etwas einfacher zu verstehen.

Frage 4
Das Protokoll zur Anmeldung sollte meiner Meinung auch erst beim SW-Entwurf dabei sein.
Bislang kann man noch nicht sagen welche Infos ausgetauscht werden müßen.

(An dieser Stelle würde ich auch die Byteorder einflicken, denn im Layer 4 ist es zu spät!
Das Layer 4 bedient sich aus Daten der unteren Layer... wenn die Unteren Layer dann nichts zur ByteOrder verraten, kann es von Layer 4 auch nicht gerochen werden. )
Ok man könnte es explizit zuweisen/konfigurieren usw. aber der ganze Konfigurationskram ist ziemlich Erklärungsbedürftig und pflegeintensiv.
Und wie uC <-> uC damit klar kommen soll würde dann auch ein Rätzel bleiben.

Netter Gruß @all
Chris

EDIT: Man sollte Nachts schlafen und nicht über geschriebenen Käse senieren ;-)

@ragnar wenn ich auf die Uhr klicke dann wird die Benachrichtung ab geschaltet ich schalte sie mal ab und wieder an mal sehen vielleicht klappt es dann wieder ist echt doof wenn man dauert gucken muß.

@Alle die Zeichen für das Framing sind mir egal sucht euch was aus.
Mir ist nur wichtig das wir mal level 1 hin bekommen damit wir weiter
machen können. Wie ich schon geschrieben habe möchte ich gerne bassiert auf diesem Protokoll meinen Roboter machen. Nachdem prinzip ich nutze auch das was ich verbrochen habe. So findet man Probleme schneller.

Ich halte mal folgendes Fest:

Wir machen Frameing
Daten die Frameing zeichen enthalten werden ein Escape zeichen vorran gestellt.
Längen Information währe schon aber ist auf dem AVR schwierig.
Es gibt eine Protokoll aushaldungs Phase am anfang.

Ich sehe mit dem Little/Big Endian Problem das sehe ich auch nicht in der schicht 1 den ich muß eh wissen von wem bzw. was es für ein tegram ist damit ich es decodieren kann damit ist auch dann die Übertragung von lsb/msb geregelt.

Gruß

Einwurf: Das mit der Network-Order ist solange eine Sache der oberen Fuzzies, solange wir da unten eh nur Bytes handeln. Gibt es aber Bestandteile , die mehr als 8 Bits haben (Adressen) müssen wir uns darum kümmern, bzw. eben einfach festlegen.
Das mit der Länge ist praktisch, wenn man beim Empfang einfach sagen könnte, in den nächsten x-Bytes kann kein Steuerzeichen sein.
ABER grad beim µC wird es vorkommen, daß er dieses oder jenes Zeichen einfach nicht mitkriegt. Es muß also trotzdem aufpassen, ob nicht mitten in seinem Frame vielleicht doch ein neues Frame beginnt.
D.h. IMHO, drüber gelegt muß auf jeden Fall eine STX /ETX Kontrolle sein. Ein Längenbyte könnt' aber durchaus das BCC ersetzen, da ja Länge & ETX zusammenpassen müssen.
Ein Länge vorne würde aber a priori einen Frame-build on-the-fly unmöglich machen.
Paketlänge: Die Zeit ist u berücksichtigen. Bei 9600 brauch er für hundert Byte ~0.1 SEKUNDEN. Das ist lange genug, wenn zwischendurch ein Alert auftritt.
Denkt an die Möglichkeit Flag:MORE, d.h. es wird gesagt, daß die Daten des nächsten Pakets zu diesem bei gleicher Adresse dazugehören. Das macht ja IP auch so.
Und für Bildbearbeitung ist UART sowieso eher sub-optimal.
Also eine Restriktion auf Framesize 127 scheint sinnvoll und eigentlich zumutbar.
Ein Atmega32 kann damit in 16 Frames seinen kompletten SRAM schicken. (samt dem Stack)

EDIT: DIe maximale Framesize ist aber typischerweise eines der Dinge, die bei den Negotiations auszuhandeln sind

@Marvin42: Da du ja meine Unit-Geschichte schon kennst, wärst du ein gutes Versuchs-Meerschweinchen für mich: (ist aber keiner ausgeschlossen)
Ich hab eine Bascom - LBX für die Netzwerk-Grundfunktionen gemacht (Beta natürlich)
Das beispiel tickert am Teminal nur sinnlos vor sich hin, aber man kann über die Tastatur sozusagen "Frames" eingeben, die an eines der Units adressiert werden können.
Das Proto-type Frame (muß man ohne Echo blind eingeben)
STX = "C"
Destination
Class = "A"
Ident = 1, 2
Data
irgendwas , wird nur angezeigt.
ETX = <ENTER> (d'13')
Backlink adresse und Ack's gibt's im Moment mal nicht mal nicht.

Also (ist aber nicht case-sensitiv)
CA1muhkuh<ENTER> ---> Unit 1
CA2saubaer<ENTER> ---> Unit 2
CA9 ....<ENTER>----> Fehlertext
Weniger als 3 Zeichen --> Fehlertext

Vielleicht hast du ja Lust

http://195.128.164.40/RT_MUSIC/elect...nload/down.htm


PS: Irgendein stuffing gibt's derweil nicht, wie gesagt->Prototype

@PicNick:
Immer für was zu haben, mache mich nach Feierabend, wenn ich zu Hause bin gleich mal drüber.

Netter Gruß

@PicNick:
Habe ich gemacht wie mir aufgetragen. Lib ins Bascom Verzeichniss, sys.bas kompiliert und in den Mega32 übertragen. Terminal angeworfen und CA1,2 ;-) eingegeben.
Ich konnte jede Unit einzeln ansprechen ihr was von unterschiedlicher Länge übergeben was sie zurückgab und sie hat mir auch brav ihre Parameter runtergebetet.
Das Unit-System gefällt mir richtig gut. Kann ja sein das es für Dich ein alter Hut ist, weis ich nicht. Aber ich freu mich halt dran.
Das mit der Lib in Bascom ist ja damit wohl auch demonstriert.
Nach so einer Phase von Überlegungen hat es auch was Erfrischendes wenn man mal so ein Alphatierchen laufen lässt. Das hatte mir auch bei NumberFive 's Sachen gefallen wenn irgendwas ein Lebenszeichen von sich gibt.

Netter Gruß
aus dem GPRC-SST

Guinea Pig Research Center - Section Softwar Test

@UlrichC:
Vom Anmeldeprotokoll und der Protokollaushandlung darf die 4. Schicht
nichts mitbekommen. Der sind die physischen Medien erstmal total
egal. Ich denke hier auch erstmal an ein unterschiedliches Protokoll
für die Frameübertragung auf der 1. Schicht (für seriell). Dann muß
dieses Protokoll auch dort sein.

@PicNick:
Übertragung von beliebig langen Frames durch Stückelung ist relativ
aufwändig. Das würde ich lieber in Schicht 3 schieben bzw. eventuell
sogar in Schicht 4.

@PickNick:
Ad-Hoc Frameaufbau mit Länge ist nicht weiter schwierig. Deine
Anwendungsschicht weis ja genau, wie lange ihre Daten werden.
Dazu kommt noch die Headerlänge - fertig. Die übertragene Länge
ist ja die Länge der realen Daten, nicht die der escapted oder
gestufften Daten.

@UlrichC:
Die Anwendungsschicht weis die Länge ihrer Daten immer genau.
Die Details des Framings, Escapings, etc werden ja durch die
unteren Schichten versteckt.

Ragnar

Zitat:

---

Deine Anwendungsschicht weis ja genau, wie lange ihre Daten werden.

---

Nun, in vielen (meisten) Fällen wird das so sein. Aber wenn du dir einen Register- Vorgang vorstellst, kann da schon mal Text drin vorkommen, "SF08-Special Vers 1.24" (auch wenn man bei µC das wohl eher vermeiden wird)
AAAAber:
Der Receiver muß auf jeden Fall trotzdem immer mit-tracken, mit der Länge allein ist die Sache einfach nicht wasserdicht, also was soll's dann ?
Technisch ist dadurch die Länge auch nicht mehr eingeschränkt, wenn einer sein komplettes logging / Video-Zeile in einem Frame übermitteln will, dann soll er. Habe ich eine Längenangabe, muß ich mir auch schon überlegen, wieviel bit die hat.

Also ich bin für STX/ETX/PFX, Steuerzeichen A0-AF , vor dem ETX ein einfacher XOR-BCC.
Anders geht's natürlich immer, aber wenn ich mir das Gefummel in den anderen Layern vorstellen, daß ja noch ausständig ist, würde ich auf dem Layer-0 mal Redaktions-schluß machen. Da is nix zum gewinnen dabei.

@Marvin42x: Meer-(Spree-)Schweinchen : Danke für die Tests. Du hast ja gesehen, daß das Receive-Modul sehr anspruchslos ist. Ich werd das als Nächstes in der Library verschwinden lassen. Leider setzt das dann schon einen PC-Partner voraus, der da auch mitspielt. (Und mir graut ja so vor dem PC-Programmieren, *kotz*)
Ich hab gedacht, das Comm-Zeugs in eine DLL zu stopfen (*würg*). Ein Arbeitskollege (VB-Spezialist) hat mir versichert, es wäre kein Problem, sowas dann auch mit VB zu benutzen.
Andere Überlegung ist, einen Stand-alone Server (Background-Programm) zu machen, der unsere Frames einfach auf IP umsetzt. Diesen Server dann über IP anzuquatschen geht eigentlich mit jeder x-beliebigen Sprache, auch gemischt (und übers Home-Network).
So eine Server-Programm sollt' dann auch gleich Sniffermäßig fürs Tracing und logging zuständig sein, denn grad am Anfang unserer Entwicklung wird beim Testen ein genaues Protokoll, wer wann was in welcher reihenfolge gesendet hat, bitter notwendig sein.

@PicNick:
Ich sehe hier schon den von UlrichC heraufbeschworenen Applikationsserver am Horizont. Einen Stand-alone Server (Background-Programm) egal in welcher Ausprägung wäre zur Zeit meine Wahl.
Beispielsweise eine VB-GUI auf der Seriellen wäre nicht mein Ziel.
Eine VB-Lib könnte ja später mal eine gewünschte Ergänzung sein.
Also so rasch wie möglich TCP/IP
Und danach die Möglichkeit auch VB-Programme anzudocken.
Der Server müsste dann, wie du schon sagst, einige Fähigkeiten drauf haben.
Die erste Version davon könnte aber auch erstmal minimal sein.
Die Kommunikation Mikro-Mikro ist m.E.. Ein spezieller Fall der auf der Ebene der Protokollaushandelung gelöst werden sollte.

@All
Erstmal einen Redaktionsschluss auf Level 0 hat, meiner Schätzung nach, wohl im Moment die Stimmenmehrheit?
Ich bin für ja, obwohl ich weis das es noch eine Menge dazu zu sagen gäbe
Sagt mal was dazu.

Netter Gruß

Zitat:

---

Zitat von PicNick

Also ich bin für STX/ETX/PFX, Steuerzeichen A0-AF , vor dem ETX ein einfacher XOR-BCC.
Anders geht's natürlich immer, aber wenn ich mir das Gefummel in den anderen Layern vorstellen, daß ja noch ausständig ist, würde ich auf dem Layer-0 mal Redaktions-schluß machen. Da is nix zum gewinnen dabei.

---

Soll mir im Prinzip recht sein so, allerdings würde ich nur 8 Spezialbytes (3 Bit statt 4 Bit) definieren.
Das sollte immer noch dicke reichen. Meinst du mit PFX das Präfix für Datenbytes? Ist es für euch
okay, die gepräfixten Datenbytes um 5 nach oben versetzt zu übertragen ? Und schlussendlich:
meinst du mit XOR-BCC ein kontinuierliches XOR auf den ungepräfixten Datenstrom ?

Damit können wir Level 1 "seriell" denke ich schliessen und uns über Level 1 "Lan" bzw die höheren
Schichten gedanken machen.

BTW: Hat einer Lust unseren Konsens für Level 1 "seriell" irgendwo (z.B. im wiki) abzulegen ?

Ragnar

@PicNick,

wenn du willst mache ich die Dll oder besser ein exe server (Com) für windows
den mache aber dann in c++ wenn ich so weit kann ich dann exe oder dll hoch laden mit source dann kann die VB frakition mal probieren.

Was hälst du davon ?

Gruß

PFX: ist das Zeichen, mit dem das folgendes Zeichen als NICHT Steuerzeichen, also als Datenbyte, gekennzeichnet wird.
XOR: ja. ich mein', eben beginnend mit NULL, alle Zeichen ZWISCHEN STX und ETX (exklusive Prefixes) aufzu-xor-en.
Es gibt da ein Verfahren, wenn das result < 32 ist, was raufzuaddieren. Da muß ich noch nachdenken, was das bringt. Wenn es beim Verarbeiten keinen unnötige Arbeit macht, würde ich es anwenden, eben weil es schon wo so definiert ist. Und unbedingt neu muß unseres ja nicht sein.
@ragnar: Prefixte char + 5 . Kannst den Hintergedanken erläutern ? Welchen Vorzug bringt das ?
@No-5 : Da jetzt schon die Rede von VB und C++ und nochwas ist, ist ein komplettes EXE wahrscheinlich das Beste, mindestens für's Erste.
Ich bin noch nicht sicher, was genau für Eigenschaften gebraucht werden.
Aber ein Prototype muß ja nicht gleich alles können.
Gut wär ein Protokoll-write in ASCII-CSV Format, dann hat man gleich ein paar Auswertungsmöglichkeiten umsonst dazu.
Parallel dazu vielleicht ein Raw-dump-format zur speziellen Analyse von verstümmelten und falsch gestufften Messages (kann ja vorkommen, hab ich gehört)
IP-mäßiges Verhalten: Irgendwann müssen wir überlegen, wieweit der Zugroff mehrerer PC-Applikation reglementiert werden soll /muß. Datenreceive vom µC kann ja beliebig verteilt werden. Nur bei Commands wären Konflikte denkbar. Dann mußte man doch eine art login machen mit session und so.

Hallo PicNick,

klar ist das was ich da schreibe erst mal zu probieren ist mir schon klar.

Das Protokol file ist bei mir Standart das brauchst bei nicht erwähnen das mit den Dumps muß ich mir mal überlegen aber da fällt mir was ein.

Ich mach ein Exe comserver das ist glaube ich erstmal die Beste lösung mal sehen wie Zeit ist dann mache ich auch ein beispiel wie mal da dann per VB zu greifen kann. Und wenn ich ganz gut drauf bin haue ich das empfange noch per Multicast raus dann kann man sich das auch mal an gucken. wie sieht jetzt genau dein Protokoll aus der lib aus ?
ETX ....... STX ? Soll ich das mal so Implemetieren der Rest kommt ?

@all habe wir hier nur VB und C++ oder auch delphi oder noch was anderes ?

Ich denke wir sollten es erst mal auf Multicast belassen da brauchen wir kein login und die Sicherung kann dann auf protokoll ebene machen.
Ports und login und so was sind code massig immer so auf wändig und seid dem ich weiß wie schnell Muticast ist halte ich das für das bessere als Punkt zu punkt verbindungen. das mit den Ports und anmelden war immer sehr komplex anderen zu vermitteln.

So habe mal schnell ein exe zusammen gehauen die emfangen und senden kann im STX ETX Frame. max frame größe sind 127 Bytes incl. EXT und STX

Da ich nicht weiß wie lange ich heute noch mache und wie die Exe dann ist habe jetzt mal hier hoch geladen. Der Rest kommt dann immer wenn was fertig ist.

Der Source ist jetzt erstmal nicht dabei bei weil überhaupt nicht kommentiert einfach runter geschrieben.

Gruß

@PicNick: Warum <char> mit <prefix><char+5> übertragen ?
Weil dann dein Kontrollzeichen mit dem Wert von char absolut eindeutig
im Datenstrom ist. Das erleichtert einige Dinge, z.B. kannst du immer
gleich feststellen, ob es sich wirklich um ein Steuerzeichen handelt.
Empfängst du ohne diese Bedingung einen char, hängt die Bedeutung immer
davon ab, ob davor eine Escapesequenz war oder nicht. Funktionell
letztendlich gleich, aber IMHO etwas flexibler zu handlen (Steuerzeichen
können vor Escapes gecheckt werden).

@PickNick:
Was ist das mit dem draufaddieren ?

@NumberFive:
Mit welchen STX/ETX/PFX hast du programmiert?
3bit oder 4 bit?
Und was nützt uns eine .exe die wir nicht haben ;-)
Und schreib doch kommentierten Source, dann hilfts uns gleich viel mehr.

@NumberFive:
Ganz wichtig: die Framegrösse muss für die Schnittstelle nach oben
gelten, 127 Bytes gelten also für die reinen Daten, ohne STX, ETX, PFX.


Wie gehts weiter ?
Tja, ich habe gerade javax.comm gedownloaded und werde damit wohl mal
die Schicht 1 für seriell implementieren. Mein Programm wird wohl erstmal
ein kruder 'Tester', der regelmässig Testframes sendet und alle empfangenen
Testframes und Debuginformationen auf der Konsole anzeigt. Wäre natürlich
prima, wenn das gleich mit euren seriellen Schicht-1en zusammenspielt.

Dann brauchen wir beizeit eine Schicht 1 für IP. Ich könnte mir hier
irgendwas wie UDP-Kommunikation auf festgelegten Ports vorstellen, mit
Rechnern die sich gegenseitig discovern. Alternativ dazu auch die
einfache Variante mit vorkonfigurierten TCP/IP Streams. Auf jeden Fall
muß da in der unteren Schicht viel automatisch gehen, die oberen
Schichten sollen ja von Kommunikationsmedium nichts mitbekommen.
Meinetwegen können wir LAN aber auch gerne erstmal schieben.

Und irgendwann brauchen wir dann eine Schicht 2+3. Da habe ich schon ein
paar ausgefeilte Ideen, die ich dann zu gegebener Zeit präsentieren werde.
Um auf PicNicks Frage mit den 'Sessions' bzw 'Login' einzugehen werde ich
schon mal ganz kurz vorgreifen:

- Eine Session wird vom Absender festgelegt und ist für den Absender eindeutig
- Eindeutig ist das Tupel (SenderAddress, SessionSequence)
- Es gibt Nachrichten ohne Session
- Es gibt Nachrichten für initiale Sessions
- Es gibt Nachrichten für Session 'follow-ups'

Eine Session baut der Absender auf, indem er eine initiale Sessionnachricht
schickt. Je nach Bedarf/Protokoll kann der Empfänger auf diese Session
einmal oder mehrfach antworten. Wann eine Session geschlossen wird, entscheiden
beide Kommunikationspartner eigenständig. Damit sind einfache Challenge-Response
Nachrichten möglich (mit Timeout für den Response) oder auch Registriermechanismen
bzw. dauerhafte Datenströme (virtuelle Debug-Konsolen)

Zur Sicherheit, bzw. 'login':
Auf Schicht 1 für LAN können wir gerne einen Login implementieren, auf den
höheren Schichten höchstens eine 'Firewall'. Das würde ich aber beides
erstmal schieben.


Ragnar

@ragnar

vielleicht habe ich ja was falsch verstanden aber für mich ist STX = chr(02) und ETX =chr(03) aber jeweils 8 Bit lang sprich ein Byte. PFX ist noch nicht implementiert weil ich noch nicht gesehen habe das ihr euch einig wart wie.
Wenn ihr euch einigseid ist das schnell drin. Die erweiterung für 127 Bytes daten kommt heute im laufe des Tages ist nur eine zahl im source.
Hast du Icq oder so entwas ? das könnten wir das Netz zusammen machen.
Leider hast du auch keine Mail adresse hier so könnte ich dir das per Mail schicken.

Du hast recht die exe ist nicht da aber hoch geladen habe ich sie kann sein das frank sie nicht nicht freigeben hat. Ich glaube das muß er immer machen.

Bitte nicht Upd warum nicht Multicast ist in java auch ganz einfach. Mir flipen hier die Firwarewals und sonstige sicherheits programme aus.

@all hat jemand noch platz auf seine HP ? PicNick ?
ich würde dann dem die exe schicken immer wenn es was neues gibt.

Gruß

@ragnar: char+5 : Alterserscheinung, ich steh' auf dem Schlauch. :oops:
Das nach dem Prefix ist ja dadurch genau KEIN Steuerzeichen. Und warum ist <char+5> eindeutiger als <char> ?
Ich laß es noch sickern, braucht uns nicht aufzuhalten.

Ich hab dzt. implementiert
#define ctl_base 0xa8
#define ctl_pfx ctl_base + 1
#define ctl_stx ctl_base + 2
#define ctl_etx ctl_base + 3

if ( (mychar & ctl_base) == ctl_base) then prefix it.

Über andere konkrete Werte können wir aber noch stundenlang diskutieren, mir ist alles recht

Ich hab noch Platz, denk ich. Gezippt schicken, aber zumindest *.Bas, *.VBS und .EXE umbenennen, der Spam-u. Viren filter frißt sonst das Mail.

robert.toegel@wienerborse.at

Frage zur Protokollwahl UDP TCP: www. TCP Port :80
Das soll am Ende gehen.
Ist das jetzt schon für die Überlegungen relevant?
Netter Gruß

Also würde port 80 / 8080 und die anderen festgelegten nicht nehmen, da macht sich jeder Webserver im Netz ins Hemd. Außer natürlich, man sprich http drauf.
Ich mach eigentlich nur STREAM, weil das meiste schließlich einen Backlink braucht (commands). Und ich will ja wissen, wenn einer stirbt.
Login mit User und Password brauchen wir ja nicht unbedingt, first come, first served.

Ich sag, wir nehmen als (parametrisierbares) Port # 42 (default) . Darüber hinaus ist das ja eine Hausnummer.

@PicNick:
Dieses http auf Port 80, was ja auch kleine Home-Web-Fileserver machen, sehe ich mehr als einen Endzweig. Nicht als Basisprotokoll. Mir geht es darum uns den Weg nicht zu arg zu verbauen.
Netter Gruß

Wär sicher auch reizvoll, eine Webserver zu basteln, der das Robonetz mit http zur Verfügung stellt. Sollte eigentlich auch nur Arbeit sein.
Was ich auf jeden Fall möchte, ohne Widerspruch zu unseren übrigen Gedanken, letztlich eine Fix-Foxi Anwendung, zugeschnitten auf bestimmte Boards (RB-Control, RNBFRA) anbieten zu können.
Es ist nicht jeder ein begnadeter PC Programmierer.
(Und nicht jeder will es *würg*)

Ich weiß garnicht was ihr immer mit der PC Programmierung habt die ist so Easy *g*.

Ich würde von den Ports deutlich nach oben gehen. da unten ist zu viel reserviert. Für web braucht man eh ein zwischen modul drum ist hier der Port ja egal.

Aber UlrichC wollte ja das web Interface machen und ich denke das macht er auch.

Was ich dringen Bräuchte währe die sachen mit dem escape und mit der Prüfsumme wenn ihr es den so wollt.

Habe Picknick das zip geschickt.

Gruß

Zitat:

---

Habe Picknick das zip geschickt.

---

jetz (um 9:30) hab ich noch nix. Hast die alle *.EXE und *.VBS umbenannt ?
Sonst muß ich unsere System-Fuzzies quälen, die Mail zu suchen und wieder auszuschaufeln.

Port-belegung: Seit ich mir die Belegungsliste mal geholt habe, hab ich keine Illusionen mehr. Ich hab gedacht, die sind definiert bis 500. Haaa-Haaa.
Das muß man parametrisieren können.

kann es sein das zip's zerlegt werden ?

Bei uns zerlegt er nix. Wenn da was drin ist, was ihm nicht paßt, frißt er alles.

Vergíß es, ich hab die Mail's (2 ?) ausschaufeln lassen.
Ich schau jetzt, ob alles da is, und rühr' mich gleich wieder

als wenn das umbennen der exe auch nicht funktioniert wie soll ich es dir dann schicken ?

Ja es war zwei mail's aber mit gleichem inhalt.

Gruß

So, ich hab das reingestellt, am besten probier's mal selbst

http://www.oldformation.at/electronic/download/down.htm

@NumberFive
welchen COM Port öffnet der Server?, bei mir ist das unterschiedlich welche mir zur Verfügung stehen, auf dem einen Rechner com1 auf dem anderen com3. Hatte sogar schon mal das Problem com16 wegen diverser Bluetuts
Netter Gruß

Edit: Mitloggen tut er ja auch schon, habe ich glatt übersehen
Edit: Und ein Initfile erstellt er auch. Ich sollte mir doch ein bisschen mehr Zeit nehmen bevor ich was frage.