Forum: Mikrocontroller und Digitale Elektronik Programmiersprachen jenseits von "C"


von Mike (Gast)


Lesenswert?

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.

:
von Alex G. (dragongamer)


Lesenswert?

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.

von Dateisammler (Gast)


Lesenswert?

Bleib bei C. Andere Sprachen kommen und gehen, aber nur C hält sich seit 
Jahrzehnten, wohl nicht ohne Grund.

von Alex G. (dragongamer)


Lesenswert?

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 ;)

von Theor (Gast)


Lesenswert?

Eine andere Möglichkeit, die nur nicht "modern" ist, sondern auch schon 
recht alt, ist FORTH.

von Olaf (Gast)


Lesenswert?

> 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

von Jan (Gast)


Lesenswert?

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.

von Alex G. (dragongamer)


Lesenswert?

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.

von Christian M. (Gast)


Lesenswert?

BASIC und Pascal

Gruss Chregu

von M. K. (sylaina)


Lesenswert?

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.

von Alex G. (dragongamer)


Lesenswert?

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.

von vn nn (Gast)


Lesenswert?

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.

von M. K. (sylaina)


Lesenswert?

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? ;)

von M. K. (sylaina)


Lesenswert?

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 ;)

von ntldr (Gast)


Lesenswert?

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).

von vn nn (Gast)


Lesenswert?

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.

von Cornelius (Gast)


Lesenswert?

Die Jugend spricht Python.
Auf dem Mikrocontroller spricht sie MicroPython.

von Olaf (Gast)


Lesenswert?

> 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

von Auto (Gast)


Lesenswert?

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.
von Niklas Gürtler (Gast)


Lesenswert?

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

von Christian M. (Gast)


Lesenswert?

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

von Visions Kraft (Gast)


Lesenswert?

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
von Florian (Gast)


Lesenswert?

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... :-)

von Stefan F. (Gast)


Lesenswert?

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.

von M. K. (sylaina)


Lesenswert?

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 ;)

von segfault (Gast)


Lesenswert?

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.
von Stefan F. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Jemand (Gast)


Lesenswert?

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ß.

von Dussel (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Dussel (Gast)


Lesenswert?

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.

von Dussel (Gast)


Lesenswert?

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".

von René H. (Gast)


Lesenswert?

LUA vielleicht? Ich hatte allerdings nur Erfahrungen auf PC Ebene 
sammeln können.

Grüsse,
René

von M. K. (sylaina)


Lesenswert?

Stefanus F. schrieb:
> Dann geht man eben noch einen Schritt weiter nach Java. Natürlich nicht
> auf einem ATtiny.

Warum nicht? ;)

von Vincent H. (vinci)


Lesenswert?

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.

von Peter S. (Gast)


Lesenswert?

Embedded ist zu 90% C/C++ und das wird sich so bald auch nicht ändern.

von Niklas Gürtler (Gast)


Lesenswert?

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?

von Cornelius (Gast)


Lesenswert?

> 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

von Anja (Gast)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

Peter S. schrieb:
> Embedded ist zu 90% C/C++ und das wird sich so bald auch nicht ändern.

Das denke ich auch.

von M. K. (sylaina)


Lesenswert?

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

von Peter S. (Gast)


Lesenswert?

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.

von Vincent H. (vinci)


Lesenswert?

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
von Einer K. (Gast)


Lesenswert?

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.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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?)

von Visions Kraft (Gast)


Lesenswert?

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.

von Jan (Gast)


Lesenswert?

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.

von Einer K. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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).

von Vincent H. (vinci)


Lesenswert?

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...

von Purzel H. (hacky)


Lesenswert?

> BASIC und Pascal

gibt's auch schon seit Jahrzehnten und werden auch weiterentwickelt.

von S. R. (svenska)


Lesenswert?

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.
von Jan (Gast)


Lesenswert?

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++.

von Wolfgang S. (ws01)


Lesenswert?

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

von Fitzebutze (Gast)


Lesenswert?

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).

von Vincent H. (vinci)


Lesenswert?

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.
von Einer K. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Einer K. (Gast)


Lesenswert?

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/

von Clonosoft (Gast)


Lesenswert?

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.
von Theor (Gast)


Lesenswert?

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.

von Berufsrevolutionär (Gast)


Lesenswert?

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.
von Christoph M. (mchris)


Lesenswert?

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

von Egon D. (Gast)


Lesenswert?

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.

von Vincent H. (vinci)


Lesenswert?

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.

von Jobst Q. (joquis)


Lesenswert?

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.

von Rainer V. (a_zip)


Lesenswert?

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

von Egon D. (Gast)


Lesenswert?

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.

von Egon D. (Gast)


Lesenswert?

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.

von Rainer V. (a_zip)


Lesenswert?

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

von Vincent H. (vinci)


Lesenswert?

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.

von Wolfgang S. (ws01)


Lesenswert?

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