Nachdem ich irgendwann den GCC für PowerPC-VLE compiliert und zum Laufen bekommen habe, war der sportliche Ehrgeiz geweckt, das auch für andere Plattformen hinzukriegen. Allerdings fand ich das eher für einen Krampf, weil es z.B. teilweise gar keine Headerfiles für I/O gab oder sich die Syntax immens unterschied. Außerdem mussten Patches im Internet zusammengesucht werden. Letztendlich wurde daraus dann die Idee geboren, eine möglichst universelle Toolchain für alle möglichen Plattformen zu erstellen. - Kein Konflikt mit bestehenden Toolchains - alles liegt unter /usr/local/toolchain - GCC und SDCC, mit zusammengesuchten Patches compiliert - Uniforme Headerfiles für I/O, soweit das möglich ist - Linkerscripts und Startup-Files - Uniforme Makefiles, in denen alle Pfade etc. schon eingetragen sind - Nur ein Programmer für alles Unterstützte Plattformen sind momentan: --------------------------------------- - Atmel AVR (nur ATMega) - Microchip PIC14 (PIC12xx, PIC16xx) - Microchip PIC16 (PIC18xx) - Freescale HCS08 - Freescale HCS12 (auch banked) - TI MSP430 - Renesas R8C - STM/Freescale SPC56xx Dazu kommt eine universelle Bibliothek, die auf allen unterstützten Plattformen äquivalente Funktionen bereitstellt. Die Bibliothek enthält derzeit Funktionen für die Fliesskomma-Grundrechenarten (soweit notwendig) und digitale Ein/Ausgabe. Weitere Funktionalität wie Timer,UART,SPI,I2C,ADC,PWM,CAN... sollen folgen. Wo es geht und ich mich auskenne, (also alles außer PIC) sind die Lib-Funktionen in ASM geschrieben. Bei Fliesskomma habe ich teilweise Dumps in Source zurückkonvertiert um das später noch optimieren zu können. Mit einer board.h, in der die konkrete Hardware definiert wird lassen sich so schon Programme schreiben, die auf jeder der Plattformen auf Anhieb laufen. Für später ist auch ein Wizard geplant, der die nötigen Files (Board Definition, Rumpf main etc) mehr oder weniger automatisch zusammenstellt. Mit "make run" wird dann z.B. das Programm übersetzt, in den Controller geschrieben und dieser anschließend gestartet. Wenn Interesse besteht, würde ich das Projekt auch veröffentlichen, wobei halt noch viel zu tun ist (z.B. Dokumentation).
Das klingt recht vielversprechend. Ich denke schon, dass dafür ein Interesse besteht, hier im Forum und generell. Dokumentation ist natürlich wichtig, denn das Konzept kann noch so genial sein - aber der Neueinsteiger muss es benutzen können.
Inzwischen ist das etwas weiter gewachsen und gediehen. Und es stellt sich mal wieder die Frage nach einer Veröffentlichung. Die Bibliothek ist teilweise auf mehr als 1100 Funktionen (Controller-abhängig) angewachsen, die Anzahl der unterstützten Controller-Familien auf 25, wobei ich mangels Testobjekten die Implementierung meist nur mit 1 oder 2 Typen testen konnte: - Diverse MCS51 - Espressif ESP32 - Microchip/Atmel AVR (nur ATMega) - Microchip PIC14 (PIC12xx, PIC16xx) - Microchip PIC16 (PIC18xx) - NXP/Freescale HCS08 - NXP/Freescale HCS12X (auch banked) - NXP/Freescale MPC57xx - NXP/Freescale S9KEA - NXP/Freescale S32K11x - NXP/Freescale S32K14x - Renesas R8C - Renesas 78K0R - Renesas RL78 - Renesas RH850 - Renesas RA6T1 - ST/NXP/Freescale SPC56xx/MPC56xx - ST SPC584 - ST STM32F0xx - ST STM32F1xx - ST STM32F4xx - ST STM32F7xx - ST STM32L4xx - ST STM8 - TI MSP430 Hardware wie UART/SPI/I2C/ADC/PWM/CAN wird in großen Teilen unterstützt, dabei halt aus Gründen der Kompatibilität nur in bestimmten Konfigurationen Zusammen mit meinem Universalprogrammer lassen sich damit sehr schnell auch recht komplexe (je nach Sichtweise) Anwendungen erstellen und auch ggf. auf eine andere Controllerfamilie übertragen. Allerdings habe ich aus Aufwandsgründen recht früh die Toolchains "eingefroren", die jüngste verwendete GCC-Version sollte z.B. die 4.92 sein, bei manchen derzeit nicht mehr vom GCC unterstützen Architekturen (HCS12X) ist sie auch noch älter. Da ich aber eigene Pfade dafür verwende (/usr/local/toolchain) sollte es keine Probleme mit parallel dazu installierten Toolchains geben. In letzter Zeit habe ich wieder einmal darüber nachgedacht, in welcher Weise sich das am sinnvollsten veröffentlichen ließe. Lizenz wäre GPL, da auch ein paar fremde Sourcen, die unter der GPL stehen, mit dabei sind. Da ich schon seit vielen jahren eine eigene "Versionsverwaltung" nutze, dazu noch eine größere Anzahl von "Code-Generatoren" und eine Unmenge an Symlinks, scheidet ein öffentliches GIT-Repo für mich aus. Denn letztendlich muss sich für mich auch der Aufwand in Grenzen halten. Die Sourcen zu veröffentlichen, ist an sich kein Problem, die ganzen Proszesse die ein "rebuild_all" auslöst, nachvollziehbar zu dokumentieren, bin ich derzeit nicht willens. Allein die Dokumentation aller Bibliotheksfunktionen und teilweise der darunterliegenden Konzepte wird schon einen erheblichen Aufwand bedeuten. Da die Bibliothek kontinuierlich wächst, wäre auch ein regelmäßiger Update-Zyklus sinnvoll. Bei einer so großen Anzahl an Controller-Familien gibt es natürlich auch Einschränkungen und Kompromisse. Da ich für einige Familien den SDCC-Compiler benutze, wird zum Beispiel C++ generell nicht unterstützt. Oder dass ich für vieles einen zentralen "Tick-Interrupt" benutze, einfach weil Interrupts auf PowerPC Architekturen bezüglich der Rechenzeit "teuer" sind. Oder DMA, was ein teil der Controller nicht unterstützt und wo ich noch bei der Ideenfindung für ein einheitliches Konzept bin. Außerdem habe ich eine feste Projekt-Struktur, nach der sich z.B. die Pfade in den Makefiles richten, die aber nicht unbedingt jedermanns Geschmack treffen wird. Lauffähig ist das Ganze derzeit praktisch nur unter Linux, wobei die controllerspezifischen Dateien natürlich betriebssystem-unabhängig sind. Da sich Docker wohl recht einfach unter WSL2 betreiben lässt, könnte man auf diese Weise auch unter Windows damit arbeiten ohne dass für mich dadurch zusätzlicher Aufwand entsteht. Da ich selbst mittlerweile fast ausschließlich dieses Build-System nutze, einfach weil es meinen Anforderungen entspricht, bin ich an dieser Stelle natürlich ein bisschen "betriebsblind". Von daher die Frage, in welcher Form das auch für andere interessant sein könnte und 4 mögliche Antworten dazu: A) Das Ganze ist zu speziell, das wird eher niemand nutzen wollen. B) Sourcen und Binaries veröffentlichen, wer es nutzen möchte, ist halt an die Pfade gebunden oder ändert sie selbst. C) Template-Packages für jeden Controller, die bereits alle notwendigen Dateien (außer der Toolchain) enthalten. Optimal für Weitergabe und Archivierung. D) Docker-Container für jede Controller-Familie, damit könnte man das auch unter WSL2 und ggf. auch online nutzbar machen. Für ein paar Controllerfamilien nutze ich das bisher selbst. Dazu kommt natürlich noch der Aufwand für die Dokumentation, die sich sicherlich in großen Teilen automatisch erzeugen lässt. Vielleicht gibt es ja von Eurer Seite Meinungen und Anregungen dazu. Jörg
Wenn Du den Aufwand für Dich klein halten willst, dann kannst Du es halt nicht veröffentlichen. Wenn man Deine Library nicht auf einem relativ übliche Weg installieren kann (z.b. einfach über git), dann wird die auch keine installieren. Wenn es keine Dokumentation zur Library gibt, dann wird die auch keiner nutzen wollen. Wenn das ganze nur mit uralten Compilern funktioniert, dann läßt es sich evtl. auch schlecht mit anderen Libraries kombinieren. Wenn die keiner nutzt, dann wirst Du auch keine Rückmeldung bekommen. Automatisch generierte Dokumentation ist meiner Meinung nach, selten wirklich hilfreich, weil die dafür üblichen Tools halt auch nur die Signatur der Funktionen scannen.
Liest sich für mich als gäbe es da große Überschneidungen mit platformio. Wäre evtl. eine Option, wenn du deine Compiler & Bibliotheken als platformio-packages anbietest. (statt /usr/local/toolchain liegt's dann halt im ~/.platformio/packages) Damit bist du das ganze "drumherum" los, hast eine Versions- und Abhängigkeitsverwaltung usw. Joerg W. schrieb: > Von daher die > Frage, in welcher Form das auch für andere interessant sein könnte und 4 > mögliche Antworten dazu: Wär halt die 5. Antwort auf die Frage...
> Und es stellt sich mal wieder die Frage nach einer Veröffentlichung.
Halte ich fuer Unsinn. :-)
ICh hab das auch schonmal vor 10-15Jahren gemacht. Also eine
Compilerversion fuer alle meine Controller (ARM, R8C, M16C, 68k, usw)
uebersetzt.
Sobald du das veroeffnetlichst wird es jeder der es auf einer anderen
Distribution uebersetzen will als du sie gerade nutzt, schnell an
irgendwelche Probleme stossen. Waere er in der Lage diese Probleme zu
beheben dann braeuchte er das nicht was du gemacht hast weil er ja sonst
den Compiler direkt selber uebersetzen koennte.
Sobald das mehr wie 10Leute haben wird das grosse jammern beginnen,
wieso gibt es nicht den neuesten Compiler, rabaeh, ich will aber doch,
mit Fuss aufstampf. Wenn du aber mal diverse gcc-versionen mitgemacht
hast dann wirst du wissen dies auch mit Arbeit verbunden ist. Ich nutze
z.B immer noch gcc4.7.xx weil mir das reicht.
Eine Vereinheitlichung der Hardware kann auch nicht klappen weil einfach
viel zu extrem unterschiedlich. Und dann gibt es auch MCUs die
Banalitaeten (z.B IRQ-Priorisierung) nicht unterstuetzen und deshalb
immer eine ganz andere Herangehensweise brauchen.
Deshalb wuerde immer nur mein eigenes Zeug nutzen. (Und mache das
natuerlich auch so)
Und dann denke nur an die ganzen Typen auf Arduinolevel die noch nicht
mal ihr Linkerscript an die eigene Hardware anpassen koennen. Wie sollen
die damit klarkommen?
Olaf
So oder ähnlich habe ich das auch befürchtet. Das Problem mit den Compiler-Versionen und Distributionen lässt sich einigermaßen über die Docker-Container in den Griff bekommen. Anstelle "make prog" gibt es dann halt ein "./docker_make prog". Bei den Interrupts komme ich meistens mit dem "Tick-Interrupt" aus, das ist natürlich ein Kompromiss und erfordert manchmal eine eigene Softwarephilosphie. Das ist zwar nicht immer der effizienteste Weg, aber mir ist halt Kompatibilität wichtiger. Ein anderes Beispiel sind z.B. grafische LCDs. Ob 128x64, 64x128 (hochkant), 320x240 oder 480x64, alle nutzen ein Image im RAM und dieselben Zeichenroutinen. Im Tick-Interrupt wird dann nur noch ein "serve_glcd18ax_ondemand();" aufgerufen, welches dann bei gesetztem Dirty-Flag in den nächsten Interrupts das geänderte Image blockweise in das Display überträgt, als "serve_glcd18ax_ondemand_fast();" auch in kleineren Blöcken... Der PlatformIO Ansatz klingt nicht schlecht, allerdings würde das wohl eine weitgehende Umstrukturierung (z.B. Versionsverwaltung) erfordern oder zweigleisiges Fahren. Und die Toolchain müsste damit wohl auch z.B. unter Windows laufen. Das hinzubekommen bin ich aber weder in der Lage noch willens dazu, denn das müsste ja auch entsprechend getestet werden. Aber ich werde es im Auge behalten. Wer unbedingt eine grafische IDE braucht, für den ist das sowieso wohl eher nicht gedacht. Naja, vielleicht frage ich in ein paar Jahren nochmals nach ;-) Jörg
> Im Tick-Interrupt wird dann nur noch ein > "serve_glcd18ax_ondemand();" aufgerufen, welches dann bei gesetztem > Dirty-Flag in den nächsten Interrupts das geänderte Image blockweise in Das lob ich mir, so mache ich das auch. :-) > Wer unbedingt eine grafische IDE braucht, für den ist das sowieso wohl > eher nicht gedacht. Nicht unbedingt. Du kannst ja auch in Eclipse ein makefile-projekt importieren und einfach nutzen. Ich schaetze grafische Umgebungen durchaus, zumindest wenn man auf einfachem Level debuggen will ist das manchmal ganz nett. Schlimm sind nur Umgebungen (z.B das neue Zeugs mit dem Segger gerade haussieren gehen) die das nicht koennen und dann wundern sie sich das es keiner nutzt. .-) BTW: Da ich gerade gesehen hab das du auch R8C nutzt, laeuft der Compiler jetzt out of the Box? Als ich das damals implementiert habe hatte ich etwas Emailverkehr mit D.J Dellorie weil es da einen bug beim startup gab ich glaube 24 anstatt 32bit adresse oder umgekehrt. Olaf
Joerg W. schrieb: > Der PlatformIO Ansatz klingt nicht schlecht, allerdings würde das wohl > eine weitgehende Umstrukturierung (z.B. Versionsverwaltung) erfordern Ganz unabhängig vom Thema des Threads ist es mir vollkommen unverständlich, warum ein fähiger und erfahrener Entwickler auf den Komfort einer modernen Versionsverwaltung verzichtet. Darf ich nach Deinem Grund fragen?
Ich habe mit dem R8C keine Probleme, nutze aber auch eigenes Startup / Vektor-Tabelle. Ich kann die Sachen hier habe mal beide Dateien als Beispiel angehängt. Ich definiere viele Dinge auch in den (meist automatisch generierten) Header-Files als Konstanten, um das überhaupt einigermaßen einheitlich hinzubekommen. Wobei bei größeren Controllern der main-Code und Konstantentabellen (z.B. Fonts) im Bereich bis 0xFFFF liegen müssen. In den Linkerscripts liegt der obere Bereich ab 0x10004 bei mir in einer eigenen Section. Ähnliches gibt es auch beim S12X, hier gibt es je nach Typ noch mehr Sections. In den Source-Dateien der Bibliothek haben dann die Funktionen z.B. ein "FKT1_TYPE" Attribut, welches bei den meisten Controllern einfach als leer definiert ist, bei Controllern mit Bank-Switching auf die entsprechende Section zeigen. Jörg
Joerg W. schrieb: > Wer unbedingt eine grafische IDE braucht, für den ist das sowieso wohl > eher nicht gedacht. Nur der Vollständigkeit halber: Platformio läuft auch komplett unabhängig von einer IDE an der Kommandozeile. Joerg W. schrieb: > Ein anderes Beispiel sind z.B. grafische LCDs. Ob 128x64, 64x128 > (hochkant), 320x240 oder 480x64, alle nutzen ein Image im RAM Das würde ich nicht als gegeben hinnehmen. Mit LVGL z.B. brauchts nur RAM für ein paar Zeilen vom Bild, idealerweise in zwei Blöcken. Da kann dann einer befüllt/gezeichnet werden, während der andere per DMA zum Display wandert.
Ein T. schrieb
> Darf ich nach Deinem Grund fragen?
Ich habe mir vor ungefähr 30 Jahren halt ein System überlegt, damals
noch auf dem Atari ST. Auf der Basis von Verzeichnissen, Versionen
werden hochgezählt und Schnappschüsse erhalten einen fortlaufenden
Buchstaben. Die letzte Version wird zur Neuen und wandert in den
"alt"-Ordner (ohne die Schnappschüsse), um sie bei Problemen schnell zur
Verfügung zu haben. Für noch ältere Versionen kann ich immer noch auf
das inkrementelle Backup (Back in Time) mit wöchentlichen Snapshots der
letzten Jahre zurückgreifen.
Das nutze ich bis heute noch und ist für meine Belange völlig
ausreichend. bis jetzt gibt es keinen Leidensdruck, auf irgendetwas
anderes zu wechseln.
Jörg
Εrnst B. schrieb:
> Das würde ich nicht als gegeben hinnehmen.
Bei mir ist es halt so gegeben. Bei einigen Displays ohne eigenen
Controller (320x240, 480x64) kann ich die Daten nicht "on the fly"
generieren, sondern brauche einen Display-Buffer. Für die 128x64 kann
man die 1K Buffer meist auch verschmerzen und andere Grafik-Displays
habe ich bis jetzt kaum genutzt.
Und weil ich halt faul bin, nutze ich dieselben Routinen so für
unterschiedliche Displays.
Und DMA ist halt auf jeder Controller-Familie anders implementiert, von
gar keiner über die unterschiedlichste Ausprägungen in Hardware bis zum
XGATE Coprozessor in den S12X.
Jörg
Joerg W. schrieb: > Ein T. schrieb >> Darf ich nach Deinem Grund fragen? > > Ich habe mir vor ungefähr 30 Jahren halt ein System überlegt, damals > noch auf dem Atari ST. Auf der Basis von Verzeichnissen, Versionen > werden hochgezählt und Schnappschüsse erhalten einen fortlaufenden > Buchstaben. Die letzte Version wird zur Neuen und wandert in den > "alt"-Ordner (ohne die Schnappschüsse), um sie bei Problemen schnell zur > Verfügung zu haben. Für noch ältere Versionen kann ich immer noch auf > das inkrementelle Backup (Back in Time) mit wöchentlichen Snapshots der > letzten Jahre zurückgreifen. Lieben Dank für Deine Antwort. Na klar, das kann ich gut verstehen -- ich hatte früher auch so ein eigenes System und hab' mich lange schwergetan, das mit einem "fertigen" Versionskontrollsystem abzulösen, in meinem Fall erst Subversion und mittlerweile, aus verschiedenen Gründen, Git. Am Ende muß ich aber (für mich, natürlich) sagen, daß es sich gelohnt hat -- denn jetzt muß ich nichts mehr manuell machen und etliche nützliche Funktionen fallen dabei gleich mit aus der Tüte. Aber wenn Du andererseits ein System hast, das gut funktioniert, Deine Aufgaben erfüllt, und an das Du gewöhnt bist: da bedarf es schon sehr guter Argumente, um das abzulösen. ;-)
> Am Ende muß ich aber (für mich, natürlich) sagen, daß es > sich gelohnt hat -- Ich denke mal es ist ein Unterschied ob man beruflich was macht wo man jeden Tag eincheckt und dabei gleich die Codingrules geprueft werden, oder privat aus Spass alle paar Tage/Wochen mal was zaubert. Meine privaten Platinen sind auch nicht fuer Massenproduktion, EMV, Vibration, Atex, RED, usw., geeignet. Zuhause macht man Kunstwerke, in der Firma Kunsthandwerk. .-) Olaf
Olaf schrieb: > Ich denke mal es ist ein Unterschied ob man beruflich was macht > wo man jeden Tag eincheckt und dabei gleich die Codingrules > geprueft werden, oder privat aus Spass alle paar Tage/Wochen > mal was zaubert. Ja, natürlich. Allerdings sehe ich halt schon, wieviel Aufwand ich früher für mein eigenes System hatte, sowohl mit der Pflege der Skripte als auch bei der eigentlichen Versionsverwaltung, und wie wenig Streß ich dann mit Subversion / Git hatte bzw. habe. Klar, ein eigenes System kann man immer besser an die eigenen Bedürfnisse und Vorstellungen anpassen, während man sich bei einem fertigen System womöglich auf siene Features einlassen und dabei womöglich den eigenen Workflow ein wenig anpassen muß, aber am Ende kann ich nur sagen, daß ich mittlerweile viel weniger Arbeit habe. Und am Ende ist die Faulheit laut Larry Wall eine der Kardinaltugenden von guten Enwicklern... daran gemessen muß ich echt super sein! ;-) > Meine privaten Platinen sind auch nicht fuer Massenproduktion, > EMV, Vibration, Atex, RED, usw., geeignet. > Zuhause macht man Kunstwerke, in der Firma Kunsthandwerk. .-) TY, YMMD! ;-)
Es mag ja Leute geben die das mögen werden, aber dazu müsste es zumindest auf github liegen. Da geht es ja auch um Issues, PRs, Diskussion und Wiki, nicht nur um tote Ablage. Und ich finde es sinnvoller auf Standards zu setzen, für Buildysteme kommt man um CMake kaum herum wenn es um so umfangreiche Konfiguration geht. Der Vorteil ist dann das es ein großes Ökosystem drumherum gibt, wie z.B. die cmake-tools in VSC. Das Ganze mittlerweile für das Dreigestirn Mac, Linux, Windows. Die Entwickler mögen keine Ausgrenzung, und dieses Multikulti funktioniert sehr gut. Dokumentiert ist das auch alles und es gibt Tutorials und Lernvideos, das möchte ich auch nicht selber machen. Ich habe einen Großteil in meinem Berufsleben an und mit einem proprietärem OS und Tools gearbeitet und damit Anwendungen wie am Fliessband erstellt. Das war auch eine Standardisierung, aber eine Insel, anders als der Rest der Welt. Damit nabelt man sich auch von anderer Entwicklung ab und das mag ich gar nicht mehr wenn ich den Vergleich sehe. Dafür muss man auch mal den Code und die Arbeit anderer akzeptieren. Und Snapshots sind absolut kein Ersatz für git oder andere VCS. Ich kann Code in wenigen Minuten schreddern und da nützt mir kein Backup von gestern. Arbeiten mit commits, branches und einem Server für eine zentrale Version sind einfach Gold wert. Vergleiche mit anderen Versionen mit dem eingebauten git in VSC gehen auf Knopfdruck und sind absolut genial, das hätte mir früher viel Zip-Chaos und überschriebenen Code gespart.
:
Bearbeitet durch User
> Es mag ja Leute geben die das mögen werden, aber dazu müsste es > zumindest auf github liegen. Noe muss nicht. Wenn man ein NAS hat ist die Installation von GIT oder SVN dort eine Sachen von ein paar Minuten. > für Buildysteme kommt man um CMake kaum herum Doch doch, das schaffe ich muehelos und mit Freude da rum zu kommen. Olaf
Olaf schrieb: > Noe muss nicht. Wenn man ein NAS hat ist die Installation > von GIT oder SVN dort eine Sachen von ein paar Minuten. und das möchtest du dann für alle freigeben?
Jetzt die ganzen Build-Prozesse umzubauen, habe ich ehrlich gesagt nicht vor. Im Moment ist praktisch alles automatisiert, von der Generierung der Includes, Linkerscripts, Makefiles bis zum Bauen der Bibliothek für jeden einzelnen Controller. Meist nach Typlisten-Dateien und Template-Files, aus denen sich dann (meist Perl) Scripts die notwendigen Informationen holen. Und weitere Scripts, die z.B. aus den ganzen Funktions-Quellcodes die Funktions-Prototypen generieren. Die kompletten Dateien zum Bauen einer Bibliothek existieren aber nur in dem Moment an der "richtigen" Stelle im Verzeichnisbaum, wenn die Bibliothek gebaut wird. Danach wird alles nicht benötigte gelöscht, neue Dateien nach Liste geholt und die Bibliothek für den nächsten Controller gebaut. Aktuell braucht mein Laptop ein paar Stunden dafür, aber das kann man auch in der Nacht laufen lassen und passiert eigentlich nur bei einem neuen Release. Ein weiterer wichtiger Grund ist ja der, dass ich (fertige) Projekte als Open Source veröffentlichen möchte, die auf diesen Bibliotheken aufbauen. Dann sollte es zumindest relativ einfach möglich sein, diese Projekte abgeändert neu zu compilieren. Aber vielleicht sehe ich da auch Probleme, wo eigentlich keine sind... Jörg
> Aber vielleicht sehe ich da auch Probleme, wo eigentlich keine sind...
Ich wuerde eher sagen du gehoerst damit zu den wenigen die sich
fuer die Probleme interessieren. Und dabei hast du im gegenueber
den meisten anderen Programmieren noch einen gewaltigen Vorteil,
du kannst davon ausgehen das deine "Kunden" programmieren koennen
weil sie sonst ja kaum an dem Projekt interessiert waeren.
Daher sollten die zumindest kleinere Probleme auch selbst gerade
biegen koennen.
Olaf
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.