Perché Embedded Strictly C / C ++ [chiuso]

Non mi è piaciuta questa domanda poiché non è possibile rispondere facilmente, ma forse posso riformulare: "Cosa impedisce a Embedded di cambiare lingua?"

Ad esempio, vediamo praticamente C / C ++ per embedded (penso di aver già sentito parlare di ADA prima? Correggimi se sbaglio)

Ma cosa impedisce esattamente al mondo Embedded di cambiare lingua? È solo che C è troppo facile da usare o non c'è davvero un "bisogno" di un cambiamento dal momento che C fa tutto bene?

Questo mi ha sempre confuso, non mi lamento. Dal momento che tenerlo in poche lingue mantiene le cose standardizzate. Ma rimane ancora la domanda.

Mi rendo conto che questa è una specie di domanda soggettiva, tuttavia la mia domanda principale è "Perché" e non "SE / QUANDO"

Prima di tutto: dimentica di "incorporato" in quanto non è una distinzione utile. L'importantissima proprietà è "limitata dalle risorse". La risorsa più importante è spesso il tempo, nel qual caso parliamo di sistemi in tempo reale, ma può anche essere memoria o energia.

• L'adozione di nuove lingue è difficile e rara. Richiede una nuova formazione, nuovi strumenti e la ricerca di un buon modo di lavorare con la nuova lingua. Questo è costoso, soprattutto per i primi utenti. È anche un problema a base di galline e uova: senza una grande base di utenti non ci saranno strumenti e libarari di buona qualità, ma senza quelli non ci sarà una grande base di utenti. Quindi una nuova lingua deve avere un grande vantaggio rispetto a quelle esistenti, altrimenti non avrà alcuna possibilità.

• La maggior parte dei nuovi "recenti" sviluppi linguistici hanno colmato il divario tra la potenza della CPU disponibile e ciò di cui l'utente ha bisogno. In altre parole: possono essere inefficienti in termini di velocità, ma compensare essendo più facili per il programmatore. Pensa all'ascesa di linguaggi come Java, Python, Perl, Tcl che sono essenzialmente gestiti da un interprete (forse dopo qualche compilazione) e fanno un uso pesante della gestione dinamica della memoria. Ma ciò non si abbina bene con il mondo limitato dalle risorse, dove vogliamo ottenere a) il massimo dalle risorse disponibili, anche a spese di maggiori sforzi di programmazione eb) un uso prevedibile delle risorse.

• C e C ++ (o un sottoinsieme adatto) sono ancora i linguaggi di livello più elevato che sono di uso comune (abbastanza che sono disponibili strumenti validi, programmatori sufficientemente addestrati e librerie estese) in grado di soddisfare requisiti di spazio e tempo prevedibili non troppo lontani da ciò che è possibile sull'hardware corrente. L'unico contendente è che credo Ada, ma ha sofferto di un brutto inizio: le prime implementazioni erano (percepite come?) Troppo lente e inefficienti, e ora (anche se sono disponibili buone implementazioni) il linguaggio è rimasto un po 'indietro in caratteristiche (rispetto al C ++). Personalmente penso che sia un peccato, a parità di condizioni preferirei volare su un piano programmato in Ada piuttosto che su uno che è stato fatto in C o C ++.

Con i sistemi embedded basati su microcontrollori a 8 e 16 bit, si arriva alla conclusione che è più semplice sviluppare software in grado di adattarsi alle risorse limitate di queste limitazioni di archiviazione molto modeste (forse qualche 100 byte di RAM per microcontrollori a 8 bit di fascia bassa , con 2-8 KiB di ROM o EPROM / Flash per la memorizzazione del codice).

In quei casi, linguaggi di piccole dimensioni come C o assembly tendono ad essere i linguaggi di sviluppo più comunemente utilizzati. Come confronto relativo molto approssimativo, un assemblatore completo e un compilatore C99 possono adattarsi a un singolo disco floppy, mentre sono necessari diversi MiB per un moderno sistema di sviluppo C ++ (con STL, ecc.).

Quando si guardano i micro di fascia più alta (high-end a 16 bit e principalmente a 32 bit, con 64 bit abbastanza rari) e DSP in ambienti embedded, le restrizioni si indeboliscono e lo sviluppo del software può costituire la maggior parte dello sviluppo sforzo, quindi ha senso utilizzare gli strumenti di sviluppo più produttivi, compresi linguaggi più avanzati con funzionalità come linguaggi di programmazione orientata agli oggetti (OOP) come C ++ e linguaggi più recenti (Java, Perl, Ruby, Python).

È possibile in Assembly e C prevedere la quantità di memoria utilizzata, in modo che sia possibile progettare con uno spazio limitato, ma funzionalità avanzate come modelli, gestione delle eccezioni e associazione runtime rendono impossibile conoscere esattamente il footprint di memoria necessario per un programma C ++ standard in anticipo. Non ne so abbastanza di MISRA C ++ , che è un sottoinsieme di C ++, per commentarlo.

