mikrocontroller.net

Forum: Compiler & IDEs Timer ISR beenden


Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen zusammen,

hab mal ne Frage zu ner ISR:
ISR(TIMER0_OVF0_vect)
  {
    TCNT0 = 0x3D;
    
    timer_tick++;

    if  (timer_tick == 40)
      { 
        timer_tick = 0;
        timer_sec++;
      }

    if (timer_sec == 60)
      {
        timer_sec = 0;
        timer_min++;
      }

    if (timer_min == 60)
      {
        timer_min = 0;
        timer_hour++;
      }
  }

so sieht die Timer_ISR (AVR GCC mit Tiny 26) bei mir aus.
Wie man erkennen kann, soll hiermit ein Stunden-, Minten- und 
Sekunden-Timer realisiert werden.
Mein Frage nun:
Muss ich die ISR noch irgendwie beenden, so wie bei normalen UP mit 
return?
Weil wenn ich nun in meinem Simulator da rein springe, kommt er nicht 
mehr raus. Auch in meinem Gerät tut sich nichts, wenn ich später das 
Minutenregister abfrage.

Hoffe ihr könnt mir helfen.

Gruß
Stephan

Autor: OliverSo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Muss ich die ISR noch irgendwie beenden, so wie bei normalen UP mit
>return?

Nö.
Auch ein "normales UP" braucht nur dann ein return, wenn ein Wert 
zurückgegeben wird. (In Basic mag das anders sein).

>Weil wenn ich nun in meinem Simulator da rein springe, kommt er nicht
>mehr raus. Auch in meinem Gerät tut sich nichts, wenn ich später das
>Minutenregister abfrage.

Welcher Simulator, wie reinspringen, ...?

Zeig doch mal das ganze Programm.

Oliver

