i2c Bus

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

Reply to
=?ISO-8859-1?Q?Michael_J=FCrge
Loading thread data ...

Michael J=FCrgens schrieb:

(bis=20

hirmt=20

ein=20

Hallo,

daf=FCr scheint mir RS485 wesentlich besser geeignet, da kann man Parity =

und CRC benutzen.

Bye

Reply to
Uwe Hercksen

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

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

Gruß

Stefan

Reply to
Stefan Broering

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

Gruß,

Michael

Reply to
=?ISO-8859-1?Q?Michael_J=FCrge

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

--
Matthias Weißer
matthias@matwei.de
 Click to see the full signature
Reply to
=?ISO-8859-1?Q?Matthias_Wei=DF

CAN??

Robert

Reply to
R.Freitag

"R.Freitag" schrieb:

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ü

Reply to
Hans J. Ude

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

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!

formatting link

Reply to
Igor "Knight" Ivanov

Michael J=FCrgens schrieb:

Hallo,

keine Repeater m=F6glich?

Bye

Reply to
Uwe Hercksen

Michael Jürgens schrieb:

Alles ist möglich.

CU. Igor.

Reply to
Igor "Knight" Ivanov

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

Reply to
=?ISO-8859-1?Q?Michael_J=FCrge

Michael Jürgens schrieb:

Ü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ü

Reply to
Hans J. Ude

Michael Jürgens wrote in news:c228t7$3u9$ snipped-for-privacy@online.de:

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.
Reply to
Matthias Weingart

Michael Jürgens schrieb:

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ß.
 Click to see the full signature
Reply to
Tilmann Reh

Michael Jürgens schrieb:

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
Reply to
Stefan Heinzmann

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

Reply to
=?ISO-8859-1?Q?Michael_J=FCrge

Michael J=FCrgens schrieb:

=20

Hallo,

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

Willst Du nur das Schema: Master sendet an genau einen Slave, dieser Slave sendet Quittung zur=FCck= ,=20 dann sendet Master an genau einen anderen Slave....? Das geht noch einfach, da k=F6nnen keine Kollisionen zwischen mehreren=20 Quittungen entstehen. Aber ein Timeout bei ausbleibender Quittung braucht man auch wieder und=20 das Timeout muss l=E4nger sein als eine verz=F6gerte Quittung.

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

Bye

Reply to
Uwe Hercksen

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

Bye

Reply to
=?ISO-8859-1?Q?Michael_J=FCrge

Michael Jürgens schrieb:

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ß.
 Click to see the full signature
Reply to
Tilmann Reh

Tilmann Reh schrieb:

Hallo,

die 100 kbit/s sind doch wohl f=FCr die 10000 Slaves gedacht. Wenn aber jeweils 100 Slaves an 100 "Unterbussen" h=E4ngen, dann wird es =

doch wohl erheblich langsamer zugehen. Da scheint es mir sinnvoller und kostensparender die Unterbusse zu den=20 Slaves entsprechend langsamer zu betreiben, das senkt den Aufwand bei=20 den Slaves deutlich. Der Master muss dann allerdings in der Lage sein etliche Unterbusse=20 simultan zu bedienen, also mit je einer seriellen Schnittstelle pro=20 logischem Unterbus.

100 logische Unterbusse sind aber wieder etwas viel des Guten, so etwa=20 10, 20 oder 25 sollten reichen. Von einem logischen Unterbus geht es dann mit Repeatern wieder an 4 bis=20 10 physikalische Unterbusse.

Ich hoffe es ist gen=FCgend klar geworden was ich meine, eine Baumstruktu= r. Eine mehrstufige Hierarchie w=E4re auch zu =FCberlegen, ein Master, 10=20 Aufseher, 100 Vorarbeiter und 10000 Slaves z.B.

Bye

Reply to
Uwe Hercksen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.