Guten Tag,
ich möchte von einem Atmega32 und einem Atmega168 auf ein gemeinsam
genutztes Eeprom 24C32 zugreifen. Solange sich die 2 Master per
separatem Handshake einig sind und nicht gleichzeitig den Bus
aktivieren, ist alles gut. Jetzt möchte ich aber den Bus per Befehl
aufteilen, so dass der Atmega32 seine eigenen Slaves(Portexpander und
LCD) hat und der Atmega168 gleichzeitig Befehle aus dem Eeprom
verarbeitet.
Zur Zeit habe ich das versuchsweise (Steckbrett) mit einem Relais(5V,
20mA, 2 Wechsler) gelöst. Die Wechsler schalten SCL und SDA um. Für
diese zugegeben rustikale Lösung suche ich eine elegantere Variante. Zum
einen möchte ich keine Schaltkontakte in den Busleitungen haben und zum
anderen ist die Relais-Umschaltzeit von 10 ms nicht prickelnd. Ich hab
von einem I2C Bus-Switch(PCA9546) gelesen, bin mir aber nicht sicher, ob
ich damit zwei getrennte Busse realisieren kann.
Wenn jemand Vorschläge oder Hinweise hat - besten Dank!
DianaZ
Wenn die I2C Master beide die Arbitrierung sauber implementiert haben,
bracht man keine Relais/Switches/etc. Man kann beide einfach parallel
schalten. Der Bus ist extra dafür designt worden.
Mit dem EEProm muß man aber aufpassen, während es speichert erzeugt es
keine ACKs. Wenn also MasterA grad war geschrieben hat, und MasterB
sofort danach z.B. lesen will, sieht es für ihn aus, also ob das EEProm
nicht da wäre.
Lies Dich mal in die I2C Specs ein und finde heraus, ob Deine Master die
Arbitrierung sauber können. Dann ist das Leben plötzlich ganz einfach!
Martin Wende schrieb:> Der EEPROM gibt zwar kein ACK, abern NACK.
Bist Du Dir sicher, daß das EEPROM beim NACK SDA aktiv auf "1" zieht?
Ich bin davon ausgegangen, daß es einfach nur "nichts" macht, und
stattdessen den Pullup arbeiten läßt.
Seisdrum, der Master kann eh nicht unterscheiden, ob gerade der Pullup
oder das EEPROM im NACK-Moment die Leitung nach high ziehen.
Guten Tag,
Jörg, ich wollte wirklich den Bus auftrennen, um zeitgleiches,
paralleles Arbeiten der beiden Master am jeweiligen Bus zu ermöglichen.
Vielleicht hab ich es nicht genau formuliert. Sicher kann man zwei
Master parallel an einem Bus anschliessen. Bei Multimaster/Arbitrierung
werden sich zwei Master am gemeinsamen Bus einig, um NACHEINANDER auf
CLK/SDA zuzugreifen. Also muss unter Umständen ein Master warten. Dieses
Warten wollte ich vermeiden.
Per "Umschaltung" sollte der Zugriff auf das gemeinsame Eeprom möglich
sein, etwa bei der Initialisierung oder zum Abspeichern gemeinsamer
Daten - beides dann im zeitunkritischen Programmteil.
Deshalb dachte ich an die elektrische Aufteilung in zwei unabhängige
Busse.
DianaZ
Die einfachste Lösung, nimm für weitere Single-Master ein SW-I2C.
Solange nicht Multi-Master benötigt wird, hat HW-I2C keine Vorteile.
Ich finde SW-I2C sogar einfacher und stabiler.
Peter Dannegger schrieb:> Die einfachste Lösung, nimm für weitere Single-Master ein SW-I2C.
Ja das würde auch gehen, ich brauch dazu zwei freie Ports. Beim Atmega32
könnte ich das prüfen. Hast Du für SW-I2C erprobten Code in C parat?
Danke!
DianaZ
Abdul K. schrieb:> Gibt auch EEPROM mit zwei Bussen. Eventuell findest du das einfacher in> deiner Anwendung.
Daran hatte ich noch nicht gedacht, wusste nicht dass es solche Eeproms
gibt. Das würde mein Problem sicher auch lösen. Hast Du eine
Typbezeichnung oder Bezugsquelle? Danke!
Oder gibt es nicht doch so eine Art Switch oder "Busweiche" mit Open
Collector?
DianaZ
Veit Z. schrieb:> Hast Du für SW-I2C erprobten Code in C parat?
Anbei meine Lib für die 4 Grundfunktionen.
Das I2C-Start hat noch ein besonderes Schmankerl. Falls ein Slave den
Bus blockiert, z.B. nach einem Störimpuls oder einem MC-Reset, versucht
es, den Bus wieder freizuschalten. Ein HW-I2C kann sowas nicht.
SCL wird als Ausgang verwendet, d.h. es braucht keinen Pullup. Das geht
natürlich nur für "dumme" Slaves, d.h. die kein SCL-Stretching machen.
Für MCs als Slave muß man das SCL-Stretching noch einbauen.
Ich hatte eine Applikation, wo häufig aus einem EEPROM gelesen wurde.
Beim ISP wurde das nun zufällig unterbrochen und manchmal zog der EEPROM
SDA auf low und der I2C hing nach dem ISP.
Mit dieser Routine wird der hängende Slave nun resettet.
Aber auch, wenn man nicht ständig neu programmiert, erhöht das die
Zuverlässigkeit. Es kann ja sein, daß ein kurzer Spannungseinbruch zwar
den MC resettet, aber nicht die I2C-Slaves.
