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

Hallo die main.c ist doch dabei.

das ist das komplette Prg für die RN-Controll jede Taste sendet einen Anders Wert für eine Variable der MC. Ich glaube kompletter geht es nicht so hast du den kompletten weg vom AVR bis ins Modul. Ist aber für ein Mega16 mit 16 Mhz aber sollte schin jeder umschreiben könne oder ?

Vielleicht mach ja jemand noch eine Bascom version davon.

@Vogon meinst du nicht das der telegramm aufbau ein bisschen sehr heavi ist. Ich kenne solche Telgramme zu gut frage mich nur ob so viel sein muß.

@Alle
Wie machen wir jetzt weiter ?
Ohne Telegramm structure kann ich nicht los legen.
Gestern war Robotchallenge ( http://www.gs-roboter.de/ , http://www.robotest.de/ )
und im Herbst ist Roboliga ( http://www.robotliga.de/ ) und ich würde im Herbst gerne dabei sein und das mit Standart system den zwei systeme
zuwarten das schaffe ich nicht. Ab morgen beginne ich mit dem PC -> I²C adapter den ich habe jetzt die Hardware wobei wir wahrschelich noch eine erweiterung bauen damit mit das mit dem Int auch vom PC aus tut.


Gruß

@NumberFive:
Sorry hatte ich als Bascom Einsteiger nicht als das identifiziert. Muss mich in C auch noch etwas bilden.
Netter Gruß

Zitat:

---

Zitat von NumberFive

... meinst du nicht das der telegramm aufbau ein bisschen sehr heavi ist. Ich kenne solche Telgramme zu gut frage mich nur ob so viel sein muß.

---

Ja, denke auch, das man auf die Sicherung durch "Recommend Server-Requester Handshake for RS-232C" verzichten kann. (3ter Teil)

Das Beispiel im 2ten Teil ist ja fast identisch mit deinem Vorschlag.
-- CP/Net Header
FMT DID SID FNC SIZ MSG / Function Name

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

An dem Beispiel vom CP/NET finde ich den "Message format code FMT" gut. So ist hat man die Möglichkeit noch weitere Protokolle zu definieren. (1ter Teil)
Auch "Size, Data field lenght -1" ist ich gut, damit kann man noch eine Message von 256 Zeichen in einem Byte beschreiben.

Schade das der Vor- und Quer-Denker, der sich schon vor 30 Jahren das erdacht und gemacht hat, uns viel zu früh alleine gelassen hat.
http://www.biocrawler.com/encyclopedia/Gary_Kildall

@Vogon:
Schönes Beispiel, aber relativ kompliziert. Das ganze ist
zwar recht universell, damit aber auch relativ aufwändig zu
implementieren. Insbesondere das variable Format von Adressen
und Datenlänge ist dabei denke ich ein Hindernis. Ob man das
RS232-Handshake implementiert, würde ich jetzt erstmal als
Teilproblem in die Übertragungsschicht schieben und da als
Option belassen. Sprich: erstmal nein, irgendwann kann mans
mal einbauen.

Ich möchte jetzt mal auch einen Vorschlag zum Format machen
und zwar jeweils zwischen den verschiedenen Schichten.

Anmerkung: Ich gehe davon aus, das die Länge eines Datenpaketes
implizit durch die Übertragungsschicht erkannt wird. Nachdem
jedes gesparte Byte bei der Übertragung ein gutes Byte ist,
ist die Länge deshalb auch nicht explizit Teil des Pakets.
In einer realen Implementierung wird die Länge vmtl immer in
der Datenstruktur stehen (als Zusatzinformation), nur taucht
sie in der Definition nicht auf und wird ergo auch nicht
explizit übertragen.

Anmerkung 2: Ich habe auch keinen speziellen Header vorgesehen.
Dieser ist in meinen Augen nur Overhead, da über das gewählte
Medium ja nur korrekte Nachrichten empfangen werden. Immerhin
ist das ganze fest verkabelt und man kennt die Gegenstelle. Wenn
ein device (aus welchen Gründen auch immer) wirklich einen Header
braucht, kann es diesen Header immer noch als Teil seines
Übertragungsprotokolls definieren.


Schicht 1 - Seriell

Auch Schicht 1 werden immer Datenpakete einer bestimmten
Länge ohne jede Bedeutung empfangen. Im folgenden mal
ein Beispiel, wie das seriell machbar ist.

Steuerzeichen
Zusätzlich zu den normalen Daten müssen Kontrollzeichen
übertragen werden. Da alle verfügbaren Zeichen (0..255)
schon belegt sind, werden einige davon als Kontrollzeichen
'abgezweigt'. Das ganze funktioniert ähnlich dem von PicNick
genannten 'Byte Stuffing':

Sei das '\0xff' das Kontrollzeichen, d.h. allen eingelesenen
Bytes mit dem Wert 0xff bzw. 255 folgt kein normales Datenbyte,
sondern ein Kontrollbyte. Im Gegensatz zum Byte Stuffing ist
dieses Zeichen aber eindeutig, d.h. das 'verschattete' Daten-
byte wird nicht durch sich selbst, sondern durch ein anderes
Zeichen übertragen.

Um also im obigen Beispiel ein Datenbyte 0xff zu übertragen,
wird das Kontrollbyte 0xff gefolgt von (z.B.) 0xfe übertragen.
Der Empfänger weis, das die Steuersequenz "0xff, 0xfe" dem
Datenzeichen 0xff entspricht und korrigiert den eingehenden
Datenstrom entsprechend.

Framing
Wie erkennt jetzt der Empfänger, wann eine Nachricht zu Ende
ist, bzw wie lange ein Datenpaket ist? Die Lösung ist Framing.
Dabei wird jede Nachricht von einer Anfangs- und einer End-
Kontrollsequenz begrenzt. Alle Datenbytes dazwischen gehören
zur Nachricht. wie lange die Nachricht genau ist, weis der
Empfänger erst, wenn er die Endsequenz empfangen hat.

Beispiel
Sei "0xff, 0xfe" ein Datenbyte mit dem Wert 0xff.
Sei "0xff, 0x00" die Startsequenz.
Sei "0xff, 0x01" die Endsequenz.

Der Sender will folgendes Paket übertragen:
<0, 0xff, 1>
Nach dem Framing und dem 'escaping' der Datenbyte mit 0xff
entsteht folgender Datenstrom:
<0xff, 0, 0, 0xff, 0xfe, 1, 0xff, 1>

Der Empfänger empfängt ein Startsequenz, erstellt einen leeren
Empfangspuffer und empfängt eine '0' die gespeichert wird. Dann
empfängt er eine Kontrollsequenz "0xff, 0xfe" und fügt dem
Empfangspuffer eine 0xff hinzu. Die folgende wird ganz normal
gespeichert. Dann empfängt er eine Endsequenz und gibt einen
Puffer mit der Länge 3 weiter.

Warum nicht Bytestuffing
Im Gegensatz zum Bytestuffing ist in diesem Verfahren das
Kontrollzeichen eindeutig. Das bietet einen Vorteil bei der
Wiederaufnahme unterbrochener Verbindungen. Wenn ich mein
Kabel aus- und wieder einstecke, dann bin ich beim Bytestuffing
nie sicher, ob ein empfangenes Kontrollzeichen wirklich ein
Kontrollzeichen oder ein Datenzeichen mit demselben Wert ist.

Warum Framing
Derselbe Grund wie oben: Wird ein Kabel im laufenden Betrieb
eingesteckt, dann können sich die Module anhand der eindeutigen
Start-Kontrollsequenz problemlos wieder synchronisieren.


Schicht 2+3 - Router+Verbindung

Empfangen/gesendet wird ein Datenpaket der Länge 'n', gebunden
an ein festgelegtes 'Segment' bzw. Übertragungs-device.

Code:

---

Byte 0: Message Type
        Bestimmt die restliche Struktur der Nachricht
          0x00 = User level msg, verbindungslos
          0x01 = User level msg, verbindungsorientiert, request
          0x02 = User level msg, verbindungsorientiert, response
          0x03 = RouterMsg (z.B. dynamic Routing Information)
          0x04 = RouterMsg (z.B. Adressvergabe)
          ... to be continued

Für Userlevel messages (Typ=00, 01, 02) gehts wie folgt weiter:
Byte 1: Receiver, subnet address
Byte 2: Receiver, node address

Byte 3: Sender, subnet address
Byte 4: Sender, node address

Byte 5: Session number, low byte  (nur für verbindungsorientierte messages)
Byte 6: Session number, high byte  (nur für verbindungsorientierte messages)

Byte 5/7..n: Daten

---

Schicht 4 - Diensteschicht

Empfangen wird ein Datenpaket mit Länge, Addresse und evtl. Session number.
Responsenachrichten (Typ 0x02) werden direkt der entsprechenden 'Session'
zugeordnet. uCs müssen Responsenachrichten nicht unterstützen, können aber.
Nachrichten vom Typ 00 bzw. Typ 01 haben immer folgendes Format für den
Datenteil:

Byte 0: Group (Dienst)
Byte 1: Command
Byte 2..n: Command specific Data

Ein Teil der Kommandogruppen ist vordefiniert und wird von der GUI
unterstützt, der Rest der Kommandogruppen kann vom User frei definiert
werden, z.B. für eigene Kommandos.

Denkbare allgemeine Dienste wäre z.B.

1.) Infrastructure
Definiert Kommandos zum Abfragen der Namen von Knoten, zum SW-Reset
eines Knotens, zur Hardware, usw. Diese Kommandogruppe sollte in jedem
(physikalischen) Knoten implementiert sein. Damit lässt sich z.B.
herausfinden, das es einen Knoten 'RNBFRA - Roboter 1' mit den logischen
Knoten 'Motorsteuerung', 'US-Sensorsteuerung' und 'Liniensensor' gibt.
Auch Kommandos zur Überwachung der Knoten (z.B. ping, heartbeat) wären
hier gut aufgehoben.

2.) Sensors
Definiert Kommandos zum Allgemeinen Abfragen einfacher Sensoren sowie
(evtl.) zur Selbstbeschreibung von Sensoren.

