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

Zitat:

---

Zitat von NumberFive

.... ins level 0 ein bauen das nicht + plus hinter einander übertragen werden dürfen...

---

Ich habe das gerade mal mit Testdaten geprüft.
Da brauch man nichts zu machen, denn es muss vor dem +++ eine kleine Pause kommen. Ich hab das so auch im Handbuch zu einem Modem gelesen habe.

Code:

---

+++ -- Escape Character Sequence. After you have connected to another modem, you may need to return to command mode to adjust the modem configuration, or more commonly, to hang up. To do this leave your keyboard idle (press no keys) for at least one second, then press "+" three times

---

Das sind meine Testdaten, übertragen mit Hyperterm im Modus "Textdatei senden". Mein Funkmodul RT868F4 geht damit nicht in den Command-Modus.

Code:

---

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
+++xxx+++xxx+++  +++  +++  +++  +++  +++  +++  +++ 
Test Test Test Test Test Test Test Test Test Test Test Test

---

Hier die Beschreibung des Funkmoduls RT433F4:
Mit Registerbelegung
http://www.robotikhardware.de/download/rt433f4.pdf

Hier Easy-Radio:
http://www.robotikhardware.de/download/er400_d.pdf

Da diese Module Kanalwechsel, Sendeleistung und Baudrateneinstellungen und zum Teil Emfangsstärkeinformation unterstützen. Wäre es zu überlegen sie als aktive Komponente zu betrachten die zur Navigation und zum Übertragungsmanagement gehören. Sprich irgendwer möchte die Dinger auch on the fly bedienen wollen. Also wegen meiner erstmal ausmaskieren aber endgültig wahlweise ansprechen können.

Ich würde gerne mittesten aber meine zicken bös mit mir rum. Ich hab denen schon gesagt, wenn sie so weiter machen kommen sie ins Heim.

@Vogon :
müssen wir nachlesen ob das für die anderen Funkmodule auch gilt, wäre ja schön.

Netter Gruß

wenn ich den Post von Vogon richtig interpretiere sollte den funkmodems uns protokoll nix aus machen da ja nie +++ am anfang steht.

Programieren Hier alle eingenlich den AVR mit Bascom ?

Ragnar hat wohl heute nacht die Seite aktualiesiert jetzt wird es echt interessant. warum er das Level für TCP neu definieren will ist mir zwar noch nicht klar aber das werden wir bestimmt bald lesen können.

Mit Seiner Schicht 1 könnte ich ganz gut leben aber warum hat er immer noch die Länge drin ?

Was ich ein bisschen schade finde ist das er da so runter definiert aber es nicht bespricht. Jetzt sieht es so aus als währe es besprochen sache.

Mal sehen was da noch so kommt.

Gruß

Morgen !
Also gut, die +++ sind für uns mal gestorben, und die 1/2 duplex Funkerei klären wir noch.

Nachrichten über TCPIP-Stream müssen vorn eine Länge haben, 16 Bit sind verbreitet, also solle es so sein. NEtwork Order oder nicht können wir noch klären, is mir so oder so recht.
Ohne die Länge wirst du unglücklich, weil du sonst bei IP nie sicher weißt, wo ein (daten) Paket anfangt oder aufhört oder vielleicht auch noch im nächsten Block fortgesetzt wird (heißt ja auch "STREAM").
Eigentlich betrifft das den "Level-0" bei IP, ("level-0" aus unserer Sicht)

BASCOM programmieren sicher nicht alle. Aber wenn es sich dort gut einbauen läßt, geht's mit allem anderen allemal. Im Gegensatz zu Bascom gibt's für GCC schon mindestens 27 Betriebsystem-varianten, dort brauchen wir nur die RNCom-Standards modularisieren, wenn überhaupt.

Ich werke gerade daran, auch für den COProzessor von der RNBFRA eine adaption zu machen und die dann in das "RNSX"-Servo Programm einzubauen.
Ist ein guter Test: 2 unabhängige µC und 1-2 PC. Wenn das geht, geht alles.

Ob man sich die PICs auch zur Brust nehmen soll, werden wir sehen. Da gibt's eigentlich ausser Assembler nicht so einen verbreiteten Standard wie Bascom.

Zitat:

---

Zitat von marvin42x

...müssen wir nachlesen ob das für die anderen Funkmodule auch gilt, wäre ja schön...

---

