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!
@Joerg L.: Also AVRs können Multimaster I2C. Der EEPROM gibt zwar kein ACK, abern NACK. Er ist also nicht in Richtung Mond verschwunden ;)
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.
Gibt auch EEPROM mit zwei Bussen. Eventuell findest du das einfacher in deiner Anwendung.
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
Sowas: http://ww1.microchip.com/downloads/en/DeviceDoc/21176d.pdf Hab ich so gefunden: http://www.google.de/search?hl=de&source=hp&q=DDC2+eeprom+i2c&gbv=1 http://en.wikipedia.org/wiki/Display_Data_Channel bzw. es gibt auch welche mit einer Seite RFID und die andere Seite i2c. Ist natürlich ne Preis- und Beschaffungsfrage. Mit Standardbauelementen kommt man längerfristig immer besser! Arbitierung läuft bei i2c über die Master(plural). Den Slaves ist das egal! Semaphore mußt du also selbst verwalten!!
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.
Hast du die Deblocking-Routine auch praktisch getestet oder ist die nur hypothetisch entstanden?
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.
Danke.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.