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

**Dirk** · 05.10.2006, 21:59

Leute, das interessiert mich jetzt, weil ich dem CoProzessor gerade ein paar Aufgaben beibringe:

Also, z.B. die Servos sind in der Rn-Server-Tabelle mit der bisher üblichen ID eingetragen, also (&H53 u. &H01 - &H0A). Natürlich im Zweig des CoProzessors (ID = &H52 / &H00), denn den Atmega32 geht das ja jetzt nix mehr an, der schickt nur weiter.
D.h. entweder ist also das Servo#1 systemweit eindeutig mit &H53/01 , dann brauche ich sonst nix, dann muß sich der Co einer zweiten RNBFRA eben mit den Servos#11-21 anmelden. (das würde ich bevorzugen)

ODER jeder Coprozessor hat Servos 1-10 , aber dann brauchen wir eine Angabe, welcher gemeint ist.

Da ich dabei bin, dem CoP als Slave weitere Augaben nahe zu bringen (es gibt ja diese schon: 10 Servos ansteuern, IR-RC5-Kommunikation,- weiteres ist in Arbeit), bin ich sehr daran interessiert, dass ein fertiger CoP in eurem System ansprechbar ist.

Warum ist das ein Problem mit dem Ansprechen von 2 CoPs bzw. deren Servos???

Man kann ihnen doch unterschiedliche I2C-Adressen geben, unter denen sie angesprochen werden können. Jeder würde als Slave bestimmte Aufgaben bekommen. Der Server würde also die I2C-Adressen kennen und braucht zusätzlich noch eine Kennung für die Art der Aufgabe (Aufgabe heißt hier z.B. "Ich bin ein CoP, der 10 Servos ansteuert = RNSI2C"). Mein Ziel wären noch weitere Aufgaben, so dass man eine Kennung bräuchte.
Identifizierung z.B.:
H68/1 ist ein CoP zur Ansteuerung von 10 Servos mit der Adresse H68.
H6A/2 ist ein CoP zur IR-Kommunikation mit Adresse H6A

Die 1 oder 2 legt fest, welche Aufgabe der CoP hat. Ein CoP mit 2 muss auf andere Weise angesprochen werden, als ein CoP mit 1 (Bei 2 z.B.: Lesen eines IR-Empfangspuffers oder Senden eines IR-Codes).

Oder habe ich da was nicht verstanden?

Grund meiner Frage:
Ich möchte weitere Anwendungen für den CoP schreiben, aber das natürlich so, dass ihr hier die Typen genau so gut einbauen könnt, wie den RNSI2C.

Sollte man da etwas vereinbaren? (oder liege ich voll neben der Spur???)

Gruß Dirk

**PicNick** · 06.10.2006, 07:45

Hallo, Dirk !
Das "Problem" liegt im Routing, also im Umsetzen der ID in einen physikalischen Pfad. Am I2C Bus MUSS ja sowieso jeder eine eindeutige Adresse haben.
Umd es taucht auch eher erst auf, wenn Applikationen einzeln und von verschiedenen Leuten entwickelt werden (was durch einen Standard ja möglich ist, und das is ja auch der Zweck)
Wenn irgendein begnadeter PC-oder Linux Entwickler eine geniales Servo-steuerprogramm entwickelt, und es spricht einfach die Servos 1-10 an, muß bei einem Einsatz festgelegt werden, sind das diese 10 Servos oder jene.
Also kein technisches Problem, man muß aber irgendwas vereinbaren.

Ich persönlich würde ja eher diese "ID" als Rollenname einsetzen, und zwar danach, was das Gerät tut.
Nimm an, ein SERVO #1. Was heißt das ? eigentlich garnix.
Ich würde eine ID vergeben, die aussagt, was das Servo tatsächlich tut.

Nimm einen Hexapoden, eine Kundschaft für viele Servos. Mir schiene es sinnvoll, wenn es da die IDs gäbe: Kniegelenk links hinten, Schulter rechts mitte, etc.
Denn eine PC anwendung mit einer Hexapodsteuerung muß sich ja danach richten, und servo 1 - 99 ist ja im Grunde bedeutungslos.

Und wenn ich das so mache, sind ja ALLE Geräte im Netzwerk automatisch eindeutig.
ID Schrittmotor links
ID Schrittmotor rechts
ID ADC-Batteriekontrolle
ID ADC GP2D12 links vorne
ID ADC GP2D12 rechts vorne

etc.

Dann kann einer perfekte PC Programme schreiben, ohne deine I2C Adressen zu wissen oder sonst was. eben weil alles Standard ist.

**Dirk** · 06.10.2006, 08:54

Hallo PicNick,

ja, das mit den IDs für die Funktionen des Slave verstehe ich.
Aber wie ist das auf der Slave-Ebene mit den einzelnen Funktionen, die ein,- sagen wir genormtes-, Programm haben könnte.
Beispiel:
Dein RNSI2C kann ja nicht nur die 10 Servos ansteuern, sondern auch noch per I2C-Befehl seine Adresse geändert bekommen.
Bei meinem RNIRI2C gibt es 3 Funktionen: IR-Empfangspuffer lesen, ein Kommando+Adresse senden und I2C-Adresse ändern. Wie kann oder sollte man das "normieren"? Es macht ja Sinn, die zusätzlichen Funktionen transparent zu machen!

