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

@ NumberFive: Möglicherweise ist deine Befürchtung mit dem Müll senden nicht ganz so gravierend wie es im ersten Moment aussieht.
Ich sehe auf der einen Seite einen Mikrocontroller der sich mit 9600 bit/sec abmüht.
Ich sehe auf der anderen Seite mal ungünstig ein 10Mbit LAN mit 10 000 000 bit/sec.
Das ist 1000 mal mehr. Da könnte man das Verhältnis 4 zu 20 Bytes eher entspannt sehen

Ihr dürft mich schelten wenn ich mich mit den vielen Nullen vertan habe.
Netter Gruß

Edit: Sorry habe den letzten Beitrag nicht mitbekommen. Ihr seit schon weiter.
weiter so, sehr spannend.

Ok wenn ihr drauf besteht aber ich denke das die Menge nachher vielleicht och ein Prob wird aber lassen wir das erstmal.

Naja in meinen ComTCP dll Gibt es so was Fasst schon die hat eine MCConnect metode und eine Spilt metode. das würde dem der Progrmmieren
will ja schon fast reichen ok wir müssten an stand der Nummer (pos im string)
einfach nur einen Namen über geheben und dann währe wird schon nah dran.

Ist <var =20 \> wirklich xml konform ich kenne nur das <Name>Wert</Name> und das ist heftig mehr.

wegen der RS232:
Ich denke 9600 ist denke auch nicht das Maß 38000 sollten es schon werden was machen die funkt module ?

Oh ich muß auf passen das Thema reiß mich zu Stark ich muß noch ein robi zu laufen bringen.

Zitat:

---

Zitat von NumberFive

Ist <var =20 \> wirklich xml konform ich kenne nur das <Name>Wert</Name> und das ist heftig mehr.

---

Jo klar fast *knirsch shit* :^o ,
is alles drin.
<var>20</var>
<var v=20 />
<var v=20></var>

...aber wie getextet das Zeug soll nicht über RS232 Funk oder ähnliches Schicken ... nur internes bzw. Netzwerkformat.

Denn man kanns durch die Leitungen jagen... und mit einem HTTP header versehen (als SOAP) durch jede Firewall auf P:80 durchs WWW jagen ;-)

Aber ich male nun erstmal ne Architektur... bis denn.
Mir geht nämlich der Text aus ;-)

Gruß,
Chris

Jetzt mal was konkretes

Nachdem ich es neulich schon mal angekündigt habe, kommt jetzt
ein Vorschlag, wie man meine Schichten in der Praxis implementieren
könnte.


Schicht 1 - Übertragung

Übertragen werden Datenblöcke mit einer bestimmten
Länge entweder direkt oder als Broadcast. Sollte als
serielle Variante problemlos auf einem uC implementierbar
sein.

• Seriell:
  Für seriell ist die direkte und die broadcast-übertragung gleich.
  Es existieren verschiedene Möglichkeiten, das Datenpaket zu
  übertragen. Meines Erachtens am besten wäre hier das von PicNick
  genannte Byte Stuffing, bzw. eine ähnliche Form davon mit Escape-
  sequenzen und Framing. Im Gegensatz zum ByteStuffing ist das
  Kontrollzeichen hier absolut eindeutig im Datenstrom, was die
  die Fehlertoleranz noch etwas verbessert.
  
  LAN:
  Am einfachsten und performantesten ist wohl die Übertragung durch
  UDP-Pakete über einen festgelegten Port. Dabei können broadcasts
  und direkte Nachrichten über die entsprechenden UDP-Äquivalente
  verschickt werden. Interessant am LAN ist noch das 'Finden' der
  anderen Teilnehmer. Dafür würde ich Lan Kontrollpakete vorschlagen,
  mit denen neue Teilnehmer auf dem LAN sich bei den anderen
  Teilnehmern bekanntmachen.

Schicht 2 - Adressierung/Routing

Adressierung:

• Einzelne Knoten werden über zwei Bytes adressiert. Dabei ist
  ein Byte die eigentliche Adresse, das andere Byte das Subnetz.
  Zusammen bilden sie eine eindeutige Adresse für jeden Knoten.
  
  Bei jedem der beiden Bytes gibt es zwei 'spezielle' Werte. Der
  Wert 0 ist eine Broadcast-Adresse, der Wert 0xff die eigene
  Adresse. Bei Broadcasts kann also nicht nur in das 'lokale'
  Subnetz gebroadcastet werden. Wird für die Adresse ein konkreter
  Wert eingetragen und für das Subnetz die Broadcastadresse, so
  wird die Nachricht an die bestimmte Adresse in jedem Subnetz
  übertragen. Dadurch kann man nahezu einen Multicast realisieren,
  indem man z.B. alle Komponenten zur Variablensynchronisation
  auf eine bestimmte Adresse legt.
  
  Auch der Wert 0xff für die 'eigene Adresse' bedarf noch einer
  Erläuterung. Setzt ein uC diesen Wert für sein Subnetz ein, so
  kann er kommunizieren, ohne sein eigenes Subnetz kennen zu
  müssen.
  

Auf der Adressierung baut nun der Router auf. Er muss entscheiden,
wohin eine eingehende Nachricht weitergeleitet wird. Der Router kennt
seine(n) lokale(n) Knoten und eine Menge an Übertragungs-HW (Segmente)
Im folgenden stelle ich zwei Möglichkeiten vor, wie es das tun könnte:

• Statisches Routing (problemlos auf uCs verwendbar)
  Besonders leicht, wenn nur ein Segment existiert (z.B. seriell)
  Die Routen sind in diesem Fall statisch eingetragen. Der uC
  weis also das er selbst (unveränderlich) der Knoten X ist
  und das es einen 'Uplink' gibt, der für alles andere
  zuständig ist. Das Routing beschränkt sich also darauf,
  Nachrichten auf die eigene Adresse zu überprüfen und entweder
  nach oben oder an das 'Default' Segment weiterzugeben.
  
  Als Erweiterung kann er ein zweites Lokales Interface mit der
  Adresse Y kennen, das z.B. am i2c Bus hängt. Auch dieses wird
  statisch eingetragen und bedient.
  
  Dynamisches Routing (aufwändiger)
  Auf irgendeiner Ebene des Systems, meistens wohl auf den
  Knoten mit LAN-interface wird die Sache aufwändiger. Jetzt
  gibt es plötzlich sehr viel mehr direkte Kommunikationspartner.
  Natürlich könnte man auch die alle statisch konfigurieren, das
  ist jedoch nicht besonders Flexibel.
  
  Für die 'Königslösung' müsste der Router nun für jede Adresse
  herausfinden und speichern über welches Interface sie erreichbar ist.
  Um das effizient zu tun brauchts entweder eine lookup-Table mit
  64k Einträgen oder einen guten Hashalgorithmus. Das ganze ist imho
  nicht so wahnsinnig praktikabel, auf uCs mit Ethernet vmtl. gar nicht
  implementierbar.
  
  Ein Zwischenlösung könnte sein, wenn der Router nicht alle Adressen
  speichert, sondern lediglich nach Subnetzen routet. Nur innerhalb des1
  'eigenen' Subnetzes wird nach Adressen geroutet. Adressen aus anderen
  Subnetzen werden nur nach ihrem Subnetz einem Sebment zugeordnet. An
  dieses Segment wird die Nachricht dann übertragen. Im Normalfall wird
  die Gegenstelle dann die Nachricht entweder selbst korrekt zustellen
  (wenn sie zur ihrem Subnetz gehört und existiert), weiterleiten (auf
  anderes Segment) oder fallenlassen (richtiges Subnetz, nicht existierende
  lokale Adresse).
  
  Klingt kompliziert - ist es aber nicht. Vor allem hoffe ich genau
  diesen Teil komplett in libraries verstecken zu können.

