Forum: Mikrocontroller und Digitale Elektronik C++ auf AVR wie gehts?


von Luk (Gast)


Lesenswert?

Hallo
ich möchte mir ein C++ Programm für meinen Atmega 16 schreiben
und das am besten dann mit hilfe des JTAGICE mk2 debuggen usw.
Ich muss im Juli C++ an der Uni ablegen und wollte mir die graue Theorie
mit etwas Hardware versüssen. Gibt es da ne möglichkeit?
DAnke

von Der kleine Jimmy (Gast)


Lesenswert?

Das Programmieren geht zwar einigermaßen, aber dem Debuggen stehe ich 
skeptisch gegenüber. Du kannst dir einen avr32 zulegen, damit kannst du 
C++ Programmieren ohne auf den JTAGICE mk2 verzichten zu müssen.

Wenn du unbedingt mit sichtbaren Ergebnissen C++ lernen willst, wieso 
fängst du nicht mit OpenGL oder DirectX auf einem PC an?

von Simon K. (simon) Benutzerseite


Lesenswert?

Der ATmega16 hat auch ein JTAG Debug Interface.

von Der kleine Jimmy (Gast)


Lesenswert?

Ja, aber soweit ich weiß gibts keine IDE die das Debuggen von c++ auf 
AVRs unterstützt.

von Sven P. (Gast)


Lesenswert?

C++ auf dem AVR ist unsinnig, dafür sind die AVR viel zu klein.
Es geht schon, aber es bringt halt unterm Strich nix.

von Kupfer Michi (Gast)


Lesenswert?

>C++ auf dem AVR ist unsinnig ...

Na, dann hast du wohl noch nicht viel C++ auf einem Atmega AVR gemacht?

>... dafür sind die AVR viel zu klein.

Wer erwarted, auf einem 8KB AVR mit 1KB SRAM die C++ Standard 
Biobliotheken & Klassen einsetzten zu können, oder auch nur genauso wie 
auf einem 2GHz 1GB PC Programmieren zu können, wird natürlich kläglich 
Schiffbruch erleiden.

Wer jedoch die verschieden Grundkonzepte und Sprachkonstrukte von C++ 
wirklich verstanden hat und sich angeschaut hat was der jeweilige 
Compiler dafür an ASM Code ausspuckt, der wird auch C++ gewinnbringend 
auf einem AVR einsetzten können.

ASM ist mühsam, C ist und bleibt ein gefrickel und mit C++ kommt 
wenigstens etwas glanz und Komfort in die Hütte.

Allerdings Programmieren lernen auf dem AVR, egal ob mit ASM oder C++, 
das tuns sich nur die wahren Masochisten an...

von Sven P. (Gast)


Lesenswert?

Naja, welche Vorteile spielt denn C++ auf dem AVR aus? Templates -> zu 
dick. Standardbibliothek -> zu dick. Klassen -> vielleicht. Dynamische 
Speicherverwaltung -> ist schon mit malloc() zu fett.

Ich gestehe aber offen ein, dass ich nicht viel mit C++ mache.

von netb (Gast)


Lesenswert?

@Sven:

Neben den ganzen dynamischen Schnick-Schnack der bei C++ besonders gerne 
benutzt wird (der aber nicht zwangläufig benutzt werden muss) hat C++ 
gegenüber reinem C einen ganz großen Vorteil: Bessere Lesbarkeit des 
Codes.

Wenn man die C++ Mittel mit Bedacht einsetzt, kann man einen wesentlich 
schöneren Code mit C++ erzeugen als mit C. Man kann einfach etwas 
schöner Strukturierenen.

Klar, das sind alles keine Argumente weswegen man unbedingt C++ 
einsetzen muss, aber wer nach 2 Jahren sich den eigenen Code noch einmal 
ansehen muss der freut sich, wenn statt irgendwelchem kryptischen Code 
hat man einen Operator geschickt überladen und einen leichter 
verständlichen Code. Ist eben Geschmacksache...

Auf jeden Fall sollte man bei C++ und AVR aufpassen welche Elemente man 
benutzt und welche nicht. Virtuelle Methoden und dynamische Objekte, 
sind eben mit Vorsicht zu genießen. Das gilt aber genauso für C und 
malloc.

