MSP430 SPI-Schnittstelle

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.

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.

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

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

1

void SpiUcb1Init (void)            

2

{

3

  P3OUT |= BIT6;              //cs high

4

  P3DIR |= BIT6;              // P3.6 output (CS)

5

  P3SEL |= 0x80;                            // P3.7 option select

6

  P5SEL |= 0x30;              //P5.4,5 option select

7

  UCB1CTL0 |= UCMST+UCSYNC+UCMSB;        //3-pin, 8-bit SPI master, MSB first

8

  UCB1CTL1 |= UCSSEL_2;                     // SMCLK -> 2MHz

9

  UCB1BR0 = 0x02;                           // /10=200kHz = ADC-SampleRate

10

  UCB1BR1 = 0;                              //

11

  UCB1CTL1 &= ~UCSWRST;                     // **Initialize USCI state machine**

12

  UCB1IE |= UCRXIE;                         // Enable USCI_A0 RX interrupt

13

}

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:

1

void SPI_Send_Command (unsigned int MST_Data)

2

{

3

  P3OUT &= ~BIT6;               // cs low

4

  while (!(UCB1IFG & UCTXIFG));

5

  UCB1TXBUF = (MST_Data >> 8);              // Transmit first character

6

  while (!(UCB1IFG & UCTXIFG));             // USCI_B0 TX buffer ready?

7

  UCB1TXBUF = (MST_Data & 0xff);

8

    while ((UCB1STAT & UCBUSY)); 

9

  P3OUT |= BIT6;              //CS high

10

}

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:

1

...

2

UCB1IFG &= ~UCRXIFG

3

...sende letztes Byte

4

while (!(UCB1IFG & UCRXIFG)) {}

5

CS high

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

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

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.

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 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

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

Das stimmt natürlich, es heisst

1

 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.

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

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?

hat sich erledigt, danke