Schicht 3 - Verbindung/Sicherung

Im ersten Schritt will ich nur verbindungslose, unsichere Nachrichten.
Diese Schicht ist also quasi leer und hat (noch) nicht viel zu tun.

Schicht 4 - Dienste

Auf dieser Schicht kommt nur ein Datenpaket mit festgelegter Länge an.
Wie genau dieses verarbeitet wird, bleibt noch festzustellen. Da ihr
alle schon ganz fleissig über diese Schicht diskutiert und diese Schicht
wenig mit der eigentlichen Übertragung zu tun hat, werde ich ihr demnächst
einen eigenen Post widmen.


Anmerkung: Natürlich sind meine heutigen Vorschläge noch lange kein
hartes Interface. Ich hoffe ihr könnte euch trotzdem schon vorstellen,
worauf ich hinaus will. Ich werde in den nächsten Tagen mal eine
konkrete Definition schreiben, dann sollte es ganz klar werden.

ciao,
Georg

Ja nun Supi,
einige arbeiten sich von vorner nach hinten und ander andersrum...
.. nur was vorn und was hinten ist kann ich nicht mit bestimmtheit sagen.
Wenn wir uns in der Mitte treffen gibts ne Party ;-)

Ich habe mal versucht was aufzumalen.
Textlich hinterlegen kann ich es aus Zeitmangel momentan nicht.
Aber viele hier wissen vermutlich was ein Applikationsserver ist und wie er funktioniert oder gar implementiert wird ... so kann ich mir das vielleicht auch sparen.

Es ist schlussendlich ein Bild geworden... wenn jemand auch drin rummalen möchte ... es entstammt aus dem MS-Visio ... ich versuche mal die Quelle hinzuzuposten (*geht nicht).

Ja dann kleiner Dienstweg per Mail?

Bis bald,
Chris

So, jetzt mal einige Kommentare zur aktuellen Diskussion der
Diensteschicht (bzw. alle Schichten drüber)

Zitat:

---

Zitat von UlrichC

Ich habe bislang geplant für den Datentausch wie gewöhnlich SOAP zu
verwenden und weitere Systemteile sofern notwendig mit CORBA zu
verschabbeln. Ist S²MIRS als etwas ähnliches angedacht oder ist das
Layer zu tief?

---

Wenn ich smirs richtig verstanden habe, dann könntest du SOAP
als 'Transfer' schicken. Problem: die Variablen in smirs sind
auf derselben Schicht wie 'Transfer'. Die kannst du also mit
XML nicht so erfassen. IMHO werden in smirs weder Bedeutung
noch Typ der Variablen festgelegt. Die Definition komplexer
Strukturen unter einem Namen ist jedoch möglich.

Zitat:

---

Zitat von UlrichC

PS: An die Doktorarbeitschreibsler ...etwas pragmatischer wäre net
schlecht, denn ich bin Informatiker und kein Theologe. Und der glaube
an ein System das multi private, public semiperstent, private persistent,
private kill... rollback public .. watch hangoff .. deadloop ... watch
external, handeln kann ist bei mir und zudem Naturwissenschaftlich schon
widerlegt.

---

Allein mit diesem Satz kann ich jedes Boolshit Bingo mit
Pseudo-Informatik-Buzzwords gewinnen. Wenn du genau aufgepasst hättest,
dann wüsstest du, daß ich nur über die Sicherung der unteren Ebene
geschrieben habe. Mag sein, das dich das als Anwendungsentwickler nicht
interessiert. Mich als Hardwarenahen Entwickler interessiert es durchaus.
Genaugenommen steht es durchaus auf meiner Wunschliste (allerdings recht
weit hinten) und deshalb werde ich auch drüber nachdenken. Nur weils
dich nicht interessiert oder nicht betrifft, brauchst du nicht gleich
diskreditierende Kommentare dazu schreiben.

Zitat:

---

Zitat von marvin42x

Ragnar hat weiter vorne ein Schichtenmodell vorgeschlagen.
Schicht 1 Übertragung
Schicht 2 Routing
Schicht 3 Verbindung
Schicht 4 Dienste
Ragnar z.B.möchte bis Schicht 3 bei der Entwicklung helfen.

Nach diesem Modell sind
Deine geplante GUI Schicht 4 .
Deine angeregte Festlegung von Werten Schicht 4.

Zur Zeit liegt der Fokus auf den Schichten 1,2 und 3 um der Schicht 4
die Plattform-Unabhängigkeit zu schenken. Bevor das nicht steht kann
man der Schicht 4 nicht sagen was sie vom Datenverkehr erwarten darf
und was sie erfüllen muss.

---

Ja Marvin, genau so habe ichs gemeint. SOAP auf Schicht 4 wäre durchaus
möglich. Aber in einem Punkt muss ich dich korrigieren. Man kann jetzt
durchaus schon über Dienste reden. Es ist sogar sinnvoll, das jetzt schon
zu tun, da die Dienste u.U. gewisse Ansprüche an die Schicht 3 haben.
Je früher man das erkennt und integriert, desto besser.

BTW: Über Schicht 4 habe ich auch so meine Vorstellungen, weis aber noch
nicht, ob die mit den euren Zusammenpassen.

Zitat:

---

Zitat von UlrichC

Ok, das mit den Layern klingt irgendwie wie Standard TCP/IP ...
Gar nicht so übel wenn man das wirklich in einen Contoller packen könnte.

---

Ja, da ist viel bei IP abgeschaut und zwar nicht zufällig. Wenn IP auf
einem uC laufen würde, dann würde ich die eigentliche Software auch direkt
auf IP aufsetzen. Leider ist der Overhead dabei recht groß, weshalb ich
das ganze einfach runterbrechen will.



@UlrichC
Darf ich dich mal etwas zu deinen Posts fragen. Wenn ich das richtig
verstanden habe willst du eine allgemeine Roboter GUI programmieren.
Wie genau stellst du dir das vor ? Was soll die GUI alles können ?
Wie soll sie beliebige Roboterdaten allgemein darstellen können ?

Beispiel: Ich habe in den letzten Posts häufig von Variablen, Typisierung
und Einheiten(naja, auch nur Typisierung) gelesen. Wie soll das z.B.
ganz konkret aussehen ?

Macht doch mal bitte noch mehr Beispiele, mich würde interessieren
wie ihr euch eine GUI konkret vorstellt ...

