Embedded-Programmierung -> Yay or nay

[sdf]

Z schrieb:

Täusche er sich nicht. Oft geht es in dem Bereich darum, aus leistungsschwachen, ressourcenarmen Systemen das Letzte herauszuholen. Das erfordert sehr gute Kenntnisse sowohl auf dem Gebiet der Algorithmik, Betriebssystem-Design, komplexen Datenstrukturen usw. als auch der Hardware und der eingesetzten Tools. Ein Freund von mir kann ein Lied davon singen.

Das ist zwar richtig, aber die Frage ist hier auch nur: "Wie lange ist das noch so?"

Auch die µC werden immer leistungsfähiger und erhalten immer mehr RAM.
Schon heute programmiert man auch dort inzwischen mit Hochsprachen wie z.B. C, weil die Dinger leistungsfähiger geworden sind und nicht alles mehr zwingend in Assembler gemacht werden muß.

Manche "eingebetteten Systeme" müssen viele Jahre hindurch, ohne Unterbrechung fehlerfrei arbeiten.

Richtig, allerdings kann man sich auf dem µC auch austoben, weil nur der eigene Code oder des des Entwicklerteams darauf werkelt.
Andere Anwendungen stehe also nicht im Weg.

[Minimee]

Naja, Embedded Software als trivial zu bezeichnen, räusper...

das Wort wäre mir eher in Verbindung mit Desktop-Software in den Sinn gekommen.

[Gast]

sdf schrieb:

Das ist zwar richtig, aber die Frage ist hier auch nur: "Wie lange ist das noch so?"

So lange kleine, schwache Controller kostengünstiger angeboten werden als größere. Entwicklungszeit muss nur einmal investiert werden. Nimmt man einen größeren Chip, beispielsweise einer auf dem uCLinux läuft, spart man zwar Entwicklungsaufwand, steigert aber die Stückkosten, was bei hohen Stückzahlen unwirtschaftlich ist.

[sdf]

Z schrieb:

sdf schrieb:

Das ist zwar richtig, aber die Frage ist hier auch nur: "Wie lange ist das noch so?"

So lange kleine, schwache Controller kostengünstiger angeboten werden als größere. Entwicklungszeit muss nur einmal investiert werden. Nimmt man einen größeren Chip, beispielsweise einer auf dem uCLinux läuft, spart man zwar Entwicklungsaufwand, steigert aber die Stückkosten, was bei hohen Stückzahlen unwirtschaftlich ist.

Schon klar, aber die Firmen die diese Dinger herstellen konkurrieren doch sowieso miteinander, einer macht nen Zug und bietet einen µC günstiger an und der andere folgt nach und überholt ihn dann.
Das geht immer so weiter bis irgendwann der Punkt ist, an dem man einen µC für den niedrigsten Betrag bekommt und trotzdem für nen µC gut darauf programmieren kann.
Und µCLinux ist ja schon wieder etwas überpowered.

Außerdem gilt hier auch.
Die Kosten spielen eigentlich eher bei den großen Massenproduzenten eine Rolle und die können gar nicht so viele Stellen anbieten. Man hat also das Problem, daß bei diesen kleinen µC der Arbeitsmarkt immer kleiner wird, während er bei den größeren und einfach zu programmierenden µC mit sinkenden Preisen größer wird.
Für kleine Unternehmen, die sowieso nur 1000-10000 Stück von irgendeinem Produkt herstellen, lohnen sich dann auch schon die größeren µC.
Die Winzigdinger machen nur bei Produkten Sinn, die Stückzahlen > 100000 haben.
Aber solche Unternehmen haben dann trotzdem nur ein überschaubares Entwicklerteam, daß die Software für so ein Massenprodukt herstellt.

Sprich, der TS hätte irgendwann das gleiche Problem wie bei seinem 3. Punkt.

[maximAL]

@sdf

Es gibt natürlich immer leistungsfähigere yC, aber du solltest bedenken, dass auch die Anwendugsbereiche immer größer werden und es sicherlich immer noch Bedarf für kleinste Systeme gibt. Man denke nur an irgendwelche mit RFIDs versehenen Waren, die am besten für den Bruchteil eines Cents auch noch einen yC aufgedruckt bekommen.

[Gast]

