i2c Bus

[Michael Jürgens]

puuh, ich muss erst mal nachdenken.
Vielen Dank für die vielen Hinweise.

Gruß,

Michael


Uwe Hercksen wrote:

Tilmann Reh schrieb:


Sei's drum, für "netto" ca. 100 kbit/s brauchst Du bei M/S mit
Quittung und TimeOuts "brutto" wohl ca. das doppelte. Mit RS-485
und geeigneten Treibern und Kabel sollte das bei 30 Metern noch
gehen. Allerdings bekommen die UARTs der meisten Controller bei
diesem Tempo echte Probleme (und die Controller häufig auch...).


Hallo,

die 100 kbit/s sind doch wohl für die 10000 Slaves gedacht.
Wenn aber jeweils 100 Slaves an 100 "Unterbussen" hängen, dann wird es
doch wohl erheblich langsamer zugehen.
Da scheint es mir sinnvoller und kostensparender die Unterbusse zu den
Slaves entsprechend langsamer zu betreiben, das senkt den Aufwand bei
den Slaves deutlich.
Der Master muss dann allerdings in der Lage sein etliche Unterbusse
simultan zu bedienen, also mit je einer seriellen Schnittstelle pro
logischem Unterbus.
100 logische Unterbusse sind aber wieder etwas viel des Guten, so etwa
10, 20 oder 25 sollten reichen.
Von einem logischen Unterbus geht es dann mit Repeatern wieder an 4 bis
10 physikalische Unterbusse.

Ich hoffe es ist genügend klar geworden was ich meine, eine Baumstruktur.
Eine mehrstufige Hierarchie wäre auch zu überlegen, ein Master, 10
Aufseher, 100 Vorarbeiter und 10000 Slaves z.B.

Bye

 

[Thomas Stanka]

Stefan Heinzmann <stefan_heinzmann@yahoo.com> wrote:

Wie andere hier schon geschrieben haben dürftest Du mit CAN oder RS485

Ist das kein vergleich Äpfel mit Birnen? Oder verstehe ich RS485
falsch, aber bei den anderen RS-Standards handelt es sich doch auch
nur um die Physikal Layer Definition, das Protokoll müsste also noch
von Hand gestrickt werden.
Und genau der Physikal Layer ist doch bei CAN eher frei (es gibt zwar
auch dafür Standards, aber _einige_ verschiedene).

Die Protokolle über RS485 sind normalerweise besser wenn Du größere
Datenmengen (z.B. 100 Byte) auf einmal übertragen willst. CAN ist bei
kurzen Meldungen ("Licht an", "Vorschub auf Position Y", etc.) im
Vorteil. "100kBit/s Nutzlast" ist für sich gesehen daher keine sehr
nützliche Angabe.

Wenn ich das richtig verstanden habe, sollen im gesamten System 10.000
Slaves jeweils 500-1000 Bit/s bekommen. Durch Matrix-Anordnung gäbe es
bereits eine Möglichkeit 100 Master jeweils 100 Slaves bedienen zu
lassen. Hier interpolieren einige eher leichtfertig auf 100kbit/s
durchsatz, der Bus muss deutlich mehr schaffen, um das hinzubekommen
oder aber ein sehr interessantes Protokoll haben, bei dem _kein_
Overhead entsteht.

Bei CAN sind pro Frame bis zu 64 Bit möglich, das bedeutet, dass jeder
Slave einige (8-16) Frames braucht mit entsprechendem Overhead was
aber bei 1 Mbit/s bis 40m Kabel gehen sollte. Bei I2C wäre der Burst
zwar beliebig lang, aber die Kapazität (Max 400pF pro Bus) könnte ein
grosses Problem werden.

Mir würde da noch USB einfallen, mit Hubs sind bis zu 127 Endgeräte
erlaubt, die Datenrate von 1.5 Mbit/s im Lowcostbereich sollte trotz
Overhead ausreichen.

Also entweder CAN oder USB oder was eigenes. Nachdem mir noch nicht
klar ist, wie sich die 100 Master abstimmen, liegt da evtl der
Knackpunkt, um doch was Hausgemachtes einzusetzen. Vielleicht können
die Zeilenmaster aber relativ autark arbeiten, und müssen sich
untereinander nur relativ schwach abstimmen, da fehlen einfach noch
Hinweise.

bye Thomas

 

[Marco Budde]

Michael Jürgens wrote:

i2c scheint ja bei Microcontrollern so etwas wie ein Standard Bus zu
sein.

Allerdings vor allem als Bus auf Platinen, auch wenn einige das
gerne vergessen .

Weiss jemand, wie Störanfällig der ist?

*) Bei normalen Geschwindigkeiten eigentlich nur auf sehr kurzen
Entfernungen zu gebrauchen (längere Kabel kannst Du wegen der
Kapazitäten eher vergessen).

*) Oberhalb von der physikalischen Schicht gibt es keine genormte
Sicherungsschicht (CRC & Co).

Ich hab die Anforderung Daten an einen ľC über große Entfernungen (bis
zu 30m) mit möglichst geringer Anzahl Leitungen, möglichst unabgeschirmt
(z.B. Flachbandkabel) und das ganze auch noch als Bus mit um die 100
Teilnehmern.
Dafür muss das ganze aber nur unidirektional und nicht sehr schnell sein
(max. ca. 100kBit/s Nutzlast)

Das wird mit I2C nichts.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-b<ät>linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de

 

[Marco Budde]

Stefan Broering wrote:

Der I2C-Master ist wesentlich unkritischer im Timing als der Slave. Deshalb
eignet sich I2C nicht sehr gut, um eigene Slaves in das Netz einzubinden. Es
gibt außerdem eine Begrenzung der Anzahl der Teilnehmer auf dem Bus (ist bei
RS485 aber genauso, 32 bei RS485).

Du kannst immerhin 1024 Devices bei I2C ansprechen. Das sollte
reichen bzw. dürfte schon wegen der Kapazitäten sowieso nichts
werden.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-b<ät>linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de

 

[Carsten Schaudel]

Es gibt einen Master, der die Daten auf die Slaves schickt.
Von den Slaves wird ausser einer Quittung nie etwas zum Master gesendet
werden.

Nu, und in just diesem Moment wird aus 'unidirektional' halt dann doch
'Bidirektional'.
Uni heisst halt wirklich nur ein EINE Richtung. Ein bischen bidirektional
geht genauso wenig wie ein bischen tod.