SPI Interrupt oder Polling

[Lars (Gast)]

Hi,

ich möchte via SPI große Arrays übertragen, so dass ich überlege 
inwiefern eine interrupt-gesteuerte Datenübertragung Sinn macht. Der DMA 
Support wird für das SPI nicht unterstützt. Als Controller verwende ich 
den LPC1758.

In meinem Interrupt lese ich das Statusregister, cleare das 
Interruptregister und schreibe das nächste Byte in das SPDR Register, 
welches anschließend übertragen werden soll. Der Datentransfer 
funktioniert.

static unsigned char buffer[512]; 

void SPI_IRQHandler(void)
{
  unsigned int state = LPC_SPI->SPSR; 
  switch(state)
  {
  case SPISTATE_SPIF:
    if(pos < 512)
        LPC_SPI->SPDR = buffer[pos++]; 
    else
    {  //Datenübertragung beenden 
       LPC_SPI->SPDR;  //read dummy 
       SPI_SetCS(HIGH); 
    }
    break;
  }
  LPC_SPI->SPINT = SPIINT_SPIF; 
}

Aber macht das überhaupt wirklich Sinn, die Datenübertragung 
interrupt-basierend zu gestalten, weil der zeitliche Abstand zwischen 
dem Beenden des SPI-Interrupts und einem neuen SPI-Interrupt ist so 
kurz, dass mein Timer Interrupt beispielsweise in dieser Zeit gar nicht 
ausgelöst wird. Erst wenn der SPI Datentransfer beendet ist, 
funktioniert der Timer (Intervall: 1ms) wieder ordnungsgemäß.

Des Weiteren kann ich während der SPI Übertragungszeit auch keine andere 
Datenübertragung die interrupt-basierend erfolgt wie z.B. I2C anstoßen, 
weil sich die Interrupts von SPI und I2C sonst in die Querre kommen. Ich 
erhalte in einem solchen Fall beispielsweise zwar die richtige Anzahl an 
ausstehenden I2C Receive Interrupts, die allerdings verzögert statt 
finden. Die erhaltenen I2C Daten werden allerdings überschrieben, weil 
das I2C-Datenregister nur ein Byte aufnehmen kann. Die restlichen 
erhaltenen Bytes sind demnach 0xFF....

Ab welchem Zeitpunkt denkt ihr darüber nach, einen Datenübertragung 
interrupt-basierend zu machen? Und wie stellt ihr sicher, dass andere 
Schnittstellen in dieser Zeit nicht mittels Interrupts angesprochen 
werden?

Gruß
Lars

[hmm... (Gast)]

Macht in meinen Augen nur Sinn wenn der Controller wesentlich schneller 
als die SPI betrieben wird. Ansonsten ist schlicht zu wenig Zeit 
zwischen zwei Interrupts in der man was anderes Sinnvolles tun kann. 
Sicher kann man durch geschicktes Priorisieren auch ander Interrupts 
noch abarbeiten,das verzögert aber den SPI Transfer zusätzlich. Macht 
also meistens keinen Sinn.

Und wenn man z.B. ein LCD möglichst schnell beschreiben will dürfte der 
Overhead um in den Interrupt zu springen mehr Relax generieren als wenn 
man auf ein Flag pollt.

Ab einem CPU Takt vom mindestens zehnfachen SPI Clock kann man drüber 
nachdenken.Besser wäre eine DMA sofern verfügbar und zwischendrin nicht 
am nCS gewackelt werden muss.

[Lars (Gast)]

hmm... schrieb:
> Ab einem CPU Takt vom mindestens zehnfachen SPI Clock kann man drüber
> nachdenken.Besser wäre eine DMA sofern verfügbar und zwischendrin nicht
> am nCS gewackelt werden muss.

ja ich glaub werd auch erstmal wieder Abstand vom Interrupt beim SPI 
nehmen. Prozessor läuft zwar auf 100MHz und die SPI mit 10MHz, aber 
Polling scheint hier doch sinnvoller zu sein

[Rudolph (Gast)]

Hmm, 10MHz SPI Takt und 100MHz CPU-Takt sind doch mindestens 80 
Taktzyklen die der Kern macht während der SPI-Transfer läuft.
Und dann kann man auch noch die Datenbreite hochsetzen.

Wenn da zwischen zwei SPI-Transfers nichts anderes passiert würde ich 
mal vermuten, dass da was falsch läuft.
Wie z.B. das der Interrupt nicht wieder freigegeben wird.

[Lars (Gast)]

Rudolph schrieb:
> Und dann kann man auch noch die Datenbreite hochsetzen.

das ist richtig, man könnte bis zu 16 Bits übertragen.

Rudolph schrieb:
> Wenn da zwischen zwei SPI-Transfers nichts anderes passiert würde ich
> mal vermuten, dass da was falsch läuft.
> Wie z.B. das der Interrupt nicht wieder freigegeben wird.

eigentlich ist das alles sehr übersichtlich bei diesem Prozessor was die 
Register angeht. Bekomme auch keine Fehler im STatusregister angezeigt.

[Jim M. (turboj)]

Lars schrieb:
> Der DMA Support wird für das SPI nicht unterstützt.

Dafür nimmt man besser die SSP Schnittstelle, die einen FIFO hat und DMA 
kennt. Eine davon liegt übrigens auf denselben Pins wie SPI, siehe auch 
UM10360.pdf, Kapitel 17.1.

Wegen dem FIFO muss man bei SSP allerdings das Datenregister immer lesen 
und schreiben.

Noch was:

LPC_SPI->SPINT = SPIINT_SPIF;

Das Rücksetzen des Interrup Flags darf nicht die letzte Anweisung in der 
Handler Function sein. Das funktioniert nicht, sobald der Compiler das 
optimiert. Hintergrund ist das Zusammenspiel von Write Buffer (1 Takt 
Verzögerung beim Schreiben) und Tail-Chaining - das dafür sorgt, das der 
Handler erneut aufgerufen würde.

Workaround: Zeile weiter nach oben schieben (vor das switch) oder

 NVIC_ClearPendingIRQ(SPI_IRQn);

als letzte Zeile einfügen.


Apropos switch: Dein switch(state) ist ungünstig, wenn mehrere Flags 
gesetzt werden. Das sollte besser ein

if( state & SPISTATE_SPIF )

sein.