Gibt ja auch Mikrocontroller Programmierung, wo kein OS dazwischen geschaltet ist.
Z.B. Atmel AVR werden bei einfachen Steuerungen sehr oft verwendet.
http://de.wikipedia.org/wiki/Atmel_AVR

Und ich bin mir sicher, dass die so schnell nicht ersetzt werden, ganz einfach deswegen, weil sie alles können, was man braucht. Wofür dann etwas komplizierteres verwenden? Ein Mikrocontroller ersetzt komplizierte fehleranfällige Transistorschaltungen (bzw. Logikgatterschaltungen), ein dazwischengeschaltestes Betriebssystem würde rein gar nichts bringen.

Und trivial ist diese Mikrocontrollerprogrammierung sicher nicht. Im Gegensatz zum "Ich klick mir meine Windows Oberfläche zusammen" geht es dabei oft um Regler, die zuerst berechnet und dann implementiert werden müssen. Aber auch die Ein und Ausgaben, also das Auslesen und Schreiben der Pins ist nicht ganz so trivial wie printf("...").

Beim Mikrocontroller programmieren hatte ich selten mit Routinetätigkeiten zu tun. Da ist jede Funktion meist eine Sonderanfertigung für das jeweilige Problem.
Aber das hardwarenahe muss einem natürlich Spaß machen, ansonsten hat man nichts davon!

[volkard]

Naja, loben wir mal nicht zu viel. Man sieht regelmäßig in Diskussionen, daß die Embedded-Leute oft genug sogar noch weniger Ahnung haben als typische Gamecoders und noch eingebildeter von sich sind.

[Minimee]

volkard schrieb:

Naja, loben wir mal nicht zu viel. Man sieht regelmäßig in Diskussionen, daß die Embedded-Leute oft genug sogar noch weniger Ahnung haben als typische Gamecoders und noch eingebildeter von sich sind.

Nur weil du von Embedded auch keine Ahnung hast und dich für einen tollen Informatiker hälst darf natürlich nicht zuviel gelobt werden, schon klar

[volkard]

Nein, es mußte nur endlich mal ausgesprochen werden.

Nun, wo es geschehen ist, platzt die Blase wie in "Des Kaisers neue Kleider".

Daß ich jetzt viele Beschimpfungen bekomme, weil ich nicht sehe, was nicht zu sehen ist, tut mir nicht sehr weh. Viel Spaß beim Nachweis, daß ich ein schlechter Informatiker bin.

[SideWinder]

Ich weiß nicht was du mit "typische Game-Coder" meinst, aber im Bereich der professionellen Spieleprogrammierung sind doch oftmals sehr gute, auch theoretisch sehr fundierte Personen unterwegs. Du redest aber dann wohl eher von "I want to do WoW until next weekend"-Personen?

MfG SideWinder

[Minimee]

Dann zeig mir doch mal ein Beispiel dafür:

Man sieht regelmäßig in Diskussionen, daß die Embedded-Leute oft genug sogar noch weniger Ahnung haben als typische Gamecoders und noch eingebildeter von sich sind.

Wovon haben die Embedded-Leute denn keine Ahnung, von irgendwelchen Grafik-Librarys ? Kein Wunder...

[Gast]

volkard schrieb:

Naja, loben wir mal nicht zu viel. Man sieht regelmäßig in Diskussionen, daß die Embedded-Leute oft genug sogar noch weniger Ahnung haben als typische Gamecoders und noch eingebildeter von sich sind.

Typische Embedded-Entwickler treiben sich allerdings selten in einem C++-Forum rum, weil sie zumeist C, Assembler, Hardwarebeschreibungssprachen und einen Lötkolben nutzen.

Davon abgesehen, benötigen Spezialisten jeder Sparte bestimmte Kenntnisse und Fähigkeiten, die sie von anderen unterscheiden. Es gibt zwar Überschneidungen, aber man kann generell nicht sagen, dass die Arbeit eines Web-Developers, Mikrokontroller-Programmierers, Game-Designers, etc. anspruchsloser oder "schlechter" ist, als die eines Programmierers anderer Couleur. Anspruchsvolle und weniger interessante Jobs gibt es in jedem Bereich.

[sdf]

Glutamat schrieb:

Gibt ja auch Mikrocontroller Programmierung, wo kein OS dazwischen geschaltet ist.
Z.B. Atmel AVR werden bei einfachen Steuerungen sehr oft verwendet.
http://de.wikipedia.org/wiki/Atmel_AVR

