¿Por qué C domina en el mercado de software embebido? [cerrado]

Casi todos dirán ahora la bendición:

rendimiento !

De acuerdo, C permite escribir código atlético. ¡Pero hay otros idiomas que pueden hacerlo, después de todo! Y el poder de optimización de los compiladores modernos es impresionante. ¿ C tiene algunas ventajas que ningún otro lenguaje tiene? ¿O simplemente no hay necesidad de instrumentos más flexibles en el dominio?

Casi todos dirán ahora la bendición:

¡actuación!

Eso es parte de eso; El uso determinista de recursos es importante en dispositivos con recursos limitados para empezar, pero hay otras razones.

1. Acceso directo a API de hardware de bajo nivel.
2. Puede encontrar un compilador de C para la gran mayoría de estos dispositivos. Esto no es cierto para ningún lenguaje de alto nivel en mi experiencia.
3. C (el tiempo de ejecución y el ejecutable generado) es "pequeño". No tiene que cargar un montón de cosas en el sistema para ejecutar el código.
4. Las API / controladores de hardware probablemente se escribirán en C o C ++.

C fue diseñado para modelar una CPU, porque C fue creado para hacer que Unix sea portátil en todas las plataformas en lugar de solo escribir lenguaje ensamblador.

Esto significa que los programas C funcionan bien como un lenguaje de programación para programas que necesitan tener un nivel de abstracción muy cercano a la CPU real, como es el caso del hardware incorporado.

Nota: C fue diseñado alrededor de 1970 y las CPU eran más simples entonces.

Una razón para la dominación es que tiene el tipo correcto de herramientas para la tarea. Después de haberse desarrollado en plataformas integradas tanto en Java como en C / C ++, puedo decirle que el enfoque básico de C ++ es simplemente más natural. Salvar al desarrollador de la sensación de que él o ella está saltando a través del aro porque el lenguaje es demasiado alto es algo bastante molesto. Un buen ejemplo es la ausencia de variables sin signo en Java.

Y las funciones prácticas de VM / lenguajes interpretados generalmente no son factibles y quedan fuera de la implementación, por ejemplo, recolección de basura.

C requiere muy poco soporte de tiempo de ejecución en sí mismo, por lo que la sobrecarga es mucho menor. No está gastando memoria o almacenamiento en soporte de tiempo de ejecución, gastando tiempo / esfuerzo para minimizar ese soporte, o tener que permitirlo en el diseño de su proyecto.

Como se mencionó en otras respuestas, C se desarrolló a principios de la década de 1970 para reemplazar el lenguaje ensamblador en una arquitectura de minicomputadora. En aquel entonces, estas computadoras generalmente cuestan decenas de miles de dólares, incluida la memoria y los periféricos.

Hoy en día, puede obtener la misma o mayor potencia de la computadora con un microcontrolador integrado de 16 bits que cuesta cuatro dólares o menos en cantidades individuales, incluidos los controladores de E / S RAM incorporados. Un microcontrolador de 32 bits cuesta quizás un dólar o dos más.

Cuando estoy programando a estos pequeños, que es lo que hago el 90% del tiempo cuando no estoy diseñando los tableros en los que se sientan, me gusta visualizar lo que el procesador va a hacer. Si pudiera programar lo suficientemente rápido en ensamblador, lo haría.

No quiero todo tipo de capas de abstracción. A menudo depuro revisando una lista de diseminadores en la pantalla. Para empezar, es mucho más fácil hacerlo cuando has escrito el programa en C.

No domina por completo, ya que C ++ se usa cada vez más a medida que los compiladores han mejorado y el rendimiento del hardware ha aumentado. Sin embargo, C sigue siendo muy popular por algunas razones;

1. Amplio soporte. Casi todos los proveedores de chips proporcionan un compilador de CA y cualquier código de ejemplo y controladores probablemente se escribirán en c. Los compiladores de C ++ son cada vez más comunes, pero no son un certificado muerto para un chip dado, y a menudo son más defectuosos. También sabe que cualquier ingeniero integrado podrá trabajar en c. Es la lengua franca de la industria.

