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

[Redhead]

Hacker23 schrieb:

...die anderen sprachen sind einfach zu hässlich...

Wer so einen Quark schreibt, ist garantiert in überhaupt keinem Bereich TÄTIG.

[~fricky]

Embedded Progger schrieb:

Meine Aussage, daß es immer Leistungsfähigere Chips im Embedded Bereich gibt und alte CPUs auf kurz oder lang dadurch verdrängt werden, bleibt also weiterhin unberührt.

µCs kommen und gehen. trotzdem besteht immer ein bedarf an low-end controllern. nach deiner logik dürfte es seit jahrzehnten keine fahrräder mehr geben, weil motorisierte fahrzeuge im handel sind.

[Embedded Progger]

~fricky schrieb:

µCs kommen und gehen. trotzdem besteht immer ein bedarf an low-end controllern. nach deiner logik dürfte es seit jahrzehnten keine fahrräder mehr geben, weil motorisierte fahrzeuge im handel sind.

Nein, denn du machst ja einen Äpfel Birnen vergleich.

Aber es gibt in der Tat keine Autos mehr, die nur 80 km/h schnell sind.
Da habe ich also schon recht.

Selbst ein Gold schaft heute locker > 190 Sachen, das war früher noch undenkbar.

[Erhard Henkes]

Ich kenne das Thema nur aus dem Hobby-Robotik-Bereich. Dort habe ich selbst den Nibo (Zentralprozessor: ATmega128 mit 4096 Bytes SRAM ) versuchsweise in C++ programmiert, um das State Pattern Design für die Navigation umzusetzen. Allerdings ist das wirklich nur ein modulares C mit Klassen. Es gibt noch kein echtes new und delete und Probleme bei "pure virtual" (siehe den absolut richtigen Kommentar von Volkard weiter vorne).

Umgehungen:

// Hilfskonstruktionen
//
// pure virtual wird dennoch ausgeführt:
extern "C"{
void __cxa_pure_virtual() {} }
//
// Ersatz für new, new[], delete und delete[] der fehlenden C++-Standard-Bibliothek
void* operator new      (size_t size) { return malloc(size); }
void* operator new[]    (size_t size) { return malloc(size); }
void  operator delete   (void* ptr)   { free(ptr); }
void  operator delete[] (void* ptr)   { free(ptr); }
//

Die C++-Schlüsselwörter new/delete werden durch das klassische malloc/free aus C ersetzt und für den ins Leere führenden Aufruf der Funktion __cxa_pure_virtual() schafft man einfach eine Sprungmarke mit einem leeren Rumpf.

Wen es genau interessiert: http://www.henkessoft.de/Roboter/Nibo.htm (unteres Drittel)

Gegenüber einer Realisierung in C bieten sich die bekannten Vorteile der Objektorientierung. Auf Dauer wird sich ein "C mit Klassen" in einigen Bereichen vielleicht durchsetzen. Für den Nibo gibt es auch eine JavaVM. Aber zur Zeit alles nur Spielerei.

Es war für mich allerdings ziemlich schwierig das Ganze zu realisieren, da man kaum Unterstützung im C++-Bereich findet, z.B. makefile, obige Umgehungen, ... .

Hier zwei Links zu dem Thema:
http://www.mikrocontroller.net/topic/23923
http://www.roboternetz.de/phpBB2/viewtopic.php?p=349094

[rüdiger]

@Embedded Progger
Die Anlagen bei der Prozessorherstellung veralten wirklich schnell. Aber nur wenn man Highendchips produziert. Intel und AMD müssen ja regelmäßig ihre Fabriken umbauen. Aber das gilt eben nur für Highendchips und die sind für den Embeddedbereich ja eh eher uninteressant. Die brauchen halt viel Leistung und eine nicht so einfache Infrastruktur. Hinzu kommt, dass die Anlagen ja ständig umgebaut werden. Es würde mich wundern, wenn Intel die Anlagen für ihre Highendchips 10 Jahre behält.

Und die Highendchiphersteller sind ja auch daran interessiert, dass die alten Chips nicht mehr hergestellt werden. Angenommen du könntest eine 2 Jahre Intel CPU für 1/100 des Preise kaufen. Dann wären 95% des PC Marktes damit doch zufrieden. Die würden sich ja einfach nur ihren eigenen Markt zerstören.

Und die Anlagen für die üblichen µCs werden ja nicht geändert. Die sind ja idr abbezahlt und daher ist es möglich die Kosten derart niedrig zu halten. µC Hersteller planen da sicher anders, als jemand der einen Highendchip herstellt.

