i2c Bus

[Michael Jürgens]

Hi,

i2c scheint ja bei Microcontrollern so etwas wie ein Standard Bus zu
sein. Weiss jemand, wie Störanfällig der ist?
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)

Gruß,

Michael

 

[Uwe Hercksen]

Michael Jürgens schrieb:

i2c scheint ja bei Microcontrollern so etwas wie ein Standard Bus zu
sein. Weiss jemand, wie Störanfällig der ist?
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)

Hallo,

dafür scheint mir RS485 wesentlich besser geeignet, da kann man Parity
und CRC benutzen.

Bye

 

[Stefan Broering]

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

i2c scheint ja bei Microcontrollern so etwas wie ein Standard Bus zu
sein. Weiss jemand, wie Störanfällig der ist?

I2C ist weniger ein Standard bei Microcontrollern, sondern war für die
interne Vernetzung in Geräten der Unterhaltungselektronik gedacht. Da es
einige interessante I2C Bausteine gibt (RTC, EEPROM), gibt es daher auch
viele Anwendungen mit Microcontrollern.

Dafür muss das ganze aber nur unidirektional und nicht sehr schnell sein
(max. ca. 100kBit/s Nutzlast)

Für I2C und für RS485 schon reichlich...

Gruß

Stefan

 

[Michael Jürgens]

Uwe Hercksen wrote:

Michael Jürgens schrieb:


i2c scheint ja bei Microcontrollern so etwas wie ein Standard Bus zu
sein. Weiss jemand, wie Störanfällig der ist?
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)

Hallo,

dafür scheint mir RS485 wesentlich besser geeignet, da kann man Parity
und CRC benutzen.

Hört sich gut an. Ich hab aber gelesen, dass RS485 nur 32 Knoten
unterstützt.

Gruß,

Michael

 

[Matthias Weißer]

Michael Jürgens schrieb:

Uwe Hercksen wrote:
dafür scheint mir RS485 wesentlich besser geeignet, da kann man Parity
und CRC benutzen.

Hört sich gut an. Ich hab aber gelesen, dass RS485 nur 32 Knoten
unterstützt.

Es gibt z.B. von Maxim RS485-Treiber die bis zu 256 Knoten unterstützen.

--
Matthias Weißer
matthias@matwei.de
http://www.matwei.de

 

[R.Freitag]

Michael Jürgens wrote:

Hi,

i2c scheint ja bei Microcontrollern so etwas wie ein Standard Bus zu
sein. Weiss jemand, wie Störanfällig der ist?
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.

CAN??

Robert

Dafür muss das ganze aber nur unidirektional und nicht sehr schnell sein
(max. ca. 100kBit/s Nutzlast)

 

[Hans J. Ude]

"R.Freitag" <rfr-mailbox@gmx.de> schrieb:

Michael Jürgens wrote:

Hi,

i2c scheint ja bei Microcontrollern so etwas wie ein Standard Bus zu
sein. Weiss jemand, wie Störanfällig der ist?
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.

CAN??

Du sagst es. Ich hatte gerade dieselbe Idee. CAN ist, was
Störsicherheit und Robustheit angeht einfach klasse. Ich weiß nicht
welche uC Familie zum Einsatz kommen soll. Viele haben aber wenigstens
ein Derivatmit CAN on chip. Dann wird höchstens noch ein externer
Leitungstreiber benötigt.

Hajü

 