Wenn ich das weiter richtig verstehe, soll es einen 'Application Server'
geben, der an das Robotersystem angebunden ist. Jetzt wirds etwas unklar.
Wenn du im folgenden von Drivern und Modulen und Softwarearchitektur redest,
dann nehme ich an, all dies bezieht sich auf den Application Server. Auch
nehme ich an, das du bei Schnittstellen immer die Schnittstellen des
Application Servers auf Schicht 4 meinst. Mit den uCs soll per SOAP
kommuniziert werden. Nicht klar ist mir, was für Standards da erzwungen
werden sollen.

Mal ein konkretes Beispiel ob ich deinen Applikationserver richtig
verstanden habe. Der Applikationserver lädt zur Laufzeit (vmtl. zum
Start) ihn vorher unbekannte Module. Diese Module können z.B.
Hardwaretreiber sein, interne Hilfsmodule für Datenaggregation
und -aufbereitung sowie Module die die Daten schliesslich graphisch
auf den Bildschirm bringen.

Dir geht es also nur um die interne Softwarearchitektur der GUI, richtig ?
Im Prinzip finde ich die Architektur der GUI so gut, allerdings auch
ganz schön allgemein. Andererseits sollte der Overhead durch XML, SOAP oder
CORBA auf dem Rechner mit der GUI kein Problem sein ...

Zitat:

---

Zitat von UlrichC

Also im Grunde ein vorgefertigtes System .. das arbeit abnimmt und freiräume lässt.
In einer Hochsprache... mit Treibern zu den Controllern ... netten GUIs
Eine Art DEV Studio/Plattform/BDE für Roboter.

---

Dem würde ich jetzt voll zustimmen, allerdings ist das auch voll
unkonkret und schon fast Marketing-Gefasel ;-)


Noch zwei Dinge bevor für heute Schluss ist:

1.) Bisher haben wir noch (fast) gar nicht über die Schicht 4 auf den
uCs gesprochen. IMHO ist diese aber noch viel wichtiger als die
interne Struktur der GUI. Welche (allgemeinen) Dienste könnten
hier angeboten werden ?

2.) Vergesst bitte nicht, das ein Roboter aus wesentlich mehr als ein
paar Variablen besteht. Das ganze ist in erster Linie ein Nachrichtensystem,
kein synchronisierter Variablenpool. Ich beabsichtige das ganze auch
innerhalb der logischen Module meines Roboters zu verwenden. Ich will
Ereignisse abstrahieren und darauf reagieren. Variablenanzeige ist für
mich nur ein klitzekleiner Teilbereich.

ciao,
Georg

So langsam wird es mir zu Theoretisch das ist, da bin ich ehrlich, zu Abgehoben. Ok wir müssen zu erst mal die Schicht 1 definieren das ist ok.

Ich habe im Moment eigendlich keine zeit Trotzdem kann ich den Thread nicht ruhen lassen.

Ich bin gegen UDP das ist zu unsicher und erzeugt last im netz die nicht zu händeln ist. Jeder der mal ein größeres Netz betreut hat kann mich da glaube ich verstehen.

Nur So auf die Schnelle:

Warum nicht Multicast ist routing fähig und versaut nicht ganz so das Netz.
Ok die Adresse muß dann halt in Jedem Modul einstellbar sein das währe ja nicht gar so schlimm.

Die Zwei Connect möglichkeit Sollte in meinen Augen die MC bleiben um weiterhin eine Möglichkeit für die Zentralle daten haltung zu habe.

das was gesenden wird sieht so aus:
<Byte> 99 -> Kenner ist ein RN robo Telegram
<Byte> lobyte telegram länge
<byte> hibyte telegram länge
<ADRESSE AD='COM1:2'>
--to define---
</ADRESSE>

COM1 Ist das Modul ein I²C Converter 2 Die Adresse auf dem I²C Bus

<ADRESSE AD='COM1'>

So sehe das dann für RS232 oder ein anders Modul aus.

Was spricht gegen namen als addresse ?
Warum die Adresse berechnen ?

Mist ich muß weg

Zitat:

---

Warum die Adresse berechnen ?

---

berechnen kann man nicht sagen, das ist mapping

Auch im flottesten IP Netz wird aus
www.wtlbrnft-und-co-ag.de.vu.xyz.simsalabim
durch den DNS irgendsowas wie
77.34.11.212
und das binär in 4 bytes

@ragnar
Ich wollte nicht diskreditieren, schade das es so angekommen ist.
Im Gegenteil find ich gut das aus dem Layer-Gelayer dann doch eine Grundlegend verständliche Struktur (bzw. Erklärung) geworden ist.
(Das war ja nicht vorhersehbar)
Zudem war mir als Quer-Leser bzw. Quereinsteiger in diesem Thread nicht unbedingt gleich klar an welcher Ecke gerade definiert wird.
Layer 1 bis X gibt es nun mal an mehreren Stellen eines "verteilten" Systems.

Ansonsten wie Du schon gesagt hast und ich in späteren Beiträgen erwähnt habe... ich halt mich aus der Hardwareanbindung raus.
Für diese Aufgabe habe ich nicht den nötigen Background um gleich ein Standard daraus zu generieren.
Im Grunde hab ich ja auch nur Wünsche fürs Frontend bzw. die Schnittstellen
... passt schon.

Was soll die GUI alles können ?
Die GUI die ich mir vorstelle ist sehr schmal gehalten.
Und soll in erster Linie eine Software sein um einen Roboter durch das WWW zu steuern und die gängigsten Messdaten zu visualisieren.
Welche Messdaten? da bin ich mir noch nicht einig.
Die Steuerung soll mit Richtungspfeilen realisiert werden.
Das einzige was wirklich sicher ist, ist das eins bis vier Kameras visualisiert werden sollen.
Wie die genau aussehen soll wird die Praxis+Anforderungen entscheiden.

Die WWW-GUI soll aber "kein" Bestandteil der hier behandelten Standardisierung sein!
Es wäre zu weitgreifend hier über weitergehenden Technischen Schnickschnack zu plaudern.
Ich möchte nur irgendwo aufsetzen können (eine Schnittstelle) ... der Rest hat dann wieder mehr mit CGI + Content-Menagement-Systemen zu tun.
Es ist lediglich eins von X Anwendungsbeispielen.
Die internas/features der WEB-GUI könnte ich nun zwar noch aufdröseln, aber das würde nix zur Sache beitragen.
Es ist ja gerade kompliziert bis verwirrend genug wenn an zwei Enden diskutiert wird.
Ich beantworte aber im Rahmen meiner Entwicklung gerne Fragen im Detail ... Mail ... die keine Elementarerklärung zur folge haben.

Der erzwungene Standard durch den AppServer währe folgender.
Dei Module müssen vom AppServer geladen werden können um im System mit anderen Teilen zu Funktionieren.
...wird erzwungen durch eine DLL Schnittstelle die verwendet bzw. implementiert werden muss.
Weitergehend sollten die Businessobjekte (Module/treibe etc.) alle von einem Masterobjekt abgeleitet werden und dessen Funktionen verwenden.
(im Falle von C eine statische Lib)
...diese abgeleiteten/bzw. verwendbaren Funktionen beschreiben die interne Schnittstelle (programmiertechnisch).