Natürlich gibt es auch im Embeddedbereich immer leistungsfähigere Chips, so wie sie zB ARM herstellt. Aber das liegt nicht daran, dass sie einfach alte Anlagen nutzen um Embeddedchips herzustellen, sondern daran, dass es eben einen entsprechenden Leistungsbedarf gibt. Settopboxen, Handhelds, Handies etc. verlangen ja entsprechende Rechenpower. Aber man würde so etwas eben doch nicht in einen Toaster einbauen (außer der Toaster ist eine Settopbox mit Toasterfunktion ;)). Und die 32 Bit ARM CPUs sind ja auch teurer als ein üblicher 8Bit µC und ARM hat ja auch Interesse daran, den Preis hochzuhalten! In 10 Jahren werden die die Dinger nur günstiger verkaufen, wenn der Markt das erfordert!

Daher dürfte der Fall, dass man eine leistungsfähigere Architektur zu den gleichen (oder besseren) Konditionen, wie eine schlechtere Architektur bekommt, nur sehr selten geben. Selbst wenn die Kosten der Hardware vergleichbar sind und die Leistungsdaten stimmen, dann kommt ja wieder die Frage der Entwicklungskosten hinzu und da dürfte es im Endeffekt dann doch wieder günstiger sein, einen alten Hasen einzustellen, der die alte Hardware absolut kennt, als jemanden für die neue Architektur zu finden.

[Embedded Progger]

rüdiger schrieb:

@Embedded Progger
Die Anlagen bei der Prozessorherstellung veralten wirklich schnell. Aber nur wenn man Highendchips produziert. Intel und AMD müssen ja regelmäßig ihre Fabriken umbauen. Aber das gilt eben nur für Highendchips und die sind für den Embeddedbereich ja eh eher uninteressant.

Eigentlich baut nur AMD ihre Fabriken um.

Die großen finanzkräftigen Konzerne wie Intel oder Texas Instruments, sowie diese TMC? (habe den Namen vergessen, ich meine die, die für Nvidia die GPU fertigen) rüsten die Fabriken nicht um, sondern bauen einfach neue
und die alten Fabriken produzieren dann halt das Low Level Zeugs bzw. eben die alten CPU Generationen bzw. gute schnelle aber günstige Embedded Chips.

Eine Fabrik von 200 mm Wavern auf 300 mm Wavern umzurüsten kostet nämlich einfach Geld, weil die Fabrik in der Zeit der Umstellung dann still steht und nichts produziert.
Deswegen ist es besser, für die neuen High End CPUs einfach komplett neue Fabriken zu bauen während die alten Fabriken weiterhin ausgelastet bleiben.
Und wenn der Firma nichts einfällt, was sie mit der alten Fabrik machen soll,
dann verkauft sie diese eben an einen anderen Chipmanufaktor der sich vielleicht auf Low Level Billig Chips konzentriert hat.
Umgerüstet wird allerhöchsten noch im kleinen, aber die großen Umbauten wie man sie bei AMD kennt, gibt es bei den großen Chipriesen eigentlich nicht.
Denn die können es sich locker leisten komplett neue Fabriken zu bauen, AMD kann das nicht und AMD kommt ja nichtmal mit der Produktion nach, die brauchen also noch viel mehr neue moderne Chipfabriken.

Die brauchen halt viel Leistung und eine nicht so einfache Infrastruktur. Hinzu kommt, dass die Anlagen ja ständig umgebaut werden. Es würde mich wundern, wenn Intel die Anlagen für ihre Highendchips 10 Jahre behält.

Siehe oben.
Und ja, soviel ich weiß produziert Intel noch 386er CPUs auf ein paar ihrer Altanlagen.
Natürlich nicht mehr für den PC Konsumermarkt, aber eben halt für die Industrie.

Und die Highendchiphersteller sind ja auch daran interessiert, dass die alten Chips nicht mehr hergestellt werden. Angenommen du könntest eine 2 Jahre Intel CPU für 1/100 des Preise kaufen. Dann wären 95% des PC Marktes damit doch zufrieden. Die würden sich ja einfach nur ihren eigenen Markt zerstören.

Nein, denn schnelle CPUs kann man nicht oft genug haben.
Wenn das was du sagst stimmen würde, dann würden die ganzen Konsumenten bei ihren alten CPUs bleiben.
Tun sie aber nicht, denn die wollen und kaufen neue schnellere CPUs.

Und die Anlagen für die üblichen µCs werden ja nicht geändert. Die sind ja idr abbezahlt und daher ist es möglich die Kosten derart niedrig zu halten. µC Hersteller planen da sicher anders, als jemand der einen Highendchip herstellt.

Eben, die alten 386er Fabriken sind ja schon abbezahlt, aber dennoch produziert man auf diesen keine lahmen 8 Bit CPUs sondern die schnelleren 32 Bit CPUs, einfach weil die Anlagen es hergeben.

