¿Por qué no puedo usar C ++ en sistemas integrados? ¿Hay buenos libros sobre C ++ para sistemas integrados?

Algunas buenas respuestas ya …

Uno de los problemas que enfrentará es el deseo / la necesidad de evitar la asignación dinámica de memoria. Esto restringirá el uso de grandes partes del STL.
Esto es especialmente cierto para sistemas sin administración de memoria.

El otro problema se relaciona con los nombres de funciones destrozadas, aunque los depuradores están mejorando en esto.

Otros problemas son la disponibilidad de componentes de terceros en C ++, aunque esto ha estado mejorando.

Cualquier característica / función heredada que desee incluir probablemente esté escrita en C en su organización.

La mayoría de los sistemas operativos y las llamadas al sistema no son C ++, ni tampoco los controladores del dispositivo. Por lo tanto, se necesita una capa de pegamento.

Es complicado lograr esto sin causar hinchazón real o percibida. (Cuando sus hilos tienen una pila de 4-16K, esto comienza a importar)

Dicho esto, la mayoría de los proyectos embebidos modernos avanzan hacia la adopción de C ++ en cierta medida debido a los beneficios obvios derivados de la abstracción y la herencia. Sin mencionar un mejor soporte de pruebas de unidad.

Este libro antiguo tiene una excelente sección larga sobre el uso de C ++ en una cafetera con un chip de 16 / 8bit temprano, el 80188.

Vale la pena leer eso, ya que el tío Bob lo usa para mostrar la diferencia entre un enfoque procesal y un enfoque OO efectivo. Luego señala que la forma OO se ajusta a los presupuestos de tiempo y espacio.

Muy recomendable.

Amazon.es: Robert C.Martin: 9780132038379: Libros

Entonces podría recomendar el libro de James Grenning sobre el uso de TDD con sistemas integrados, en caso de que te quedes atascado con C después de todo:

Amazon.es: James W.Grenning: 9781934356623: Libros

Sí, puede usar C ++ en sistemas integrados. Cuando la memoria es limitada, es probable que desee deshabilitar excepciones, ya que a menudo no es práctico escribir su código de tal manera que no se genere una gran cantidad de código de objeto de manejo de excepciones nunca utilizado. Si los requisitos de latencia estricta prohíben el uso de la asignación de memoria dinámica, debe evitar las bibliotecas estándar (como los contenedores STL) que dependen de la asignación de memoria dinámica.

La sobrecarga de usar las capacidades orientadas a objetos en C ++ es más o menos comparable en la mayoría de los casos al código que escribiría que no las usara. Y el código que usa estas capacidades cuando son apropiadas generalmente será mucho más fácil de mantener. Intenté describir la sobrecarga involucrada en un par de otras respuestas: la respuesta de Walt Karas a ¿Cómo se implementa realmente la tabla de métodos virtuales en C ++? La respuesta de Walt Karas a ¿Cómo se logra la herencia múltiple en C ++?

boost :: intrusive (Boost C ++ Libraries) proporciona contenedores que son más difíciles de usar, pero no dependen de la asignación de memoria dinámica de propósito general (nuevo, malloc). También he escrito una biblioteca de contenedores intrusivos algo más flexible: wkaras / C-plus-plus-intrusive-container-templates.

También he escrito una alternativa a las estructuras de campo de bits que proporciona el lenguaje base: wkaras / C-plus-plus-library-bit-fields. Está diseñado para facilitar la escritura de código que funciona con campos de bits que es portátil entre procesadores endian grandes y pequeños. También tiene capacidades para ayudar a interactuar con dispositivos que no están mapeados en memoria cuyos mapas de registro están compuestos de campo de bits.

Otro código que podría ser útil en un sistema embebido es esta facilidad para el intercambio de campos integrales en una estructura / clase: wkaras / C-plus-plus-struct-component-wise-endiance-swap.

No sé a qué sistema en particular te refieres, pero, en general, un compilador de C ++ es MUCHO más complejo que un compilador de C y produce un back-end adecuado para un sistema en particular donde las restricciones de tamaño y velocidad nunca permitirán grandes las implementaciones de escalabilidad no pagan el esfuerzo.

Dicho esto, hay un sistema incrustado que permite usar algún subconjunto de C ++ (como el uso de clases, operadores y herencia) que permiten, en cierto nivel, escribir algo que se pueda compilar como C ++ (aunque, de hecho, es un dialecto específico del sistema: un programa o biblioteca C ++ con todas las funciones nunca puede entrar en esos sistemas: en particular, las plantillas están lejos de ser compatibles con la mayoría de los compiladores C ++ integrados).

Por lo que puedo ver, la razón no es técnica, sino económica.

Por una cuestión técnica, si una plataforma me pretende elegir entre una C estándar y una C ++ inferior, iré con la estándar.

Si está utilizando C en los sistemas integrados, ya está utilizando C ++.

C y C ++ tienen un núcleo común, que probablemente es lo que usa en ese contexto de programación. Lo más probable es que no uses las cosas en C que no están disponibles en C ++, porque estarás construyendo algo relativamente simple.

Hay un pequeño costo relacionado con C ++ que tendrá que pagar: el compilador es más complejo y, para sistemas personalizados, solo un compilador C podría estar disponible. Me he encontrado con varios sistemas que tenían su propio compilador, y C es mucho más fácil de implementar que C ++. Pero la mayoría de los sistemas usan hoy en día un compilador público como GNU Compiler Collection, y si eso sucede, entonces C ++ también podría ser una opción posible para su plataforma.

