¿Por qué está incrustado estrictamente C / C ++ [cerrado]

15

No me gustó esta pregunta, ya que no se puede responder fácilmente, pero quizás pueda reformular: "¿Qué impide que Embedded cambie de idioma?"

Por ejemplo, casi vemos C / C ++ para embebido (creo que también he oído mencionar ADA antes? Corrígeme si estoy equivocado)

Pero, ¿qué impide exactamente que el mundo integrado cambie de idioma? ¿Es solo que C es demasiado fácil de usar o simplemente no hay realmente una "necesidad" de cambio ya que C hace todo bien?

Esto siempre me ha desconcertado, no es que me esté quejando. Dado que mantenerlo en unos pocos idiomas mantiene las cosas estandarizadas. Pero aún queda la pregunta.

Me doy cuenta de que esta es una especie de pregunta subjetiva, sin embargo, mi pregunta principal es "Por qué" y no "SI / CUÁNDO"


fuente
2
¿Existe un lenguaje particular de nivel superior que le gustaría ver en los sistemas integrados? EDITAR: o más bien, ¿qué características del lenguaje le interesan que C no proporciona?
Jon L
1
@JonL: hay un montón de características de bajo nivel que desearía que C tuviera. Por ejemplo, mejor manipulación de bit / mordisco / byte / palabra dentro de ints grandes. Mejor soporte de seguridad, por ejemplo, los tipos de características que tiene Ada.
Rocketmagnet
3
Embebido no es estrictamente C. Aquí hay un montón de lenguajes de alto nivel para sistemas embebidos: electronics.stackexchange.com/questions/3423/…
Kellenjb
1
"Embebido" tiene diferentes significados. Un microcontrolador de 4 bits que ejecuta una tostadora es diferente a una ECU o decodificador. Este espectro hace que su pregunta sea difícil de responder.
Toby Jaffey
1
Y, como se esperaba, esto se ha cerrado. Esta pregunta que esperaba recibiría respuestas de alta calidad y la gente trabajaría para mantenerla como una gran pregunta, este no es el caso. En cambio, estamos recibiendo muchas respuestas que son una oración que recibe múltiples votos a favor, tenemos una respuesta en prosa que tiene una guerra de votos negativos con banderas en abundancia, y las otras respuestas generaron más banderas en 1 día y luego el resto del sitio combinado . El problema es que para muchas personas hay muchas respuestas correctas diferentes sobre por qué no han cambiado.
Kortuk

Respuestas:

18

En primer lugar: olvidarse de "incrustado", ya que no es una distinción útil. La propiedad más importante es "limitada por recursos". 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 potencia.

  • La adopción de un nuevo lenguaje es difícil y raro. Requiere una nueva capacitación, nuevas herramientas y encontrar una buena manera de trabajar con el nuevo idioma. Esto es costoso, especialmente para los primeros usuarios. También es un problema de gallina y huevo: sin una gran base de usuarios no habrá herramientas y bibliotecas de buena calidad, pero sin ellas 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 la brecha entre la potencia de CPU disponible y lo que el usuario necesita. En otras palabras: pueden ser ineficientes en velocidad, pero compensan siendo más fáciles para el programador. Piense en el surgimiento de lenguajes como Java, Python, Perl, Tcl que esencialmente son ejecutados por un intérprete (tal vez después de una compilación) y hacen un uso intensivo de la administración de memoria dinámica. Pero esto no coincide bien con el mundo con recursos limitados, donde queremos obtener a) la mayor parte 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 como para contar con buenas herramientas, suficientes programadores capacitados y amplias bibliotecas) que pueden cumplir con los requisitos predecibles de espacio y tiempo que no están muy lejos de lo que es posible en el hardware actual. El único contendiente es, creo, Ada, pero ha sufrido un mal comienzo: las primeras implementaciones fueron (¿percibidas como?) Demasiado lentas e ineficientes, y ahora (a pesar de que hay buenas implementaciones disponibles) el lenguaje se ha retrasado un poco en características (en comparación con C ++). Personalmente, creo que es una lástima, en igualdad de condiciones, prefiero volar en un avión programado en Ada que uno que se haya hecho en C o C ++.

Wouter van Ooijen
fuente
+1 - buena respuesta. Ada parece un lenguaje interesante, ¿hay algún compilador de Ada para micros pequeños?
Oli Glaser
Existe GNAT, el compilador GCC Ada. Pero AFAIK no se ha utilizado mucho en micros, por lo que tendrá dificultades para encontrar algo que se pueda leer para ejecutar.
Wouter van Ooijen
Sí, vi a GNAT mencionado en la página Wiki. Tienes razón, no hay mucho para micros pequeños, pero parece que hay un poco de apoyo (como es de esperar) para cosas de misión crítica en 68k, x86, MIPS, etc. (por ejemplo, DDCI )
Oli Glaser
Veo que también hay SPARK Ada, como lo menciona Deek a continuación. Voy a tener que comprobar que funciona cuando tengo algo de esa materia difícil de alcanzar que llaman tiempo ...
Oli Glaser
2
Ada, en forma de mosquito, funciona bien en el microprocesador AVR, como se ve en Arduino. El ejecutable de Gnat más pequeño que he construido fue de 65 bytes. Es cierto que todo lo que hizo fue parpadear un LED, aunque el boceto Arduino equivalente fue superior a 1K. Cuando mi ejecutable alcanzó los 600 bytes, estaba manejando 2 motores paso a paso de forma independiente ... No necesita SPARK, ¡a menos que quiera probar que su intermitente LED es formalmente correcto!
Brian Drummond
9

