MSP430 - ^CS von EEPROM zu früh deaktiviert - UCB0STAT-Funktion?

[Herold (Gast)]

Morgen zusammen, ich bräuchte mal eure Hilfe mit meinem EEPROM, das ich 
beschreiben will.

Im Video ist das Timing angehängt, oben ist SCK und unten ist ^CS zu 
sehen.
Wie man erkennen kann, wird ^CS während der letzten steigenden Flanke 
bereits mit hochgezogen, der entsprechende Quelltext dazu:

while (1)
{
  EE1_SEL; 
  while (!(IFG2 & UCB0TXIFG)) {}
  UCB0TXBUF = *data;
 
  while (UCB0STAT & UCBBUSY) {}
  //delay(); // Mit Delay geht es, aber es sollte auch ohne gehen...
  EE1_DES;                              // Deselect EEPROM
}

Mit

while (UCB0STAT & UCBBUSY) {}

sollte doch eigentlich geprüft werden, ob die Übertragung fertig ist und 
erst danach ^CS wieder deaktiviert werden...dachte ich. Aber es ist 
vorzeitig schon wieder auf 'high'.

Das ist doch nicht der Sinn von UCBBUSY...


Weiß da einer Rat? Mit nem Delay geht das natürlich, aber es wäre schön, 
wenn ich keine Delays verwenden müsste.

[Herold (Gast)]

Sorry für das große Bild, hab ich zu spät gesehen.

[Stefan (Gast)]

Ob das UCBUSY-Flag bei SPI nicht verlässlich funktioniert, weiß ich 
jetzt nicht. Müsste ich erst ausprobieren. Bei UART-Kommunikation habe 
ich das so aber auch schon erfolgreich gemacht.

Bei SPI funzt bei mir das hier:

  EE1_SEL;
  IFG2 &= ~UCB0RXIFG;
  UCB0TXBUF = *data; 
  while(!(IFG2 & UCB0RXIFG));     // warten, bis Übertragung beendet
  EE1_DES;

[Frank K. (fchk)]

Herold schrieb:
> Morgen zusammen, ich bräuchte mal eure Hilfe mit meinem EEPROM, das ich
> beschreiben will.
>
> Im Video ist das Timing angehängt, oben ist SCK und unten ist ^CS zu
> sehen.
> Wie man erkennen kann, wird ^CS während der letzten steigenden Flanke
> bereits mit hochgezogen, der entsprechende Quelltext dazu:

[...]

> sollte doch eigentlich geprüft werden, ob die Übertragung fertig ist und
> erst danach ^CS wieder deaktiviert werden...dachte ich. Aber es ist
> vorzeitig schon wieder auf 'high'.

... weil da intern ein Puffer ist. Das Problem kenne ich auch.
Der Trick ist, dass bei SPI sowohl ein Sende- als auch ein 
Empfangsvorgang läuft. Wenn Du also auf UCB0RXIFG wartest und 
anschließend das empfangene Byte ausliest (auch wenn Du es nachher gar 
nicht brauchst), dann passt das alles.

char spi_sendrecv(char c)
{
  UCB0TXBUF=c;
  while(!(IFG2&UCB0RXIFG));
  return UCB0RXBUF;
}

fchk

[Stefan (Gast)]

Frank K. schrieb:
> ... weil da intern ein Puffer ist. Das Problem kenne ich auch.

Nun, das scheint dann aber -wie ich schon geschrieben habe- ein 
SPI-Problem zu sein (oder ein Derivat-Bug?), denn UCBUSY funktioniert 
bei mir in der vorgeschlagenen Art und Weise bei UART-Kommunikation ohne 
Probleme, trotz Doppel-Pufferung!

[Herold (Gast)]

Ich werde das jetzt mal an den entsprechenden Stellen einsetzen und 
gucken, ob das den gewünschten Erfolg bringt.

Danke schonmal!

[Frank K. (fchk)]

Stefan schrieb:
> Frank K. schrieb:
>> ... weil da intern ein Puffer ist. Das Problem kenne ich auch.
>
> Nun, das scheint dann aber -wie ich schon geschrieben habe- ein
> SPI-Problem zu sein (oder ein Derivat-Bug?), denn UCBUSY funktioniert
> bei mir in der vorgeschlagenen Art und Weise bei UART-Kommunikation ohne
> Probleme, trotz Doppel-Pufferung!

Beim UART musst Du ja auch nicht die Übertragung bitgenau mit einem 
GPIO-Pin synchronisieren. Da fällt es schlichtweg nicht auf.

fchk

[Herold (Gast)]

Also ich habe es jetzt mit dem Warten auf UCB0RXIFG gemacht, das 
funktioniert! Aber es wird dadurch doch erheblich langsamer, weil wenn 
man sich jetzt das Oszi-Bild anguckt, dann wird ^CS wesentlich später 
hochgezogen - dauert wohl ne Weile, bis das Flag gesetzt wird.

Naja, aber es geht...

[Herold (Gast)]