[Igor \"Knight\" Ivanov]

Sorry, falschen Button erwischt, ging an private e-mail....

Michael Jürgens schrieb:
Uwe Hercksen wrote:
dafür scheint mir RS485 wesentlich besser geeignet, da kann man Parity
und CRC benutzen.

Hört sich gut an. Ich hab aber gelesen, dass RS485 nur 32 Knoten
unterstützt.

Es gibt z.B. von Maxim RS485-Treiber die bis zu 256 Knoten unterstützen.

Hi!
Als ich hier RS485 in Verbindung mit Parity und CRC las, verstand ich, dass
hier ein Misverständnis am laufen ist. RS485 ist ein "Hardware"-Standard
(Layer 0/1 laut ISO-Netzwerkmodell), Parity und CRC gehören zu Software
Protokoll (Layer 2 und aufwärts), und haben miteinander streng gesehen nix
zu tun.

Die Anzahl der Knoten, die RS485 unterstützt, ist wieder Hardware-Sache,
nicht die Adressierung. Es gibt tatsächlich Tranceiver, die nur zu 1/8 den
Bus belasten (z.B. sn65hvd2x von Texas Instruments, günstig) und somit
tatsächlich bit 256 Knoten zulassen.

Gruss,
Igor.


Don't let them take your rights!
http://www.againsttcpa.com

 

[Uwe Hercksen]

Michael Jürgens schrieb:

Hört sich gut an. Ich hab aber gelesen, dass RS485 nur 32 Knoten
unterstützt.

Hallo,

keine Repeater möglich?

Bye

 

[Igor \"Knight\" Ivanov]

Michael Jürgens schrieb:

Hört sich gut an. Ich hab aber gelesen, dass RS485 nur 32 Knoten
unterstützt.

Hallo,

keine Repeater möglich?

Bye

Alles ist möglich.

CU.
Igor.

 

[Michael Jürgens]

Hans J. Ude wrote:

"R.Freitag" <rfr-mailbox@gmx.de> schrieb:


Michael Jürgens wrote:


Hi,

i2c scheint ja bei Microcontrollern so etwas wie ein Standard Bus zu
sein. Weiss jemand, wie Störanfällig der ist?
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.

CAN??


Du sagst es. Ich hatte gerade dieselbe Idee. CAN ist, was
Störsicherheit und Robustheit angeht einfach klasse. Ich weiß nicht
welche uC Familie zum Einsatz kommen soll. Viele haben aber wenigstens
ein Derivatmit CAN on chip. Dann wird höchstens noch ein externer
Leitungstreiber benötigt.

Ich vergass zu erwähnnen, dass es extrem um die Kosten geht.
Ich suche nach einer Lösung wo ich die Möglichkeit habe 10000 ľC zu
adressieren. Da die Matrixartig auf einer Fläche von 20 x 20 Meter
angeordnet sind, wollte ich immer 100 Stück an einen Bus hängen.

CAN ist vermutlich erheblich teurer als RS485?

Gruß,

Michael

PS: Ich finde die Resonanz hier in der Newsgroup echt super - Musste mal
gesagt werden !!!

 

[Hans J. Ude]

Michael Jürgens <info@hunnenburg.de> schrieb:

Ich vergass zu erwähnnen, dass es extrem um die Kosten geht.
Ich suche nach einer Lösung wo ich die Möglichkeit habe 10000 ľC zu
adressieren. Da die Matrixartig auf einer Fläche von 20 x 20 Meter
angeordnet sind, wollte ich immer 100 Stück an einen Bus hängen.

CAN ist vermutlich erheblich teurer als RS485?

Über aktuelle Preise kann ich leider nichts sagen. Das war anno 96/97,
daß ich damit gearbeitet habe. Wir hatten damals Intel 82527 (passiv)
im Einsatz. Aber der ist längst ein alter Hut. Heute gibt's das alles
onchip. Musste wohl Listen wälzen und vergleichen.

Hajü

 

[Tilmann Reh]

Michael Jürgens schrieb:

Ich vergass zu erwähnnen, dass es extrem um die Kosten geht.
Ich suche nach einer Lösung wo ich die Möglichkeit habe 10000 ľC zu
adressieren. Da die Matrixartig auf einer Fläche von 20 x 20 Meter
angeordnet sind, wollte ich immer 100 Stück an einen Bus hängen.

CAN ist vermutlich erheblich teurer als RS485?

Wenn es "extrem" um die Kosten geht und 10000 ľC zum Einsatz kommen
sollen, könnte es durchaus sinnvoll sein, eine "eigene" Schnittstelle
zu definieren...
Für den Gegenwert von einem einzigen Euro pro Gerät kann man in
diesem Fall schon ziemlich lange nachdenken

Controller mit CAN sind m.W. immer noch deutlich teurer als die
einfacheren Standard-Derivate. RS-485 mit modernen 1/4- oder 1/8-Last
Treibern dürfte da bei den Kosten besser wegkommen. Möglicherweise
geht's aber noch preiswerter mit einem eigenen Konzept und ganz
ohne spezielle Treiberbausteine; vielleicht verrätst Du einmal mehr
über die eigentliche Aufgabe:

- Master/Slave-Kommunikation?
- Du schriebst "unidirektional": heißt das, es gibt *keine* Antwort?
(Auch keine Quittung etc.?)
- Wieviele Informationen pro Telegramm?
- Wieviele Telegramme pro Sekunde am Master?
- Minimale/Maximale Zeit zwischen Telegrammen für jeden Slave?
- Wie genau kamst Du auf die 100 kbit/s "Nutzlast"?
- Welche Ressourcen sind im Master bzw. den Slaves sowieso vorhanden
oder gar frei (z.B. ľC, Komparatoren, ...)?
- Wozu das alles überhaupt?

Je mehr Informationen, desto besser die Antworten ;-)

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)

 

