Forum: Mikrocontroller und Digitale Elektronik [STM32F4xx] SPI Optimierung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von STM_Apprentice (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
1
void Funktion1 (uint16_t val)
2
{
3
  PC0_low;  /*  soft chip select  */
4
5
  /*  wait for TX empty  */
6
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
7
  SPI1->DR = (uint8_t)(val >> 8);
8
9
  /*  wait for TX empty  */
10
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
11
  SPI1->DR = (uint8_t)(val);
12
13
  PC0_high;  /*  soft chip select  */
14
}
15
16
17
void Funktion2 (uint16_t val)
18
{
19
  uint8_t  rd_val;
20
21
  PC0_low;  /*  soft chip select  */
22
23
  /*  wait for TX empty  */
24
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
25
  SPI1->DR = (uint8_t)(val >> 8);
26
27
  /*  wait for RX not empty  */
28
  while ((SPI1->SR & SPI_I2S_FLAG_RXNE) == 0);
29
  rd_val = SPI1->DR;
30
31
  /*  wait for TX empty  */
32
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
33
  SPI1->DR = (uint8_t)(val);
34
35
  /*  wait for RX not empty  */
36
  while ((SPI1->SR & SPI_I2S_FLAG_RXNE) == 0);
37
  rd_val = SPI1->DR;
38
39
  PC0_high;  /*  soft chip select  */
40
}


Bei der Implementierung meiner SPI-Ansteuerung auf dem STM32F407
ist mir der folgende Sachverhalt aufgefallen:

(Bild1 gehört zu Funktion1.c
 Bild2 gehört zu Funktion2.c)

Ich möchte ein oder mehrere Bytes in einer Funkton übertragen.
Stellvertretend zeige ich dies hier für zwei Bytes. Das ganze
soll möglichst schnell gehen, daher kommt erst das Problem auf.
Ja ich weiss dass die SPI-Maschine auch 16 Bit kann, aber es
sollen ja mehr oder weniger sein können.

In Bild 1 ist zu sehen dass der soft-generierte (Port I/O) Chip
Select früher weggeht als die SPI-Maschine fertig ist. Und das
obwohl die Funktion korrekt das Transmit-Flag abwartet. Die 16
Bits kommen dicht aufeinander so wie man sich das für optimale
Geschwindigkeit wünscht. Der Chip Select ist jedoch für einen
Slave ungeeignet da er seinen Datenstrom abgeschnitten bekommt.

Um das zu vermeiden muss ich (siehe Bild 2 und Funktion2.c)
zusätzlich das SPI Datenregister lesen um die (parallel zum
Senden) empfangenen Daten zu "entleeren". Erst das "RX not
empty" Flag garantiert dass ich in der Funktion weiss wann die
SPI-Maschine fertig ist, und der Chip Select kommt dann für
den Slave zeitlich korrekt.

Die Erklärung dafür habe ich. Einfache Frage: gibt es eine
Möglichkeit das "zeitraubende" Dummy-Lesen des SPI-
Datenregisters zu vermeiden? Immerhin gehen in dem Spalt
zwischen zwei Bytes 250usec drauf. Die bleiben ja konstant bzw
fallen immer noch stark ins Gewicht wenn ich die Datenrate
höher wähle (jetzt 10MBit/s), der Prozessor kann ja nicht
schneller, nur die SPI-Maschine wird schneller arbeiten.
Nochmals anders herum gefragt: wie könnte ich feststellen
dass alleine der Transmit Vorgang abgeschlossen ist?

von STM_Apprentice (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Das nachträgliche Warten nach dem Senden auf das Transmit empty
Flag hilft nicht da es auch sehr früh kommt (offensichtlich
gepuffertes Handling).

von STM_Apprentice (Gast)


Bewertung
0 lesenswert
nicht lesenswert
STM_Apprentice schrieb:
> Immerhin gehen in dem Spalt
> zwischen zwei Bytes 250usec drauf.

Nein, natürlich sind es "nur" 250nsec, eine viertel Mikrosekunde.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
STM_Apprentice schrieb:
> In Bild 1 ist zu sehen dass der soft-generierte (Port I/O) Chip
> Select früher weggeht als die SPI-Maschine fertig ist. Und das
> obwohl die Funktion korrekt das Transmit-Flag abwartet.

Nö, sie wartet nicht korrekt. Das 2. Byte wird eigeschrieben, und 
unmittelbar danach sofort CS High gesetzt.
Außerdem wartet die Funktion nur auf TX Empty, der mit FIFO sofort 
wieder gesetzt wird.

STM_Apprentice schrieb:
> Immerhin gehen in dem Spalt
> zwischen zwei Bytes 250usec drauf.

Ich sehe da 250 ns, also Faktor 1000 weniger. Und die bekommt man weg 
wenn man sich eine Mischung aus 1 und 2 ausdenkt - erst 2x senden, dann 
BUSY abwarten und zum Schluss das DR Register mehrmals lesen.

von STM_Apprentice (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Ich sehe da 250 ns, also Faktor 1000 weniger.

STM_Apprentice schrieb:
> Nein, natürlich sind es "nur" 250nsec, eine viertel Mikrosekunde.

von STM_Apprentice (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Das 2. Byte wird eigeschrieben, und
> unmittelbar danach sofort CS High gesetzt.

STM_Apprentice schrieb:
> Nachtrag:
>
> Das nachträgliche Warten nach dem Senden auf das Transmit empty
> Flag hilft nicht da es auch sehr früh kommt (offensichtlich
> gepuffertes Handling).

von STM_Apprentice (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> und zum Schluss das DR Register mehrmals lesen.

Das setzt voraus dass das Rx Register beliebig viele
Pufferstufen hat. Geht wohl nich ....

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was ist mit:

SPI_FLAG_BSY

http://stm32info.com/en/spi-status-flags/

von STM_Apprentice (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hp-freund schrieb:
> Was ist mit:
>
> SPI_FLAG_BSY

Hab ich bis jetzt übersehen.

Danke, das teste ich gleich aus ....

von STM_Apprentice (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
hp-freund schrieb:
> Was ist mit:
>
> SPI_FLAG_BSY
>
1
void SPI1_Write16 (uint16_t val)
2
{
3
  uint8_t  rd_val;
4
5
  PC0_low;  /*  soft chip select  */
6
7
  /*  wait for TX empty  */
8
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
9
  SPI1->DR = (uint8_t)(val >> 8);
10
11
  /*  wait for TX empty  */
12
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
13
  SPI1->DR = (uint8_t)(val);
14
15
  /*  wait for Busy flag not active  */
16
  while ((SPI1->SR & SPI_I2S_FLAG_BSY) != 0);
17
18
  PC0_high;  /*  soft chip select  */
19
}


Ein Wort: funktioniert!

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
Aufpassen sollte man jedoch, dass das BSY Bit ausschließlich im Master 
Mode verlässlich abgefragt werden kann. Im Slave Mode hat ST da seit 
Jahren einen bösen Bug drin, bei dem BSY auch mal High bleiben kann...

Das tut bei einer Endlosschleife natürlich weh.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
STM_Apprentice schrieb:
> Jim M. schrieb:
>> und zum Schluss das DR Register mehrmals lesen.
>
> Das setzt voraus dass das Rx Register beliebig viele
> Pufferstufen hat. Geht wohl nich ....

Er schmeisst die gelesenen Werte weg. Dann muss ich nur den RX Fifo 
leeren, damit kein alter Müll in einer nachfolgenden Transaktion gelesen 
wird.

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Das tut bei einer Endlosschleife natürlich weh.

Wer sowas macht hat es auch nicht besser verdient. Bei mir kommt da 
immer noch ein Downcounter mit rein und wenn der auf Null ist dann gibt 
die Funktion einen Fehler zurueck.

Olaf

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]
  • [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.