Mein aktuelles Projekt ist z.B. ein DCF77-Decoder mit I2C-Ausgabe für den 2313,- das klappt schon ganz gut und ist in der Testphase.

Ich würde also in eurem Projekt zur Zeit folgende IDs beantragen:

ID IR-RC5: Empfangspuffer lesen
ID IR-RC5: Adresse+Kommando senden
ID DCF77: Zeit einlesen
ID DCF77: Uhrzeit Softclock stellen

Was bleibt als Frage:
Wer "weiss" auf den höheren Ebenen eigentlich, welche Funktionen es auf Ebene des 2313-Slaves gibt und wie sie ausgeführt werden?
Bei deinem RNSI2C ist das z.B. CMD (1) | srvNr | srvpos, bei meinem IR-Slave ist das CMD (0) | RC5-Adr | RC5-Cmd für das Senden, dazu kommt noch das Empfangen, da auch evtl. mit unterschiedlicher Größe des Empfangspuffers.
Ähnlich wird es auch beim DCF77-Slave aussehen. Da wird dann noch dazu kommen, dass man auch die "Betriebsart" des DCF77-Decoders per I2C-Befehl ändern kann. Dafür würde ich dann sozusagen noch eine weitere ...
ID DCF77: Betriebsart (Parameter) einstellen
... brauchen.
Für fast jeden Slave bräuchte man auch eine ID fürs Ändern der eigenen Adresse:
ID IR-RC5: I2C-Adresse ändern
ID DCF77: I2C-Adresse ändern

Ich weiss nicht, ob ich klar gemacht habe, was ich meine.

**PicNick** · 06.10.2006, 10:13

Man muß unterscheiden zwischen ID und Gerätefunktion. Eine bestimmte Gerätefunktion (lesen, schreiben, etc) und auch der Aufbau der Nutz-Daten sind Vereinbarungen zwischen Gerät und Appilkation, die das nützt, das spielt für unser Netzwerk keine Rolle
Das Netzwerk und das Routing ist sozusagen der Briefträger, der verteilt Briefe, was in denen drin steht, geht ihn nix an.
Sinnvoll wäre es, Die Nutzdaten immer mit einem "Command" (byte?) beginnen zu lassen
Bei deinen Geräten seh ich das so:
RC5 könnte es theoretisch mehrere geben, also wäre eine ID z.B,
IR_RC5 + Nummer 1 bis Nummer x
Das, was dann zu tun ist (lesen, schreiben), ist dann ein Kommando
Dein Beispiel als vollständige Message wäre dann:

Anm: Die Absenderangabe ist bei unserem Netzwerk meistens garnicht notwendig, denn das Netz weiß ja immer, wer den Brief in den Briefkasten geschmissen hat.

**Dirk** · 06.10.2006, 12:45

okay, verstanden -> wunschlos!

Gruß Dirk

**PicNick** · 06.10.2006, 13:18

Gleich eine Anfrage an die Gemeinde:

Es wäre günstig, wenn sich ein Programm beim RN-Server meldet, daß es auch gleich die Protokoll-art (smir und was weiß ich) mitteilen würde.
In weitem Bereich kann ich dann automatisch drauf eingehen.

Any suggestions ? Vorschläge ? wer (welche Protokolle) ttäten denn mitspielen wollen ?

(mir is alles recht, was STREAM-Sockets betreibt)

**LostInSpace** · 06.10.2006, 13:27

hi,
ein tipp zu eurem ip problem.
wichtig ist der unterschied zwischen udp und tcp. das projekt sollte nur tcp verwenden, da bei udp nicht garantiert wird, ob ein packet auch angekommen ist.
bei tcp wird alles ueber den ip-stack gecheckt. treten fehler in der uebertragung auf, kann dies einfach abgefragt werden.

nun zum problem:
frau sendet ein datenpaket mit einer laenge von 600bytes. im empfaenger werden diese auch ankommen, nur evtl. nicht in einem stueck. es kann sein, das das paket beim senden vom ip-stack fragmentiert wird (stichwort zb mtu). der empfaenger liest nun in seinem empfangspuffer 400bytes. er weiss nicht, ob noch weitere daten folgen.
die loesung fuer dieses problem wurde schon einige seiten zuvor in diesem thread genannt. frau muss auch hier mit start- und stop-sequenzen arbeiten. gelesene daten werden in eine queue geschrieben und beim empfang einer stopp-sequenz wird aus der queue ein neues 'packet' gelesen.

**PicNick** · 06.10.2006, 13:39

Du hast recht, ip kann einem mit seinem blocks ganzschön freude machen.
Ich selbst empfehle die Kombination Länge(short)/Data (um transparente Daten zuzulassen). Das tun auch viele andere, manche nehmen auch 32-bit längen, scheint mir aber überdrüber.
Start-Stop zeichen verwendet bei Ip keiner, den ich kenne (also nicht professionell, sonst weiss ich nix, ja, eventuell EDI)

Das zusammenschustern von den Daten beim receive muß halt so oder so immer gemacht werden, die Exception-behandlung aber auch, was soll's

EDIT
Achja, die ganzen Internet geschichten gibt's auch noch, aber das ist nicht für transparente daten