¿Será posible escribir código en C++ para microcontroladores PIC en el futuro?

¿Alguna vez será posible usar C++ para codificar PIC? ¿Hay alguna limitación de hardware que nos impida usar C++? ¿Cuánto aumenta el tamaño del archivo .hex generado y el tiempo de ejecución del programa cuando usamos C++ en lugar de C? ¿Es prácticamente posible usar C++ para los PIC actuales? ¿Hay algún plan futuro o desarrollo en curso sobre esto?

Creo que es posible y seguirá siendo posible, pero AFAIK no se recomienda ya que implementa estructuras y funciones de alto nivel que no son adecuadas para una programación fuertemente relacionada con el hardware.
Dado que la respuesta es "Sí, ya existen compiladores de C++", voy a dejar esto en pie, pero en el futuro debe tener en cuenta que las preguntas de Stack Exchange deben ser sobre hechos verificables, no sobre suposiciones sobre el futuro.
@clabacchio: No necesariamente cierto. En C++, solo paga por lo que usa. Vea mi respuesta en: electronics.stackexchange.com/questions/3027/…
"PIC" es una generalización inútil. En algunos PIC de gama baja (piense en 10F200), C es casi imposible de usar. En algunos PIC de gama alta (serie 32MX) se rumorea que C++ se usa en este momento, y ciertamente no hay ninguna razón técnica por la que no pueda hacerlo. Entonces, un mejor enfoque podría dar una respuesta más útil, en este momento todos están respondiendo una pregunta diferente.

Respuestas (5)

¿Alguna vez será posible usar C++ para codificar PIC?

Sí, ahora es posible. Para dsPIC, existe el Compilador C++ de IAR Systems (aunque es muy antiguo y no es compatible).

Otra opción es usar un convertidor de C++ a C. Usando un paso de preconstrucción, convierta el C++ a C, luego entregue el C (aspecto desagradable) a su compilador de C normal. Eche un vistazo a LLVM o al compilador C++ de Comeau, que hacen eso. Comeau cuesta solo $ 50, pero probablemente requerirá un poco de esfuerzo hacer que toda la cadena de herramientas y las bibliotecas funcionen correctamente.

¿Hay alguna limitación de hardware que nos impida usar C++?

Respuesta corta, no, no hay limitaciones de hardware. Respuesta larga, C ++ ciertamente fomenta el uso de un montón y / o pila, con lo que las MCU más pequeñas con RAM limitada tendrán problemas.

¿Por qué luchan con un montón/pila? Por dos razones: A) muchas MCU tienen RAM limitada, ciertamente no suficiente para un montón y apenas suficiente para una pila. B) muchas MCU no manejan bien los punteros, por lo que el uso de variables en la pila realmente mata el rendimiento.

Cuando las personas preguntan sobre el uso de C++ en una MCU, me parece constructivo comparar C++ con C. Se hicieron (y aún se hacen) exactamente las mismas preguntas sobre C en una MCU. La gente solía resistirse a la idea. ¿Un lenguaje de alto nivel, en MCU de RAM de 256 bytes? Imposible. Pero ahora todos sabemos que es posible. He escrito C para un PIC12. No hay problema. Es posible porque A) los desarrolladores de software saben que deben tener un poco de cuidado: no usen malloc(), etc. y B) el compilador ha sido escrito especialmente para MCU. El compilador también tendrá mucho cuidado con la asignación de memoria, no intentará crear un montón y es posible que no cree una pila. Algunos compiladores de C simplemente no le permitirán escribir código reentrante (recursivo) que requiere absolutamente una pila.

Sabiendo que es posible escribir C para una MCU, las mismas respuestas se aplican a la cuestión de escribir C++ en una MCU. Siempre que el compilador comprenda las limitaciones del dispositivo de destino y el usuario también comprenda el idioma, no hay ningún problema. En C++, solo pagas por lo que usas. Es perfectamente posible escribir C++ (con objetos y todo) que produzca la salida exacta de ASM que habrías obtenido si hubieras usado C.

