Quasi tutti ora diranno la benedizione:
prestazioni
Ok, C consente di scrivere codice atletico. Ma ci sono altre lingue che possono farlo, dopo tutto! E il potere di ottimizzazione dei compilatori moderni è fantastico. C presenta alcuni vantaggi che nessun altro linguaggio ha? O semplicemente non c'è bisogno di strumenti più flessibili nel dominio?
Almost everyone will now say the blessing:
performance!
Questo è parte di esso; l'uso di risorse deterministiche è importante su dispositivi con risorse limitate, ma ci sono altri motivi.
C è stato progettato per modellare una CPU, perché C è stato creato per rendere Unix portatile su piattaforme invece di scrivere solo linguaggio assembly.
Ciò significa che i programmi C funzionano bene come linguaggio di programmazione per i programmi che devono avere un livello di astrazione molto vicino alla CPU effettiva, come nel caso dell'hardware incorporato.
Nota: C è stato progettato intorno al 1970 e le CPU erano più semplici di allora.
C richiede pochissimo supporto di runtime in sé e per sé, quindi il sovraccarico è molto più basso. Non stai spendendo memoria o spazio di archiviazione sul supporto di runtime, spendendo tempo / impegno per ridurre al minimo tale supporto o doverlo permettere nella progettazione del tuo progetto.
Una ragione del dominio è che ha il giusto tipo di strumenti per il compito. Dopo essermi sviluppato su piattaforme embedded sia in Java che in C / C ++, posso dirvi che l'approccio "bare to bones" del C ++ è più naturale. Salvare lo sviluppatore dal sentire che lui o lei sta saltando i cerchi perché il linguaggio è troppo alto è una cosa abbastanza fastidiosa. Un buon esempio è l'assenza di variabili non firmate in Java.
E le pratiche funzionalità di VM / linguaggi interpretati non sono solitamente fattibili e sono lasciati fuori dall'implementazione, ad es. Garbage Collection.
Come menzionato in altre risposte, C è stato sviluppato nei primi anni '70 per sostituire il linguaggio assembly su un'architettura minicomputer. Allora, questi computer in genere costano decine di migliaia di dollari, inclusi memoria e periferiche.
Al giorno d'oggi, è possibile ottenere la stessa potenza del computer con un microcontroller incorporato a 16 bit che costa quattro dollari o meno in quantità singole, compresi i controller RAM e I / O incorporati. Un microcontrollore a 32 bit costa forse un dollaro o due di più.
Quando sto programmando questi piccoli ragazzi, che è quello che faccio il 90% delle volte in cui non sto progettando le schede su cui siedono, mi piace visualizzare ciò che il processore sta per fare. Se potessi programmare abbastanza velocemente nell'assemblatore, lo farei.
Non voglio tutti i tipi di livelli di astrazione. Eseguo spesso il debug passando attraverso un elenco di dissomiglianze sullo schermo. È molto più facile farlo quando hai scritto il programma in C per cominciare.
Non domina il tutto poiché il C ++ viene sempre più utilizzato mentre i compilatori sono migliorati e le prestazioni dell'hardware sono aumentate. Tuttavia C è ancora molto popolare per alcuni motivi;
Ampio supporto. Praticamente ogni produttore di chip fornisce un compilatore c e qualsiasi codice di esempio e driver sarà probabilmente scritto in c. I compilatori C ++ sono sempre più comuni, ma non un certificato morto per un determinato chip e sono spesso bugger. Sapete anche che qualsiasi ingegnere incorporato sarà in grado di lavorare in c. È la lingua franca del settore.
Prestazioni. Sì, l'hai detto tu. Le prestazioni sono ancora valide e in un ambiente in cui le core routine sono ancora spesso scritte in assembler, o almeno ottimizzate in c con riferimento all'output di assembly, non sottovalutano mai l'importanza di questo. Spesso gli obiettivi incorporati sono molto economici e hanno memorie molto piccole e pochi simboli.
Dimensioni. Il C ++ tende ad essere più grande. Certamente qualsiasi cosa utilizzi il STL sarà più grande. Generalmente sia in termini di dimensioni del programma che di impronta di memoria.
Il conservatorismo. È un'industria molto conservatrice. In parte perché i costi del fallimento sono spesso più elevati e il debug è spesso meno accessibile, in parte perché non ha bisogno di cambiare. Per un piccolo progetto integrato c fa bene il lavoro.
Per i sistemi incorporati, la cosa importante è prestazioni . Ma come hai detto tu, perché C e non qualche altro linguaggio performante?
Molte persone hanno finora menzionato disponibilità di compilatori , ma nessuno ha menzionato disponibilità di sviluppatori . Molti più sviluppatori conoscono già C di, per esempio, OCaml.
Queste sono le tre cose più importanti.
Il software incorporato è molto diverso.
Su un'app desktop, le astrazioni e le librerie ti fanno risparmiare molto tempo di sviluppo. Hai il lusso di lanciare un altro paio di megabyte o gigabyte di RAM o alcuni core CPU a 64 bit a 2 + GHz a un problema, e qualcun altro (utenti) sta pagando per quell'hardware. Potresti non sapere su quali sistemi verrà eseguita l'app.
In un progetto integrato, le risorse sono spesso molto limitate. In un progetto su cui ho lavorato (processori della serie PIC 17X) l'hardware aveva 2 KB di memoria di programma, 8 livelli di stack (in-hardware) e 192 byte (< 0.2kB) di RAM. Diversi pin I / O avevano capacità diverse e l'hardware è stato configurato come necessario scrivendo su registri hardware. Il debug coinvolge un oscilloscopio e un analizzatore logico.
In embedded, le astrazioni spesso intralciano e gestiscono (e costano) risorse che non si hanno. Per esempio. la maggior parte dei sistemi incorporati non ha un file system. I forni a microonde sono sistemi integrati. Controller per motori auto. Alcuni spazzolini da denti elettrici. Alcune cuffie con cancellazione del rumore.
Un fattore molto importante per me nello sviluppo di sistemi embedded è conoscere e controllare ciò che il codice traduce in termini di istruzioni, risorse, memoria e tempo di esecuzione. Spesso l'esatta sequenza di istruzioni controlla ad es. tempistica per forme d'onda dell'interfaccia hardware.
Le astrazioni e la "magia" dietro le quinte (ad esempio un garbage collector) sono ottime per le app desktop. I raccoglitori di immondizie ti fanno risparmiare un sacco di tempo a caccia di perdite di memoria, quando la memoria è / può essere allocata dinamicamente.
Tuttavia, nel mondo embedded in tempo reale abbiamo bisogno di conoscere e controllare quanto tempo le cose richiedono, a volte anche fino a nanosecondi, e non è possibile lanciare un altro paio di megabyte di RAM o una CPU più veloce a un problema. Un semplice esempio: quando si esegue il dimming software dei LED controllando il duty cycle (la CPU aveva solo il controllo on / off dei LED), NON è OK per il processore che si spegne e fa ad es. garbage collection per 100ms perché il display lampeggerà visibilmente o uscirà.
Un esempio più ipotetico è un controller del motore che accende direttamente le candele. Se quella CPU si disattiva e fa la garbage collection per 50 ms, il motore si fermerebbe per un momento o sparerebbe alla posizione sbagliata dell'albero motore, potenzialmente bloccando il motore (durante il passaggio?) O danneggiandolo meccanicamente. Potresti far uccidere qualcuno.
Leggi altre domande sui tag programming-languages c embedded-systems