Me interesan los lenguajes de programación adecuados para la programación integrada. En particular:Utilice la herramienta adecuada para el trabajo: programación integrada
¿Es posible programar sistemas integrados en C++? ¿O es mejor usar C puro? O, ¿C++ está OK solo si se excluyen algunas funciones del lenguaje (por ejemplo, RTTI, excepciones y plantillas)?
¿Qué hay de Java en este dominio?
Gracias.
¿Es posible programar los sistemas integrados en C++?
Sí, por supuesto, incluso en sistemas de 8 bits. C++ solo tiene unos requisitos de inicialización de tiempo de ejecución ligeramente diferentes que C, que es que antes de que se invoquen constructores main() para cualquier objeto estático se debe invocar. La sobrecarga (sin incluir los propios constructores que está bajo su control) es muy pequeña, aunque debe tener cuidado ya que el orden de construcción no está definido.
Con C++ solo pagas por lo que usas (y muchas cosas útiles pueden ser gratuitas). Es decir, por ejemplo, una parte del código C que también es compilable en C++ generalmente no requerirá más memoria y no se ejecutará más lentamente cuando se compile como C++ que cuando se compiló como C. Hay algunos elementos de C++ que puede necesitar para tener cuidado con, pero muchas de las características más útiles tienen un costo bajo o nulo y un gran beneficio.
¿O es mejor usar pure C?
Posiblemente, en algunos casos. Algunos objetivos más pequeños de 8 e incluso 16 bits no tienen compilador de C++ (o al menos no tienen ninguna reputación), el uso de código C le dará una mayor portabilidad en caso de que sea un problema. Además, en objetivos severamente restringidos en recursos con aplicaciones pequeñas, los beneficios que C++ puede aportar a C son mínimos. Las características adicionales en C++ (principalmente aquellas que permiten OOP) lo hacen adecuado para la construcción de software relativamente grande y complejo.
O es C++ Aceptar sólo si algunos características del lenguaje (por ejemplo, RTTI excepciones y plantillas) están excluidos ?
Las características del lenguaje que pueden ser aceptables dependen completamente del objetivo y la aplicación. Si tiene limitaciones de memoria, puede evitar las características o bibliotecas costosas, e incluso entonces puede depender de si el código o el espacio de datos le falta (en los destinos donde están separados). Si la aplicación es hard real-time, evitará esas características y clases de biblioteca que no son deterministas.
En general, sugiero que si su objetivo será de 32 bits, siempre use C++ en lugar de C, luego corte su C++ para adaptarlo a las limitaciones de memoria y rendimiento. Para partes más pequeñas, sea un poco más circunspecto al elegir C++, aunque no lo descarte por completo; puede hacer la vida más fácil.
Si opta por utilizar C++, asegúrese de tener hardware/software depurador decente que sea consciente de C++. La relativa facilidad con la que se puede construir un software complejo en C++, hace que un depurador decente sea aún más valioso. No todas las herramientas en la arena incrustada son compatibles con C++ o son capaces.
Siempre recomiendo a cavar en los archivos en Embedded.com sobre cualquier tema incorporado, se tiene una gran cantidad de artículos, incluyendo un número de sólo esta cuestión, entre ellas:
En cuanto a Java, no soy un experto, pero tiene importantes necesidades de tiempo de ejecución que lo hacen inadecuado para los sistemas de recursos limitados. Probablemente se limitará a hardware relativamente caro utilizando Java. Su principal beneficio es la independencia de la plataforma, pero esa portabilidad no se extiende a plataformas que no pueden admitir Java (de las cuales hay muchas), por lo que es posiblemente menos portátil que una implementación C o C++ bien diseñada con una interfaz de hardware abstraída.
[editar] Concidentally Acabo de recibir esto en el boletín TechOnLine: Using C++ Efficiently in Embedded Applications
En la mayoría de los casos, en los sistemas integrados, el lenguaje en el que está programando está determinado por el compilador que realmente está disponible.
Si su hardware solo tiene un compilador C, eso es lo que va a utilizar. SI tiene un compilador C++ decente, realmente no hay ninguna razón para preferir C sobre C++.
Me atrevo a decir que Java no es una opción muy popular en los sistemas integrados.
Si su HW solo tiene un compilador de C, Comeau puede proporcionarle un compilador de C++ a C. Y hay otros lenguajes que se pueden compilar en C, precisamente por esta razón. – MSalters
Tengo un compilador de C++ disponible y aún uso C. Que "realmente no hay ninguna razón para preferir C sobre C++" es una afirmación bastante fuerte. C++ puede comer implícitamente a través de la memoria en un sistema restringido si no tiene mucho cuidado. Además, Java es una opción extremadamente popular para muchos sistemas integrados (por ejemplo, teléfonos móviles). –
@Judge Maygarden: C++ no "come" memoria mágicamente, solo pagas por lo que usas, incluso compila C, ya que es probable que C++ se beneficie de una verificación de tipo más sólida sin costo en tiempo de ejecución. En cuanto a Java, habrá consumido una gran cantidad de recursos en soporte de tiempo de ejecución incluso antes de haber escrito una sola línea de código, pero no plantea la misma objeción a eso. – Clifford
Tanto C como C++ se pueden usar en sistemas integrados. Si limita las funciones de C++ que utiliza, entonces usará aproximadamente la misma velocidad y espacio que C. En cuanto al uso de estas características adicionales, realmente depende de sus limitaciones. Por ejemplo, si está haciendo un sistema en tiempo real, las excepciones pueden no ser una buena idea, simplemente porque teniendo en cuenta el tiempo de propagación de las excepciones y todas las rutas a través de las cuales las excepciones pueden propagarse, las garantías duras en tiempo real pueden ser difíciles (aunque, una vez más, la implementación CORBA en tiempo real de ACE/Tao usa excepciones). Si bien las plantillas y RTTI pueden conducir a programas más grandes, existe una gran variabilidad en los sistemas integrados, por lo que, dependiendo de las limitaciones de recursos, esto podría ser perfectamente correcto o inaceptable. Lo mismo vale para Java. Java (bueno, técnicamente, el lenguaje de programación Java con un subconjunto de la API de Java) se ejecuta en Android, por ejemplo, utilizando la VM Dalvik. J2ME se ejecuta en una variedad de dispositivos integrados. Si funcionará o no para su aplicación, depende de sus limitaciones particulares.
c es el lenguaje más común utilizado en los sistemas integrados.
Sin embargo, creo que el futuro de C++ reside en el dominio del sistema integrado. Creo que los estándares C++ 0x ayudarán en ese repectivo. Entonces no me sorprendería ver que C++ usó mucho más en este campo.
Por lo que puedo decir, C++ 0x realmente no parece resolver gran parte del clunkiness de C++ ... se siente como una solución incremental de unas pocas cosas. –
La programación integrada en estos días abarca una amplia gama de aplicaciones.
Aproximadamente, va desde sensores/conmutadores hasta sistemas de seguridad completos.
Debe basar su lenguaje en la complejidad y los recursos de hardware.
Es 1 de las opciones junto a HW (CPU, ...), sistema operativo, protocolos, ...
posibles opciones:
que realmente se reduce a lo que la plataforma de hardware que está ope valoración y, por lo tanto, qué plataformas de software están abiertas para usted. Para una gran cantidad de kits integrados recientes, diseñados alrededor de un sistema en chip, un megabyte o dos de RAM, algunos dispositivos, realmente desea un sistema operativo pequeño para administrar el hardware de bajo nivel mientras se concentra en su aplicación.Su elección de sistema operativo entonces limita su conjunto de idiomas disponibles.
Ciertamente es posible usar C++ en el espacio incrustado, pero el conjunto completo de características del lenguaje requiere mucho trabajo para portarlo correctamente. Por ejemplo, eCos se implementa en una mezcla de C y lo que podríamos llamar los aspectos estructurales de C++; soporte para RTTI, las excepciones y el STL faltan en la versión gratuita, aunque hay personas trabajando en esto (y un puerto comercial disponible).
De forma similar, es posible usar Java: lo sé, he portado una JVM a un entorno incrustado; no fue divertido, aunque generalmente se obtiene una configuración reducida del lenguaje Java, a menudo algo basado en J2ME.
O es C++ Aceptar sólo si algunas de las características de la lengua (por ejemplo RTTI, excepciones y plantillas) están excluidos?
Es bueno pensar en esta línea. La complejidad del tiempo de compilación no es un gran problema, pero la complejidad del tiempo de ejecución tiene un costo de recursos.
C++ facilita clase/modularidad espacio de nombres (por ejemplo método foo() en más de un contexto) y la modularidad instancia (campo miembro bar pertenecientes a más de un objeto), ambos de los cuales son una gran ventaja en el diseño de software. También hay funciones como const, referencias, moldes estáticos y plantillas, que pueden ayudar a imponer restricciones y tienen poco o ningún costo de tiempo de ejecución.
Me no excluir plantillas. Son complejos de considerar y necesitas un compilador que los maneje bien, pero el costo del recurso es casi todo el tiempo de compilación. Lo que te va a "costar" es el hecho de que cada vez que utilizas una plantilla con diferentes parámetros de clase, usted produce un nuevo conjunto de códigos para crear instancias de funciones miembro. Pero casi seguramente tendrías que hacer lo mismo sin plantillas. Además, las plantillas le permiten diseñar y probar bibliotecas para circunstancias generales, en archivos separados que se instancian en tiempo de compilación en lugar de tiempo de enlace. Solo para aclarar eso: las plantillas te permiten tener un archivo A.h que pruebes. Luego lo usa con el archivo B.ho B.c para crear una instancia en tiempo de compilación. (Una biblioteca estaría vinculada en lugar de compilada, y esto lo hace menos flexible: los métodos de plantilla pueden optimizarse para que no incurran en una llamada a función). He usado plantillas en sistemas integrados para implementar código CRC y señalar matemática: puedo probar el código general, ponerlo en control de versión y luego reutilizarlo varias veces escribiendo una clase simple que se deriva de una plantilla o tiene un campo de miembro de plantilla. El ejemplo clásico del curso es STL.
RTTI y excepciones: agregan complejidad de tiempo de ejecución.No tengo una buena idea del costo de los recursos, pero espero que RTTI sea bastante simple (solo agrega una etiqueta de tipo, lo que cuesta más espacio), mientras que las excepciones son probablemente bestiales e implican el desenrollado de la pila.
funciones virtuales: Yo solía descartar esto debido a los costos de ejecución de la memoria + + (mínimo pero todavía existe), así como la complejidad de la depuración, pero que permiten desacoplar objetos entre sí. Si no usa funciones virtuales, cuando una instancia de una clase (por ejemplo, Foo) necesita ejecutar código asociado con una instancia de otra clase (por ejemplo, Bar), entonces la primera clase necesita saber todo sobre la segunda (para compilar Foo) necesita tener un enlace estático a todos los métodos en Bar) - esto agrega mucho acoplamiento apretado.
Asignación de memoria dinámica: esta es otra gran cosa (también en C), que evitamos como la peste en mi compañía - no solo hay todo tipo de errores que pueden surgir, sino que los grandes el costo del tiempo de ejecución es el asignador/desasignador, y debe estar dispuesto y capacitado para saber cuál es ese costo y aceptarlo.
edición: Me amor utilizar Java en lugar de C++ en el mundo incrustado. Desafortunadamente, mis opciones son limitadas y los costos de recursos de tiempo de ejecución (tamaño de código, tamaño de memoria, restricciones de tiempo de recolección de basura) son demasiado altos en el espacio en el que trabajo. Mi razón para usar Java es menor debido a sus recursos de tiempo de ejecución y más para el hecho de que su diseño de software es mucho más limpio, y las herramientas son mucho mejores (OMG! refactoring! woohoo!) ... la clave para mí parece residir en dos cosas, que hacen que C/C++ se sienta muy torpe en comparación:
que todo es un objeto y todos los métodos son virtuales, por lo que puede apoyarse mucho en las abstracciones de las interfaces.
la separación de interfaz/implementación en Java no es tan desagradable .c/.h división de archivos cosa que hace que los compiladores sean tan lentos. En contraste, uso Java en Eclipse y compila automáticamente el código a medida que lo edito. ¡Esto es enorme! Encuentro la mayoría de mis errores de inmediato. En C/C++ tengo que esperar todo un ciclo de compilación.
Algún día espero que habrá un lenguaje entre C/C++ y Java que proporciona las ventajas de Java para el desarrollo de software, sin necesidad de las campanas y silbatos que hacen de Java tan atractivo para aplicaciones de escritorio/servidor, pero poco atractivo en la mayor parte del mundo integrado.
Creo que ya tiene una gran respuesta de Clifford, pero le agregaré mi experiencia. Como se señaló, el tipo de sistema integrado es el principal impulsor. En Defensa/Aeroespacial, C y Ada son los lenguajes incrustados más populares que encuentro. Aunque a medida que pasa el tiempo, estoy viendo más C++ a medida que el desarrollo basado en modelos se vuelve popular con las herramientas como Rhapsody. En la lista de trabajos, ver los requisitos para la experiencia de Diseño Orientado a Objetos también me lleva a creer que el mercado está cambiando lentamente para seguir las tendencias del desarrollo convencional.
Si está realmente interesado en el desarrollo integrado, comenzaría con C. Es bastante universal. Casi todos los sistemas operativos, incluidos los sistemas operativos en tiempo real como Integrity, Nucleus, VxWorks y Linux incorporado, tienen un compilador y herramientas para ello. Las cosas que aprenderá sobre punteros, administración de memoria, etc ... se traducirán en desarrollo de C++ en el mundo integrado al menos.
En cuanto a Java, si está interesado en el desarrollo de plataformas móviles como teléfonos inteligentes, esta es una opción sólida (me viene a la mente Android). Pero en el mundo de los sistemas operativos en tiempo real, no lo he visto.
En ese sentido, eso me lleva a mi último punto y consejo. Si quisiera incursionar en la programación integrada (lo cual hice hace 4 años), me enfocaría en aprender C desde un punto de vista de bajo nivel como se mencionó anteriormente. Entonces, también aprendería lo que hace que la programación en tiempo real sea tan difícil/diferente. El siguiente libro me pareció bastante bueno para enseñarte a pensar como un programador integrado frente a un desarrollador de aplicaciones. ¡Buena suerte!
Gracias por sus puntos y consejos. (FWIW, ya conozco C y C++ desde una perspectiva de desarrollo de aplicaciones). – EmbeddedProg
No sólo usted tiene que elegir el idioma, tiene que elegir las herramientas de desarrollo que mejor soportan la plataforma de destino. Algunas recomendaciones: Metaware, Greenhills y Microsoft Visual Studio (versiones que incluyen MS Closed visual C o C++). Además, es posible que necesite un sistema operativo: ThreadX, Nucleus, VRTX, WindRiver y MS Embedded (Platform Builder). Si su sistema es lo suficientemente grande, es posible que también necesite un sistema de archivos. –