[Stefan Heinzmann]

Michael Jürgens schrieb:

Hi,

i2c scheint ja bei Microcontrollern so etwas wie ein Standard Bus zu
sein. Weiss jemand, wie Störanfällig der ist?
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)

Wie andere hier schon geschrieben haben dürftest Du mit CAN oder RS485
besser bedient sein als mit I˛C. Das heißt nicht daß es nicht mit I˛C
gehen würde, aber bei I˛C wird's schnell kritisch mit der kapazitiven
Buslast. I˛C ist entwickelt worden, um Bausteine innerhalb desselben
Gerätes miteinander zu verbinden. Da braucht man z.B. keine Angst vor
differierenden Massepegeln zu haben. Bei Deinem verteilten Aufbau kann
das durchaus ein Problem werden. Besser Du nimmst von Anfang an was
"Vernünftiges".

Bei RS485 letzterem muß man das Protokoll noch separat spezifizieren, da
es bei RS485 nur um die elektrische Schnittstelle geht. Das Protokoll
kann dabei auf asynchroner Übertragung (per UART) oder auf synchroner
Übertragung (z.B. HDLC) beruhen. Du wirst vermutlich anhand der
Fähigkeiten des Prozessors entscheiden wollen. Viele haben einen
eingebauten UART (oder wie das immer genannt wird), also würde sich eine
asynchrone Variante anbieten. Du solltest Dir aber darüber im klaren
sein daß das Protokoll insbesondere bei Multimasterbetrieb recht
knifflig werden kann. Es gibt auch fertige Protokolle (z.B. Profibus).

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.

--
Cheers
Stefan

 

[Michael Jürgens]

Tilmann Reh wrote:

Michael Jürgens schrieb:


Ich vergass zu erwähnnen, dass es extrem um die Kosten geht.
Ich suche nach einer Lösung wo ich die Möglichkeit habe 10000 ľC zu
adressieren. Da die Matrixartig auf einer Fläche von 20 x 20 Meter
angeordnet sind, wollte ich immer 100 Stück an einen Bus hängen.

CAN ist vermutlich erheblich teurer als RS485?


Wenn es "extrem" um die Kosten geht und 10000 ľC zum Einsatz kommen
sollen, könnte es durchaus sinnvoll sein, eine "eigene" Schnittstelle
zu definieren...
Für den Gegenwert von einem einzigen Euro pro Gerät kann man in
diesem Fall schon ziemlich lange nachdenken

