mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MSP430 - ^CS von EEPROM zu früh deaktiviert - UCB0STAT-Funktion?


Autor: Herold (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Herold (Gast)
Datum:

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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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; 

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Herold (Gast)
Datum:

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

Danke schonmal!

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Herold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Herold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Herold (Gast)
Datum:

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

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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Herold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

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

Wie lange denn ?

Autor: Herold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mach gleich mal n Bild vom Oszi.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ???

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.