Perché C domina nel mercato del software embedded? [chiuso]

Quasi tutti ora diranno la benedizione:

spettacolo !

Va bene, C permette di scrivere un codice atletico. Ma ci sono altre lingue che possono farlo, dopo tutto! E il potere di ottimizzazione dei compilatori moderni è eccezionale. Fa C ha alcuni vantaggi che nessun altro linguaggio è? O semplicemente non c'è bisogno di strumenti più flessibili nel dominio?

Quasi tutti ora diranno la benedizione:

prestazione!

Fa parte di esso; l'uso delle risorse deterministiche è importante per i dispositivi con risorse limitate all'inizio, ma ci sono altri motivi.

1. Accesso diretto alle API hardware di basso livello.
2. È possibile trovare un compilatore C per la stragrande maggioranza di questi dispositivi. Questo non è vero per nessun linguaggio di alto livello nella mia esperienza.
3. C (il runtime e l'eseguibile generato) è "piccolo". Non è necessario caricare un sacco di roba nel sistema per far funzionare il codice.
4. Le API / i driver hardware saranno probabilmente scritti in C o C ++.

C è stato progettato per modellare una CPU, perché C è stato creato per rendere Unix portatile su più piattaforme invece di scrivere semplicemente un 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.

Uno dei motivi del dominio è che ha il giusto tipo di strumenti per l'attività. Dopo aver sviluppato piattaforme embedded sia in Java che in C / C ++, posso dirti che l'approccio bare to the bone del C ++ è semplicemente più naturale. Salvare lo sviluppatore dal sentire che sta saltando attraverso i cerchi perché la lingua è di livello troppo alto è una cosa piuttosto fastidiosa. Un buon esempio è l'assenza di variabili non firmate in Java.

E le utili funzionalità della VM / dei linguaggi interpretati di solito non sono fattibili e sono escluse dall'implementazione, ad es. Garbage Collection.

C richiede di per sé un supporto di runtime molto ridotto, quindi l'overhead è molto più basso. Non stai spendendo memoria o spazio di archiviazione sul supporto di runtime, non stai impiegando tempo / sforzi per minimizzare tale supporto o non devi permetterlo nella progettazione del tuo progetto.

Come menzionato in altre risposte, C è stato sviluppato nei primi anni '70 per sostituire il linguaggio assembly su un'architettura di minicomputer. Allora, questi computer in genere costano decine di migliaia di dollari, tra cui memoria e periferiche.

Al giorno d'oggi, puoi ottenere la stessa o maggiore potenza del computer con un microcontrollore incorporato a 16 bit che costa quattro dollari o meno in singole quantità, inclusi i controller RAM e I / O integrati. Un microcontrollore a 32 bit costa forse un dollaro o due in più.

Quando sto programmando questi ragazzini, che è quello che faccio il 90% delle volte quando non sto progettando le schede su cui siedono, mi piace visualizzare cosa farà il processore. Se potessi programmare abbastanza velocemente in assemblatore, lo farei.

Non voglio tutti i tipi di strati di astrazione. Spesso eseguo il debug passando attraverso un elenco di dissemblatori sullo schermo. È molto più facile farlo quando hai scritto il programma in C per cominciare.

Non domina del tutto poiché il C ++ viene sempre più utilizzato poiché i compilatori sono migliorati e le prestazioni dell'hardware sono aumentate. Tuttavia C è ancora molto popolare per alcuni motivi;

1. Ampio supporto. Praticamente ogni fornitore di chip fornisce compilatore ac e qualsiasi codice e driver di esempio saranno probabilmente scritti in c. I compilatori C ++ sono sempre più comuni, ma non rappresentano un dead dead per un determinato chip e sono spesso più potenti. Sai anche che qualsiasi ingegnere embedded sarà in grado di lavorare in c. È la lingua francese del settore.

2. Prestazione. Sì, l'hai detto. Le prestazioni sono ancora re e in un ambiente in cui le routine di base sono ancora spesso scritte in assemblatore, o almeno ottimizzate in c con riferimento all'output dell'assemblaggio, non sottovalutano mai l'importanza di questo. Spesso gli obiettivi incorporati avranno un costo molto basso e avranno memorie molto piccole e pochi mips.

3. Taglia. Il C ++ tende ad essere più grande. Certamente tutto ciò che utilizza STL sarà più grande. Generalmente sia in termini di dimensioni del programma che di ingombro della memoria.

4. 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 è necessario modificarlo. Per un piccolo progetto incorporato c fa bene il lavoro.

Per i sistemi embedded, la cosa importante sono le prestazioni . Ma come hai detto, perché C e non un altro linguaggio performante?

Molte persone finora hanno menzionato la disponibilità di compilatori , ma nessuno ha menzionato la disponibilità degli sviluppatori . Molti più sviluppatori conoscono già C di, diciamo, OCaml.

Questi sono i tre biggie.

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 della 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 incorporato, le risorse sono spesso molto limitate. In un progetto su cui ho lavorato (processori serie PIC 17X) l'hardware aveva 2 parole chiave di memoria del programma, 8 livelli di stack (nell'hardware) e 192 byte (<0,2 KB) di RAM. Pin I / O diversi avevano capacità diverse e l'hardware è stato configurato secondo necessità scrivendo ai registri hardware. Il debug comporta un oscilloscopio e un analizzatore di logica.

In embedded, le astrazioni spesso si intromettono e gestiscono (e costano) le risorse che non hai. Ad esempio, la maggior parte dei sistemi embedded non ha file system. I forni a microonde sono sistemi integrati. Controller per motori auto. Alcuni spazzolini elettrici. Alcune cuffie con cancellazione del rumore.

Un fattore molto importante per me nello sviluppo di sistemi embedded è conoscere e controllare ciò a cui il codice si traduce in termini di istruzioni, risorse, memoria e tempi di esecuzione. Spesso l'esatta sequenza di comandi di istruzioni, ad es. Tempistica per le forme d'onda dell'interfaccia hardware.

L'astrazione e la "magia" dietro le quinte (ad es. Un garbage collector) sono eccezionali per le app desktop. I garbage collector ti fanno risparmiare MOLTO tempo a caccia di perdite di memoria, quando la memoria è / può essere allocata in modo dinamico.

Tuttavia, nel mondo embedded in tempo reale, dobbiamo sapere e controllare quanto tempo impiegano le cose, a volte fino a nanosecondi, e non possiamo lanciare un altro paio di megabyte di RAM o una CPU più veloce a un problema. Un semplice esempio: quando si esegue l'oscuramento software dei LED controllando il ciclo di lavoro (la CPU aveva solo il controllo on / off dei LED), NON è GIUSTO che il processore si spenga e esegua ad esempio la garbage collection per 100 ms perché il display sarebbe visibilmente lampeggia o si spegne.

Un esempio più ipotetico è un controller del motore che accende direttamente le candele. Se quella CPU si spegne e esegue la raccolta dei rifiuti per 50 ms, il motore si spegne per un momento o si spegne nella posizione errata dell'albero motore, potenzialmente arrestando il motore (mentre passa?) O danneggiandolo meccanicamente. Potresti far uccidere qualcuno.