Hallo, Es wäre schön wenn mir hier jemand weiterhelfen könnte .... Und zwar liegt mein Problem im rjmp Befehl bzw. das mein Mikrocontroller ihn nicht richtig ausführt in Zeile 66 (Anhang) sollte er zur Marke start springen bin ich der Meinung. Stattdessen führt er mit Konstanter Boßhaftig keit auch die letzten drei Zeilen (Anhang 70-72)aus. Und setzt nur den Ausgang PORTB,2 wäre schön wenn mir jemand dazu einen Tipp geben könnte... vielen Dank schon mal im vorraus mfg Christian
Christian C. wrote: > Hallo, > > Es wäre schön wenn mir hier jemand weiterhelfen könnte .... > > Und zwar liegt mein Problem im rjmp Befehl bzw. das mein Mikrocontroller > ihn nicht richtig ausführt in Zeile 66 (Anhang) sollte er zur Marke > start springen bin ich der Meinung. Stattdessen führt er mit Konstanter > Boßhaftig keit auch die letzten drei Zeilen (Anhang 70-72)aus. Und setzt > nur den Ausgang PORTB,2 wäre schön wenn mir jemand dazu einen Tipp geben > könnte... > > vielen Dank schon mal im vorraus > > mfg Christian Also die Zeile 70 wird definitiv nie angesprungen! Kann es sein, dass du übersehen hast, dass die DDR-Register ebenfalls bereits bei Bit 0 und nicht erst bei Bit 1 anfangen, (hältst du dein Eingangssignal an die richtigen Pins?)?
Albrecht H. wrote: > Christian C. wrote: >> Hallo, >> >> Es wäre schön wenn mir hier jemand weiterhelfen könnte .... >> >> Und zwar liegt mein Problem im rjmp Befehl bzw. das mein Mikrocontroller >> ihn nicht richtig ausführt in Zeile 66 (Anhang) sollte er zur Marke >> start springen bin ich der Meinung. Stattdessen führt er mit Konstanter >> Boßhaftig keit auch die letzten drei Zeilen (Anhang 70-72)aus. Und setzt >> nur den Ausgang PORTB,2 wäre schön wenn mir jemand dazu einen Tipp geben >> könnte... >> >> vielen Dank schon mal im vorraus >> >> mfg Christian > > Also die Zeile 70 wird definitiv nie angesprungen! Kann es sein, dass du > übersehen hast, dass die DDR-Register ebenfalls bereits bei Bit 0 und > nicht erst bei Bit 1 anfangen, (hältst du dein Eingangssignal an die > richtigen Pins?)? Danke für die Schnelle Antwort, aber leider nicht habe Portb,0 Portb,1 und Portb,2 jeweils alle mit einer Leuchtdiode verbunden benutzte das myavr Board und habe eben auch nochmal ausprobiert die Leuchtdiode direkt an Pin 14, 15 und 16 zu halten, nur Pin 16 ist an :-( Aber wenigstens siehst Du das schon mal genauso das der da eigentlich nicht hinkommen darf lol. Könnte das auch am Compiler liegen ?? Das der da irgendwie mist macht ?? Mache das ganze unter Linux mit den AVR binutils das brennen habe ich auch schon mit dem AVR Quick prog versucht beide male mit dem gleichen Ergebnis nur Portb, 2 geht an. mfg christian
Christian C. wrote: > ... > halten, nur Pin 16 ist an :-( Aber wenigstens siehst Du das schon mal > genauso das der da eigentlich nicht hinkommen darf lol. Ich hab das im AVR-Studio4-Simulator laufen lassen und zumindest da funktioniert dein Programm schon so wie es soll, (nur vielleicht nicht unbedingt wie du es erwartest?), und Zeile 70 wird wirklich nicht angesprungen, habe da einen Breakpoint gesetzt, (nur für den Fall ...). > Könnte das > auch am Compiler liegen ?? Das der da irgendwie mist macht ?? Mache das > ganze unter Linux mit den AVR binutils Ist rein theoretisch natürlich immer möglich, aber ich glaube nicht, dass der Compiler einen Fehler macht, (zumal das ja eigentlich ein Assembler ist und es da wirklich nicht viel Interpretationsspielraum gibt). Ich habe auch erst vor kurzem mit den AVRs angefangen, (vorher 8051), und jedesmal wenn ich mir sicher war, dass da ein Fehler im System oder im Controller vorliegt, war es letztlich ein Denkfehler von mir. Wie schaltest du eigentlich die Porteingänge mit Masse oder mit +5V, (oder besser: Was glaubst du wie die geschaltet werden?), und wie sind deine LEDs angeschlossen, leuchten die bei 0 oder bei 1, (je nachdem wie du die angeschlossen hast musst du die nämlich mit 0 und nicht mit 1 einschalten)? Also leuchtet dann z.B. LED 1 nicht mit (0b00000010) sondern mit (0b11111101). Und bei den Eingängen ist es genau dasselbe Spiel, also wenn du da einen internen oder externen Pull-Up, (auf +5V oder was auch immer),dran hast musst du ja auf Eingang = Low und nicht auf Eingang = High prüfen. Tausch doch z.B. einfach mal die "sbrs"-Befehle gegen "sbrc" aus, (und schau ob dann wenigstens "invertiert betrachtet" deine LEDs so leuchten wie sie sollen). Eigentlich ist es nicht sonderlich kompliziert, aber ich muss auch immer kurz innehalten und nachdenken, was ich am Eingang anlegen muss, (also Masse oder +5V), damit sich der Zustand des Eingangspins auch tatsächlich ändert, (also wenn der schon auf +5V liegt, kann ich lange versuchen den auf High zu bringen, da wird sich gar nichts tun, weil er ja schon auf High ist, (oder umgekehrt)). Also! Schreib zwei ganz kurze Progrämmchen: 1. Eines mit dem du testest ob deine LEDs mit 0 oder 1 Leuchten, (vermutlich mit 0). 2. Eines mit dem du sicherstellen kannst, dass du ein High oder Low am Eingangspin auch wirklich richtig interpretierst und nicht nur glaubst das zu tun! Und vergiss nicht dass die Eingänge des AVRs immer prellen werden, also wenn du an einen Eingangspin z.B. Masse anlegst wird noch mindestens 30 mal vorher der der Zustand des Pull-Up oder Pull-Down Widerstands anliegen bevor wirklich endgültig Masse anliegt. > das brennen habe ich auch schon > mit dem AVR Quick prog versucht beide male mit dem gleichen Ergebnis nur > Portb, 2 geht an. > > mfg christian
Guten Morgen :-) > Wie schaltest du eigentlich die Porteingänge mit Masse oder mit +5V, > (oder besser: Was glaubst du wie die geschaltet werden?), und wie sind > deine LEDs angeschlossen, leuchten die bei 0 oder bei 1, (je nachdem wie > du die angeschlossen hast musst du die nämlich mit 0 und nicht mit 1 > einschalten)? Also leuchtet dann z.B. LED 1 nicht mit (0b00000010) > sondern mit (0b11111101). Meine Porteingänge werden mit Tastern auf 0V gezogen darum werden auch die internen Pull up s eingeschaltet. Die Leuchtdioden werden mit 5V eingeschaltet und leuchten wenn diese Spannung anliegt, über einen 1kOhm Vorwiderstand. > Also! > Schreib zwei ganz kurze Progrämmchen: > > 1. Eines mit dem du testest ob deine LEDs mit 0 oder 1 Leuchten, > (vermutlich mit 0). > > 2. Eines mit dem du sicherstellen kannst, dass du ein High oder Low am > Eingangspin auch wirklich richtig interpretierst und nicht nur glaubst > das zu tun! So das Progrämmchen zum testen ist im Anhang und funktioniert auch Fabelhaft (Also Leuchtdiode über Taster einschalten), bis die drei Zeilen wieder darunter kommen, schon geht die Leuchtdiode (dies mal halt an PORTC)wieder an :-( Danke für Deine Bemühungen, ist das Programm mit dem du das getestet hast irgendwo frei Verfügbar ? mfg Christian
Christian C. wrote: > Guten Morgen :-) > >> ... > > Meine Porteingänge werden mit Tastern auf 0V gezogen Schön, aber musst du dann nicht auf "0" testen also "sbrs" gegen "sbrc", (Skip bei nicht gesetztem Bit), tauschen? > darum werden auch > die internen Pull up s eingeschaltet. > Die Leuchtdioden werden mit 5V > eingeschaltet und leuchten wenn diese Spannung anliegt, über einen 1kOhm > Vorwiderstand. Schon klar, aber was musst du auf deinem Port ausgeben, damit eine LED leuchtet eine "1" oder eine "0"? > Ah, schau mal hier steht doch alles, sogar für den Mega8: http://www.mikrocontroller.net/articles/AVR-Tutorial:_IO-Grundlagen Das asm-Programm unter der Überschrift "Eingabe" und das unter der Überschrift "Pullup-Widerstand". Also, da wird die LED mit 0 geschaltet und die Eingabepins werden auf 0 getestet, du hast es bei deinem ersten Programm genau umgekehrt gemacht. > > So das Progrämmchen zum testen ist im Anhang und funktioniert auch > Fabelhaft (Also Leuchtdiode über Taster einschalten), bis die drei > Zeilen wieder darunter kommen, schon geht die Leuchtdiode (dies mal halt > an PORTC)wieder an :-( ldi r17,0b00000100 mov r16,r17 out PORTC,r17 warum kopierst du r17 nach r16, wenn du dann doch r17 ausgibst? (Außerdem müssten so an Port C alle LEDs leuchten bis auf die dritte). > > Danke für Deine Bemühungen, ist das Programm mit dem du das getestet > hast irgendwo frei Verfügbar ? AVR-Studio4 gibts kostenlos zum runterladen bei Atmel, (eventuell Registrierung erforderlich), ist aber für Windows, keine Ahnung ob das unter Linux z.B. mit Wine läuft. > > mfg Christian
Albrecht H. wrote: > Schon klar, aber was musst du auf deinem Port ausgeben, damit eine LED > leuchtet eine "1" oder eine "0"? Ich muss am Port eine "1" ausgeben damit eine LED leuchtet, mein Problem liegt eigentlich auch viel mehr darin das er immer die letzten Zeilen noh ausführt obwohl er davor wieder zu start springen müsste. > >> >> So das Progrämmchen zum testen ist im Anhang und funktioniert auch >> Fabelhaft (Also Leuchtdiode über Taster einschalten), bis die drei >> Zeilen wieder darunter kommen, schon geht die Leuchtdiode (dies mal halt >> an PORTC)wieder an :-( > > > ldi r17,0b00000100 > mov r16,r17 > out PORTC,r17 > > > warum kopierst du r17 nach r16, wenn du dann doch r17 ausgibst? > (Außerdem müssten so an Port C alle LEDs leuchten bis auf die dritte). > mache ich nur weil ich eigentlich noch mit r17 ein bisschen rechnen will das habe ich nur zur Fehlersuche rausgebaut damit ich da beim rumrechnen keinen Fehler einbaue. > > AVR-Studio4 gibts kostenlos zum runterladen bei Atmel, (eventuell > Registrierung erforderlich), ist aber für Windows, keine Ahnung ob das > unter Linux z.B. mit Wine läuft. > So Software habe ich mir runtergeladen werde ich gleich mal testen >> >> mfg Christian
Christian C. wrote: > Albrecht H. wrote: > >> Schon klar, aber was musst du auf deinem Port ausgeben, damit eine LED >> leuchtet eine "1" oder eine "0"? > > Ich muss am Port eine "1" ausgeben damit eine LED leuchtet, Ok, dann mach doch mal ein Schaltbild hier rein wie du die LED genau angeschlossen hast. > mein Problem > liegt eigentlich auch viel mehr darin das er immer die letzten Zeilen > noh ausführt obwohl er davor wieder zu start springen müsste. > > Das bezweifle ich immer noch. > >...
Hey Christian, also zu Beginn ist ein Fehler in der Initialisierung. Du beginnst den Programmspeicher bei $0 (.org $0) dann folgen bei dir 2x rjmp main. Wenn du dir nen Disassembler ansiehst, steht beim IRQ-Vector2 auch ein rjmp main drin. Also obacht. Hab das entfernt und dein Testprogramm läuft bei mir einwandfrei. Die zustände am PB0 werden entsprechend dem Eingang PB1 belegt. Da ich mit AVR Studio arbeite habe ich dein .include "avr.h" entfernt. Verstehe ich nicht ganz, warum bei dir ne Header-Datei drinne steht, obwohl du ASM machst. Im Studio heißt die .include "M8def.inc" Gruß Alexander
Hab dein Hauptprogramm gestestet und das geht auch sehr gut. Genau die Funktion, die du haben willst. (Änderung des Startvektor und Include-File). Kannst ja mal die HEX-Datei laden, mit der sollte es funktionieren, ansonsten Hardwarefehler. Alexander
1 | .include "M8def.inc" |
2 | |
3 | .org 0 |
4 | |
5 | |
6 | |
7 | |
8 | ;--- Reset and Interrupt vector ---- ;VNr. Beschreibung ----- |
9 | |
10 | |
11 | rjmp main ;1 POWER ON RESET |
12 | reti ;2 Int0-Interrupt |
13 | reti ;3 Int1-Interrupt |
14 | reti ;4 TC2 Compare Match |
15 | reti ;5 TC2 Overflow |
16 | reti ;6 TC1 Capture |
17 | reti ;7 TC1 Compare Match A |
18 | reti ;8 TC1 Compare Match B |
19 | reti ;9 TC1 Overflow |
20 | reti ;10 TC0 Overflow |
21 | reti ;11 SPI, STC Serial Transfer Complete |
22 | reti ;12 UART Rx Complete |
23 | reti ;13 UART Data Register Empty |
24 | reti ;14 UART Tx Complete |
25 | reti ;15 ADC Conversion Complete |
26 | reti ;16 EEPROM Ready |
27 | reti ;17 Analog Comparator |
28 | reti ;18 TWI (IC) Serial Interface |
29 | reti ;19 Store Program Memory Ready |
30 | |
31 | |
32 | |
33 | |
34 | main: sbi DDRB,0 ; DDRB,0 als Ausgang initialisieren |
35 | sbi DDRB,1 ; DDRB,1 als Ausgang initialisieren |
36 | sbi DDRB,2 ; DDRB,2 als Ausgang initialisieren |
37 | |
38 | cbi DDRD,2 ; DDRB,2 als Eingang initialisieren |
39 | sbi PORTD,2 ; Pull Up Widerstand einschalten |
40 | cbi DDRD,3 ; DDRB,3 als Eingang initialisieren |
41 | sbi PORTD,3 ; Pull Up Widerstand einschalten |
42 | |
43 | ldi r17,0b00000000 ; lade 0b00000000 in Register 17 |
44 | |
45 | |
46 | start: in r18,PIND ; Lese Register 18 ein und schiebe es in Register 18 |
47 | sbrs r18,2 ; Überspringe nächsten Befehl wenn Register 18, Bit 2 gesetzt ist |
48 | rjmp unten ; springe zu Marke unten |
49 | |
50 | sbrs r18,3 ; Überspringe nächsten Befehl wenn Register 18, Bit 3 gesetzt ist |
51 | rjmp oben ; springe zu Marke oben |
52 | rjmp start ; springe zu Marke start |
53 | |
54 | |
55 | unten: ldi r17,0b00000010 ; lade 0b00000010 in Register 17 |
56 | mov r16,r17 ; verschiebe den Inhalt von Register 17 in 16 |
57 | out PORTB,r16 ; gebe Register 16 an Port B aus |
58 | rjmp start ; springe zu Marke start |
59 | |
60 | oben: ldi r17,0b00000001 ; lade 0b00000001 in Register 17 |
61 | mov r16,r17 ; verschiebe den Inhalt von Register 17 in 16 |
62 | out PORTB,r16 ; gebe Register 16 an Port B aus |
63 | rjmp start ; springe zu Marke start |
64 | |
65 | |
66 | //Diese 3 Zeilen werden nie erreicht!!!! |
67 | ldi r17,0b00000100 ; lade 0b00000100 in Register 17 |
68 | mov r16,r17 ; verschiebe den Inhalt von Register 17 in 16 |
69 | out PORTB,r16 ; gebe Register 16 an Port B aus |
Albrecht H. wrote: > Christian C. wrote: >> Albrecht H. wrote: >> >>> Schon klar, aber was musst du auf deinem Port ausgeben, damit eine LED >>> leuchtet eine "1" oder eine "0"? >> >> Ich muss am Port eine "1" ausgeben damit eine LED leuchtet, > > Ok, dann mach doch mal ein Schaltbild hier rein wie du die LED genau > angeschlossen hast. So das Gesamte Schaltbild ist im Anhang und auf Seite 3 im .pdf zu finden > >> mein Problem >> liegt eigentlich auch viel mehr darin das er immer die letzten Zeilen >> noh ausführt obwohl er davor wieder zu start springen müsste. >> >> > Das bezweifle ich immer noch. >> >>... Mit der .hex von Alexander funktioniert es alles :-) werde mich da jetzt mal auf die suche begeben wo das Problem beim Code - hex erstellen liegt er benutzt eine andere Datei ... mfg christian
Alexander Liebhold wrote: Hallo Alexander :-) jetzt bin ich erstmal erleichtert das mein Programm so funktioniert wie es soll, also mit deiner Hex Datei jedenfalls (ich habe schon gedacht ich drehe durch lol) > Hey Christian, > > also zu Beginn ist ein Fehler in der Initialisierung. Du beginnst den > Programmspeicher bei $0 (.org $0) dann folgen bei dir 2x rjmp main. Wenn > du dir nen Disassembler ansiehst, steht beim IRQ-Vector2 auch ein rjmp > main drin. Also obacht. Hab das entfernt und dein Testprogramm läuft bei > mir einwandfrei. Die zustände am PB0 werden entsprechend dem Eingang PB1 > belegt. Diesen Programmkopf habe ich so bekommen und die anderen Programme ohne Sprünge liefen so auch immer ohne Probleme von daher habe ich mir ehrlich gesagt keine weiteren gedanken dazu gemacht. Da das compilieren und programmieren bis auf dieses Problem bisher super funktionierte ... > > Da ich mit AVR Studio arbeite habe ich dein .include "avr.h" entfernt. > Verstehe ich nicht ganz, warum bei dir ne Header-Datei drinne steht, > obwohl du ASM machst. Im Studio heißt die .include "M8def.inc" Wie man sieht hatte ich mich da wohl zu früh gefreut, werde mich jetzt also mal selbst daran machen und nachschauen was der compiler da genau anstellt bzw. was da fehlschlägt und ob er vielleicht auch mit der M8def.inc zurechtkommt falls ich die finde. In der AVR.H stehen z.B. die Bit Definitionen also sowas wie PORTB = Adresse 0x.. hab sie mal mit angehängt. Ansonsten warte ich mal auf den Registrierungscode für das AVR Studio 4 und hoffe das ich dazu bald eine Lösung finde besten Dank schon mal für deine Bemühungen mfg christian
Hi
>selbst daran machen und nachschauen was der compiler da genau anstellt...
Das ist ein Assembler, kein Compiler.
MfG Spess
Albrecht H. wrote: > Christian C. wrote: >> Albrecht H. wrote: >> >>> Schon klar, aber was musst du auf deinem Port ausgeben, damit eine LED >>> leuchtet eine "1" oder eine "0"? >> >> Ich muss am Port eine "1" ausgeben damit eine LED leuchtet, > Ok, so wie das auf deinem Board verschaltet ist, (hättest gleich den Schaltplan mit dranhängen sollen), macht das natürlich Sinn die LEDs mit "1" einzuschalten, im Gegensatz zu einigen anderen Mikrocontrollern, (mit Open-Collector-Ausgang), kann der Atmega ja auch einigermaßen gut "sourcen", (also Verbraucher mit Strom versorgen, anstatt sie nur auf Masse zu ziehen). Bei meinem Test im AVR-Studio habe ich, (da mir die AVR.H ja nicht zur Verfügung stand), standardmäßig, .include "m8def.inc", verwendet. Das erste "begin: rjmp main" hatte ich auch entfernt, nicht unbedingt weil es mir gleich als Fehler auffiel, sondern eher weil ich es überflüssig fand. Einerseits, dadurch, dass da am Anfang zweimal hintereinander "rjmp main" steht, stand es ja einmal im Reset-Vektor und einmal im INT0-Vektor, (externer Interrupt), und der wird ja durch PIND2 ausgelöst, den du als Eingang deklariert hattest. Andererseits, da du den INT0 erst einschalten musst bevor er irgendwas macht, (Defaultzustand ist laut Datenblatt ausgeschaltet), hat das zweite "rjmp main" gar nichts bewirkt, nichts gutes aber auch nichts schlechtes. Wie auch immer, darauf hatte ich gar nicht geachtet, weil ich immer davon ausging, das Problem wäre, dass du die LEDs wie im Tutorial-Beispiel angeschlossen hättest, und versuchen würdest sie mit "1" anstatt "0" zu schalten ... > ... >> mein Problem >> liegt eigentlich auch viel mehr darin das er immer die letzten Zeilen >> noh ausführt obwohl er davor wieder zu start springen müsste. >> >> > Das bezweifle ich immer noch. >> >>...
Im Grunde steht schon das Gleiche in der AVR.h, nur das sich da halt jemand mit seinen Namen schmückt. Das AVR Studio mit allen Definitionsfiles ist doch kostenlos und du kannst die Hex-Files mit jedem Programmer laden. Ich bin sehr zufrieden damit, vorallem mit dem Zusatzprogramm WinAVR für C. Anbei die Datei. Gruß Alex
Albrecht H. wrote: Guten morgen!! > Ok, so wie das auf deinem Board verschaltet ist, (hättest gleich den > Schaltplan mit dranhängen sollen), macht das natürlich Sinn die LEDs > mit "1" einzuschalten, im Gegensatz zu einigen anderen Mikrocontrollern, > (mit Open-Collector-Ausgang), kann der Atmega ja auch einigermaßen gut > "sourcen", (also Verbraucher mit Strom versorgen, anstatt sie nur auf > Masse zu ziehen). Ja, das stimmt hatte gehofft das du es mir auch so glaubst ;-) Habe das mit dem AVR Studio nochmal ausprobiert selbst zu bauen und dann funktioniert auch alles so wie es soll freu muß malsehen wann ich dazu komme mir das unter Linux fertig zumachen mfg christian
Alexander Liebhold wrote: > Im Grunde steht schon das Gleiche in der AVR.h, nur das sich da halt > jemand mit seinen Namen schmückt. Das AVR Studio mit allen > Definitionsfiles ist doch kostenlos und du kannst die Hex-Files mit > jedem Programmer laden. Ich bin sehr zufrieden damit, vorallem mit dem > Zusatzprogramm WinAVR für C. > Habe das ganze gestern auch mal mit dem AVR Studio gemacht und war sehr zufrieden vorallem weil es dann funktionierte gg und er nicht mehr an den Sprungmarken vorbei rennt > Anbei die Datei. > Danke für die Datei die sehen sich wirklich recht ähnlich nur mein avr-as kommt damit nicht zurecht. Schade eigentlich, werde jetzt erstmal die Programme mit dem Studio erstellen hat auch die besseren debug Funktionen wenn ich rausgefunden habe was an dem avr-as bzw. der avr.h nicht funktioniert werde ich das hier nochmal reinstellen hätte die nur gerne benutzt weil wir die in unserer Fachhochschule auch verwenden also nochmal vielen Dank und man liest sich bestimmt demnächst nochmal wieder :-) mfg christian
Na wunderbar! Du kannst den Inhalt der AVR.h mal in ne Textdatei meinetwegen MyM8def.inc ablegen und in den Ordner (glaub es ist programm/atme/atme tools/avr assembler/app notes/) kopieren. Einfach im Programm dann abändern und mal testen. So könntes gehen.
Alexander Liebhold wrote: > Na wunderbar! Du kannst den Inhalt der AVR.h mal in ne Textdatei > meinetwegen MyM8def.inc ablegen und in den Ordner (glaub es ist > programm/atme/atme tools/avr assembler/app notes/) kopieren. > > Einfach im Programm dann abändern und mal testen. > > So könntes gehen. Nabend Alex :-) das rüber kopieren habe ich eben mal versuch damit kann das AVR Studio dann nichts mehr anfangen ...die m8def.inc gibt es zweimal für Assembler / Assembler2, verschiedene Bausteintypen werde also das Studio benutzen und mal schauen wie sich das ganze im Labor verhält. Ist auf alle Fälle schon mal sehr schön das es jetzt so geht In C gehts übrigens auch in Linux ohne Problme .... Aber erstmal bleibe ich jetzt beim Assemblieren he he mfg christian
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.