I linguaggi basati su macchine virtuali che eseguono byte-code (Java, Perl, Python) sono meno maturi nell'esperienza dello sviluppatore incorporato e poiché questi linguaggi sono progettati per isolare il programmatore dal particolare hardware, rende anche più difficile essere coscienti di limitazioni e restrizioni di tale sistema hardware incorporato. Questo è meno un problema con processori veloci a 32 bit (ad esempio ARMv7) con MiB se non GiB di RAM.

Tutte le implementazioni BASIC di cui sono a conoscenza sono piuttosto semplicistiche nelle caratteristiche del linguaggio, rimanendo sostanzialmente fedele all'eredità di Dartmouth BASIC degli anni '60. Ciò significa che la lingua non ha librerie runtime complesse o gestione delle eccezioni e che un interprete o un compilatore è abbastanza semplice da scrivere ed ha anche dimensioni di file ridotte. La maggior parte dei microcontrollori ha almeno un compilatore BASIC disponibile per questo.

Spero che delinei i motivi per cui troverai C e assembly utilizzati principalmente su sistemi embedded più piccoli o più vecchi, e con le limitazioni dei nuovi sistemi embedded di fascia medio-alta differiscono solo leggermente da un personal computer desktop tradizionale.

La maggior parte delle risposte ha già indicato le ragioni storiche (ben noto, tutti lo usano, non sarebbe facile cambiare le abitudini, ecc.). Mentre sono d'accordo con loro, dovremmo tenere presente che esiste un'altra ragione importante.

E ' non è che "C è una scelta cattiva o non aggiornato, ma abbiamo ancora lo usano per abitudine" (come le tastiere QWERTY).

C è di per sé un'ottima scelta per lo sviluppo embedded, specialmente in applicazioni time-critical. Perché?

• è abbastanza basso da poter essere facilmente utilizzato per implementare programmi in tempo reale. Se è necessario misurare il tempo nei nanosecondi, intercettare un interrupt ogni 5 microsecondi o utilizzare esattamente 64 byte di RAM totale, quindi con un linguaggio di livello molto elevato sarebbe spesso impossibile o molto difficile risolverlo . C ti offre un controllo molto migliore sull'hardware rispetto ai linguaggi di livello superiore, questa è una delle differenze più importanti tra lo sviluppo per embedded rispetto a PC.

• è abbastanza alto da essere veloce e facile da programmare, rispetto ad Assembly.

Quindi, C è il miglior (o uno dei migliori) compromesso tra la velocità e l'accesso diretto all'hardware di Assembly e la facile lettura e comprensione di linguaggi di alto livello.

È esattamente lo stesso motivo per cui nella programmazione regolare le lingue (più utilizzate) non cambiano (realmente):

1. Enorme quantità di codice esistente (librerie / implementazioni esistenti)
2. Grande set di strumenti in grado di funzionare con queste lingue (IDE, simulatori, ...)

Nel mondo embedded, può essere molto più difficile (o impossibile) fornire aggiornamenti software, quindi è tanto più critico garantire la correttezza. Sfortunatamente C fornisce pochissimo aiuto in questo senso e permette al programmatore di giocare velocemente e liberamente.

Mi fa male usare C per i sistemi embedded, e vorrei almeno passare a C ++ per i numerosi vantaggi che offre sotto forma di vincoli come const, riferimenti, tipizzazione di stringer, ecc.

Immagino che la risposta sia semplicemente che siamo bloccati con C perché il cambiamento non è commercialmente praticabile. Tutti conoscono C, ci sono un sacco di compilatori per esso, librerie per esso e strumenti per generarlo. Con una nuova lingua, inizieremmo da zero.

Immagino sia per questo che le persone usano ancora PHP .

Nessuno qui ha sentito parlare di SPARK Ada?

Questa è una versione "piccola" del linguaggio Ada e dei relativi strumenti di sviluppo per sistemi embedded, ad es. Avionica e altre applicazioni critiche per la sicurezza come le apparecchiature mediche.

Gli studi hanno mostrato solo una perdita del 5-10% nella velocità di elaborazione rispetto a C / C ++ con la codifica SPARK più affidabile.

Penso che la proliferazione di C nei sistemi embedded sia dovuta a motivi economici:

• È già lì e di solito utilizzabile per la maggior parte delle applicazioni - e la maggior parte delle applicazioni su base volumetrica non sono critiche, nessuno morirà se la lavatrice invade - quindi perché cambiare?

• Il set di strumenti SPARK rappresenterà una spesa aggiuntiva in sé e per la formazione del personale.

• I vantaggi aggiuntivi di SPARK (o di altri linguaggi non C) per il controller / sistema di gestione incorporato potrebbero non essere sufficienti per giustificare il premio necessario nel prezzo del prodotto agli occhi del consumatore, soprattutto quando vedono vendere marchi rivali apparentemente "buoni" per un prezzo inferiore.

• La società AdaCore sta attenta a non approfondire troppo le applicazioni del mercato di massa in quanto queste richiederanno inevitabilmente un forte aumento del personale di supporto tecnico per affrontare le questioni non fondamentali. AdaCore è un'azienda ad alto livello di competenza, è orgogliosa in quanto tale e presenta i propri prodotti e servizi a società ad alta tecnologia. È insolito che una lingua penetri in nuovi mercati a meno che i suoi principali stakeholder non lo vogliano davvero.