Ahora, los PIC32 ciertamente pueden hacer frente a C++. Tienen hasta 64kB de RAM y se basan en el núcleo MIPS, que es un procesador de 32 bits adecuadamente desarrollado. Puede manejar punteros y una pila, así como una PC. De hecho, hay PC basadas en MIPS (o al menos, solía haber).

Lamentablemente, hay muchos malentendidos en torno a C++. Incluso los codificadores con mucha experiencia parecen no tener idea de cómo funciona el lenguaje. Vea mi respuesta sobre por qué C ++ es adecuado en CPU integradas.

¿Cuánto aumenta el tamaño del archivo .hex generado y el tiempo de ejecución del programa cuando usamos C++ en lugar de C?

Como dije, puede que no haya diferencia. Bjarne Stroustrup hizo una comparación de un grupo de compiladores C/C++ para comparar el rendimiento de tiempo y espacio para una serie de operaciones. Los resultados variaron ampliamente. En algunos casos, el C++ salió más lento y más grande, en algunos casos más lento y más pequeño, o más rápido y más grande, ¡e incluso más rápido y más pequeño! Entonces, la respuesta a su pregunta es que depende en gran medida del compilador, pero en general, no necesita hacer ninguna diferencia. Para obtener más detalles, consulte el Informe técnico sobre el rendimiento de C++

¿Hay algún plan futuro o desarrollo en curso sobre esto?

Eso no lo sé. Sé que el compilador Microchip C32 es de código abierto y puede descargar el código fuente. También sé que alguien con quien trabajé encontró algunas instrucciones en línea y logró que el compilador compilara código C++. Pero dejó la empresa antes de poder ofrecerme una cadena de herramientas adecuada.

ACTUALIZAR

Microchip ahora tiene un compilador C++ disponible para su gama PIC32 de MCU integrados.

de la página web de IAR: "Producto heredado: IAR Embedded Workbench para dsPIC es un producto heredado. IAR Systems no lo actualiza y no es posible comprar un Acuerdo de soporte y actualización para él".
Sé que los productos IAR son geniales, pero desafortunadamente muy caros y parecen 'antiguos'. Sé que C ++ es factible en cualquier plataforma siempre que no use todas las funciones. Sin embargo, agrega la posibilidad de una capa adicional de abstracción con clases. No uso plantillas a menudo, ni tampoco uso asignaciones de memoria dinámica. ¿Alguien conoce a algún otro competidor para C++ en PIC24/PIC32?
Sí, lo siento, no fue realmente un gran descubrimiento. Permítanme agregar algunas cosas más a mi respuesta.
Consideraría a C como un competidor de C++ en un microcontrolador. No se me ocurre nada que me gustaría hacer en C++ que no pueda hacer en C y hay menos llamadas a funciones invisibles (constructores, destructores, etc.). Hace que el código sea más determinista y simple. ¿Qué características de C++ son imprescindibles y no se pueden confundir con C?
Uno podría preguntarse: "¿Qué características de C son imprescindibles que no se pueden confundir en ASM?" Respuesta, "Nada". Los beneficios son una mayor capacidad para que el diseñador especifique el diseño y hacer que el compilador verifique que la implementación sea correcta. Consulte mi respuesta electronics.stackexchange.com/questions/3027/… para obtener una lista de los beneficios reales e inmediatos de C++ a este respecto.
Lástima que no puedo encontrar ningún binario para LLVM. El Comeau parece un programa extraño, que usa palabras como 'impresionante, sorprendente y fabuloso' (es decir, ¿qué PUEDE hacer? - ¡No tengo idea, no pagué 50 $ por eso!). Tendría que probar LLVM en un VMware, pero suena muy doloroso para el uso diario.
Sí, es muy triste que no haya grandes soluciones.
Puede probar el compilador Comeau en línea: comeaucomputing.com/tryitout
Te he otorgado la recompensa como la única respuesta útil en el período de recompensa. ¡Descubrí el chipKIT32, que es compatible con Arduino y, por lo tanto, usa C ++! Incluso vi pic32-g++.exe, por lo que es un poco prometedor. Publicaré aquí si puedo sacar algo de esto. La documentación de los nuevos compiladores futuros de Microchip ha cambiado el estado de C++ de 'no compatible' a 'todavía no compatible'.
Gracias Hans. ¡Buenas noticias sobre el chipKIT32 y muy buenas noticias de que Microchip algún día podría tener un compilador PIC32 C++!
Es importante tener en cuenta que los procesadores como los PIC "clásicos" o el 8x51, no es posible generar un buen código sin generar un gráfico de llamadas sin bucles. Los compiladores de tales máquinas son generalmente pesimistas en su generación de gráficos de llamadas, pero para el código escrito en C eso no suele ser un problema. No he intentado codificar C++ en tales plataformas, pero esperaría que en muchos casos sea más difícil probar que una rutina no se puede llamar recursivamente.
@supercat: ese es realmente un punto muy interesante.
¿Qué compiladores de C no permiten el código recursivo?
El enlace del compilador IAR C++ ahora está muerto.
@Dean: creo que hay al menos un compilador de C para el PIC que no lo hace, tal vez el de CSS . Además, el compilador PSoC generalmente no permite código reentrante .