Autor: Thomas W. (thomasw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst das Flag löschen, dass den Interrupt ausgelöst hat.

MfG

Autor: Stephan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich den Simulator von AVR Studio verwende kann man ja Schritt für 
Schritt das Programm durchgehen. Nur wenn ich nun in die ISR 
reinspringe, komm ich da nicht mehr raus.

Also müsste ich dann timer_min mit reutrn zurückgeben?
kann ich auch mehrere Werte zurückgeben, bräuchte auch den Stundenwert.
Wenn ja, wie?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also müsste ich dann timer_min mit reutrn zurückgeben?

Nein. Wohin sollte es auch zurückgegeben werden? Du rufst die ISR ja 
nirgends explizit auf.

> kann ich auch mehrere Werte zurückgeben, bräuchte auch den Stundenwert.
> Wenn ja, wie?

So wie du es schon tust: Indem du sie als globale Variablen anlegst. 
Allerdings mußt du sie als volatile deklarieren.

> Nur wenn ich nun in die ISR reinspringe, komm ich da nicht mehr raus.

Wie "springst" du denn da rein?

Warum gibst du eigentlich aus allen Funktionen 0 zurück (außer bei 
main(), wo es eigentlich vorgeschrieben ist)? Außerdem solltest du bei 
der Parameterliste explizit void reinschreiben, also z.B. so:

[/C]
void timer_init(void)
{
  TCCR0 = 0x05;
  TIMSK = 0x02;
  TCNT0 = 0x3D;

}
[/C]

Übrigens empfiehlt es sich, statt irgendwelchen magischen Zahlen die 
Bits beim Namen zu nennen (bei TCNT0 natürlich nicht). Das ist deutlich 
lesbarer.

Übrigens: Ist es gewollt, daß dein Programm einmal pro Stunde für eine 
Minute wild den PB4 hin- und hertoggelt?

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok danke für die Tipps.

Bin grad erst noch am Anfang mit der C-Programmierung.
Habe mich die ganze Zeit mit Assembler rumgetrieben und wollte
jetzt halt mal was neues ausprobieren.

Ja des mit dem toggeln war halt, dass ich seh, ob der Timer irgendwas 
macht.

Eine volatile Deklaration geht dann so?:
volatile uint8_t timer_tick, timer_sec, timer_min, timer_hour;

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus wrote:

> Außerdem solltest du bei
> der Parameterliste explizit void reinschreiben, also z.B. so:
>
> [/C]
> void timer_init(void)
> {
>   TCCR0 = 0x05;
>   TIMSK = 0x02;
>   TCNT0 = 0x3D;
>
> }
> [/C]
>

Und wozu soll das gut sein?

(Das void in der Argumentliste macht nur bei Protoypen Sinn,
da ist es dann aber tatsächlich wirklich wichtig. Bei
Funktionsdefinitionen wie hier im Beispiel ist es IMHO sinnlos.
Was soll der Compiler denn in diesem Fall annehmen, ausser dass
die Argumentliste leer ist?)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas W. wrote:
> Du musst das Flag löschen, dass den Interrupt ausgelöst hat.
>

Quatsch.
Dafür sorgt schon der reine Aufruf der ISR.
AFAIK ist einzig und alleine der UART Receive Interrupt eine
Ausnahme: Das Interrupt Flag wird erst durch Lesen von UDR
gelöscht. Aber ansonsten wird das Flag immer automatisch
durch den Aufruf der zugehörigen ISR gelöscht.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, volatile funktioniert so.  Ist aber eine ,,Pessimierung'', ggf.
willst du die Werte dann in der ISR am Anfang cachen:
ISR(TIMER0_OVF0_vect)
  {
    uint8_t t, s, m, h;

    TCNT0 = 0x3D;

    t = timer_tick;
    s = timer_sec;
    m = timer_min;
    h = timer_hour;

    if  (++t == 40)
      {
        t = 0;
        s++;
      }

    if (s == 60)
      {
        s = 0;
        m++;
      }

    if (m == 60)
      {
        m = 0;
        h++;
      }

    timer_hour = h;
    timer_min = m;
    timer_sec = s;
    timer_tick = t;
  }

Übrigens: das Rücksetzen von TCNT0 innerhalb der ISR ist nicht gerade
optimal.  Vom Overflow selbst bist zum Rücksetzen vergeht Zeit, u. U.
hat der Zähler dann bereits weiter gezählt.  Wenn dein AVR für den
Timer 0 den CTC-Modus unterstützt (clear timer on compare match), dann
nimm lieber diesen.  Dann heißt aber die ISR auch anders (z. B.
TIMER0_COMPA_vect).

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> (Das void in der Argumentliste macht nur bei Protoypen Sinn,
> da ist es dann aber tatsächlich wirklich wichtig.

Wenn die Definition der Funktion zugleich die Deklaration ist
(d. h. die erste Erwähnung dieses Namens im laufenden Programmtext),
dann hat es sehr wohl Sinn.  Ansonsten schadet es auch nichts, wenn
man es sich gleich so angewöhnt, dann vergisst man es wenigstens
nicht, wenn es wirklich drauf ankommt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Karl heinz Buchegger wrote:
>
>> (Das void in der Argumentliste macht nur bei Protoypen Sinn,
>> da ist es dann aber tatsächlich wirklich wichtig.
>
> Wenn die Definition der Funktion zugleich die Deklaration ist
> (d. h. die erste Erwähnung dieses Namens im laufenden Programmtext),
> dann hat es sehr wohl Sinn.

Glaubst du im Ernst, dass ein Compiler so dämlich ist
aus

void foo()
{
  irgendwas;
}

sich ein Deklaration von
void foo();
zurechtzulegen.

> Ansonsten schadet es auch nichts,

Das ist wohl wahr.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Glaubst du im Ernst, dass ein Compiler so dämlich ist
> aus
>
> void foo()
> {
>   irgendwas;
> }
>
> sich ein Deklaration von
> void foo();
> zurechtzulegen.

Na klar macht er das.

#include <stdio.h>
void
foo()
{
        printf("foo!\n");
}

int
main(void)
{
        foo(42);
        bar(42);
        return 0;
}
% gcc -Wall -Wextra -ansi -pedantic -c foo.c
foo.c: In function `main':
foo.c:12: warning: implicit declaration of function `bar'

Wie zu sehen ist, wird foo() ordentlich als Funktion mit "old style
K&R"-Deklaration registriert, es gibt keine Warnung, wenn die Funktion
anschließend mit einem Parameter aufgerufen wird, obwohl sie
eigentlich gar keinen Parameter verarbeiten kann.  Eine im Vergleich
dazu undeklarierte Funktion bar() erzeugt hingegen sehr wohl eine
Warnung.

Der C-Standard sieht es ausdrücklich vor, dass Deklaration und
Definition einer Funktion zusammen fallen können.  Zwar sagt der
Standard, dass eine leere Parameterliste in einem Funktionsdeklarator,
der Teil einer Funktionsdefinition ist (also nicht eigentständig nur
als Deklarator benutzt wird) eine parameterlose Funktion deklariert.
Da aber bei der nicht-prototypischen Funktionsdeklaration der Compiler
keinerlei Argumentüberprüfungen vornimmt, vergisst zumindest der GCC
diese Parameterlosigkeit sofort wieder, obwohl er den Namen der
Funktion sehr wohl ab diesem Moment als deklariert ansieht.  Nachdem
ich Punkt 6.7.5.3 Anmerkung 14 Satz 2 gelesen habe, denke ich, dass
der Compiler zumindest eine Warnung generieren dürfte, wenn die
Funktion dann dennoch mit Parametern aufgerufen wird (so wie hier).

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Glaubst du im Ernst, dass ein Compiler so dämlich ist aus
>
> void foo()
> {
>   irgendwas;
> }
>
> sich ein Deklaration von
> void foo();
> zurechtzulegen.

Also gcc ist so "dämlich". Aber hat er denn eine andere Wahl? Ich kann 
grad nicht in der C-Norm nachschlagen, aber ich kann mir eigentlich 
nicht vorstellen, daß der Compiler hier an der Deklaration noch 
eigenmächtig was verändern darf.

Autor: OliverSo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ist aber eine ,,Pessimierung'', ggf.
>willst du die Werte dann in der ISR am Anfang cachen:

Generell ist der Hinweis sicher richtig, aber ggf. ist auch das richtige 
Stichwort. In dem speziellen Fall müsste man tatsächlich einmal genau 
nachzählen, ob die zusätzlichen 8 Zyklen fürs cachen tasächlich durch 
die bessere Registeroptimierung wieder rausgeholt werden, und bei mal 
gerade 40Hz ISRfrequenz und 8MHz CPU-Takt ist das alles sowieso völlig 
Wurscht :-)


Oliver

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OliverSo wrote:

> Generell ist der Hinweis sicher richtig, aber ggf. ist auch das richtige
> Stichwort. In dem speziellen Fall müsste man tatsächlich einmal genau
> nachzählen, ob die zusätzlichen 8 Zyklen fürs cachen tasächlich durch
> die bessere Registeroptimierung wieder rausgeholt werden,

Der Compiler muss die Werte aus dem SRAM ohnehin in Register
laden, bevor er sie benutzt.  Damit ensteht durch das Cachen in
keinem Falle ein Nachteil.  Der generierte Code wird kleiner und
schneller:

/* function __vector_6 size 52 (40) */

gegenüber:

/* function __vector_6 size 49 (31) */

> und bei mal
> gerade 40Hz ISRfrequenz und 8MHz CPU-Takt ist das alles sowieso völlig
> Wurscht :-)

Klar, "never start optimizing before you have profiled it".
Andererseits sollte man sich solche Dinge einfach schon frühzeitig
angewöhnen.  Wenn irgendwo ein "volatile" auftaucht, sollten die
Alarmglocken klingeln, dass hier der Compiler am Optimieren gehindert
wird, und dass man ihm ggf. helfen kann, die Dinge trotzdem noch zu
optimieren, die optimierbar sind.  So ein Caching nachträglich
reinzubauen ist viel mehr Aufwand, als wenn man's gleich von Beginn an
macht.

Autor: OliverSo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Der Compiler muss die Werte aus dem SRAM ohnehin in Register
>laden, bevor er sie benutzt.

Das ist richtig. Allerdings pusht er in der cache-Variante bei jedem 
Aufruf 4 Register mehr, als in der Nicht-Cache-Variante, während ein 
Teil des durch die Optimierung verkürzten Codes nur bei erfüllter 
Vergleichbedingung, d.h. äusserst selten, durchlaufen wird.

Da kommt es halt darauf an, was jetzt das Optimierungsziel ist: mittlere 
kürzeste Durchlaufzeit, oder minimale Maximaldurchlaufzeit.
Echt "profilert" hab ich das natürlich nicht.

>Wenn irgendwo ein "volatile" auftaucht, sollten die
>Alarmglocken klingeln, dass hier der Compiler am Optimieren gehindert
>wird

Grundsätzlich volle Zustimmung.

Oliver

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OliverSo wrote:

> Das ist richtig. Allerdings pusht er in der cache-Variante bei jedem
> Aufruf 4 Register mehr, als in der Nicht-Cache-Variante, während ein
> Teil des durch die Optimierung verkürzten Codes nur bei erfüllter
> Vergleichbedingung, d.h. äusserst selten, durchlaufen wird.

OK, hier noch die mikro-optimierte Variante ohne zuätzliche Pushes. ;-)
#include <avr/io.h>
#include <avr/interrupt.h>