Controller mit CAN sind m.W. immer noch deutlich teurer als die
einfacheren Standard-Derivate. RS-485 mit modernen 1/4- oder 1/8-Last
Treibern dürfte da bei den Kosten besser wegkommen. Möglicherweise
geht's aber noch preiswerter mit einem eigenen Konzept und ganz
ohne spezielle Treiberbausteine; vielleicht verrätst Du einmal mehr
über die eigentliche Aufgabe:

- Master/Slave-Kommunikation?
Es gibt einen Master, der die Daten auf die Slaves schickt.

Von den Slaves wird ausser einer Quittung nie etwas zum Master gesendet
werden.

- Du schriebst "unidirektional": heißt das, es gibt *keine* Antwort?
(Auch keine Quittung etc.?)
- Wieviele Informationen pro Telegramm?
- Wieviele Telegramme pro Sekunde am Master?
- Minimale/Maximale Zeit zwischen Telegrammen für jeden Slave?
- Wie genau kamst Du auf die 100 kbit/s "Nutzlast"?
Die Anzahl der Telegramme ist mir eigenlicht egal. Ich muss im

Durchschnitt einen Datenstrom von ca. 500 bis 1000 Bit/s an einen Slave
schicken. Durch Komprimierung könnte man das noch reduzieren, was aber
dann wieder die Kosten auf dem Slave erhöhen würde.
Wenn ich also 100 Slaves an einen Bus anschliesse, komme ich im
Extremfall auf 100kBit/s.

 

[Uwe Hercksen]

Michael Jürgens schrieb:

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

Hallo,

aber dann ist es doch bidirektional.
Wenn nun noch Broadcast an alle Slaves gehen soll, dann aber in diesem
Fall besser ohne Quittung. Denn sonst gibt es Kollisionen zwischen den
Quittungen.

Willst Du nur das Schema:
Master sendet an genau einen Slave, dieser Slave sendet Quittung zurück,
dann sendet Master an genau einen anderen Slave....?
Das geht noch einfach, da können keine Kollisionen zwischen mehreren
Quittungen entstehen.
Aber ein Timeout bei ausbleibender Quittung braucht man auch wieder und
das Timeout muss länger sein als eine verzögerte Quittung.

Man kann RS 485 auch mit zwei Paaren machen, ein Paar für Master zu den
Slaves, das andere Paar für Quittungen von Slaves zum Master.

Bye

 

[Michael Jürgens]

Uwe Hercksen wrote:

Michael Jürgens schrieb:


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


Hallo,

aber dann ist es doch bidirektional.
Wenn nun noch Broadcast an alle Slaves gehen soll, dann aber in diesem
Fall besser ohne Quittung. Denn sonst gibt es Kollisionen zwischen den
Quittungen.

Willst Du nur das Schema:
Master sendet an genau einen Slave, dieser Slave sendet Quittung zurück,
dann sendet Master an genau einen anderen Slave....?
Das geht noch einfach, da können keine Kollisionen zwischen mehreren
Quittungen entstehen.
Aber ein Timeout bei ausbleibender Quittung braucht man auch wieder und
das Timeout muss länger sein als eine verzögerte Quittung.

Genau so habich mir das vorgestellt. Dazu evtl. noch Broadcasts. Dann
aber ohne Quittung.

Bye

 

[Matthias Weingart]

Michael Jürgens <info@hunnenburg.de> wrote in
news:c228t7$3u9$1@online.de:

Ich vergass zu erwähnnen, dass es extrem um die Kosten geht.
Ich suche nach einer Lösung wo ich die Möglichkeit habe 10000 ľC
zu adressieren. Da die Matrixartig auf einer Fläche von 20 x 20
Meter angeordnet sind, wollte ich immer 100 Stück an einen Bus
hängen.

