Was (genauer) ist embedded Programmierung?

krümelkacker

lololo schrieb:

LOL, echte embedded Systeme haben gar kein Betriebssystem, da programmiert man selbst direkt auf der Hardware und mus sich um Interuptsteuerung, Speicherverwaltung und I/O Angelegenheiten über die Ports des Devices selbst kümmern.

Das was du meinst bieten lediglich die fetten Embedded Systeme, wie z.B. ARM, aber das ist Embedded für Warmduscher.

Richtiges Embedded ist blank auf der Hardware, z.B. bei den µC ATMega, PIC, MSP430 usw.

ARM ist nicht gleich ARM. Du scheinst dabei an die Dinger zu denken, wie sie in Handys, Tablets oder dem Amazon Kindle verbaut sind. Da gibt's aber auch noch die Cortex-M Schiene für Microcontroller, einigermaßen abgespeckt: max 200 MHz, feste Adressierung und meist auch ohne Hardwareunterstützung für Fließkomma-Arithmetik. Ich habe zu Hause einen Cortex-M4 Microcontroller liegen, der mit 72Mhz läuft und nur 48 KBytes RAM hat. Für Microcontroller ist das schon in der oberen Leistungsklasse mit den restllichen Features. Aber im Vergleich zu dem, was in Smartphones verbaut wird, ist das natürlich ein Witz.

fragexxz schrieb:

Hallo,

ich lese permanend was von embedded C/C++ und embedded programmierung.
Mir ist (nach rechereche) klar dass es sich um eingebettete systeme handelt (z.B. elektronische regelung im zug etc...).

Was mir aber nicht klar ist, wie genauer schaut embedded programmierung aus und mit welchen themen beschäftigt sich ein berufliche embedded entwickler? Regelungstechnik? Echzeit?

worin unterscheid sich embedded programmierung von normaler programmierung?

Danke für eure Antwort!

Nochmal meine Erfahrungen:

Embedded = ASM oder C, wenn du Glück hast kannst du C++ nutzen, wenn du noch viel mehr Glück hast, kannst du teile der stl von C++ nutzen.

Wer aus der Java-Ecke oder sonstwo herkommt wird gnadenlos untergehen, da man meist Kontroller mit sehr wenig Speicher hat. Mikrocontrollerprogrammierung ist meist hässlich, weil man drei Dinge in Einklang bringen muss:

- Es muss meist schnell sein
- Es muss wenig Speicher brauchen
- Der Code muss irgendwo wartbar bleiben

Meist sieht es so aus: Irgendwer plant eine Hardware, z.B. eine Platine, da steckt dein Mikrocontroller drauf, verbunden mit den ganzen anderen Sachen. Dann geht das Datenblatt lesen los, der Controller muss "in Betrieb" genommen werden. Interrupts setzen, Ports konfigurieren, irgendwie zum laufen bekommen.

Bei der eigentlichen Programmierung gilt: Du hast nichts! SD-Karte auslesen? Selber implementieren. Irgendwas ausgeben? #include <iostream> ist nicht!
Komfortabel debuggen? Ggfs. je nach Hardware ist gar kein Debuggen möglich.

Embedded Programming ist fordernd und kann Spaß machen, aber ehrlich gesagt genieße ich es einfach alles zu haben und mag daher "normale" Programmierung lieber. Da hol ich mir die Libs ins Boot die ich gerade brauche und brauch mir keinen Kopf darum zu machen, dass #include <sprintf> mal wieder 0.8kb Speicher kostet...

<sprintf> gibt es gar nicht, was deine Antwort inkompetent erscheinen lässt

Wo hört embedded auf?

Armbanduhr (digital) -> Taschenrechner -> Handy -> Smartphone -> Tablet -> PC?

Kurz nach Smartphone

Bitte ein Bit

Worin unterscheid sich embedded programmierung von normaler programmierung?

Bei embedded Programmierung spielt oft beschränkte Hardware (CPU Taktfrequenz, Arbeitsspeicher, Flash Speicher) eine Rolle. Aber auch andere Dinge wie Wärmeentwicklung, Akku-Laufzeit, Absturzsicherheit spielen eine Rolle. Oftmals tauchen aber auch Echtzeitanforderungen auf, welche garantieren dass eine Operation nicht länger als X Sekunden dauert.

Und natürlich haben embedded Systems auch ganz andere Aufgabengebiete. Oftmals reagieren diese autonom, ohne Kenntniss des Benutzers. Viele Systeme verarbeiten Sensordaten, verarbeiten diese weiter und/oder steuern Aktuatorik an. Dementsprechend müssen diese auch oft ausfallsicher sein. Typische Aufgaben sind Steuerung, Regelung,...

