Hi, wie man wohl merkt, komm' ich in letzter Zeit zu nix.
Der Broterwerb kann manchmal lästig sein.
Nun, als zwischen- neben- hilfs- Produkt der RN-Server.exe mit einstellbarer Baudrate, sonst wie gehabt.
Druckbare Version
Hi, wie man wohl merkt, komm' ich in letzter Zeit zu nix.
Der Broterwerb kann manchmal lästig sein.
Nun, als zwischen- neben- hilfs- Produkt der RN-Server.exe mit einstellbarer Baudrate, sonst wie gehabt.
Leben ist hart aber ungerecht.
Da brauchen wir ja nicht fragen ob der alte Holzmichel noch lebt, weil:
Jaaa er lebt noch :-)
Viel Erfolg beim Broterwerben.
Netter Gruß aus der Stadt wo die Forsyzien sich zu blühen anschicken
Hallo an Alle!
So langsam kriege ich Entzugserscheinungen ;) Verfolge die Entwicklung hier höchstinteressiert, und wünschte ich könnte selbst mithelfen. Ich werde mich einklinken, wenn ich meine Chance sehe ;) :mrgreen:
Lieben Gruß aus Hamburg
:-)
so ist recht.Zitat:
So langsam kriege ich Entzugserscheinungen
schön das Du das schreibst, so ein Feedback von "Aussen" tut dem Projekt auch mal gut.
Netter Gruß
Ja supi,
ich bastel ja auch im Background imma weida imma waida ....
Der Experimental-Server für die Webseitige GUI und der damit verbundenen XML-Komunikation läuft schon ne Weile:
http://www.ulrichc.de/cgi-bin/cu-soap.pl
(Dieser Link ist nur die HTTP-XML-Schnittstelle also keine Bildchen erwarten)
Ich hack derzeit noch an den Clients (das man mal was sieht)
Die Spez. etc. steht schon ... muß aber noch zu Papier gebracht werden ;-)
Netter Gruß,
Chris
Ich muß gestehen das ich arbeitsmässig ziemlich unter strom stehe und so auch nicht recht weiter komme. Ausserdem mußte ich auch mal an meiner Hardware weiter bauen leider tuen die Sensoren immer noch nicht so richtig.
Mal sehen vielleicht hat es ja dieses we hin das noch was mache. Leider muß ich das Protokoll auf der Multicast stream föllig umbauen. damit ich Picks telegramme nach bauen kann.
http://www.i-do-more.de/mine-robo/do...-Protokoll.zip
hier liegt immer die Aktuelle Software
http://www.i-do-more.de/mine-robo/do...deoCapture.zip
hier liegt die anfänge der Video erkennung das soll später mal zusammen
laufen. siehe
https://www.roboternetz.de/phpBB2/vi...=179097#179097
Gruß
Hier habe ich einen guten Artikel und Software passend zum Thema gefunden:
********* Technologies *********
uC to uC to PC Communications using Mailbox
Multi-port, Multi-protocol Serial RAM
2 Way Wireless RF
http://www.botgoodies.com/
Bild hier
I can monitor all of my important robot variables and send commands and variables to the robot.
Bild hier
Wenn ich es in der Schnelle richtig verstanden habe, verfolgt er die Methode "Memory-Mapping". d.h. im µC gibt's ein Speicherbereich, daß vom PC geholt bzw. beschrieben wird.
Auf dem PC hat er ein ähnliches Konzept wie wir dzt., nur setzt er voll auf Windows-Plattform, was mit aber nichts freudiges entlocken kann.
Da find ich (als Basis) unseren "simply stupid socket"-Layer besser.
Wenn's interessiert: Da ich die RNBFRA-Karte durch die zwei Prozessoren als Prüfstein für alle Netzwerk-Konzepte sehe (Pc-seitig gibt's keine vergleichbare Problematik), bastle ich (mit kleiner Flamme) an den Möglichkeiten.
Ich wärme grad die Variante auf: RNBFRA als I2C Multimaster-Netzwerk. Denn die rs232-split oder chain Lösung befriedigt mich nicht recht.
Hallo Leute, ich unterbreche mal ganz kurz die Stille.
Auch ich bin keineswegs verschwunden und auf dem Laufenden.
Hier gibt es was ganz spannendes:
http://www.heise.de/newsticker/meldung/74451
und direkt:
http://www.microsoft.com/downloads/d...displaylang=en
Microsoft hat ein Geschenkpacket für Roboter Entwickler geschnürt.
Ich habe den Verdacht, dass wir damit PC-Seitig eine Menge Arbeit sparen können?
Kann da mal einer eine Meinung zu kundtun?
@PicNick:
Ich mach mir bisschen Sorgen um Deine Zähne, meines Wissens nach haben sich an der Kommunikation Mega32 zu Co auf dem RNBFRA schon einige die Zähne ausgebissen.
Aber jetzt ist ja erstmal Erdbeerzeit, dafür brauch man die Beißer glaube ich nicht so ;-)
Frage:
Ich habe in VB2500 Testweise und zum Üben einen TCP/IP-Client zusammengebaut der sendet auch brav an Deinen RN_Server und wenn vorneweg ein RN steht zeigt der Server auch das Gesendete in der Zeile unter Received an. Danach geht der Server auf Closed empfängt aber weiterhin alles mit RN vorneweg. Wenn ich es noch mal probiere.
Muss ich noch was machen damit er mich akzeptiert?
Mein Client empfängt ansonsten Problemlos von einem anderen Server.
Netter Gruß
An der Stelle ist Gelächter angesagt.Zitat:
..Sorgen um Deine Zähne..
Ich bin gut unterwegs, mit dem Mega und dem 2313 ein Multimaster-Netz zu haben. Ich laß mich doch von so einem Plastik-Dödi nicht tyrannisieren. Ich muß das Zeugs aber noch für eine Anwendung konfektionieren.
Test-Client: müßt ich genaueres wissen. eigentlich geht das.
Ok zu runter laden und angucken hatte ich jetzt noch keine Zeit.
Aber was ich komisch finde nirgens ist so richtig beschrieben wie es geht nur das es ganz doll ist. das ist wieder typisch MS.
"Wenn ich 32 Bit getrunken habe behaupte ich auch das ich alles kann"
Soweit
https://www.roboternetz.de/phpBB2/vi...=191143#191143
@marvin42x du warst nicht der einzige nur andere Quelle
@PicNick:
Multimaster I2c wäre ja ein Ding. Das I2C wurde ja meines Wissens schon mal entnervt zur Seite gelegt, geschweige von Multimaster. Da drück ich Dir aber die Daumen, wäre ja eine hochelegante Lösung, da hätte der kleine sogar seine serielle wieder frei, wozu auch immer.
Der Mega32 als Gateway :-) .
Test-Client:
Wenn das normal geht, werde ich mich da noch etwas rein vertiefen. Beim Lösen eines Problems lerne ich immer am meisten.
Bascom:
Ich hatte ein Update gemacht und jetzt geht alles. Dass so ein winziger Versionsunterschied der Grund ist hätte ich jetzt mal nicht gedacht, zumal es bei den ersten Programmversionen noch ging. Nun denn, mein Compiler weis jetzt auch was ich meine.
@NumberFive:
Na dann ging es Dir beim Lesen der Beschreibung nicht anders als mir. Ich hatte es mir gestern Abend noch runter geladen, steige aber noch nicht ganz hinter.
Nicht der Einzige:
Ja, sehe schon, da werde ich mal mitlesen.
32 Bit:
Da sieht man, dass Du etwas jünger bist, nach 32 Bit würde ich schon unterm Tisch schlafen und nichts mehr behaupten :-)
Netter Gruß
Hallo PicNick,
... das interessiert mich jetzt auch. Weil ja bei mir 2 RNBFRA in 3 cm Abstand übereinander schweben, suche ich nach einer Möglichkeit, alle 4 uCs in einem einfachen Multimaster Betrieb zu betreiben.Zitat:
Ich bin gut unterwegs, mit dem Mega und dem 2313 ein Multimaster-Netz zu haben.
Das hat zwar mit eurem tollen Projekt hier nur indirekt zu tun, aber ...
Gibt es für so einen Betrieb schon irgendwelche "Standards"? Man müßte sich ja Codes für Anfang und Ende des Master-Betriebs eines uCs ausdenken, ein Master müßte sich abmelden und es müßte klar sein, wer dann an die Reihe kommt. Zusätzlich müßte ein uC sich auch "zwischendurch" melden können, wenn er wichtige Daten braucht oder bereit stellt (Int2 durch PB2???). Und es müßte ein Weg gefunden werden, wie die anderen (nicht-uC-) Sklaven am I2C eingebunden werden können.
Hast du da schon eine Art Protokoll?
Gruß Dirk
Multimaster:
Mein erster Ansatz ist/war mal der, daß auf einem I2C Bus mehrere µC hängen, die von einander unabhängig so agieren können, daß sie ihre Nachrichten sicher durchbringen und auf Konflikte richtig reagieren, daß sie nicht hängenbleiben oder irgendwas verschluckt wird.
Konkret: Auf der RNBFRA-Karte sollen der Mega32 und der 2313 hemmungslos die übrige I2C Peripherie benutzen können, d.h. der 1213 wütet am Expansion-Port und der Mega mit dem Power Port.
Dazu hab ich den Mega als Multimaster konfiguriert, also mal Master richtung Output-PCF, mal Slave.
Der 2313 Co war eigentlich nur Master, er hat in der Schleife mal das Powerport und mal den Mega angequatscht. (normales Bascom I2C)
Mit der HW-TWI am Mega geht das eigentlich super, dem geht nix verloren, wenn ihm der 2313 mal in die Suppe spuckt, merkt er das und wiederholt seine Sendung, bis sie durch ist. Daß der mega mit 400 kHz fährt und der 2313 mit irgendwas langsamen, spielt keine Rolle.
D.h. Mehrere Megas mit Hw-TWI über I2C zu vernetzen ist so mal ein Klacks, da brauchst kein Protokoll, außer der eingebauten Arbitrierung.
Mit den 2313 Bascom Soft-I2C routinen ist das erwartungsgemäß so eine Sache. Der wartet nicht auf einen freien Bus, der fängt einfach an.
Also hab ich ihm mit dem Assembler erstmal eine Stop-Condition-detection eingebaut, und er sendet erst, wenn die da ist.
Das ist zwar etwas laborhaft theoretisch, war aber mal ein Versuch.
Auf diese Art geht das Ganze mal ganz gut, der Mega kann multimastern, wie er mag, und der 2313 kann auch dazwischen "mastern"
Was jetzt fehlt, ist dem 2313 eine anständige Arbitrierung einzubauen, und natürlich eine vernünftige Slave-Function mit erträglicher Bus-Speed.
Bis 100 kHz kann ich dzt. mitspielen, mal sehen, was geht.
(Da wird natürlich gestretcht, wo es geht, logo, wunder gibt's keine)
Und dann den ganzen Schmafu so zu konfektionieren, daß man das auch brauchen kann.
*stöhn*
EDIT @dirk:
etwas hat's schon mit dem Protokoll zu tun. Denn ich find' der Mega auf einer RNBFRA sollte sozusagen "routen" können auf die I2C.
Das durchschlängeln von RS232 will mir nicht unter die Nase
Erstaunlich, dass sich HW-TWI nicht durch Querschüsse des 2313 irritieren läßt! Was passiert denn, wenn der 2313 in einer Schleife auf PCFs zugreift, während der M32 mit ihm oder sonstwomit reden will?
Da müßte doch ein Chaos auf dem Bus herrschen?
Naja, ich verstehe zu wenig davon und werde mir Codes für Stop und Go hernehmen.
Gruß Dirk
Ich hab ja anderenorts berichtet:
https://www.roboternetz.de/phpBB2/ze...164&highlight=
dass ich jetzt mal den RNBFRA-Coprozessor soweit habe, daß er als normaler I2C -Slave arbeiten kann.
Das ist in der Servo-Funkionalität etwas schwieriger, da er ja die ganze Zeit von Interrupts gebeutelt wird und nicht immer so hellhörig am Bus sein kann.
Aber immerhin, er tut es. D.h. nächster schritt ist ja, daß der CO auch Master spielt.
Da muß ich jetzt an den Soft-I2C-Master Routinen vom Bascom , die es ja eigentlich gäbe, basteln, denn die kennen keine Bus-Übernahme und Multimaster-Arbitrierung. Wenn ich Pech habe, muß ich sie frisch schreiben, naja, fummel, fummel.
Warum erzähl ich das in dem Thread ? Weil es um die Adressen geht.
Für das RN-Netz gehen wir ja von 16-Bit Sende- und EmpfangsAdressen aus.
Und normalerweise sind die I2C Geräte alle auf 8-Bit adressen (eigentlich ja 7) ausgelegt.
Bei selbstgemachten µC können wir ja basteln, aber die anderen, fertigen (PCF, LM75 etc.) sind ja, wie sie sind.
Gibt es Meinungen ? Sollen wir einen I2C Bus als "system" betrachten, mit 8-Bit identifizieren, und die Geräte drauf mit 8-Bit Sub-Adressen ansprechen ?
D.h. das "Gateway"/der Router nimmt 8 Bit der 16-Bit adresse und das ist dann die I2C Adresse. Die anderen 8 Bit wären dann eben die "Router" adresse.
Oder war das jetzt wirres Zeugs ?
@PicNick
Die überraschende Vielfalt an geäußerten Meinungen kann einen manchmal richtig erschlagen.
In dem ganzen Wirrwarr von Ansichten würde ich sagen: Du bist heute der Bestimmer.
Da Du so was schon lange genug machst, werden wir mit Deiner Lösung schon nicht so falsch liegen.
Respekt hier noch mal, dass Du deine www (werkstatt weit web) auf dem I2C-Bus zum laufen bekommen hast.
@NumberFive:
Mein Interesse an einem einfachen VB2005 Beispielclient der mit dem Server von PicNick über TCP/IP reden kann ist ungebrochen.
Das ich meinen Rasen immer noch von Hand mähe(trotz hohem Alter und gebrechen) will ich hier ja gar nicht besonders erwähnen.
Netter Gruß
@PicNick:
Die Frage rund um ein serielles Protokoll taucht recht oft in verschiedener Form im Forum auf.
Ich frage mich ob es nicht Sinn macht, das RN-Level 0 (seriell) als Fertigbaustein schon anzubieten.
Es ist ja schon am laufen und muss nicht zwingend auf die Fertigstellung des gesamten Projektes warten?
Ich meine, ich hab gut Fragen, die Arbeit hast ja Du, wo sie Dir mit dem I2C-Bus eh schon bis zum Hals steht.
Netter Gruß
Hallo, Berliner !
Nun, Gottseidank hab ich in meiner übergroßen Weisheit die Communications-Funktionen für µC ohnehin extra gestaltet, sodaß dieser Level-0 auch stand-alone angewendet werden kann. dzt. halt nur für Bascom.
Problem ist die PC-Seite: wenn einer mit dem RN-Server leben kann "as it is", ist auch das ja funktionabel, ohne daß man sich darüber hinaus mit dem RNcom beschäftigen muß.
Nur: eine "LBX" / DLL für Pc haben wir halt nicht.
PS: Brich' dir nicht das Kreuz mit Rasenmähen.
@Marvin42x
Ich hab ein paar sich abzeichnende Szenarien zusammengefaßt.
https://www.roboternetz.de/wissen/in...ler/PC_I2C-Bus
Wunderbar, musste ich zweimal lesen.
Wenn Du mal nicht mehr Programmieren willst kannst Du auch Rechtsanwalt für Erbschaftsangelegenheiten werden.
Das ist recht kniffelig aber aus meiner Sicht klar und logisch. Der Agent hat mir gefallen.
Von meiner Seite ein freudiges Nicken.
Zum RN Server:
Ja, ist mir schon aufgefallen, Deine Weisheitsanfälle.
Das hat mich auch auf den Gedanken gebracht.
Die RS232 Routinen auf der Bascom-Seite und auf der PC-Seite sind aus meiner Sicht Stan-Alon-Fähig.
Das mit den Libs wäre ja was für später.
Ich sehe bloß immer die Jungs mit dem Problem dastehen, wo das Gute doch so nahe ist.
Außerdem steigert das den Bekanntheitsgrad des Projekts :-)
Netter Gruß,
Ich muss jetzt noch schnell Rasen mähen gehen
Ich habe mal wieder im Wissensbereich über das Projekt nachgelesen. Da hast Du ja inzwischen noch mal eine menge Arbeit rein gesteckt. Mir gefällt es sehr gut. Prima strukturiert und trotz der Komplexität für mich gut zu verstehen. Auch die Serielle am PC ist angesprochen. Das sieht sehr solide aus.
Freu mich, dass Du das machst.
Netter Gruß
@PicNick:
Ich fass noch mal mein Verstehen zusammen:
Der I2C Bus hat 255 mögliche Adressen.
Egal ob da ein oder zwei RNBFRA mit ihren Co’s dran hängen.
Alle Adressen wären von allen Mastern aus ansprechbar.
Das bedeutet auch, dass ein zweites RNBFRA, welches I2C mitmachen will völlig umadressiert werden muss.
Ein Mega32-sys könnte also auf die Physikalische Peripherie seines Nachbar-RNBFRA zugreifen.
Das RNBFRA-Betriebssystem welches die serielle Schnittstelle handhabt(sys-ser) muss alle I2C-Busteilnehmer kennen. -----nee.. muss es nicht, es könnte ja auch über I2C Aufgaben an das sys ohne serielle übergeben werden.
Da die I2C-Busteilnehmer eh fest verdrahtet sind scheint die Undynamik der Adressen hier unkritisch.
Das Betriebsystem(sys) hat für alle ihm bekannten I2C-Teilnehmer eine eigene Behandlungsroutine bzw. für Gruppen gleichartiger I2C-Teilnehmer.
Es scheint eine in der Standart-Message gekapselte Master-Master-Message zur Leistungsverteilung denkbar. Das würde wohl der Agent übernehmen müssen.
Die Standard-Message hat zwei Byte. Das erste beschreibt die Unit das zweite die Unter-Unit?
Die Unter-Unit kann auch eine I2C-Adresse sein.
Da wir jetzt mit der Multimaster Erweiterung die Anzahl der möglichen Unter-Units über die 255 treiben könnten brauche wir ab 255 Unter-Units 3 Byte an Adresse.
Wäre die Frage:
Lassen wir Das Standard-Message-Format unverändert, was für kleine Systeme sicher besser wäre.
Wickeln wir bei über 255 Unter-Units die Adressierung gekapselt innerhalb der Standard-Message ab?
Machen wir gleich 3 Bytes Adresse?
Ist ja wie im Internet, denen reicht der Adressraum auch nicht mehr. Die Computergeschichte ist einen einzige Orgie an Adressraumerweiterungen. Da können wir ja gleich mit anfangen Geschichte zu schreiben ;-)
Netter Gruß
Hallo, Marvin !
RNBFRA-Adressen: Richtig, bei den PCF's muß man umstecken. Da man ja 8 Adressmöglichkeiten jumpern kann und 6 PCF's da wären, sollte das ja gehen. Bei den Atmega und Co- adressen kann man sich ja was ausdenken. Ich hab derzeit 6C und 6E für die Mega, und 68 und 6A für die Co.
Ich teste dzt. mit einer RNBFRA und einer zweiten Atmega-Platine kreuz und quer. Im Prinzip kein Problem, die Co's spucken aber gelegentlich in die Suppe, müssen noch räsoniert werden.
Ein paar Ansätze hab' ich da noch dazugeschrieben
https://www.roboternetz.de/wissen/in...sage_an_Master
Bei der Adress-Map-Routing-Bredouille darf man sich nicht verwirren lassen, sonst werden wir meschugge.
Ich bin unser R232-Router, über den Level-0 kommt eine Message daher
1. Ich habe eine "Unit" mit der adresse, also kriegt die es und fertig. z.B. ein Agent)
2. Kenn ich nicht.
2.1 Ich schick das Zeug einfach als General-Call über I2C weg (+Retour-adresse) und lass es drauf ankommen, ob sich wer rührt (PCF-en werden das nicht tun, logo)
2.2 Ich find eine Tabelle
16-Bit-sys-adresse <> 8 Bit I2C addresse Type: Master/peripherie
2.2.peripherie--> I2C standard , Level-0 daten werden teils geschickt, teils geholt.
2.2.master --> wie General Call, nur mit direkter I2C adresse
Gibt's ein NAK, wird das zurückgeschickt (level-0)
Bei General Call gibt's kein NAK, das ist einfach Pech für den Absender.
Empfang General Call: Entweder kann man was damit anfangen, dann sollte man dem Router was sagen, (Tabelle erweitern)
Oder nicht.---> Gibts noch ein Netzwerk, dann eben weiter. Wenn nicht, isses eben aus.
(Die Ursprüngliche Absende-Applikations muß sowas wie Timeouts kennen und damit umgehen)
Dynamisch könnte man machen:
Was der Router an (I2C) Geräten kennt, kann er dem PC ja mitteilen
Ist er kein Router, aber ein master, könnt er ja seine Geräte also Liste mit General Call beim Startup oder periodisch allen anderen bekanntmachen. ( Und ev. dem PC weitersagen)
Das wär im aktuellen Fall noch einfacher, denn dann gibt es gar keine Messages in Blitzblaue.
Erläuterung: General Call ist die Addresse NULL, die erkennen alle Master und können die Nachricht lesen, also ein Art I2C-Broadcast.
*schwitz*
@PicNick:
Das mit dem meschugge war ein wesendlicher Grund das hier noch mal für mich aufzurollen.
Deine Sicht mit den Augen eines Routers macht die Sache etwas tröstlicher.
Ich frage mich, ob ich nicht in einem meiner nächsten Leben als Router auf die Welt kommen sollte.
Ein paar Tabellen ein paar Regeln und der Rest ist mir egal, sollen doch die Anderen sehen was sie mit dem Quatsch machen den Sie so glauben hin und her schicken zu müssen.
Ansonsten erstmal alles klar soweit. Der Wissenbereich ist mit den Ergänzungen ja auch auf Ballhöhe.
Netter Gruß aus dem gewitterumwölkten Berlin
28,5° in
25,0° out
Jaja, so ein Router hat eine interessante Lebenseinstellung. :-)Zitat:
Zitat von marvin42x
Gruß von der blauen *g* Donau, heute etwas moderater temperiert. In der Wahlkampfzeit (bei uns) machen sie halt alles, um Stimmen zu kriegen.
So Leute ich weiß habe lange nix geschrieben und leider wird das auch in absehbarer Zeit so bleiben den ich habe mir / uns eine Haus gekauf was zur Zeit Vorrang hat. Also bitte nicht böse sein.
Gruß
Es ist bei vielen Wesen auf diesem Erdball üblich, ab einem bestimmten Alter ein Nest zu bauen.
Gratuliere zum Haus und viel Erfolg beim Bau. :-)
Wir werden Dir fehlen.
Netter Gruß
Macht ja nix, dass ich jetzt bis ans Ende meiner Tage den Rasen von Hand mähen muss :-(
Es sind halt immer so ganz profane Sachen, die das menschliche Genie einsperren.
@Number5 : Auch von mir viel Glück, ich hab das hinter mir, dadurch weiß ich, was dich erwartet (wenn du vorne mit was fertig bist, fängst du hinten wieder an).
Per Aspirin ad Asthma ! (oder so ähnlich)
@Number5:
Das sich die Prioritäten ändern hab ich auch erlebt. Wenn du das mit dem Nestbau einigermassen auf die Reihe bekommen hast, stehst du ebenfalls vor dem Problem: Rasen mähen.
@marvin42x:
Ich vermute das du schon in der nächsten Mäh-Saisong einen neuen Leidensgenossen finden wirst. Warten wirs mal ab !!!
@PicNick:
Ich habe jetzt meinen TCP/IP Client soweit, dass er mit Deinem Server spricht.
Kannst Du mal gucken ob das so richtig ist.
Ich weis, dass Du nicht auf Windows - Programmierung stehst aber es wäre mir eine Hilfe, da mir da Number5 fehlt, wenn Du Dir das Programm mal ansiehst und mir ein paar Hinweise gibst.
Speziell Bytes receive und Client close zicken noch.
Das ist vom Schwierigkeitsgrad hier hart an der Kante für mich, da brauch ich etwas Rückendeckung.
Der Client ist über das Menü der GUI zu erreichen.
Ist alles voll die Baustelle aber ich ziehe das jetzt durch.
Ansonsten kommen als nächstes reale Adressen von Units die ich brauche.
Wenn wir da mal was festlegen könnten?
Des weiteren ist mir nicht klar ob wir das TCP/IP Byte-Array(die Message) schon definiert haben oder ob wir hier Ascci zwitschern?
Frage:
Das Teil ist 1100KB und geht nicht als Attachement (max400KB). Wie mache ich Dir das zugänglich?
In dem Sinne
Netter Gruß in die Alpen
So, ich habe Dir das mal gemailt, was besseres ist mir gerade nicht eingefallen. Ich muss mich da mal drum kümmern.
Netter Gruß
Morjen !
Wie bereits zurückgemail, ist alles da.
Ich werd wohl wirklich VB installieren müssen, mein Kollege will mir das eh' schon die ganze Zeit reindrücken.
(Wir haben in der Firma die Situation, daß jeder Entwickler seine eigene Präferenz zu eine Entwicklungsumgebung hat: Einer steht auf VB, ein anderer will mir unbedingt Delphi reindrücken. Und ich bin halt hauptsächlich C /C++ und Assembler. Naja)
Das finde ich sehr freundlich von Dir, dass Du dich für mich über Deine Abneigungen hinwegsetzt.
Ich werde sicher auch meine Hilferufe sparsam gestalten.
Netter Gruß
Ich brauche hier mal einen Tip
Ich habe die Absicht eine Art "Pressemappe" für dieses Projekt anzulegen.
Der Thread ist so groß, dass man das keinem antun sollte der sich nur mal informieren will.
Unten seht Ihr was mir in etwa vorschwebt.
Die Möglichkeiten Die ich sehe sind ein extra Thread oder irgendwie in der Wiki?
Oder macht man sowas ganz anders?
Oder macht man sowas nicht?
Hier ein Entwurf als Threaderöffnung:
Bitte in diesen Thread nicht posten!!
Diesen Thread habe ich eröffnet um einen aktuellen Kurzüberblick über das
Open-Source-Projekt:
Titel:
Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt
zu ermöglichen da der Haupt-Thread eine unübersichtliche Länge erreicht hat.
Ziel:
Fern Überwachung und Steuerung eines Multithreadfähigen-Roboters über einen lokalen PC und/oder über das Internet
--------------------------------------------------------------------
Einzelkomponenten:
---------------------------------------------------------------------
-----------------------Microkontroller---------------------------
Komponente :
Multithread-Betriebssystem für Mega32 insbesondere auf dem RNBFRA-Board
Programmiersprache: Bascom
Beteiligte: PicNick
Status: Rumpfsystem mit Beispielkomponenten läuft.
Komponente :
I2C Multimasterfunktionalität
Programmiersprache Bascom
Beteiligte: PicNick
Status: Rumpfsystem mit Beispielkomponenten läuft.
----------------------PC-------------------------------------------
Komponente :
Handling (RS232) der seriellen Schnittstelle auf dem PC zur Datenübertragung zwischen Roboter und PC
Name: RN-Server
Link:
Programiersprache: C
Beteiligte: PicNick
Status: läuft
Komponente:
Fehlertolerantes Protokoll für die serielle(RS232) Datenübertragung PC-Roboter
Link:
Name: RN-Protokoll
Beteiligte: PicNick, Ragnar, NumberFive
Status: läuft
Komponente:
Grafische Benutzer-Oberfläche zur Fernüberwachung und Steuerung eines Roboters. . Inklusive Einbindung von Kameras .
Datenanbindung: TCP/IP
Programmiersprache: Visual Basic 2005
Beteiligte: Marvin42x
Link:
Status: Vorentwurf in Kürze.
-------------------------PC/Internet-----------------------------------
Komponente:
Umsetzung des seriellen Datenstroms(RS232) in das TCP/IP-Protokoll(LAN/Internet) und Weiterleitung.
Programiersprache: C
Beteiligte: PicNick
Link:
Status: läuft
Komponente:
Grafische Benutzer-Oberfläche zur Fernüberwachung und Steuerung eines Roboters Browserbasiert
Programmiersprache: ?
Beteiligte: UllrichC
Link:
Status: in Vorbereitung
So Marvin42x hat mich mal animiert hier bissle mit zu palaberen.
Ihr habt ja sicher schon meine Software gesehen, habt ihr mal den Telegramm Aufbau (TCP Schnittstelle) für mich was ich tun muss, das meine GUI weis wo z.b. der Bot aktuell ist? Der Thread ist nu wirklich zu lang zum lesen ;)
So, Männer, es geht wieder ein Stück weiter, schön langsam wird Tacheles gesprochen.
Vorläufiger Status (Besuch am Nachmittag, keine Zeit mehr)
https://www.roboternetz.de/wissen/in...ler/PC_Routing
Meinung:
Sehr schön gemacht, die kompakte Lösung der Misere.
Würde ich gerne so mitmachen.
Lamenta:
Mein alter indischer Freund Prakasch pflegte zu sagen: „Sometimes Live becomes difficult“.
Aber so ist das Leben.
Schade, dass ich jetzt mein Gehirn so anstrengen muss. Mein Freund meint: „Ist wohl ungewohnt für Dich“, soll er doch sehen wo er demnächst seine Tasse Kaffee herkriegt.
Unverfrorene Bitte:
Ich nehme Deinen Testserver zum Testen (wie der Name schon sagt).
Könntest Du dem die Neuigkeiten beibringen?
Wobei ja das Testprogramm auf dem Mega32 das ansatzweise auch können müsste, *verlegen grins*.
Frage am Rande:
Wie hast Du den TCP-Dialog Server Client realisier. Fragt der Client regelmäßig ob was da ist oder bekommt er unaufgefordert Nachricht?
Zurzeit hole ich da ungefragt einfach was ab.
Nützliche Info:
Wenn man zum Besuch zu nett ist bleiben der lange und kommen wieder.
Wenn man gerade ganz wichtige Sachen vor hat kann das zu Behinderungen führen.
Netter Gruß
Ps. Der Umstand ob man Besuch bekommt ist natürlich auch schon Aussagekräftig ;-)
Morjen !
Ich schreib eben grad das Konzept auf, meine ganzen PC- und µC-Fragmente müssen das natürlich dann lernen. Die Wiki ist sozusagen gleichzeitig auch meine Prog-Description.
Lustig wird ja díe auto-configuration von dem ganzen Zeugs. Mal sehen.
CLient-IP Ich verwend im Kern einen normalen "blocking" recv, allerdings in einem eigenen Thread, dadurch läuft alles andere derweil normal weiter. Der schreibt receive-messages in Socket-spezifische Queues, die von den anderen Threads unabhängig ausgelesen werden.
Die Kunst des Gastgebers ist es, seinen Besuch zum Dableiben zu bewegen, ohne ihn am Fortgehen zu hindern