Hallo. Ich hab eine Frage, ob es möglich ist, ein und dasselbe I2C Peripheral auf mehrere Pins zu mappen und zu benutzen. Und zwar hab ich konkret einen STM32F401. Auf den Pins PB8 und PB9 verwende ich I2C1. Auf den Pins PB6 und PB7 ist I2C1 auch verfügbar. Die Frage ist, wenn ich es auch dort konfiguriere, ob ich dann auch dort Geräte ansprechen kann. Also (fast) wie wenn das Gerät am Bus von PB8 und PB9 hängen würde. Der Grund für die Überlegung ist, dass wir eine Platine haben, die fertig produziert ist und bei der die Pins PB6 und PB7 auf einem Erweiterungssteckplatz geroutet sind. Ursprünglich nur als GPIOs vorgesehen. Und jetzt wärs interessant, ob wir sie nicht auch als I2C verwenden könnten. Aber es ist eben der selbe I2C Bus, den wir schon auf den anderen Pins in Verwendung haben. Eigentlich würde ich vermute, dass das trotzdem funktionieren sollte, oder? Danke schonmal, Andreas
Probierts doch aus :-P Ich denke, das es nicht geht, aber hinterher seid ihr klüger. Kaputt geht jedenfalls nichts.
Gleichzeitig sollte das nicht gehen. Umschalten sollte funktionieren.
Das geht nicht, nur entweder die primäre Zuordnung oder die Sekundäre. Schau dir die entsprechenden Register an, wo man das einstellt. Dann siehst du dass beides gleichzeitig unmöglich ist.
Stefan ⛄ F. schrieb: > Dann > siehst du dass beides gleichzeitig unmöglich ist. Umgekehrt ists richtig. Du kannst nicht mehrere AFs auf einen Pin mappen. Aber es steht nirgends, das man ein Peripheral AF nicht auf mehrere Pins mappen kann (siehe z.B. Figure 26 und 27 im RM0090 Dokument). Also doch ausprobieren. Der TE möchte ja I2C1 auf z.B. PB8 und PB9, sowie zusätzlich auf PB6 und PB7 mappen. Klar, man kann dann nicht z.B. USART1 auch noch auf PB6 und PB7 haben, aber das weiss der TE ja.
:
Bearbeitet durch User
Aber i²c auf mehreren Pins ergibt doch absolut keinen Sinn. Wie soll das funktionieren? Dafür ist die Peripherie nicht konzipiert.
Matthias S. schrieb: > Aber es steht nirgends, das man ein Peripheral AF nicht auf > mehrere Pins mappen kann Das würde aber intern zu einem Kurzschluss führen. Siehe Figure 20 in https://www.st.com/resource/en/reference_manual/dm00096844-stm32f401xb-c-and-stm32f401xd-e-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf Jeder I/O Pin hat seinen eigenen Schmitt Trigger. Wenn der eine ein HIGH liefert und der andere ein LOW, dann hast du einen Kurzschluss. Ich vermute, dass der Chip diese Konfiguration verhindert. Egal ob er es tut, oder nicht: es kann nicht funktionieren - falls dieses Diagramm stimmt.
Also im Grunde möchte ich nur erreichen, dass die I2C Signalisierung auch auf den beiden anderen Pins rauskommt. Im Endeffekt wäre es so, als würde ich einen zusätzlichen I2C Slave an den selben Bus hängen (also Microcontroller soll Master sein), nur dass die "Verkabelung" nicht direkt auf der Platine erfolgt sondern einmal über den Controller geht. Durch die verschiedenen I2C Adressen sollte es auch zu keinen Konflikten kommen. Einziges Problem das ich momentan sehe, ist, welches Eingangsignal kriegt das I2C Peripheral im Controller. Das von den zuletzt konfigurierten Pins? Dachte nur, vielleicht hat das schonmal jemand versucht.
Andreas A. schrieb: > Also im Grunde möchte ich nur erreichen, dass die I2C Signalisierung > auch auf den beiden anderen Pins rauskommt. Die beiden Pins arbeiten bidirektional. > Einziges Problem das ich momentan sehe, ist, welches Eingangsignal > kriegt das I2C Peripheral im Controller. Das von den zuletzt > konfigurierten Pins? Das meine ich doch! Es kann nur einer sein oder gar keine Funktion.
Stefan ⛄ F. schrieb: > Die beiden Pins arbeiten bidirektional. Sind aber, wenn man es richtig macht, auf Open Drain konfiguriert. Ein Kurzschluss kommt also nicht vor, höchstens ein Konfilkt, bei dem man den Pegel falsch lesen würde.
Matthias S. schrieb: > Kurzschluss kommt also nicht vor Doch, weil zwischen jedem I/O Pin und dem internet Alternate-Function Umschalter ein Schmitt-Trigger liegt. Siehe Figure 20 in https://www.st.com/resource/en/reference_manual/dm00096844-stm32f401xb-c-and-stm32f401xd-e-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf (wie ich bereits schrieb).
Ok. Ich hab das jetzt mal kurz so konfiguriert und es hat sich gezeigt, dass auch der I2C Slave der auf den ursprünglichen Pins hängt dann nicht mehr antworten mag. Ich bin hier aber nicht ins Detail gegangen. Eventuell, fehlt ihm das Acknowledge vom Slave, das er dann vielleicht auf dem anderen Eingang erwartet und nicht bekommt. Aber wie gesagt... ich habs nicht im Detail angeschaut. Gehen tuts wie es ausschaut tatsächlich nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.