Natürlich gibt es auch im Embeddedbereich immer leistungsfähigere Chips, so wie sie zB ARM herstellt. Aber das liegt nicht daran, dass sie einfach alte Anlagen nutzen um Embeddedchips herzustellen,

Doch, genau daran liegt es.
Denn die heutigen ARM CPUs sind nicht umsonst nur bei maximal 600 MHz Takt,
sondern weil die alten Anlagen aus den 1 GHz Zeiten der x86 Reihe (übrigens das ist auch schon wieder 8 Jahre her!) nichts besseres produzieren können, wenn man auch Strom sparen will.

Würde man diese ARM CPUs aber auf modernen Anlagen in 45 nm Technik herstellen,
(was man noch nicht tut), dann könnte der Takt vielleicht schon locker für diese Stromspar CPUs bei 1,2 GHz liegen.

Es werden also für die ARM CPUs sehr wohl Altanlagen verwendet.
Nur sind die natürlich noch lange nicht so alt, wie z.b. für den MSP430.
Da sind die Anlagen etwa 8 weitere Jahre noch älter.

Aber die 8 Bit CPUs, von denen ihr die ganze Zeit sprecht, da sind die Anlagen schon 30 Jahre alt und irgendwann rechnen sich die Produktionskosten dieser lahmen 8 Bit Chips nicht mehr, wenn der MSP430 auf den ebenfalls schon abbezahlten > 16 Jahre alten Fabriken gleich günstig produziert werden kann.
Und in 5 Jahren dürfte es für den so weit sein.
Und die ersten ARM CPUs werden dann in 9-10 Jahren ebenfalls nachziehen.
Natürlich nicht zu den 600 MHz Taktrate, denn das ist ja die heutige SPitzenleistung der ARM CPUs, sondern eben zu den bewährten Taktraten von vielleicht 66 MHz, die sich schon heute seit über 8 Jahren bewährt haben und jetzt nur noch im Preis fallen werden bis sie für ein paar Cent zu haben sind.

Sondern daran, dass es eben einen entsprechenden Leistungsbedarf gibt. Settopboxen, Handhelds, Handies etc. verlangen ja entsprechende Rechenpower. Aber man würde so etwas eben doch nicht in einen Toaster einbauen (außer der Toaster ist eine Settopbox mit Toasterfunktion ;)).

Wie ich schon sagte, wenn du die Wahl hast, zwischen einer 32 Bit und einer 8 Bit CPU, bei gleichem Preis, dann wirst du als Kunde das leistungsfähigere Produkt wählen, auch dann, wenn du nur Toaster bauen willst.

Und die 32 Bit ARM CPUs sind ja auch teurer als ein üblicher 8Bit µC

Ja, jetzt, aber wie oft muß ich hier noch sagen, daß es in 10 Jahren nicht mehr so sein wird.
Dann wirst du auch die 66 MHz ARM Versionen für <1 € nachgeschmissen bekommen und die sind dann halt schon deutlich schneller als die 8 Bit CPU aus dem Jahre 1980.

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

Nein, denn das ist ja nicht nötig.
Denn die High End ARM CPUs werden immer nötig sein.
Heute sind es 400-600 MHz in der High End Klasse, die Midrange Preisklasse liegt bei 66 - 400 MHz,
aber schion sind es in der High End Klasse 800-1600 MHz,
die High End Klasse von Heute rutscht dann in die Midrange Preisklasse,
das werden also die 400-600 MHz schnellen CPUs sein und die Midrange Preisklasse von Heute werden in den Centbereich abrutschen.

Beim MSP430 kann man das schon beobachten.
Vor kurzem war der noch Midrange im Embedded Bereich, aber er wird von Jahr zu Jahr billiger und landet bald im Centbereich.

In 10 Jahren werden die die Dinger nur günstiger verkaufen, wenn der Markt das erfordert!

Da Leistungsfähige Cent CPUs wieder völlig neue Möglichkeiten erschließen lassen, wird es immer einen Markt geben.

Selbst wenn die Kosten der Hardware vergleichbar sind und die Leistungsdaten stimmen, dann kommt ja wieder die Frage der Entwicklungskosten hinzu und da dürfte es im Endeffekt dann doch wieder günstiger sein, einen alten Hasen einzustellen, der die alte Hardware absolut kennt, als jemanden für die neue Architektur zu finden.

Die alten Hasen leben oder arbeiten auch nicht ewig.
Und mit den schnelleren Cent CPUs erschließt man neue Möglichkeiten.

[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

[sam foo]

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.

[~fricky]

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/...

[Embedded Progger]

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.

[Embedded Progger]

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.