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.
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 ;)
> 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:> 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.
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
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
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.
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".
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.
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
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.
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...
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.
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-languagehttp://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...?
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.
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
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.