Herold schrieb:
> Im Video ist das Timing angehängt

Da seh ich jetzt erst, das ich Video geschrieben hab...naja, ich hoffe 
danach hat keiner vergeblich gesucht, ist natürlich nur ein Bild :)

[Stefan (Gast)]

Frank K. schrieb:
> Beim UART musst Du ja auch nicht die Übertragung bitgenau mit einem
> GPIO-Pin synchronisieren. Da fällt es schlichtweg nicht auf.

Zum Synchronisieren bei SPI ist der SCLK da und nicht das UCBUSY Flag!
Außerdem erledigt das die HW-USART/USCI von alleine.
Aber egal... ;-)

[Herold (Gast)]

Stefan schrieb:
> Außerdem erledigt das die HW-USART/USCI von alleine.

Und was ist dein Tip dazu? Wie machst du sowas?

[Stefan (Gast)]

Herold schrieb:
> Stefan schrieb:
>> Außerdem erledigt das die HW-USART/USCI von alleine.
> Und was ist dein Tip dazu? Wie machst du sowas?

Ich verstehe Deine Frage nicht so ganz?

Ich bezog mich oben auf die Synchronität der SPI, die nunmal durch einen 
Daten-Clock (SCLK) sichergestellt wird. Und diese Synchronität wird eben 
durch die eingebaute Hardware erledigt... da brauch man gar nix machen!

Dein Problem habe ich wie beschrieben (mittels UCB0RXIFG) gelöst.

[Herold (Gast)]

Sorry, hab die Namen der Beirtagsteller nicht nachgegeuckt, habs ja 
jetzt auch so, und es geht. Nur wundert mich echt, wie lang es dauert, 
bis das Flag gesetzt wird.

[Stefan (Gast)]

Herold schrieb:
> Nur wundert mich echt, wie lang es dauert,
> bis das Flag gesetzt wird.

Wie lange denn ?

[Herold (Gast)]

Ich mach gleich mal n Bild vom Oszi.

[Frank K. (fchk)]

Stefan schrieb:
> Frank K. schrieb:
>> Beim UART musst Du ja auch nicht die Übertragung bitgenau mit einem
>> GPIO-Pin synchronisieren. Da fällt es schlichtweg nicht auf.
>
> Zum Synchronisieren bei SPI ist der SCLK da und nicht das UCBUSY Flag!
> Außerdem erledigt das die HW-USART/USCI von alleine.

Das ja. Aber die zeitliche Beziehung zwischen der UART-Engine und den 
GPIOs ist erstmal undefiniert.

Das gleiche Problem hast Du auch bei RS485 halbduplex, wenn Du die 
Transmitter passend ein- und ausschalten musst.

fchk

[Stefan (Gast)]

Frank K. schrieb:
>> Zum Synchronisieren bei SPI ist der SCLK da und nicht das UCBUSY Flag!
>> Außerdem erledigt das die HW-USART/USCI von alleine.
>
> Das ja. Aber die zeitliche Beziehung zwischen der UART-Engine und den
> GPIOs ist erstmal undefiniert.

Ich will jetzt eigentlich nicht drauf rumreiten...
...aber was haben GPIOs mit einer UART zu tun, zumindest wenn ich kein 
HW-Handshake benutze? Und das CS z.B. beim SPI muss schlichtweg einfach 
nur aktiv gesetzt werden bevor ich anfange zu senden und muss 
nachdem ich aufgehört habe zu senden wieder deaktiviert werden. 
Synchronisiert wird da gar nix und die zeitliche Beziehung ist mir dabei 
in erster Näherung auch völlig wurscht...

[Christian R. (supachris)]

Stefan schrieb:

> HW-Handshake benutze? Und das CS z.B. beim SPI muss schlichtweg einfach
> nur aktiv gesetzt werden bevor ich anfange zu senden und muss
> nachdem ich aufgehört habe zu senden wieder deaktiviert werden.
> Synchronisiert wird da gar nix und die zeitliche Beziehung ist mir dabei
> in erster Näherung auch völlig wurscht...

Genau das ist es ja. Es ist nicht wurscht. Es muss definitiv nach dem 
Senden erst deaktiviert werden, sonst bricht der Slave alles ab. Das ist 
das Problem des TE, wenn er auf das Flag schaut, ist die Übertragung des 
Bytes aus dem Shieberegister noch nicht abgeschlossen. Da sind die 
MSP430 bissl zickig, und auch verschieden in den Modulen (USART, 
USCI...). Auf der sicheren Seite ist man, wenn man auf das RX-Flag 
wartet, denn erst wenn auch das Byte in den RX-Puffer geschrieben ist, 
ist die Übertragung garantiert abgeschlossen.

[Stefan (Gast)]

Christian R. schrieb:
> Genau das ist es ja. Es ist nicht wurscht. Es muss definitiv nach dem
> Senden erst deaktiviert werden, sonst bricht der Slave alles ab.

Das haben wir doch durch ...UCB0RXIFG... schon lange erledigt ???