MSP430 SPI-Schnittstelle

[Andreas (Gast)]

Hallo zusammen,

ich möchte über die SPI-Schnittstelle einen Baustein ansprechen(Daten 
senden und entfangen)
Dazu möchte ich den STE-Pin (PIN-Bereich 3.0-3.3) auf Masse ziehen um 
den Slave-Baustein zu aktivieren und dann Daten senden. Im User Guide 
steht, man kann einen 3-Wire-System und ein 4-Wire-System einstellen. 
Mit dem 4-Wire-System geht der MC in den Slave-Mode wenn ich STE 
verändere (??).
Das kann doch nicht so schwer sein, Ze fix!!
Kann mir hier irgendjemand weiterhelfen Verzweiflung

Gruß
Andreas

[Rufus Τ. F. (rufus)]

a) Welchen MSP430 verwendest Du?

b) Was ist das für ein Baustein, mit dem Du da kommunizieren willst?

c) Wer soll bei der Übertragung Master, und wer Slave sein?

[Andreas (Gast)]

Ich verwenden den MSP430FG4619, dieser soll auch der Master sein.

Zu dem Baustein gibt es noch kein Datenblatt, wenn ich z.B. 0x20 an den 
Baustein sende, führt er etwas aus.

[Dennis (Gast)]

Andreas schrieb:
> Im User Guide
> steht, man kann einen 3-Wire-System und ein 4-Wire-System einstellen.

3-Wire:

CLK
DIN
DOUT

4-Wire:

CLK
DIN
DOUT
STE

Der Mikrocontroller geht nicht automatisch in den Slave-Modus, nur weil 
du STE benutzt - STE regelt nur selbstständig die Chip-Select-Leitungen.

Leider fällt bei ihrer Benutzung ein weiter Kommunikationspin weg, da 
diese meist doppelt belegt sind - daher wird jeder, der die USCIs 
braucht, eine eigene CS-Leitung als normalen Port-Pin ausführen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andreas schrieb:
> Im User Guide steht, man kann einen 3-Wire-System
Hier werden MISO und MOSI verbunden, das ist auch bekannt als 
Microwire...
Damit können nicht wie bei SPI gleichzeitig Daten gesendet und 
empfangen werden.

> und ein 4-Wire-System einstellen.
Das dürfte der klassische SPI sein: SS, MOSI, MISO und SCLK.

Du solltest das Datenblatt nochmal genau lesen.
IdR. ist es so, dass der uC, wenn er als Master konfiguriert ist, nichts 
mit der SlaveSelect Leitung tut. Das mußt du selber in die Hand nehmen, 
und einen Portpin vor der Übertragung richtig setzen, und nachher wieder 
deaktivieren...

EDIT:
Dennis schrieb:
> 3-Wire:
>
> CLK
> DIN
> DOUT
Das ist ja ein blödes Interface.
Da fehlt jede Synchronisation auf Byte- bzw. Wortebene...

[Andreas (Gast)]

Hat das noch keiner gemacht mit dem MSP430?
Ist doch normale Vorgehensweise, den CS auf LOW etc.

[nicht_eingeloggt (Gast)]

Initialisierung sollte ungefähr so aussehen. Ist zwar von nem F5438, 
aber das ist alles recht ähnlich. Zu beachten ist dann noch, dass das 
Teil in diesem Fall eine RX-ISR braucht

void SpiUcb1Init (void)            
{
  P3OUT |= BIT6;              //cs high
  P3DIR |= BIT6;              // P3.6 output (CS)
  P3SEL |= 0x80;                            // P3.7 option select
  P5SEL |= 0x30;              //P5.4,5 option select
  UCB1CTL0 |= UCMST+UCSYNC+UCMSB;        //3-pin, 8-bit SPI master, MSB first
  UCB1CTL1 |= UCSSEL_2;                     // SMCLK -> 2MHz
  UCB1BR0 = 0x02;                           // /10=200kHz = ADC-SampleRate
  UCB1BR1 = 0;                              //
  UCB1CTL1 &= ~UCSWRST;                     // **Initialize USCI state machine**
  UCB1IE |= UCRXIE;                         // Enable USCI_A0 RX interrupt
}

Das hier sendet einen 16 bit-Wert, wenn du MISO und MOSI miteinander 
verbindest solltest du gerade das wieder zurückbekommen, was du gesendet 
hast:

void SPI_Send_Command (unsigned int MST_Data)
{
  P3OUT &= ~BIT6;               // cs low
  while (!(UCB1IFG & UCTXIFG));
  UCB1TXBUF = (MST_Data >> 8);              // Transmit first character
  while (!(UCB1IFG & UCTXIFG));             // USCI_B0 TX buffer ready?
  UCB1TXBUF = (MST_Data & 0xff);
    while ((UCB1STAT & UCBUSY)); 
  P3OUT |= BIT6;              //CS high
}

[Dennis (Gast)]

Andreas schrieb:
> Hat das noch keiner gemacht mit dem MSP430?
> Ist doch normale Vorgehensweise, den CS auf LOW etc.

Doch, das macht wohl jeder so!

Mach es in etwa so, wie "nicht_eingeloggt (Gast)" geschrieben hat, dann 
klappt das schon. Ein paar Sachen sind hier jedoch falsch!

