mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LCD mit Interrupt möglich?


Autor: Matze Niemand (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ich möchte auf einem LCD-Display alle 10ms sieben Messwerte ausgeben 
lassen. Jeder Messwert hat die Länge von 5 Zeichen.
Nun hab ich aber das Problem, daß mein Display für anstatt 1s für 700 
Messwerte plötzlich ca. 10s braucht. Ich weiß, daß liegt an den vielen 
Pausen,die das Display sich gönnt.
Nun meine Frage: kann man diese ganzen Pausen auch irgendwie anders 
lösen. Ohne das mein µC in Warteposition steht - der hat nämlich 
eigentlich noch anderes zu tun. Zum Beispiel diese Messwerte über einen 
UART rauszupusten.

Ich bin für alle Lösungen offen!
Danke

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>ich möchte auf einem LCD-Display alle 10ms sieben Messwerte ausgeben
>lassen.

Und wer soll das lesen???

MfG Spess

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich erlaube mir mal die Fragem wer ein 100Hz Geflimmer von Meßwerten auf 
einem LCD lesen können soll?
Wenn sich die Werte so oft ändern, gibt es unlesbares Geflacker und wenn 
sich sich nicht so oft ändern, gibt es keinen Grund, sie so oft anzeigen 
zu wollen.

Gruß aus Berlin
Michael

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und du liest die 700 Messwerte pro Sekunde?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> alle 10ms ... Messwerte ausgeben
Kann das Display seine Kristalle überhaupt so schnell umschalten?  :-o

Autor: Matze Niemand (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eigentlich lese ich sogar 800 messwerte/s, aber das ist egal.
Ich habs eben mal ausgerechnet: mein µC befindet sich für einmal 7 
Messwerte schreiben 89,124ms  in der Warteschleife.
Vielleicht kann man den Schreibtakt auf 1/s herabsetzen, aber dennoch is 
er dann ca. 90ms mit wärmeproduzieren beschäftigt...

Das muß doch besser gehen!

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Ich habs eben mal ausgerechnet: mein µC befindet sich für einmal 7
>Messwerte schreiben 89,124s  in der Warteschleife.

In welcher Warteschleife??

MfG Spess

Autor: Matze Niemand (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, diese doofe _delay_ms funktion

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Welcher halbwegs intelligente Mensch benutzt DELAYS?

MfG Spess

Autor: Stefan M. (celmascant)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage hab ich mir auch schon gestellt.
Das LCD braucht nach jeder Datenübertragung eine Pause um die Daten zu 
verarbeiten.
Im Tutorial sind dazu Warteschleifen programmiert, wo der MC einfach 
sinnlos vor sich hin Zählt. Zum verdeutlichen der aktuellen Situation 
hier mal der Warteschleifen-Auszug aus meiner 8bit-Routine:
(Sollte eigendlich das gleiche wie im Tutorial sein)
;**********************************************************************
;
 ; Pause nach jeder Übertragung
delay50us:                              ; 50us Pause
           push temp1
       ldi  temp1, ( XTAL * 50 / 4 ) / 1000000
delay50us_:
       nop
           dec  temp1
           brne delay50us_
       pop temp1
           ret                          ; wieder zurück

 ; Längere Pause für manche Befehle
delay5ms:                                ; 5ms Pause
           push temp1
       push temp2
       ldi  temp1, ( XTAL * 5 / 607 ) / 1000
WGLOOP0:   ldi  temp2, $C9
WGLOOP1:   dec  temp2
           brne WGLOOP1
           dec  temp1
           brne WGLOOP0
       pop temp2
       pop temp1
           ret                          ; wieder zurück


;**********************************************************************

Kann man das irgendwie per Interupt regeln? Die Rechenzeit muss doch 
irgendwie sinnvoll zu nutzen sein...

Gruss Stefan

Autor: micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die meisten Dispalys haben auch ein Busy-Flag...

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Das LCD braucht nach jeder Datenübertragung eine Pause um die Daten zu
>verarbeiten.

Welches?

MfG Spess

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

es wurde zwar kein Display-Typ genannt, aber bei allen mir bekannten 
Display-Controllern kann man dann doch einfach vor der nächsten Ausgabe 
das Busy-Flag des Display abfragen.

Man kann das natürlich auch in einen Timer-Interrupt legen und z.B. alle 
5ms o.ä. ein Zeichen aus aus einem Displaybuffer ausgeben. Wenn man die 
Zeit passen wählt, muß man garnicht warten, höchstens bei Befehlen mit 
langer interner Laufzeit (Clear o.ä.).

Gruß aus Berlin
Michael

Autor: Matze Niemand (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite noch nicht solange mit µC. Das ist das erste mal, daß ich 
delays doof finde. Und anstatt hier doof rumzumaulen

>Welcher halbwegs intelligente Mensch benutzt DELAYS?

würde ich mich freuen, wenn ein solcher Kommentar mit einem Tipp 
versehen ist.

Blöd rumkacken kann jeder...

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Blöd rumkacken kann jeder...

Schon mal weiter gelesen?

MfG Spess

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

dann beantworte doch wenigstens die Frage wozu Du 700 Werte in einer 
Sekunde auf ein Display ausgeben willst!

Gruß aus Berlin
Michael

Autor: kurz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, na mal nicht so patzig.

Die Botschaft lautet: Delays sind hier eine schlechte Lösung (wie 
meistens, aber das geht in viele Hirne nicht rein)


So wie Du schreibst hast Du die Software selbst geschrieben und ab und 
an was abgeschaut.

Es kamen schon sehr vernünftige Vorschläge wie Timerinterrupt und 
Busy-Flag. War da nichts dabei? Kann fast nicht sein.

Also ran an den PC oder sonstwas Rechner und die Vorschläge in 
Programmzeilen gießen. Was hält Dich ab?

Autor: Matze Niemand (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nichts, ich war nur grad eine Rauchen.

Wie das mit dem TimerInterrupt  funktionieren soll, weiß ich noch nicht. 
Was das is, allerdings schon - auch schon häufig benutzt.
Das mit der Busy-Flag is na klasse Idee - hätt ich selber drauf kommen 
können :)
Problem daran is bloß, daß mein µC mit 3,3V arbeitet und ich für das 5V 
Display nen 74HCT244-Pegelwandler benutze, der leider nur in eine 
Richtung Wandeln kann: 3,3 -> 5,0 V

Zu meinem Tonfall: Sorry, ich sitze schon 7 Std am PC... Kommt nicht 
wieder vor!

Gruß

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst mit nem Spannungsteiler ganz einfach aus den 5V 3,3V machen. 
Sind nur 2 Widerstände.

Autor: kurz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem Timerinterrupt ist doch ganz einfach.

Im Hauptprogramm oder sonst wo bastelst Du Dir einen Ausgabestring 
zurecht, auf einem Array. Im Timerinterrupt gibst Du Byte für Byte an 
die Anzeige raus. Etwas Softwarehandshake zwischen Interrupt-Routine und 
Stringerstellung ist nötig.

- Stringlänge, Ausgabestelle in der Anzeige
- Flag für String fertiggestellt -> ausgeben im Interrupt
- Flag für String ausgegeben -> neuen erstellen im HP.

PC-Pause ist immer gut. Mach ich auch gleich wieder.

Autor: Matze Niemand (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, stimmt. Die Idee kam mir auch grad. Aber ich habe ein neues Problem.

Selbst wenn ich auf die Busy-Flag warte, warte ich doch auch. Das übrige 
Programm hängt dann auch und die Werte, die in dieser Zeit bekomme, kann 
ich dann auch nicht abarbeiten. Ich müßte, und das is jetzt nur 
gesponnen, ein paralleles abarbeiten von zwei getrennten strängen... 
einen zweiten processor sozusagen.
Moment, kann ich mein eingangssignal (ein I²C) auch an zwei µCs 
einlesen? Dafür bräuchten sie dann aber eine synchronisierte SCL... auch 
doof!

Tipps?

Autor: Matze Niemand (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu den Interrupts:

Du meinst, ich generiere ein Timer, der 1ms läuft. Dann greift er sich 
die volatile mit dem messwert und zwar nur das erste, halbe byte 
(4-Leitungs-Bus) überträgt es. danach den timer neu starten. dann das 
zweite, halbe byte. dann hat das hauptprogramm einen neuen Messwert 
errechnet, usw usw.
meinst du das so?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Welcher halbwegs intelligente Mensch benutzt DELAYS?

Ich z.B..

50µs Delay ist voll o.k., das machen 99% aller LCD-Routinen so und es 
ist überhaupt kein Rechenzeitproblem.

Er will ja nur 7 Werte a 5 Zeichen ausgeben, das sind dann also 1,8ms.

10ms Updaterate ist allerdings Schwachsinn.
Man sollte schon auf Ergonomie Wert legen, d.h. maximal 2..5 
Aktualisierungen pro Sekunde.

Bei 5 Aktualisierungen/s sind das also 1,8ms je 200ms, also riesige 
wahnsinns 0,9% CPU-Last!

Da ist es einfach nur lächerlich, auf den Delays rumzuhacken.
Das macht jede CPU mit links und 40 Fieber.


Peter

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm FreeRTOS, lass den LCD-Task mit niedriger Priorität laufen, benutze 
Multitasking-freundliche Wartefunktionen für ms-Delays (vTaskDelay
). Je komplexer das Projekt, desto eher lohnt sich FreeRTOS.

Autor: kurz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Selbst wenn ich auf die Busy-Flag warte, warte ich doch auch. Das übrige
>Programm hängt dann auch und die Werte, die in dieser Zeit bekomme, ..


Nix Warten - Busy abfragen geht anders:

Das Anzeigenprogramm liegt in der Hauptprogrammschleife.

- das Hauptprogramm kommt beim Anzeigenprogramm vorbei
- das ANZ-Porg fragt das Busy-Flag ab
    - Anzeige ist noch busy -> zurück ins HP weiter Messen, rechnen
                                                    Uart bedienen usw.

    - Anzeige ist ready -> ein Byte ausgeben -> zurück ins HP


Schon hast Du 2 Prozesse quasi parallel laufend.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dietmar schrieb:
> Nimm FreeRTOS, lass den LCD-Task mit niedriger Priorität laufen,

Dann kommst Du vom Regen in die Traufe.
Die 50µs Wartezeit wird warscheinlich schon ein Taskwechsel komplett 
aufbrauchen.
Für solche kleinen Wartezeiten ist ein RTOS ungeeignet.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und hier mal eine Interruptlösung:

Beitrag "Formatierte Zahlenausgabe in C"

Ich setze sie aber bisher nicht praktisch ein, war mehr ne Designstudie, 
obs geht.

Ich nehme die standard 50µs warten 4-Bit LCD Ansteuerung. Und ein 
Scheduler in der Mainloop ruft sie alle 200ms auf.


Peter

Autor: Matze Niemand (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich denke, ich habs:
- ich habe eben das Display an seine zeitlichen Grenzen gebracht - das 
hat ganzschön was gebracht.
- dann habe ich mir eben noch mal angeschaut, wie 3 Messwerte/s 
aussehen, und man sieht, daß 100 wirklich übertrieben waren.
- außerdem werde ich jetzt einen Timer entwerfen, der alle 50ms abläuft 
und werde dann einen messwert auf das LCD bannen (50ms * 7 = 350ms, also 
2,85 Aktuallsierungen / s)

Das mus reichen!

Danke für allen guten Ratschläge, ich bin wieder etwas schlauer!

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die 50µs Wartezeit wird warscheinlich schon ein Taskwechsel komplett 
aufbrauchen. Für solche kleinen Wartezeiten ist ein RTOS ungeeignet.

Er soll für die ms-Wartezeiten (5ms == 5000us), die bei bestimmten 
Befehlen anfalle, z.B. beim Clear-Befehl, das Multitasking-freundliche 
Delay nehmen. Der Task-Switching-Overhead spielt dabei keine 
erwähnenswerte Rolle. Das sind einige Dutzend us.

Die us-Wartezeiten programmiert er natürlich wie bisher als 
Busy-Waiting. Das wird durch das Multitasking entschärft: Der LCD-Task 
blockiert die CPU unter FreeRTOS nur bis zum nächsten Taskwechsel - der 
kommt z.B. in 1ms (oder wenn ein Interrupt einen höher prioritisierten 
Task aufweckt).

Insgesamt nimmt der LCD-Task so kaum Rechenleistung der CPU in Anspruch 
- ohne dass man grossartig nachdenken muss. Voraussetzung ist, dass das 
Display es nicht übel nimmt, wenn us-Pausen plötzlich länger dauern. 
Sollte bei 4bit so sein (ist bei meinem so - das blaue 16x2 von Pollin). 
Notfalls müsste man um bestimmte us-Delays herum das Task-Switching 
abstellen.

Ich verwende in meinem Programm so einen LCD-Task (und eine Mess-Task 
und einen InputHandler-Task usw.) und halte das für eine sehr angenehme 
Lösung. Die Tasks schicken sich über Queues Nachrichten zu - z.B. was 
anzuzeigen ist - und sind stark von voneinander entkoppelt. So kann man 
auch sehr komplexe Programme schreiben, ohne sich im Interrupt-Kleinkram 
zu vertüddeln.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich würde es so machen, leg dir einen puffer für dieser 5 Zeichen 
an. Starte einen Timer der alle 50ms eines der Zeichen auf das Display 
schreibt.
Dann brauchst du keine Wartezeit und über das Display brauchst du dir 
auch keine Gedanken machen sooo lange braucht kein Befehl.
Vorteil ist halt auch das du jederzeit und belibig oft/schnell auf 
diesen Buffer schreiben kanns von überall aus deinem Programm heraus.
Kann man natürlich auch auf das ganze LCD ausweiten .

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nutze seit einiger Zeit einen "Bildschirmspeicher" im AVR, in dem 
jede Byteposition einer Ausgabeposition entspricht. Das Hauptprogramm 
darf da dann jederzeit neue Texte reinschreiben.

Ein vom Timer-Interrupt über Flag synchronisierter Job der Mainloop 
schaufelt jede Millisekunde (neben anderen Aufgaben wie z.B. 
Drehgeberauswertung) ein Byte davon an das LCD und entwirrt dabei den 
Zeilenverschachtelungssalat.

Der Bildschirmspeicher hat also durchgehende Adressen und kann auch mit 
Fließtext beschrieben werden.

Achja, in einem 1ms-Takt werden beide Nibbles des Bytes geschrieben, 
eine Wartezeit zwischen beiden Nibbles ist nicht nötig.


In einem anderen Projekt (Bedienteil zum Parametrieren von 
Feuerwerks-Zündgeräten) mit Tiny2313 und LCD 4x40 (wo der SRAM nicht für 
einen Bildschirmspeicher reicht), habe ich das "Hauptprogramm" (Tasten 
abfragen, UART bedienen) in die Wartepausen des LCDs verlegt.

Ein Timer setzt alle 1ms ein Flag. Die Hauptschleife gibt in diesem Takt 
byteweise reihum eine Überschrift, 20 Parameter und einen 
kontextabhängigen Menütext aus, wobei der zu ändernde Parameter blinkend 
dargestellt wird. Statt Busywait oder Warteschleife werden hier die 
anderen Jobs des Programms ausgeführt, wie jedes 16. mal (alle 16 ms) 
Tasten entprellen, UART auf Empfang prüfen und Byte wegräumen, UART 
Senden, falls erforderlich und UDR leer ist.


Der optimale Lösungsweg ist immer auch etwas von der zu lösenden Aufgabe 
abhängig, eine Superlösung, die immer und überall optimal ist, wird es 
nicht geben.

...

Autor: Stefan M. (celmascant)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Antworten!

Da sind einige gute Anregungen dabei. Im nächsen Projekt werd ich die 
Interupt-LCD-Ansteuerung mal ausprobieren.

Eigendlich hätte ich da mit ein bisschen mehr Überlegung selbst drauf 
kommen können, auch auf das Busy-Flag...

Nochmal Danke^^

Gruss Stefan

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wo wir gerade schonmal bei interrupts und lcd sind :

mir ist da vor einiger zeit (ca nem jahr oder so) eine idee gekommen.
wenn man im timerinterrupt die 4-6 userdefinierbaren zeichen mit einem 
teil aus einem frame-buffer füllt, diese 4-6 zeichen auf einem display 
darstellt, im nächsten interrupt dann wieder 4-6 zeichen füllen und auf 
dem display ausgibt (also 4-6 zeichen weiter) und so weiter ... damit 
müssten sich doch auf einem text-display schon fast grafiken darstellen 
lassen können oder ? abgesehen von den zwischenräumen zwischen den 
zeichen und dadurch das immer nur teile der grafiken angezeigt werden 
dürfte die darstellung auch nicht allzu rosig aussehen, aber denkbar 
wäre es oder ? hat jemand sowas schonmal ausprobiert ?

Autor: Matze Niemand (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich auch wenn ich ein bißchen die euphorie nehme, aber ich habe heute 
versucht, das troggeln der e-Leitung per Busy-Flag zu lösen und ich habs 
nich geschafft, die einmal 10us und die 20us zu ersetzen - aber 
vielleicht war ich auch einfach nur zu blöd... auch die interruptroutine 
mußte deswegen bei mir je zeichen 60us warten... doofe sache.

Falls jemand die Zeiten beim KS0066U lösen kann, bitte ich um quelltext 
:)

Gruß und danke dennoch für alle klugen köpfe!

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TheMason schrieb:
> wo wir gerade schonmal bei interrupts und lcd sind :
>
> mir ist da vor einiger zeit (ca nem jahr oder so) eine idee gekommen.
> wenn man im timerinterrupt die 4-6 userdefinierbaren zeichen mit einem
> teil aus einem frame-buffer füllt, diese 4-6 zeichen auf einem display
> darstellt, im nächsten interrupt dann wieder 4-6 zeichen füllen und auf
> dem display ausgibt (also 4-6 zeichen weiter) und so weiter ... damit
> müssten sich doch auf einem text-display schon fast grafiken darstellen
> lassen können oder ? abgesehen von den zwischenräumen zwischen den
> zeichen und dadurch das immer nur teile der grafiken angezeigt werden
> dürfte die darstellung auch nicht allzu rosig aussehen, aber denkbar
> wäre es oder ? hat jemand sowas schonmal ausprobiert ?

Wenn ich mich recht entsinne, wirken sich geänderte Zeichen auch auf den 
bereits dargestellten Text aus. Es sind also nie mehr als acht 
verschiedene, zusätzliche Zeichen vorhanden.
Das Oszi auf dem Text-LCD (Siehe youtube) nutzt dieses "Feature", die 
Wellenform wird dabei nur über die anpassbaren Zeichen verändert, die 
aneinandergereiht den vollen "Bildschirm" von umwerfenden 8x40 Pixeln 
darstellen ;)

Bezieht sich jetzt alles auf HD44780-Displays.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>wirken sich geänderte Zeichen auch auf den
>bereits dargestellten Text aus.

das ist mir bewusst ;-) deswegen dachte ich auch daran (ok ich hatte es 
nicht dabei geschrieben) die nicht in dem aktiven "segment" 
darzustellenden zeichen einfach durch spaces ersetzen. das heißt zwar 
das man bei allen 4 partiellen-grafik-zeichen die dargestellt werden 
immer das komplette display leer schreiben muß und das dürfte sich auf 
die helligkeit bzw darstellung eben auswirken ... aber denkbar wäre es 
doch oder ?

ich pinsel das mal schematisch für ein 8x2 display auf

1.
"1111    "
"        "

2.
"    2222"
"        "

3.
"        "
"3333    "

4.
"        "
"    4444"

die zahlen 1-4 beziehen sich auf die zeichen im cg-ram die immer in 
vierer-gruppen aus dem frame-buffer kopiert werden.

ok. der nachteil an der lösung wäre das die helligkeit der einzelnen 
pixel auf 1/4 schrumpft da so oft umgeschaltet wird, aber das müsste man 
einfach mal austesten ...

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.