Die Kommunikation erledigt der AppServer ... wenn alles so läuft wie ich es mir erdacht habe... wird der Programmierer des Treibers kein SMIRS oder XML zu Gesicht bekommen... sondern nur die vorhandenen Funktionen bedienen.
Der Appserver ist im weiten Sinne als LoginServer des SMIRS oder als Proxi/Router der Module zu verstehen.
Ich möchte das Ding auch nur bauen um eine Programmierschnittstelle und kein Protokoll zu haben.
...
Dieser (Teil) Standard ist dann nur die Programmierschnittstelle zum ganzen.

Wieder Beispiel Web-GUI (wie geh ich vor):
1.Ich installiere das System (Appserver + Module)
2.Lese die Schnittstellenbeschreibung
3.(Programmierbeginn) Ich leite das Masterobjekt ab und habe die Funktionen die ich für das anhacken der anderen Systemteile brauche.
4.Ich überlege mir von welchem Modul ich welche Daten brauche. ... ich brauch nur das Bild
5.Programmabel sage ich (durch die Funktionen) Modul "CAM" gib mir "BILD1"
6.Da ich auf dem System aufsetze und nicht auf der Hardware selbst bekomme ich ein Bildobjekt (das Format ist von Modul "CAM" bestimmt)
7.Das bild ist nun in meinem Modul und ich habe die Freiheit damit zu tun was ich möchte...
8.Ich schicke es über CGI an meinen Webserver wo schon ein Script darauf wartet.
9.Nun will ich Den Roboter Steuern (also ein anderes Modul mit Daten versorgen)
10.Ich Frage den Webserver ob einer die Steuerung bedient hat. (Fernab vom System den ich bin ja nur Nutzer wie alle Module anderen auch)
11.Der Webserver erzählt mir JA und zwar 10 cm vorfahren.

12.Programmabel sage ich nun wieder (durch die Funktionen) Modul "DUALMOTORSTEUERUNG" "POWER_ENGINE_A" "10"
13.Programmabel sage ich nun wieder (durch die Funktionen) Modul "DUALMOTORSTEUERUNG" "POWER_ENGINE_B" "10"
14.Programmabel sage ich nun wieder (durch die Funktionen) Modul "DUALMOTORSTEUERUNG" "WEGSTRECKE" "1000"
15.Programmabel sage ich nun wieder (durch die Funktionen) Modul "DUALMOTORSTEUERUNG" "RUN" "TRUE"
16.Programmabel erzählt mir (durch die Funktionen) Modul "MOTORSTEUERUNG" "SENSOR_ERROR" "SENSOR1"

...oder
12.Programmabel sage ich nun wieder (durch die Funktionen) Modul "EASY_NAVYGATOR" "FORWARD" "10000"

...oder
12.Programmabel sage ich nun wieder (durch die Funktionen) Modul "2D_NAVIGAROR" "ABS_POS_X" "121"
13.Programmabel sage ich nun wieder (durch die Funktionen) Modul "2D_NAVIGAROR" "ABS_POS_Y" "12"
14.Programmabel sage ich nun wieder (durch die Funktionen) Modul "2D_NAVIGAROR" "RUN" "TRUE"

...oder
12.Programmabel sage ich nun wieder (durch die Funktionen) Modul "WEBROBOTER" "FORWARD_10"

xx.Programmabel erzählt mir (durch die Funktionen) Modul "xxxxxxxxx" "SENSOR_ERROR" "SENSOR1"
xx. Ich schicke meinem Webserver das es ein netter Versuch war aber er sollte die nächste Version des Programms abwarten.
... so im groben.

Welche Befehle für die unkomplizierte Kommunikation unter den Modulen sinnvoll sind und welche nicht wird die Praxis zeigen.
(oben schon erzählt)
Die Datentypen bzw. Definitionen / Parameter / werden vom Modul selbst festgelegt...
...vielleicht in einem XML-Mapping direkt neben der vorgeschriebenen Config jedes Moduls.

...
Das ist ja nur der Begin und die Überlegung der Geschichte meinerseits.
Ob der AppServer dann auch SMIRS-Geschichten über einen SCHNITTSTELLEBMODUL_SMIRS macht oder gleich dies in erweiterter Form verwendet...

...

Das nach Marketing-Gefasel ist nur gewählt um Breitbandig ... Intensionen zu vermitteln ;-)
...

Ich hoffe das ich manches Beantwortet habe.
Ich bin leider erst nächste Woche wieder da...

Netter Gruß,
Chris

EDIT:
Gerade erst das Thema des Threads nochmal gelesen.
Diese Schnittstelle zum WWW hat dann nochmal 10 Seiten zur Folge...
...glatt überlesen.
Wenn ich das Ding (WWW-GUI) schreibe im RFC Standard und in Verbindung mit dem hier Beschrieben Standards für alle Layer aufsetze sollte es genügen. Denn darüber zu plaudern dauert fast länger als einen Prototype zu entwerfen ;-)

@UlrichC
Ja, steht da, www :-)
Schön das du auch die Visionen nicht zu kurz kommen lässt.
Es wird ein 3D Visualisierungsmodul geben welches sich der heute gebräuchlichen 3D Grafikkarten bedient.
Die ermittelten Karten werden samt Robi aus allen Blickwinkeln visualisiert werden können.
Es wird Module geben die Roboter verkörpern die noch nicht gebaut wurden aber schon in dieser Umgebung fahren und getestet werden können.
Die Daten im Netz müssen keine echten sein sowohl die Umgebung wie die Roboter können virtuell sein.
Wenn einer mit seinem noch nicht gebauten Roboter in einer virtuellen Umgebung agieren kann wird er vielleicht auch mehrere Roboter fahren lassen, kost ja nix.
Andere könnten die Idee haben da auch mit mitfahren zu wollen.
Kein Problem mal bisschen Schwarmverhalten zu forschen………

ja ich hör schon auf.

Aber ich denke die Bedeutung des Projektes ist viel größer als manche ahnen.
Netter Gruß

@UlrichC:
Ok, das mit der GUI klingt ja super so. Klingt zwar auch
nach viel Arbeit aber wenn du dich anbietest da ein
Grundgerüst zu schreiben ;-)

Eins möchte ich aber noch klarstellen:
Das System wie ich es hier geplant habe (nennen wir es mal
uCom) und smirs sind zwei verschiedene Paar Stiefel. Beide
haben zwar ähnliche Ziele (Kommunikation zwischen Roboter-
modulen) aber unterschiedliche Voraussetzungen, vor allem
in der Hardware. Smirs erfordert relativ große Rechner mit
IP-Anbindung. uCom hingegen soll bis hinunter zum kleinsten
uC skalieren. Der Nachteil von uCom ist natürlich, das das
System Beschränkungen hat, dafür kann man eben auch Roboter
die nur auf uCs aufbauen noch anschliessen (und das sollten
die meisten hier im RN sein).

Noch was: Beide Systeme sind dafür ausgelegt, mehrere Roboter-
komponenten und u.U. auch mehrere Roboter zu verbinden. Der
Plan ist, die GUI dann als einen Teil in diese Infrastruktur
einzuklinken. Es ist also nicht der Plan, hinter dem Application
Server bzw. der GUI noch weitere Applikationen/Roboter
anzuschliessen. Wenn man es gratis dazubekommt soll es mir
natürlich recht sein, aber es sicher kein Designziel.

