Gast
#4841426
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
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?