3.) Motor Control
Definiert Kommandos um Allgemein eine Motorsteuerung zu kontrollieren,
z.B. Vorwärts(100cm), Rechts drehen(50grad), usw.

4.) Debugging
Definiert Kommandos zum Entwickeln neuer Komponenten. Funktionen dieses
Dienstes könnten z.B. 'virtuelle Konsolen' für den jeweiligen Knoten sein.
Auch ein 'Notstop' bzw. 'Pause' Kommando würde hier gut passen, genauso
wie das auslesen bestimmter Speicherstellen, ...

5.) Synchronised Variables
Definiert Client- und Serverfunktionalität für Synchronisierte Variablen.
Client-Befehle z.B. GetVar, SetVar, CreateVar.



Ich hoffe das war jetzt einigermaßen gut beschrieben. Wenn irgendwo noch
Fragen offen sein sollten: stellt sie jetzt.


Wie gehts weiter:
Ich werde zum obigen Protokoll "mal schnell(tm)" einen Prototypen hacken,
der das ganze demonstriert und mit dem man auch Teilbereiche wie das
Adress-DHCP und das dynamische Routing ausprobieren kann.

Sobald wir uns auf ein Protokoll für Schicht 3 bzw. Schicht 4 geeinigt haben,
können wir konkrete Schnittstellen für z.B. Java, C, Bascom definieren und
dann die Schichten entsprechend implementieren.


ciao,
Georg

Ich möchte bei der Protokollfestlegung noch mal einen Gedanken aufgreifen.
Auf der Ebene der Mikrocontroller geht es sehr spezifisch und eng zu. Können wir im Entwurf,
nicht unbedingt in der ersten Implementierung,
optional mehrere Protokolle vorsehen aus welchen der Mikro sich eins aussucht und ansagt?
Das würde für Verbindungen gelten bei denen die Beteiligten bekannt sind z.B Seriell com1: oder I2C. Das hat PicNick meiner Meinung nach auch schon mal vorgeschlagen.
Die Festlegung würde in einem Eröffnungsdialog der Verbindungspartner stattfinden.


Ein Verbindungs-Eröffnungs-Dialog wo sich die Verbindungs-Partner bekannt machen, (auch z.B.Konfigurations-Veröffendlichung) und das Protokoll aushandeln.
Dieser Dialog ist auf Anforderung wiederholbar.
Danach Verbindung mit gewähltem Protokoll.
Wir könnten verschiedene Protokolle testen ohne uns jetzt schon festzumauern.
Bei der ersten Implementierung wären unterschiedliche Protokolle für die Mikros denkbar solange die Gegenstelle auf dem PC diese beherrscht.
Den Eröffnungsdialog bräuchte man fürs Erste nur ganz kärglich realisieren:
Mikro sagt: Protokoll 5
PC sagt: kann ich
Mikro sagt: Ok
Los geht’s…….

Netter Gruß

@ragnar (Stuffing), denk noch mal nach. im Prinzip isses wurst, ob du vor oder nach einem Zeichen was einfügst.
Deine Variation bedeutet, dass du vor JEDEM Steuerzeichen prefixen mußt.
Ich hab eben vorgeschlagen, daß jedes Zeichen immer das ist, was es scheint, ausser eben, es ist vorher prefixed. Also statistisch günstiger.
Fehler gibt's keine, glaub mir, ich hab das schon öfter angewendet.