Si tiene un compilador de C ++ para su plataforma, debe usarlo, no hay discusión al respecto. Si tiene un programa simple, no importa, y si tiene un programa más grande, reducirá su costo de desarrollo a largo plazo.

Incluso si no puede usar C ++, aún puede hacer POO, y probablemente debería hacerlo.

Estudie el kernel de Linux por un tiempo y se dará cuenta de que es un programa orientado a objetos, simplemente sin ningún azúcar sintáctico para lo que está sucediendo.

Un ejemplo muy sólido es el sistema operativo integrado eCos, tan profundamente integrado y con la mínima memoria posible. El núcleo está escrito en C ++ con la evitación cuidadosa de plantillas y algunas otras características que hacen imposible comprender el uso de la memoria.

página de wikipedia: eCos – Wikipedia

página de inicio del proyecto: eCos

No digo que C ++ sea mejor para este o cualquier otro uso, pero eCos ciertamente muestra que se puede hacer.

Aunque no estoy tan familiarizado con los sistemas integrados como me gustaría; Tengo algunos enlaces que pueden ayudarte a encontrar lo que estás buscando. ¿C ++ es adecuado para sistemas integrados?
Una guía de C ++ para programadores de C
Gracias y espero que esto ayude!

He usado C ++ para escribir un sistema incrustado. Era una computadora de buceo en la que estaba trabajando. Elegiría C ++ sobre C para absolutamente cualquier proyecto que me arrojes.

Me parece recordar que había una sección de inicio en capas en la biblioteca estándar y que necesitaba un poco de cuidado especial cuando se ejecutaba en la plataforma que elegí. Igual que C tendría, estoy seguro. Si puede encontrar un sistema de compilación C ++ para su objetivo, mucho mejor.

Cualquier libro que pueda encontrar sobre el uso de C para sistemas integrados debería estar bien. C ++ puede hacer cualquier cosa que C pueda hacer. El acceso de bajo nivel será el mismo para C y C ++. C ++ simplemente le permite organizar mejor el software y darle más sugerencias de optimización al compilador.

Como otros ya señalaron, depende del microcontrolador. Por lo general, está vinculado a un compilador específico del dispositivo enviado con el dispositivo. Supongo que generalmente es C sin cierta funcionalidad (por ejemplo, administración de memoria, acceso al sistema de archivos).

Puede usar Síntesis de alto nivel (HLS), es decir, Metodología de diseño C / C ++ para diseño integrado con FPGA. mientras que C / C ++ se usa mucho para la programación de controladores integrados como para el microcontrolador. Puede estudiar el libro de Muhammed Ali Mazidi para la programación de microcontroladores con C / Assembly.

Programación del procesador ARM hay un libro de Steve Furber.

Para el diseño FPGA con síntesis de alto nivel, puede tomar un curso en línea de $ 10 para Udemy. Aquí está el enlace del Código del Cupón del Curso: Diseño FPGA con Herramienta de Síntesis de Alto Nivel (VIVADO HLS)

¡Sí tu puedes!
También puede incluir ensamblaje en línea, instrucciones directas para CPU, en C ++.
Y hay un compilador traducido de C / C ++ a RISC, como GNU toolchain.

La programación del sistema integrado no es muy famosa en la comunidad de programación. En mi universidad, solo los ingenieros informáticos aprenden la programación de sistemas integrados utilizando C y RISC.

También quiero aprender programación de sistemas integrados, pero el curso de informática en mi universidad solo aprendió a administrar la estructura de la computadora para ser más inteligente y resolver problemas mundiales.

Algunas razones son:
– los sistemas integrados a menudo tienen limitaciones de costo o tamaño, y los lenguajes orientados a objetos tienden a tener mucha memoria, lo que aumenta el costo. Además, requerir más memoria requiere más potencia.
– velocidad. Algunos sistemas integrados hacen cosas en tiempo real. C ++ no es particularmente bueno para operaciones cronometradas con precisión a nivel de máquina.
– C generalmente requiere menos potencia de CPU que los sistemas engorrosos con muchos objetos.

Solo hay una razón por la que no puede escribir para un procesador incorporado en C ++: la disponibilidad de un compilador. Se garantiza que el compilador de CA se envía con el procesador, un compilador de C ++ puede valer o no el tiempo y el dinero del OEM para la comisión.

Las versiones modernas de C ++ incluían muchas extensiones como throw que son malas ideas y muy caras en términos de tiempo de procesador, y en algunos procesadores integrados el uso de throw es demasiado costoso para proyectos reales. Pero la mayoría de los desarrolladores de C ++ sienten que tienen que usar todas las herramientas en la caja y no solo las lanzan, sino que las usan en circunstancias que ni siquiera son errores, y mucho menos excepciones. Esto crea una lógica de flujo de control dual que es imposible de analizar o probar a fondo.

Esta es una buena razón para usar C en lugar de C ++.

Cuando los equipos de Windows Mobile prohibieron lanzar teléfonos móviles, sus métricas mejoraron drásticamente.

C ++ es bastante adecuado para el trabajo incrustado, pero probablemente se limitaría al subconjunto incrustado. Cosas como la identificación del tipo de tiempo de ejecución pueden consumir mucha memoria. Pero, con cuidado, C ++ se puede usar de manera muy efectiva.