Also alle 20 cm ein Controller. Wenn es um die Kosten geht, dann ist
die preisgünstigste Möglichkeit das Verbinden der uC Pins direkt
miteinander. Zum Schutz kleine Serienwiderstände und Dioden nach +Vcc
und Masse (oder die internen Schutzdioden reichen schon aus) oder
vielleicht kommst du ja völlig sogar ohne Schutz aus (wenn es
abgeschlossen ist, die Kabel intern alle auf ner dicker Blechplatte
laufen usw., da im Betrieb keiner anfassen kann, dann ist das nicht so
problematisch).
Ich würde die einfach seriell verbinden, also Rxd und Txd am Controller
zusammenschliessen, dann die kleine Schutzschaltung davor und dann auf
die eine gemeinsame Busleitung raus. Musst du mal rechnen, wie schnell
deine uC-Ausgänge dann die kapazitiven Lasten umladen können, das ist
dann die Speed, die du noch erreichst. 100kbps sind da schon recht
anspruchsvoll! Da musst du dir dann vielleicht auch schon Gedanken um
die Signalreflektionen machen (Bus am Anfang und Ende mit der
Kabelimpedanz abschliessen). Notfalls bidirektionale Treiber IC's
dazwischenschalten (da ist man dann bald bei RS485). Eine Busleitung
ist dann aber 20m lang, und du musst was gegen Kollisionen tun
und die Geschwindigkeit ist durch die 100fache kapazitive Last stark
begrenzt (ich schätze mal, wenn die 300baud erreichst, hast du schon
viel Glueck ;-).

Unkritischer (in Bezug auf das Signal) wäre es, die Controller
hintereinanderzuketten, also

---Rxd(controller)Txd----Rxd(controller)Txd----Rxd(controller)Txd---

Damit ist jede serielle Leitung nur ca. 20cm lang und hat nur 1 Last.
Absolut unproblematisch. In der Firmware muss jeder Controller dann
einfach alle Daten die er empfängt, wieder rausschicken (sofern die
nicht nur allein für ihn sind). Du hast dann aber ne riesige
Datenlaufzeit. Bei 115000Baud sind es 86us pro Byte *100 = 8,6ms, ehe
der letzte Knoten erreicht wurde (mindestens, ev. auch etwas länger,
wenn Knoten Daten hinzufügen). Der letzte Knoten geht dann wieder
auf deinen Steuerrechner raus, der dann sogar überprüfen kann, ob das
was er geschickt hatte, durch alle Konten gelaufen ist. Vorteil: keine
Kollisionen, kurze Kabel, maximale Speed.

Das ist das Prinzip, wie es auch bei JTAG gemacht wird (dort aber mit
mind. 2 Leitungen, Clock und Daten) nur hier von mir auf 1 Leitung und
RS232 umgemünzt. Vielleicht hat dein Controller ja ein SPI Interface,
das sowas kann.

M.
--
Bitte auf mwnews2@pentax.boerde.de antworten.

 

[Tilmann Reh]

Michael Jürgens schrieb:

Willst Du nur das Schema:
Master sendet an genau einen Slave, dieser Slave sendet Quittung zurück,
dann sendet Master an genau einen anderen Slave....?
Das geht noch einfach, da können keine Kollisionen zwischen mehreren
Quittungen entstehen.
Aber ein Timeout bei ausbleibender Quittung braucht man auch wieder und
das Timeout muss länger sein als eine verzögerte Quittung.

Genau so habich mir das vorgestellt. Dazu evtl. noch Broadcasts. Dann
aber ohne Quittung.

Gut, aber an dieser Stelle kommt die Telegrammlänge wieder ins
Spiel. Denn ein Telegramm mit Quittung braucht eine gewisse
Antwortzeit, egal wie lang das Telegramm ist. Also sind in diesem
Fall längere seltene Telegramme günstiger als kurze häufige.

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

Also solltest Du zunächst mal prüfen, ob Deine Controller (Master
und Slaves) eine solche Bitrate überhaupt verarbeiten können.
Wenn nein, läuft das auf andere Typen oder externe Schnittstellen-
Controller hinaus, und dann könnte CAN doch wieder ins Spiel kommen...

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)

 

[Uwe Hercksen]

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