Auf jeden Fall immer bevor du etwas an den USCI-Registern änderst, 
solltest du das Software-Reset-Bit setzen und danach wieder löschen.

Was du auch nicht machen solltest, ist das enablen der Interrupts ohne 
sie danach zu verwenden, oder zumindest einen Handler dafür zu 
erstellen.

nicht_eingeloggt schrieb:
> while ((UCB1STAT & UCBUSY));
>   P3OUT |= BIT6;              //CS high

Das hier klappt meistens, aber bei höheren Baudraten nicht immer.
Besser ist es, das RXIFG abzufragen:

...
UCB1IFG &= ~UCRXIFG
...sende letztes Byte
while (!(UCB1IFG & UCRXIFG)) {}
CS high

Noch besser wäre es natürlich wenn du die Interrupts nutzt und keine 
while-Schleifen drin hast, die bremsen halt alles.

[Andreas (Gast)]

Was bedeutet ...
(UCB1IFG & UCTXIFG)
... Diese Register gibt es nicht!?

[nicht_eingeloggt (Gast)]

Eigentlich ist das mehr oder weniger aus einer Application-Note von TI 
übernommen.

Dennis schrieb:
> Auf jeden Fall immer bevor du etwas an den USCI-Registern änderst,
> solltest du das Software-Reset-Bit setzen und danach wieder löschen.

Soweit ich das in Erinnerung habe, langt es mit UCB1CTL1 &= ~UCSWRST; 
nach der Konfiguration die Statemachine neu zu initialsieren.

Dennis schrieb:
> Das hier klappt meistens, aber bei höheren Baudraten nicht immer.
> Besser ist es, das RXIFG abzufragen:

> ...
> UCB1IFG &= ~UCRXIFG
> ...sende letztes Byte
> while (!(UCB1IFG & UCRXIFG)) {}
> CS high

hat bei mir immer so geklappt, aber wär mal n Versuch wert.

[nicht_eingeloggt (Gast)]

Andreas schrieb:
> Was bedeutet ...
> (UCB1IFG & UCTXIFG)
> ... Diese Register gibt es nicht!?

Naja, es ist halt für einen anderen Controller. Ich schrieb ja, dass das 
im Prinzip immer gleich ist, aber es kann schon sein, dass dieses 
Register bei deinem Controller anders heisst.

BTW: Hast du mal auf der TI-Seite geguckt, die haben eigentlich immer 
ganz brauchbare Codebeispiele zu den einzelnen Controllern / Familien

[nicht_eingeloggt (Gast)]

nicht_eingeloggt schrieb:
> BTW: Hast du mal auf der TI-Seite geguckt, die haben eigentlich immer
> ganz brauchbare Codebeispiele zu den einzelnen Controllern / Familien

Zum Beispiel hier:
http://www.ti.com/litv/zip/slac118d

[Dennis (Gast)]

Andreas schrieb:
> ... Diese Register gibt es nicht!?

Das stimmt natürlich, es heisst

 UC1IFG & UCB1TXIFG

nicht_eingeloggt schrieb:
> Soweit ich das in Erinnerung habe, langt es mit UCB1CTL1 &= ~UCSWRST;
> nach der Konfiguration die Statemachine neu zu initialsieren.

Ja klappt meistens auch, das stimmt, aber siehe Bild - lieber auf Nummer 
sicher :-)

nicht_eingeloggt schrieb:
> hat bei mir immer so geklappt, aber wär mal n Versuch wert.

Ich weiß nicht genau, woran es liegt, aber ich habe mich mal Ewigkeiten 
mit genau dem Scheiss herumgeschlagen, weil ich aufs Busy-Register 
gewarte hab, aber immer ging CS zu früh hoch. Mit RXIFG klappt es immer.

Am besten ist aber klar immer die Interrupt-Lösung...manchmal natürlich 
oversized.

[Andreas (Gast)]

Hallo,

danke für die Hilfe.
Habe jetzt meinen MSP wie oben beschrieben initalisiert.
Sende jetzt z.B. 0x20.
Habe aber ein Problem mit dem MISO-Eingang.
Habe mal ein Oszi-Bild angehängt. Alle Leitungen sind nicht an ein 
Bauteil angeschlossen, also SPI-Schnittstelle ist offen.
Blau ist CLK, Rosa ist SIMO, Grün ist SOMI und Gelb ist CS.
Warum habe ich auf SOMI so ein gezappel. Schaut irgendwie nach 
einkopplungen durch den CLK aus?
Vielen Dank im voraus!

Gruß
Andreas

[Rufus Τ. F. (rufus)]

Andreas schrieb:
> Blau ist CLK, Rosa ist SIMO, Grün ist SOMI und Gelb ist CS.

Es wäre hilfreich, wenn Du zusätzlich noch die Eingangsnummern erwähnst, 
denn das angehängte Bild enthält zwei der genannten Farben nicht.

1 ist blau
2 ist türkis (oder meinetwegen "Hellblau")
3 ist violett (oder meinetwegen "Lila")
4 ist grün

[Andreas (Gast)]

oh sorry.

türkis (2) ist CLK, lila (3) ist SIMO, Grün (4) ist SOMI und blau(1) ist 
CS.
Durch das Abspeichern haben sich die Farben verändert...
Hat jemand einen Plan?

[Andreas (Gast)]

hat sich erledigt, danke