Habe bei deinem Link zum Easy-Radio mal nachgeschaut.
Dort lese ich:

Code:

---

Die Programmier-Software sendet Text-Mitteilungen an die Module und diese Aktion kann über ein Terminalprogramm ....

Befehl            Funktion              Wert
ER_CMD#U1          UART Datenrate        2400
ER_CMD#U2                                4800
ER_CMD#U3                                9600
....
ER_CMD#P0          HF-Sendeleistung      1mW
....
ER_CMD#C0          Kanal 0              433.23 Mhz
...

---

Das ist also anders. Ob das mit dem Zeitverhalten auch so ist sollte jemand der diese Modula hat mal testen.
Da sie ja zur Datenübertragung gebaut werden liegt es ja nahe es so zu machen. In der DOC steht dazu nichts.
In der DOC zum RT433 und RT868 habe ich aber auch nichts dazu gelesen.

Was ich bei Easy geucht und nicht gefunden habe, waren konkrete Angaben zum Zeitverhalten bei Richtungsumkehr.
Ich glaub', Marvin hat ja das Zeugs, da werden wir schon noch dahinterkommen.


EDIT BTW, es gibt ja auch noch IR und anderes Teufelszeugs

Ich habe 2 Rn-funkmodule ausgestattet mit den Funkmodulen RT868F4 (FM-868...870MHz). Das sollten die gleichen sein wie die von Vogon.
Hatte gestern noch mit Ihnen in Freundschaft gesprochen aber konnte keine Einigung erzielen, jetzt kommen sie ins Heim für schwer erziehbare Funkmodule.
Wenn sie dann zurückkommen kann ich mich da rann machen.
Ich gehe mal gefühlsmäßig davon aus das die Erbauer der Funkmodule das Problem auch kannten und ein entsprechendes Design gemacht haben, aber man wird sehen…., den Weihnachtsmann soll’s ja auch nicht geben.

Netter Gruß aus der schon wieder eingeschneiten Hauptstadt

Ps. @PicNick: Sehr löbliches Tun, Deinen rn_server auf Port 42 horchen zu lassen ;-).

Also da wir unter der Paket grösse von tcp bleiben und ich ja ein start zeichen und ein eindeutinges ende Zeich habe glaube ich nicht das die länge so wichtig ist das sag mir zu mindestens mein erfahrung bis jetzt. aber es soll so sein.

dann würde der Tcp Stream also so aus sehen:
BYTE[0] = CTL_C_STX;
BYTE[1] = length Teil1
BYTE[2] = length Teil2
....
BYTE[N] = CTL_C_ETX;

die länge kommt das so rein
WORD Len;
memcpy(&Leve0[1],Len,2);

Ok ?

STX u. ETX brauchen wir bei IP nicht, natürlich auch kein Stuffing.
Am Einfachsten also (Längen-angaben immer daten-Netto)

Zitat:

---

Länge LSByte
Länge MSByte
Daten

---

memcpy is ok so.

:mrgreen: 42 is eine gute Wahl, denk ich. Etwas größer als 41 und trotzdem immer noch kleiner als 43 :mrgreen:

EDIT: btw: Meine IP send/receive haben so eine Art Auto-detect Mechanismus (optional).
Bei der ersten incom-Message probier ich die Varianten aus (Länge oder nicht, networkorder oder Intel) Wenn eins davon paßt, gilt das dann für die Dauer der ganzen Connection. Dann wird auch in dem Format zurückgeschickt.

Ein schönen eingeschneiten Sonntag wünsch' ich !

Kurz vorweggeschickt: Ich mach seit '92 praktisch nix anderes als Applikations-kommunikation von verschiedenen Plattformen (DEC-Alpha/VMS, IBM, PC, Sun, wasweissich) mit DecNet, IP, X25, Mq-Series, 3270, Wählmodem, Telnet, POP und Mail, (kermit *haha*), blabla.
Ich sag das nur, damit ihr wißt, daß ich eine gute Vorstellung habe, was mich einmal in der Hölle erwarten wird.

Und ich hab auch kein Problem, noch ein paar Layer zu definieren.

Aber im Zusammenhang mit µC, Robotern und harmlosen Amateur-Entwicklern bin ich mir nicht sicher, ob wir nicht das Ziel aus den Augen verlieren, nämlich ein einfaches Vernetzungssystem für PC- u. µC-Programme.

