Welcher Programmiersprache gehört die Zukunft im Embedded Bereich? C++ oder Java

vlad_tepesch schrieb:

also wir programmieren unsere µCs und DSPs in C. Warum?
geringere Größe weil, schlankere Runtime.
keine dynamische speicherallokierung erlaubt.
meist auch schneller.

Ja geringere Größe und schlankere Runtime.
Aber ihr arbeitet dann sicher noch mit Embedded Chips die noch nicht den Speicher und Leistung von heutigen aktuellen Embedded Chips liefern.

Also noch alte Technik, wegen langen in der Industrie üblichen Supportzeiten von 10 Jahren.
Aber DAS wird irgendwann aufhören, in 10 Jahren habt ihr sicher auf einen der neuen Embedded Chips umgestellt und ist Speicherplatzersparnis und schlankheit
der Routinen kein Argument mehr um auf Programmierfreundliche Programmiersprachen zu verzichten.

In diesem Kontext möchte ich das betrachtet sehen.

Außerdem kann man auf den GC und dynamische Speicherallokierung ja auch verzichten.
Das geht sowohl in C++ als auch in D.

Wenn man so durch Portierung vom Prototypencode in c++ nach c einen DSP einsparen kann, oder einen kleineren verwenden kann, lohnt sich bei entsprechenden Stückzahlen natürlich auch ein Portierungsaufwand von 2-3 Mannjahren.

Ja, aber siehe oben.

Irgendwann gibt es die Leistungsschwachen 8 Bit CPUs nicht mehr oder sie lohnen sich nicht mehr, weil die 32 Bit CPUs genau das gleiche kosten.

Und die DSP wandern bei diesen Embedded CPUs sowieso mit auf den Chip.
Man denke z.B. an ARM oder MSP430 CPUs.

Edit:
außerdem ist c natärlich sehr Hardwarenah.

Ja, das ist jetzt einer der Gründe, welche wirklich für C sprechen.
Aber dies wäre zumindest mit C++ und D auch möglich.

[quote="rapso"]

vlad_tepesch schrieb:

ich denke java hat eine chance wenn es hauptsaechlich um die anwendung geht und nicht die hardware. wenn die software aber nur das mittel zum zweck ist (weil es um die hardware geht), wird c weiter standard bleiben.

Ja, wenn es um grafische Oberflächen geht.
Z.b. eine grafishes Menü mit Touchpad für eine Waschmaschine, dann wäre Java sicher eine Option.

Aber was Hardwarenaheprogrammierung betrifft, mit Realtime Code.
Da ist es ja nun wirklich nicht so, daß hier C++ oder D nicht gehen würde.

Nagila Hawa schrieb:

Mobile Geräte müssen natürlich auch Energie sparen. Der effizienteste Energiesparprozessor bringt nichts, wenn die Software die zehnfache Rechenleistung benötigt, wie eine alternative Lösung für die gleiche Aufgabe.

Ich würde sagen Assembler und C werden weiterhin für kleine Programme verwendet, C++ für größere Systeme, Ada für sicherheitskritische Systeme. Zumindest tendenziell.

Ein Newcomer würde mich natürlich brennend interessieren.

Meinst du Newcomer wie D?

Ja, wenn die ersten Compiler für Embedded Platformen verfügbar sind, dann wäre D in der Tat sehr interessant.

Embedded Progger schrieb:

Aber DAS wird irgendwann aufhören, in 10 Jahren habt ihr sicher auf einen der neuen Embedded Chips umgestellt und ist Speicherplatzersparnis und schlankheit
der Routinen kein Argument mehr um auf Programmierfreundliche Programmiersprachen zu verzichten.

Auch in 10 Jahren wird es große und kleine µC geben, und auch in 10 Jahren wird der Große mehr kosten als der Kleine (Ausnahmen die diese Regel bestätigen gibt es auch heute). Da kannst du mit deinen "für 2€ hinterhergeschmissen"-µCs kommen wie du willst. Auch in 10 Jahren wird man eine Rechnung aufstellen und Abhängig von Stückzahl, Entwicklungskosten, Produktionskosten etc. entscheiden welcher µC genommen wird. Aber mit deinen letzten Worten schlägt bei mir auch der troll-o-meter an. "Programmierfreundliche Programmiersprachen" sorry, ernst nehmen kann ich dich nicht...

Und D? Hallo? Ich lach mich gleich weg...

tfa

volkard schrieb:

Kennerio schrieb:

Und einen größeren Schwachsinn habe ich selten gelesen (@volkard).

es würde dir gut anstehen, dir die geschichte von java ein wenig zu gemüte zu führen. kläre dabei doch mal die designziele von oak ab. in den alten jdks steht übrigens noch oak statt java in den dateikopfkommentaren.

Oje! Das ist wirklich schon mehr als 10 Jahre her, dass sich Sun von Oak und dem Gedanken verabschiedet hat, eine Programmiersprache für Toaster und Waschmaschinen zu entwickeln. Java hat sich in den letzten anderthalb Jahrzehnten weiter eintwickelt, falls du dir das mal zu Gemüte führen willst.
Und Java auf Handys ist nun mal Fakt. Ob einem das gefällt oder nicht.

vlad_tepesch

Embedded Progger schrieb:

Also noch alte Technik, wegen langen in der Industrie üblichen Supportzeiten von 10 Jahren.
Aber DAS wird irgendwann aufhören, in 10 Jahren habt ihr sicher auf einen der neuen Embedded Chips umgestellt und ist Speicherplatzersparnis und schlankheit
der Routinen kein Argument mehr um auf Programmierfreundliche Programmiersprachen zu verzichten.

Naja unser DSP ist nicht so alt: Blackfin 561 dualcore mit je 500MHz. und davon sinds 2.
Dennoch ist es recht wenig, für die vielzahl der Anwednungen, die er gleichzeitig berechnen soll.
hierbei handelt es sich um Bildverarbeitung mit komplexen matehmatischen Hypothesen und Modellen, die gebildet werden.
Zumal er keine FPU hat.

Das heißt man investiert bewusst einige Mannjahre an Ent-double-isierungsaufwand um dann ein paar Dollar einzusparen.
Es kommt halt auf die Stückzahlen an.

Ebendso mit der portierung nach C.
Wenn man sich die STL anschaut, ist das sehr nett, aber natürlich auch recht overhead-behaftet, der eingespart werden muss.

Außerdem kann man auf den GC und dynamische Speicherallokierung ja auch verzichten.
Das geht sowohl in C++ als auch in D.

Garbage Collector in C++?
D? lol, find mal ein embedded compiler für D.

borg

Embedded Progger schrieb:

Wieviel kosten 128 MB RAM heute? 2 €?

Soso, und du denkst 2€ sind wenig? Was glaubst du wie oft sich z.B. ein Controller der die Neigung von einem Scheinwerfer in Autos entsprechend der Lastverteilung im Auto anpasst verkauft? Für 2€ kannst du da ohne weiteres 5 Mannjahre (und mehr) investieren. Dazu kommt noch das die Kosten dafür verglichen mit den Kosten für Tests und Zertifizierungen gar nicht auffallen.

vlad_tepesch schrieb:

Garbage Collector in C++?
D? lol, find mal ein embedded compiler für D.

Ja, natürlich.
In C++09 wird der Garbage Collector dabei sein und ich versuche den Thread ja auf die Sicht aus "in 10 Jahren" zu betrachten.

Und in 10 Jahren wird es für D bestimmt auch brauchbare Compiler für embedded Chips geben, denn gerade D bietet sich ja für solche Embedded Chips an.
Es hat nicht die Nachteile von C++ oder C, aber ist genauso für die Systemprogrammierung geeignet wie C und bietet darüberhinaus noch eine gute STD API.

borg schrieb:

Embedded Progger schrieb:

Wieviel kosten 128 MB RAM heute? 2 €?

Soso, und du denkst 2€ sind wenig? Was glaubst du wie oft sich z.B. ein Controller der die Neigung von einem Scheinwerfer in Autos entsprechend der Lastverteilung im Auto anpasst verkauft? Für 2€ kannst du da ohne weiteres 5 Mannjahre (und mehr) investieren. Dazu kommt noch das die Kosten dafür verglichen mit den Kosten für Tests und Zertifizierungen gar nicht auffallen.

Nun, es ist eine Annahme des untersten Preis von verfügbaren Mikrochips.
Ob es tatsächlich 2 € sind weiß ich nicht.

Aber eines steht klar, es gibt natürlich nichts günstigeres als dieses untersten Preises. Wo der unterste Preis liegt, bitte selbst anpassen!

Denn wie schon gesagt, es ist Fakt, wenn ich eine moderne 32 Bit Architektur
zu gleichen Produktions und Materialkosten auf die gleiche Die Fläche bekomme wie eine alte 8 Bit Architektur, dann hat die alte 8 Bit Architektur natürlich keinen Preisvorteil.