volatile uint8_t timer_tick, timer_sec, timer_min, timer_hour;

ISR(TIMER0_OVF0_vect)
{
    uint8_t t, s, m;

    TCNT0 = 0x3D;

    t = timer_tick;

    if  (++t == 40)
    {
        timer_tick = 0;

        s = timer_sec;

        if (++s == 60)
        {
            timer_sec = 0;

            m = timer_min;

            if (++m == 60)
            {
                timer_min = 0;

                timer_hour++;
            }
            else
            {
                timer_min = m;
            }
        }
        else
        {
            timer_sec = s;
        }
    }
    else
    {
        timer_tick = t;
    }
}

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blöde Frage: Die Angabe der Controllers in der makefile bzw. im 
AVR-Studi stimmt, oder?

Das Programm sieht auf den ersten Blick lauffähig aus. Nur das sei();
würde ich gleich hinter den Initialisierungen und nicht im Mainloop
platzieren!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Wie zu sehen ist, wird foo() ordentlich als Funktion mit "old style
> K&R"-Deklaration registriert, es gibt keine Warnung, wenn die Funktion
> anschließend mit einem Parameter aufgerufen wird, obwohl sie
> eigentlich gar keinen Parameter verarbeiten kann.

Ich schmeiss mich weg.
Bin wohl schon zusehr C++ verwöhnt.

