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

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ß