Der VS1000 von VLSI hat leider keine I2C/TWI-Schnittstelle. Ich möchte allerdings einen IO-Expander damit steuern. Ist es möglich, das I2C-Protokoll mithilfe der vorhandenen GPIO-Pins zu emulieren? Theoretisch müsste das ja möglich sein, aber wieso haben Mikrocontroller dann spezielle GPIOs für I2C, wenn man eigentlich jeden Port dafür nutzen könnte?
@ Kim-Yannick Jürs (kim_yannick) >Der VS1000 von VLSI hat leider keine I2C/TWI-Schnittstelle. Ich möchte >allerdings einen IO-Expander damit steuern. Ist es möglich, das >I2C-Protokoll mithilfe der vorhandenen GPIO-Pins zu emulieren? Schreibst du SELBER Firmware für den VS1000? >Theoretisch müsste das ja möglich sein, Ja, wenn man die IOs dynamisch zwischen EIngang und Ausgang umschalten kann. >aber wieso haben Mikrocontroller >dann spezielle GPIOs für I2C, wenn man eigentlich jeden Port dafür >nutzen könnte? Weil das I2C Modul nur an diesen bestimmten IOs angeschlossen ist.
Gast
#4370288
Kim-Yannick J. schrieb: > aber wieso haben Mikrocontroller > dann spezielle GPIOs für I2C, Weil nach Standard die I2C Pins echte Open-Kollektor-Pins sein sollen und deshalb auch keine Probleme machen sollen, wenn der µC nur mit 3.3 V betrieben wird und am I2C die Hochzieh-Widerstände an 5 V gehen. Zum Emulieren kann man zumeist zwei ganz gewöhnliche Portpins nehmen, man muß sie bloß für High aud tristate schalten können. Geht das nicht, dann sind (für Master) 3 Portpins und zwei simple Transistoren nötig: ein Portpin+Transistor als O.C. Treiber für SCL und dasselbe nochmal für SDA. Der dritte Portpin ist (mit dezentem Vorwiderstand) zum Abtasten von SDA nötig. W.S.
Ich würde meine eigene Firmware dafür schreiben. Das dynamische Umschalten müsste eigentlich möglich sein (hoffe ich).
Wenn ich SPI-Flash benutze hätte ich genug Pins frei, allerdings scheint SPI-Flash nicht mehr richtig verkauft zu werden. Gibt es irgendwo noch eine Quelle für "guten" SPI-NAND?
Gast
#4372183
W.S. schrieb: >> aber wieso haben Mikrocontroller >> dann spezielle GPIOs für I2C, > > Weil nach Standard die I2C Pins echte Open-Kollektor-Pins sein sollen > und deshalb auch keine Probleme machen sollen, wenn der µC nur mit 3.3 V > betrieben wird und am I2C die Hochzieh-Widerstände an 5 V gehen. Noch ein bißchen schärfer - I²C Pins müssen sogar hochohmig sein selbst wenn der Bauteil gar nicht versorgt wird. Diesen Spezifikationspunkt verletzen allerdings so manche Chips leider wegen falsch ausgelegter integrierten Schutzbeschaltung. Die die sich an die Spec halten haben folglich spezielle Pins weil man ja so eine unübliche Schutzbeschaltung nicht an allen GPIOs einbauen will.
IO-Expander gibts auch mit SPI, zB MCP23S17. Da hast Du das Problem nicht. fchk
Gast
#4372247
W.S. schrieb: > Zum Emulieren kann man zumeist zwei ganz gewöhnliche Portpins nehmen, > man muß sie bloß für High aud tristate schalten können. "tristate" ist der Begriff, der klarstellt, dass ein Port in der Lage ist, neben "low" und "high" auch noch einen dritten Zustand liefern zu können, englisch: High-Z (deutsch: "hochohmig" bzw. "hochimpedant"). Wie auch immer: für I2C braucht man tatsächlich diesen High-Z-Zustand, aber als zweiten nicht etwa High (das besorgen die Pullups, wenn die Ausgänge High-Z sind), sondern natürlich LOW.
Gast
#4372274
Kim-Yannick J. schrieb: > Theoretisch müsste das ja möglich sein, aber wieso haben Mikrocontroller > dann spezielle GPIOs für I2C, wenn man eigentlich jeden Port dafür > nutzen könnte? Hauptsächlich weil viele Mikrocontroller (wie die kleinen AVR) die Peripherie-Einheiten fix an bestimmten Pins haben, und die Pins die an der I²C-Peripherie hängen somit festgelegt sind. Man kann zwar I²C per Software machen, aber dann kann man auf dem Controller kaum noch was anderes gleichzeitig machen um das Timing einhalten zu können. Die maximale Geschwindigkeit erreicht man so auch nicht unbedingt.
Dr. Sommer schrieb: > Man kann zwar I²C per > Software machen, aber dann kann man auf dem Controller kaum noch was > anderes gleichzeitig machen um das Timing einhalten zu können. Nö, der Master kann sich alle Zeit der Welt nehmen, zwischenzeitliche Interrupts sind überhaupt kein Problem. SW-Master-I2C wird daher gerne genommen. Manchmal muß man es sogar nehmen, weil das HW-I2C buggy ist und sich bei Störungen aufhängen kann. Und wenn das HW-I2C nicht als Interrupt läuft, ist es auch nichtmal schneller.
Gast
#4372302
Peter D. schrieb: > Nö, der Master kann sich alle Zeit der Welt nehmen, zwischenzeitliche > Interrupts sind überhaupt kein Problem. Aber auch nur der Master und auch nur in einem Single-Master-System, denn bei Multi-Master müsste man kontinuierlich den Bus überwachen auf "Busy". Peter D. schrieb: > Und wenn das HW-I2C nicht als Interrupt läuft, ist es auch nichtmal > schneller. Genau dafür ist es aber da... Und dann gibts auch so nette HW-I²C's die können FM+ mit 1 MHz oder so.
Gast
#4372506
Naja, Multimaster ist aber nun alles andere als die Regel... genau wie FM+, das verwendet fast niemand, da kaum ein Slave es unterstützt.
Gast
#4373048
Dr. Sommer schrieb: >> Nö, der Master kann sich alle Zeit der Welt nehmen, zwischenzeitliche >> Interrupts sind überhaupt kein Problem. > Aber auch nur der Master und auch nur in einem Single-Master-System, > denn bei Multi-Master müsste man kontinuierlich den Bus überwachen auf > "Busy". Nein auch der Slave kann sich in gewissen Bereichen Zeit lassen. Deshalb gibt's ja clock stretching im I²C Standard definiert.