Beim AVR-Studio zwei Projekte "verschmelzen"

[Nico (Gast)]

Hallo,
beim AVR-Studio sollen zwei C-Projekte zusammengefasst werden.

Der Übersichlichkeit halber habe ich die Main-Datei vom kleineren 
Projekt in den Ordner "Source Files" vom größeren Projekt gepackt und 
die Main-Datei vom kleineren Projekt in

int projekt_klein(void)    //vorher: int main(void)

umbenannt.

Wenn ich aber

projekt_klein(void);

von der Main-Datei aus dem größeren Projekt aufrufe, wird die nicht 
ausgeführt.
Woran kann das liegen?

(es sind nebenbei gesagt auch noch zwei h.Dateien beteiligt)

[Theor (Gast)]

Es wird vermutlich hilfreich sein, falls Du die Projektdatei in einem 
neuen Beitrag anhängst, sowie die evtl. Fehlermeldungen und Warnungen, 
die beim Compilieren auftreten.

"AVR-Studio" nannte die Projektdateien "*.aps".

Ich verweise ausdrücklich auf das von Dir in der Überschrift genannte 
"AVR-Studio", denn ich weiß nicht, wie das aktuellere "Atmel Studio" 
seine Projektdateien nennt. (Ich habe allerdings auch keinen 
Anhaltspunkt, dass die Dateiendung geändert wurde).

[Nico (Gast)]

Fehlermeldungen und Warnungen beim Compilieren gibt es nicht, da ist 
alles ok.

Ich habe die main.c-Datei (nach Umbenennung in ber_uart.c) und die 
zugehörige.h Datei (ohne Umbenennung) vom kleineren Projekt in den 
Projektordner vom größeren Projekt kopiert und dann nach Starten der 
.apd-Datei vom größeren Projekt in dieses die beiden Neulinge 
eingebunden:


Kleines Projekt:
main.c -umbenannt-> ber_uart.c
uart.h

Dann die beiden Dateien in den Projektordner vom großen Projekt 
verschoben.

Dann das große Projekt gestartet und dort folgendes eingebunden:
ber_uart.c in Source Files (dort ist auch die main.c vom großen Projekt 
untergebracht)
uart.h in Header Files


Code hier veröffentlichen geht leider nicht ohne weiteres, bin nur 
Teilautor.

[Theor (Gast)]

Nico schrieb:
> Fehlermeldungen und Warnungen beim Compilieren gibt es nicht, da ist
> alles ok.

Aha. OK. Nur der Vollständigkeit halber die Frage, welchen Warnlevel Du 
eingestellt hast. Am besten wäre m.M.n. "-wall".

> [...]

> Code hier veröffentlichen geht leider nicht ohne weiteres, bin nur
> Teilautor.

Das macht die Sache nun nicht gerade einfacher. :-)

Irgendwelche konkreten Anhaltspunkte (jenseits der bloßen Namen der 
Dateien) sind aus meiner Sicht notwendig.
Das soweit von Dir geschilderte Vorgehen allein kann eine Fehlfunktion 
jedenfalls nicht erklären.

Allenfalls könnte man vermuten, dass beide "Teilprogramme" jeweils die 
gleichen Peripherieeinheiten benutzen oder zwar verschiedene, aber 
solche deren Funktion sich ggs. beeinflusst.

Aber auch die beschreibung: "... wird die [Funktion] nicht ausgeführt." 
ist nicht hilfreich. Zumal das prinzipiell eher fragwürdig ist. Eine CPU 
kann sich nicht "weigern" eine Funktion auszuführen.

[Theor (Gast)]

Ein Ansatzpunkt wäre noch, das Programm im Simulator zu untersuchen. 
Oder, falls vorhanden, mit einem Emulator wie "Atmel ICE".

[Stefan F. (Gast)]

Nico schrieb:
> von der Main-Datei aus dem größeren Projekt aufrufe, wird die nicht
> ausgeführt.

Was genau heißt "wird die nicht ausgeführt"? Wenn das Programm 
compilierbar ist, dass ist der Code auch ausführbar. Es sei denn, du 
hast einen Fehler der dazu führt, dass das Programm vorher hängen bleibt 
oder eine Bedingung (if) die nie erfüllt wird.

[Nico (Gast)]

Hier schon mal Danke für deine Hilfe!

Theor schrieb:
> Aha. OK. Nur der Vollständigkeit halber die Frage, welchen Warnlevel Du
> eingestellt hast. Am besten wäre m.M.n. "-wall".

-Wall ist eingestellt.


Theor schrieb:
>> Code hier veröffentlichen geht leider nicht ohne weiteres, bin nur
>> Teilautor.
>
> Das macht die Sache nun nicht gerade einfacher. :-)

Allerdings. Das größere Programm ist zudem noch sehr umfangreich.


Aber grundsätzlich ist an der oben beschriebenen Vorgehensweise schon 
mal nichts auszusetzen, wenn ich das richtig verstehe?!


