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.
Beitrag #7055087 wurde von einem Moderator gelöscht.
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"!
> Trifft auf moderne Webentwicklung zu. > Aber definitiv nicht auf Embedded. Ist bei dir noch nicht angekommen? Warte ab. :-D Olaf
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.
Beitrag #7075588 wurde von einem Moderator gelöscht.
Beitrag #7075744 wurde von einem Moderator gelöscht.
Beitrag #7084101 wurde von einem Moderator gelöscht.
Beitrag #7084107 wurde von einem Moderator gelöscht.
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.