> Der C-Standard sieht es ausdrücklich vor, dass Deklaration und
> Definition einer Funktion zusammen fallen können.

Logisch.

>  Zwar sagt der
> Standard, dass eine leere Parameterliste in einem Funktionsdeklarator,
> der Teil einer Funktionsdefinition ist (also nicht eigentständig nur
> als Deklarator benutzt wird) eine parameterlose Funktion deklariert.

Auch das ist sofort einsichtig.

> Da aber bei der nicht-prototypischen Funktionsdeklaration der Compiler
> keinerlei Argumentüberprüfungen vornimmt, vergisst zumindest der GCC
> diese Parameterlosigkeit sofort wieder, obwohl er den Namen der
> Funktion sehr wohl ab diesem Moment als deklariert ansieht.

Den Satz versteh ich jetzt nicht. Ich seh irgendwie nicht wie
der erste Satzteil mit dem zweiten zusammenhängt.
Und ehrlich: so richtig logisch erscheint mir das nicht. Wenn die
Funktionsdefinition vorliegt, kann doch die Deklaration vollständig
davon abgeleitet werden. Eine leere Argumentliste in einer
Definition ist doch einer void Argumentliste in der Dekleration
absolut gleichzusetzen.

Aber gut das wir mal darüber gesprochen haben. Wieder was
gelernt.

Autor: OliverSo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Traumhaft :-)

Oliver

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus wrote:
>> Glaubst du im Ernst, dass ein Compiler so dämlich ist aus
>>
>> void foo()
>> {
>>   irgendwas;
>> }
>>
>> sich ein Deklaration von
>> void foo();
>> zurechtzulegen.
>
> Also gcc ist so "dämlich". Aber hat er denn eine andere Wahl? Ich kann
> grad nicht in der C-Norm nachschlagen, aber ich kann mir eigentlich
> nicht vorstellen, daß der Compiler hier an der Deklaration noch
> eigenmächtig was verändern darf.