@PickNick: Ja, du hast natürlich recht. Wenns nur ein Steuerzeichen gibt
ist das mit dem Bytestuffing gut. Eigentlich hindert einen auch niemand
daran, bei Bedarf ein zweites Kontrollbyte zu stuffen. Was mir aber noch
nicht ganz klar ist: Wie erkennst du das Ende einer Nachricht (ohne die
Länge explizit mitzuschicken)? Das geht in diesem Fall dann nicht, oder ?

@marvin42x: Nicht unmöglich das mit den verschiedenen Protokollen,
aber welche genau stellst du dir da vor? Irgendwo müssen wir uns
festlegen, sonst können wir nie anfangen. Und wenn man die 4. Schicht
richtig implementiert ist es ihr egal, welches Format die Addressen genau
haben und man kann die unteren Schichten problemlos austauschen.

ciao,
Ragnar

Mein Vorschlag soll die Einigung und den Fortgang nicht bremsen.
Punkt 1 ist Einigung auf ein Protokoll und los.
Ich bin mit fast allem einverstanden weil ich es eh nicht besser kann.

Der Vorschlag soll verhindern, dass das System am Ende zu properitär wird. Ich sehe andere Mikrocontroller-Welten und Projekte die ich optional gerne zu Gast hätte. Wie die am Ende aussehen mach ich mir noch keine Gedanke, ob das Legosysteme sind oder von irgendeiner Uni oder was aus Jugend forscht. Oder was anderes weis ich nicht.

Aber generell würde ich lieber auf diese Option verzichten als auf die Fertigstellung eines funktionierenden Kommunikationssystems.

Netter Gruß

@ragnar

Ich muß zu geben das ich ganz schlechte erfahrung mit Telegrammen ohne Längen information gemacht habe. Das Problem ist die er kennung von Müll.
OK an was ich nicht gedacht habe ist steuer Byte in halb der Daten.
Ich finde den Header des halb gut um den Anfang zu finden. gerade wegen dem Stecken und ziehen der verbindung. Was bei mir sicher nicht vo kommen kann aber wenn die RS232 über Funk geht währe das sicher öfter mal möglich (Funkschatten).

Zweites problem bei Übertragung ohne Längen Information auf einem AVR ist es sicher noch möglich ein Timeout zu bauen aber auf dem PC bringt man sich schier um wenn so ding sagt wie wenn das nächste Zeichen mehr als 5 msec braucht ist es ein neues Telegram.

Klar währe Framing auch eine Lösung die bei Funkübertragung vielleicht noch besser tut. Jedes Byte durch zwei zu ersetzen halte ich auch für zu aufwendig und zu daten intensiv.

Ich denke auch wenn man die Anwendung und das Protokoll durch gemeisam genutze Komponeten abgrenz sind Protokoll änderung nicht ganz so Probelmatisch. weil man "nur" so files oder dll tauschen muß dann tut es wieder oder beim avr ein header und ein c file.

Dabei stellt sich mir gerade die frage wie macht man so was bei Bascom ? Kann man da auch libs bauen ?

Freue mich schon auf die erste software.
Wie machen wie es auf der TCP/PC Seite das Selbe Protokoll ?
Oder was lesbares ?
Wenn nicht das Selbe würde ich dann den TCP/PC teil machen so bald ragnar das mal roh gehackt hat.

Off Topic:
Warum wurde ich nicht benachritig das es hier was neues gibt ?

Gruß

Zitat:

---

Wie erkennst du das Ende einer Nachricht (ohne die
Länge explizit mitzuschicken)? Das geht in diesem Fall dann nicht, oder ?

---

Klar, eine explizite oder implizite Endekennung muß es geben. Ich hab da zwei Variation am Laufen: Eben mit einer Länge gleich als zweites Byte nach HDR-Kennung
Die andere (für andere Zwecke) ist, a la EDI(FACT) Es gibt
Frame Start/Ende Ctrl Bytes UND
Element und sub-element Separators. (ÚND ein eigens Prefix-Zeichen)
Das ist dann sinnvoll, wenn man die Daten als völlig transparent und variabel-lange Fields & Folders übertragen will.
Für µC scheint mir entweder die Längenbyte Lösung ODER
ein EOB -Zeichen anwendbar.
Längenbyte ist beim Empfang praktisch, beim Senden muß ich aber erstmal das ganze Frame aufbauen und kann dann erst senden. (und µC haben nie viel Platz)

Ich würde für diesen Level aber einfach mal die erforderlichen Funktionen definieren (Init, RX, TX, ev CRC) und die Schnittstelle dazu.
Dann kann man das immer noch auf zehn Arten Lösen, je nach Laune. (von mir aus Brieftauben)
Wir müssen ja auch Half-duplex und andere HW-Specialities mögloich machen