Und jetzt noch ein Wort zu SOAP. Prinzipiell finde ich die
Idee mit SOAP/XML schon ziemlich reizvoll, insbesondere weil
man typisierte und selbstbeschreibende Daten/Funktionen verwenden
kann. Allerdings ist SOAP auch ein Protokoll, das nicht unbedingt
wenig Overhead erzeugt (in der Übertragung und in der Verarbeitung).
Auf einem PC mag das tragbar sein, auf einem uC mit zweikritischen
Aufgaben aber nicht. Ich hatte bisher immer ein Datenformat mit
einem Byte 'Command' im Auge, der dann implizit die Struktur der
restlichen Daten bestimmt. Wobei es natürlich auch möglich wäre,
das es ein Command 'SOAP' gibt, das nun mal nur die dickeren bzw.
die nicht zeitkritischen uCs implementieren.

ciao,
Georg

Hallo Leute,

es muß Kongretter werden sonst steige ich aus.
Ich habe schon mal wochen lange diskutiert nd dann wochen Programmiert und jetzt habe ich viel gelernt und das wars dann das wäre dann das dritte oder vier mal hier im forum.

Ich versuche das jetzt mal ein bisschen zu trennen UlrichC hätte gerne einen der für Ihn alles macht. Was sicher auch für die meinsten VB programmieren hier unter uns zu trifft. UlrichC zwar aus anderen gründe aber das ist ja mal egal.

Wir sind uns einig das echte textteile für RS232 und für AVR einfach zu heftig sind oder in der PC welt kein problem und schön weil sie lesen kann.

Drum bin ich der Meinung das wir das trennen müssen so weh wie das auch tut.

PicNick hat folgen auf bau beschrieben:

HEADER / SOURCE-ID / DESTINATION-ID / MsgNR / Action /DataLen / Data (optional).......

Den finde ich gar nicht mal schlecht.
Wir müssen nur ein Teil tauschen die MsgNR denn nummer eindeutig durch das sytem zu bekommen wird nix.
Ich würde daraus ein resposnummer machen mit der größe ein WORD das sollte hin passen.

Meine Defintion von der Message:

HEADER = 3 byte => immer RNM => RoboterNetzMessage
SOURCE = 2 Byte => WORD 0000 und FFFF dürfen nicht verwendet werden.
DESTINATION = 2 Byte => WORD 0000 und FFFF dürfen nicht verwendet werden.
resposnummer = 2 Byte => WORD
Action = 2 BYte => WORD => 65535 Aktionen
DataLen = 2 Byte => WORD wieviel Bytes kommen noch bis ende
Data = 0 Byte bis 65535

Aktionen im Bereich von 0 bis 4000 sind fest definiert und drüber darf jeder machen was er will
ich denke 4000 Sollte reiche die zahl ist aber nur aus gedacht.

Wird könnten so eine art DHCP machen:

wenn was online geht dann muß es grundsätzlich mal so eine Nachricht schicken:
RNM HEADER
<00><00> SOURCE
<FF><FF> DESTINATION
<00><00> resposnummer
<00><00> Action
<00><00> DataLen

Das ist jetzt die Broadcast anfrage nach einer eingener ID.

Kommt inerhalb von 5 sec keine Antwort war man wohl der Erste und darf sich was aussuchen.

Bekommt man die Antwort:
RNM<ID des Senden modules><00<00><00><00><00><01><00><01><Neue ID>
Gibt es einen der die Id's vergibt.

Bekommt man:
RNM<ID des Senden modules><00<00><00><00><00><02><00><00>
kann man sich zwar eine aus suchen aber diese ID's sind schon in verwendung.

Das baucht man natürlich nur wenn man unbedingt dynamiche adressen vergabe braucht.
Im internet muß auch einer die Ip's in den DNS reinkopfen.

Wie finden ich meinen Weg:
RNM<ID des Senden modules><FF><FF><00><01><00><03><00><00>
Wird jetz von dem modul gesendet. Trift es jetzt auf ein Teil welche weiß das es Procy spiel muß
wird einfach RNM<ID des Senden modules><FF><FF><00><01><00><03><00><01><ID des Proxy moduls>
daus und wenn ein zweite kommt kommt noch ein word dran.

Was ist ein Proxymodul:
ein AVR der zu Beispiel eine RS232 hat und auf der anderen seite ein IC2 Bus muß jetz sein ID anhängen.
und per RS232 weiter schicken so weiß der PC die ID'S die Hinter dem AVR am RS232 Port hängen.

Wenn jetzt ein PC modul an der AVR Hinter dem Proxy AVR was schicken will macht er einfach:
RNM<ID des Senden modules><id Procy><resposnummer><00><04><länge nachricht><nachricht>
wo bei die nachricht wieder ganz normal auf gebaut ist mit ausnahme des RNM vorne dran.

Bei PC => IC2 verbindung muß halt die ID und die Adresse des I²C Gleich sein.

So jetzt bin ich mal gespannt.
In den 4000 Actions könnte man dann auch nocht die smir's Telegramme verstecken.
gibt halt ein großes Dokument aber mit ein bisschen sorgfallt sollte es klappen.

Auf dem PC könnte man dann in der smirs welt nocht die ID's durch namen ersetzt dann wird es lesbarer.

so jetzt habe ich mir die halbe nach um die Ohren gehauen nur weil ich diesen text nicht lassen
konnte obwohl ich eineglich mal mein Robi zum laufen bringen sollte.

Gruß

So nochmal (ich sollte eigentlich was anders tun),
@marvin42x
Sorry...Die Visonen gehen bei mir immer so schnell aus.
Bei Roboterschwärmen denke ich eigentlich gleich an Online-Games *itsReal*

@ragnar
Ja ich werde mal einen Prototypen der GUI schreiben.
Das umliegende System der Webapplikation aber nicht vom scretch programmieren.

@NumberFive
Ich möchte nicht alles machen lassen, lediglich eine Standard Programmierschnittstelle.
Denn eine Protokollschnittstelle ist sehr erklärungsbedürftig somal der Standard-Roboter in weiter ferne liegt.
Mir ist klar daß ich die auch selber schreiben muß. Und ich habe schon x mal hier geschrieben das diese dann auch auf Smirs aufsetzen kann.
Aber solange keine Einigkeit gefunden ist ... und der SMIRS-Entwickler sich noch über erweiteungen am Protokoll verschweigt... dreh ich Daumen und schreibe WWW-GUI
... ob dann die Oberfläch nur mit eigem Zeug funzt oder auf einer Schnittstelle sitzt ... ist dann ein portierungsaufwand von wenigen Stunden für mich.
Und ich werde einen Teufel tun um hier erstmal fröhlich Prototypen (ferner www-GUI) zu schreiben um hinterher festzustellen das die SMIRS verwendet werden soll.

