¿Por qué Embedded Strictly C / C ++ [cerrado]

Primero que todo: olvídate de "incrustado" ya que no es una distinción útil. La propiedad más importante es "con recursos limitados". El recurso más importante suele ser el tiempo, en cuyo caso hablamos de sistemas en tiempo real, pero también puede ser memoria o poder.

• La adopción de un nuevo idioma es difícil y rara. Requiere reentrenamiento, nuevas herramientas y encontrar una buena manera de trabajar con el nuevo idioma. Esto es costoso, especialmente para los primeros adoptantes. También es un problema del huevo y la gallina: sin una gran base de usuarios no habrá herramientas y bibliotecas de buena calidad, pero sin esas no habrá una gran base de usuarios. Por lo tanto, un nuevo idioma debe tener una gran ventaja sobre los existentes, de lo contrario no tendrá ninguna posibilidad.

• La mayoría de los nuevos desarrollos "recientes" en idiomas han estado llenando el vacío entre la potencia de CPU disponible y lo que el usuario necesita. En otras palabras: pueden ser ineficientes en velocidad, pero compensar al ser más fáciles para el programador. Piense en el auge de lenguajes como Java, Python, Perl, Tcl que son esencialmente ejecutados por un intérprete (quizás después de alguna compilación) y haga un uso intensivo de la administración dinámica de memoria. Pero esto no coincide bien con el mundo de recursos limitados, donde queremos obtener a) el máximo provecho de los recursos disponibles, incluso a expensas de un mayor esfuerzo de programación, yb) un uso predecible de los recursos.

• C y C ++ (o un subconjunto adecuado) siguen siendo los lenguajes de más alto nivel que son de uso común (lo suficiente para que estén disponibles buenas herramientas, suficientes programadores capacitados y extensas bibliotecas) que pueden cumplir el espacio y el tiempo predecibles Requisitos que no están muy lejos de lo que es posible en el hardware actual. El único contendiente es Ada, pero ha tenido un mal comienzo: las primeras implementaciones fueron (¿se percibió que eran?) Demasiado lentas e ineficientes, y ahora (aunque hay buenas implementaciones disponibles) el lenguaje se ha retrasado un poco. características (en comparación con C ++). Personalmente, creo que esto es una pena, otras cosas son iguales. Prefiero volar en un avión programado en Ada a uno que se haya hecho en C o C ++.

Con los sistemas embebidos basados en microcontroladores de 8 y 16 bits, todo se reduce a que es más fácil desarrollar software que pueda adaptarse a los recursos limitados de estas limitaciones de almacenamiento muy modestas (quizás unos pocos bytes de RAM para microcontroladores de 8 bits de gama baja, con 2-8 KiB de ROM o EPROM / Flash para almacenamiento de código).

En esos casos, los lenguajes pequeños como C o ensamblaje tienden a ser los lenguajes de desarrollo más utilizados. Como una comparación relativa muy aproximada, un ensamblador completo y un compilador C99 pueden caber en un solo disquete, mientras que usted necesita varios MiB para un moderno sistema de desarrollo de C ++ (con STL, etc.).

Cuando busca micros de gama alta (de gama alta de 16 bits, y en su mayoría de 32 bits, con 64 bits bastante raros) y DSP en entornos integrados, las restricciones se debilitan y el desarrollo de software puede constituir la mayor parte del esfuerzo de desarrollo, por lo que tiene sentido utilizar las herramientas de desarrollo más productivas, incluidos lenguajes más avanzados con características como Object Lenguajes de programación orientada (OOP) como C ++ y lenguajes más nuevos (Java, Perl, Ruby, Python).

Es posible, en ensamblado y en C, predecir cuánta memoria se está utilizando, de modo que es posible un diseño con espacio limitado, pero las características avanzadas como las plantillas, el manejo de excepciones y el enlace en tiempo de ejecución hacen que sea imposible saber exactamente el Memoria de huella necesaria para un programa estándar de C ++ por adelantado. No sé lo suficiente sobre MISRA C ++ , que es un subconjunto de C ++, para comentarlo.

Los lenguajes basados en máquinas virtuales que ejecutan byte-code (Java, Perl, Python) son menos maduros en la experiencia del desarrollador integrado, y como estos lenguajes están diseñados para aislar al programador del hardware particular, también hace que sea más difícil Sea consciente de las limitaciones y restricciones de dicho sistema de hardware integrado. Esto es un problema menor con los procesadores rápidos de 32 bits (por ejemplo, ARMv7) con MiB, si no GiB de RAM.

Todas las implementaciones de BASIC que conozco son bastante simplistas en cuanto a las características del lenguaje, y siguen siendo en gran parte fieles al legado de Dartmouth BASIC de los años sesenta. Esto significa que el lenguaje no tiene bibliotecas complejas en tiempo de ejecución ni manejo de excepciones, y un intérprete o compilador es bastante simple de escribir y también es pequeño en tamaño de archivo. La mayoría de los microcontroladores tienen al menos un compilador BASIC disponible para él.