Con sistemas embebidos basados ​​en microcontroladores de 8 y 16 bits, todo se reduce a que es más fácil desarrollar un software que se adapte a los recursos limitados de estas limitaciones de almacenamiento muy modestas (quizás unos 100 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 ensamblado 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 necesita varios MiB para un sistema de desarrollo C ++ moderno (con STL, etc.).

Cuando está buscando micros de gama alta (16 bits de alta gama, 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 desarrollo esfuerzo, por lo que tiene sentido utilizar las herramientas de desarrollo más productivas, incluidos los lenguajes más avanzados con características como lenguajes de programación orientada a objetos (OOP) como C ++ y lenguajes más nuevos (Java, Perl, Ruby, Python).

Es posible en el ensamblaje y en C predecir cuánta memoria se está utilizando, de modo que un diseño con espacio limitado es factible, pero las características avanzadas como plantillas, manejo de excepciones y enlace de tiempo de ejecución hacen que sea imposible saber exactamente la huella de memoria 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 código de bytes (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 en particular, también hace que sea más difícil ser consciente de limitaciones y restricciones de dicho sistema de hardware integrado. Este 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 las características del lenguaje, y se mantienen en gran medida fieles al legado de Dartmouth BASIC de la década de 1960. Esto significa que el lenguaje no tiene bibliotecas de tiempo de ejecución complejas o manejo de excepciones, y un intérprete o compilador es bastante simple de escribir y también tiene un tamaño de archivo pequeño. La mayoría de los microcontroladores tienen al menos un compilador BASIC disponible para ello.

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

mctylr
fuente
5

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

Es no que "C es una mala elección o anticuado pero todavía lo utilizan por costumbre" (como los teclados QWERTY).

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

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

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

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

vsz
fuente
1
Creo que un aspecto importante a favor de C es que le permite a uno optimizar el código para una plataforma en particular mientras permite que dicho código se ejecute (tal vez no tan eficientemente) en otros. En algo como un PIC, muchas instrucciones de C se traducirán previsiblemente en instrucciones de máquina; un bucle como unsigned char i=63,j=128; do {something;} while(--j); while(--i);no será tan legible como unsigned int i=16000; do {something;} while(--i);, pero se ejecutará más rápido y será más eficiente en el PIC. Si el código se moviera al ARM, el segundo enfoque sería más eficiente, pero el primero aún funcionaría.
supercat
4

Es exactamente la misma razón por la cual en la programación regular los lenguajes (más utilizados) no cambian (realmente):

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

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 usar C para sistemas embebidos, y desearía poder al menos subir a C ++ por los muchos beneficios que proporciona en forma de restricciones como const, referencias, escritura de stringer, etc.

Supongo que la respuesta es simplemente que estamos atrapados con C porque cambiar no es comercialmente viable. Todos conocen C, hay muchos compiladores, bibliotecas y herramientas para generarlo. Con un nuevo lenguaje, estaríamos comenzando desde cero.

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

PHP martillo doble.

Rocketmagnet
fuente
Si desea analizar la pregunta, utilice comentarios o metadatos, si desea darle una palmadita al usuario en la parte posterior para obtener una buena pregunta, vote o comente.
Kortuk
Siempre puede usar Pascal; parece tener las limitaciones adicionales que está buscando :-). O alguna forma de Super-Lint.
Russell McMahon
2
Una razón muy importante para C es que es MUCHO más fácil escribir un compilador de C básico que un compilador de C ++. Trabajé en uno por un tiempo antes de que tareas más importantes me alejaran. ¡Cosas divertidas! ¿Escribir un compilador de C ++? Ugh Sin embargo, prefiero C ++ como usuario.
darron
1
@RussellMcMahon - No puedo usar Pascal, porque no hay un compilador Pascal para las MCU que estoy usando.
Rocketmagnet
@darron - Ese es un muy buen punto. Sin embargo, hay muy buenos compiladores de C ++ de código abierto, como gpp. Solo tendrían que escribir un back-end para ello.
Rocketmagnet
4

¿Nadie ha oído hablar de SPARK Ada?

Esta es una versión "pequeña" del lenguaje Ada y las 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 los sistemas integrados se debe a razones económicas:

  • Ya está allí y, por lo general, funciona para la mayoría de las aplicaciones, y la mayoría de las aplicaciones en volumen no son críticas, nadie morirá si la lavadora se desborda, entonces, ¿por qué cambiar?

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

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

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

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

Ya está en los sistemas de aviones durante muchos años. Del mismo modo para su marcapasos.

Pero para el lavavajillas, el sistema de control de servicios de construcción, el controlador del horno de laboratorio y otras arenas no tan estrictamente reguladas, ¿vale la pena económicamente hacer un esfuerzo adicional?

Deek
fuente
Interesante, gracias. No había oído hablar de SPARK, lo comprobaré.
Oli Glaser
Algunos estudios muestran una aceleración relativa a una aplicación existente en C - mira el servidor DNS "Ironsides" ...
Brian Drummond
3

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, que trae consigo la ejecución no determinista del programa, los objetos, que traen memoria dinámica, los requisitos de memoria grandes (ya que uno de los lados 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 está el hecho de que muchas de las bibliotecas que se envían con Java o C # son inútiles para una gran cantidad de proyectos integrados.

Por otro lado, tenemos idiomas 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 una gran cantidad de programadores e ingenieros aprenden C hoy. En algunas escuelas, Pascal o Basic ni siquiera se aprenden. También está el hecho de que muchos lenguajes populares hoy en día tienen una sintaxis similar a la de C y usar Pascal sería extraño para un programador de C.

En cuanto a FORTRAN, bueno, supongo 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) no se usa en sistemas integrados.

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

AndrejaKo
fuente
1
C es popular porque C es popular? :-)
stevenvh
2
@stevenvh Sí, eso es cierto. Es una especie de retroalimentación positiva. Cuanto más popular es, más popular se vuelve.
AndrejaKo
3

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

Por esta y 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 ++ se puede implementar (en realidad originalmente) como una capa de traducción de código fuente encima de C, lo que significa que obtienes C ++ (o al menos alguna versión de él) de forma gratuita con tu compilador de C.

Con C y C ++, usted es un programa de arranque prácticamente todo lo que necesita para su nuevo chip, por lo que es el lugar lógico para comenzar.

tylerl
fuente
3

Algunas razones que los otros no han mencionado:

  • Espacio problemático: 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 (sin estructuras de datos complejas, sin malloc, sin manejo complejo de errores).

  • Volumen de producción: si tiene grandes series 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 único.

starblue
fuente
2

Creo que es porque C / C ++ son los lenguajes de nivel más bajo y alto.

Amit Tomar
fuente
1

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

Además del ensamblado, C es el único lenguaje que sé que compila en código nativo y para el cual 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 el ensamblaje).