Denn die Teile die ich dann bereitwillig programmieren würde...
AppServer
Objekt zur Ableitung (schnittstellen)
Treiber für den ersten Roboter (Demo/Vorlage)
... schreiben sich nicht von selbst.
(Steht da alles schwarz auf Blau)

...jetzt muß ich aber wieder anderes tun.

Netter Gruß, SO LONG AND THX FOR ALL THE FISH,
Chris

EDIT:
Boa bin ich durchnächtigt... ich raf den Text nicht mehr.
Das beste ist wenn ich vorerst nur mit dem Modulen WWW-GUI und dem eigenen Robotermodul (auf tcp/ip basis) beginne..in zwei-drei Wochen muß mir dann einer sagen auf welchen Standard ich aufsetzen kann. (um mein gehack zu verschabeln) ... hierzu brauche ich erstmal keinen anderen Code (selbst ist die Frau)
Den Appserver habe ich schon bei einem weiteren bekannten programmierer angefragt... wenn muß dann wird.

@NumberFive
Ich schreib Dir eine Mail wenn ich wieder fit bin ;-)

Hallo nochmal (ich bin eigentlich gar nich da *pssst*),
ich hab nochmal in der Mittagspause den Kopf rauchen lassen.

Also meine Intension ist wirklich so ne Art VB-ActiveX Com+ für Module (Nur ohne Registrie) ... darum diese mini-plattform AppServer für Plattformunabhängige komunikation .. die ähnlich wie AktiveX bedient werden kann. ...über Aufruf der registrierten Funktionen... ohne Protokoll...sondern mit einer Programmierschnittstelle.
Dies muß aber auch nicht unbedingt ein Standard werden. Lediglich ein Feature/Bereicherung des Standarts. Denn ich könnte auch dieses Ding einem evtl. Standard anpassen. Intern könnte ich aufgrund der Trennung von Protokoll und Programmierung verfahren wie ich wollte.

Denkbare Architekturen von AppServer aus.
AppServer<->AppServer
..oder
AppServer<->LoginServer (SMIRS)
..oder
AppServer<->RN-VerbindungsLayerHandler

... dies kann dann später wenn der Standard funzt programmiert werden.

Auf den Teil der Architektur bin ich noch nicht eingegandgen daher ist dies was neues ;-) aber eine weitere Abgrenzung ... so könnte ich ja fröhlich beginnen.


Gruß,
Chris

@NumberFive
Zur Umsetzung von Binärdaten auf Menschenlesbare Daten:
Ja, menschenlesbare Daten wären schön, sind aber auf dem uC nicht
zu machen. Wenn ich dich richtig verstanden habe, willst du die
Binärdaten an irgendeiner Stelle _im_ Kommunikationssystem in
Menschenlesbare Daten umsetzen.

Für einen Teil der Daten (z.B. Adressen) ist das eine gute Idee.
Allerdings würde ich die Adressen erst direkt vor der Darstellung
(z.B. im Debuggingtool) umsetzen.

Bei den verbleibenden Daten ist dies noch schwieriger. Diese hängen
nämlich z.B. vom Kommando ab. Um die Daten umzusetzen muß der
Umsetzer also wissen wie er die Daten zu verstehen hat. Das ist
fehlerträchtig, denn es kann jederzeit neue Kommandos oder geänderte
Datenstrukturen geben. Um die Daten möglichst lokal zu halten, würde
ich auch hier die Daten erst direkt vor der Ausgabe umsetzen. Das
Schlimmste was dann passieren kann ist das die ausgegenen Daten nicht
gültig sind.

Zitat:

---

Zitat von NumberFive

Wird könnten so eine art DHCP machen:
[...]

---

Was du beschreibst hat leider ein Problem:
Der "DHCP" Response kann nicht so ohne weiteres zurückgeschickt
werden denn der Anfragende hat ja noch keine Adresse.

Prinzipiell natürlich trotzdem möglich, es liegt dann aber in
der Routingschicht und ist eine spezielle Nachricht außerhalb
des Msg-Modells von dir (eine Schicht drunter)

Ein weiteres Problem dabei: Wie können die Module dann
untereinander kommunizieren? Woher erfahren sie die
(dynamisch vergebene) Adresse ihres Kommunikationspartners?
"DHCP" erfordert also auch eine Art "DNS" (bzw. eine Registry),
mit der man die Adresse seines Kommunikationspartners anhand
bestimmter Merkmale (Name, angeboteten Dienste, ...) heraus-
finden kann.

Zu deinen Ideen zum Routing:
Das ganz große Problem das ich bei dir sehe ist, daß die
Knoten hinter Proxys ihre eigene Adresse nicht kennen (denn
die wird ja vom Proxy 'mitbestimmt'). Außerdem sind mir die
unterschiedlich langen Adressen noch etwas suspekt und mir ist
nicht klar, wie Nachrichten zwischen verschiedenen Modulen
geroutet werden sollen. Außerdem muß bei deinem Ansatz IMHO
immer eine Oberste Ebene als Bezugspunkt existieren.

ciao,
Georg

Hallo, ihr da vom Thread der Doktoranden und Nachtarbeiter !
Ich leb' schon auch noch.
Immer wenn's kompliziert wird, geh' ich gern den Weg der "Ausserstreitstellung", d.h. ich schau mir einmal genau an, was nicht strittig ist und trotzdem unerlässlich. Das versuch ich mal zu lösen, auch um zu sehen, wo's hapert. Da nehm ich auch ein paar Leerkilometer in Kauf.
Wir haben nämlich dauernd die Stituation, daß vor diesem und jenem eigentlich vorher noch was anderes zu klären wäre, und das setzt sich fort und man kommt zu keinem Ende oder Anfang oder, schlimmer, was weiß nicht mehr was Ende oder Anfang ist.

Egal: da bei mir PCs und Midranges durch die berufliche Tätigkeit immer ein leichtes Grausen auslösen, schau ich mir einmal genauer die Umsetzungsmöglichkeiten auf AVRs an. Ein paar Versuche hab' ich ja schon gemacht, Marvin42 weiß das.
Ich halte es nämlich auch für wichtig, eine ZUMUTBARE Library dafür zu entwerfen. Wenn der µC nämlich nix anderes mehr kann als netzwerken, setzt sich das Ganze niemals durch.

Mal sehen

Hallo,
ich kann die Finger nicht raushalten.
Aber spezifizieren mag ich nun nicht...

Ich wollte nur mal einen Ansatz bzw. ein Punkt wo die Meinungen vielleicht noch Auseinanderlaufen untermalen
Und zwar ...

Zitat:

---

Zitat von PicNick

Ich halte es nämlich auch für wichtig, eine ZUMUTBARE Library dafür zu entwerfen. Wenn der µC nämlich nix anderes mehr kann als netzwerken, setzt sich das Ganze niemals durch.

---

Ja das sollte auf jeden Fall auch das Ziel sein und zwar an beiden Enden des Systems.

