Guten Abend,
ich wollte mal fragen wie es in der Embedded Softwareentwicklung so zu
sich geht? Ist das zu empfehlen? Was genau wird da so gemacht? Ich
stelle mir das so vor: Jegliche Software die an einer Maschine später
benötigt wird:
- Steuerungs-/Regelunsgalgorithmen
- Signalverarbeitung
- Sensorik
- Graphische Benutzeroberflächen
- IoT
- KI
- noch mehr Algorithmen
Wird da noch viel programmiert oder kommt das Meiste mittlerweile aus
dem Codegenerator? Wenn ich mir so Matlab anschaue da gibt es ja für
alles eine Toolbox.
Robert schrieb:> Wird da noch viel programmiert oder kommt das Meiste mittlerweile aus> dem Codegenerator?
Da wird am ehesten noch selbst programmiert. Embedded Maschinen sind
üblicherweise noch keine dicken Kisten mit 16 GB RAM, wo man die
Software in einem Web-Framework in einem Browser in einem
Docker-Container auf einer VM laufen lassen kann.
najaaa, ich muss zugeben: kommt drauf an.
In der Regel kann man das aus der Stellenbeschreibung herauslesen.
Meiner Erfahrung nach gibt es beides.
Ich embedde gerade neuronale Netze auf "Steuergeräte" mit 32GB RAM. Da
kommt viel aus dem Codegenerator und alles was er nicht kann,
programmiert man per Hand dazu.
"Modellbasierte Funktionsentwicklung" in der Automobilbranche hat zum
Teil gar keinen Programmieranteil.
der gefühlte Trend: je größer die Stückzahlen desto mehr lohnt es sich
Code zu schreiben.
> ich wollte mal fragen wie es in der Embedded Softwareentwicklung so zu> sich geht? Ist das zu empfehlen?
Klar! Jeden Tag Party mit lustigen Maedchens!
> Wird da noch viel programmiert oder kommt das Meiste mittlerweile aus> dem Codegenerator?
Nein, viel zu schlecht. Vielleicht hier und da in begrenzten
Ausnahmefaellen mal. Geh mal davon aus das 99% von Hand programmiert
wird.
Olaf
Robert schrieb:> Wird da noch viel programmiert oder kommt das Meiste mittlerweile aus> dem Codegenerator? Wenn ich mir so Matlab anschaue da gibt es ja für> alles eine Toolbox.
Wieso oder? Codegeneratoren werden nicht von Alexa konfiguriert. Und
wenn Du Mal in UML oder stateflow Steuerungstechnik (nicht
Regelungstechnik) gemacht hast, bist Du froh, wenn Du nicht dazu
gezwungen bist.
Auf der anderen Seite programmiert keiner mehr zu Fuß eine Sinusfunktion
mehr in assembler oder eine FFT in C.
Diese ganze grafischen Configtools und ihre IDEs (wie z.B. ST CubeMX als
prominentes Beispiel) wird bei uns höchstes genutzt, um am Anfang mal
schnell was auszuprobieren oder einen Proof-of-Concept mal zu machen.
Die produktive Arbeit später ist dann wirklich handgemacht, mit eigenem
Buildsystem etc.
Teilweise integrieren wir aber durchaus mal portierte Software-Stacks
(z.B. RTOS) etc.
Laberkopp schrieb im Beitrag #7055087:
> * Sehr viele langweilige Meetings> * Sehr viele lange andauernde Meetings> * Sehr viele sinnlose Meetings> * Sehr viele hippe Tools> * Ständig die neuesten hippen Tools> * Sehr viel Projektplanung> * Immernoch sehr viele Meetings> * Viel könnte, hätte, wäre Entscheidungen> * Sehr viel gegendere> * Jede Woche ein neues hippes Tool> * Lastenhefte und Anforderungen sind gestern, agil ist heute!> * Papierkrieg bis zum Umfallen> * Wenig programmieren und wenn, dann mit hippen Programmiersprachen wie> Go, Rust oder Python>> Wenn dich das alles anspricht, nur zu!
Trifft auf moderne Webentwicklung zu.
Aber definitiv nicht auf Embedded.
Robert schrieb:> Wird da noch viel programmiert oder kommt das Meiste mittlerweile aus> dem Codegenerator?
Ich versteht die Frage nicht?!
Auch ein codegenerator viel programmiert sein, also musste wissen
welchen Parameter du dem vorgibst. Da ist kein Button "Wünsch dir was"!
Deshalb nimmt man für Embedded eher einen ET-Studierten als einen
INF-studierten, weil unter löetzteren mehr meinen programmieren hört
beim programmiersprache codieren auf. (wo die eigentliche Arbeit aber
erst beginnt).
> - Graphische Benutzeroberflächen
Das ist kein embedded sondern Bürosoftware. Auch bei eine Kaffeemaschine
mit KlickiKackiBunti-Display lässt man den Display-Teil einen
Bürosoftwerker machen (resp. dengelt sich was aus Linux zusammen)
während für den sonstigen Teil der Maschine (Elektrik, Mechanik) ein
erfahrenere embedded und ein Elektrotechniker dran kommt, weil die von
der Niederspannungsrichtlinie und anderen VDE-Normen mehr verstehen als
nur "Elektr. Strom macht klein, schwarz, und häßlich".
Ing. braucht das Land, keine Nerds schrieb:> Auch ein codegenerator viel programmiert sein, also musste wissen> welchen Parameter du dem vorgibst. Da ist kein Button "Wünsch dir was"!
Grmm, soll heissen:
Auch ein Code-Generator will programmiert sein, also musst'e wissen
welchen Parameter du dem vorgeben musst und wo die "Trade-Off"s liegen.
Da ist kein Button "Wünsch dir was"!
Laberkopp schrieb im Beitrag #7055087:
> * Sehr viele hippe Tools> * Ständig die neuesten hippen Tools> * Jede Woche ein neues hippes Tool> * Lastenhefte und Anforderungen sind gestern, agil ist heute!
Das ginge bei uns alles schon rein regulatorisch nicht.
Robert schrieb:> ich wollte mal fragen wie es in der Embedded Softwareentwicklung so zu> sich geht? Ist das zu empfehlen?
Wenn es Dich interessiert, ja.
Wenn es Dich nicht interessiert, nein.
> Was genau wird da so gemacht?
Na es wird Software entwickelt, nach ingenieurswissenschaftlichen
Maßstäben.
> Ich stelle mir das so vor: Jegliche Software die an einer Maschine später> benötigt wird
...kann selbst programmiert werden, oder kann von anderen Firmen
zugekauft werden. In den meisten Firmen wird es immer eine Mischung aus
beidem geben: Man macht nicht alles selbst, das wäre heutzutage auch gar
nicht mehr möglich. Sondern man kauft bestimmte Subsysteme bei anderen
Firmen ein, bzw. man nutzt auch kostenfreie Software und -Bibliotheken
(Open Source), und bestimmte andere Teile der Software entwickelt man
selbst.
> Wird da noch viel programmiert
Ja.
> oder kommt das Meiste mittlerweile aus dem Codegenerator?
Es gibt sicher einen Trend, zunehmend mehr Code zu generieren und
weniger von Hand zu schreiben. Je nach Branche ist der unterschiedlich
stark ausgeprägt.
Hi !
Das ist heute alles kein Problem mehr. Wir haben in der Firma ein
Tool. Da musst Du nur mit der Maus die Datei mit dem Pflichtenheft
in das Icon ziehen. Dann kommt alles fertig raus. Firmware, Tests
und Doku.
HAL9000
>Hi !>Das ist heute alles kein Problem mehr. Wir haben in der Firma ein>Tool. Da musst Du nur mit der Maus die Datei mit dem Pflichtenheft>in das Icon ziehen. Dann kommt alles fertig raus. Firmware, Tests>und Doku.
Ja, ich denke das trifft es heutzutage fast: Wichtig ist das
Requirementsengineering. Wenn die in DOORs mal gemacht sind, gibt man
sie einfach nur den Codern und die machen dann den Rest schnell.
Wahres Embedded ist wie ne Wurzelbehandlung. Es wird bis zur
Wurzelspitze aufgebohrt. Schon wenn du SDKs benutzt oder Arduino bist du
nicht mehr an der Spitze ;) Esseidenn du hast den Code dahinter
verstanden.
Macher schrieb:> Eckhart schrieb:>> und die machen dann den Rest schnell.>> Schnell geht das sicher nicht.
Schnell geht nur, wenn man Indische Qualität will
Dieter H. schrieb:> Schnell geht nur, wenn man Indische Qualität will
Du meinst sicher diese schönen, bunten, sporadischen Fehler, die einmal
alle paar Stunden auftauchen, nicht reproduzierbar sind und meistens
durch asynchrone Abläufe entstehen? Ja, die gibts gratis.
Robert schrieb:> Ich> stelle mir das so vor: Jegliche Software die an einer Maschine später> benötigt wird:
Naja man kann nicht jede "Maschine" in den selben Schmelztiegel werfen,
da sind schon große Unterschiede ob die Software für
*Consumer (billig, aber teuer aussehend)
*Automotive(Billig in Massen, und stur nach amtlichen
Sicherheitsvorgaben)
*Medizintechnik (sicher, sicher, sicher)
*Avionic (sicher und robust)
entwickelt wird.
