STM32 Interrupts - Welche Regeln sollte man beachten?

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.

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];

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...

Zum einen:

1

   char foo[4];

2

   ...

3

   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.

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.

man strncpy:

1

   ...

2

       The  strncpy() function is similar, except that at most n

3

       bytes of src are copied.  WARNING: If there  is  no  null

4

       byte among the first n bytes of src, the string placed in

5

       dest will not be null-terminated.

6

   ...

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.

1

char foo[4] = {0,0,0,0};

2

char *p = nmea_fields[1];

3

4

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

5

p +=2;

6

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

7

p +=2;

8

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

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. 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 :-)