> Allenfalls könnte man vermuten, dass beide "Teilprogramme" jeweils die
> gleichen Peripherieeinheiten benutzen oder zwar verschiedene, aber
> solche deren Funktion sich ggs. beeinflusst.

Gute Frage. Ein paar include#-Dateien sind doppelt, das bügelt der 
Compiler normalerweise einfach weg.


> Aber auch die beschreibung: "... wird die [Funktion] nicht ausgeführt."
> ist nicht hilfreich. Zumal das prinzipiell eher fragwürdig ist. Eine CPU
> kann sich nicht "weigern" eine Funktion auszuführen.
Kurz gesagt habe ich in der "main-Funktion" des kleineren Projekts alles 
deaktiviert, was mit Berechnungen zu tun hat und darauf reduziert, dass 
nach dem Aufruf nur eine Variable als Endlosschleife über den UART 
ausgegeben wird und sich eine LED einschaltet. Das passiert aber nicht. 
Daher gehe ich davon aus, dass die Funktion gar nicht erst aufgerufen 
wird.

[Stefan F. (Gast)]

Nico schrieb:
> -Wall ist eingestellt.

Und, wie lauten die Warnungen?

> Ein paar include#-Dateien sind doppelt, das bügelt der
> Compiler normalerweise einfach weg.

Wie bitte? Woher soll der Compiler wissen, welche der doppelten Dateien 
die richtigen sind?

> Kurz gesagt

Das geht so nicht. Lege uns den ganzen Quelltext vor, so dass wir das 
Problem nachvollziehen können.

[Theor (Gast)]

Nico schrieb:
> Hier schon mal Danke für deine Hilfe!
>
> Theor schrieb:
>> Aha. OK. Nur der Vollständigkeit halber die Frage, welchen Warnlevel Du
>> eingestellt hast. Am besten wäre m.M.n. "-wall".
>
> -Wall ist eingestellt.
>
>
> Theor schrieb:
>>> Code hier veröffentlichen geht leider nicht ohne weiteres, bin nur
>>> Teilautor.
>>
>> Das macht die Sache nun nicht gerade einfacher. :-)
>
> Allerdings. Das größere Programm ist zudem noch sehr umfangreich.
>
>
> Aber grundsätzlich ist an der oben beschriebenen Vorgehensweise schon
> mal nichts auszusetzen, wenn ich das richtig verstehe?!
>
>
>> Allenfalls könnte man vermuten, dass beide "Teilprogramme" jeweils die
>> gleichen Peripherieeinheiten benutzen oder zwar verschiedene, aber
>> solche deren Funktion sich ggs. beeinflusst.
>
> Gute Frage. Ein paar include#-Dateien sind doppelt, das bügelt der
> Compiler normalerweise einfach weg.

"Wegbügeln" in gewissen Fällen schon. Aber was nicht per 
Sprachdefinition redundant ist oder sich auslöscht, sollte, falls etwa 
widersprüchliche Deklarationen vorliegen, zu Warnungen führen.

>
>> Aber auch die beschreibung: "... wird die [Funktion] nicht ausgeführt."
>> ist nicht hilfreich. Zumal das prinzipiell eher fragwürdig ist. Eine CPU
>> kann sich nicht "weigern" eine Funktion auszuführen.
> Kurz gesagt habe ich in der "main-Funktion" des kleineren Projekts alles
> deaktiviert, was mit Berechnungen zu tun hat und darauf reduziert, dass
> nach dem Aufruf nur eine Variable als Endlosschleife über den UART
> ausgegeben wird und sich eine LED einschaltet. Das passiert aber nicht.
> Daher gehe ich davon aus, dass die Funktion gar nicht erst aufgerufen
> wird.

OK. Das ist aber im Grunde eine "Vermutung".
Und selbst wenn Du diese Vermutung für realistisch hältst, hilft Dir 
das nicht weiter. Du musst ja offenbar den Code an irgendeiner Stelle 
ändern, damit sich das Programm wie gewünscht verhält. Und weder für die 
Stelle dieser Änderung noch für die Art der Änderung ergibt Deine 
Beschreibung einen Anhalstpunkt.

Ein klarer Beleg für die Vermutung wäre, falls die Funktion tatsächlich 
nicht aufgerufen wird. Das könntest Du belegen, in dem Du in der 
aufzurufenden Funktion einen Breakpoint im Simulator setzt.

[Nico (Gast)]

Jedenfalls hier die Main-Funktion vom größeren Programm, teilweise 
schematisch.

int main 
{
    //jede Menge Initialisierungskram/Konfigurierungskram/Registerzieherei

    while(1) //Hauptprogrammschleife
    {
         // *** alles andere hier in der Hauptprogrammschleife deaktiviert
        int projekt_klein(void); //hier wird die Hauptfunktion im anderen c-Sheet aufgerufen
        _delay_ms(100);
    }

return 0 ;
}

[Stefan F. (Gast)]

Nico schrieb:
> int main {...}

So fäng keine main Funktion an.

> int projekt_klein(void); // hier wird die Hauptfunktion im anderen c-Sheet 
aufgerufen