Wenn wir uns da was ausdenken, was dann aber nur abgefahrene Kampf-programmierer begreifen, geschweige denn anwenden können, halt ich das bei aller Perfektion für danebengeschossen.

Wir haben jetzt eine gute UART-Level-0 Verbindung, und mehrere Ansätze von Programmen, die von da einen Übergang zu IP bewerkstelligen können.
Wir können µC seitig mal Bascom recht gut einbinden.
Und User-programm connections zu IP können wir noch konfektionieren (mit DLL oä), aber erfinden brauchen wir das nicht mehr, das gibt's schon.

Im Grund fehlt uns doch nurmehr das Konzept, mit welchen angaben und woher hat er die findet jemand sein Ziel, ohne bei jedem Umstecken sein Programm frisch zu kompilieren ?

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ß

holla jetzt hänge ich mal ein Wochenende nicht hier rum und dann passiert so viel.

Warum das TCP und das Level0 bei TCP so unterschiedlich der sind ist mir noch nicht ganz klar ?

Wenn ich das hier alles richtig verstanden habe Könnte ich ja mal ein versuchen machen für die Servo an stuerung auf dem RN Borad zu Basteln. So was mit meiner dll und VB weil das hier doch wohl die Verbreites PC Sprache zu sein Scheint. Habe zwar kein Board hier aber wenn die Spezifikationen passen sollte es trotzdem gehen.

OK mein Klassen structur muß ich ordendlich umbauen aber das war wohl klar.

Was haltet Ihr da von wenn ich dem RN-Com NetworkLayer noch ein TCP Port verpasse auf den man sich Connecten kann ? So hätte mal dort dan zwei Ausgänge TCP und Com über die DLL ?

Ist nicht die Antwort auf alle Fragen 42 ?

@ragnar die Links sind mit Action=Edit ist das so gewohl oder nicht ich finde das ein bissle störent. Weil ich ja nur lesen will und nicht editieren.

Seriel rnbfra:
Sorry, na endlich gefunden:
https://www.roboternetz.de/phpBB2/viewtopic.php?t=1995
Edit: @NumberFive: Das mit der 42 siehst Du ganz richtig.

Netter Gruß

@NumberFive:
Einen TCP/IP-Port am RN-Com NetworkLayer schadet ja nicht wirklich oder? Ich bin ja immer für Optionen zu haben, manchmal staunt man wozu das gut ist.
Einen Servo versuchsweise per Spezifikation anzusteuern finde ich gut, sollten wir mal machen. Ich habe alles um das laufen zu lassen. Wir können das auf kurzem Weg über icq mal durchtesten.
@PicNick:
Ich jumper mein Board dann mal um wie Du es hast.

Netter Gruß

@Marvin42x: Du freust Dich, wenn sich Servos bewegen ?
Dann hab ich was für dich.

In der Zip file ein RN_SERVER.EXE und ein RN_CLIENT.EXE


1 Server starten, Open com, Open IP
2 Client starten, IP-Adresse einstellen , Open IP

Slider verschieben und Freude haben *g*

Von Layern und Routing-definitions ist das weit entfernt, aber ich will ja auch mal was ticken sehen.

@PicNick: Völlig richtige Einschätzung der Lage :-)
Schicksalshart ist, dass ich gerade jetz weg muss wo es lustig wird.
Freu mich immer über kleine Abstecher vom vernünftigen Weg der Rationalität.

Netter Gruß von jemandem der vermutlich weit nach Mitternacht noch schnell mal rumfummeln wird.

@PicNick:
Ich hätte da gern mal ein Problem.
seit der letzten Version vom 12.3. kann ich das sys.bas nicht mehr compilieren. Ich hatte erstmal versucht der Sache auf den Grund zu kommen weil die Version mit den blinkenden LED problemlos geht, auch jetzt noch. Gibt es da einen Unterschied der mir beim Suchen weiterhilft?
Vers. Bascom 1.11.7.8
Die Meldung, die NUR bei der letzten Version ab 12.3 auftritt.
Fehler: Selected chip and targed chip do not match ATMEGA32<>AT90S2323

Moment, die Meldung kommt eigentlich vom Brenner, wenn
$regfile="m32def.dat" (sys.bas) und das, was auf dem Programmier-kabel draufhängt, nicht zusammenpassen.
Bist du sicher, daß du auf dem richtigen Stecker steckst ?
was sagt er, wenn du beim Brenner auf das Fragezeichen klickst ?