¿Cuánto aumenta el tamaño del archivo .hex generado y el tiempo de ejecución del programa cuando usamos C++ en lugar de C?

Depende de las funciones que uses. Si usa las características principales orientadas a objetos (clase + métodos), es probable que tenga muy poco efecto (los nombres de variables/funciones alterados son más largos, por lo que es probable que la tabla de símbolos aumente un poco). Las plantillas tampoco deberían agregar mucho con un buen compilador.

Si te vuelves loco e incorporas elementos como la biblioteca de plantillas estándar y usas la asignación de memoria dinámica y las excepciones, es probable que te encuentres con un código inflado.

Solo una advertencia para el OP, tenga mucho cuidado con la asignación de memoria en arquitecturas de memoria pequeña y sistemas integrados que siempre se ejecutan.
¿Podría el "-1" comentar por qué no está de acuerdo?
No soy el -1er, pero las plantillas son una característica que debe usarse con mucho cuidado para evitar la sobrecarga de código. Puede terminar fácilmente con muchas copias de un algoritmo cuando una sería suficiente.
Para hacer eso, en realidad tendría que usar la plantilla con varios tipos de datos diferentes, y una copia NO SERÍA suficiente a menos que esté usando un código polimórfico que tenga una clase base común. (En cuyo caso hay un costo de tiempo de ejecución). Las plantillas no hacen que su código se hinche mágicamente, solo causan un código hinchado cuando las usa con múltiples tipos de datos y no es consciente de las consecuencias.

Ya hay compiladores de C++ para pic, por ejemplo, http://www.sourceboost.com/Products/BoostCpp/Overview.html

No he usado esto y no sé nada al respecto aparte de que existe ...

Generalizando un poco su pregunta, hay procesadores ARM que están diseñados para el mercado integrado que contienen una MMU (unidad de administración de memoria). El tamaño y la asignación de la memoria hicieron que lenguajes como Java y C++ fueran malas opciones integradas. A medida que los procesadores integrados se vuelven más rápidos y potentes, y que la memoria se vuelve más densa y económica, las opciones de idioma disponibles para los ingenieros integrados cambian drásticamente. Un procesador ARM de 32 bits a 600 MHz con MMU y una tarjeta Flash de 64 G es un gran candidato para las aplicaciones de C++. Si se ajusta a la definición del procesador integrado clásico es otra cuestión.

Probablemente sí... pero no deberías de todos modos... C es el lenguaje de incrustado y no hay ventajas de usar C++. O más bien, las ventajas de C superan con creces las ventajas de C++ para sistemas integrados. No pierdas tu tiempo.

  • si sabe cómo usar punteros de función, etc. Puede codificar como C ++, no hay problema allí.