Nein, das ist kein Funktionsaufruf.

Das Programm ist noch nicht einmal compilierbar. Warum ignorierst du die 
Fehlermeldungen des Compilers?

[Nico (Gast)]

Theor schrieb:
> OK. Das ist aber im Grunde eine "Vermutung".
> Und selbst wenn Du diese Vermutung für realistisch hältst, hilft Dir
> das nicht weiter. Du musst ja offenbar den Code an irgendeiner Stelle
> ändern, damit sich das Programm wie gewünscht verhält. Und weder für die
> Stelle dieser Änderung noch für die Art der Änderung ergibt Deine
> Beschreibung einen Anhalstpunkt.
>
> Ein klarer Beleg für die Vermutung wäre, falls die Funktion tatsächlich
> nicht aufgerufen wird. Das könntest Du belegen, in dem Du in der
> aufzurufenden Funktion einen Breakpoint im Simulator setzt.

Du hast völlig recht, irgendwie muss man das Problem sicher einkreisen.

Habe noch nie mit dem Simulator gearbeitet.
https://www.mikrocontroller.net/articles/AVR-Simulation
Dann würde ich mir das hier mal anschauen.

[Stefan F. (Gast)]

Simulieren ist sinnlos, solange das Programm nicht compiliert ist. Dann 
simuliert man nämlich nichts.

[Nico (Gast)]

Stefan ⛄ F. schrieb:
> Simulieren ist sinnlos, solange das Programm nicht compiliert ist. Dann
> simuliert man nämlich nichts.

Dann gib mal Butter bei die Fische, warum ist das Programmfragment 
deiner Meinung nach nicht kompilierbar?

Mein Compiler sagt nämlich Build succeed with 0 warnings.

[Theor (Gast)]

Nico schrieb:
> Theor schrieb:
>> OK. Das ist aber im Grunde eine "Vermutung".
>> Und selbst wenn Du diese Vermutung für realistisch hältst, hilft Dir
>> das nicht weiter. Du musst ja offenbar den Code an irgendeiner Stelle
>> ändern, damit sich das Programm wie gewünscht verhält. Und weder für die
>> Stelle dieser Änderung noch für die Art der Änderung ergibt Deine
>> Beschreibung einen Anhalstpunkt.
>>
>> Ein klarer Beleg für die Vermutung wäre, falls die Funktion tatsächlich
>> nicht aufgerufen wird. Das könntest Du belegen, in dem Du in der
>> aufzurufenden Funktion einen Breakpoint im Simulator setzt.
>
> Du hast völlig recht, irgendwie muss man das Problem sicher einkreisen.
>
> Habe noch nie mit dem Simulator gearbeitet.
> https://www.mikrocontroller.net/articles/AVR-Simulation
> Dann würde ich mir das hier mal anschauen.

Genau. Und da den Abschnitt über den im AVR-Studio enthaltenen 
Simulator. Vielleicht noch HAPSIM dazu, dort kannst Du sowohl den UART 
als auch die Portpins visualiseren.

Aber ACHTUNG:
Bitte kläre erstmal ob Du nun "AVR-Studio" oder "Atmel Studio" 
verwendest. Ich kenne Atmel Studio nicht. Wenn ich auch vermute, das 
vieles ähnlich ist und das nicht zwei grundverschiedene IDEs sind, kann 
es doch Unterschiede bei der Bedienung geben. Siehe auch hier: 
https://www.mikrocontroller.net/articles/Atmel_Studio

[Stefan F. (Gast)]

Nico schrieb:
> Dann gib mal Butter bei die Fische, warum ist das Programmfragment
> deiner Meinung nach nicht kompilierbar?

Habe ich doch in Beitrag "Re: Beim AVR-Studio zwei Projekte "verschmelzen"" 
geschrieben.

Nico schrieb:
> Mein Compiler sagt nämlich Build succeed with 0 warnings.

Dann hast du etwas anderes compiliert, jedenfalls nicht diese Datei.

[Christian H. (netzwanze)]

Nico schrieb:
> Aber grundsätzlich ist an der oben beschriebenen Vorgehensweise schon
> mal nichts auszusetzen, wenn ich das richtig verstehe?!

Schreibe doch ein kleines Programm, welches die Problematik zeigt aber 
vom Geheimprogramm nichts verrät. Das ist dann hoffentlich 
verständlicher als Prosa. Das Programm muss vollständig compilierbar 
sein, so dass auch ein anderer das Problem nachvollziehen kann.

[Peter D. (peda)]

Man kann nicht einfach 2 Endlosschleifen hintereinander pappen.
Man muß sich schon Gedanken machen, wie man beide Tasks sinnvoll in 
Zeitscheiben unterteilt und die dann wechselseitig in einer gemeinsamen 
Endlosschleifen aufrufen.
Davor muß natürlich eine gemeinsame Initialisierung erfolgen, die keine 
sich gegenseitig widersprechende Einstellungen vornimmt.

Man kann sich ja mal das hier ansehen:

http://www.dunkels.com/adam/pt/