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

Hallo erstmal, ich habe mich die letzen Tage im Wiki rumgetrieben und ein paar Gedanken/Vorschläge niedergelegt, insbesondere für die Schicht 1:

https://www.roboternetz.de/wissen/in...Ncom_Schicht_0
https://www.roboternetz.de/wissen/in...Ncom_Schicht_1
https://www.roboternetz.de/wissen/in...Ncom_Schicht_2

Ich hoffe das ist ausreichend flexibel um uns nichts zu verbauen, gleichzeitig aber noch nicht zu kompliziert. Dynamisches Routing ist mit diesem Ansatz sicher möglich, trotzdem würde ich das ganze lieber noch etwas zurückstellen und momentan nur statisch routen.

@PicNick: Dynamisch Routen ist keine einfache Sache und ich erwarte nicht, dass Otto-Normalprogrammierer meine Seiten auf Anhieb versteht. Ich hoffe aber es ist trotzdem noch nicht zu kompliziert und gerade dies ist ein Teil von dem ich hoffe, ihn in einer Library verpacken zu können.

@PicNick: Betreffend der UART0-Spezifikation noch eine Frage:
Warum ist STX eigentlich als CTL_BASE+1 definiert, bzw. warum ist CTL_BASE+0 nicht genutzt ?

@PicNick:
Zwecks dem finden von Kommunikationspartnern: Prinzipiell spricht nichts dagegen, die Adressen innerhalb eines Subnetzes statisch zu vergeben. Wenn wir irgendwann einmal dynamische Adressvergaben haben, können wir immernoch einen Schicht3 Dienst einführen, der DNS spielt.

@Alle:
Warum eigentlich 2 Bytes für die Länge bei TCP-Stream Nachrichten ? 1 Byte müsste doch eigentlich reichen, länger als die maximale UART-Länge können wir sowieso nicht schicken.

ciao,
Ragnar

Tagchen ! Keine Sorge, wir schauen dir genau auf die Finger. Du schreibst keine Zeile in die Wiki, von der wir nix wissen :mrgreen:
Länge: weiss der Teufel, was sich die Router gegenseitig noch alles an Tabellen um die Ohren Hauen werden, was die Applikationen oder die UART garnicht zu sehen kriegen. Wenn wir 16 Bit definieren, brauchen wir uns darüber unser Leben lang nie mehr den Kopf zu zerbrechen. Vergeßt nicht, erst kommt die Länge, und dann erst Typ/adressen etc. d.h. es gibt keine Modifikationsmöglichkeit.
BASE + 1: kein Grund, der mir jetzt einfiele, das sind Hausnummern, Hauptsache, alle haben die gleichen. Gibt's einen Grund für eine Änderung ?
Dynamisch und begreifen: Nun, es kommt darauf an, was von der Sache beim Betrieb für den User spürbar bleibt, denk' ich. Ich kann das wahrscheinlich garnicht gut beurteilen.

Als Unerfahrener, (mit dem Risiko was falsch verstanden zu haben):
1. Erstmal ein einfaches System das niemanden/niefrauden überfordert und verfügbar ist.
2. Dabei die Möglichkeit für Wachstum nicht verbauen.
3. Erst im Folgeschritt Erweitern und verfeinern.
4. Ich glaube man kann ab und an auf die alten Programmier-Haudegen hören. Muss ja nicht zur Gewohnheit werden. :-)

Frage zur Wiki:
ragnar hat dankenswerter Weise schon eine menge Gedanken in die Wiki eingebracht.
Meine Frage:
Sollten wir etwas Neues in der Wiki erst dann RN-Com nennen wenn wir den Inhalt so beschlossen haben?
Davor würde es mir gefallen wenn es eine Diskussionsgrundlage genannt wird, an der Einigkeiten erarbeitet werde können.

Mit nettem Gruß

Solange es im Wiki im "Projekte" bleibt, haben wir noch Spielraum. Aber sicher sollten wir einen offiziellen Anstrich noch vermeiden. Das ist das dann wichtig, wenn es effektive Spezifikationen betrifft. Die derzeitigen Artikel sind ja in weiten Teilen nur Erörterungen, die kann ja eh' keiner anprogrammieren und zu kaufen gibt's auch noch nix.

