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

[marvin42x]

Nachtrag:

Die GUI's nehmen ja nur eingeschränkt am Plug and Play teil.

Mehr solln se nich, hat der Wiener gesagt, na und, eben nicht, macht mir garnichts. dann sagen wir auch nix im Absender.

Netter Gruß

[PicNick]

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.

Bei IP können (müssen) wir die in die Anmeldung irgendwie noch eine ID reinquetschen. Wenn alle Applikationen point-to-point direkt mit dem Server reden, würde das dann reichen, dass die Burschen auch untereinander können.

EDIT: auf der PC-Seite haben wir kein Platzproblem, wir könnten da genausogut Text-Adressen zulassen.


EDIT II: Ich richt' mich PC-Seitig gern nach euch

[PicNick]

Nachtrag:
Die GUI's nehmen ja nur eingeschränkt am Plug and Play teil.

Mehr solln se nich, hat der Wiener gesagt, na und, eben nicht, macht mir garnichts. dann sagen wir auch nix im Absender.

Wenn bei der Anmeldung eine GUI ein Kennzeichen liefert, wer sie wohl sei, haben wir auch da kein Problem

[PicNick]

BTW: Was hieltest du/ihr davon, bei allen RnCOm Rechnern, die mitspielen wollen, die eigene I2C Adresse im EERAM ganz vorne zu speichern.
Dann kann man sie direkt im Pony oder im Bascom-Brenner einstellen, ohne in das eigentliche Programm angreifen zu müssen.
(Klaro ? EERAM auslesen, 1. Byte editieren, zurückladen)

Irgendwelchen "I2C Adresse-Setzen"-Befehlsfolgen würden entfallen. Schon garnicht kompilieren müssen.

Die üblichen Methoden sind sowieso etwas halbseiden, da man ja dazu meist alle anderen I2C Geräte deaktivieren muss oder sonst irgendwelche Tricky Things.

Und Pins jumpern kann es ja auch nicht sein.


Weiteres: Die Rechner-ID könnte man gleich dahinter speichern, und eigenlich auch einen Ident-Offset (das wäre +10 bei den Servos im zweiten RnBFRA, zum Beispiel)

[marvin42x]

Das mit dem EERAM hört sich gut an.
Ich bin leider nicht kompetent genug um das vollständig bewerten zu können.
Aber der Sound ist gut. Von mir aus gerne. Da kann man dann ein neues Programm laden und muss sich keine Gedanken um die ID zu machen.
Außerdem ist die Entscheidung ja nicht so schwerwiegend. Wenn es und nicht mehr gefällt machen wir es anders.

PC-Seitig:
Wir machen mal wie Du denkst, das sieht im Moment gut aus. Ich wollte nur mal ein bisschen lamentieren .
Auch da werden wir sehen wie es sich bewährt und dementsprechend weiter verfahren.
Es beginnt wieder so eine schöne Zeit wo Ideen das Laufen üben und man zwischen Tests und Entwicklung immer im Wandel ist.

Nette Gruß

[Vogon]

... Bei der RNBFRA KArte direkt am Com-port wär das einfach, die ist ja immer eindeutig....

Das möcht ich dir ja glauben, aber wie ist das wenn an dem Com-Port ein Funkmodul hängt, das sich mit mehreren Empfängern unterhalten möchte?

[marvin42x]

Ich sehe ja da PicNicks Vorschlag mit dem EERAM mächtig Fahrt aufnehmen.
Damit wäre eine Menge an Identitäts-Findung elegant vom Tisch.
Auch die Frage von mehreren RS232 Beteiligten. Was man ja auch bei einer Schnittstellen -Umsetzung auf RS485 erwarten müsste.

Netter Gruß

[PicNick]

..Com-Port ein Funkmodul hängt, das sich mit mehreren Empfängern

Da wird zwar Bitmäßig "UART" gesprochen, aber die Kontrolle der Verbindungen zu den einzelnen Emfängern ist dann eins drauf.
Könnte ja genausogut auch Wählmodems sein.

Aber di hast recht: so schlampig sollt' man nicht sein, wir setzen ja "COM" mit der RS232-Kable Konfiguration gleich.

[marvin42x]

@PicNick:
PC-Seitige IP_Komunikation:

Da wir demnächst vermutlich auch Daten über die neue Infrastruktur schicken werden. Würde ich gerne noch mal über den Message-Aufbau auf der IP-Seite reden.
Schade ist, das ich ziemlich unerfahren damit bin, was aber auch seine Vorteile haben könnte. Ich kann also keine ausgefeilte Empfangsroutine herstellen die clever genug ist die Allüren der TCP/IP-Übertragung abzufedern.
Speziell ist hier die Eigenart der TCP-Verbindung gemeint die Pakete nicht so zu senden oder zu empfangen wie man sie schnürt.
Ich weis, dass Deine Clients damit kein Problem haben.
Meiner schon.
Mir wäre es lieber ich könnte die rein kommenden Pakete, egal wie Sie zusammengesetzt sind, schlicht aneinander hängen.
Gestützt durch ein Startzeichen und eine anschließende Längenangabe zurechtsägen.
Die nun eindeutigen Message nach unseren Spezifikationen, wie Adressen usw. auswerten.
Wie ich Eingangs sagte: Kann sein das ich zu unbeholfen mit dem TCP bin.
Da wir auf der IP-Seite aber keine Platznot haben würden wir eine leicht zu implementierende Messageform haben die auch ein Anfänger packt.

Eine andere Alternative wäre, das so in eine Dll zu packen das es seine Kanten verliert?
Was meinst Du?


GUI-Identität:
Das mit der GUI-ID würde mir stilmäßig gefallen. Alle sagen wer sie sind und was sie drauf haben.
Nur die PC-Aplikationen schweigen sich aus, das fühlt sich irgendwie schräg an.
Wobei ich auch mit schrägen Sachen gut leben kann.

Was meinst Du?

Netter Gruß

[PicNick]

Ich muß mir mal anschauen, was sich mit dem IP Gerümpel machen läßt, damit man das einfach verwenden kann. Irgendwas DLL mäßiges, das ist wohl am ehesten sprachenunabhängig. Mal sehen.

Im Prinzip können wir das mit den ID's von irgendwem auch bleiben lassen.
Es gibt ja die Zieladresse "IAM", wo man eine ID hinterlegen kann. Wenn einer das sendet, isses gut, wenn nicht, kann man ihn halt nicht adressieren. wer nicht will, hat schon.