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

Erhard Henkes

Im µC- und Robotikbereich benötigt man auf Dauer auch normierte Schnittstellen, um nicht jedes Mal 90-95% Basics wieder von vorne programmieren zu müssen. Das war ja einer der großen Vorteile bei MS Windows gegenüber DOS, wenn man da mal an Sound, Grafik oder Input denkt. Ein typischer Versuch dieser Art ist MS Robotics Studio, das momentan natürlich noch belächelt wird, langfristig aber den richtigen Weg weist. C++, Java, Betriebssysteme werden sich - analog der PC-Entwicklung - im embedded-Bereich ihren Weg bahnen, aber das braucht Zeit. Lohnt sich natürlich nur bei innovativen Bereichen und nicht im Low-Cost-Sector.

abc.w

Die ganze Diskussion dreht sich bisher um uC und CPUs. Was ist mit den programmierbaren Logikbausteinen, FPGAs und CPLDs? Ich denke, man müsste hier noch erwähnen, in Zukunft gibt es neben C++ oder Java auch noch VHDL und Verilog oder gar SystemC...

tfa

abc.w schrieb:

Die ganze Diskussion dreht sich bisher um uC und CPUs. Was ist mit den programmierbaren Logikbausteinen, FPGAs und CPLDs? Ich denke, man müsste hier noch erwähnen, in Zukunft gibt es neben C++ oder Java auch noch VHDL und Verilog oder gar SystemC...

Wieso in Zukunft? Verilog und VHDL sind viel älter als Java.
Außerdem sind es Hardwarebeschreibungssprachen, die sich C++ oder gar Java schlecht vergleichen lassen.

abc.w

tfa schrieb:

abc.w schrieb:

Die ganze Diskussion dreht sich bisher um uC und CPUs. Was ist mit den programmierbaren Logikbausteinen, FPGAs und CPLDs? Ich denke, man müsste hier noch erwähnen, in Zukunft gibt es neben C++ oder Java auch noch VHDL und Verilog oder gar SystemC...

Wieso in Zukunft? Verilog und VHDL sind viel älter als Java.
Außerdem sind es Hardwarebeschreibungssprachen, die sich C++ oder gar Java schlecht vergleichen lassen.

Ok, sie lassen sich schlecht vergleichen. Aber ich denke, man darf die Diskussion nicht nur auf C++ und Java beschränken. Vielleicht werden in Zukunft im Embedded Bereich nur die FPGAs dominieren. Die ganzen C++ oder Java Programme werden nach VHDL übersetzt und die ganzen Projekte ausschließlich in VHDL/Verilog "programmiert"... Was heisst denn "Verilog und VHDL sind viel älter als Java"?

tfa

abc.w schrieb:

Ok, sie lassen sich schlecht vergleichen. Aber ich denke, man darf die Diskussion nicht nur auf C++ und Java beschränken. Vielleicht werden in Zukunft im Embedded Bereich nur die FPGAs dominieren. Die ganzen C++ oder Java Programme werden nach VHDL übersetzt und die ganzen Projekte ausschließlich in VHDL/Verilog "programmiert"...

Ja, aber warum? Ich glaube nicht, dass das so einfach möglich ist. Außerdem wäre sehr viel teurer als bei einer "Mainstream"-Sprache wie C++ oder Java zu bleiben. Hardwarebeschreibungssprachen sind doch sehr anders.

Was heisst denn "Verilog und VHDL sind viel älter als Java"?

Sie wurden früher erfunden als Java, so ca. 10-12 Jahre

tfa schrieb:

Außerdem wäre sehr viel teurer als bei einer "Mainstream"-Sprache wie C++ oder Java zu bleiben.

Es kann garnicht teurer sein, als vorher, wenn man mit C++ oder Java die Systeme richtig konfiguriert.

rüdiger schrieb:

...und ARM hat ja auch Interesse daran, den Preis hochzuhalten!

ARM ist es ziemlich schnurz, zu welchem preis die controller-hersteller ihr zeug verkaufen.

Erhard Henkes schrieb:

Auf Dauer wird sich ein "C mit Klassen" in einigen Bereichen vielleicht durchsetzen.

nö. C hat structs und braucht deshalb keine klassen. weill du die erweiterten features von c++ auf einem kleinen embedded system kaum verwenden kannst (wie du schon bemerkt hast), bringt's nix, wenn du object.method() statt method(&object) schreiben kannst.

abc.w schrieb:

Die ganze Diskussion dreht sich bisher um uC und CPUs. Was ist mit den programmierbaren Logikbausteinen, FPGAs und CPLDs?

serienmässige microcontroller mit integriertem cpld, etc. gibts ja schon lange. aber möglicherweise wird konfigurierbare hardware irgendwann mal unsere starre PC-technik ablösen. hier ist z.b. ein schönes beispiel: http://www.c64upgra.de/c-one/