Es ist mit gelungen, die Layer-0 Bascom-Library auch für den RNBFRA-CoProzessor zu adaptieren und hab' das gleich in das Servoprogramm eingebaut. Läuft jetzt so ab, daß der ATmega eine Message für die Sys-ID "S" (0x53) bekommt, das ist er nicht, also schickt er es einfach weiter. dahinter sitz der CoProc, der sagt juhuu, das zweite Byte der Adresse ist die Servo-nummer 1-10, und daher stellt er dieses Servo auf das Word ein, das er als Daten bekommt (600-2000).
Rücksenden kann er nicht, ist dzt. technisch problematisch, nur ein MAX da. Aber getestet hab ich's, vom programm her geht's.
Um die Servos auf der RNBFRA vom PC aus anzusteuern, brauch ich also auf dem Atmega selber garnix mehr.
Dzt. tu' ich mit dem RN-Server ein Servo von links nach rechts durchtickern. Toll *g*
Die Sache mir den Units bla bla ist für den kleinen 2313-er wahrscheinlich nix, soviel Platz ist da nicht, daß das viel sinn hat. Aber der Level-0 ist ja eh' auch extra zu betreiben.

@PicNick:
Da hüpft mein Kinderherz, wenn ein Servo hin und her macht.
Technische Frage:
Ich habe mein Board so gejumpert das der Mega32 zwei serielle Kontakte hat. Einmal zum Max232 und einmal zum CoProzesor.
Liegen bei Dir beide auf demselben seriellen Strang? Damit würde ja die Hilfsbrücke wie ich sie verwende entfallen?
Kann man das bei dir schon downloaden?

Mit ausgeprägtem Spieltrieb
M42x

Jetzt weiß ich nicht ? Ich hab das mit einem schrägen jumper so, daß der TX vom Atmega32 sowohl zum Max als auch zum RX vom CoProzessor geht. Also genauso wie bei allen meinen Backx Programmen.
Ich kann das Zeugs schon morgen zum Downloaden herrichten, wenn du magst, der RN_Server ist halt noch ein Dödi, volle Baustelle.

Mir fällt ein, ich werd morgen dicke Luft haben.
Ich stell meine augenblicklichen Schätze mal da rein

Message f. Servo
byte..byte..byte.byte..byte..WORD..byte..byte
STX 0x53 0x01 0x00 0x00 0x0nnn BCC ETX

Word : 600 - 2000 Servo position

Message f. LED
byte..byte..byte.byte..byte. byte..byte..byte
STX 0x42 0x01 0x00 0x00 0xnn BCC ETX

0xnn Bits für die LED

@PicNick:
Ich such mir hier einen Höcker. In diesem pdf wird das beschrieben:
Servotreiber RNS1.pdf, mit bild.
dazu gibt es ein Demoprogramm von Frank, wo beide varianten anprogrammiert sind:
Beispiel Prog Servo ser.bas
sorry ich finde den Link nicht aber wenn du willst maile ich es Dir.
Kinderherz: wenn Du mir was zum spielen reinstellst sage ich nicht nein.

Netter Gruß

Edit: Uups... da war ja schon wieder was neues... Danke :-)

Noch ein Edit: Da muss ich NumberFive zustimmen. Das Benachrichtigungssystem per Mail funktioniert oft nicht.

Das RNS1 ServoProgramm hilft uns nix, das ist vom Frank und weiß nix von unserem RN-COM
Ich hab vor einer Zeit das RNSX bereitgestellt, das ist fast das Gleiche + ein paar Features.
FÜr RN-COM wäre jetzt das RNSXNET interessant, und um das geht es.

Ja, das Servoprogramm ist nichts für uns. Mir ging es um den Umstand das es eine Variante gibt die den Reseveport des board als serielle benutzt. Im Demoprogram kann man dann schön sehen "print #2" .
Zusammengefasst: es gibt zwei Möglichkeiten.
1. den jumper über kreuz = gemeinsame serielle
2. patchkabel auf Reserveport = privates seriell zwischen den beiden controllern.
Eines Tages finde ich das pdf hier in der Riesenseite noch.

Netter Gruß