Hallo Community, ich möchte mich intensiver mit Embedded Systems und Echtzeitsystemen beschäftigen, finde aber den richtigen Einstieg nicht so recht. Im Studium habe ich ein wenig mit ADA (Ravenscar-Subset) auf STM32-Boards gearbeitet. Als Hobby habe ich außerdem erste Erfahrungen mit dem ESP32 und FreeRTOS gesammelt sowie grundlegende Programmierung mit AVR und C ausprobiert. Nun frage ich mich, welcher Weg langfristig am meisten Sinn ergibt. Besonders ADA mit Ravenscar hat mir viel Spaß gemacht: Die Sprache wirkte auf mich sehr logisch, robust und durchdacht – auch wenn die Programmierung teilweise etwas umständlich war. Ich bin mir unsicher, ob es sich lohnt, tiefer in ADA einzusteigen, oder ob meine Zeit in anderen Sprachen besser investiert wäre. Hat jemand von euch Erfahrung damit? Welche Sprachen und Tools werden heutzutage typischerweise für Echtzeitsysteme eingesetzt? Ist ADA noch relevant oder eher ein Auslaufmodell? Beeindruckt hat mich z.B. dieses Projekt hier – eine kleine 2D-Physik-Engine in ADA: https://github.com/Kidev/DemoAdaPhysics2D Allerdings ist das verwendete Board auch schon über 10 Jahre alt und mit rund 50 € definitiv nicht das günstigste. Wie seht ihr das? Hat ADA noch eine Zukunft in der Embedded-Welt – oder ist es eher ein Relikt vergangener Tage? Ich freue mich auf eure Meinungen und Erfahrungen!
Programmiersprachen kommen und gehen wie unterschiedliche Schraubendreher. Interessanter sind die Produkte, die nan damit baut. Wenn du irgendeine eine Programmiersprache drauf hast sammle damit Erfahrung. Diese auf eine andere Sprache umzusetzen, ist im Vergleich zu anderen Aufgaben eine der einfachen. Es ist besser, in wenigstens einer Programmiersprache sehr gut zu sein, als in vielen auf Anfänger Lebel.
> Wie seht ihr das? Hat ADA noch eine Zukunft in der Embedded-Welt – oder > ist es eher ein Relikt vergangener Tage? In der Embedded Welt hat derzeit nur ein Relikt vergangener Tage eine Zukunft und das heisst C. Vielleicht noch C++. Es gibt auch ein paar die bruellen jedem ins Ohr das die Zukunft Rust sein wird, aber solange die noch bruellen ist das sehr sehr unsicher. Aber zum programmieren gehoert sehr viel mehr als eine Programmiersprache. Sowas ist nur eine austauschbare Grundlage. Vanye
Erster Post von einer Neuanmeldung. Ist denn heute schon Freitag? Ach ne, nur langes Wochenende. Für diejenigen, die irgendwann später diesen Thread finden weil sie wirklich das Problem haben: Als "Studierter" in der Softwareentwicklung sollte man mehr können und wollen als nur Kodieraffe zu spielen. Programmiersprachen sind nur ein kleiner Teilaspekt der Softwareentwicklung. Man baut seine Karriere nicht um eine Programmiersprache oder ein Tool herum auf. Zumindest nicht als "Studierter" der Karriere machen will statt nur Kodieraffe zu sein. Programmiersprachen sind Handwerk von denen man mehrere kann. Was gerade benötigt wird. Man ist in der Lage sich schnell noch eine weitere drauf zu schaffen wenn es gefragt wird. Spezifisch für ADA: ADA spielt sich hauptsächlich in Nischen in der Luft- und Raumfahrt und in der Verteidigung ab. Kurz: Fliegt und/oder macht Bum. In Programmiersprachen-Indizes wie TIOBE ist ADA aus gegebenem Anlass aufsteigend (aktuell Platz 15 in TIOBE, vor 12 Monaten noch 22. Langzeitkurve über Jahrzehnte allerdings absteigend [1]). Aktuelle findet man auf https://de.indeed.com/q-ada-programmierung-jobs.html sechs "ADA"-Jobs. Bei gerade mal zwei scheint es wirklich um die Programmiersprache zu gehen. Dabei in beiden Fällen als "nett zu können" gewünscht, kein absolutes Muss. Branche? Fliegt und macht Bum. Wenn man da hin will und dort in eine ADA-Nische, dann lernt man halt mal ADA. Das schreibt man unten in seine Bewerbung mit rein. Nach den anderen Fähigkeiten mit denen man glänzen möchte. Neben all den anderen Programmiersprachen die man kann. __ [1] Programmiersprachen-Indizes sind mit Vorsicht zu genießen.
:
Bearbeitet durch User
Jup, ok Boomer. Habe die Kernaussage verstanden. Programmiersprachen sind Werkzeuge und und manche eignen sich besser für einen Job als andere. Und Tischler ist man nicht dann, sobald man die Kreissäge beherrscht. Kodieraffe möchte plane ich nicht zu werden, sondern ich möchte hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das richtige Werkzeug dafür. In der Hoffnung Tipps von Experten zu erhalten bot sich dieses Forum an. Danke dennoch für die Aufklärung.
David schrieb: > ich möchte > hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das > richtige Werkzeug dafür. Das Merkmal eines Hobbies ist das Fehlen der Sinnanforderung. Ob du da Basic, Assembler, ADA, oder Brainfuck verwendest, ist dein reines Privatvergnügen. Hilfreich ist es aber in all den Fällen, daß es eine brauchbare und gut verfügbare Toolchain für die Hardware deiner Wahl gibt. Abgesehen davon brauchts zum Entwurf eh gar keine Programmiersprache. Oliver
David schrieb: > Jup, ok Boomer. Bist Du jetzt enttäuscht, weil Deine Begeisterung für Ada nicht geteilt wird?
David schrieb: > Kodieraffe möchte plane ich nicht zu werden, sondern ich möchte > hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das > richtige Werkzeug dafür. In der Hoffnung Tipps von Experten zu erhalten > bot sich dieses Forum an. Wenn du es hobbymäßig für dich alleine machen willst: tu es. Wenn du dich mit gleichgesinnten austauschen willst: such mal nach "ADA" in Foren wie diesem. Dann siehst du, wieviele sich darüber mit dir potentiell unterhalten könnten/würden. Wenn du kaum Treffer bekommst, dann solltest du eher die Finger davon lassen. Verbreitet sind eben immer noch C, C++ und Assembler. <schulterzuck>
David schrieb: > Welche Sprachen und Tools werden heutzutage typischerweise für > Echtzeitsysteme eingesetzt? Auf der ganz harten Echtzeit im us-Bereich: C und C++. Wenn langsamer auch reicht: Java und Python. Aber in der Industrie programmiert kein Mensch in Ada. > Nun frage ich mich, welcher Weg langfristig am meisten Sinn ergibt. Dann schau mal von deinem "habe ich im Studium kennengelernt"-Suppenteller auf in die weite Welt hinein. Dann stellt sich diese Frage ganz anders: Was willst du in 10 Jahren machen?
Anwendungen .. Weltraum, Hochsicherheit. Seltsamerweise nicht
Automotive.
Der Vorteil von ADA ... stark typisiert und durchgesetzt. Mehrdeutige
Konstrukte wurden definiert, resp entfernt, sodass der Code maximal
Lesbar und sicher ist. Man kann sich darauf verlassen, dass der Code
macht, was er soll. Kein uups, Klammer vergessen und nicht gesehen. Kein
Eingerueckt und daher Kommentar. Mit extensiven Checks gleich eingebaut
zB
var u:integer range 0..10_000
// irgendwo muss natuerlich definiert werden was bei ueberlauf
geschieht.
Und Ada unterstuetzt Tasks und parallele Konzepte direkt in der Sprache,
ohne spezielle Konstrukte ohne Libraries.
task ABC is
entry READ( ..)
entry WRITE(..)
end;
task body ABC is
TABLE: ...
loop
select
accept READ( ...)
end
or
accept WRITE(...)
end
or terminate
end select
end loop
Wobei obiges Konstrukt einem WaitMultipleObject entspricht, welches
sonst eine eher aufwendige Geschichte ist. Hinter einem "select" steht
ein semaphorengeschuetzter Eingang, allenfalls auch eine Warteschlange.
Der Nachteil .. der Preis des Compilers. Es ist nahezu unendlich
aufwendig einen Compiler zertifizieren zu lassen. Fuer die Compiler gibt
es Testsuites, welche durchlaufen werden muessen. Bedeutet der Compiler
passt auf den Controller. Konfigurationsfehler darf es natuerlich nicht
geben.
Ich hab grad nachgeschaut, es gibt Referenzmanuals fuer 20$, zur
Inspiration. Meins war noch eine Ecke teurer.
Ich empfehl ein Studium davon, ohne es einzusetzen. Mir war der Compiler
damals zu teuer. Ich mag mich noch an etwas von gegen 10k erinnern, fuer
einen 8086, wobei ein Turbopascal fuer 100$ erhaeltlich war.
:
Bearbeitet durch User
David schrieb: > Kodieraffe möchte plane ich nicht zu werden, sondern ich möchte > hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das > richtige Werkzeug dafür. Am Ende ist es Code in einer formalen Sprache. Ob Matlab/Simulink/Stateflow, C/C++ oder UML. Kodieraffen sind heute genauso selten wie Tippsen. Und lass Dich nicht täuschen: Entwürfe in UML oder anderen "High-Level"-Sprachen sind oft eher vage Ideen unverstandener Genies.
Die Frage ist halt, was du damit machen willst. David schrieb: > Welche Sprachen und Tools werden heutzutage > typischerweise für Echtzeitsysteme eingesetzt? Auf die Allgemeinheit bezogen, C und C++. Oder ein Betriebssystem kommt drauf und dann wird 'ganz normal' programmiert. Soweit ich mitgekriegt habe, wird ADA in besonders sicherheitskritischen Bereichen verwendet, weil es von sich aus schon ziemlich sicher ist. Rust könnte ADA vielleicht ablösen, hat sich aber bisher noch nicht eindeutig durchgesetzt. Ich würde sagen: Wenn du ADA besonders magst, programmier ADA. Wenn du allgemein Embedded Systems programmieren willst, nimm C oder C++. Wenn du in den Sicherheitsbereich gehen willst, informiere dich über ADA und Rust.
Ada (Merke, keine Abkuerzung, wie 'ADA' suggeriert) ist schon nicht so doof, und wird auch noch verwendet. Die Firma Adacore bietet immer noch eine gut gewartete Toolchain an und der gnat-Compiler tickert hier in der Continuous Integration. Fuer die Hardware-Ansteuerung nehme ich dann aber doch lieber schlicht C, der Sprachenmischmasch laesst sich per Gnu-Compiler ja problemlos linken. Aber wie schon gesagt Nische und nur fuer Safety-Geschichten sinnvoll, wo die Anforderungen entsprechend stehen. Sonst laesst sich auch ein C-Code entsprechend fuer Safety verifizieren. Ist halt ein bisschen verbose/geschwaetzig, was gegenueber der Unlesbarkeit von Rust aber schon Vorteile beim re(verse)-Engineering hat. Siehe auch endlose Diskussionen zum verwandten VHDL.
> Siehe auch endlose Diskussionen zum verwandten VHDL. Wurde das nicht von System-C abgeloesst? Oder ist es in einer internationalen Welt wo alle cool auf English stehen nicht Zeit auf Verilog zu wechseln? :-p Vanye
Vanye R. schrieb: >> Siehe auch endlose Diskussionen zum verwandten VHDL. > > Wurde das nicht von System-C abgeloesst? Oder ist es in einer > internationalen Welt wo alle cool auf English stehen nicht Zeit auf > Verilog zu wechseln? :-p > > Vanye Ne dumme Frage: Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich beschreib ja damit ein Modell? Ada ist ja ne Programmiersprache, kann man die trotzdem mit VDHL vergleichen? lotta.
Danke an alle, die ihre Einschätzungen geteilt haben. Ich werde Ada vorerst ad acta legen und mir zunächst fundiertes Wissen zu Mikrocontrollern, Embedded- und Echtzeitsystemen aneignen und lernen, wie man diese Systeme in C programmiert. Ich denke, das ist langfristig einfach sinnvoller. Sobald die Wissensbasis vorhanden ist, kann ich mir mit Ada immer noch ein neues „Werkzeug“ erschließen. Mir ist klar geworden, dass die Programmiersprache, in der man Embedded Systems entwickelt, nur einen kleinen Teilaspekt der gesamten Entwicklung ausmacht. ;) Danke dafür. Galigrü David
Lotta . schrieb: > Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich > beschreib ja damit ein Modell? > Ada ist ja ne Programmiersprache, kann man die trotzdem > mit VDHL vergleichen? Auch wenn die Konstrukte unterschiedliche Auswirkungen haben, gibt es deutliche Überschneidungen. Zuweisungen, Bedingungen und Schleifen braucht man zum Beispiel in Beschreibungs- und Programmiersprachen. Da liegt dann die Ähnlichkeit.
Florian schrieb: > Lotta . schrieb: >> Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich >> beschreib ja damit ein Modell? >> Ada ist ja ne Programmiersprache, kann man die trotzdem >> mit VDHL vergleichen? > Auch wenn die Konstrukte unterschiedliche Auswirkungen haben, gibt es > deutliche Überschneidungen. So ist es. Es ist vor allem die (IHMO schreckliche ;-)) Syntax und weniger die Semantik, die VHDL von Ada geerbt hat. Aus https://en.wikipedia.org/wiki/VHDL:
1 | Influenced by |
2 | Ada,[1] Pascal |
3 | |
4 | Due to the Department of Defense requiring as much of the syntax as |
5 | possible to be based on Ada, in order to avoid re-inventing concepts |
6 | that had already been thoroughly tested in the development of |
7 | Ada,[citation needed] VHDL borrows heavily from the Ada programming |
8 | language in both concept and syntax. |
David schrieb: > Ich werde Ada > vorerst ad acta legen und mir zunächst fundiertes Wissen zu > Mikrocontrollern, Embedded- und Echtzeitsystemen aneignen und lernen, > wie man diese Systeme in C programmiert. Jaaa.... Das scheint mir ein brauchbarer Ansatz zu sein. Wobei ich über ADA nicht viel sagen kann, außer dass es mir im Data General AOS/VS Umfeld begegnet ist. Da hatten "wir" einen solchen Compiler und ein paar ADA Anwendungen im Einsatz. Also: Mehr als ein Seepferdchen ist da nicht dran. Den Freischwimmer habe ich, ungefähr zur gleichen Zeit, auf DG/UX und SCO Xenix in C gemacht. C++ ist erst viel später, mit Arduino, bei mir aufgetaucht. Wie auch immer, ich empfehle mit C++ zu beginnen. Es kann viele C Quellen einfach so mit übersetzen. Zumindest kann man C Objekt Dateien recht problemlos in C++ Hauptprogramme linken. C++ ist gegenüber C deutlich mächtiger, OOP, Templates, Operator Überladungen usw. Verallgemeinerungen: Wer C++ lernt, lernt die C Grundlagen gleich mit. Automatisch. Wer einmal eine prozedurale Sprache (z.B. C) richtig gelernt hat, hat es meist mit der OOP viel schwerer, als wenn er gleich damit angefangen wäre. Klarer: Der Paradigmenwechsel ist nur in eine Richtung leicht.
:
Bearbeitet durch User
Yalu X. schrieb: > Florian schrieb: >> Lotta . schrieb: >>> Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich >>> beschreib ja damit ein Modell? >>> Ada ist ja ne Programmiersprache, kann man die trotzdem >>> mit VDHL vergleichen? >> Auch wenn die Konstrukte unterschiedliche Auswirkungen haben, gibt es >> deutliche Überschneidungen. > > So ist es. Es ist vor allem die (IHMO schreckliche ;-)) Syntax und > weniger die Semantik, die VHDL von Ada geerbt hat. > > Aus https://en.wikipedia.org/wiki/VHDL: > >
1 | > Influenced by |
2 | > Ada,[1] Pascal |
3 | > |
4 | > Due to the Department of Defense requiring as much of the syntax as |
5 | > possible to be based on Ada, in order to avoid re-inventing concepts |
6 | > that had already been thoroughly tested in the development of |
7 | > Ada,[citation needed] VHDL borrows heavily from the Ada programming |
8 | > language in both concept and syntax. |
9 | > |
> Aus https://en.wikipedia.org/wiki/VHDL:
Boahhh, das ist ja ne neue Welt. :-O Da besteht ja wirklich
ein Zusammenhang zwischen den Sprachen!
Lotta.
1 | P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S |
2 | ((1.0/C_M_LSB_BH) * |
3 | G_M_INFO_DERIVE(T_ALG.E_BH))) |
Obige Zeile ADA-Code führte 1996 zu einen Schaden in Höhe von mehreren hundert Millionen Euro. Und das obwohl derselbe Code all die Jahre zuvor es bestens tat und "seinem Schöpfer" in Lohn und Brot hielt. Die Grund für diesen Zweck-Umkehr ist nicht im Code sondern im System (hier Wertebereich Sensor) zu suchen. Insofern biste mit "robuste Embedded Systeme" schon in der richtigen Richtung unterwegs. Und viel lernt man aus Fehlern. Also ist es eigentlich wurscht welche verschiedenen Programmiersprachen mal erlernt, Hauptsache man lernt was grundlegend Neues und füllt sich nicht mit kalten Kaffee ab. Also mein Tipp ist daher, sich eher ein exotisches System zaufzubauen (bspw. DIY-PCB mit Padauk MCU) und from the scratch aka vom Datenblatt weg zu programmieren. Dann beginnt man, das System zu verstehen. PS: Ref. für den Code oben: https://de.wikipedia.org/wiki/Ariane_V88
> Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich > beschreib ja damit ein Modell? > Ada ist ja ne Programmiersprache, kann man die trotzdem > mit VDHL vergleichen? ADA und VHDL teilen sich die selbe Entstehungsgeschicht, beide stammen von Department of Defense der USA, resp. wurden von diesen als die von ihren "Zuliefern" zu verwendeten Sprachen vorgeschrieben. Und dienten zu Beginn hauptsächlich zur Überprüfung der Requirements (auf Vollständigkeit/Widersprüche/...) und weniger der endgültigen Implementierung. Das man aus ADA wie aus Verilog/VHDL ausführbaren Code bekommt, wurde da eher als "Zugabe" verstanden. ADA und VHDL haben beide auch bestimmte "Features" die reine Programmiersprachen nicht kennen, wie "ranges" (Wertebereiche/Teilmengen von Typen) und Konstrukte zu Modellierung parall ("concurrently") laufender Funktionen ("tasks" resp. "processes") https://www.accessengineeringlibrary.com/content/book/9780071545815/back-matter/appendix4
Pandur S. schrieb: > er Nachteil .. der Preis des Compilers. Es ist nahezu unendlich > aufwendig einen Compiler zertifizieren zu lassen. Für "hobbymäßig" braucht man keinen zertifizierten Compiler - gnat ist kostenlos und braucht sich vor jenen auch nicht zu verstecken.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.