Und davon geht ihr ja aus, aber der ist ja nichtig, wenn wir reden ja schon vom untersten machbaren Preis.

@ Tim
Auf deinem Niveau diskutiere ich ganz sicher nicht.

hustbaer

Embedded Progger schrieb:

vlad_tepesch schrieb:

Garbage Collector in C++?
D? lol, find mal ein embedded compiler für D.

Ja, natürlich.
In C++09 wird der Garbage Collector dabei sein und ich versuche den Thread ja auf die Sicht aus "in 10 Jahren" zu betrachten.

lol.
informier dich mal richtig, was du schreibst ist falsch.
in c++0x wird es KEINEN GC geben!

hustbaer schrieb:

informier dich mal richtig, was du schreibst ist falsch.
in c++0x wird es KEINEN GC geben!

Vor noch ca. 12 Wochen habe ich da aber ganz anderes gehört.

volkard

[quote=http://en.wikipedia.org/wiki/C%2B%2B0x]Transparent garbage collection
C++0x will not feature transparent garbage collection directly. Instead, the C++0x standard will include features that will make it easier to implement garbage collection in C++.

Full garbage collection support has been remanded to a later version of the standard or a Technical Report.[/quote]

ihr fallt doch immer wieder auf den gleichen troll rein

rüdiger

Embedded Progger schrieb:

borg schrieb:

Embedded Progger schrieb:

Wieviel kosten 128 MB RAM heute? 2 €?

Soso, und du denkst 2€ sind wenig? Was glaubst du wie oft sich z.B. ein Controller der die Neigung von einem Scheinwerfer in Autos entsprechend der Lastverteilung im Auto anpasst verkauft? Für 2€ kannst du da ohne weiteres 5 Mannjahre (und mehr) investieren. Dazu kommt noch das die Kosten dafür verglichen mit den Kosten für Tests und Zertifizierungen gar nicht auffallen.

Nun, es ist eine Annahme des untersten Preis von verfügbaren Mikrochips.
Ob es tatsächlich 2 € sind weiß ich nicht.

Aber eines steht klar, es gibt natürlich nichts günstigeres als dieses untersten Preises. Wo der unterste Preis liegt, bitte selbst anpassen!

Der Punkt ist eben, dass es bei Embeddedsachen in der Regel um die Stückzahl geht. Das ist ja eine ganz einfache Rechnung: Mehrkosten * Stückzahl = Verbratenesgeld. Angenommen du gehst von 2€ aus und einer (wohl eher geringen Stückzahl) von 1 Millionen, dann hast du 2 Millionen € verbraten. Da lohnt es sich lieber 1 Millionen € in ein fähiges Entwicklerteam zu stecken.

Das ist eben der Unterschied zwischen dem Embedded und dem PC Bereich. Beim PC Bereich weißt du, dass die Rechenleistung exponentiell steigt (und du musst selbst idR nicht die Kosten der Hardware tragen). Also nimmt man lieber Tools, die im Endeffekt mehr Rechenleistung benötigen, aber die Entwicklungszeit reduzieren.

Embedded Progger schrieb:

Denn wie schon gesagt, es ist Fakt, wenn ich eine moderne 32 Bit Architektur
zu gleichen Produktions und Materialkosten auf die gleiche Die Fläche bekomme wie eine alte 8 Bit Architektur, dann hat die alte 8 Bit Architektur natürlich keinen Preisvorteil.

Und davon geht ihr ja aus, aber der ist ja nichtig, wenn wir reden ja schon vom untersten machbaren Preis.

Die Rechnung ist auch nicht so einfach. Du kannst ja zum Beispiel nicht einfach die alten Anlagen benutzen um die neue Architektur herzustellen und du musst die Entwicklung bezahlen, die Tests werden komplizierter etc. daher ist eine moderne Architektur teurer, auch wenn die Integrationsdichte höher ist. Hinzu kommt natürlich, dass du bei einer alten Architektur mehr Leute findest, getestete Tools hast und die Fehler der Hardware bekannt sind.

(Und im Zweifelsfall kann man immer noch damit argumentieren, dass du mit verbesserter Integration eben den 8 Bit Chip auf eine noch kleinere Fläche bekommst und noch weniger Material verbrauchst)

----
Wobei der Begriff Embedded eh eher schwammig ist. Eine Steuerung für einen Toaster mit sehr hoher Stückzahl ist natürlich was anderes, als die Programmierung einer Settopbox - die die Rechenleistung eines vielleicht 2 Jahre alten PCs bietet. Aber dennoch gibt es Leute für die beides unter die Embeddedprogrammierung fällt.

Embedded Progger schrieb:

@ Tim
Auf deinem Niveau diskutiere ich ganz sicher nicht.

Und ich geh nicht mit Reinhold Messner Bergsteigen. Go figure.

rüdiger schrieb:

Der Punkt ist eben, dass es bei Embeddedsachen in der Regel um die Stückzahl geht. Das ist ja eine ganz einfache Rechnung: Mehrkosten * Stückzahl = Verbratenesgeld. Angenommen du gehst von 2€ aus und einer (wohl eher geringen Stückzahl) von 1 Millionen, dann hast du 2 Millionen € verbraten. Da lohnt es sich lieber 1 Millionen € in ein fähiges Entwicklerteam zu stecken.

Um was dann zu erreichen?
Der Chip kostet ja immer noch 2 € -> untersten Preis.

Oder machen wir es ganz einfach, du ganz wählen zwischen:
8 Bit CPU Preis 2 €
oder
32 Bit CPU Preis auch 2 €

Denn 2 € ist der unterste Preis aller verfügbaren CPUs.
Wo sparst du da mit einem fähigen Entwicklerteam Geld ein?
Ohne CPU können die ja auch nichts anfangen.

Die Rechnung ist auch nicht so einfach. Du kannst ja zum Beispiel nicht einfach die alten Anlagen benutzen um die neue Architektur herzustellen

Da die heutigen Neuanlagen in 10 Jahren Altanlagen sind, werden die auch fähig sein diese billigen 32 Bit CPUs zu produzieren.
Was dann übrig bleibt sind reine Material und Energiekosten und hier dürften die neuen Anlagen wieder besser abschneiden.

und du musst die Entwicklung bezahlen, die Tests werden komplizierter etc.

Warum sollten die Tests mit C++ komplizierter werden als mit C?
Oder meinst du die Hardware?

Embedded CPUs haben den Vorteil, daß sie auf eine langfristige Produktion ausgelegt sind.
D.h. man nutzt die ersten 1-2 Jahre um die Anlage so zu
kalibrieren, daß sie einen hohen Yield erzeugen, also ne gute Rate Funktionsfähiger Chips ausspucht und dann läuft das Ding so weiter für die nächsten 5-8 Jahre, denn es sind ja Embedded CPUs die deutlich länger produziert werden als die modernen High Tech PC CPUs.
Und dennoch, auch bei den Embedded Chips steigt die Leistung mit den Jahren an.

daher ist eine moderne Architektur teurer, auch wenn die Integrationsdichte höher ist.

In 10 Jahren ist die aber nicht mehr modern, sondern alt.

Hinzu kommt natürlich, dass du bei einer alten Architektur mehr Leute findest, getestete Tools hast und die Fehler der Hardware bekannt sind.

Siehe oben.
Nimm z.b. eine moderne ARM CPU.
32 Bit fähig und mit nem Takt irgendwo bei 200 Mhz.
In 10 Jahren ist das alte Technik die zum Centpreis verkauft wird und die Tools dafür sind bis dahin ausgereift.
Tja, und jetzt stellt man fest, daß 200 MHz eigentlich unglaublich schnell sind für C++ und Java fängt ebenfalls an Interessant zu werden.

Heute kostet so ne ARM CPU ca. 10 €, aber schon morgen wird sie nur noch ein paar Cents kosten.

(Und im Zweifelsfall kann man immer noch damit argumentieren, dass du mit verbesserter Integration eben den 8 Bit Chip auf eine noch kleinere Fläche bekommst und noch weniger Material verbrauchst)

Ein MSP430 ist heutzutage inzwischen so groß die der Fingernagel des kleinen Fingers. D.h. der kommt schon in Bereiche vor, bei der die Bestückung zu ner Fummelarbeit wird.
Auch wenn man dafür Maschinen verwendet, so gibt es dennoch eine Mindestgröße.
Die Maschinen sind nämlich nicht in der Lage, im Nanobereich zu bestücken.

Also geht man lieber her und integriert die ganzen Technik drumherum, wie Speicheranbindung, DSP etc. in den Chip und bleibt bei etwa der Fingernagelgröße.
Denn eines muß man Bedenken, der Chip braucht auch Datenleitungen nach draußen und deswegen kann man den nicht unendlich Miniaturisieren.

Schon die Größe so eines SMD Kondensators ist kaum noch zu erreichen, wenn man über 32 Adressleitungen nach außen leiten muß.

Wobei der Begriff Embedded eh eher schwammig ist. Eine Steuerung für einen Toaster mit sehr hoher Stückzahl ist natürlich was anderes, als die Programmierung einer Settopbox - die die Rechenleistung eines vielleicht 2 Jahre alten PCs bietet. Aber dennoch gibt es Leute für die beides unter die Embeddedprogrammierung fällt.

In der Tat, für mich wäre beides schon Embedded.

Auch diese Switchs mit WLAN Router und Co würde ich schon in den Embeddedbereich zählen.

Tim schrieb:

Embedded Progger schrieb:

@ Tim
Auf deinem Niveau diskutiere ich ganz sicher nicht.

Und ich geh nicht mit Reinhold Messner Bergsteigen. Go figure.

Tja, dann müßtest du ja auch wissen warum du als Newbie mit mir hier nicht diskutieren mußt.

rüdiger schrieb:

Die Rechnung ist auch nicht so einfach. Du kannst ja zum Beispiel nicht einfach die alten Anlagen benutzen um die neue Architektur herzustellen und du musst die Entwicklung bezahlen, die Tests werden komplizierter etc. daher ist eine moderne Architektur teurer...

die entwicklung läuft sowieso ständig weiter. entwicklungskosten und testerei spielen kaum eine rolle. das ist ebenfalls nur 'ne rechnung von angebot, nachfrage, stückzahlen, etc. neue µCs werden anfangs in geringen stückzahlen produziert und brauchen einige teaser fatures, damit sich überhaupt einer dafür interessiert. wenn sie sich etabliert haben (was oft nicht der fall ist), wird die produktion hochgefahren und der preis gesenkt, um konkurrenten zu unterbieten und dadurch noch mehr verkaufen zu können. was glaubt ihr wohl, warum uCs so furchtbar billig sind? weil man kunden fast nur über geringen preis kriegt. ein µC, der z.b. eine eurone teurer ist, als ein anderer, muss viel-viel sinnvolle dinge (die käufer sind nicht doof!) mehr bieten, sonst hat er keine chance.

dass ihr euch auch auf jeden flamewar einlasst.

Nagila Hawa

Embedded Progger schrieb:

Denn 2 € ist der unterste Preis aller verfügbaren CPUs.
Wo sparst du da mit einem fähigen Entwicklerteam Geld ein?
Ohne CPU können die ja auch nichts anfangen.

Es gibt sogar bei Reichelt einen für 0.49€ und das ohne Mengenrabatt. Wie kommst du auf 2€ als fixe unterste Größe?

Embedded Progger schrieb:

daher ist eine moderne Architektur teurer, auch wenn die Integrationsdichte höher ist.

In 10 Jahren ist die aber nicht mehr modern, sondern alt.

Silizium-Kristall wird aus Sand hergestellt. Die Hauptkosten bei Mikrochips liegen in der Entwicklung. Nur um die Herstellung auf einen anderen Chip umzustellen bist du schnell im 4-Stelligen Bereich. Deswegen sind auch die 74er so günstig, weil die nun wirklich sehr sehr langlebig sind. Alte Chips werden immer günstiger und solche, bei denen von Anfang an davon ausgegangen wird, daß sie sehr lange und in hohen Stückzahlen hergestellt werden, sind von vornherein günstig, gegenüber Highend-Chips, die immer auf dem neuesten Stand der Technik sind.

Embedded Progger schrieb:

(Und im Zweifelsfall kann man immer noch damit argumentieren, dass du mit verbesserter Integration eben den 8 Bit Chip auf eine noch kleinere Fläche bekommst und noch weniger Material verbrauchst)

Ein MSP430 ist heutzutage inzwischen so groß die der Fingernagel des kleinen Fingers. D.h. der kommt schon in Bereiche vor, bei der die Bestückung zu ner Fummelarbeit wird.
Auch wenn man dafür Maschinen verwendet, so gibt es dennoch eine Mindestgröße.
Die Maschinen sind nämlich nicht in der Lage, im Nanobereich zu bestücken.

Das hat nichts mit der Chipgröße, sondern mit der Gehäusegröße zu tun.