[STM32F4xx] SPI Optimierung

Gast #4841426
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?
Angehängte Dateien:
#4841447
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.
Gast #4841468
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!
Angehängte Dateien:
Gast #4842582
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

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren