MSP430 SPI Schnittstelle Pegel

Das habe ich mir auch schon gedacht, aber ich habe bereits alle 
Varianten ausprobiert und es ist immer dasselbe. Es ändert sich nix :o(

Das ist korrekt, also an P2.0 hängt der Max und an 2.1 der 74HCT244. 
Diesen benutze ich als Level Shifter, da der MAX 5V Level benötigt. dort 
ziehe ich den Enable Pin auf Low. Zuerst wird also bei einer Übertragung 
der 74HCT244 aktiviert, dann warte ich kurz und aktiviere den MAX.

Habe eben nur eine Sonde, darum kann ich das nicht messen wann genau der 
Puls kommt, aber wie gesagt, habe alle Varianten immer wieder 
durchprobiert.

Ein Kollege im anderen Thread meinte, der MAX sei sehr empfindlich und 
ein Layout wie ich es hätte, Lochrasterplatine würde niemals laufen. Was 
meinst Du. Habe eben nur den SMD Typ bekommen und musste ihm mit Wrap 
Drahten anschliessen. Habe aber schon sehr viele Schaltungen so 
aufgebaut und hatte noch nie Probleme

Gruss

Hab gerade gelesen der soll enorm empfindlich auf Störungen der Speisung 
reagieren. Werde mir wohl einen Adapter fräsen müssen

Gruss und merci für die Hilfe

reflection

Hallo zusammen

Ich bin ein Stück weiter gekommen. Konnte endlich eine zweite Sonde für 
den KO holen und siehe da, folgendes:

Der CLK und die Daten kommen sauber am MAX an, habe ich mit zwei Sonden 
gemessen und die Daten stimmen mit dem gesendeten, der CLK ist so 
gelegt, wie im Datenblatt des MAX beschrieben.

Das Problem ist der CS. Dieser macht was er will! Der CS müsste LOW sein 
während der ganzen 16CLK Pulse eines Befehls. Der CS ist auch meist LOW, 
aber irgendwo im CLK stream geht er auf HIGH und kurz danach wieder auf 
LOW. Er ist alles in allem gesehen viel zu lang LOW, vor allem wenn auch 
die Senderoutine bereits abgeschlossen ist. Im Code den angehängt habe 
sieht man, wie ich es mache, zuerst CS auf LOW, dann Daten senden und 
dann CS auf High. Er macht alles andere, einfach invertiert ist es auch 
nicht. Der Pin zieht völlig asynchron zu den Daten auf LOW mit einer 
völlig anderen Zeit als er sollte.

Dachte ich mir, OK, vielleicht ist ja der Port im Eimer oder so. Habe 
also genau gleich wie ich hier Port2 für den CS einsetzte, Port4 
mitlaufen lassen. Sie sehen absolut identisch aus, also Port2 macht 
denselben Mist wie Port4

Wäre echt toll wenn mir jemand helfen könnte und den Code kurz 
durchschauen.

Gruss reflection

PS: Der CS des MAX ist auf P2.0, der des 74HC244 auf P2.1
Port2 ist folgendermassen initialisiert:

P2SEL &= 0x00;
P2DIR = 0x03;

KO ->  K atodenstrahl O szilloskop

Kommt aus der Zeit als die Dinger noch Röhren hatten und nicht WinXPs..

Felix

Ich würde extern auf die positive Flanke des LOAD Signals triggern und 
mir dann das SCLOCK-Signal und das DIN-Signal gleichzeitig anschauen.
Wichtig dabei ist, dass am Ende der Datenübertragung (DIN) das 
SCLOCK-Signal mit einer steigenden Flanke endet. Sollte nach 16 
High-Flanken des SCLOCK-Signals, SCLOCK nochmals auf High gehen, bevor 
LOAD wieder auf High ist, verliert der 72xx die Data.

Gruß
Udo

Dein Problem ist das hier:

1

void SPI0WaitForComplete(void)       // Warten bis Sende / Empfangs Buffer frei

2

{

3

  while (!(IFG1 & UTXIFG0));             // USART0 TX buffer ready?

4

  do

5

  {

6

    IFG1 &= ~URXIFG0;

7

  }

8

  while (URXIFG0 & IFG1); 

9

}

Zuerst sendest Du die Adresse (op).
In do-while setzt Du URXIFG0 zurück. Wenn dann die while-Bedingung 
abgefragt wird, ist die Datenübertragung noch nicht fertig und Du 
springst aus der Schleife raus, weil URXIFG0 immer noch null ist.
Danach wird das zweite Byte (val) in den TXBUF0 gelegt und gesendet. Das 
do-while-Problem wiederholt sich, Du springst zu früh aus der Schleife 
und setzt CS auf High, obwohl das zweite Byte noch gar nicht komplett 
übertragen wurde!

Ausserdem überprüft man UTXIFG0 bevor man Daten in TXBUF0 legt und 
nicht hinterher, das ist aber hier nicht das Problem!

Hallo zusammen

Danke für die Antworten. Das mit dem SPI prüfen ob gesendet habe ich 
jetzt schon in so vielen Variationen gesehen und mir wurde bestätigt, 
das der Code so korrekt ist. Kann mir in diesem Falle mal jemand sagen 
wie ich das dann absolut korrekt abfrage? Hatte mal selber was 
geschrieben und das lief auch, aber es sagte jemand das das nur Glück 
sei. (dieses im Code verwendete SPIWaitforComplete stammt von jemandem 
aus dem Forum) .

Wäre toll wenn ihr mir weiterhelfen könntet. Achja, habe es jetzt soweit 
am laufen, dass wenn ich jeweils nach dem LOW ziehen, resp. vor dem High 
setzen des CS ein 50uS Delay einbaue und siehe da es lauft. Würde mich 
aber schon noch interessieren wie ich es korrekt machen muss, will ja 
was lernen :o)

Gruss reflection

KO: Kathodenstrahl Oszilloskop :o) Sorry, komme aus der CH, da ist das 
ein gängiger Ausdruck, kennt man das in D nicht?

Jaja, die Deutsch-Schweizer Unterschiede :o) Fängt ja schon bei Natel 
und Handy an :o)

>dieses im Code verwendete SPIWaitforComplete
>stammt von jemandem aus dem Forum
Ja, ich weiß... und der hat's wiederum von TI... und die sind auch nicht 
gerade bekannt für fehlerfreie Beispielcodes ;-)

>Würde mich aber schon noch interessieren wie ich es korrekt machen muss
Z.B. so:

1

void spiSendByte(char op, char val)

2

{

3

  char   dummy;

4

5

  P2OUT &= 0xFC;                   // CS low

6

7

  while (!(IFG1 & UTXIFG0));       // USART0 TX frei?

8

  TXBUF0 = op;                     // Sende Adresse

9

  while (!(IFG1 & URXIFG0));       // Datenübertragung komplett? 

10

  dummy = RXBUF0;                  // RX-Buf lesen -> URXIFG0 wird gelöscht

11

12

  while (!(IFG1 & UTXIFG0));       // USART0 TX frei?

13

  TXBUF0 = val;                    // Sende Daten

14

  while (!(IFG1 & URXIFG0));       // Datenübertragung komplett?

15

  dummy = RXBUF0;                  // RX-Buf lesen -> URXIFG0 wird gelöscht

16

17

  P2OUT |= 0x01;                   // CS high

18

}

Zuvor (z.B. in der Init) würde ich sicherheitshalber URXIFG0 einmalig 
löschen, also z.B. auch ein Dummy-Read auf RXBUF0 anwenden.