2. Actuación. Sí, lo dijiste. El rendimiento sigue siendo el rey y en un entorno donde las rutinas centrales todavía se escriben a menudo en ensamblador, o al menos se optimizan en c con referencia a la salida del ensamblaje, nunca subestimes la importancia de esto. A menudo, los objetivos integrados tendrán un costo muy bajo y tendrán muy pocos recuerdos y pocos mips.

3. Talla. C ++ tiende a ser más grande. Ciertamente, cualquier cosa que use el STL será más grande. Generalmente tanto en términos de tamaño del programa como en huella de memoria.

4. Conservatismo. Es una industria muy conservadora. En parte porque los costos de la falla son a menudo más altos y la depuración a menudo es menos accesible, en parte porque no ha tenido que cambiar. Para un pequeño proyecto incrustado, c funciona bien.

Para sistemas embebidos, lo importante es el rendimiento . Pero como dijiste, ¿por qué C y no otro lenguaje performante?

Muchas personas hasta ahora han mencionado la disponibilidad de compiladores , pero nadie ha mencionado la disponibilidad de desarrolladores . Muchos más desarrolladores ya conocen C que, por ejemplo, OCaml.

Esos son los tres grandes.

El software incorporado es muy diferente.

En una aplicación de escritorio, las abstracciones y las bibliotecas le ahorran mucho tiempo de desarrollo. Tiene el lujo de arrojar otro par de megabytes o gigabytes de RAM o algunos núcleos de CPU de 2 + GHz de 64 bits en un problema, y ​​otra persona (usuarios) está pagando por ese hardware. Es posible que no sepa en qué sistemas se ejecutará la aplicación.

En un proyecto integrado, los recursos suelen ser muy limitados. En un proyecto en el que trabajé (procesadores de la serie PIC 17X) el hardware tenía 2Kwords de memoria de programa, 8 niveles de pila (en hardware) y 192 bytes (<0.2kB) de RAM. Los diferentes pines de E / S tenían diferentes capacidades y usted configuró el hardware según sea necesario escribiendo en los registros de hardware. La depuración implica un osciloscopio y un analizador lógico.

En las incrustaciones, las abstracciones a menudo se interponen en el camino y gestionarían (y costarían) los recursos que no tiene. Por ejemplo, la mayoría de los sistemas integrados no tienen sistema de archivos. Los hornos de microondas son sistemas integrados. Controladores de motor de automóvil. Algunos cepillos de dientes eléctricos. Algunos auriculares con cancelación de ruido.

Un factor muy importante para mí en el desarrollo de sistemas embebidos es saber y controlar a qué se traduce el código en términos de instrucciones, recursos, memoria y tiempo de ejecución. A menudo, la secuencia exacta de instrucciones controla, por ejemplo, el tiempo para las formas de onda de la interfaz de hardware.

Las abstracciones y la "magia" detrás de escena (por ejemplo, un recolector de basura) es ideal para aplicaciones de escritorio. Los recolectores de basura le ahorran MUCHO tiempo persiguiendo pérdidas de memoria, cuando la memoria se puede / puede asignar dinámicamente.

Sin embargo, en el mundo embebido en tiempo real, necesitamos saber y controlar cuánto tardan las cosas, a veces en nanosegundos, y no podemos arrojar otro par de megas de RAM o una CPU más rápida a un problema. Un ejemplo simple: cuando se atenúa el software de los LED mediante el control del ciclo de trabajo (la CPU solo tenía el control de encendido / apagado de los LED), NO está bien que el procesador se apague y haga, por ejemplo, recolección de basura durante 100 ms porque la pantalla se vería visiblemente parpadea o se apaga.

Un ejemplo más hipotético es un controlador de motor que dispara directamente bujías. Si esa CPU se apaga y recolecta basura durante 50 ms, el motor se apagaría por un momento o se dispararía en la posición incorrecta del cigüeñal, lo que podría detener el motor (¿al pasar?) O dañarlo mecánicamente. Podrías matar a alguien.