Und hierbei möchte ich noch zus. Intensionen loswerden.
Eine Kapselung des Protokolls in eine verständliche bis einfache Schnittstelle für den Verwender.
Jedenfalls habe ich die Fahne auf der PC-Seite des Systems hierfür auch schon gehalten.
..und das nicht aus Einfachheits- bis Faulheits- gründen...sondern
Eine Programmierschnittstelle (+Spezifikation) verbaut in einer Bibliothek (Lib) ist sozusagen die Lebensversicherung des Systems.
Das Protokoll + API selbst kann sich dann *ändern wenn es notwendig wird.
Der Verwender des Systems sollte einfach durch kompilieren seines Codes mit der "dann neuen Lib" Standardkonform bleiben ohne eigenen Code ändern zu müssen.

Jedenfalls ist man das als Programmierer/Anwender so gewohnt.
Falls sich wirklich Anwender für einen eventuellen *Standard finden sollten dann sollten diese über alle Versionen erhalten bleiben.
Ich würde als Normal-Modul-Programmierer (nicht API Schreiber) wahre Freudensprünge im Dreieck machen,
wenn ich alles wegen eines Denkfehlers oder einer Erweiterung die eine Änderung des Protokolls zu Folge hatten,
die Kommunikation umtexten müsste.

Diese Schnittstellenfunktionen werden so oder so geschrieben ... nur wenn die nicht in der Lib zur API liegen muß diese jeder für sich anpassen.
In einem Fall wären es [Support "+Punkte"] im anderen [Standard "-Punkte"].

*Änderungen ... gibt’s oft:
... neue Features neue Bugs *isKlar* Workarounds
... andre Encodings (Vielleicht wird mein Unicode nun doch anders Interpretiert)
... mehr Funktionalität (Vielleicht wird alles aufgebohrt ... und man muss explizit den verwendeten Standard im Protokoll mitschicken... um gewohnt verfahren zu können)
... anderes Handling des Protokolls (Vielleicht müssen Commands vorgeschoben oder bestätigt werden)
... schnellere Reglungen (vielleicht ändert sich die Kommunikation grundlegend um Connects/Syncs zu sparen)
... obsolet Commands (manche zuerst als sinnvoll erscheinenden Funktionen des Protokolls werden ersetz / oder erweisen sich als unsicher)
... mehr Sicherheit (vielleicht läuft in naher Zukunft alles Verschlüsselt durch die Leitung)
... weitere Interfaces (feileicht müssen die Adressräume geändert werden weil die vorgesehenen 2 Byte doch nicht reichen)
etc.

*Standard wird nur verwendet wenn es Vorteile bringt.. Vorteile sind verschieden geartet
... Kompatible Zusatzsoftware
... Zeit/Kostenersparnis
... KnowHow-Gewinn
... Funktionsgewinn
etc.

Ist schon wieder ein Roman geworden... *sorry*

Netter Gruß,
Chris

Aus meiner Berufspraxis, die nichts mit Programmieren zu tun hat, weis ich, dass ein Pendeln zwischen Überlegungen und Prototypen am fruchtbarsten für Entwicklungen war.

Ich würde daher vorschlagen diese Möglichkeit in Betracht zu ziehen.

Die Liste der Vorteile ist lang. Weder nur Überlegung noch nur Prototyping vermögen das zu leisten.

Wir müssen auch bedenken, dass die serielle Kommunikation eines Textes im Forum Schwierigkeiten hat mit der Darstellung mehrerer mehrdimensionaler Topologieentwürfe wie sie hier erörtert werden. UlrichC hat da mit seiner Grafik schon mal zur geeigneteren Waffe gegriffen. Prototypen erzwingt Festlegung und bildet gleichzeitig die Idee beispielhaft ab ohne Änderungen im Weg zu stehen. Er ist gleichzeitig von allen einsehbarer Stand der Dinge.
Frage:
Wäre es sinnvoll eine minimale Topologie aufzubauen die z.B. zwei Sachen kann. Get var und Put var um am Objekt weiter zu Entwickeln.
Das würde sich dann in etwa so anhören:
Auf der einen Seite haben wir bereits mindestens ein lauffähiges Betriebssystem für einen Mega32 wenn man das modifiziert, das es put und get für eine variable kann. Die lib dazu auch minimal auf diese zwei Funktionen beschränkt.
Wie die Lib das macht wäre erstmal egal
Wie das Prokoll aussieht wäre erstmal egal.
Der Apserver sollte zu Studienzwecken nur…….usw.

Ein Mega32 der, über einen Apserver, auf einer GUI in einem Textfeld seine Batterispannung ausgibt.
Auf dieser Basis ließe sich vortrefflich:
Erweitern
Verwerfen
Neu entwerfen
Erfahrungen einbauen
Probleme erkennen
Aufgabenbereiche abgrenzen
Schnittstellen erschaffen……..na ja usw.
Netter Gruß

Zitat:

---

Zitat von ragnar

... Ich hatte bisher immer ein Datenformat mit einem Byte 'Command' im Auge, der dann implizit die Struktur der restlichen Daten bestimmt. Wobei es natürlich auch möglich wäre, das es ein Command 'SOAP' gibt, das nun mal nur die dickeren bzw. die nicht zeitkritischen uCs implementieren ...

---

... das lässt mich an P-Code denken.
Ob ich jetzt unter einer virtuellen Maschine einen Prozessor oder einen Roboter verstehe. Ist doch auch nichts anderes.

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.

@NumberFive:
Ich würde einer Aufteilung des Threads wenn es für euch Sinn macht in keiner Weise im Wege stehen. Müsstet Ihr aber machen. Ich kenne mich mit Forumstechnik nicht so gut aus. Oder Ihr sagt mir wie ich es machen soll. Mir ist nur das Projekt als solches wichtig.
Zur Downloadfrage, schick dem Frank doch lieber eine Nachricht. Da ist es dann nicht so dem Zufall überlassen.

In diesem Sinne:
Mut zur Lücke