Espero que describa a grandes rasgos las razones por las que encontrará que C y el ensamblaje se utilizan principalmente en sistemas integrados más pequeños o más antiguos, y con las limitaciones de los sistemas incorporados de gama media a alta más nuevos, difieren solo ligeramente de una computadora personal de escritorio tradicional .

La mayoría de las respuestas ya expresaron las razones históricas (bien conocidas, todos lo usan, no sería fácil cambiar los hábitos, etc.). Aunque estoy de acuerdo con ellos, debemos tener en cuenta que existe otra razón importante.

Es no que "C es una opción mala o obsoleta, pero todavía lo usamos por costumbre" (como los teclados QWERTY).

C es en sí misma una muy buena opción para el desarrollo integrado, especialmente en aplicaciones de tiempo crítico. ¿Por qué?

• es lo suficientemente bajo como para ser utilizado fácilmente para implementar programas en tiempo real. Si necesita medir el tiempo en nanosegundos, tiene que detectar una interrupción cada 5 microsegundos, o tiene que usar exactamente 64 bytes de RAM total, entonces, con un lenguaje de muy alto nivel, lo más probable es que sea Imposible o muy difícil de resolverlo. C le da mucho mejor control sobre el hardware que los lenguajes de nivel superior, esta es una de las diferencias más importantes entre el desarrollo para incrustado y PC.

• es lo suficientemente alto como para ser rápido y fácil de codificar, en comparación con Assembly.

Por lo tanto, C es el mejor compromiso (o uno de los mejores) entre la velocidad y el acceso directo al hardware de Assembly, y la fácil lectura y comprensión de los idiomas de alto nivel.

Es exactamente el mismo motivo por el que en la programación normal los (más usados) lenguajes no cambian (realmente):

1. Gran cantidad de código existente (bibliotecas / implementaciones existentes)
2. Gran conjunto de herramientas que puede funcionar con estos idiomas (IDE, simuladores, ...)

En el mundo integrado, puede ser mucho más difícil (o imposible) proporcionar actualizaciones de software, por lo que es aún más crítico garantizar la corrección. Lamentablemente, C proporciona muy poca ayuda a este respecto y permite que el programador juegue rápido y suelto.

Me duele el uso de C para sistemas integrados, y me gustaría poder al menos moverme a C ++ por los muchos beneficios que brinda en forma de restricciones como const, referencias, tipificación de stringer, etc.

Supongo que la respuesta es simplemente que estamos atascados con C porque el cambio no es comercialmente viable. Todo el mundo sabe C, hay muchos compiladores, bibliotecas y herramientas para generarlo. Con un nuevo idioma, estaríamos empezando desde cero.

Supongo que es por eso que la gente todavía usa PHP .

¿Nadie ha oído hablar de SPARK Ada?

Esta es una versión "pequeña" del lenguaje Ada y herramientas de desarrollo relacionadas para sistemas integrados, por ejemplo, Aviónica y otras aplicaciones críticas para la seguridad, como equipos médicos.

Los estudios han demostrado solo una pérdida del 5-10% en la velocidad de procesamiento en comparación con C / C ++ con la codificación SPARK más confiable.

Creo que la proliferación de C en sistemas integrados se debe a razones económicas:

• Ya está ahí y generalmente es viable para la mayoría de las aplicaciones, y la mayoría de las aplicaciones en función del volumen no son críticas, nadie morirá si la lavadora se desborda, ¿por qué cambiar?

• El conjunto de herramientas SPARK será un gasto adicional en sí mismo y para que el personal capacitado lo use.

• Los beneficios adicionales de SPARK (u otros lenguajes que no sean C) para el controlador / sistema integrado de administración pueden no ser suficientes para justificar la prima necesaria en el precio del producto a los ojos del consumidor, especialmente cuando aparentemente ven "buenas" marcas rivales que se venden a un precio más bajo.

• La compañía AdaCore tiene cuidado de no profundizar demasiado en las aplicaciones del mercado masivo, ya que éstas inevitablemente exigirán un gran aumento en el personal de soporte técnico para tratar los problemas no esenciales. AdaCore es una compañía experta de alto nivel, se enorgullece de ser así y presenta sus productos y servicios a compañías de alta tecnología. Es inusual que un idioma penetre en nuevos mercados a menos que sus principales partes interesadas realmente quieran hacerlo.

Entonces, @ Wouter, ¡no debes preocuparte por morir en los cielos por falta de código incrustado de Ada!

Ya lleva muchos años en los sistemas del avión. Igualmente para su marcapasos.

