In der Hoffung das Frank weiterhin mit liest.

Könnten wir im Download bereich eine Ordner haben ?
Ich würde mein SMIRS zeug gerne mal hoch laden aber mein HP
ist ein HP bei T-online privat page und da reicht werde Traffing noch Platz
auf die Dauer.

Zu rück zum Thema ich würde auch gerne ein alpha im plemetierung machen da wird es einfach leichter. Ich muß so was sehen / Programmieren dann wir es für mich einfach leichter und vor allem kann man mal messungen machen wie lange was wirklich dauert.

Desweiteren würde ich den Thread gerne Trennen aber wenn wann dann mehr lesen muß Application layer und Protokoll layer oder wir gewönnen uns an es Obentrüber zu schreiben um was es gerade geht. Bitte diesen Post nicht falsch verstehen es ist nicht mein Thread und es sind nur vorschläge.

Zur alpha im Plementierung:
Von mir kommt immer nur windows software (win2000) und wenn AVR dann c software.

Jeder der was für das Projekt programmier muß sich im klaren sein das sich das protokoll morgen komplett ändert bist die Defintion mal steht.

Zu Protolllayer:

Ich habe noch mal drüber nach gedacht und ein paar änderungs vorschläge.
ID's / Adresse sind vor erst mal per hand zu vergeben. das Dynamisch ver geben von ID's ist ein Option die wir erst später realiesieren. Also im source vorsehen aber zur Zeit würde uns das nur auf halten und wir haben genung andere Probs zu lösen.

Ich würde gerne das Protokoll teilen AVR Welt und PC Welt um es den PC Programierern einfachen zu machen und das Protoll notfalls auch lesen zu können. Zweiter vorteil man würde sich mit den 0 Bytes als C++ Programierer nicht so um bringen (Stringklassen). Aber auch Delphi oder VB hat glaube ich so ihr probs mit 0 Bytes im string. Bei java weiß ich es nicht wirklich.

Wie soll es laufen:

Bild hier  

Angehängtes Bild betrachten und jetzt geht es los.

RNM Low sollte so was Byte Oritiertes sein damit der AVR sich nicht einen Abbricht und das RNM Hight sollte doch ziemlich Text oritiert sein damit man es schnell lernen kann und wir viele schöne Module bekommen.

In meinen Bild sieht mal schon das wir dann beide Welten haben und man beides nutzen kann. die MC könnte erst mal so weiter leben und und die Eine änderung sollte sich realtiv schnell ein bauen lassen.

auf der LOW seite würde ich gerne das
RNM HEADER
<00><00> SOURCE
<FF><FF> DESTINATION
<00><00> resposnummer
<00><00> Action
<00><00> DataLen

Verwenden denn ich denke das geht schon in die richtige richtung.
Ich stelle mir die Frage warum wenn ich Über die RS232 an den AVR gehe den Dahinterliegen AVR von dem Motor Controller zum beispiel wirklich direckt er reichen muß. In meinen Augen eigendlich nicht. Wenn ich mehr als ein gerät direckt erreich will / muß baue ich den I²C bus dann habe ich da keine Probs die meinsten RN Borad können den Ja. Im PC I²C Adapter würde ich dann per Ini oder regestry ein Übersetzung tabelle von Name auf ID's Führen.

Wenn wir den Proxy weg lassen und dafür Feste befehle bauen wird das ganz nicht so komplex und wird erreichen schneller was verwendbares.

Um das was ich mein zu verdeutlichen:
RNM HEADER
<00><34> SOURCE
<00><99> DESTINATION
<00><54> resposnummer
<00><99> Action
<00><03> DataLen
<00><01> DataByte
<00><01> DataByte
<00><50> DataByte

Hier schickt das RS232 Modul (ID 34) and den AVR (ID 99) den Befehl 99 (Stellemotor leistung) des Motor's 1 in Richtung 1 (Vorwärts) auf 50 %.

Ob jetzt der PWM Generator auf dem AVR sitzt oder der AVR einem Andere AVR was mit teilt ist ja eineglich egal und das kann jeder mache wir er will.
Hat er eine RN Motorcontroller würde er das Selbe Telegramm ein fach über den I2C bus jagen und das Tut. Ok dafür muß man den Robi ein bisschen in logische Teile auf teilen aber ein standart ist immer auch ein Kompromiss.

Wie kommt jetzt der Navigator an den AVR, Ich gehe davon aus das der Navigator ein PC Programm ist, ganz einfach über die Multicast Adresse.

er jagt ein Telegramm raus das so aussieht (ist nur ein beispiel bin für vorschläge offen) <byte><byte><RNM><ADRESSE AD='RS232'><RESPOS ID = '54'/><ACTION ID = '99'/><DATALEN Value = '3'/><DATA01 Value='1'><DATA02 Value='1'><DATA03 Value='50'></ADRESSE></RNM>

Die Zwei Byt am anfang um bei Wlan sicher zu stellen das das Telegramm voll ständig war. nach dem an es nun hat und die ersten zwei byte's abschneidet sollte man es ein XML Parser zu fressen geben können wenn ich XML richtig verstanden habe. So hat man beides ein Telegramm was einem beim Coden auf dem AVR nich um bringt wo man auch ein klassen / lib für machen kann und ein PC Telegramm was man relativ gut lesen kann aber von prinzip sind sie gleich. Für die Fraktion die sich nicht mit dem Protokoll layer rum ändern wollen wurde ich ein dll machen die ein Com Objekt ist die der man nur die Multicast adresse gibt und die Einge adresse und dann kommen Event's wenn für einen was neues da ist dort Kann man dann mit Metoden die Aktion und die daten abfragen. So das einem das Protokoll egal sein kann. UlrichC mach bestimmt auch ein .so file für die Linux Jungs unter uns.

Was haltet Ihr von meiner Idee ? Ok ich habe mich sehr weit vor gewagt aber so kann ich mir das einfach besser Vorstellen. Achso auch ein simirs Client kommt natürlich an das Mutlicast es gibt ja den befehl Transfer damit kommt das Modul dann an die Multicast geschichte. Und die MC hat eine Adresse auf der Multicast seite.

Wenn wir uns auf den Nachrichtenauf bau einigen können könnte man anfangen die Action zu definieren. Das währe dann Applications layer 1.

Gruß
PS: ich hoffe es ist einiger massen zu verstehen

Schade ich darf keine Bilder mehr hoch laden sagt das forum zu mir
Deshalb habe ich das mal als link ein gefügtmal sehen wann die Telekom mir aufs dacht steigt.