Será possível escrever código em C ++ para microcontroladores PIC no futuro?

Alguma vez será possível usar C ++ para codificar PICs? Existe alguma limitação de hardware que nos impede de usar C ++? Quanto o tamanho do arquivo .hex gerado e o tempo de execução do programa aumentam quando usamos C ++ em vez de C? É praticamente possível usar C ++ para PICs atuais? Existe algum plano futuro ou desenvolvimento contínuo disso?

Alguma vez será possível usar C ++ para codificar PICs?

Sim, é possível agora. Para o dsPIC, existe o compilador IAR Systems C ++ (embora seja muito antigo e sem suporte).

Outra opção é usar um conversor de C ++ para C. Usando uma etapa de pré-construção, converta o C ++ em C e, em seguida, dê o C (desagradável) ao seu compilador C normal. Dê uma olhada no LLVM ou no compilador C ++ da Comeau, que ambos fazem isso. O Comeau's custa apenas US $ 50, mas provavelmente será necessário algum esforço para que todo o conjunto de ferramentas e bibliotecas funcione corretamente.

Existe alguma limitação de hardware que nos impede de usar C ++?

Resposta curta, não, não há limitações de hardware. Resposta longa, o C ++ certamente encoraja o uso de uma pilha e / ou pilha, com a qual os MCUs menores com RAM limitada terão dificuldade.

Por que eles lutam com um heap / stack? Por duas razões: A) muitos MCUs têm RAM limitada, não o suficiente para um monte de pilha e apenas o suficiente para uma pilha. B) muitas MCUs não lidam bem com ponteiros; portanto, o uso de variáveis ​​na pilha realmente mata o desempenho.

Quando as pessoas perguntam sobre o uso de C ++ em um MCU, acho construtivo comparar C ++ a C. As mesmas perguntas exatamente foram (e ainda são) feitas sobre C em um MCU. As pessoas costumavam recusar a ideia. Uma linguagem de alto nível, em 256 bytes RAM MCU ?? Impossível. Mas agora todos sabemos que é possível. Eu escrevi C para um PIC12. Sem problemas. É possível porque A) os desenvolvedores de software sabem que precisam ser um pouco cuidadosos: não use malloc () etc. eb) o compilador foi escrito especialmente para o MCU. O compilador também terá um cuidado extra com a alocação de memória, não tentará criar um heap e pode não criar uma pilha. Alguns compiladores C simplesmente não permitem escrever código reentrante (recursivo) que exige absolutamente uma pilha.

Sabendo que é possível escrever C para um MCU, as mesmas respostas se aplicam à questão de escrever C ++ em um MCU. Enquanto o compilador entender as limitações do dispositivo de destino e o usuário entender o idioma também, não haverá realmente nenhum problema. Em C ++, você paga apenas pelo que usa. É perfeitamente possível escrever C ++ (com objetos e tudo) que produza a saída ASM exata que você teria se tivesse usado C.

Agora, os PIC32s certamente podem lidar com C ++. Eles têm até 64kB de RAM e são baseados no núcleo MIPS, que é um processador de 32 bits adequadamente desenvolvido. Pode lidar com ponteiros e uma pilha, bem como um PC. De fato, existem PCs baseados no MIPS (ou pelo menos costumavam existir).

Infelizmente, há muito mal-entendido em torno de C ++. Até codificadores muito experientes parecem não ter idéia de como a linguagem funciona. Veja minha resposta sobre por que o C ++ é adequado em CPUs incorporadas.

Quanto o tamanho do arquivo .hex gerado e o tempo de execução do programa aumentam quando usamos C ++ em vez de C?

Como eu disse, pode não haver diferença. Bjarne Stroustrup fez uma comparação de vários compiladores C / C ++ para comparar o desempenho de tempo e espaço em várias operações. Os resultados variaram amplamente. Em alguns casos, o C ++ saiu mais lento e maior, alguns casos mais lento e menor, ou mais rápido e maior, e ainda mais rápido e menor! Portanto, a resposta para sua pergunta é que depende muito do compilador, mas, em geral, não precisa fazer nenhuma diferença. Para mais detalhes, consulte o Relatório Técnico sobre Desempenho em C ++

Existe algum plano futuro ou desenvolvimento contínuo disso?

Isso eu não sei. Eu sei que o compilador Microchip C32 é de código aberto e você pode fazer o download do código-fonte. Também sei que alguém com quem trabalhei encontrou algumas instruções online e conseguiu que o compilador compilasse o código C ++. Mas ele deixou a empresa antes que pudesse me montar uma cadeia de ferramentas adequada.

ATUALIZAR

A Microchip agora tem um compilador C ++ disponível para sua linha PIC32 de MCUs incorporadas.

Quanto o tamanho do arquivo .hex gerado e o tempo de execução do programa aumentam quando usamos C ++ em vez de C?

Depende dos recursos que você usa. Se você usar os principais recursos orientados a objetos (classe + métodos), provavelmente terá muito pouco efeito (nomes de variáveis ​​/ funções desconfigurados por mais tempo, portanto a tabela de símbolos provavelmente aumentará um pouco). Os modelos também não devem adicionar muito com um bom compilador.

Se você enlouquecer e usar coisas como a Biblioteca de modelos padrão e usar alocação de memória dinâmica e exceções, é provável que você se depare com um inchaço de código.

Já existem compiladores c ++ para pic, por exemplo http://www.sourceboost.com/Products/BoostCpp/Overview.html

Eu não usei isso e não sei nada sobre isso além de existir ...

Generalizando um pouco a sua pergunta, existem processadores ARM criados para o mercado incorporado que contêm uma MMU (unidade de gerenciamento de memória). O tamanho e a alocação da memória criaram linguagens como java e c ++ más opções incorporadas. À medida que os processadores embarcados continuam a ficar mais rápidos e poderosos, e à medida que a memória se torna mais densa e barata, as opções de idioma disponíveis para os engenheiros embarcados mudam drasticamente. Um processador ARM de 32 bits e 600 MHz com MMU e um cartão Flash de 64G é um ótimo candidato para aplicativos c ++. Se ele se encaixa na definição do processador embutido clássico é outra questão.

Provavelmente sim ... mas você não deveria mesmo assim ... C é a linguagem do incorporado e não há vantagens em usar C ++. Ou melhor, as vantagens do C superam em muito as vantagens do C ++ para incorporado. Não perca seu tempo.

• se você souber usar ponteiros de função, etc. Você pode codificar como C ++, não há nenhum problema.