Ich habe mal eine LCD Steuerung (Datenstrom -> LCD Ausgabe) programmiert. Der Chip hatte, glaube ich, 4 kHz Taktfrequenz und ich hatte nur 16 kByte Flash Speicher. Da passt kein OS drauf. Selbst die printf Funktion muss man in solchen Fällen beschneiden. Die Interrupt Funktion schaufelte die Daten vom Bus und da durfte man keinen Takt zuviel verbraten.

Im Zuge unserer mobilen Welt gibt's aber auch softe embedded Systems. Da sitzt meistens eine dicke CPU mit dickem Akku drin. Da kann man sich halt streiten ob dies noch als richtiges embedded System bezeichnen möchte.

Psycho

Oftmals tauchen aber auch Echtzeitanforderungen auf, welche garantieren dass eine Operation nicht länger als X Sekunden dauer

Oder z.b. auch "Sichere Software", die dann ab bestimmten Anforderungen nicht mehr mit einer CPU (nicht CORE) pro Gerät auskommt. Da sind dann 2 (oder mehr) CPU's drin (oftmals mit unterschiedlichen Compilern, OS's oder auch Dev - Teams) die sich gegenseitig überwachen um auf Fehler des anderen reagieren zu können.

hustbaer

Ämbeddet schrieb:

Nochmal meine Erfahrungen:

Embedded = ASM oder C, wenn du Glück hast kannst du C++ nutzen, wenn du noch viel mehr Glück hast, kannst du teile der stl von C++ nutzen.

Embedded ist im Prinzip alles wo ne CPU in irgend ein System eingebaut ist, was nicht primär als Computer zu bezeichnen ist.
Ein Wettautomat auf dem Windows läuft ist "embedded".
Und ein kleiner 8-Bit µC der nen Brushless Motor steuert ist genau so "embedded".

Ich arbeite z.B. mit Windows XP embedded und Windows Embedded Standard 7.
Ersteres ist ein stinknormales Windows XP Pro + ein paar kleine Zusatzfeatures + ein paar wenige lästige Zusatzbugs. Zweiteres ist das selbe nur auf Basis von Windows 7.
Auf beiden kannst du ohne Probleme so-gut-wie jede normale Windows Applikation installieren und laufen lassen. Man könnte die Dinger im Prinzip auch ganz normal zum Arbeiten, Surfen, Spielen etc. verwenden.

Und programmieren tut man sie dementsprechend gleich wie eine normale Windows Kiste. Die selben Tools, die selben APIs etc.

Wo es sich dann unterscheidet, ist was man in dem Umfeld so programmiert. Auch wie die Interaktion mit dem User aussieht etc. Oder auch nicht aussieht, falls das Programm nur irgendwelche Abläufe automatisch steuert.

Beispielsweise wäre es bei nem Bankomaten blöd wenn eine Windows Fehlermeldung aufpoppt. Sieht einfach peinlich aus. Oder noch blöder wenn das Programm crasht und der normale Windows "Programm ist gecrasht" Dialog kommt. Besser wäre wenn eine hübsche bunte Fehlermeldung angezeigt wird, bzw. wenn das Programm crasht automatisch ein Crashdump irgendwohin übermittelt wird, und das Ding sich dann auch automatisch neu startet.
Genau so wäre es auch doof wenn man in ner Bankomaten-Software einen Dialog ohne Owner-Window aufmacht, der User dann neben diesen Dialog hinklickt, und der darauf hinter dem bildschirmfüllenden Fenster der Applikation verschwindet. Wo er dann für immer verbleibt, weil man ihn nichtmehr anklicken kann.
Uswusf.

Und nein, ich programmiere keine Software für Bankomaten. Zwar auch für Kisten mit Touchscreen und Co., aber nicht für Bankomaten.

hustbaer

we'rDoinfine schrieb:

Wo hört embedded auf?

Armbanduhr (digital) -> Taschenrechner -> Handy -> Smartphone -> Tablet -> PC?

Embedded hört eigentlich gar nicht auf.
Also maximal dort, wo etwas zu gross ist, als dass es noch in etwas anderes eingebaut werden könnte.

Und ich würde die Programmierung für Tablets z.B. nicht unbedingt als "embedded" bezeichnen. Und bei Smartphones eigentlich auch nur den Teil der Software der "so tut als ob das Ding ein Telefon wäre".

Im Prinzip sind das ja einfach nur Computer im Taschenformat, die auch als solche genutzt werden. Und als tragbare Computer sind sie eben einfach Computer, nicht Teile die in irgend ein grösseres System "eingebettet" wären.

Ein dicker fetter PC mit 16 Cores und 64 GB RAM der irgendwo irgendwelche Fertigungsstrassen überwacht/steuert ist dagegen schon "embedded".

HarteWare

qwertzu schrieb:

embedded artist schrieb:

Embedded Programmierung ist die Kunst auf ganz niedrigem Niveau zu proggen.

Also viele gotos?

HAHA