Non hai bisogno di dispositivi diversi per usare queste lingue, hai solo bisogno del sistema software appropriato.

I problemi principali per cui questo non viene fatto più spesso sono:

• Questi linguaggi in genere richiedono più risorse (memoria, runtime) per lo stesso compito. Per grandi volumi lo sforzo ridotto nella programmazione sarebbe più che compensato da costi hardware più elevati.

• La maggior parte dei linguaggi di livello superiore richiede un'allocazione dinamica della memoria con garbage collection, cosa difficile da fare in un'impostazione in tempo reale.

• È più difficile ottenere sviluppatori incorporati per questi linguaggi.

Detto questo, ci sono cose come Real-Time Java, che vengono utilizzate in sistemi embedded reali.

Ci sono progetti open source che lavorano su questi obiettivi. C'è un progetto per Ada sugli MCU Atmel (anche se non sono riuscito a farlo funzionare). Uno dei miei colleghi sta programmando il suo MCU 68HC11 con una versione ridotta di Ruby su cui ha lavorato lui stesso. E c'è una società, BlueSpec, che ha un nuovo HDL per FPGA / ASIC basato su Haskell. Ma non è uno strumento a cui la maggior parte avrebbe accesso.

I fornitori tendono a rimanere fedeli a C perché c'è un vasto pubblico per C ed è ampiamente accettato. Allo stesso modo, per FPGA / PLD, VHDL / Verilog sono ampiamente accettati e collaudati. Invece di dover supportare molti linguaggi diversi, la maggior parte preferisce concentrarsi sui propri chip, cercando di migliorare le prestazioni dei propri compilatori C e offrire strumenti migliori per la configurazione e la gestione delle risorse sui propri chip. Sono d'accordo con questo approccio anch'io. Preferisco di gran lunga che Texas Instruments migliori i propri strumenti per la configurazione di periferiche avanzate sui propri chip piuttosto che implementare la metaprogrammazione avanzata dei modelli sul proprio compilatore C ++ minimo.

Sei perdonato.

Il motivo per cui C, e meno C ++, (tra l'altro linguaggio come VHDL) viene utilizzato per questo tipo di dispositivi è che è facile tradurre dai costrutti del linguaggio all'hardware sottostante. Il C è considerato lingua franca, compreso da molti e trasferire una nuova lingua sul dispositivo, specialmente se leggere / scrivere nei registri è scomodo, non vale lo sforzo se la lingua non è molto più brava nell'esprimere costrutti utili.

Gli esempi che usi come linguaggi più nuovi e più brillanti, D, per esempio, potrebbero essere candidati per un linguaggio di "basso livello" se più programmatori lo usano. D è pubblicizzato come il moderno C ++ senza tutti i compromessi con C e implementato fin dall'inizio. Purtroppo senza tutte le librerie C ++. Penso che tu possa chiamare le librerie C da D.

La domanda non è se è più recente, la domanda è se sono strumenti migliori. Per quanto posso vedere, non è così.
modifica
Quando ho scritto codice incorporato (in C), ho desiderato macro / modelli migliori di quelli che C può offrire. Poiché è un costrutto in fase di compilazione, non ha davvero nulla a che fare con l'hardware sottostante. Ma molto più complicato da implementare in un compilatore.

I dispositivi sono stati progettati per utilizzare altri linguaggi in modo efficiente, come LISP / Scheme, Forth e Java. Non credo che siano stati progettati per quei linguaggi che hai citato, forse non sono adatti per i sistemi embedded (a parte D che dovrebbe funzionare in modo efficiente su qualsiasi cosa progettata per C / C ++). Potrebbero, presumibilmente, essere implementati su qualsiasi MCU adatto, se qualcuno volesse farlo.

C'è sempre netduino, che ti consente di scrivere codice in .NET.

Dai un'occhiata a Micro Python http://micropython.org/

Micro Python è un'implementazione snella e veloce del linguaggio di programmazione Python 3 che è ottimizzato per funzionare su un microcontrollore. La scheda Micro Python è un piccolo circuito elettronico che esegue il linguaggio Micro Python.

È stato finanziato con successo come progetto kickstarter nel dicembre 2013 e hanno un tavola di riferimento.

Stai cercando un microprocessore. Intel li vende, così fanno AMD e ARM. Puoi usare qualsiasi lingua di programmazione su questi dispositivi.

Per quanto riguarda gli FPGA: la tua scelta di linguaggi è limitata. Questo perché hai bisogno di uno strumento di sintesi che traduca il tuo codice in una netlist. Oltre a VHDL, Verilog e (C limitato), puoi utilizzare linguaggi più moderni come MyHDL (basato su Python) o Bluespec (simile a Haskell).

In primo luogo i tuoi esempi sono piccoli dispositivi che hanno un insieme limitato di risorse, quindi i vecchi linguaggi vicini all'hardware come ce vhdl fanno bene il lavoro.

I nuovi linguaggi "interessanti" hanno bisogno di più risorse per funzionare bene, quindi la mia ipotesi è che ciò che stai cercando arriverà abbastanza presto poiché l'MCU sta diventando più potente nel tempo.

Il punto è che la maggior parte degli MCU: s è ancora programmata in C, e il ragazzo in gamba ha appena iniziato a giocare con C ++ su quei dispositivi.

Ma se dai un'occhiata all'MCU basato su ARM a 32 bit che ha molte più risorse rispetto al vecchio 8 bit una volta che può trovare progetti folli come eLua, che cerca di eseguire il linguaggio di script lua su un mcu basato su Cortex-M3 ...

Quindi ci arriveremo, ma lo farà impiegano un paio di anni in più e non penso che nessuno di quei folli progetti sia pronto per l'uso in produzione (ancora), ma alcuni lo saranno poiché è più veloce si sviluppano in linguaggi con un livello di astrazione più alto.

Esiste un ' applicazione proof-of-concept in esecuzione sotto Rust sui microcontrollori ARM STM32F4xx. Le sorprendentemente piccole modifiche necessarie per portare Rust sono disponibili in questo fork di Rust.