@PicNick:
Andere Programme macht er, angefangen mit Versionen meiner eigenen Programme von früher, bis einschließlich zur Demo mit blinkender LED. Also früher 12.3.06.das kompiliere ich und übertrage es wie gewohnt und alles arbeitet wie es soll. Also Hardware, Stecker Schnittstellen, alles tut.
Ja, denke ich auch so, das ist eine Brennerfehlermeldung. Die Ursache ist nach meiner bisherigen Recherche das er nix vernünftiges zum brennen findet. Wenn ich nur den oberen Programmteil, der so allgemeines enthält kompiliere bekomme ich keine Fehlermeldung. Was ich als erstes gerne wüsste, ob das ein lokales Problem ist was nur mich betrifft.
Das angekündigte Fragezeichen entzieht sich erfolgreich meiner Entdeckung. Den Chip identifiziert der Brenner tadellos, falls das gemeint ist?
Ich würde das Problem erstmal auch hinten an stellen wollen wenn Du so gut wärst mir das sys Hex noch reinzustellen, dann könnte ich mich an dem Rest freuen und der Sache nebenbei auf den Grund gehen.

Netter Gruß

Eventuell probier mal, die Datei SYS.CFG zu löschen, vielleicht macht ihn da was nervös

Das Fragezeichen in der Mitte hab ich gemeint

@PicNick:
Na gut, ist ein Fragezeichen, ist aber echt gut getarnt.
So, und nun freu freu, hüpf rum, ähem macht man ja in meinem Alter nicht mehr. Also, alles tut und ich bin Herr über 10 Servos :-)
Du hast in myrncom.bas geschrieben: $lib "mybuffer.lbx" , "myrncom.lib"
Besser ist Du schreibst: $lib "mybuffer.lbx" , "myrncom.lbx"
Die alte Schreibweise stärkt auf der einen Seite mein Verständnis der Programiererei auf der anderen Seite habe ich den armen Compiler verdächtigt.

Netter Gruß
Ps. Danke für das schnelle Hex

LBX /LIB oops ! Ich werd' das gleich ausbessern.

Ich geh' nun daran, PC-seitig das Ganze ein wenig zusammenzuräumen und gleichartigen Schmus zu modularisieren. Is halt alles ein rumgefummel.
Schon bei dem Servo-Client sieht man, wo's fehlt:
Jetzt nimmt er ja einfach alle Servos unter seine Fittiche, das sollt man aber flexibler konfiguriern können.
Man sollte irgendwelche positionen als ausgangspunkt einstellen und speichern können, und natürlich auch abrufen.

Andererseits sieht man auch, wie leicht man noch einen 2313 dazuhängen könnte und mit einer zweiten Client-Instanz hätt man schon 20 Servos im Griff, ohne groß zu programmieren.

Naja, man werkt halt rum .

Stimmt, durch die neue Architektur ergeben sich interessante neue Optionen. Ich finde das neue System steht dem Board gut. Sehr transparent, wie ein gutes Sommerkleid.
Netter Gruß

Zitat:

---

...transparent....Sommerkleid.

---

o lala !

So. wieder Nachschub, insbes. für Marvin42x.
Das ist sozusagen mein Prototyp-Set, an dem ich die Möglichkeiten und Erfordernisse von Verteilung und dyn. oder statischem Routen überprüfen kann.

RNSXNET.HEX für RNBFRA-CoProzessor
SYS.HEX für mega32 u. RNBFRA
RN_SERVER.exe (PC) als Port Com <> IP
RN_CLIENT.exe (PC)als "User-Applikation", die die Servos steuert
RN_ADC.exe (PC) das die 8 ADC-Sensordaten empfängt und anzeigt

Alles äußerst anspruchslos.

Jede der x Applikationen(nicht eingeschränkt) sendet an den RN_SERVER, der es zusammenstuffed und mit STX u. BCC u. ETX an den µC schickt.
(Adressen, die der MEGA nicht kennt, werden einfach zurück/weiter geschickt, dadurch kriegt sie auch der CoProzessor).
Umgekehrt geht alles vom µC an alle IP-Kunden, die grad connected sind
RN_ADC fischt sich die ADC Werte, die der µC produziert, heraus und zeigt 0-1023 auf Progress-Bars an.
RN_CLIENT interessiert das alles nicht, aber er schickt dafür messages von Sliders an die 10 Servos.

