MSP430 I2C und SPI toggeln

Hallo,

ich habe ein Problem, bzw. ich bin auf der Suche nach einem Bauteil das folgendes Problem lösen kann.

Ich möchte gerne einen MSP430F169 einsetzen. Dieser stellt 2 USARTs zur Verfügung, von welchen eine als I2C eingesetzt werden kann. Eine USART möchte ich exclusiv mit einem UART Device verbinden. Die verbleibende Schnittstelle möchte ich zeitweise als I2C an einer RTC betreiben und zweitweise um verschiedene andere Devices via SPI zu kontaktieren.

Das eigentliche Problem ist nun, dass die I2C Pins und die SPI Pins sich decken (SCL und UCLK, sowie SDA und SIMO). Jetzt habe ich Hemmungen, die beiden Busse einfach parallel anzuklemmen, denn: Wenn der MSP 'SPI' spricht könnte sich das I2C Device angesprochen fühlen und evtl. herumbabbeln, oder?

Anders herum ist es wohl nicht so kritisch, da die SPI Devices ja mittels STE als Chipselect direkt angesprochen werden.

Daher dachte ich mir, dass es nötig ist, einen Bustrenner an den Anfang des I2C zu setzen, damit ich quasi eine Weiche habe, die dann der MSP (ver)stellt, bevor er den Bus (welchen auch immer) benutzt... .

Dieser Bustrenner/Treiber müßte also einen enable haben und im Zustand 'sidabled' den Ausgang hochohmig schalten. Und dieser Baustein müßte bidirektional sein, damit das I2C Device seine Daten auf senden kann.

Hat jemand Erfahrung mit dieser Problematik? Oder habe ich einen Denkfehler?

Weiß jemand einen geeigneten Baustein?

Christian

Reply to
Christian Schulz
Loading thread data ...

Hängt an dem I2C nur die RTC oder noch weiteres ? Und wie zeitkritisch ist der Zugriff darauf ?

Den I2C-Zugriff könntest du evtl. ja auch über normale GPIO-Ports abwickeln, von denen der MSP430 ja genug hat. Einen I2C-Master in Software zu bauen ist nicht sehr schwer und es gibt auch einiges an Codebeispielen dafür. (Ich hab das früher auch mal am MSP430 gemacht, als er noch kein Hardware-I2C-Interface hatte)

Nur mal so als Alternative, bevor du großartig externe Logik brauchst.

cu Thomas

Reply to
Thomas Pinz

Initial wird wohl tatsächlich nur der RTC am I2C hängen (nicht zeitkritisch). Jedoch könnten unter Umständen auch weitere Devices hinzutreten, die evtl. die Lösung in Hardware benötigen.

Christian

Reply to
Christian Schulz

Thomas Pinz wrote in news: snipped-for-privacy@individual.net:

Das muss er sowieso machen, weil der I2C-Master in den '16xern Rev A, B kaputt ist. Kannst z.B. die CLK-Ltg sharen und nur den SDA auf nen extra Pin legen. Slave soll übrigens gehen (Wissen nur aus der MSP430 yahoo-Group, das neue I2C Zeuchs in den MSPs habe ich noch nicht angefasst :-).

Ob das grundsätzlich geht (I2C und SPI sharen) muesste man sich mal genauer ansehen. Entweder erzeugen die Signale an SPI gar keine Startbedingungen oder ständig welche (Daten wechseln ja nur, wenn clk unten ist; nicht wenn er oben ist; oder umgekehrt...). Beides würde nicht stören. M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.
Reply to
Matthias Weingart

Hallo Christian,

Was Du suchst, nennt sich BUS-SWITCH und hört z.B. bei TI auf die Namen

74CBTxyz. Du kannst auch aus der 40er Reihe (74HC40xy) die mit den Analogschatern nehmen, wenns nicht zu schnell zugeht, ansonsten wäre evtl der zusätzliche Widerstand schädlich (was bei I²C höchstens wegen dem Pullup stress machen könnte). Gibt es in allen Familien auch als Umschalter, bidirektional sind sie per Prinzip.

Marte

Reply to
Marte Schwarz

Ist das mit der defekten I2C Hardwareeinheit gesichert? Im Errata steht nichts davon... . Hmmm gibt's diese Y! Group noch? Konnte eben nichts finden bei der Suche nach MSP430... .

Christian

Reply to
Christian Schulz

"Christian Schulz" schrieb im Newsbeitrag news:d4rbmq$iq3$ snipped-for-privacy@worf.visyn.net...

Hallo Christian,

das ist die größte Gruppe dies es überhaupt zum MSP430 gibt.

formatting link

SPI und I2C auf den gleichen Pins zu benutzen ist eine Schnapsidee. Vergiss es.

Gruß Helmut

Reply to
Helmut Sennewald

"Helmut Sennewald" schrieb im Newsbeitrag news:d4rd73$p8h$00$ snipped-for-privacy@news.t-online.com...

....

Nachschlag ==========

Hallo Christian,

wenn man bei I2C der Master ist, dann kann man das problemlos mit beliebigen Portpins plus einem Open-Drain Treiber(Gatter) machen. Das scheint ja bei dir der Fall zu sein.

Clock->

Dout->"OD"->

Din

Reply to
Helmut Sennewald

Christian Schulz wrote in news:d4rbmq$iq3$ snipped-for-privacy@worf.visyn.net:

Jedenfalls haben etliche Leute berichtet, das sie alles auf Software-Master ungestellt hatten, nachdem es mit dem HW-Master unerklärliche Ausfälle gegeben hat (unstabile Operation, manchmal gehts, manchmal liest er aber Mist).

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.
Reply to
Matthias Weingart

Hallo Helmut,

ich bin nun ein Stück weiter gekommen, und zwar habe ich in den Application Notes von TI ein Beispiel gefunden, wie man einen I2C mit nur zwei Portpins emulieren kann.

formatting link

Christian

Reply to
Christian Schulz

"Helmut Sennewald" wrote in news:d55nnt$6gr$00$ snipped-for-privacy@news.t-online.com:

Naja für simple Temperatursensoren magst du recht haben. Sofern da aber ein (bevorzugt uC-basierter) Chip mit dran ist, der den CLK als Slave unten hält, solltest Du das nich ttun. :-)

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.
Reply to
Matthias Weingart

----- Original Message ----- From: "Christian Schulz" Newsgroups: de.sci.electronics Sent: Sunday, May 01, 2005 5:55 PM Subject: Re: MSP430 I2C und SPI toggeln

Hallo Christian, für den Clock braucht man gar keinen Pullup. Da dein Prozessor immer der Master ist, kannst du diese Leitung auch gleich hart treiben. Das hat den großen Vorteil daß deine Flanken am Clock schön steil bleiben. Da sind kleiner 300ns gefordert. Allerdings am Dateineingan auch. Ich hatte in der Vergangenheit mit einem IC einmal Probleme wegen zu lahmer Clockflanke.

Die Richtung des Daten-Pins am Prozessor umzuschalten ist sicher eine nette Idee, wenn der Prozessor das Spikefrei kann. Ich gehe davon aus, daß das beim MSP430 geht da es in einer Appnote vorgeschlagen wird.

Gruß Helmut

Reply to
Helmut Sennewald

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.