Und die werden inzwischen auch verstärkt in C programmiert. Das OS ist nicht im Weg, und die zu tätigende Funktionalität ist oft klein, leichter und einfacher kann man es doch nicht haben!

Die 32 Bitter von Atmel sind stark im kommen und werden auch immer günstiger, man spart sich also selbst die umständliche Programmierung mit den ATMega & ATTiny 8 Bittern.
Aber selbst wenn die 32 Bitter noch zu teuer sind, Texas Instrument ist schon auf den Zug aufgesprungen und bietet mit dem MSP430 einen 16 Bitter an, der wirklich sehr bequem zu programmieren ist.
Flaches Speichermodell, dann gleich 16 Bit, programmiert wird in C und die µC kosten fast nichts, was will man mehr?

Und ich bin mir sicher, dass die so schnell nicht ersetzt werden, ganz einfach deswegen, weil sie alles können, was man braucht. Wofür dann etwas komplizierteres verwenden?

Die 8 bittigen ATMega8 sind komplizierter zu programmieren als die 16 bittigen MSP430.

Ein Mikrocontroller ersetzt komplizierte fehleranfällige Transistorschaltungen (bzw. Logikgatterschaltungen), ein dazwischengeschaltestes Betriebssystem würde rein gar nichts bringen.

Das sowieso nicht, deswegen habe ich ja auch gesagt, daß µCLinux schon wieder overpowered ist.
Ohne OS ist es in solchen Fällen oft einfacher und da zählt dann wie einfach die Architektur aufgebaut ist, sprich, wie sieht das Speichermodell aus, wieviele Register hat man und kann man in C programmieren.

[sdf]

Minimee schrieb:

Dann zeig mir doch mal ein Beispiel dafür:

Man sieht regelmäßig in Diskussionen, daß die Embedded-Leute oft genug sogar noch weniger Ahnung haben als typische Gamecoders und noch eingebildeter von sich sind.

Wovon haben die Embedded-Leute denn keine Ahnung, von irgendwelchen Grafik-Librarys ? Kein Wunder...

volkard hat da nicht ganz unrecht.

Für die Programmierung von µC muß man oft nur ganz einfache Prozeduranweisungen schreiben. Sprich, wenn an Pin x ne 1 anliegt, mache dann dies und gebe XY über Pin x2 aus. Und Timerbrechnungen usw. gehen in den Alltag über.
All das kann Spaß machen, weil es recht hardwarenah ist, aber es ist vom Programmieren her betrachtet dennoch trivial.

Ganz anders sieht das schon bei der Entwicklung einer 3d Engine aus.
Da geht es erst richtig los mit der Speicherverwaltung, der Verwaltung von Objekten, den Matrizenberechnungen usw..

Auch der Umfang an Stoff den man können muß, ist bei letzterem viel umfangreicher.
µC kann man im Prinzip schon programmieren wenn man
A) ein bischen Assembler gelernt hat (dient dem Verständnis),
die Programmiersprache C kann
C) sich mit dem jeweiligen µC auseinandergesetzt hat

Bei 3d Engines ist man mit C und OpenGL/Direct3d noch längst nicht am Ziel.
Von da geht es dann weiter mit Scene Graphen, Sichtbarkeit von Objekten, möglicherweise auch Kollisionserkennung usw..
Und die ganzen Grundlagen aus dem Infostudium wie Datenstrukturen, Mathe und co braucht man sowieso.

All das braucht man bei µC nicht.
Lediglich Datenstrukturen können noch hilfreich sein.
Für die Mathe reicht in den meisten Fällen die Schulmathematik bis zur 13.

Die Programmierung von µC ist aus Informatikersicht also nicht schwer und genau aus diesem Grund werden µC auch schon von Leuten programmiert, die Elektrotechnik studiert haben.
Das kann man sich nämlich alles nebenbei beibringen.
Prinzipiell reicht dafür schon ein Schüler aus, der in der Freizeit C und etwas Assembler gelernt hat.

PS: Natürlich gibt es auch Spezialfälle wie ESP, die die Funktionalität und das notwendige Wissen für das Programmieren eines µC für eine Kaffemaschine deutlich übersteiegn, aber das sind eben die Ausnahmen von der Regel.

[Minimee]

sdf schrieb:

volkard hat da nicht ganz unrecht.