Pero para el lavaplatos, el sistema de control de los servicios del edificio, el controlador del horno de laboratorio y otras áreas no tan estrictamente reguladas, ¿vale la pena económicamente hacer un esfuerzo adicional?

Supongo que la razón principal de la popularidad de C es que primero: C es popular y mucha gente lo sabe, y segundo: ninguno de los nuevos lenguajes populares como Java, C # e incluso muchos aspectos de C ++ son adecuados para el trabajo integrado. Básicamente, los otros 3 lenguajes que mencioné dependen mucho de la memoria dinámica, lo que trae consigo la ejecución no determinista del programa, los objetos, lo que trae consigo la memoria dinámica, grandes requisitos de memoria (ya que uno de los aspectos más importantes de OO es el uso de mayor número de clases), la creciente popularidad de la compilación justo a tiempo (y muchas plataformas integradas ni siquiera pueden compilar su propio código C) ...

También existe el hecho de que muchas de las bibliotecas que se envían con, por ejemplo, Java o C # son inútiles para una gran cantidad de proyectos integrados.

Por otro lado, tenemos lenguajes más antiguos como Pascal o Basic. Desde mi punto de vista, no son tan populares porque C se convirtió en el lenguaje "estándar de la industria" y un gran número de programadores e ingenieros aprenden C hoy. En algunas escuelas ni a Pascal ni a Basic ni siquiera se aprenden. También está el hecho de que muchos lenguajes populares de hoy en día tienen una sintaxis similar a la de C y el uso de Pascal sería extraño para un programador de C.

En cuanto a FORTRAN, bueno, creo que entró en un campo de nicho y es utilizado principalmente por ingenieros y científicos que trabajan en áreas donde hay un ecosistema adecuado para su uso. No veo ninguna razón en particular (aparte de las que mencioné para Pascal y Basic) que no se usa en sistemas integrados.

Tenga en cuenta que en esta respuesta me centré principalmente en sistemas más pequeños. También hay muchos dispositivos integrados que utilizan sistemas operativos más complejos como GNU / Linux o algún otro derivado de Unix y para su programación, se puede usar más o menos cualquier lenguaje popular.

C es un lenguaje muy simple, y se ha mencionado en más de una ocasión como lenguaje ensamblador de lujo . Es casi la cantidad mínima de abstracción que puede proporcionar sobre el código de ensamblaje, ya que las construcciones en C se asignan directamente a las construcciones a nivel de máquina.

Por esta y muchas otras razones, es muy fácil implementar un compilador de C en un nuevo chip. Gran parte del trabajo ya está hecho, hay relativamente poca complejidad o cosas que pueden salir mal, y el control de bajo nivel le permite manejar con bastante facilidad cualquier peculiaridad que tenga su hardware.

C ++ puede implementarse (en realidad originalmente) como una capa de traducción de código fuente en la parte superior de C, lo que significa que obtienes C ++ (o al menos alguna versión) gratuitamente con tu compilador de C

Con C y C ++, usted es un bootstrap prácticamente todo lo que necesita para su nuevo chip, lo que lo convierte en el lugar lógico para comenzar.

Algunas razones por las que otros no han mencionado:

• Espacio de problemas: C es adecuado para sistemas pequeños y simples. Si todo lo que hace es reaccionar a las señales externas y presionar algunos números, entonces C funciona bastante bien (no hay estructuras de datos complejas, ni malloc, ni manejo de errores complejos).

• Volumen de producción: si tiene grandes ejecuciones de producción, es económicamente razonable ahorrar en cada unidad de hardware y gastar más en programadores, porque la programación es un costo de una sola vez.

Creo que esto se debe a que C / C ++ son los lenguajes de más alto nivel y nivel más bajo.

De hecho, para sistemas embebidos pequeños, C es mucho más popular que C ++. Y la razón es la misma que para no usar otros idiomas. C ++ requiere un tiempo de ejecución, a menos que ceda la mayoría de las características que lo hacen diferente de C.

Aparte del ensamblaje, C es el único idioma que conozco que se compila en el código nativo y para el que tener un tiempo de ejecución es opcional. Por lo tanto, se garantiza que será la huella más pequeña y el tiempo de ejecución más rápido en un entorno restringido (excepto si usa ensamblaje).

Por otro lado, en los sistemas incrustados medianos y grandes (me refiero a más memoria y reloj, mayor tamaño de palabra) No diría que C (o C ++) es tan frecuente. He visto sistemas que soportan Python, Forth ... incluso Java.

Pero, por supuesto, casi siempre tiene la opción de usar C / C ++, obviamente, por las mismas razones que mencioné anteriormente. Y teniendo la opción, y siendo usted alguien que ya se siente cómodo con C para aplicaciones de pequeño tamaño, ¿por qué elegiría otro idioma?