Wenn es wirklich nur um das Lernen von C++ angeht, würde ich abraten, 
dies auf einem µC zu machen. Dann lieber am PC C++ lernen, dort hat man 
andere Randbedingungen und kann die Möglichkeiten von C++ voll 
ausschöpfen ohne Ständig an Speichergrenzen und so zu denken.

von Sven P. (Gast)


Lesenswert?

netb wrote:
> @Sven:
> gegenüber reinem C einen ganz großen Vorteil: Bessere Lesbarkeit des
> Codes.
Wodurch das denn? Also ich meine, spontan fallen mir da Referenzen und 
Überladerei ein, wobei man mit beidem auch Schindluder treiben kann -- 
genauso wie man mit C sauberen Code schreiben kann.
Wie auch immer.

> [...]
Joa, wobei ich überladene Operatoren nicht unbedingt lesbarer halte, das 
birgt ja auch wieder Risiken in sich.

> Wenn es wirklich nur um das Lernen von C++ angeht, würde ich abraten,
Das sowieso, gar keine Frage.

von Kupfer Michi (Gast)


Lesenswert?

>Naja, welche Vorteile spielt denn C++ auf dem AVR aus? Templates -> zu
>dick. Standardbibliothek -> zu dick. Klassen -> vielleicht. Dynamische
>Speicherverwaltung -> ist schon mit malloc() zu fett.

Sag ich ja, vergiss alle Unarten an C++/Objektorientierter 
Programmierung die du auf dem PC gelernt hast und schau dir jedes 
Sprachkonstrukt von C++ genau an ob du es auf dem AVR verwenden kannst.

Mühsam aber es lohnt sich, denn wenn die Alternative C heisst, gibt es 
in C++ nichts was das Programmieren zwingend ineffizienter oder mühsamer 
macht, aber jede Menge Features, die wohl überlegt eingesetzt, einem das 
Leben leichter machen.

von Sven P. (Gast)


Lesenswert?

Kupfer Michi wrote:
> Mühsam aber es lohnt sich, denn wenn die Alternative C heisst, gibt es
> in C++ nichts was das Programmieren zwingend ineffizienter oder mühsamer
> macht, aber jede Menge Features, die wohl überlegt eingesetzt, einem das
> Leben leichter machen.
Welche denn dann?

von Kupfer Michi (Gast)


Lesenswert?

>> macht, aber jede Menge Features, die wohl überlegt eingesetzt, einem das
>> Leben leichter machen.

>Welche denn dann?

Ja bekommst du denn z.B. mit Sprachkonstrukten wie Klassen und Templates 
deine Programme nicht aufgeräumter und effizienter hin?

Gerade Templates ermöglichen sehr effiziente Variantenprogrammierung, 
die helfen auch das letzte bisschen an Speicher und Laufzeit Overhead 
aus deinem Programm herauszukompilieren.

Wenn das auf dem AVR nicht wichtig ist, was dann?
Mann mag sich ja garnicht anschauen, wie da die C Fraktion versucht, mit 
#defines und Preprozessor Gewürge, etwas vergleichbares hinzubekommen.

von (prx) A. K. (prx)


Lesenswert?

Sven P. wrote:

> Naja, welche Vorteile spielt denn C++ auf dem AVR aus?

Saubere Modularisierung beispielsweise. Hat eher ästhetische Relevanz, 
kostet aber wenig.

Vereinheitlichung von Sensoren gleicher Klasse aber verschiedener 
Arbeitsweise lässt sich prima über abgeleitete Klassen einer Basisklasse 
und virtuelle Funktionen realisieren. So beispielsweise 
Temperatursensoren, die sicherheitshalber teils digital (DS18x20) teils 
analog (LM335) realisiert wurden. Nutzen ist gross, zusätzlicher Aufwand 
gering.

Es hängt allerdings von der Architektur ab, wie gut sich typische C++ 
Sprachkonstrukte umsetzen lassen. Ziemlich wichtig ist dabei die 
Möglichkeit, relativ zu einem Pointer adressieren zu können. Bei AVR 
oder MSP430 ist das einfach, ein 8051 hingegen muss jedesmal die Adresse 
zu Fuss ausrechnen.

> Templates -> zu dick.

Nein. Beispiele in denen ich C++ Templates verwendet habe:

- Generische Klasse für Ringpuffer zwischen Anwendung und Interface, 
verwendbar für beispielsweise UART (oder CAN, ...). Ist nicht viel 
erzeugter Code dahinter und der vervielfacht sich auch bei mehreren 
Interfaces gleichen Typs nicht weil:

- Interface-Modul für beispielsweise UART, in dem die Datenpuffer (s.o.) 
für jeden UART-Kanal statisch gespeichert werden. Ich verwendet bei 
Controllern nur sehr ungern dynamischen Speicher, weil sich statischer 
Speicherverbrauch besser kalkulieren lässt. Der Code steckt zu 95% in 
einer nicht generischen für alle UART-Kanäle verwendbaren Basisklasse, 
vervielfacht sich bei mehreren Kanälen nicht. Über das Template werden 
nur Häppchen relevant für Initialisierungsparametrisierung und ggf. 
Interruptabhängigkeiten vervielfacht.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Dieses ganze Blablabla "C++ auf dem AVR ist besser, weil ..." ist doch 
Bockmist.

Der Grund warum Leute C++ auf dem AVR verwenden wollen ist, weil sie 
nichts anderes kennen und können. Dazu werden dann stundenlang Ausreden 
wie "ist besser lesbar" oder "hat ganz tolle Features" an den Haaren 
hergezogen.

Einmal, nur ein einziges Mal möchte ich von den C++-Jammerern hören "ich 
verwende C++ weil ich es nicht besser kann oder weiß". Das wäre einmal 
nicht gelogen. Nur die Java-Typen sind noch schlimmer.

Wir reden hier von MCUs mit lächerlichen Speichergrößen. Nichts, absolut 
nichts, was C++ wirklich interessant macht (z.B. STL oder RTTI) lässt 
sich auf einem AVR sinnvoll in Stellung bringen. Das ist wie der Versuch 
mit einem Vorschlaghammer zu arbeiten, bei dem man den Stiel nicht 
verwenden kann.

Im besten Fall, beim größten AVR lassen sich vielleicht ein paar tausend 
Zeilen C in einen AVR quetschen. Wie man bei so ein paar lächerlichen 
Zeilen Code den Überblick verlieren kann und warum das mit C++ nicht 
passieren soll verstehe ich nicht. Wer in ein paar tausend Zeilen C 
keine Ordnung halten kann, der programmiert auch in C++ nur Scheiße. Wem 
von so ein paar Zeilen C schwindelig wird, der sollte sich vielleicht 
nach einem anderen Job umsehen.

von let (Gast)


Lesenswert?

Gibt es Leute die C++ aber kein C sprechen können?

von (prx) A. K. (prx)


Lesenswert?

Um mal Zahlen zu bringen: Quelltext eines Programms inklusive Includes 
(bei C++ durchaus relevant) = 7800 Zeilen, eher sparsam kommentiert. Nur 
gehört der verwendete Mega32 nicht wirklich zu den Monstern.

Weder will ich jemanden zu C++ überreden, noch halte ich das für es 
Nonplusultra (mein erster Eindruck, als diese Sprache noch recht frisch 
war, lässt sich nicht magenfreundlich ausdrücken). Ich verstehe bloss 
nicht, warum ich angesichts dessen Verfügbarkeit auf die nützlichen 
Aspekte von C++ verzichten soll. Ich mache das ja nicht beruflich, sonst 
wäre evtl. relevant, dass viele kommerzielle Compiler nur für C 
existieren.

von Michael G. (linuxgeek) Benutzerseite


Lesenswert?

Sven P. wrote:
> C++ auf dem AVR ist unsinnig, dafür sind die AVR viel zu klein.
> Es geht schon, aber es bringt halt unterm Strich nix.

ACK. Ausserdem ist C++ nur mit Einschraenkungen verwendbar, es steht 
also nicht der gesamte Sprachumfang und die library zur Verfuegung. In 
C++ kann man seine Programme so leicht aufblasen (code bloat) dass sie 
in keinen AVR mehr passen.

von (prx) A. K. (prx)


Lesenswert?

Michael G. wrote:

> C++ kann man seine Programme so leicht aufblasen (code bloat) dass sie
> in keinen AVR mehr passen.

Ack. Wobei ich eine recht gute Vorstellung davon habe, wie gut oder 
schlecht sich Code umsetzen lässt. Man muss schon mit der Schere im Kopf 
programmieren, sonst wird das nix.

Wobei das in reduziertem Umfang auch für C gilt. Schon mancher wurde vom 
Codeverbrauch durch Fliesskommarechnung überrascht. Und bei 
Architekturen, die sich mit Stackframes etwas schwer tun (z.B. 8051 und 
8bit PICs einschliesslich älterer PIC18), ist es ebenfalls ziemlich 
hilfreich, um deren Schwächen sorgsam herumzuprogrammieren. Auch da ist 
also diese Schere angebracht.

von Michael G. (linuxgeek) Benutzerseite


Lesenswert?

Ich will ja nicht sagen dass es garnicht geht. Aber C++ ohne "new"... 
naja ;) Wenn danach 70% des Codes doch wieder reines C ist, weil auch 
fast alle libs fuer den AVR in reinem C geschrieben sind kann man ja 
gleich bei C bleiben.

von netb (Gast)


Lesenswert?

Naja, ich sehe schon. Diese Diskussion gleitet mal wieder in religiöses 
Gehabe ab. Ein Wunder, dass hier noch nicht jemand behauptet hat, dass 
man mit dem Vi einen, für µCs, besseren Code schreiben kann als mit 
emacs...

Nahezu jedes C Programm kann problemlos mit einem C++ Compiler übersetzt 
werden. Daher spricht nichts dagegen, sich an geeigneter Stelle 
bestimmter C++ Sprachkonstrukte zu bedienen, um damit die Lesbarkeit zu 
erhöhen.

Falls jemand der Meinung ist, dass er C Code grundsätzlich schneller und 
besser (nach 2 Jahren) wieder lesen kann als C++ Code, dann spricht doch 
nichts dagegen einfach C Code zu schreiben. Falls man dann doch mal 
einen Operator überladen möchte, dann macht man das einfach... der Rest 
bleibt halt C.

Das kommt eben auf die persönlichen Vorlieben eines jeden Entwicklers 
an, aber pauschal zu sagen, dass C++ und µC nicht zusammen passt ist 
schlichtweg dumm.

von Kupfer Michi (Gast)


Lesenswert?

>Ausserdem ist C++ nur mit Einschraenkungen verwendbar, es steht
>also nicht der gesamte Sprachumfang und die library zur Verfuegung

Lustige Logik: Nur weil ich nicht ALLES verwenden kann, verzichte ich 
gleich in Bausch und Bogen auch auf die nützlichen Dinge? - Also ich 
gehe da pragmatischer vor.

>In C++ kann man seine Programme so leicht aufblasen (code bloat) dass sie
>in keinen AVR mehr passen.

Tja, sollte man beim Programmieren eines AVR nicht generell wissen was 
man tut? Gilt das selbe Argument nicht auch gegenüber C, wenn ich mir 
beliebigen Code reinziehe.

Ein AVR ist nun mal kein PC.

Oder liegt darin vielleicht das grosse Missverständniss?
Erwarten die Leute etwa, dass mit C++ auf magische Weise und ohne eigene 
Anstrengungen und Programmier Know How, der AVR doch so komfortabel wie 
ein PC wird und geben dann C++ (anstatt sich selber) die Schuld wenns 
nicht klappt?

Wenn ich mir die Beiträge so anschaue, scheint mir das fast so.
Ständig wird von Dingen geredet die nur auf dem PC Sinn machen.

von Kupfer Michi (Gast)


Lesenswert?

>Aber C++ ohne "new"... naja ;)

Genau das meinte ich.
Dynamische Programmierung wie auf dem PC und dann entäuscht sein wenns 
nicht geht.
Oder bist du genauso konsequent und schmeisst C auch gleich auf den 
Müllhaufen und nimmst ASM, nur weil in der gleichen Situation in C das 
malloc genauso wenig funktioniert?

von P. S. (Gast)


Lesenswert?

Kupfer Michi wrote:

> Wenn ich mir die Beiträge so anschaue, scheint mir das fast so.
> Ständig wird von Dingen geredet die nur auf dem PC Sinn machen.

Ich habe eher den Eindruck, viel mehr als ein BlinkeLEDs haben hier 
viele noch nicht gemacht. Im Chat gab's auch schon ein paar Debatten, wo 
Leute meinten sie haetten gigantische Applikationen geschrieben, weil 
sie 1000 Zeilen C-Code zusammen hatten. Ich habe hier fuer eine 
Fernsteuerung auf Atmega2560 Basis 20.000 Zeilen C++-Code und bin weder 
fertig, noch habe ich den Kontroller voll.

Objektorientierte Programmierung hat mit new/delete, Templates und Co. 
erstmal gar nichts zu tun. Das faengt ganz primitiv damit an, dass man 
Objekte hat, bei denen Methoden und benoetigte Variablen zusammen 
liegen. Natuerlich kann man alles auch in Modulen mit Prefixen und weiss 
der Geier was organisieren, das ist dann auch objektorientiert - aber 
wieso sollte man, wenn es einen Compiler gibt, der das eleganter macht? 
Und genau das macht 80% von den Vorteilen aus und bringt die bessere 
Uebersichtlichkeit.

von P. S. (Gast)


Lesenswert?

Luk wrote:

> ich möchte mir ein C++ Programm für meinen Atmega 16 schreiben
> und das am besten dann mit hilfe des JTAGICE mk2 debuggen usw.
> Ich muss im Juli C++ an der Uni ablegen und wollte mir die graue Theorie
> mit etwas Hardware versüssen. Gibt es da ne möglichkeit?

Mit avr-gcc und avrdude kannst du mit Einschraenkungen in C++ fuer den 
Atmega entwickeln. Wie andere schon schrieben, wuerde ich auf dynamische 
Speicherverwaltung und komplexe Konstrukte verzichten. Leider 
funktionieren zumindest bei meiner avr-gcc-Version die virtuellen 
Methoden nicht - da musst du dir mit Funktionspointern behelfen.

Wenn du C++ erst lernen willst, wuerde ich davon die Finger lassen.

von (prx) A. K. (prx)


Lesenswert?

Peter Stegemann wrote:

> funktionieren zumindest bei meiner avr-gcc-Version die virtuellen
> Methoden nicht - da musst du dir mit Funktionspointern behelfen.

Habe damit keine Probleme. Meinst du evtl. pure virtuals? Workaround 
dafür ist harmlos.

von Luk (Gast)


Lesenswert?

Manche von euch haben den Sinn meiner Frage nicht verstanden?

Ich möche C++ nicht auf meinen Microkontroller laufen lassen weil ich es 
muss

sondern weil ich es lernen will natürlich geht das ganze auch mit dem PC
aber ich wollte es halt mit einem Mikrokontroller machen zumindest für 
einige Sachen.

Also mit dem AVR Studie geht es nicht das einzige was eventuell
geht ist der IAR Combiler. Der kann auf jedenfall ganz offiziell C++.
Ich muss in nur noch Knacken.
MFG

von (prx) A. K. (prx)


Lesenswert?

Wenn du C++ der Sprache wegen lernen willst, dann vergiss AVRs und 
andere Zwerge. Denn dann solltest du dich unbedingt auch mit der STL 
beschäftigen, und die ist genau jene Sorte Code, die selbst wenn 
verfügbar bei Zwergen zu schwer kalkulierbarer Menge Code sorgt. Dem PC 
ist das herzlich egal, dem Zwerg nicht. Vom Debugging ganz zu schweigen.

C++ auf AVRs läuft m.E. andersrum besser. Man kennt die Sprache vom PC 
und verwendet eine Untermenge auf dem AVR.

von (prx) A. K. (prx)


Lesenswert?

Luk wrote:

> Ich muss in nur noch Knacken.

Gehört "IAR knacken" bei deiner Uni auch zum Ausbildungsprogramm?

von Kupfer Michi (Gast)


Lesenswert?

>Also mit dem AVR Studie geht es nicht das einzige was eventuell
>geht ist der IAR Combiler. Der kann auf jedenfall ganz offiziell C++.

???
Lad dir WinAVR herunter und du hast gcc, der kann C++ und kannst weiter 
mit dem AVRStudio arbeiten.
Nicht vergessen: C++ Source Files mit grossem .C enden lassen, dann 
erkennt der gcc automatisch, dass es sich um einen C++ File handelt.

http://www.mikrocontroller.net/articles/WinAVR

von (prx) A. K. (prx)


Lesenswert?

.cc geht auch und ist weniger riskant als .C.

von Kupfer Michi (Gast)


Lesenswert?

@Peter Stegemann,

kann dir in deiner generellen Aussage nur zustimmen.

(wollte jedoch nicht so deutlich sagen, dass viele kategorische 
Ablehnungen wohl eher der mangelnden Erfahrung geschuldet sind, das 
kommt bei den Leuten nicht so gut an ... Zeig mir einen Programmierer 
der sich nicht für sehr erfahren hält ;-) )

von Mehmet K. (mkmk)


Lesenswert?


von P. S. (Gast)


Lesenswert?

A. K. wrote:
> Peter Stegemann wrote:

>> funktionieren zumindest bei meiner avr-gcc-Version die virtuellen
>> Methoden nicht - da musst du dir mit Funktionspointern behelfen.
> Habe damit keine Probleme. Meinst du evtl. pure virtuals? Workaround
> dafür ist harmlos.

Nein, normale virtuals. Ich wollte fuer meine Screen-Klasse so Sachen 
wie entrySelected() etc. natuerlich virtuell zum ueberschreiben machen, 
das fuehrte zu recht obskuren Compilerfehlern - irgendwo habe ich das 
auch noch von Anderen beschrieben gefunden, also habe ich es anders 
geloest und mich nicht weiter darum gekuemmert. Gut moeglich, dass es 
inzwischen geht.

Ich nutze noch Version 4.1.2 und wenn es sich nicht wirklich lohnt, 
werde ich nicht updaten, da die neueren Versionen wohl fetteren Code 
erzeugen...

von (prx) A. K. (prx)


Lesenswert?

Hab nochmal nachgesehen. Das hier hängt bei mir seit Jahren als C-Code 
mit drin:
void __cxa_guard_acquire(void) {}
void __cxa_guard_release(void) {}

Im Link von Mehmet steht es präziser drin.

von P. S. (Gast)


Lesenswert?

Ich hab's dann doch nochmal probiert, ich muss nur einfach new und 
delete implementieren, im Prinzip, wie Mehmet es beschrieben hat. 
Allerdings mappe ich die beiden nicht auf malloc, da ich sie ja sowieso 
nicht brauche.

von ajax (Gast)


Lesenswert?

Hey, das ist ja ein ganz schön lange, abgehoben Diskussion.
Könnt Ihr nicht mal zwei kurze Codeteile posten, die die Überlegenheit 
von C++ auf dem AVR zeigen?
Dann kann man sich direkt ein Urteil bilden.

von P. S. (Gast)


Lesenswert?

Nein, das waere Bloedsinn.

von spess53 (Gast)


Lesenswert?

Hi

>Hey, das ist ja ein ganz schön lange, abgehoben Diskussion.
>Könnt Ihr nicht mal zwei kurze Codeteile posten, die die Überlegenheit
>von C++ auf dem AVR zeigen?
>Dann kann man sich direkt ein Urteil bilden.

Richtig. Und das was der Compiler dann daraus macht würde mich noch mehr 
interessieren.

MfG Spess

von (prx) A. K. (prx)


Lesenswert?

Beim oben skizzierte Beispiel mit den Temperatursensoren kann ich das 
erklären: In jeder struct sitzt ein Pointer auf eine Funktionstabelle. 
Statt also die Funktion direkt aufzurufen erzeugt der Compiler einen 
zweifach indirekten Funktionsaufruf. Also:
1
fuction_pointer_t vtbl1[];
2
struct Sensor {
3
   function_pointer_t *vtbl_ptr;
4
   ... Daten ...;
5
}
und aus einem Funktionsufruf object->function(parameters) wird
(object_ptr->vtbl_ptr[2])(object_ptr, parameters);
Das war's auch schon.

von (prx) A. K. (prx)


Lesenswert?

Hmm. editieren geht grad nicht, also müssen die Schönheitsfehler halt 
drin bleiben.

von Luk (Gast)


Lesenswert?

So Problem gelöst

ich mache es nun mit der 30 Tage Version des IAR Combiler sollte jemand
ne besser Idee haben dann bitte schreiben

Bitte 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
Noch kein Account? Hier anmelden.