STM32 Interrupts - Welche Regeln sollte man beachten?

[Christian J. (Gast)]

Moin,

sorry..... aktuell kommen grad echt ne Menge Fragen auf, die teilweise 
nicht eindeutig zu beantworten sind durch Googlen :-)

habe mir bis gestern um 2 Uhr und heute morgen weiter mal meinen kleinen 
NMEA Parser geschrieben für den GPS RMC Satz. Mehr brauche ich nicht, 
daher auch nix aus dem Netz besorgt. Für die 4 Werte.

Das liegt derzeit alles im ISR Handler, wenn die USART das letzte Byte 
erkannt hat und danach 1s Pause ist. Bläht den Code aber mal eben so um 
5 kb auf durch die String Funktionen und 1 x float Rechnung.

Der nicht optimierte Code (-O0) braucht nach Messung mit dem DWT Counter 
3800 Zyklen für vollen Durchlauf.

Gibt es da eine Schmerzgrenze? Oder sollte man besser ein Flag setzen, 
damit das in der arbeitslosen Hauptroutine erledigt wird? Aktuell läuft 
alles über INTs, die ganze Datensammelei, das Ein/Aus der Peripherie 
usw.

Würde mich mal interessieren, wie die Profis das so machen?

/* UART1 Interrupt Service Routine */
void USART1_IRQHandler() {

    #define MAX_NMEA_FIELDS 16
    static char* nmea_fields[MAX_NMEA_FIELDS];

    /* GPS Empfang abgeschaltet? Dann alles verwerfen */
    if (fGPSRecDisable) {
        /* Buffer ungültig machen */
        fGPSDataValid = false;
        NmeaBuf_Ptr = 0;
        USART1->SR;
        USART1->DR;
        return;
    }

    /* Neues Byte wurde empfangen vom GPS Modul */
    if (USART_GetITStatus(USART1, USART_IT_RXNE) == SET)
    {
       // USART_ClearITPendingBit(USART1, USART_IT_RXNE);
       NmeaBuf[NmeaBuf_Ptr] = USART_ReceiveData(USART1);
       NmeaBuf_Ptr = (NmeaBuf_Ptr + 1) % BUFSIZE;               /* Pointer auf nächstes Byte */
       fGPSReceiveInProgress = true;
       SetLED(GELB,ENABLE);
    }

    /* Timeout, letztes Byte wurde empfangen */
    if (USART_GetITStatus(USART1, USART_IT_IDLE) == SET)
    {
       fGPSReceiveInProgress = false;

       /* FIXXXXXME Test */
       strcpy((char*)NmeaBuf,"$GNRMC,124520.00,A,5200.19391,N,00910.23188,E,30.585,231.29,180121,,,A*45");

        /* String terminieren */
        NmeaBuf[NmeaBuf_Ptr] = 0;

       /* Vorsortierung: Überprüfe die ersten Zeichen auf $GNRMC*/
       const char str1[] = "$GNRMC";
       if (strncmp((char*)NmeaBuf,str1,sizeof(str1)-1) != 0)
            fGPSDataValid = false;
       else {

           fGPSDataValid = true;

           /* String zerteilen, der durch , separiert ist */
           uint8_t i = 0;
           char* ptr = (char*)NmeaBuf;
           nmea_fields[i++] = ptr;  /* Erstes Element setzen, NMEA Typ RMC */

           /* Feld auf einzelne Teil Strings erzeugen */
           while (((ptr = strchr(ptr,',')) != NULL) && (i < MAX_NMEA_FIELDS)) {
                *ptr = '\0';
                nmea_fields[i++] = ++ptr;
           }

           char foo[4];

           /* Gültiger Fix = 1, kein Fix = 0 */
           if (strncmp((char*)nmea_fields[2],"A",1) == 0)
               gps_info.validfix = 1;
           else
               gps_info.validfix = 0;

           /* Uhrzeit extrahieren */
           char *p = (char*)nmea_fields[1];
           gps_info.utc_hour = atoi(strncpy(foo,p,2));
           p +=2;
           gps_info.min = atoi(strncpy(foo,p,2));
           p +=2;
           gps_info.sec = atoi(strncpy(foo,p,2));

           /* Geschwindigkeit extrahieren in khm */
           gps_info.speedkhm = (float)atoi((char*)nmea_fields[7]) * 1.852;
       }

       NmeaBuf_Ptr = 0; /* Reset RX Pointer */
       SetLED(GELB,DISABLE);
    }

    /* Overflow Error abfangen */
    if (USART_GetITStatus(USART1, USART_IT_ORE_RX) != RESET)
    {
        fGPSDataValid = false;
        NmeaBuf_Ptr = 0; /* Reset RX Pointer & Clear */
        //memset((void*)NmeaBuf,0,sizeof(NmeaBuf));
    }

    /* Alle Error Flags löschen */
    USART1->SR;
    USART1->DR;

}

[Stefan F. (Gast)]

Christian J. schrieb:
> Gibt es da eine Schmerzgrenze?

Das kommt ganz auf deine Anwendung an. Während diese ISR läuft, sind 
alle niedriger priorisierten Interrupts gesperrt.

Wenn die ISR zur Verarbeitung der Daten länger braucht, als die nächsten 
Daten herein kommen, hast du ganz sicher eine Schmerzgrenze 
Überschritten.

[Christian J. (Gast)]

