Delay in ISR

[Walter T. (nicolas)]

Hallo zusammen,

gibt es eigentlich einen Grund, der gegen einen delay in einer ISR 
spricht?

void HardFault_Handler(void)
{
    // Sicheren Zustand herstellen
    GPIOA->MODER = 0;
    GPIOB->MODER = 0;
    GPIOC->MODER = 0;
    GPIOD->MODER = 0;


    setOutput(ERRORLED_GPIO, ERRORLED_Pin);

    while(1) {
        ERRORLED_GPIO->ODR ^= (uint32_t) ERRORLED_Pin;
        delay_ms(200);
    }
}

Eigentlich müßte doch beim HardFault-Handler der Drops gelutscht sein 
und mich delays nicht mehr interessieren.

Viele Grüße
W.T.

[Stefan F. (Gast)]

In diese Fall spricht nichts dagegen, finde ich.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Nö, du musst nur zusehen, das der SysTick eine noch höhere Priorität als 
der Hardfault Handler hat, sonst hängts. Nicht, das du das nicht sowieso 
wolltest, aber blinken tuts dann auch nicht.

[dummschwaetzer (Gast)]

Sicherer Zustand währe für mich Interrupts sperren, geht da deine 
delay() noch?

[Vincent H. (vinci)]

Hat der HardFault nicht eine höhere (nicht änderbare) Priorität als der 
SysTick? Falls ja, dann geht das mit Sicherheit nicht.

[Ingo L. (corrtexx)]

Bei sowas würde ich auch keine delay-Funktion nutzen, die auf andere 
ISRs angewiesen ist. Da würde ich tatsächlich mit roher CPU Gewalt 
Rechenleistung für ein delay alà:

void delay ( uint32_t Delaytime ) 
{
 while ( Delaytime ) Delaytime--;
}

verbraten. Timing is hier sowieso nur von geringerer Präzision 
notwendig.

[Peter II (Gast)]

Ingo L. schrieb:
> für ein delay alà:

und hoffen das der Compiler es nicht komplett entsorgt. Da sollte dann 
noch ein volatile oder ähnliches rein.

[Walter T. (nicolas)]

Die hier funktioniert recht zuverlässig:

    #define TUNE_FAC 1.0
            

   #define delay_us(delayval) delay_us_( \
          (uint64_t)( (SYSCLK) / 3000000ULL *delayval * TUNE_FAC) )

  #define delay_ms(delayval) delay_us_( \
          (uint64_t)( (SYSCLK) / 3000ULL *delayval * TUNE_FAC) )

  static inline void delay_us_(uint64_t delayval)
  {
        if(delayval)
            {
          asm volatile (\
                "L_LOOPUS_%=:     \n\t" \
                "subs %0, %0, #1  \n\t" \
                "bne  L_LOOPUS_%= \n\t" \
                :  "+r" (delayval) );
        }
        else
            {
          asm volatile("nop");
        }
    }

[Ingo L. (corrtexx)]

Peter II schrieb:
> und hoffen das der Compiler es nicht komplett entsorgt. Da sollte dann
> noch ein volatile oder ähnliches rein.
Kann man ja machen, wenn es nicht auf Anhieb funktioniert...

[Walter T. (nicolas)]

dummschwaetzer schrieb:
> Sicherer Zustand währe für mich Interrupts sperren,

Warum? Was sollten die ISRs noch anstellen, wenn alle Pins Eingänge 
sind?

[Jim M. (turboj)]

Peter II schrieb:
> Ingo L. schrieb:
>> für ein delay alà:
>
> und hoffen das der Compiler es nicht komplett entsorgt. Da sollte dann
> noch ein volatile oder ähnliches rein.

Und genau das sorgt bei unterschiedlichen optimierungsstufen für eine 
seeeehr variable Durchlaufzeit. Viele Leute nutzen daher eine simple 
Funktion, die eine passend berechnete Anzahl an __NOP(); für so 1us oder 
10us enthält.

Für den OP noch der Hinweis, das man solche Schleifen im Hardfault gerne 
mal mit Taste unterbrechbar haben will (um z.B. einen Reset auszulösen). 
Dann muss man die 200ms unterteilen (z.B. 1ms Schritte), sonst muss der 
Anwender die Taste lange gedrückt halten.

[Jörg W. (dl8dtl) (Moderator)]

Walter T. schrieb:
> "L_LOOPUS_%=:     \n\t" \
>                 "subs %0, %0, #1  \n\t" \
>                 "bne  L_LOOPUS_%= \n\t" \