Por otro lado, en sistemas embebidos medianos y grandes (con los cuales quiero decir más memoria y reloj, mayor tamaño de palabra) no diría que C (o C ++) es tan frecuente. He visto sistemas que admiten 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 pequeños, ¿por qué elegiría otro idioma?

fceconel
fuente
44
C ++ puede generar muchos gastos generales, pero el compilador de C ++ totalmente compatible que utilicé para MSP430 no requirió tiempo de ejecución, C ++ sí compiló en código nativo. Lo siento, decirle a los demás es un mal servicio y te he rechazado. Puede eliminar el voto negativo proporcionando referencias que me convenzan de que soy incorrecto (lo cual será difícil, he leído la lista de ensamblaje de C ++ compilado para mis proyectos, parte de asegurarme de que se compila de manera eficiente) o puede eliminar su respuesta, lo que eliminará el efecto en tu reputación (aunque en este punto recibes +8 repeticiones netas)
Kortuk
3
Estoy totalmente de acuerdo con Kortuk. Algunas partes de C ++ requieren un amplio soporte de tiempo de ejecución, pero la parte que no lo hace sigue siendo una C mucho mejor (y completamente OO). La restricción a este subconjunto es forzada fácilmente por algunos compiladores y modificadores de enlace. En algunas partes (el temido printf, por ejemplo), C ++ tiene al menos el potencial de lenguaje para requerir mucho menos tiempo de ejecución (si solo std :: cout se implementara con pequeños sistemas en mente ...)
Wouter van Ooijen
1
@Kortuk, perdón por no ser claro allí, pero cuando dije que "C es el único lenguaje que ..." no significaba que C ++ no tuviera ambas cosas, quise decir que C tiene la combinación de los dos y C ++ tiene uno de ellos. Mi énfasis estaba en la parte de tiempo de ejecución. Tampoco digo que sea completamente imposible usar C ++ sin un tiempo de ejecución, pero es bastante inusual. No puedo ver cómo puede tener cosas como el manejo de excepciones y RTTI sin un tiempo de ejecución, por ejemplo, y esas son características bastante importantes. Pero me disculpo si la forma en que expresé esto condujo a posibles conceptos erróneos.
fceconel
@fceconel, nunca he usado C ++ con un entorno de tiempo de ejecución, y estamos discutiendo los sistemas integrados aquí, nunca he usado un tiempo de ejecución en mis microcontroladores. Esta pregunta es un poco diferente de lo que puede haber leído, se pregunta por qué C / C ++ son las únicas opciones frecuentes, no por qué C en lugar de C ++. Debo admitir que usar algo tan simple como cout nunca sucederá en mi micro, tengo algunos pines libres, no una pantalla.
Kortuk