Ich seh das eigentlich so, dass diese Funktionsdefinition
eine Deklaration (*) von

void foo( void );

nach sich ziehen sollte. Denn genau das steht doch in der
Definition: Eine Funktion die keine Argumente nimmt. Das
Pendant dazu in der Dekleration ist die void Argumentliste.


(*) heisst das eigentlich Dekleration oder Deklaration
                              #                #

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dekl_a_ration. Kommt von Dekl_a_rieren.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Ich schmeiss mich weg.
> Bin wohl schon zusehr C++ verwöhnt.

C++ hat ja auch kein 1970er K&R-Erbe zu tolerieren...  Da ist
void foo(void);

und
void foo();

wirklich das Gleiche.

>> Da aber bei der nicht-prototypischen Funktionsdeklaration der
>> Compiler keinerlei Argumentüberprüfungen vornimmt, vergisst
>> zumindest der GCC diese Parameterlosigkeit sofort wieder, obwohl er
>> den Namen der Funktion sehr wohl ab diesem Moment als deklariert
>> ansieht.

> Den Satz versteh ich jetzt nicht. Ich seh irgendwie nicht wie der
> erste Satzteil mit dem zweiten zusammenhängt.

Beide Funktionen sind in der Tat als Funktionen ohne Parameter
deklariert.  Aber: dann schlägt das K&R-Erbe zu, in Form der
constraints in 6.5.2.2, Absatz 2:

  If the expression that denotes the called function has a type that
  includes a prototype, the number of arguments shall agree with the
  number of parameters. Each argument shall have a type such that its
  value may be assigned to an object with the unqualified version of
  the type of its corresponding parameter.

Da nun eine Deklaration + Definition der Form
void foo()
{
  ...
}

keinen Prototypen darstellt, ist der Compiler nicht gehalten, die
Anzahl der Argumente zu überprüfen.  Hyster^H^H^H^Historischer Code
könnte sich auf diesen Quatsch leider verlassen (auch wenn das
Verhalten bei falschen Argumenten explizit "undefined" ist), sodass
GCC daran wahrscheinlich auch nicht drehen mag.  Nicht-prototypische
Funktionsdeklarationen sind laut Standard ein "obsolescent feature",
d. h. sollten in neuem Code einfach mal nicht auftauchen.

> Und ehrlich: so richtig logisch erscheint mir das nicht. Wenn die
> Funktionsdefinition vorliegt, kann doch die Deklaration vollständig
> davon abgeleitet werden.

Nein, eine prototypische Deklaration ist etwas anderes als eine
K&R-mäßige.  Die folgenden beiden Funktionen sind nämlich in ihrem
Aufrufverhalten nicht gleich:
void
foo(char c, float f)
{
   ...
}

void
bar(c, f)
  char c;
  float f;
{
   ...
}

Beim Aufruf von foo() werden die Argumente so übergeben, als wären sie
Zuweisungen an die beiden Parameter.  Beim Aufruf von bar() dagegen
werden default argument promotions durchgeführt, also der erste
Parameter (der dann hoffentlich ein ganzzahliger Typ ist :) wird nach
int promotet, der zweite nach double!  (Diese default argument
promotion passiert bei protypischen Deklarationen nur noch für die
variable Argumentliste, die aus diesem Grunde auch keine Datentypen
kleiner als int oder double übernehmen kann.)

Alles zusammen jedenfalls gute Gründe, bei C immer
void
foo(void)
{
  ...
}

...zu schreiben.  Da's bei C++ nicht stört, bevorzuge ich diese
Schreibweise auch dort.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> ...  Nicht-prototypische
> Funktionsdeklarationen sind laut Standard ein "obsolescent feature",
> d. h. sollten in neuem Code einfach mal nicht auftauchen.

Wenigstens dafür aber gibt's eine Warnung, wenn man will:

-Wstrict-prototypes

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Wenigstens dafür aber gibt's eine Warnung, wenn man will:
>
> -Wstrict-prototypes

Sehe ich gerade noch:

  -Wold-style-definition (C only)
      Warn if an old-style function definition is used.  A warning is
      given even if there is a previous prototype.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Merci, Jörg

Jetzt hab ichs auch geschnallt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.