Projekt mit mehreren Files und Interrupt

Gast #1573911
Lesenswert?

Hallo zusammen,

ich möchte ein großes Projekt auteilen und sparate Funktionen / Abläufe 
auslagern in separate .c Dateien. Jetzt habe ich eine Frage bezüglich 
Interrupts. Ich habe noch nicht angefangen, daher hier der Code, den ich 
mir vorstelle:

Hauptprogramm:
main.c
1
#include {alles mögliche}
2
#include "Funktion_eins.h"
3
#include "Funktion_zwei.h"
4

5
#define alles mögliche
6

7
ISR (Timer0_vect)
8
{
9
...code...
10
}
11

12
void Funktion_drei (void)
13
{
14
...code...
15
}
16

17
void main (void)
18
{
19
  for(;;)
20
  {
21
    ...code...
22
    MachWas(); // siehe Funktion_eins.c
23
    ...code...
24
    NochMehr(); // siehe Funktion_zwei.c
25
    ...code...
26
    Funktion_drei(); // siehe oben
27
  }
28
}

Funktion_eins.c
1
#include "Funktion_eins.h"
2

3
void MachWas(void)
4
{
5
...code...
6
}

Funktion_zwei.c
1
#include "Funktion_zwei.h"
2

3
void NochMehr(void)
4
{
5
...code...
6
}

Funktion_eins.h
1
void MachWas(void)

Funktion_zwei.h
1
void NochMehr(void)

So und nun meine Frage:
Generell: stimmt die Struktur?
zu Interrupt: Wenn ich mich in eine der beiden (externen)Funktionen 
(eins oder zwei) befinde und der Timer0 (Im Hauptfile) einen Interrupt 
erzeugt, wird dann auch meine ext. Funktion unterbrochen? Oder muss 
ichin dieser Funktion.C auch eine ISR anlegen bzw auf den Hauptfile 
verweisen?
Gast #1573983
Lesenswert?

M.B. schrieb:
> So und nun meine Frage:
> Generell: stimmt die Struktur?

Naja, man legt normalerweise nicht für jede Funktion ein separates File 
an, sondern versucht logisch zusammenhängede Funktionen in extra Files 
zu bündeln.

> zu Interrupt: Wenn ich mich in eine der beiden (externen)Funktionen
> (eins oder zwei) befinde und der Timer0 (Im Hauptfile) einen Interrupt
> erzeugt, wird dann auch meine ext. Funktion unterbrochen? Oder muss
> ichin dieser Funktion.C auch eine ISR anlegen bzw auf den Hauptfile
> verweisen?

Natürlich wird sie unterbrochen. Wenn du eine Funktion in einem anderen 
File hast, hat dass doch nichts mit der Ausführung des Programmes zu 
tun. Ein Programm wird immer schön Schritt für Schritt ausgeführt - bis 
es ein Interrupt unterbricht - dann gehts weiter.
Das Auslagern in andere Files hat doch größtenteils nur was mit der 
Übersichtlichkeit zu tun. Nach dem Compilieren hast du ein großes 
Programm, dass nicht mehr weiß, aus welchen Files sein Code kam. Ist 
auch unwichtig für die Ausführung.
Gast #1574685
Lesenswert?

LordZiu schrieb:
> M.B. schrieb:
>> So und nun meine Frage:
>> Generell: stimmt die Struktur?
>
> Naja, man legt normalerweise nicht für jede Funktion ein separates File
> an, sondern versucht logisch zusammenhängede Funktionen in extra Files
> zu bündeln.

Ja das ist mir schon klar, aber diese Funktionen werden in diesem Fall 
recht groß sein und praktisch eine eigenes Programm abarbeiten, was 
eigentlich schon eine Main ist, aber nur selten oder einmalig zur 
initialisierung benötigt wird und mir den wesentlichen Code schwer 
lesbar machen würde.

LordZiu schrieb:
> Natürlich wird sie unterbrochen.

Ja, vielen Dank. Ich war mir nicht ganz sicher, aber jetzt im nachhinein 
betrachtet ist das ja auch völlig logisch! Aber trotzdem Danke für deine 
Antwort, du hast mich sicherer gemacht.
Da es ein großes Projekt werden soll, wollte ich von Anfang an alles 
übersichtlich gestalten und späteres umstrukturieren vermeiden. Das 
führt nämlich zu 99% zu Fehlern, bei denen keiner mehr durchblickt.

Dann mal los...
#1574719
Lesenswert?

M.B. schrieb:

> Da es ein großes Projekt werden soll, wollte ich von Anfang an alles
> übersichtlich gestalten und späteres umstrukturieren vermeiden.

Mach dir deswegen keine Sorgen.
Auch wenn du von Anfang an alles 'richtig gemacht' hast, wirst du um 
späteres umstrukturieren nicht umhin kommen.

> Das
> führt nämlich zu 99% zu Fehlern, bei denen keiner mehr durchblickt.

globale Variablen an einer Stelle sammeln
gute Variablennamen wählen
gute Funktionsnamen wählen
keine elends lange Funktionen schreiben
saubere Code-Formatierung
nichts als in Stein gemeißelt ansehen, sondern ruhig auch grundlegende
 Dinge verändern wenn sich rausstellt, dass eine Entscheidung nicht
 so toll war.
Seinen Code immer kritisch betrachten

damit kriegt man die Dinge schon in den Griff

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren