Seit 40 Jahren ist die Programmiersprache C quasi Industriestandard im µC bzw. Embedded - Bereich. Gibt es da inzwischen Alternativen - Assembler natürlich ausgenommen? Bisher sind mir wenige Industrieprojekte begegnet, bei denen nicht C verwendet wurde. Irgendjemand bei uns in der Firma verwendete mal C++. Dann kannte ich mal jemanden, der die Steuerung einer Kegelbahn auf einem AVR in BASCOM programmiert hat. In meiner Studienzeit waren noch ADA und Forth aktuell. ADA fand ich ganz gut, ist aber aus der Nische Militär/Raumfahrt nie herausgekommen. Forth hatte einige fanatische Anhänger, hat mich aber eher an HP-Taschenrechnerprogramme erinnert. Spätestens, wenn man größere Datenstrukturen brauchte, wurde es ein ziemlich undurchschaubarer Krampf. Ich glaube kaum, dass das heute noch jemand für ernsthafte Anwendungen benutzt. Java & Co sind wegen des gewaltigen Overheads auf Mikrocontrollern wohl nicht sinnvoll nutzbar.
:
Eine richtig vollumfängliche Alternative ist leider schwierig zu etablieren da nunmal all die Entwickler auf C(++) eingestimmt sind. Ein Unternehmen das eine andere Sprache einsetzen will, muss teurere/seltene Mitarbeiter finden und danach suchen sie deswegen erst garnicht. Henne-Ei Problem. Zwei Sprachen die man als Alternative bezeichnen könnte gibt es aber: Embedded Rust: https://rust-embedded.github.io/book/ Von Anfang an als System-Sprache entwickelt (wie C) aber mit Fokus auf Sicherheit. Zumindest für das normale Rust ist diese sogar mathematisch bewiesen: https://internals.rust-lang.org/t/rustbelt-securing-the-foundations-of-the-rust-programming-language/5509 Dafür muss man ein paar ungewohnte Eigenheiten in Kauf nehmen, die aber verhindern dass man in so viele Fettnäppchen tritt wie in C(++). Micro Python: https://micropython.org/ Inzwischen sind die uCs nicht mehr die Selben wie vor Jahrzehnten. Man kann es sich oft durchaus leisten etwas Rechenleistung für die Sprache zu opfern, wenn dafür die Entwicklung deutlich schneller geht.
Bleib bei C. Andere Sprachen kommen und gehen, aber nur C hält sich seit Jahrzehnten, wohl nicht ohne Grund.
Dateisammler schrieb: > Bleib bei C. Andere Sprachen kommen und gehen, aber nur C hält sich seit > Jahrzehnten, wohl nicht ohne Grund. Naja.. das ist sozusagen eine selbsterfüllende Prophezeihung. Es gibt etliches an C zu kritisieren, aber damit fangen wir hier am besten garnicht an, denn sonst wird das zum Flameware ;)
Eine andere Möglichkeit, die nur nicht "modern" ist, sondern auch schon recht alt, ist FORTH.
> Inzwischen sind die uCs nicht mehr die Selben wie vor Jahrzehnten. Man > kann es sich oft durchaus leisten etwas Rechenleistung für die Sprache > zu opfern, wenn dafür die Entwicklung deutlich schneller geht. Inzwischen gibt es aber viele Anwendungen wo der Stromverbrauch wichtig ist. Da sind dann auch schnelle Sprachen und kleine Controller mit geringem Ruhestrom wichtig. Ausserdem wird das Henne-Ei Problem noch dadurch verstaerkt das jeder Programmierer auch immer noch den Source der letzten 10-20Jahre verstehen muss den andere in seiner Firma programmiert haben. Daher muesste jede neue Sprache zusaetzlich gelernt werden. Ich wuerde ein andere modernere Sprache auch fuer sinnvoll halten, aber erwarte nicht das dies jemals passiert. Olaf
Ah ja, all diese modernen Sprachen, deren Jünger kaum noch programmieren können. import * und los geht's. Hat sich hier schonmal wer gewundert, warum man heutzutage immer mehr RAM im Desktop-Bereich braucht? Bald vielleicht auch bei Mikrocontrollern.
Jan schrieb: > Ah ja, all diese modernen Sprachen, deren Jünger kaum noch programmieren > können. import * und los geht's. Hat sich hier schonmal wer gewundert, > warum man heutzutage immer mehr RAM im Desktop-Bereich braucht? Bald > vielleicht auch bei Mikrocontrollern. Erstens weil Kunden und damit auch die, diese zufriedenstellenden Firmen, Ergebnisse sehen wollen und das so schnell wie möglich. Entsprechend gibt es wenig Zeit für Optimierung. Zweitens, (da Erstens eigentlich schon immer galt), weil man es heute kann. Die Rechner haben einfach viel RAM. Schau dir mal an was Software heute kann und wie dessen Oberfläche aussieht im Vergleich zur Software von vor 20 Jahren. Das ist enormer Fortschritt. Der wäre nicht möglich wenn die Entwickler weiterhin so viel zeit in Bit-Frickeleien stecken würden wie zu 64kb Ram zeiten. Das hat rein garnichts mit dem Wissensstand des Entwicklers zutun.
Alex G. schrieb: > Dateisammler schrieb: >> Bleib bei C. Andere Sprachen kommen und gehen, aber nur C hält sich seit >> Jahrzehnten, wohl nicht ohne Grund. > Naja.. das ist sozusagen eine selbsterfüllende Prophezeihung. > Es gibt etliches an C zu kritisieren, aber damit fangen wir hier am > besten garnicht an, denn sonst wird das zum Flameware ;) Ja, an C gibt es etliches zu kritisieren. Aber in 99,9% aller Fälle ist es der falschen Verwendung von C geschuldet und nicht der Sprache an sich. Die Compiler sind inzwischen sehr gut. Da muss man dann schon richtig was auf dem Kasten haben um besser zu sein (oder nur genauso gut) was wieder das Problem mit dem Personal und der Bezahlung nach sich zieht. Auf C wird immer viel geschimpft, das ist wie mit der Bild-Zeitung: Jeder meckert drüber, niemand liest sie aber sie ist die auflagenstärkste Zeitung in Deutschland. Ist ja klar, als Verleger produziert man gerne Zeitungen, die sich nicht verkaufen. Ich hab in C auch schon so manches Fettnäppfchen mitgenommen aber ich sehe es so wie es ist: Es waren alles meine Fehler, nicht die von C.
M. K. schrieb: > Es waren alles meine Fehler, nicht die von C. Eine gute Sprache sollte einen dabei unterstützen so wenig Fehler wie möglich zu machen.
M. K. schrieb: > Ja, an C gibt es etliches zu kritisieren. Aber in 99,9% aller Fälle ist > es der falschen Verwendung von C geschuldet und nicht der Sprache an > sich. Die Compiler sind inzwischen sehr gut. Da muss man dann schon > richtig was auf dem Kasten haben um besser zu sein (oder nur genauso > gut) was wieder das Problem mit dem Personal und der Bezahlung nach sich > zieht. > Auf C wird immer viel geschimpft, das ist wie mit der Bild-Zeitung: > Jeder meckert drüber, niemand liest sie aber sie ist die > auflagenstärkste Zeitung in Deutschland. Ist ja klar, als Verleger > produziert man gerne Zeitungen, die sich nicht verkaufen. > Ich hab in C auch schon so manches Fettnäppfchen mitgenommen aber ich > sehe es so wie es ist: Es waren alles meine Fehler, nicht die von C. Würden die Leute zu C++ wechseln, würde es ihnen viel schwerer gemacht, Fehler zu produzieren, bei mindestens gleicher Performance.
Alex G. schrieb: > Eine gute Sprache sollte einen dabei unterstützen so wenig Fehler wie > möglich zu machen Das tut C, man muss halt nur diese ganze Funktionalität auch einschalten. Wenn ich aber auch immer wieder sehe, wievielen Programmierern z.B. Warnings völlig egal sind...naja, die würden sich über eine „moderne Sprache“ wahrscheinlich nicht freuen. Ich wills mal so sagen: Du willst einen Kaffee mit Milch, sagst aber nur, dass du gerne einen Kaffee hättest, woher soll die Gegenseite dann wissen, dass du rote Tassen schrecklich findest? ;)
vn nn schrieb: > Würden die Leute zu C++ wechseln, würde es ihnen viel schwerer gemacht, > Fehler zu produzieren, bei mindestens gleicher Performance. Sie müssten mehr arbeiten und die Performance wäre maximal genauso gut wie bei C, nicht mindestens ;)
Teils lässt sich aus C++ relativ einfach mehr Performance als aus C rauskitzeln. Ein einfaches Beispiel dafür ist die Verwendung von constexpr & templates, da man hier den Compiler auch zur Berechnung von Werten beim kompilieren zwingen kann. In C ist das leider nicht direkt möglich (außer man berechnet die Werte irgendwie extern). Generell erlaubt C++ deutlich bessere Fehlerbehandlung zur Compilezeit, die einem in C erst zur Laufzeit auffallen (z.B. fälschlich durch Tippfehler Ausgangsport als Eingangsport verwenden).
M. K. schrieb: > Sie müssten mehr arbeiten und die Performance wäre maximal genauso gut > wie bei C, nicht mindestens ;) Hast du gehört, oder weißt du? Kannst du dies auch begründen? M. K. schrieb: > Das tut C, man muss halt nur diese ganze Funktionalität auch > einschalten. Vor randalierenden Pointern, unterminierten Strings, Arrayzugriffen ins Leere kann C prinzipbeding nicht schützen.
Die Jugend spricht Python. Auf dem Mikrocontroller spricht sie MicroPython.
> Die Jugend spricht Python. > Auf dem Mikrocontroller spricht sie MicroPython. Das aendert sich sobald sie von der Uni in die Entwicklungsabteilung wechseln oder sie verschwinden sehr schnell wieder aus der Firma. .-) Wer im Embeddedbereich programmieren will der kann entweder C oder ist arbeitslos. Olaf
Asa Spark gibt es noch falls die Funktion wichtig ist. Ist ein Ada subset mit moeglichkeit zum Beweise the post conditionen.
Beitrag #5650583 wurde von einem Moderator gelöscht.
vn nn schrieb: > Hast du gehört, oder weißt du? Kannst du dies auch begründen Hier ein Beispiel: https://github.com/Erlkoenig90/langcomp/blob/master/README.md
Umsonst gäbe es nicht auch: http://www.oshonsoft.com/ https://www.mikroe.com/compilers/compilers-pic Ja ich weiss, Industriestandard und so... Hallo, es gibt mehr neben PeeCee, Windows und C! Nur tote Fische schwimmen mit dem Strom. Gruss Chregu
Mike schrieb: > Seit 40 Jahren ist die Programmiersprache C quasi Industriestandard im > µC bzw. Embedded - Bereich. Gibt es da inzwischen Alternativen - > Assembler natürlich ausgenommen? Seit fast 200 Jahren gibt es Schraubenschlüssel, gibt es da mal endlich Alternativen zum Schraubenschlüssel - Hammer natürlich ausgenommen ??? IMHO sollte man das mit dem Sprachwechsel sein lassen und sich lieber mit scripting und anderen Ansätzen der Computerbedienung auseinandersetzen als textuelles Codieren, bspw: http://www.ni.com/getting-started/labview-basics/d/dataflow
:
Bearbeitet durch Moderator
Alex G. schrieb: > Es gibt etliches an C zu kritisieren, aber damit fangen wir hier am > besten garnicht an, denn sonst wird das zum Flameware ;) Schreibe doch einfach mal einen neuen Post mit Titel "Bascom ist gut"! Die C-Progger bekommen Schnappatmung und laufen blau an, während die Basic-Jünger freuen und dich einen runterholen... :-)
Visions Kraft schrieb: > IMHO sollte man das mit dem Sprachwechsel sein lassen und sich lieber > mit scripting und anderen Ansätzen der Computerbedienung > auseinandersetzen als textuelles Codieren, bspw: LabView Sorry, aber LabView ist was für Spielkinder und High-Level Künstler, die fertige gut durchdachte Module zusammen stöpseln. Und wer programmiert die Module? Ich kam mit dem LabView Style durch Lego MindStorms NXT in Kontakt. Das ist die größte Verschwendung von Arbeitszeit, die ich je gesehen habe. Diese Diagramme sind ab einer gewissen Komplexität nicht einmal übersichtlicher, als Quelltext.
vn nn schrieb: > Vor randalierenden Pointern, unterminierten Strings, Arrayzugriffen ins > Leere kann C prinzipbeding nicht schützen. Als ob es bei C++ keine Probleme gäbe ;)
Mike schrieb: > In meiner Studienzeit waren noch ADA und Forth aktuell. ADA fand ich > ganz gut, ist aber aus der Nische Militär/Raumfahrt nie herausgekommen. Ada (gnat/gcc) funktioniert gut für populäre µCs & OSs.
Beitrag #5650634 wurde von einem Moderator gelöscht.
vn nn schrieb: >> Vor randalierenden Pointern, unterminierten Strings, >> Arrayzugriffen ins Leere kann C prinzipbeding nicht schützen. M. K. schrieb: > Als ob es bei C++ keine Probleme gäbe ;) Dann geht man eben noch einen Schritt weiter nach Java. Natürlich nicht auf einem ATtiny.
Asm'ler schrieb im Beitrag #5650634: > Ich bleib bei 8Bit lieber bei DER Programmiersprache diesseits von C. > Direkt 1:1 und ohne jeden Overhead. Ohne Overhead ist nicht ganz richtig. Wer Assembler gut kann, der bekommt damit vieles deutlich schneller und kompakter hin. Für mich ist C ein guter Kompromiss. > Mit einer Doku die noch auf ein A4 Blatt passt. Wie meinst du das denn? > Eine höhere, hochperformante Sprache, die mich überzeugt weil sie > wirklich vereinfacht und von den Niederungen der Hardware wirklich > abstrahiert muss noch erfunden werden. Du hast noch keine Enterprise Backend Anwendungen entwickelt. Da sendet man einen einfachen Request übers Netz und parst die Antwort mit zwei Zeilen Code. Mach das mal in C. Die Vereinfachung und Abstraktion kommt nicht von der Sprache alleine, sondern dem gesamten Gespann aus Betriebssystem, Programmiersprache, Libraries, Frameworks, Laufzeitumgebung und Assistenten in der IDE. In diesem Enterprise Umfeld ist C aus vielen Gründen fast unbrauchbar.
Habe schon mit D auf μCs experimentiert. Durch Metaprogrammierung kann man da sehr viel interessanten Kram machen, beispielsweise habe ich mal eine Bibliothek zusammengebastelt welche Registerdefinitionen aus einer Datei lesen kann, ggf. die passende Bitbanding-Addresse berechnet, die Zugriffsberechtigung überprüft und dazu den passenden Code ohne Laufzeitkosten generiert. Am Ende konnte ich dann derartigen Code schreiben:
1 | with (RCC.PLLCFG) |
2 | PLLSRC = HSI; |
3 | with (GPIOD.MODE) |
4 | { |
5 | io0 = output; |
6 | io3 = output; |
7 | io4 = output; |
8 | } |
9 | with (GPIOD.OD) |
10 | { |
11 | io0 = true; |
12 | io3 = false; |
13 | io4 = true; |
14 | } |
Promblematisch ist, dass standardmäßig Typeninformation in der Binary landen, vor zwei Jahren muste ich die manuell hinterher rausschmeißen. Die uC-Community ist da leider nicht so groß.
Stefanus F. schrieb: > Asm'ler schrieb: >> Ich bleib bei 8Bit lieber bei DER Programmiersprache diesseits von C. >> Direkt 1:1 und ohne jeden Overhead. > > Ohne Overhead ist nicht ganz richtig. Wer Assembler gut kann, der > bekommt damit vieles deutlich schneller und kompakter hin. Für mich ist > C ein guter Kompromiss. Bist du sicher? Ich glaube nicht, dass man als durchschnittlicher bis guter Programmierer insgesamt besser als ein optimierender Compiler ist. Da die Frage ja nicht auf Mikrocontroller bezogen war, kann ich auch meine Stimme für Python geben. Das scheint sich (leider) stark zu verbreiten.
Bei Python ist die Sache mit den Einrückungen für mich ein absolutes No-Go. Alleine deswegen habe ich an dieser Sprache so wenig Interesse, wie an rosa gefärbter Milch.
Stefanus F. schrieb: > Bei Python ist die Sache mit den Einrückungen für mich ein absolutes > No-Go. Alleine deswegen habe ich an dieser Sprache so wenig Interesse, > wie an rosa gefärbter Milch. Bei mir auch fast. Das ist als Lehrsprache (als die es konzipiert wurde) zwar eine gute Sache, aber nicht im produktiven Einsatz. Leider setzt es sich immer mehr durch und ich werde wohl gezwungen sein, es zu lernen.
Dussel schrieb: > Da die Frage ja nicht auf Mikrocontroller bezogen war, kann ich auch > meine Stimme für Python geben. Ich muss mich korrigieren. Das Thema steht ja unter "Mikrocontroller und Digitale Elektronik".
LUA vielleicht? Ich hatte allerdings nur Erfahrungen auf PC Ebene sammeln können. Grüsse, René
Stefanus F. schrieb: > Dann geht man eben noch einen Schritt weiter nach Java. Natürlich nicht > auf einem ATtiny. Warum nicht? ;)
Mike schrieb: > Forth hatte einige fanatische Anhänger, hat mich aber eher an > HP-Taschenrechnerprogramme erinnert. Spätestens, wenn man größere > Datenstrukturen brauchte, wurde es ein ziemlich undurchschaubarer > Krampf. Ich glaube kaum, dass das heute noch jemand für ernsthafte > Anwendungen benutzt. Das Problem an Forth ist in meinen Augen, dass es recht lang braucht bis man versteht was Forth von allen anderen Sprachen unterscheidet. Forth ist die einzig mir bekannte (halbwegs standardisierte) Sprache, bei der der vollständige Interpreter und Compiler locker in einen 16kB ATtiny passt. Ein Compiler der runter zu Maschinencode compiliert und damit beinahe native Geschwindigkeit erreicht. Das ist ein absolutes Novum und ich versteh nicht wieso das von der Forth Community nicht öfter angesprochen wird.
Embedded ist zu 90% C/C++ und das wird sich so bald auch nicht ändern.
Vincent H. schrieb: > Ein Compiler der runter zu Maschinencode compiliert und damit beinahe > native Geschwindigkeit erreicht Wie schafft der das ohne die hochkomplexen Optimierungsalgorithmen welche bspw. der GCC für C und C++ nutzt?
> Die Jugend spricht Python. > Auf dem Mikrocontroller spricht sie MicroPython. Olaf schrieb >Das aendert sich sobald sie von der Uni in die Entwicklungsabteilung >wechseln oder sie verschwinden sehr schnell wieder aus der Firma. .-) Ich glaube, das geht eher anders: Fortschrittliche Entwicklungsabteilungen nehmen Python, ansonsten werden sie nicht mehr lange existieren, weil von der Entwicklung überholt ;-) Ich kenne Leute von Google, die ja nur die Besten nehmen: Die machen Python. Die Mikrocontroller werden immer Leistungsfähiger, also braucht man auch leistungsfähige Sprachen. Und nicht nicht umsonst heißt der RasPi: RasPi
Peter S. schrieb: > Embedded ist zu 90% C/C++ und das wird sich so bald auch nicht ändern. kann man so nicht sagen. Es gibt auch zunehmend einige modellbasierte Ansätze zumindest für die High-Level Funktionen: - Matlab/Simulink - ASCET/SD (Automotive) - Scade (Luftfahrt zertifiziert) Gruß Anja
Peter S. schrieb: > Embedded ist zu 90% C/C++ und das wird sich so bald auch nicht ändern. Das denke ich auch.
Cornelius schrieb: > Die Mikrocontroller werden immer Leistungsfähiger, also braucht man auch > leistungsfähige Sprachen. C/C++ als nicht leistungsfähig zu bezeichnen hat auch was :D
Cornelius schrieb: > Die Mikrocontroller werden immer Leistungsfähiger, also braucht man auch > leistungsfähige Sprachen. Was eigentlich nur bedeutet, dass sich Assembler immer mehr auf dem Rückzug befindet und seine Anteile größtenteils an C/C++ abgibt.
Niklas Gürtler schrieb: > Vincent H. schrieb: >> Ein Compiler der runter zu Maschinencode compiliert und damit beinahe >> native Geschwindigkeit erreicht > > Wie schafft der das ohne die hochkomplexen Optimierungsalgorithmen > welche bspw. der GCC für C und C++ nutzt? Bei komplexeren Aufgaben natürlich gar nicht, keine Chance. Aber das hab ich damit auch nicht gemeint. Das höchste der Gefühle ist Konstanten falten oder so, das geht sich in den paar kB aus. Trotzdem sind von Forth übersetzte Scripts im Endeffekt Maschinencode. Natürlich wird hier oder dort mal ein ldr/str zu viel stehen, allein schon durch den Stack-basierten Ansatz, aber das wird trotz alledem flotter sein als ein Bytecode Interpreter. Und die Kombination aus geringem Platzbedarf und der Geschwindigkeit macht Forth eigentlich wahnsinnig attraktiv als Skriptsprache für Systeme wo Python und Lua zu groß und langsam ist. /edit Und nur um das nochmal zu unterstreichen. Das letzte mal als ich es benutzt hab hat Python mindestens ~100k und Lua ~30k Flash gebraucht. Das sind einfach komplett andere Dimensionen.
:
Bearbeitet durch User
Mike schrieb: > Ich glaube kaum, dass das heute noch jemand für ernsthafte > Anwendungen benutzt. Es seien mal nur 2 genannt: Postscript! Ist ein mehr oder weniger direkter Forth Abkömmling. Durchaus, heute noch sehr weit verbreitet. Die zu verwaltenden Datenmengen sind im Grafikbereich erheblich. Open Firmware! Auch heute noch im Einsatz. Das Forth Prinzip findet sich also auch heute noch im professionellen Einsatz. Allerdings eher im Verborgenen. Niklas Gürtler schrieb: > Wie schafft der das ohne die hochkomplexen Optimierungsalgorithmen > welche bspw. der GCC für C und C++ nutzt? Braucht es nicht. Es wohnt dem Prinzip inne. Im Zweifel baut man sich einen angepassten Compiler. Selbst auf einem ATMega328p sind mehrere Interpreter und Compiler gar kein Problem, sogar mehr als üblich. Der Standard. Eigentlich gibt es keine Forth Syntax, außer der Grundregel: "Forth Worte werden durch Whitespaces von einander getrennt" Auch Datentypen gibt es nicht. Allgemein kann man sagen: In anderen Programmiersprachen, muss man das Problem solange modellieren, bis man es in der Sprache abbilden kann. In Forth passt man die Sprache solange an, bis sie das Problem optimal widerspiegelt. Forth ist nicht wirklich eine Programmiersprache. Es ist eher eine Philosophie, oder ein Betriebsystem.
Vincent H. schrieb: > Und die Kombination aus geringem Platzbedarf und der Geschwindigkeit > macht Forth eigentlich wahnsinnig attraktiv ... wenn nur die sehr verquere Logik dieser Sprache nicht wäre. Man muss schon irgendwie sehr früh in der Kindheit mit HP-Taschenrechnern "gepolt" werden, um mit Forth irgendwas anfangen zu können. (Ich hatte einen der wenigen "Homecomputer", die mit Forth ausgestattet waren - das war eine technisch schickere Alternative zum ZX81, aber ob die Verkaufszahlen von dem Ding in Deutschland mehr als zwei- oder vielleicht dreistellig waren?)
M. K. schrieb: > Cornelius schrieb: >> Die Mikrocontroller werden immer Leistungsfähiger, also braucht man auch >> leistungsfähige Sprachen. > > C/C++ als nicht leistungsfähig zu bezeichnen hat auch was :D Wenns aber stimmt. Eine Maschinensteuerung bedienbar auf dem Niveau von Türdichtgummieinklopfer ist mit einem darauf optimierten Framework besser zusammengestrickt als mit C++ oder anderenen CPU-nahen Code-GeGurke. Das ganze Konzept Programmiersprache gehört im Rahmen der technischen Erneuerung auf den Prüfstand, insbesonders was seit Jahrzehnten völlig überzogen als "Hochsprache" bezeichnet werden aber immer noch auf unterste Dateneben fokusieren. Anwendungsspezifische Scriptsprachen und Frameworks sind das Mittel der Zeit.
Stefanus F. schrieb: > Ich kam mit dem LabView Style durch Lego MindStorms NXT in Kontakt. Das > ist die größte Verschwendung von Arbeitszeit, die ich je gesehen habe. > Diese Diagramme sind ab einer gewissen Komplexität nicht einmal > übersichtlicher, als Quelltext. Also du urteilst nach ein paar Stunden Lego in einer abgespeckten Labview Umgebung über die Sprache? Traurig. Aber klar, Hardcore C Pointerprofies sind eh unbelehrbar. Auf uC Ebene ist LV Mist, aber für Anwendung auf PC Basis, wie Kalibrationsanlagen, Mess- und Prüfaufbauten in Verbindung mit der National Instruments eigenen Hardware ziemlich alternativlos. Und bevor du meinst ich habe keine Ahnung. Ich programmiere in C. Für Messeautomatisierung nutze ich Labview. Daher kenne ich beide Seiten und deren Vor- und Nachteile. Und ja, man kann den Quellcode auch übersichtlich gestalten, das erfordert genau wie bei textbasierten Sprachen eine gewisse Disziplin.
Rufus Τ. F. schrieb: > Man muss > schon irgendwie sehr früh in der Kindheit mit HP-Taschenrechnern > "gepolt" werden, um mit Forth irgendwas anfangen zu können. Hatte nie einen solchen Taschenrechner. Und dennoch war Fort meine erste "Hochsprache", wenn ich das mal so nennen darf. Hauptsächlich Heizungssteuerungen (damals waren die Heizungen noch ohne jede Elektronik) und Lichtsteuerungen für Veranstaltungsräume. Ich bin der Forth Welt sehr dankbar. Habe viel daraus gelernt. Auch und gerade, die Welt aus anderen Blickwinkeln zu betrachten.
Jan schrieb: > Also du urteilst nach ein paar Stunden Lego in einer abgespeckten > Labview Umgebung über die Sprache? Ich habe auch andere Diagramm-basierte Programmiersprachen ausprobieren müssen. Zum Beispiel BPEL (würg), nutz die Firma wo ich arbeite leider. Aber nicht mehr lange, es wird bereits Schrittweise ausgebaut. Grafisch Programmieren ist halt nicht meine Welt. Ich weiß dass manch anderer damit prima zurecht kommt. Ich habe nichts dagegen. Das Schöne ist doch, dass man oft die freie Wahl hat, ob man Diagramme malen will, oder Text schreibt. Außerdem gibt es dazwischen noch reichlich hybride Lösungen. Ich nehme mal stark an, dass Labview beides kann (nur nicht die abgespeckte Lego Variante).
Rufus Τ. F. schrieb: > Vincent H. schrieb: >> Und die Kombination aus geringem Platzbedarf und der Geschwindigkeit >> macht Forth eigentlich wahnsinnig attraktiv > > ... wenn nur die sehr verquere Logik dieser Sprache nicht wäre. Man muss > schon irgendwie sehr früh in der Kindheit mit HP-Taschenrechnern > "gepolt" werden, um mit Forth irgendwas anfangen zu können. > > (Ich hatte einen der wenigen "Homecomputer", die mit Forth ausgestattet > waren - das war eine technisch schickere Alternative zum ZX81, aber ob > die Verkaufszahlen von dem Ding in Deutschland mehr als zwei- oder > vielleicht dreistellig waren?) RPN ist absolut grausig ohne Frage. Dummerweise sorgt aber gerade jene Notation dafür dass man mit einem Single-Pass Parser für Interpreter und Compiler auskommt. Wen man sich überlegt wie absurd komplex dazu im Vergleich das Parsen von C oder (Gott bewahre) C++ ist...
> BASIC und Pascal
gibt's auch schon seit Jahrzehnten und werden auch weiterentwickelt.
Visions Kraft schrieb: > Das ganze Konzept Programmiersprache gehört im Rahmen der technischen > Erneuerung auf den Prüfstand, insbesonders was seit Jahrzehnten völlig > überzogen als "Hochsprache" bezeichnet werden aber immer noch auf > unterste Dateneben fokusieren. Ich empfehle ja, Programmiersprachen durch angepasste KI zu ersetzen.
Beitrag #5650824 wurde von einem Moderator gelöscht.
Beitrag #5650836 wurde von einem Moderator gelöscht.
Beitrag #5650842 wurde von einem Moderator gelöscht.
Beitrag #5650848 wurde von einem Moderator gelöscht.
Stefanus F. schrieb: > Grafisch Programmieren ist halt nicht meine Welt. Das kann ich nachvollziehen, ist nicht jedermanns Sache. Labview ist sehr mächtig, aber halt auf uC Ebene nicht der bringer. Es gibt zwar Module wie Labview Embrdded von Schmitt Engineer in aus der Schweiz, die bringen das auf den Blackfin Prozessor, oder auch Addons für Arduino (Controllino) aber das ist nicht so effizient wie C, Rust oder C++.
Mike schrieb: > Seit 40 Jahren ist die Programmiersprache C quasi Industriestandard im > µC bzw. Embedded - Bereich. Gibt es da inzwischen Alternativen - > Assembler natürlich ausgenommen? Diverse und schon lange, allerdings oft in einer Kombination aus mehreren Sprachen, etwa als Duo aus interpretierter Hochsprache und in C oder Assembler geschriebenen Modulen. Ein konkretes Beispiel dafür ist Lua. NodeMCU für die Espressif-Systeme, die Verwendung von Lua in den Fritzboxen, im Rahmen von OpenWrt/LEDE und CHDK zur Firmwareerweiterung auf Canon-Knipsen sind Beispiele. Lesestoff z.B. https://stackoverflow.com/questions/4448835/alternatives-to-lua-as-an-embedded-language http://www.ethernut.de/en/firmware/nutlua.html Für Systeme, die bzgl. Speicher - das ist der limitierende Faktor - nicht potent genug sind, empfehle ich weiterhin, Rust im Auge zu behalten. Leider hat die Mozilla Foundation wichtigere Probleme, als diesen Zweig der Rust-Entwicklung voranzutreiben, insofern hält sich der Erfolg bzgl. "zero cost abstraction" bislang noch in Grenzen. Anders als bei Python oder Lua gibt es aber keine prinzipiellen Hinderungsgründe, warum nicht auch wirklich kleine Microcontroller damit programmiert werden könnten. Hier erzählt jemand etwas von einem aktuellen Kleinprojekt https://www.youtube.com/watch?v=g25xsK3HKkE Slides dazu http://github.jcreedon.com/static/EmbeddedWithRustSlidesTeardown2018.pdf
Vincent H. schrieb: > Trotzdem sind von Forth übersetzte Scripts im Endeffekt Maschinencode. > Natürlich wird hier oder dort mal ein ldr/str zu viel stehen, allein > schon durch den Stack-basierten Ansatz, aber das wird trotz alledem > flotter sein als ein Bytecode Interpreter. > > Und die Kombination aus geringem Platzbedarf und der Geschwindigkeit > macht Forth eigentlich wahnsinnig attraktiv als Skriptsprache für > Systeme wo Python und Lua zu groß und langsam ist. Ja, Stichwort Stack-Maschine. Damit haben die meisten Programmierer vom High-Level her ihre Schwierigkeiten. Es gibt ja auch vom Forth-Erfinder Chuck Moore eine echte Forth-CPU, interessant ist auch die offene Implementierung 'J1'. Da Python ebenfalls eine Stackmaschine ist, lässt sich ein Subset davon gut in Forth emulieren, bzw. Python-Code direkt für eine Stackmaschine übersetzen. Generell sind die Stackmaschinen nicht sonderlich schnell, aber mit cleverer Optimierung kann man extrem platz- und stromsparend rechnen, dazu kommt eine verbesserte Fehlertoleranz ggü. Registerbasierten CPUs. Komplette gehärtetete netzwerkfähige OS passen so mal eben in unter 32 kB on Chip-RAM. Forth ist aber insofern keine Scriptsprache, sondern das absolute Minimum an Abstraktion einer Stackmaschinen-Asemblersprache. Da muss auf einer Stackmaschinen-Architektur nichts mehr optimiert werden. Andersrum, d.h. C auf eine SM-Architektur optimal zu übersetzen, ist schon kniffliger. Aber zum Thema zurück: An C/C++ geht nichts vorbei, wenn man einen uniformen Source portabel und möglichst maschinennah für viele verschiedene Architekturen übersetzen will. Da kann die Sprache noch so viele Unzulänglichkeiten haben, es geht dann einfach um eine nackte Ingenieurstätigkeit, die so gar nichts mit Fanboy-Aspekten zu tun hat. Ich habe es mir so auch angewöhnt, nur noch Leute anzustellen/beauftragen, denen die Wahl der Sprache a priori egal ist, und die sich die Finger auch mit intensivem Testen schmutzig machen. Wenn das Projekt Ada erfordert, wird eben Ada geschrieben. Aber ich erwarte, dass jemand C so gut kann, dass er die ganzen "Pitfalls" kennt (wo leben Datenstrukturen, wem gehören sie).
Wolfgang S. schrieb: > Für Systeme, die bzgl. Speicher - das ist der limitierende Faktor - > nicht potent genug sind, empfehle ich weiterhin, Rust im Auge zu > behalten. Leider hat die Mozilla Foundation wichtigere Probleme, als > diesen Zweig der Rust-Entwicklung voranzutreiben, insofern hält sich der > Erfolg bzgl. "zero cost abstraction" bislang noch in Grenzen. Anders > als bei Python oder Lua gibt es aber keine prinzipiellen > Hinderungsgründe, warum nicht auch wirklich kleine Microcontroller damit > programmiert werden könnten. Der Link der weiter oben gepostet wurde zeigt dass sich zumindest ein bisschen was tut: https://rust-embedded.github.io/book/ Das dürfte recht aktuell sein, weil als ich im Sommer ein wenig gerostet bin gabs irgendwie nur so ein paar Blogposts hier und dort...?
Beitrag #5650864 wurde von einem Moderator gelöscht.
Jan schrieb im Beitrag #5650864:
> oder ein Troll bist.
Ja, das stimmt!
Ich beantrage hiermit die Löschung aller deiner Beiträge in diesem
Thread.
Jan und Jan, beschließt was ihr möchtet. Ihr werde ein wesentlich ruhigeres leben führen, wenn ihr manche Gedanken (wie diesen) für Euch behaltet. Wenn euch jemand blöd kommt, antwortet einfach nicht. Das ist besser. Mir fällt das auch schwer. @Arduino Fanboy D: Musst du immer wieder Streit provozieren? Du bist alt genug, dich besser benehmen zu können.
Stefanus F. schrieb: > Wenn Dir > jemand blöd kommt, antworte einfach nicht. Das ist besser. Hiermit überreiche ich dir die Merkbefreiung: https://www.knuffingen.de/stadt-portal/aktuell/merkbefreiung-standard-formular/
Wer benoetigt denn Portabilitaet. Im Projekt die Prozessorfamilie wechseln ? Was soll das ? Im Projekt von 8 auf 32 bit gehen ?
Beitrag #5650895 wurde von einem Moderator gelöscht.
Man braucht in FORTH, wie in C auch, eine gewisse Übung und eine Vorstellung davon, was im Inneren passiert. Was dem C-Anfänger die Sequence-Points bedeuten, sind in FORTH eben die Parameterreihenfolgen. Beides ist an gewissen Stellen auch mal etwas schwieriger. Man kommt aber damit, mit etwas Erfahrung gut klar. Das scheint mir in beiden Sprachen so zu sein. Ich meine, die Sprache und das System vereint Einfachheit und Eleganz in sich. Sie wurde, ihrem Ursprung nach, für Steuerungssysteme gedacht. In der jüngeren Zeit sind UEFI und OpenFirmware relevant geworden. Aktuell werden Empbedded-Systeme, bei denen Produktivität gefragt ist, in FORTH programmiert. Es gibt eine ganze Reihe Firmen, die aktuell aktiv sind. Ebenso wie in Bezug auf andere Sprachen, wurde auch für FORTH über Objektorierentierung und vieles andere nachgedacht und das implementiert. http://forth.org/fd/FD-V10N2.pdf Vielleicht ist das nicht für jeden etwas, aber ich denke, es lohnt sich, sich damit einmal näher auseinander zu setzen; und sei es nur um seinen Horizont zu erweitern.
S. R. schrieb: > Visions Kraft schrieb: >> Das ganze Konzept Programmiersprache gehört im Rahmen der technischen >> Erneuerung auf den Prüfstand, insbesonders was seit Jahrzehnten völlig >> überzogen als "Hochsprache" bezeichnet werden aber immer noch auf >> unterste Dateneben fokusieren. > > Ich empfehle ja, Programmiersprachen durch angepasste KI zu ersetzen. "Programmieresprachen" oder "Programmierer" selbst ersetzen -> das ist die Frage - die Antwort ist nicht selten deprimierend: https://www.youtube.com/watch?v=0OqSwzO1qn0
Beitrag #5650906 wurde von einem Moderator gelöscht.
Beitrag #5650980 wurde von einem Moderator gelöscht.
Beitrag #5650999 wurde von einem Moderator gelöscht.
Beitrag #5651013 wurde von einem Moderator gelöscht.
Beitrag #5651022 wurde von einem Moderator gelöscht.
Beitrag #5651059 wurde von einem Moderator gelöscht.
Beitrag #5651061 wurde von einem Moderator gelöscht.
Beitrag #5651062 wurde von einem Moderator gelöscht.
Beitrag #5651093 wurde von einem Moderator gelöscht.
Beitrag #5651094 wurde von einem Moderator gelöscht.
Beitrag #5651098 wurde von einem Moderator gelöscht.
Apropos Forth ... Für den Parallax-Propeller2 wird wohl Tachyon-Forth eingebaut haben: http://forums.parallax.com/discussion/167868/taqoz-tachyon-forth-for-the-p2-boot-rom
Vincent H. schrieb: > RPN ist absolut grausig ohne Frage. Sehe ich überhaupt nicht so. RPN finde ich um LÄNGEN einfacher als z.B. den Operatorenvorrang von C oder die Einschränkungen in der Registerverwendung im Z80. > Dummerweise sorgt aber gerade jene Notation dafür > dass man mit einem Single-Pass Parser für Interpreter > und Compiler auskommt. Naja, und wo ist der praktische Gewinn? Also, was habe ich davon, dass jedes embedded system seinen eigenen Compiler mit herumschleppt? Gerade bei so kleinen Zielsystemen drängt sich doch Crossentwicklung auf. Auf der anderen Seite ist es natürlich sehr nett, sich auf dem Steuerrechner einloggen zu können und das laufende System beobachten oder in Grenzen modifizieren zu können -- nur will niemand deswegen die gesamte Entwicklungsarbeit direkt auf dem Zielsystem machen. Da wäre ein Mittelweg vernünftig... > Wen man sich überlegt wie absurd komplex dazu im > Vergleich das Parsen von C oder (Gott bewahre) C++ > ist... Das stimmt zwar -- aber wo ist der Schaden, wenn das auf dem Host gemacht wird? Ich gestehe ja die Eleganz des FORTH-Ansatzes zu, aber ich sehe nicht, wo sich das als Vorteil im Arbeitsablauf auszahlt. Ich habe mit FORTH nur ein paar mal herumgespielt, weil ich die Kernidee eigentlich bestechend finde. Echt grauslich ist für mein Empfinden - die komplette Abwesenheit eines Typsystems, - die Sonderzeichenwüste und - der verhältnismäßig großen Mindestwortschatz, den man beherrschen muss, um überhaupt irgend etwas zum Laufen zu bekommen. Die Quelltexte fand ich genauso kryptisch wie C-Quellen, aber längere Worte oder weniger Sonderzeichen will man ja nicht, weil das zu Lasten der Codegröße geht -- womit wir wieder beim Anfang sind.
Egon D. schrieb: > Naja, und wo ist der praktische Gewinn? Also, was habe > ich davon, dass jedes embedded system seinen eigenen > Compiler mit herumschleppt? Gerade bei so kleinen > Zielsystemen drängt sich doch Crossentwicklung auf. > > Auf der anderen Seite ist es natürlich sehr nett, sich > auf dem Steuerrechner einloggen zu können und das > laufende System beobachten oder in Grenzen modifizieren > zu können -- nur will niemand deswegen die gesamte > Entwicklungsarbeit direkt auf dem Zielsystem machen. Da > wäre ein Mittelweg vernünftig... Deshalb nenne ich Forth auch eine Skriptsprache. Für mich ist sie das und ich benutze sie so. Wer nicht weiß wozu er eine Skriptsprache braucht, der benötigt vermutlich einfach keine? Für alle anderen ist Forth sicher einen Blick Wert, auch wenn es neben Python und Lua ziemlich... erm retro erscheint.
vn nn schrieb: > Vor randalierenden Pointern, unterminierten Strings, Arrayzugriffen ins > Leere kann C prinzipbeding nicht schützen. Muss es auch nicht. Es ist Sache des Programmierers, solches zu verhindern. Ein Messer kann auch prinzipbedingt nicht davor schützen, dass man sich ins eigene Fleisch schneidet. Wer ein Werkzeug benutzt, muss wissen, was er damit tut. Idiotensicheres ist selten effektiv. Und dass jeder Idiot sich Prorammierer nennen kann, ist als Ziel auch recht fragwürdig.
Egon D. schrieb: > Ich gestehe ja die Eleganz des FORTH-Ansatzes zu, aber > ich sehe nicht, wo sich das als Vorteil im Arbeitsablauf > auszahlt. Habe auch schon öfter auf Forth hingewiesen und würde - nebenbei gesagt - Eleganz nicht an den Anfang einer Bewertung stellen, aber das ganze Konzept ist wirklich Elegant. Und der Gang der Dinge ist doch immer wieder dieser: ein Ingenieur kommt im Laufe seiner Ausbildung irgendwann mal mit Programmiersprachen in Berührung. Zu meiner Zeit war das Fortran auf Lochkarte. Wenn dann später im Beruf ein Kontroller gebraucht wurde, dann war das sowas wie Z80 mit Pascal, das sich jemand, der sich durch Fortran gequält hatte, ausreichend schnell "draufschaffen" konnte. Hatte damals noch als HiWi vergeblich versucht, unseren Controller mit Forth zu verheiraten und obwohl ich einen lauffähigen Code hatte, wurde dies vom Jungunternehmer als "zu exotisch und nicht wartbar" schlicht abgelehnt. Natürlich hat sich nie jemand die Mühe gemacht, in den Code wirklich einzusteigen. Und so wird heute auch weiterhin das genommen, was der Chef will oder was der Entwickler kann. Und wenn gar der Kunde die Software vorschreibt, dann wird halt das zusammen gestückelt. Lange Rede kurzer Sinn: wenn genügend Menschen sagen, der rote Baum ist blau, dann ist das so :-) Gruß Rainer
Vincent H. schrieb: > Egon D. schrieb: >> Naja, und wo ist der praktische Gewinn? Also, was habe >> ich davon, dass jedes embedded system seinen eigenen >> Compiler mit herumschleppt? Gerade bei so kleinen >> Zielsystemen drängt sich doch Crossentwicklung auf. >> >> Auf der anderen Seite ist es natürlich sehr nett, sich >> auf dem Steuerrechner einloggen zu können und das >> laufende System beobachten oder in Grenzen modifizieren >> zu können -- nur will niemand deswegen die gesamte >> Entwicklungsarbeit direkt auf dem Zielsystem machen. Da >> wäre ein Mittelweg vernünftig... > > Deshalb nenne ich Forth auch eine Skriptsprache. Für mich > ist sie das und ich benutze sie so. Wer nicht weiß wozu > er eine Skriptsprache braucht, der benötigt vermutlich > einfach keine? Den Einwand verstehe ich nicht. Wo ist der Zusammenhang zu meinen Text? Ich habe nicht kritisiert, dass Forth eine Scriptsprache ist (das ist AWL auf der SPS nach meinem Verständnis auch), ich habe nur gefragt, wo der Gewinn für den Arbeitsablauf ist, dass auf dem Zielsystem ein komplettes Entwicklungs- system läuft. Ich würde keine komplette Steuerungsanwendung auf einem Mikrocontroller entwickeln wollen -- aber nur in diesem Falle wäre das ein Vorteil.
Rainer V. schrieb: > Hatte damals noch als HiWi vergeblich versucht, > unseren Controller mit Forth zu verheiraten und > obwohl ich einen lauffähigen Code hatte, wurde > dies vom Jungunternehmer als "zu exotisch und > nicht wartbar" schlicht abgelehnt. Natürlich hat > sich nie jemand die Mühe gemacht, in den Code > wirklich einzusteigen. Naja, das ist ja der Knackpunkt: Mit einem exotischen System kommt man gegen den Mainstream nur an, wenn der Exot etwas kann, was der Mainstream nicht kann -- aber alle haben wollen :) Mit Blick auf Forth frage ich also: Was könnte das sein? Aus meiner Sicht passt das Leistungsprofil von Forth nicht optimal auf moderne Steuerungsanwendungen.
Egon D. schrieb: > Ich habe nicht kritisiert, dass Forth eine Scriptsprache > ist (das ist AWL auf der SPS nach meinem Verständnis auch), > ich habe nur gefragt, wo der Gewinn für den Arbeitsablauf > ist, dass auf dem Zielsystem ein komplettes Entwicklungs- > system läuft. Ich würde keine komplette Steuerungsanwendung > auf einem Mikrocontroller entwickeln wollen -- aber nur in > diesem Falle wäre das ein Vorteil. Hi, Gewinn im Arbeitsablauf gibt es halt immer nur dann, wenn du einen hast, der die gerdade geforderte Qualifikation hat! Und das bestimmt die Verbreitung einer Sprache. Denke immer wieder gern an einen Bewerber auf einen Hardware-Entwickler-Platz, der in seinen Papieren "gängige Controller und Betriebssysteme" angegeben hatte. Im Gespräch stellte sich heraus, dass er eine simple OP-Schaltung nicht erklären konnte und mit Betriebssytem - ohne Quatsch - stolz sein Programm für irgendeinen Adurnio (ich nenne die so) zeigte, mit dem berühmnten "Hello World". Fragen nach "richtigen" Betriebssystemen hat er mit völligem Unverständnis beantwortet und hat nach seiner Ablehnung unseren Betriebsrat noch wochenlang mit abstrusen Anfragen beschäftigt! Gruß Rainer
Egon D. schrieb: > Den Einwand verstehe ich nicht. Wo ist der Zusammenhang zu > meinen Text? > > Ich habe nicht kritisiert, dass Forth eine Scriptsprache > ist (das ist AWL auf der SPS nach meinem Verständnis auch), > ich habe nur gefragt, wo der Gewinn für den Arbeitsablauf > ist, dass auf dem Zielsystem ein komplettes Entwicklungs- > system läuft. Ich würde keine komplette Steuerungsanwendung > auf einem Mikrocontroller entwickeln wollen -- aber nur in > diesem Falle wäre das ein Vorteil. Ein System dass über eine eingebettete Skriptsprache verfügt lässt sich viel leichter konfigurieren. Man hat eine Möglichkeit ohne Firmware Update ins Laufzeitverhalten der Software einzugreifen. Wenn irgendein Kunde mit einem XY Feature Sonderwunsch ankommt, dann muss nicht extra für den einen Kunden ein Stückerl Code geschrieben werden, dass sonst kein anderer Mensch braucht. Usw. usf. In anderen Branchen (etwa Spieleentwicklung) wo diese einfache Möglichkeit zum Konfigurieren ständig gebraucht wird sind eingebettete Skriptsprachen quasi Industriestandard.
Vincent H. schrieb: > Wolfgang S. schrieb: >> Für Systeme, die bzgl. Speicher - das ist der limitierende Faktor - >> nicht potent genug sind, empfehle ich weiterhin, Rust im Auge zu >> behalten. Leider hat die Mozilla Foundation wichtigere Probleme, als >> diesen Zweig der Rust-Entwicklung voranzutreiben, insofern hält sich der >> Erfolg bzgl. "zero cost abstraction" bislang noch in Grenzen. Anders >> als bei Python oder Lua gibt es aber keine prinzipiellen >> Hinderungsgründe, warum nicht auch wirklich kleine Microcontroller damit >> programmiert werden könnten. > > Der Link der weiter oben gepostet wurde zeigt dass sich zumindest ein > bisschen was tut: > https://rust-embedded.github.io/book/ Ja, hatte ich gesehen. Der Vortrag, d.h. das YT-Video und die Slides von Jacob Creedon, auf die ich verlinkt hatte, benutzen die da beschriebene Toolchain und auch das STM32F303VCT6-Demoboard. > > Das dürfte recht aktuell sein, weil als ich im Sommer ein wenig gerostet > bin gabs irgendwie nur so ein paar Blogposts hier und dort...? Und dann gibt es noch das AVR-Rust-Projekt (https://github.com/avr-rust), welches noch ziemlich am Anfang steht. Ob das irgendwann Fahrt bekommt steht in den Sternen. Ich persönlich finde die kleineren Prozessoren interessanter und glaube nicht, daß Controller mit sehr wenig Speicher und kleiner Wortbreite mittelfristig komplett verschwinden werden. Ob das als Betätigungsfeld für Rust attraktiv genug ist, wird sich zeigen.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.