Was (genauer) ist embedded Programmierung?

lolololo hat Recht.

Ein vollwertiges OS auf einem kleinen ATMega oder MSP430 mit nur 128 Byte RAM (ja, Byte, nicht Kbyte!) ist völliger Mumpitz!
Mußt dich halt mal informieren, wie klein die µC sind.

klar verwendet man auf einem atmega kein OS, auch wenn es welche gibt!

aber embedded ist mehr als die welt der mikrocontroller!
und sobald man dinge wie netzwerk braucht wäre es ziemlich unsinnig, das alles selber zu programmieren.

dfdsfsdfsdfs hat recht. Embedded Programming ist trivial.

lol geber schrieb:

dfdsfsdfsdfs hat recht. Embedded Programming ist trivial.

jedenfalls Mikrocontroller programmieren ist trivial. Die Typen kopieren sich im Internet den gesamten Code zusammen. Schlimmsten Code hab ich da schon gesehen (einer hat z.B. ein switch mit vielen cases mit if's nachgebaut, warum auch immer... ), weil die echt harten Typen die ohne OS auskommen komischerweise auch nicht in der Lage sind, vernünftigen C Code zu schreiben. Wahrscheinlich ist ihnen selbst C noch zu soft, denn ASM ist die einzige Sprache für harte Jungs :p

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

embedded artist schrieb:

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

Also viele gotos?

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?

Wenn du in das Thema einsteigen möchtest, so gibt es inzwischen viele (günstige) Möglichkeiten:
* Raspberry Pi: ARM Computer im Mini Format, läuft mit Linux
* AVR Board: zum Kennenlernen der Mikrocontroller Programmierung
* Asuro: kleiner Roboter, zentrale Komponente auch hier ein AVR Atmega

Das ist eine spannende Art und Weise, in das Thema einzusteigen!

Zur Diskussion über meinem Beitrag: ein typisches Beispiel wieder, dass jeder glaubt, er selbst arbeite an der schwierigsten Aufgabe der Welt, und alles andere sei eh trivial. Ein bisschen über den Tellerrand blicken würde helfen. Es gibt Aufgaben, da macht eine simple Mikrocontroller Lösung Sinn, es gibt Aufgaben, da verwendet man lieber ein Betriebssystem mit einem leistungsstarken Prozessor. Insgesamt geht die Tendenz aber eindeutig Richtung leistungsstarker eingebetteter Systeme, auf denen dann oft eine spezielle Linux Version läuft. Dazu einfach mal Jobportale durchsuchen, da sieht man recht schnell wo es hingeht.

qwertzu schrieb:

embedded artist schrieb:

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

Also viele gotos?

siehe Linux Source Code, dort wird goto verwendet, und der Code ist verständlicher als so manch anderes Konstrukt was ich bis jetzt sehen durfte.

Linus sucks

Gregor

Ich habe zwar nie ernsthaft Embedded Programmierung betrieben, aber...

Nach meinem Verständnis haben hier alle Recht.

Ein "eingebettetes System" ist ein System, das Teil in einem größeren "Kontext" ist und somit mit diesem größeren Kontext kommunizieren muss. Insofern hat es vor allem Aufgaben wie "Dinge steuern" oder "regeln". Es empfängt Daten von Sensoren, verarbeitet diese und sendet dann Daten an Aktoren. Oft ist die Programmlogik hinter den Aufgaben eines Embedded Systems relativ einfach und kann leicht durch einen Automaten oder ähnliches modelliert werden. Ein einfaches und rein steuerndes Embedded System wäre zum Beispiel ein Bankautomat, der sich in bestimmten Zuständen befinden kann und bei bestimmten Aktionen des Nutzers dann bestimmte Dinge in Gang setzen muss, wie zum Beispiel den Auswurf der Bankkarte oder des Geldes, das jemand abheben will.

Eine andere Art von Embedded System wäre zum Beispiel eine Umsetzung von "Fly-By-Wire" oder einem Autopiloten, bei dem durchaus auch auf Daten wie die Ausrichtung des Flugzeugs reagiert werden muss, um dieses stabil zu halten. Da regelt das eingebettete System eher.

Diese beiden Beispiele von eingebetteten Systemen machen eigentlich recht direkt klar, dass damit sehr verschiedenes gemeint sein kann. Entsprechend sind auch die Programmierbedingungen sehr unterschiedlich. Mal geht es darum, mit sehr geringen Resourcen auskommen zu müssen, ein anderes mal gibt es zum Beispiel gewisse Echtzeitanforderungen. Was eigentlich ein verbindendes Merkmal ist, ist die mehr oder weniger direkte Kommunikation mit irgendwelchen (außergewöhnlichen) Hardwarekomponenten, wie zum Beispiel Motoren oder vielleicht Bar-Code-Scanner.

Oft geht es dabei auch um Leben und Code!

Ein einfaches und rein steuerndes Embedded System wäre zum Beispiel ein Bankautomat, der sich in bestimmten Zuständen befinden kann und bei bestimmten Aktionen des Nutzers dann bestimmte Dinge in Gang setzen muss, wie zum Beispiel den Auswurf der Bankkarte oder des Geldes, das jemand abheben will.

ganz so trivial ist die software, die auf einem bankomaten läuft, aber auch nicht

Auf Bankautomaten läuft meisten Windows NT 4.0

asc

Kenner der New Technology schrieb:

Auf Bankautomaten läuft meisten Windows NT 4.0

Nach meinen Erfahrungen ist zwar häufig ein Windows auf Bankautomaten (spätestens wenn man die Fehlermeldungen gesehen hat), aber laut Aussagen eines Entwicklers aber ein abgespecktes embedded Windows.

asc schrieb:

Kenner der New Technology schrieb:

Auf Bankautomaten läuft meisten Windows NT 4.0

Nach meinen Erfahrungen ist zwar häufig ein Windows auf Bankautomaten (spätestens wenn man die Fehlermeldungen gesehen hat), aber laut Aussagen eines Entwicklers aber ein abgespecktes embedded Windows.

Windows CE

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