[STM32F4xx] SPI Optimierung

[STM_Apprentice (Gast)]

void Funktion1 (uint16_t val)
{
  PC0_low;  /*  soft chip select  */

  /*  wait for TX empty  */
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
  SPI1->DR = (uint8_t)(val >> 8);

  /*  wait for TX empty  */
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
  SPI1->DR = (uint8_t)(val);

  PC0_high;  /*  soft chip select  */
}


void Funktion2 (uint16_t val)
{
  uint8_t  rd_val;

  PC0_low;  /*  soft chip select  */

  /*  wait for TX empty  */
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
  SPI1->DR = (uint8_t)(val >> 8);

  /*  wait for RX not empty  */
  while ((SPI1->SR & SPI_I2S_FLAG_RXNE) == 0);
  rd_val = SPI1->DR;

  /*  wait for TX empty  */
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
  SPI1->DR = (uint8_t)(val);

  /*  wait for RX not empty  */
  while ((SPI1->SR & SPI_I2S_FLAG_RXNE) == 0);
  rd_val = SPI1->DR;

  PC0_high;  /*  soft chip select  */
}

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?

[STM_Apprentice (Gast)]

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

[STM_Apprentice (Gast)]

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

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

[Jim M. (turboj)]

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.

[STM_Apprentice (Gast)]

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.

[STM_Apprentice (Gast)]

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

[STM_Apprentice (Gast)]

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

[hp-freund (Gast)]

Was ist mit:

SPI_FLAG_BSY

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

[STM_Apprentice (Gast)]

hp-freund schrieb:
> Was ist mit:
>
> SPI_FLAG_BSY

Hab ich bis jetzt übersehen.

Danke, das teste ich gleich aus ....

[STM_Apprentice (Gast)]

hp-freund schrieb:
> Was ist mit:
>
> SPI_FLAG_BSY
>

void SPI1_Write16 (uint16_t val)
{
  uint8_t  rd_val;

  PC0_low;  /*  soft chip select  */

  /*  wait for TX empty  */
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
  SPI1->DR = (uint8_t)(val >> 8);

  /*  wait for TX empty  */
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0);
  SPI1->DR = (uint8_t)(val);

  /*  wait for Busy flag not active  */
  while ((SPI1->SR & SPI_I2S_FLAG_BSY) != 0);

  PC0_high;  /*  soft chip select  */
}

Ein Wort: funktioniert!

[Vincent H. (vinci)]

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.

[Jim M. (turboj)]

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.

[Olaf (Gast)]

> 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