Kommunikation zwischen den PC-Clients findet dzt. nicht statt

Die eigentliche Message besteht (prototyp)
Zieladr1 Zieladr2 Absender1 Absender2 Daten (byte oder short, je nach message)

An dem Servo-Client sieht man, daß es für solche Geräte eine Art Reservierung geben müßte. Wenn man 2 solche Clients startet, verstellen sich die gegenseiting natürlich die Servos. Da braucht's eine Regelung.

@PicNick:
Freue mich, dass das jetzt so sichtbar wird, warste ja fleißig
Habe leider wieder Familienkrach mit meinem Compiler. Jetzt hat er sich drauf verlegt nichts zu sagen, so zu tun als kompiliere er dann aber nichts zu machen und sich ohne Fehlermeldung davonzuschleichen.
Habe im schon ein altes sys.bin untergeschoben, das soll helfen sagt man aber dann nimmt der Brenner halt das alte sys.bin und brennt es brav.
Dein sys.hex mag mein Brenner nicht brennen weil er sagt da wäre ein Unterschied und Brenner die Unterschiede sehen sind recht ablehnend.
Du siehst alles in vollem Gange, das einzige was bei mir im Moment klappt sind die Türen.
Ich komm aber schon noch dahinter, keine Bange. Dein Compiler scheint besser erzogen als meiner.
Kann heute leider abends nicht mehr dran arbeiten, erst morgen.

Netter Gruß

Klingt ja sehr seltsam. Du mußt mir mal deine Konfigurationen verklamüsern. Schon mal mit dem Pony zu brennen versucht ?

Was mich wundert, dass Dein Compiler alles gnadenlos frisst und ein Binärfile draus macht, Nach dem Motto ich "weis schon was du meinst".
Du hast bestimmt ne KI-LIb drinn :-)
Ponny habe ich noch nicht probiert.
Das Hex was du mir als erstes geschickt hattest, hat er auch mit derselben Begründung nicht gebrannt, da war aber auch der Haken mit de lib drin, was Deinen Compiler aber scheinbar nicht sonderlich schreckt.
Ich vermute mal, dass es eine einfache Erklärung gibt und das am Ende alles gut läuft.
Das Pony werde ich aber trotzdem morgen mal ausprobieren.

Netter Gruß

Gut, das ist klar, bei mir findet er ja auch die .LIB und die .LBX, daher hab' ich's ja auch nicht gemerkt.
Und mein Kompiler/Computer weiß, wenn er nicht spurt, gibt's eins auf die Glocke.
(Ich hab' ein Bild vom Schrottplatz als Drohung eingescannt, seitdem ist er brav)

Sowas erinnert mich an ein Kindkeitstrauma: Ein Spielzeug am Heiligabend kriegen, aber keine Batterien drin, und zwei Feiertage vor der Nase, wo alle Geschäfte zu sind. *räusper,egal,naja*

@PicNick:
So, nachdem ich nun einen Tag mit der Betrachtung von Compilerunverträglichkeiten verbracht habe, habe ich das zur Seite gelegt. Habe mir ein Pony geschnappt und meinem Mege32 das Gehirn gewaschen. Mein Pony sagt zwar es kenne keinenMega32 aber wenn ich will ist es ihm egal und es schreibt dem der da dran hängt das was ich will ins Hirn, egal wer es ist und was es ist.
Womit ich jetzt noch vor Ende der Feiertage an Batterien gekommen bin, egal was Opas Herzschrittmacher dazu sagt.
Was jetzt wirklich schön funktioniert ist Deine kleine Programmfamilie.
Sieht so aus das ich langsam Rasenmäherblätter kaufen gehen muss, damit ich auf der Hardwareseite nicht ins Hintertreffen komme. Ich finde das total entspannen wenn alles so rund läuft, habe schon mal paar Sensoren rangehängt und das alles auf einer Servogetriebenen Halterung hin und her und rauf und runter geschwenkt und die Sensorwerte beobachtet. Sieht alles sehr plausibel aus.
So, aber jetzt gehe ich erstmal ins Internet, schnapp mir ne Waffe und rette die Welt, irgendjemand muss das ja machen.

Netter Gruß

Ps. Könntest Du mir mal Dein Bild vom Schrottplatz schicken? ;-)

Probier' mal, vielleicht hilft es ja