STM32 SPI im IRQ

[Michael (Gast)]

Es war soweit, ich wollte auch mmal mit einem LED-Cube spielen. Also 
gegriffen was noch rumlag, 512LEDs, 5 MCP23S17, ein STM32F303 und ne 
Handvoll Hühnerfutter. Nach 'nem Wochenende Löten ging es an die 
Programmierung.

Die Ansteuerung der LEDs funktioniert, ein kompletter Durchlauf braucht 
650µs.

Um ein stabiles Bild zu haben, wollte ich den Anzeige in einen 
Timerinterrupt legen und da häge ich jetzt.
Der Interrupt funktioniert, zum Testen alle 10ms

void Timer3_Config(void)
{
    TIM_TimeBaseInitTypeDef TIM_TimeBase_InitStructure;
    NVIC_InitTypeDef NVIC_InitStructure;

    RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM3, ENABLE);

    TIM_TimeBase_InitStructure.TIM_ClockDivision = TIM_CKD_DIV1;
    TIM_TimeBase_InitStructure.TIM_CounterMode = TIM_CounterMode_Up;
    TIM_TimeBase_InitStructure.TIM_Period = 100;
    TIM_TimeBase_InitStructure.TIM_Prescaler = 6400;
    TIM_TimeBaseInit(TIM3, &TIM_TimeBase_InitStructure);

    TIM_ITConfig(TIM3, TIM_IT_Update, ENABLE);

    NVIC_InitStructure.NVIC_IRQChannel = TIM3_IRQn;
    NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
    NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0x0F;
    NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0x0F;
    NVIC_Init(&NVIC_InitStructure);

    TIM_Cmd(TIM3, ENABLE);
}

void TIM3_IRQHandler(void)
{
  TIM_ClearITPendingBit(TIM3, TIM_IT_Update);

GPIOB->ODR  ^= GPIO_Pin_3;  // PB3 togglen


}

Sobald ich jetzt im IRQ den SPI-Bus ansprechen will, bleibt jede Abfrage

  while (!(SPI1->SR & SPI_SR_TXE)); // Wait while transmit buffer is not empty

oder

  while ((SPI1->SR & SPI_SR_BSY)); // Wait while busy

hängen.

Wenn ich das ganze in den Systick verlagere funktioniert es, sobald ich 
länger als 22ms zwischen den Aufrufen warte.
Auch wenn ich den Bildaufbau spaltenweise mache (Dauer etwa 85µs) geht 
es nicht schneller.

Da mich der F3 schon bei ILI9341-Displays geärgert hat, hab ich den mal 
durch einen F103 ersetzt. Hat aber am Verhalten nichts geändert.

Kann mir jemand sagen, was ich übersehe?

[aSma>> (Gast)]

Michael schrieb:
> Da mich der F3 schon bei ILI9341-Displays geärgert hat, hab ich den mal
> durch einen F103 ersetzt. Hat aber am Verhalten nichts geändert.
>
> Kann mir jemand sagen, was ich übersehe?

Häng mal den ganzen Code dran.

Versuche deine Strategie zu überdenken und benutze DMA.

[Patrick J. (ho-bit-hun-ter)]

Hi

Benötige SPI Interrupts?
Dann könnte hier der Fall sein, da Du bereits in einer ISR bist, daß 
keine weiteren Interrupts gerade zugelassen sind und Dein Kommando 
wartet (vergeblich) auf die Interrupt-Antwort der ISP-Routine.

Reiner Hüftschuß

MfG

[Jim M. (turboj)]

Michael schrieb:
> Sobald ich jetzt im IRQ den SPI-Bus ansprechen will, bleibt jede Abfrage
> while (!(SPI1->SR & SPI_SR_TXE)); // Wait while transmit buffer is not
> empty
> oder  while ((SPI1->SR & SPI_SR_BSY)); // Wait while busy
> hängen.

Relativ blöde Idee im Interrupt zu warten, auch auf 'nem STM32. Im SPI 
Interrupt ist das Peripherial in einem bekannten Zustand - da brauchts 
keine Wartezeiten.

Schnelles SPI für'n Cube würde ich lieber mit DMA machen.

[Michael (Gast)]

Patrick J. schrieb:
> Benötige SPI Interrupts?
Nein, die Daten werden ins Register geschoben, den Rest macht die 
Hardware.

Jim M. schrieb:
> Relativ blöde Idee im Interrupt zu warten, auch auf 'nem STM32. Im SPI
> Interrupt ist das Peripherial in einem bekannten Zustand - da brauchts
> keine Wartezeiten.
Naja, ich kann schlecht neue Daten nachschieben, bevor die alten raus 
sind.
Außerdem liegen die Abstände der IRQ deulich über der Laufzeit, selbst 
mit den Warterunden.

Ich hab jetzt auf DMA umgestellt, ich dachte das sei für die paar Bytes 
alle paar ms nicht nötig.
Mich hätte nur interessiert, warum es im Timer 3 nicht klappt und im 
Systick nur mit langen Pausen.
Aber egal, jetzt geht es an die Effekte.