Für die Programmierung von µC muß man oft nur ganz einfache Prozeduranweisungen schreiben. Sprich, wenn an Pin x ne 1 anliegt, mache dann dies und gebe XY über Pin x2 aus. Und Timerbrechnungen usw. gehen in den Alltag über.

Das ist doch Bullshit, ihr habt nur keine Ahnung davon. Vielleicht wenn man nen Kaffeemaschinen-uC programmiert, aber die Algorithmen für Regelungen im Auto/Flugzeug/Drehstrommaschinen gehen weit, weit über den Ansrpuch einer Grafik-Library hinaus, für die man gerade mal Oberstufen-Mathematik benötigt.

[theta]

Vergleiche der Länge der Geschlechtsteile (nat. nur bei Männern) und das im Bereich der SW Entwicklung. Also bitte...

[Gast]

sdf schrieb:

All das braucht man bei µC nicht.
Lediglich Datenstrukturen können noch hilfreich sein.
Für die Mathe reicht in den meisten Fällen die Schulmathematik bis zur 13.

Na, wenn du meinst. Dann erklär mir doch mal, wieso Firmen wie beispielsweise diese hier und diese, ausgebildete Physiker und Mathematiker beschäftigen, wenn das alles so furchtbar einfach ist, dass jeder Wald-und-Wiesen-Informatiker, der mal ein paar .NET-Anwendungen zusammengezimmert hat, damit klar käme? :p

[Bashar]

Minimee schrieb:

die Algorithmen für Regelungen im Auto/Flugzeug/Drehstrommaschinen gehen weit, weit über den Ansrpuch einer Grafik-Library hinaus, für die man gerade mal Oberstufen-Mathematik benötigt.

Du vergleichst jetzt den mathematischen (bzw. eigentlich fachlichen) Anspruch mit dem Programmieranspruch. Die Behauptung sdfs, es sei nur ganz einfaches Manipulieren irgendwelcher Ports ist prinzipiell richtig, was macht denn ein Regelalgorithmus? Er wird periodisch aufgerufen, liest ein paar Werte ein, rechnet ein bisschen rum (jaja das WIE ist die Kunst, aber das ist am Ende halt auch nur eine Formel und ein bisschen Zustandslogik), speichert etwas ab und schreibt die Ergebnisse raus. Programmiertechnisch ist das überhaupt nicht anspruchsvoll. Darf es ja eigentlich auch nicht, es muss einfach sein, um stabil zu laufen. Der Anspruch liegt wie gesagt im Entwickeln der Regelung, außerdem im Scheduling, in der Kommunikation und in der Robustheit gegenüber Ausnahmezuständen.
Ich hab hin und wieder mit Sachen aus der Autoindustrie zu tun, und was ich da sehe, haut mich -- der programmiertechnische Teil -- absolut nicht vom Hocker. Ich glaube die Leute sehen Programmierung als notwendiges Übel an, das irgendwo zwischen Entwurf und Testen gequetscht wird. Die Qualität (oder was man dafür hält) wird durch rigide Formvorschriften sichergestellt. Ich würde da nicht als Programmierer arbeiten wollen.

[Gast]

Bashar schrieb:

Ich glaube die Leute sehen Programmierung als notwendiges Übel an, das irgendwo zwischen Entwurf und Testen gequetscht wird.

Das ist richtig. Von diesen Leuten kommen z.B. Aussagen wie: "Die beste Software ist keine Software." :p

[sdf]

Z schrieb:

sdf schrieb:

All das braucht man bei µC nicht.
Lediglich Datenstrukturen können noch hilfreich sein.
Für die Mathe reicht in den meisten Fällen die Schulmathematik bis zur 13.

Na, wenn du meinst. Dann erklär mir doch mal, wieso Firmen wie beispielsweise diese hier und diese, ausgebildete Physiker und Mathematiker beschäftigen, wenn das alles so furchtbar einfach ist, dass jeder Wald-und-Wiesen-Informatiker, der mal ein paar .NET-Anwendungen zusammengezimmert hat, damit klar käme? :p

WLAN (-> Elektromagnetische Wellen) und Sensoren (-> nutzen Reale Welt um Information zu erhalten) haben nunmal etwas mit Physik zu tun, du brauchst dort die Physiker und Mathematiker also für das Materielle, eben der Hardwareentwicklung.
Aber definitiv nicht zum Programmieren der µC die die Sensoren auslesen!