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?
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.
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.
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.
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 ?
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
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.
@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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.