Dafür hat der Gott der Unix-Assembler local labels erfunden:

   "1:  subs %0, %0, #1 \n\t" \
   "    bne 1b\n\t" \

[Adam P. (adamap)]

Die Funktion delay_ms() basiert doch nicht auf Interrupts und auch nicht 
auf dem System-Tick (solange es keine Eigenentwicklung ist) - oder habe 
ich da etwas überlesen?

Die Prio vom HardFault und SysTick ist einstellbar.

Ich beziehe mich jetzt auf einen Cortex-M4, denn der verwendete 
Controller wurde nicht genannt.

[Carl D. (jcw2)]

Walter T. schrieb:
> Hallo zusammen,
>
> gibt es eigentlich einen Grund, der gegen einen delay in einer ISR
> spricht?
>
>

> void HardFault_Handler(void)
> {
>     // Sicheren Zustand herstellen
>     GPIOA->MODER = 0;
>     GPIOB->MODER = 0;
>     GPIOC->MODER = 0;
>     GPIOD->MODER = 0;
> 
.
>     setOutput(ERRORLED_GPIO, ERRORLED_Pin);
> 
>     while(1) {
>         ERRORLED_GPIO->ODR ^= (uint32_t) ERRORLED_Pin;
>         delay_ms(200);
>     }
> }
>

>
> Eigentlich müßte doch beim HardFault-Handler der Drops gelutscht sein
> und mich delays nicht mehr interessieren.
>
> Viele Grüße
> W.T.

Das ist keine ISR, sondern ein Fault-Handler. Falls der nur eine 
Error-LED blinken lassen soll, warum nicht. Wenn er eine Situation 
behandelt, für die es tatsächlich eine softwaretechinsche Lösung gibt, 
dann würde man sicher kein delay() wollen. Die würde man dann aber eher 
in UsageFault/MemoryManagementFault behandeln, im HardFault ist die 
Fehlerursache gar nicht mehr ablesbar.

Hardfault ist so eine Art letztes Zucken, denn der kommt, wenn andere 
Fehlersituationen nicht oder nicht ohne neu auftretende Fehler behandelt 
werden. Da ist alles erlaubt. Zumal ein Hardfault eine kaum noch zu 
unterbietende Prio hat.

[Walter T. (nicolas)]

Jörg W. schrieb:
> Dafür hat der Gott der Unix-Assembler local labels erfunden:

Danke für den Hinweis! ARM-Assembler ist für mich eine Fremdsprache, die 
ich nie ohne Wörterbuch in der Hand anfasse.

[Adam P. (adamap)]

Adam P. schrieb:
> Die Prio vom HardFault und SysTick ist einstellbar.

Muss mich korrigieren:
HardFault hat Prio. (-1)

[Carl D. (jcw2)]

Walter T. schrieb:
> Jörg W. schrieb:
>> Dafür hat der Gott der Unix-Assembler local labels erfunden:
>
> Danke für den Hinweis! ARM-Assembler ist für mich eine Fremdsprache, die
> ich nie ohne Wörterbuch in der Hand anfasse.

Die Sprache zu verstehen wäre aber Grundvoraussetzung, um die Auswirkung 
verschiedener C-Konstrukte abschätzen zu können.
Plus so Feinheiten, daß ein Register in dem Befehl nachdem es geladen 
wurde vielleicht noch nicht verfügbar ist und man deshalb besser 2 
"C-Statement" verschränkt ausführt.

[Walter T. (nicolas)]

Jim M. schrieb:
> Für den OP noch der Hinweis, das man solche Schleifen im Hardfault gerne
> mal mit Taste unterbrechbar haben will (um z.B. einen Reset auszulösen).
> Dann muss man die 200ms unterteilen (z.B. 1ms Schritte), sonst muss der
> Anwender die Taste lange gedrückt halten.

Meine Reset-Taste benötigt immer gleich lang, egal was im Fault-Handler 
läuft.

[Jörg W. (dl8dtl) (Moderator)]

Walter T. schrieb:
> ARM-Assembler ist für mich eine Fremdsprache

Wobei die Geschichte der local labels nicht so viel mit der
Architektur zu tun hat, sondern mit der Umgebung.  Der hier verwendete
GNU Assembler hat seine historischen Wurzeln in den Unix-Assemblern,
die haben solche Labels halt seit jeher gekannt.

Die kann man im GNU Assembler dann unabhängig von der Architektur
nutzen, also sowohl auf ARM, AVR oder x86.

Andere ARM-Assembler haben dieses Feature möglicherweise nicht.