Quindi, @ Wouter, non devi preoccuparti di morire nei cieli per mancanza del codice incorporato di Ada!

È già nei sistemi aerei da molti anni. Allo stesso modo per il tuo pacemaker.

Ma per la lavastoviglie, il sistema di controllo dei servizi di costruzione, il controller della fornace da laboratorio e altre arene non così rigorosamente regolamentate, vale la pena economicamente fare il possibile?

Immagino che la ragione principale della popolarità di C sia la prima: C è popolare e molte persone lo sanno e in secondo luogo: nessuno dei nuovi linguaggi popolari come Java, C # e persino molti aspetti di C ++ sono adatti per il lavoro incorporato. Fondamentalmente le altre 3 lingue che ho menzionato si basano molto sulla memoria dinamica, che porta con sé l'esecuzione non deterministica del programma, oggetti, che portano con sé memoria dinamica, requisiti di memoria di grandi dimensioni (poiché uno dei lati più importanti di OO è l'uso di maggior numero di classi), la crescente popolarità della compilazione just in time (e molte piattaforme embedded non riescono nemmeno a compilare il proprio codice C) ...

C'è anche il fatto che molte delle librerie fornite con Java o C # sono inutili per un gran numero di progetti integrati.

D'altra parte, abbiamo lingue più vecchie come il Pascal o il Basic. Dal mio punto di vista, non sono così popolari perché C si è fatto il linguaggio "standard del settore" e un numero molto elevato di programmatori e ingegneri impara oggi il C. In alcune scuole Pascal o Basic non vengono nemmeno appresi. C'è anche il fatto che molte lingue oggi popolari hanno una sintassi simile al C e l'uso di Pascal sarebbe strano per un programmatore C.

Per quanto riguarda FORTRAN, suppongo che sia andato in un campo di nicchia e sia utilizzato principalmente da ingegneri e scienziati che lavorano in aree in cui esiste un ecosistema adatto per il suo utilizzo. Non vedo alcun motivo particolare (diverso da quelli che ho citato per Pascal e Basic) che non viene utilizzato su sistemi embedded.

Da notare che in questa risposta mi sono concentrato principalmente su sistemi più piccoli. Esistono anche molti dispositivi embedded che utilizzano sistemi operativi più complessi come GNU / Linux o qualche altro derivato Unix e per programmarli, è possibile utilizzare più o meno qualsiasi linguaggio popualr.

C è un linguaggio molto semplice ed è stato più volte indicato come linguaggio di assemblaggio di fantasia . È quasi la quantità minima di astrazione che puoi fornire sopra il codice dell'assieme, poiché i costrutti C mappano in modo abbastanza diretto sui costrutti a livello di macchina.

Per questo e molti altri motivi, è molto semplice implementare un compilatore C su un nuovo chip. Gran parte del lavoro è già fatto, c'è relativamente poca complessità o cose che vanno male, e il controllo di basso livello ti consente di gestire abbastanza facilmente qualsiasi stranezza del tuo hardware.

Il C ++ può essere (effettivamente originariamente) implementato come livello di traduzione del codice sorgente sopra C, il che significa che puoi ottenere C ++ (o almeno una sua versione) gratuitamente con il tuo compilatore C.

Con C e C ++, sei un bootstrap praticamente tutto il necessario per il tuo nuovo chip, rendendolo il punto logico per iniziare.

Alcuni motivi che gli altri non hanno menzionato:

• Spazio problematico: C è adatto per sistemi piccoli e semplici. Se tutto ciò che fai è reagire a segnali esterni e spingere qualche numero in giro, allora C funziona piuttosto bene (nessuna struttura di dati complessa, nessun malloc, nessuna complessa gestione degli errori).

• Volume di produzione: se si hanno grandi tirature di produzione, è economicamente sensato risparmiare su ogni unità hardware e spendere di più per i programmatori, poiché la programmazione è un costo una tantum.

Penso che sia perché C / C ++ sono i linguaggi di livello più basso e di alto livello.

In effetti, per i piccoli sistemi embedded il C è molto più popolare del C ++. E la ragione di ciò è la stessa di non usare altre lingue. Il C ++ richiede un runtime, a meno che non si dia via la maggior parte delle funzionalità che lo rendono diverso da C.

Oltre all'assembly, C è l'unico linguaggio che conosco che viene compilato in codice nativo e per il quale avere un runtime è opzionale. Quindi è garantito il minimo ingombro e il tempo di esecuzione più rapido in un ambiente limitato (tranne se si utilizza l'assemblaggio).

D'altra parte, nei sistemi embedded di medie e grandi dimensioni (per cui intendo più memoria e clock, parole più grandi) non direi che C (o C ++) è così prevalente. Ho visto sistemi che supportano Python, Forth ... persino Java.

Ma ovviamente hai quasi sempre la possibilità di usare C / C ++, ovviamente, per le stesse ragioni che ho menzionato sopra. E avendo l'opzione, e essendo te qualcuno che già si sente a proprio agio con C per i piccoli sistemi integrati, perché dovresti scegliere un'altra lingua?