Siento disentir. Puede usar muchas características de C++ (clases, plantillas, sobrecarga de operadores, referencias) con poco o ningún costo de tiempo de ejecución. Sí, puedes hacer todas estas cosas en C simple con construcciones hackish, pero es un lastre para tu cerebro, y preferiría usar C++. (Por supuesto, preferiría usar un lenguaje mejor, pero elegiría un compilador de C ++ en un abrir y cerrar de ojos en lugar de C simple).
Classes = structs (sin métodos incorporados, pero si lo desea, puede almacenar un puntero de función en la estructura y llamarlo). Plantillas = usas esas??? Sobrecarga de operadores = sí, también me gustaría eso. Referencias = punteros, ¿no? Con C, al menos, puede usar solo las 'características' de C ++ que desea sin preocuparse por la generación excesiva de código o tener que incluir una gran biblioteca aleatoria solo para obtener algo para compilar.
También discrepo.
Sí, las plantillas son una forma extremadamente poderosa de generar código confiable y de alto rendimiento. Las referencias son un indicador más fiable. Con C++ también solo paga por las funciones que usa. Creo que realmente necesitas entender más C++.
Chicos, lo siento... C es el lenguaje de incrustado. Sí, puedes hacer C++ pero los beneficios siempre serán marginales. Un código C bien escrito supera cualquier código C++ cualquier día de la semana. Esa al menos mi experiencia. Leí en alguna parte, es más difícil pegarse un tiro con C++, pero una vez que lo haces, te lleva toda la pierna. Estoy completamente de acuerdo. Cuando estás cerca del metal, no quieres abstracciones interminables, sobrecargas, etc. La mejor manera es ceñirte a lo básico.
No sé a qué te refieres con "C es el lenguaje de incrustado". Claro, es muy popular. ¿Estás diciendo que es el mejor lenguaje posible? Seguramente no.
@Rocketmagnet El 90 % del código incrustado es C. ¿Es el mejor? No sé, pero es el más común y el más fácil de mantener. Este es un problema de gusto, encuentro que C ++ es desagradable para incrustado. Lo encuentro aún más desagradable para la programación de aplicaciones, hay mejores lenguajes, lua, java, etc., son algunos ejemplos. Puedo codificar bien pero no soy programador, así que lo dejo así.
@Rocketmagnet: Llamar a un método C++ que podría arrojar excepciones impondrá una sobrecarga significativa, ya sea que el método arroje alguna o no. A menos que uno deshabilite las excepciones globalmente, no creo que haya una forma conveniente de pagarlas solo donde se usan.
@Ktc: las sobrecargas pueden ser muy útiles cuando se trata de escribir código eficiente. Si a una función generalmente se le pasa un valor de 8 bits, pero a veces se le pasa uno de 16 bits, tener métodos separados para los casos de 8 y 16 bits (incluso si el primero simplemente se encadena con el último) ahorrará dos instrucciones por sitio de llamadas En algunos proyectos, eso puede acumularse muy rápidamente. Las sobrecargas pueden facilitar el uso de métodos separados. Me gustaría que el comité de estándares de C permitiera sobrecargas para métodos estáticos y en línea ; Históricamente, la objeción tradicional a la sobrecarga ha sido que requiere una modificación del nombre, pero...
... eso solo sería un problema para los nombres a los que se podía acceder a través de un código externo. Restringir la sobrecarga a funciones estáticas y en línea de ninguna manera impediría su utilidad, ya que un archivo de encabezado podría fácilmente decir inline int foo(unsigned char x) { return foo_byte(x); }y convertir cada llamada a foo()la que pasa an unsigned charen una llamada a foo_byte().
@Ktc: al menos, gracias a gente como tú, la gente como yo tiene trabajo. Y, por cierto, me resulta bastante extraño que no promocione ensamblador sobre C, porque, ya sabes, está más cerca del metal. Lo siento, pero tu respuesta y comentarios son pura tontería.
¿Será posible escribir código en C++ para microcontroladores PIC en el futuro?
RespuestasAquíPolítica de privacidad1y, 0v