... soll doch nix wegschmeißen. [-X
Ich habe gerade den USER'S GUIDE für CP/NET aus dem Jahr 1980 (Digital Research) in der Hand.

Ich schreibe mal einige Stellen ab:

Code:

---

.-----.-----.-----.-----.-----.--------- - - -.
| FMT | DID | SID | FNC | SIZ | MSG          |
'-----'-----'-----'-----'-----'--------- - - -'
  |    |    |    |    |    |
  |    |    |    |    |    Actual Message, Size + 1 Bytes
  |    |    |    |    Size, Data field lenght -1
  |    |    |    CP/M, MP/M Function code
  |    |    Message souce processor ID
  |    Message destination processor ID
  Message format code


        Message Field Length Table
      .-----.-----.-----.-----.-----.-----.
FMT    | FMT | DID | SID | FNC | SIZ | MSG |
Code  '-----'-----'-----'-----'-----'-----'
 00      1    1    1    1    1    1-256        Preferred format       
 01      1    1    1    1    1    1-256        Returned result       
 02      1    1    1    1    2    1-65536
 03      1    1    1    1    2    1-65536 Returned result
 04      1    2    2    1    1    1-256
 05      1    2    2    1    1    1-256  Returned result
 06      1    2    2    1    2    1-65536
 07      1    2    2    1    2    1-65536 Returned result

---

Code:

---

CP/NET Logical Message Specification
ss = Server ID
rr = Requestor ID
xx = Don't care byte
nn = Value specified

 FMT  DID  SID  FNC  SIZ  MSG / Function Name       
.----.----.----.----.----.------------------------.
|    |    |    |    |    | System Reset          |
| 00 | ss | rr | 00 | 00 | 00-00 = xx            |
| 01 | rr | ss | 00 | 00 | 00-00 = 00            |
|----+----+----+----+----+------------------------|
|    |    |    |    |    | Console Input          |
| 00 | ss | rr | 01 | 00 | 00-00 = xx            |
| 01 | rr | ss | 01 | 00 | 00-00 = 00            |
|----+----+----+----+----+------------------------|
|    |    |    |    |    | Console Output        |
| 00 | ss | rr | 02 | 00 | 00-00 = xx            |
| 01 | rr | ss | 02 | 00 | 00-00 = 00            |
|----+----+----+----+----+------------------------|
|    |    |    |    |    | RAW Console Input      |
| 00 | ss | rr | 03 | 00 | 00-00 = xx            |
| 01 | rr | ss | 03 | 00 | 00-00 = 00            |
|----+----+----+----+----+------------------------|
|    |    |    |    |    | RAW Console Output    |
| 00 | ss | rr | 04 | 00 | 00-00 = xx            |
| 01 | rr | ss | 04 | 00 | 00-00 = 00            |
|----+----+----+----+----+------------------------|
|    |    |    |    |    |                        |
.    .    .    .    .    .                        .
|    |    |    |    |    |                        |
|----+----+----+----+----+------------------------|
|    |    |    |    |    | Return Version Number  |
| 00 | ss | rr | 0C | 00 | 00-00 = xx            |
| 01 | rr | ss | 0C | 00 | 00-00 = 00            |
|----+----+----+----+----+------------------------|
.    .    .    .    .    .                        .
|    |    |    |    |    |                        |
'----'----'----'----'----'------------------------'

---

Code:

---

Recommend Server-Requester Handshake for RS-232C
.-----.-----.-----.-----.-----.-----.-----.-----.-----.-----.-  -.-----.-----.-----.
| ENQ | SOH | FMT | DID | SID | FNC | SIZ | HCS | STX | MSG | ::: | ETX | CKS | EOT |       
'-----'-----'-----'-----'-----'-----'-----'-----'-----'-----'-  -'-----'-----'-----'
Messages format codes 00 & 01 are recommended

ENQ = Enquire, one byte, 05H
SOH = Start of Header, one byte, 01H
FMT,DID,SID,FNC,SIZ = as defined, onebyte per field
HCS = Header Checksum, one byte
STX = Start of Data, one byte, 02H
MSG = SIZ + 1 bytes long
ETX = End of Data, one byte, 03H
CKS = Checksum, one byte
EOT = End of Transmission, one byte, 04H

Source                Destination        Comment
5 - ENQ        ------->
        <------- ACK - 6

1 - SOH ------->
    FMT ------->
    DID ------->
    SID ------->
    FNC ------->
    SIZ ------->
    HCS ------->        Modulo 256 sum from SOH to HCS = 0
        <------- ACK -6

2 - STX ------->
    DB0 ------->        First data Byte
        ....
    DBn ------->
3 - ETX ------->
    CKS ------->        Modulo 256 sum from STX to CKS = 0   
4 - EOT ------->
        <------- ACK -6

---

Da ist einer fleißig wie ein Eichhörnchen und trägt Nuss für Nuss zusammen. Im Wissensbereich gibt es ein neues Kapitel „Betriebssystem für Bascom“.
Oder hätte ich das jetzt nicht petzen sollen?
@PicNick:
Da hast Du mir ja Stoff gegeben.. Muss ich mir erst mal unters Kopfkissen legen. Das ist halt ein bildschönes System
Danke, dass Du das über so eine gute Dokumentation bereitstellst.

Netter Gruß

@Vogon: Schau mal unter "DDCMP" (is auch in der wikipedia).
Zum Abschauen isses gut , ansonst für µC etwas über-drüber.

@PicNik: Das ist aus dem Jahr 1984. Da ist noch weiter Ausgebaut.

Ja, so habe ich das auch gedacht. Zum Abschauen isses gut.
Das es etwas über-drüber ist - klar für ein MultiuserMultitask (mit 8080, Z80) war das sicher notwendig. Aber man kann sich ja an einem System das recht ordendlich funktioniert hat orientieren.
Und wenn man mal von einem AVR zu einem DSP mit FunkLan wechselt soll es ja auch noch gehen.

Wir haben damals mit DDCMP die PCs an VMS Maschinen gehängt und sind DecNet drüber gefahren, wenn Dir das was sagt.
Es ist ein gutes Beispiel, schlimmer kann's nämlich nicht werden.

Ähnlich isses mit SLIP (serial line IP)

Zitat:

---

Zitat von NumberFive

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.

---

Hi,
ich schau nur sproatisch mal in diesen Thread, ich hab bislang aus Zeitmangel nicht alles genau verfolgt. Momentan steht bei mir in der Art auch nix an, so das ich mich da nicht beteilige, aber bin gespannt was ihr da auf die Beine stellt.
Wie umfangreich sind denn die SMIR Sachen. Wenn man alles zusammen in ein ZIP-File stecken könnte und das unter 3 MB groß ist, dann könnte man es z.B. unter einer neuen Rubrik "Open Source Projekte" ablegen. Eine ganz eigene Rubrik für Smir wäre glaube etwas zuviel. Da das aktuallisieren nicht so einfach im Downloadbereich ist, wäre es natürlich Vorteilhaft wenn man nur gewisse Endversionen oder stabilere Beta-Versionen dort ablegt. Oder man verlinkt dort eine Datei von Euren Server.

Gruß Frank

Als zip und kompiliert sind es zur Zeit 890 KB.

Ok ich stelle es mal bei Opensource rein. Damit wer will spielen bzw. Probieren kann.

EDIT:

Da es die Rubirk noc nicht gibt vorrest unter Andere dateien

Gruß
PS: Ich hoffe Frank verschiebt es dann die Rubrik könnte ja auch RN Projekte heissen.

Ich habe die Rubriken etwas umgestaltet. Es liegt nun unter weitere RN-Projekte:
https://www.roboternetz.de/phpBB2/dl...gory&cat_id=15

@NumberFive:
Anmerkung zu Deiner Datei im Downloadbereich.
Wäre es möglich noch ein Minisystem für z.B. einen Mega32 dazuzulegen welches zwei Sensorwerte über die serielle nach deinem Protokoll kommuniziert? Oder ein gleichwertiges Pseudomodul?
Dann würde das System als Gesamtheit agieren.
Da Deine anderen Komponenten schon laufen wäre es dann eine komplette Funktionseinheit die gut vorführ- und verstehbar wäre (falls ich nichts übersehen habe)
Das wäre für alle die, die sich aus den vorgetragenen theoretischen Überlegungen noch kein Bild machen können.
Das wäre nicht unbedingt als ein Beitrag zur Entwicklung gemeint aber ein Beitrag zur Demonstration, Werbung und Motivation. Ein wesendlicher Teilaspekt mit dem wir verhindern können, dass das hier nur eine Diskussion bleibt.
Netter Gruß

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