tfa schrieb:

Außerdem wäre sehr viel teurer als bei einer "Mainstream"-Sprache wie C++ oder Java zu bleiben. Hardwarebeschreibungssprachen sind doch sehr anders.

ja, aber als c++ progger muss man nicht unbedingt verilog können: http://de.wikipedia.org/wiki/SystemC

Erhard Henkes

nö. C hat structs und braucht deshalb keine klassen. weill du die erweiterten features von c++ auf einem kleinen embedded system kaum verwenden kannst (wie du schon bemerkt hast), bringt's nix, wenn du object.method() statt method(&object) schreiben kannst.

Das ist überwiegend die aktuelle Wertung, die sich aber durch Sprünge in der Hardwareentwicklung ändern kann. Die Geschichte der Sprachen auf den Großrechnern/PCs (Assembler -> C-> C++ -> C#/Java/...) und der Betriebssysteme mag hier als Analogon für die mögliche weitere Entwicklung dienen.

volkard

Erhard Henkes schrieb:

Die Geschichte der Sprachen auf den Großrechnern/PCs (Assembler -> C-> C++ -> C#/Java/...)

hihi. die bloße zeitlich erfindungsabfolge ist ein tolles maß.
zum vergleich die geschichte der automobile:
Ford Model A -> VW Käfer -> Porsche 911 -> Renault Twingo

Nagila Hawa

ja, aber als c++ progger muss man nicht unbedingt verilog können: http://de.wikipedia.org/wiki/SystemC

Das ändert nichts daran, daß Hardwarebeschreibung etwas ganz anderes ist als "Softwarebeschreibung". VHDL baut auch auf einer Programmiersprache, Ada, auf. Das ändert aber nichts daran, daß man Ada-Programme nicht einfach so in Hardware gießen kann. Genauso wird man keine C++-Programme in Hardware gießen können.

Als C++ Programierer muß man also kein Verilog können, aber irgendeine Hardwarebeschreibungssprache zu beherrschen wäre schon nicht schlecht. Die Syntax von SystemC ist vielleicht ähnlich der von C++, aber Syntax sollte das geringste Problem bei der Erlernung von HDLs sein.

Im Übrigen habe ich den Eindruck, daß C++ nicht unbedingt für seine besonders angenehme Syntax bekannt ist, wieso also eine HDL mit C++-Syntax?

abc.w

tfa schrieb:

Was heisst denn "Verilog und VHDL sind viel älter als Java"?

Sie wurden früher erfunden als Java, so ca. 10-12 Jahre

Ach so, wir haben uns missverstanden. Ich habe mich vorhin bezogen auf die Frage "Welcher Programmiersprache gehört die Zukunft im Embedded Bereich? C++ oder Java" ausgedrückt und habe dabei ein Paar Gedanken übersprungen.

tfa schrieb:

...Ich glaube nicht, dass das so einfach möglich ist. Außerdem wäre sehr viel teurer als bei einer "Mainstream"-Sprache wie C++ oder Java zu bleiben. Hardwarebeschreibungssprachen sind doch sehr anders.

Es gibt ja bereits Compiler, die C/C++ Quellcode nach VHDL/Verilog übersetzen können (Catapult C oder C2H). Einige FPGA Hersteller nutzen sie angeblich so für irgendwelche Video Demos. Sie schreiben Algorithmen in C/C++ und "kompilieren" bestimmte Teile des Codes nach VHDL/Verilog. Und so wird dann die Perfomance demonstriert. Bei relativ kleinen Taktfrequenzen. So nach dem Prinzip, man braucht keinen 400 MHz DSP sondern einen FPGA mittlerer Größe mit einer 50 MHz Softcore CPU und einer Software, deren rechenintensiven Teile in Hardware ausgelagert sind.

Erhard Henkes

zum vergleich die geschichte der automobile:
Ford Model A -> VW Käfer -> Porsche 911 -> Renault Twingo

Der Vergleich passt doch perfekt
Porsche 911 -> Renault Twingo
C++ -> Java/...

abc.w schrieb:

Die ganze Diskussion dreht sich bisher um uC und CPUs. Was ist mit den programmierbaren Logikbausteinen, FPGAs und CPLDs? Ich denke, man müsste hier noch erwähnen, in Zukunft gibt es neben C++ oder Java auch noch VHDL und Verilog oder gar SystemC...

Dafür gibt es schon Verilog und auf diesen Programmierbaren Logikbausteinen gibt es faktisch keine Software wie bei einem Mikrocontroller, da da sowieso alles reine Hardware ist.

Das ist also ein ganz anderes Gebiet.

abc.w schrieb:

Bei relativ kleinen Taktfrequenzen. So nach dem Prinzip, man braucht keinen 400 MHz DSP sondern einen FPGA mittlerer Größe mit einer 50 MHz Softcore CPU und einer Software, deren rechenintensiven Teile in Hardware ausgelagert sind.

Ein ganz anderes Thema ist übrigens die Frage, ob FPGA überhaupt wirklich eine nennenswerte Zukunft haben oder doch eher immer ein Nischenprodukt für bestimmte Spezialfälle bleiben.

FPGAs sind z.b. Klasse wenn es paralelle Berechnungen geht, da kann man in FPGAs sehr viele Recheneinheiten erstellen, die dann so ne Berechnung sehr schnell durchführen können.
So war es zumindest bisher so und dafür waren FPGAs sehr gut.
Diese Raytraycing Hardware aus der Uni in Saarland wurde z.b. in FPGAs realisiert.

Aber FPGAs haben einen großen Nachteil, sie sind im Vergleich zu echter Hardwware sehr langsam und was den Einsatzzweck von paralellen Berechnungen betrifft, dafür gibt es heute und kommen immer stärker Grafikkarten mit CUDA und OpenCL und die machen das zwar alles in Software, aber dafür sind sie mit > 500 MHz und mehr viel schneller als FPGAs und deren Entwicklung was die Anzahl der Cores betrifft, nimmt auch immer stärker zu.

Wo soll da also noch ein Markt für FPGAs sein?
Ich sehe das aufgrund von CUDA und OpenCL sehr skeptisch und jetzt kommt ja noch Fusion und Larabee.

Dann könnte man natürlich sagen, daß mam mit FPGAs spezielle DSPs realisieren kann, das ist natürlich alles richtig, nur wandern in die embedded Chips wie ARM und MSP430 schon heute sehr viele DSP Einheiten rein.
D.h. die brauchen meist keinen extra in FPGA realisierten DSP Soundchip mehr, da sie selbst einen haben.

D.h. es bleiben also für FPGAs nur sehr spezielle Aufgabengebiete übrig, bei der die embedded CPUs noch zu langsam sind, aber die werden ja auch immer schneller.

Daher halte ich die Zukunft der FPGAs für fraglich.
D.h. die werden jetzt zwar nicht aussterben sondern natürlich immer noch nebenbei weiterbestehen, aber sie werden im Gegensatz zu den fertigen Mikrocontrollern auch immer unwichtiger, da letztere ja immer Leistungsfähiger werden und somit meist schon alles so in Software können.

Aber wie die Zukunft von FPGAs aussieht, das wäre dann jetzt doch wieder ein eigener Diskussionsthread wert.

Embedded Progger schrieb:

Aber wie die Zukunft von FPGAs aussieht, das wäre dann jetzt doch wieder ein eigener Diskussionsthread wert.

Lies dir aber bitte mal vorher z.B. das durch, damit du wenigstens mit Halbwissen glänzen kannst.
http://de.wikipedia.org/wiki/Field_Programmable_Gate_Array

Tim schrieb:

Embedded Progger schrieb:

Aber wie die Zukunft von FPGAs aussieht, das wäre dann jetzt doch wieder ein eigener Diskussionsthread wert.

Lies dir aber bitte mal vorher z.B. das durch, damit du wenigstens mit Halbwissen glänzen kannst.
http://de.wikipedia.org/wiki/Field_Programmable_Gate_Array

Glaub mir, ich kenne die Anwendungsgebiete von FPGAs gut genug.

Aber gehen wir mal auf die Anwendungsgebiete der Wikipedia ein und sagen was es da als Alternative gibt:

PGAs haben in den letzten Jahren ihren Anwendungsbereich von der klassischen „Glue-Logic“, also der reinen Verbindungslogik zwischen verschiedenen digitalen Bausteinen, zunehmend erweitert und werden heute auch bei mittleren Stückzahlen für die Realisierung komplexer digitaler Schaltungen bis hin zu kompletten digitalen Systemen eingesetzt.

Alternative:
-> System on a Chip (SoC)
http://de.wikipedia.org/wiki/System_on_Chip

Durch die Rekonfigurierbarkeit von FPGAs direkt beim Endanwender besteht darüber hinaus der wesentliche Vorteil, auf aktuelle technische Entwicklungen reagieren zu können und die digitalen Schaltungen durch Updates anpassen zu können, ohne direkt die zugrundeliegende Hardware der FPGA-Chips verändern zu müssen.

Alternative:
Wenn man programmierbare Mikrochips hat, die Leistungsfähig genug sind,
dann kann man auch mit reiner Software deren Fähigkeiten verwirklichen und die Software dann updaten.

Und ich sagte ja, die Zukunft!
In der Zukunft werden wir unglaublich leistungsfähige Embedded Mikrochips genaugenommen SoCs haben.

FPGAs werden beispielsweise zur Echtzeit-Verarbeitung von einfachen bis komplexen Algorithmen genutzt, zur digitalen Signalverarbeitung im Rahmen von digitalen Filtern oder zur schnellen Fourier-Transformation. Aber auch Protokoll-Implementierungen wie Teile des Ethernet-MAC-Layers, die Kodierung von digitalen Videosignalen, die Verschlüsselung von Daten und Fehlerkorrekturverfahren sind Anwendungsgebiete.

Ja, das sind noch so ein paar Nischengebiete wo es für FPGAs platz gibt.

Wobei auch hier viele Funktionen schon heute in die SoCs wandern (z.b. Ethernet) oder beim PC diese Funktionen in den Mainboard Chipsatz wandern.

Besonders in Bereichen, in denen Algorithmen bzw. Protokolle einer schnellen Weiterentwicklung unterliegen, ist die Verwendung rekonfigurierbarer FPGAs statt ASICs angebracht. Die Vorteile sind schnelle Marktreife, nachfolgende Fehlerbehebungen, Anpassung an neue Entwicklungen.

Mikroprozessoren sind per Software immer veränderbar und wenn man deren zukünftige Leistungsfähigkeit berücksichtigt, dann werden die das mit Software abdecken könenn, was die FPGAs heute können.

Für einige Klassen von Rechenproblemen sind auch FPGA-basierte Parallelcomputer sehr geeignet. Das wahrscheinlich bekannteste Beispiel sind FPGA-Rechner zum Brechen kryptographischer Verfahren, wie dem Data Encryption Standard (DES). Der aus 120 FPGAs bestehende Parallelrechner COPACOBANA ist ein solcher Parallelcomputer zum Codebrechen.

Tja, ich sagte ja.
Grafikkarten, Larabee und Fusion.
Sowie CUDA und OpenCL.

Wer braucht da noch langsame FPGAs?

Die inzwischen erreichte Anzahl von Logikblöcken erlaubt die Integration mehrerer eingebetteter Computersysteme in einen einzigen FPGA-Baustein inklusive CPU(s), Bussystem(en), RAM, ROM, RAM-Controller, Peripherie-Controller etc. Solche kompletten Systeme werden als System on a Chip (SoC) bezeichnet.

Und diese SoCs gibt es genau auch als normale ICs.

[QUOTE]
FPGAs werden auch als Entwicklungsplattform für den digitalen Teil von ASICs verwendet.
[QUOTE]
Ja, auch noch ne Nischenlösung die übrig bleibt.

Wie du also siehst.
Ich kenne die FPGAs mehr als gut genug um darüber ein Urteil zu sprechen.

Und ich werde ganz sicher nicht für paralelle berechnungen auf 50 MHz langsame FPGAs setzen, wenn ich CUDA mit 256 Core Einheiten habe, die mit 1 GHz getaktet sind.

Ja, die machen dann alles in Software, sind aber aufgrund der Taktrate dennoch schneller als die FPGAs.

abc.w

@Embedded Progger

Alternative:
-> System on a Chip (SoC)
http://de.wikipedia.org/wiki/System_on_Chip

Genau, lies doch mal im Link von Dir, was da von FPGAs steht.

abc.w

Und hier gibt es noch einen Link mit ähnlicher Diskussion und vielen vielen Meinungen (FPGA contra Mikrocontroller): http://www.mikrocontroller.net/topic/50101

Embedded Progger schrieb:

Und ich sagte ja, die Zukunft!
In der Zukunft werden wir unglaublich leistungsfähige Embedded Mikrochips genaugenommen SoCs haben.

Während FPGAs immer langsamer werden. Sorry, du bist halt doch nur ein zweitklassiger Troll.

volkard schrieb:

Erhard Henkes schrieb:

Die Geschichte der Sprachen auf den Großrechnern/PCs (Assembler -> C-> C++ -> C#/Java/...)

hihi. die bloße zeitlich erfindungsabfolge ist ein tolles maß.

naja, man sollte zumindest annehmen, dass die nachfolger aus den fehlern der vergangenheit gelernt haben usw, also der fortschritt geht von links nach rechts.

Nagila Hawa schrieb:

Im Übrigen habe ich den Eindruck, daß C++ nicht unbedingt für seine besonders angenehme Syntax bekannt ist, wieso also eine HDL mit C++-Syntax?

ich auch nicht. dieses systemC war ja ursprünglich nur zur simulation gedacht, aber mittlerweile solls schon systhesetools geben, die aus systemsC netzlisten machen und fpgas damit befüllen.