Stefan ⛄ F. schrieb:
> Das kommt ganz auf deine Anwendung an. Während diese ISR läuft, sind
> alle niedriger priorisierten Interrupts gesperrt.

Klar, logisch.... dachte nur es gibt da heilige Grals, die man nicht 
verletzten sollte.

Nimmt man zb das Wörtchen static hier weg klappt die Auswertung schon 
nicht mehr, da bleiben Felder dann leer. Ohne mir das genau angeschaut 
zu haben was da jetzt nicht klappt. Normalerweise deklariere ich alles 
als static im Int, damit es im .data (oder .bss?) Bereich liegt damit da 
keine "Stack Geschichten" passieren können.

static char* nmea_fields[MAX_NMEA_FIELDS];

[John Doe (Gast)]

Christian J. schrieb:
> Nimmt man zb das Wörtchen static hier weg klappt die Auswertung schon
> nicht mehr, da bleiben Felder dann leer. Ohne mir das genau angeschaut
> zu haben was da jetzt nicht klappt. Normalerweise deklariere ich alles
> als static im Int, damit es im .data (oder .bss?) Bereich liegt damit da
> keine "Stack Geschichten" passieren können.

Gutgemeinter Rat: Besorg Dir ein C-Buch.
Dein Code macht mir Angst...

[foobar (Gast)]

Zum einen:

   char foo[4];
   ...
   gps_info.min = atoi(strncpy(foo,p,2));

Der strncpy macht nicht das, was du dir vorstellst.

Zum anderen: String-Funktionen in Interrupts zu benutzen ist unsauber. 
POSIX erlaubt sie z.B. nicht in signal-Handlern.  Die, die du benutzt, 
sind wahrscheinlich OK aber es gab Zeiten, wo sie z.B. auf x86 
sporadisch nicht funktionierten (direction-flag falsch).  Komplexere wie 
z.B. strtok oder printf sind immer ein no-go.

[Christian J. (Gast)]

foobar schrieb:
> Der strncpy macht nicht das, was du dir vorstellst.

Und was macht er? Das sah vorher anders aus und wurde nur zusammen 
geschrumpft. Der Rückgabewert ist aber ein Zeiger auf das was ich haben 
will. Laufen tut es zumindest. Wie geht es besser?

PS: Es fehlt der \0 Terminator, der wird ja nicht kopiert. Das klappt 
also nur zufällig.

Declaration
Following is the declaration for strncpy() function.
char *strncpy(char *dest, const char *src, size_t n)
Parameters
dest − This is the pointer to the destination array where the content is 
to be copied.
src − This is the string to be copied.
n − The number of characters to be copied from source.

Return Value
This function returns the final copy of the copied string.

[foobar (Gast)]

man strncpy:

   ...
       The  strncpy() function is similar, except that at most n
       bytes of src are copied.  WARNING: If there  is  no  null
       byte among the first n bytes of src, the string placed in
       dest will not be null-terminated.
   ...

[Christian J. (Gast)]

Habs schon, danke !!!!
Fehlersicher ist das sowieso nicht, sobald der String nicht so ist wie 
erwartet fliegt das alles aus der Kurve :-( Wobei alle static Vars 0 
sind beim Start des Systems, allerdings nicht wenn der Speicher sich vom 
Stack geklaut wird, dann steht da Müll drin.

char foo[4] = {0,0,0,0};
char *p = nmea_fields[1];

gps_info.utc_hour = atoi(strncpy(foo,p,2));
p +=2;
gps_info.min = atoi(strncpy(foo,p,2));
p +=2;
gps_info.sec = atoi(strncpy(foo,p,2));

[MaWin (Gast)]

Welche Regeln sollte man beachten?

1. ISR wird 'priviligiert' ausgeführt.
2. Eine höhere Priorität unterbricht eine niedrigere.
3. Die ISR sollte enden, bevor sie wieder angesprungen wird (werden 
sollte).

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

Und immer erstmal das IT Flag löschen, wenns gesetzt ist, egal, was 
später passiert.
Das ist besonders bei externen (GPIO) Interrupts wichtig.
Beim Initialisieren der IRQ Quelle die Pendings löschen.
Delays, die auf sys_tick basieren, hängen in ISRs, weil sys_tick meist 
eine niedrige Priorität hat - ist eigentlich logisch und macht man 
sowieso nicht, kann aber im Fehlerfall Kopfzerbrechen bereiten.

[Christian J. (Gast)]

Matthias S. schrieb:
> Delays, die auf sys_tick basieren, hängen in ISRs, weil sys_tick meist
> eine niedrige Priorität hat - ist eigentlich logisch und macht man
> sowieso nicht, kann aber im Fehlerfall Kopfzerbrechen bereiten.

Naja, wer einen Delay in einer ISR verwendet gehört eigentlich auch an 
den Ei... aufgehängt :-)

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

Christian J. schrieb:
> Naja, wer einen Delay in einer ISR verwendet gehört eigentlich auch an
> den Ei... aufgehängt :-)

Es sind Fälle vorstellbar, wo mans trotzdem braucht. Ich hatte z.B. mal 
prellende Hallsensoren in einem BLDC, musste aber unbedingt den Sensor 
auswerten. Da konnte es schon mal passieren, das man ein paar µs warten 
muss.
Aber ich schrieb ja auch:
Matthias S. schrieb:
> und macht man
> sowieso nicht