TWI oder SPI oder RS232

[Mr. K. (kaktus-)]

Hallo Forum,

habe folgendes Projekt:

In einem 19 Schrank gibt es verschiedene "Einschübe" wie 
Stromversorgung, HF-Sender, HF Empfänger, Steuerung etc. In jedem 
Einschub sitzt ein Mega8 als Controller, der verschiedene Daten sammelt, 
Spannung misst etc.

Alle Einschübe sollen über einen bidirektionalen Bus mit dem Einschub 
"Steuerung" verbunden werden. In die Steuerung soll ein ATmega256 wegen 
dem großen Speicher.

Beim Bus dachte ich an einen I2C Bus, damit hab ich bereits etwas 
Erfahrung gesammelt, jedoch bin ich jetzt fast am verzweifeln beim 
Master - Slave Betrieb. Ich arbeite mit Bascom (und möchte auch gerne 
dabei bleiben).Ich lese jetzt schon 2 Wochen von MASTER/ SLAVE mit 
Bascom und bin nun vollends wuschelig mit den ganzen Libraries.  Nun bin 
ich mir nicht mehr sicher ob I2C die beste Wahl ist.

Ist auch SPI geeignet?         Vorteile / Nachteile ?
Oder einfach UART / RS232?     Vorteile / Nachteile ?

Der ATmega256 hat ja mehrere RS232 Schnittstellen, evtl ist das 
einfacher?

[2922 (Gast)]

Im Gegensatz zu I2C (TWI) ist SPI bidirektional, ohne die Richtug 
umzuschalten. Dh SPI ist potentiell schneller.

Asynchron (UART) ist mit 2 signalen bidirektional.

Treiber, dh RS232, RS422, oder RS485 kann man sowohl asynchron, als auch 
synchron mit SPI verwenden. Sie werden verwendet, um die Reichweite zu 
erhoehen und Stoerungen zu unterdruecken.

[Mr. K. (kaktus-)]

2922 wrote:
> Im Gegensatz zu I2C (TWI) ist SPI bidirektional, ohne die Richtug
> umzuschalten. Dh SPI ist potentiell schneller.

Soviel mir bekannt ist, ist I2C auch bidirektional z.B. bei Master-Slave 
Betrieb.

Aber erstmal danke für deinen Beitrag, ich schau mir grad mal Beispiele 
mit SPI an, scheint gar net so schwer zu sein.

[Andreas K. (a-k)]

SPI-Slave auf AVRs ist nicht einfach, aufgrund fehlender Pufferung des 
Transferregisters. Der Slave darf da ja nur dann was reinschreiben, wenn 
grad kein Transfer läuft.

[M. H. (doktorgnadenlos)]

Es schein hier ein paar grundsätzliche Denkfehler zu geben

1. Alle Schnittstellen sind bidirektional, die Frage ist nur, ob es pro 
Datenrichtung eine (I2C) oder zwei (SPI, UART) physikalische 
Datenleitungen gibt.

2. Kein Controller hat einen RS232-Schnittstelle. ihr meint eine UART. 
Was ihr daraus macht ist Euch überlassen (RS232, RS485, LIN u.ä.)

3. TWI ist der von ATMEL gebrauchte Name für I2C. ursprünglich ist I2C 
ein geschützter Name, ATMEL wollte nicht für jede Nutzung im Datenblatt 
Geld für Philips abdrücken.

4. I2C ist ein lokaler Bus, d.h. man kann damit keine weiten Distanzen 
(sprich . Kabelverbindungen) überwinden. Die Idee dabei : das 
Platinenlayout übersichtlich zu halten, kompakte Bausteine einsetzen.

Noch Fragen ?

[Kaktus (Gast)]

OK soweit, das wäre erst mal geklärt.

Ich habe gestern ein paar Versuche mit dem SPi Bus gemacht. Habe dazu 
zwei Mega 8 über SPI verbunden und habe ein Bascom Beispiel Programm 
verwendet. Es funktionierte komischerweise auf Anhieb. Es sind vier 
Leitungen notwendig. MISO MOSI SCK und SS. Das ganze funktioniert auch 
bidirektional ohne das ich eine extra LIB ( I2C TWI SLave )kaufen muss. 
Also wäre SPI jetzt erst mal meine erste Wahl für obiges Projekt.

Gedanke:

Eigentlich müsste das mit den UARTS ( serielle Schnittstelle mit TTL 
Pegel ) genausogut gehen. Der Nachteil ist doch, wenn ich das richtig 
sehe, ich muss zum jeden Slave eine eigene Leitung legen und brauche am 
Master die entsprechende Anzahl an UARTS ? Der Vorteil wäre das ich mit 
dem Laptop und einen MAX232 als Pegelwandler mich direkt auf den SLave 
hängen kann um dort nach den rechten zu schauen.

Ist eine Kabellänge beim SPI BUS von 0,5m verträglich? Denke da an Patch 
Kabel.

mfg

Kaktus

[M. H. (doktorgnadenlos)]

Busfähig, d.h. mehrere Teilnehmer an einem Strang, ist nur der I2C, alle 
anderen sind zunächst Peer-to-Peer-Verbindungen.
Allerdings läßt sich aus einem UART-Bus, wenn die Ausgänge nicht "hart", 
sondern nur über einen PullUp-Wiedertand nach VCC schalten, ein 
busfähiges System machen. Ich weiß nicht genau, ob die AVRs die 
TxD-Leitung hart gegen VCC schalten. Wenn ja, kann man das mit einer 
externen Diode + Pullup-Widerstand vermeiden.
Weiters müssen die angeschlossenen Teinehmer über eine eindeutige 
Adresse verfügen, das Handling in den höheren Kommunikationsschichten 
wird entsprechend komplexer.
Wenn man sich das nicht antun will, bleibt nur das Verfahren mit 
mehreren UARTs, ganz richtig.
Will man den Bus nur "belauschen", kann man das natürlich jederzeit mit 
einem Terminalprogramm (z.B. ZOC) tun.

[Martin Cibulski (Gast)]

@Markus:

>> I2C ist ein lokaler Bus, d.h. man kann damit keine weiten Distanzen
>> (sprich . Kabelverbindungen) überwinden.

Wie sieht es INNERHALB eines Baugruppenträgers mit I2C aus ?

Ich baue gerade ein System mit einer Masterkarte (LPC2148) und mehreren 
Slavekarten (mega16), die über I2C Befehle vom Master erhalten sollen. 
Dabei läuft der I2C-Bus über die Backplane.

So etwas sollte doch funktionieren, oder nicht ?

Gruß,
Martin