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

[NumberFive]

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

[NumberFive]

https://www.roboternetz.de/phpBB2/vi...=191143#191143

@marvin42x du warst nicht der einzige nur andere Quelle

[marvin42x]

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

[Dirk]

Hallo PicNick,

Ich bin gut unterwegs, mit dem Mega und dem 2313 ein Multimaster-Netz zu haben.

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

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

[PicNick]

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

[Dirk]

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

[PicNick]

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 ?

[marvin42x]

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

[marvin42x]

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

[PicNick]

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.