Existe alguma razão para usar C em vez de C ++ para desenvolvimento de sistemas embarcados?

https://stackoverflow.com/questions/812717

03-07-2019
|

Pergunta

Pergunta
Eu tenho dois compiladores no meu hardware C ++ e C89

Eu estou pensando em usar C ++ com as classes mas sem polimorfismo (a vtables evitar). As principais razões que eu gostaria de usar C ++ são:

Eu prefiro usar funções “inline” em vez de definições de macro.

Eu gostaria de usar namespaces como eu prefixos desorganização do código.

Eu vejo C ++ um tipo pouco mais seguro, principalmente por causa de modelos e detalhado casting.

Eu realmente gosto de funções e construtores sobrecarregados (usado para fundição automática).

Você vê qualquer razão para ficar com C89 no desenvolvimento de hardware muito limitado (4KB de RAM)?

Conclusão

Obrigado por suas respostas, eles foram realmente útil!

Eu pensei que o assunto através de e eu vou ficar com C principalmente porque:

É mais fácil prever código real em C e isto é realmente importante se você tiver apenas 4KB de RAM.
A minha equipa é constituída principalmente de desenvolvedores de C, de modo recursos avançados de C ++ não será usado freqüentemente.
Eu encontrei uma maneira de funções embutidas no meu compilador C (C89).

É difícil aceitar uma resposta que você forneceu tantas boas respostas. Infelizmente eu não posso criar um wiki e aceitá-lo, então eu vou escolher uma resposta que me fez pensar mais.

Solução

Duas razões para usar C sobre C ++:

Para um monte de processadores embarcados, ou não há compilador C ++, ou você tem que pagar extra por isso.
A minha experiência é que uma proporção signficant de engenheiros de software embutidos têm pouca ou nenhuma experiência de C ++ - ou por causa de (1), ou não, porque ele tende a ser ensinado em graus engineeering eletrônicos - e por isso seria melhor ficar com o que eles sabem.

Além disso, a pergunta original, e uma série de comentários, mencionar a 4 Kb de RAM . Para um processador incorporado típico, a quantidade de RAM é (principalmente) não relacionado com o tamanho do código, como o código é armazenada, e executado a partir, de flash.

Com certeza, a quantidade de espaço de armazenamento de código é algo a ter em mente, mas como novos e mais espaçoso, processadores de aparecer no mercado, é um problema menor do que costumava ser para todos, mas a maioria dos projectos sensíveis ao custo .

Sobre o uso de um subconjunto de C ++ para uso com sistemas embarcados: existe agora uma Misra C ++ padrão, que pode valer a pena dar uma olhada.

EDIT: Veja também este questão, o que levou a um debate sobre C vs C ++ para embutido sistemas.

Outras dicas

Para um muito alvo recursos limitados, tais como 4KB de RAM, eu testar as águas com algumas amostras antes de cometer uma grande quantidade de esforço que não pode estar de volta facilmente portado em uma pura ANSI C implementação.

O incorporado C ++ grupo de trabalho fez propor um subconjunto padrão da língua e um subconjunto padrão da biblioteca padrão para ir com ele. Perdi a noção do que esforço quando Jornal do Usuário C morreu, infelizmente. Parece que há um artigo em Wikipedia , e que o comitê ainda existe.

Em um ambiente incorporado, você realmente tem que ser cuidadoso sobre alocação de memória. Para reforçar esse cuidado, pode ser necessário definir a operator new() global e seus amigos para algo que não pode mesmo ser ligado de modo que você sabe que não é usado. new colocação por outro lado, é provável que seja seu amigo, quando usado criteriosamente juntamente com uma estável, thread-safe, e esquema de atribuição de latência garantida.

funções inline não irá causar muito problema, a menos que eles são grandes o suficiente para que eles deveriam ter sido verdadeiras funções em primeiro lugar. É claro que as macros sua substituindo tinha o mesmo problema.

Modelos, também, não pode causar um problema a menos que seus funcionamentos instanciação amok. Para qualquer modelo que você faça uso, auditar o código gerado (o mapa ligação pode ter indícios suficientes) para ter certeza de que somente as instâncias que você pretendia usar aconteceu.

Uma outra questão que pode surgir é a compatibilidade com o depurador. Não é incomum para um depurador hardware de outra forma utilizável para ter suporte muito limitado para a interação com o código-fonte original. Se você efetivamente deve depurar em conjunto, então o nome interessante deturpação de C ++ pode adicionar confusão extra para a tarefa.

RTTI, moldes dinâmicos, herança múltipla, polimorfismo pesado, e as exceções todos vêm com uma certa quantidade de custo de tempo de execução para a sua utilização. Algumas dessas características nivelar esse custo ao longo de todo o programa, se eles são usados, outros apenas aumentam o peso das classes que precisam deles. Saber a diferença e escolher recursos avançados sabiamente com pleno conhecimento de pelo menos uma análise superficial de custo / benefício.

Em um ambiente incorporado pequeno você quer ser ligando diretamente para um kernel em tempo real ou em execução diretamente no hardware. De qualquer maneira, você vai precisar para ter certeza de que seus tempo de execução alças código de inicialização C ++ afazeres de inicialização específica corretamente. Isso pode ser tão simples como certificando-se de usar as opções de vinculador certas, mas uma vez que é comum ter controle direto sobre a fonte do poder no ponto de entrada reset, você pode precisar de auditoria que ter certeza de que ele faz tudo. Por exemplo, em uma plataforma ColdFire que trabalhei, as ferramentas dev fornecidos com um módulo CRT0.S que tinha a C ++ initializers presente, mas comente. Se eu tivesse usado direto da caixa, eu teria sido mistificado por objetos globais cujos construtores nunca tinha executado.

Além disso, em um ambiente incorporado, muitas vezes é necessário para inicializar dispositivos de hardware antes que eles podem ser usados, e se não houver OS e sem carregador de boot, então é o código que faz isso. Você precisa se lembrar que os construtores para objetos globais são executados antes main() é chamado assim você terá que modificar seu CRT0.S local (ou equivalente) para obter essa inicialização hardware feito antes os construtores globais em si são chamados. Obviamente, o topo do main() é muito tarde.

No. Qualquer um dos recursos linguagem C ++ que podem causar problemas (polimorfismo de tempo de execução, RTTI, etc.) podem ser evitados ao fazer desenvolvimento de sistemas embarcados. Há uma comunidade de desenvolvedores integrados C ++ (Lembro-me de ler colunas por desenvolvedores de sistemas embarcados utilizando C ++ no antigo C Journal / C Usuários ++), e eu não posso imaginar que seria muito vocal, se a escolha foi tão ruim assim.

O Relatório Técnico de Desempenho C ++ é um grande guia para este tipo de coisa. Note-se que ele tem uma seção sobre questões de programação incorporados!

Além disso, ++ na menção de Embutido C ++ nas respostas. A norma não é de 100% para o meu gosto, mas é um bom bocado de referência ao decidir que partes do C ++ que você pode cair.

Enquanto a programação para pequenas plataformas, nós exceções desativar e RTTI, evitou herança virtual, e pagou muita atenção para o número de funções virtuais que tem por aí.

Seu amigo é o mapa de vinculador, no entanto:. Verificá-lo com freqüência, e você verá fontes de código e inchaço memória estática rapidamente

Depois disso, as considerações de uso de memória dinâmica padrão se aplicam: em um ambiente tão restrito quanto o que você falar, você pode querer não usar alocações dinâmicas em tudo. Às vezes você pode sair com pools de memória para pequenas alocações dinâmicas, ou "-frame base" alocação onde preallocate um bloco e jogar fora a coisa toda mais tarde.

Eu recomendo usar o compilador C ++, mas limitando o uso de características específicas C ++. Você pode programar como C em C ++ (o tempo de execução C está incluído ao fazer C ++, embora na maioria dos aplicativos incorporados você não fazer uso da biblioteca padrão de qualquer maneira).

Você pode ir em frente e utilizar classes C ++ etc., apenas

limitar o uso de funções virtuais (como você disse)
limitar o uso de modelos
Para uma plataforma embarcada, você vai querer substituir o operador de novo e / ou colocação uso novo para alocação de memória.

Como um firmware / engenheiro de sistemas embarcados, eu posso dizer a vocês algumas das razões por que C ainda é a escolha # 1 sobre C ++ e sim, eu sou fluente em ambos.

1) Alguns alvos que desenvolvemos no tem 64kb de memória RAM tanto para código e dados, então você tem que se certificar que cada contagem de bytes, e sim, eu lidei com a otimização de código para salvar 4 bytes que me custou 2 horas, e isso é, em 2008.

2) função de biblioteca Todo C é revisto antes de deixá-los no código final, por causa da limitação de tamanho, por isso, nós preferimos as pessoas a não utilização divisão (sem divisor de hardware, por isso, uma grande biblioteca é necessário), malloc (porque nós não têm montão, toda a memória é alocada de buffer de dados em 512 bytes pedaço e deve ser o código revisado), ou outra prática orientada a objetos que carregam grande penalidade. Lembre-se, cada função de biblioteca que você use contar.

3) Já ouviu falar da sobreposição prazo? você tem tão pouco espaço de código que às vezes você tem que coisas trocar com outro conjunto de código. Se você chamar uma função de biblioteca, em seguida, a função de biblioteca deve ser residente. Se você usá-lo apenas em uma função de sobreposição, você está desperdiçando um monte de espaço contando com muitos métodos orientados a objeto. Portanto, não assumir qualquer função de biblioteca C, muito menos C ++ para ser aceito.

4) Fundição e até mesmo a embalagem (onde a estrutura de dados desalinhados atravessa limite de palavra) são necessários devido ao design de hardware limitada (ou seja, um motor ECC, que é ligado de certa forma) ou para lidar com um erro de hardware. Você não pode assumir muito inplicitly, então por objeto oriente demais?

5) pior cenário: eliminando alguns dos métodos orientados a objeto forçará desenvolver a pensar antes de usar recursos que podem explodir (ou seja, que reparte 512bytes em uma pilha ao invés de um buffer de dados), e evitar alguns dos potenciais pior cenário que não são testados para ou eliminar todo o caminho de código todos juntos.

6) Nós usamos um monte de abstração para manter hardware de software e código make tão portátil quanto possível, e simulação amigável. acesso ao hardware deve ser acondicionada em uma macro ou função em linha que estão compilados condicionalmente entre diferentes plataformas, tipo de dados deve ser fundido como byte tamanho, em vez de específico alvo, utilização ponteiro directa não é permitido (porque alguns plataforma assumir memória mapeada I / O é a mesmo que a memória de dados), etc.

Eu posso pensar de mais, mas você começa a idéia. Nos firmware caras têm formação orientada a objeto, mas a tarefa de sistema embarcado pode ser tão hardware orientado e de baixo nível, que não é de alto nível ou abstraível por natureza.

BTW, cada trabalho firmware Estive no controle de origem usos, eu não sei de onde você tirou essa idéia de.

-alguns cara firmware da SanDisk.

A minha preferência pessoal é C, porque:

Eu sei o que cada linha de código está fazendo (e custos)

Não sei C ++ bem o suficiente para saber o que cada linha de código está fazendo (e custos)

Por que as pessoas dizem isso? Você não sabe o que cada linha de C está fazendo a menos que você verifique a saída asm. O mesmo vale para C ++.

Por exemplo, o que asm faz isso produzir declaração inocente:

a[i] = b[j] * c[k];

Parece bastante inocente, mas um compilador baseado gcc produz este asm para um 8-bit micro

CLRF 0x1f, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1f, F, ACCESS
MOVWF 0x1e, ACCESS
MOVLW 0xf9
MOVF 0xfdb, W, ACCESS
ADDWF 0x1e, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfa
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1f, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x1c
NOP
MOVFF 0xfef, 0x1d
NOP
MOVLW 0x1
CLRF 0x1b, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1b, F, ACCESS
MOVWF 0x1a, ACCESS
MOVLW 0xfb
MOVF 0xfdb, W, ACCESS
ADDWF 0x1a, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfc
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1b, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x18
NOP
MOVFF 0xfef, 0x19
NOP
MOVFF 0x18, 0x8
NOP
MOVFF 0x19, 0x9
NOP
MOVFF 0x1c, 0xd
NOP
MOVFF 0x1d, 0xe
NOP
CALL 0x2142, 0
NOP
MOVFF 0x6, 0x16
NOP
MOVFF 0x7, 0x17
NOP
CLRF 0x15, ACCESS
RLCF 0xfdf, W, ACCESS
ANDLW 0xfe
RLCF 0x15, F, ACCESS
MOVWF 0x14, ACCESS
MOVLW 0xfd
MOVF 0xfdb, W, ACCESS
ADDWF 0x14, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfe
MOVF 0xfdb, W, ACCESS
ADDWFC 0x15, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0x16, 0xfee
NOP
MOVFF 0x17, 0xfed
NOP

O número de instruções produzidas depende maciçamente em:

Os tamanhos de a, b, e c.
se esses ponteiros são armazenados na pilha ou são globais
se i, j, k estão na pilha ou são globais

Isto é especialmente verdadeiro no pequeno mundo incorporado, onde os processadores não são apenas configurado para lidar com C. Assim, a minha resposta seria que C e C ++ são tão ruins quanto o outro, a menos que você examine sempre a saída asm, em caso em que eles são apenas tão bom quanto o outro.

Hugo

Ouvi dizer que algumas pessoas preferem C para o trabalho incorporado devido ao fato de que é mais simples e, portanto, mais fácil de prever o código real que será gerado.

Eu, pessoalmente, acho que a escrita de estilo C C ++ (usando modelos para o tipo-segurança) iria dar-lhe uma série de vantagens embora e eu não consigo ver nenhuma verdadeira razão para não.

Eu não vejo nenhuma razão para usar C em vez de C ++. Tudo o que você pode fazer em C, você pode fazê-lo também em C ++. Se você quer evitar overheads de VMT, não use métodos virtuais e polimorfismo.

No entanto, C ++ pode proporcionar algumas expressões muito úteis com nenhuma sobrecarga. Um dos meus favoritos é RAII. As aulas não são necessárias caro em termos de memória ou de desempenho ...

Eu escrevi algum código para ARM7 paltform incorporado em IAR Workbench. Eu recomendo contando com modelos para fazer a otimização de tempo de compilação e previsão caminho. Evite elenco dinâmico como praga. Use traços / políticas para a sua vantagem, como prescrito no livro de Andrei Alexandrescu, Modern C ++ projeto .

Eu sei, pode ser difícil de aprender, mas estou também a certeza de que o produto irá beneficiar dessa abordagem.

Um bom motivo e às vezes a única razão é que ainda não há um compilador C ++ para o sistema específico incorporado. Este é o caso, por exemplo micro-controladores Microchip PIC . Eles são muito fáceis de gravação para e eles têm um compilador livre C (na verdade, uma ligeira variante do C), mas não há compilador C ++ em vista.

Para um sistema restrito a 4K de RAM, gostaria de usar C, não C ++, apenas para que você pode ter certeza de ver tudo o que está acontecendo. A coisa com C ++, é que é muito fácil de usar muito mais recursos (tanto CPU e memória) do que parece que olhando para o código. (Oh, eu vou criar outro BlerfObject fazer isso ... gritos! Sem memória!)

Você pode fazê-lo em C ++, como já mencionado (sem RTTI, há vtables, etc, etc), mas você vai gastar tanto tempo ter certeza que seu C ++ uso não ficar longe de você como você poderia fazer o equivalente em C.

A mente humana lida com a complexidade de avaliar, tanto quanto possível, e, em seguida, decidir o que é importante para se concentrar, e descartando ou depreciando o resto. Esta é toda a base para trás a marca em Marketing, e em grande parte, ícones.

Para combater esta tendência prefiro C para C ++, porque força você a pensar sobre seu código, e como ele está interagindo com o hardware mais de perto - implacavelmente perto.

De longa experiência é a minha crença de que C obriga a chegar a melhores soluções para os problemas, em parte, por ficar fora do seu caminho e não forçá-lo a perder muito tempo que satisfazem uma restrição algum pensamento compilador de escritor era uma boa idéia, ou descobrir o que está acontecendo "sob as cobertas".

Nesse sentido, linguagens de baixo nível como C você gastar muito tempo focado no hardware e construção de data-estrutura bons / Bundles algoritmo, enquanto linguagens de alto nível que você gastar um monte de tempo coçando a cabeça se perguntando o que está acontecendo lá dentro, e por que você não pode fazer algo perfeitamente razoável em seu contexto específico e meio ambiente. Batendo seu compilador em sua apresentação (tipagem forte é o pior criminoso) não é um uso produtivo do tempo.

Eu provavelmente se encaixa no molde programador bem - I como controle. Em minha opinião, isso não é uma falha de personalidade para um programador. Controle é o que somos pagos para fazer. Mais especificamente, na perfeição controlar. C lhe dá muito mais controle do que C ++.

Pessoalmente com 4KB de memória Eu diria que você não está recebendo muito mais milhagem fora de C ++, então basta escolher o que parece ser a melhor combinação de compilador / runtime para o trabalho, já que a linguagem provavelmente não vai importar muito .

Note que ele também não é tudo sobre a língua de qualquer maneira, uma vez que também os assuntos da biblioteca. Muitas vezes libs C têm um tamanho mínimo de um pouco menor, mas eu poderia imaginar que um lib C ++ orientada para desenvolvimento de sistemas embarcados é cortada, por isso certifique-se de teste.

Alguns dizem que compiladores C pode gerar o código muito mais eficiente, porque eles não têm de suportar os recursos avançados de C ++ e pode, portanto, ser mais agressivo em suas otimizações.

É claro que, neste caso, você pode querer colocar os dois compiladores específicos para o teste.

C ganha em portabilidade - porque é menos ambígua na especificação linguagem; portanto, oferecendo muito melhor portabilidade e flexibilidade em diferentes compiladores etc (menos dores de cabeça).

Se você não está indo para alavancagem C ++ apresenta para suprir uma necessidade, em seguida, ir com C.

Você vê qualquer razão para ficar com C89 ao desenvolver por muito limitado hardware (4KB de RAM)?

Pessoalmente, quando se trata de aplicações embarcadas (Quando eu digo incorporado, eu não quero dizer WinCE, iPhone, etc .. inchado incorporado dispositivos hoje). I recurso média dispositivos limitados. Eu prefiro C, apesar de eu ter trabalhado com C ++ um pouco também.

Por exemplo, o dispositivo que você está falando tem 4kb de RAM, bem apenas por esse motivo eu não iria considerar C ++. Claro, você pode ser capaz de projetar algo pequeno usando C ++ e limitar o seu uso dela em sua aplicação como outras mensagens têm sugerido, mas C ++ "poderia" potencialmente acabam complicando / inchaço sua aplicação sob as cobertas.

Você vai vincular estaticamente? Você pode querer comparar a aplicação de um manequim estático usando c ++ vs c. Isso pode levar você a considerar C em seu lugar. Por outro lado, se você é capaz de construir uma aplicação C ++ dentro de seus requisitos de memória, vá para ele.

IMHO, Em geral, em aplicações embarcadas Gosto de saber tudo o que está acontecendo. Quem está usando recursos de memória / do sistema, quanto e por quê? Quando eles libertá-los?

Ao desenvolver para um alvo com X quantidade de recursos, CPU, memória, etc .. Eu tento ficar no lado inferior de usar esses recursos, porque você nunca sabe o que as necessidades futuras virá junto, assim, ter de adicionar mais código para o projeto que era "suposto" para ser uma pequena aplicação simples, mas acaba se tornando muito maior.

A minha escolha é geralmente determinada pela biblioteca C que decidir usar, que é selecionado com base no que o dispositivo precisa fazer. Assim, 9/10 vezes .. ele acaba sendo uClibc ou newlib e C. O kernel que usamos é uma grande influência sobre isso também, ou se estamos escrevendo nosso próprio kernel.

A sua também uma escolha de um terreno comum. A maioria dos bons programadores C não tem nenhum problema usando C ++ (embora muitos se queixam o tempo todo que eles usá-lo) .. mas eu não encontrei o inverso é verdade (na minha experiência).

Em um projeto que estamos trabalhando (que envolve um zero kernel), a maioria das coisas são feitas em C, no entanto, uma pequena pilha de rede foi implementada em C ++, porque era mais fácil e menos problemático para implementar rede usando C ++ .

O resultado final é, o dispositivo será ou testes de trabalho e aceitação passagem ou não vai. Se você pode implementar foo na pilha xx e restrições heap yy usando linguagem z, vá para ele, use o que o torna mais produtivo.

A minha preferência pessoal é C, porque:

Eu sei o que cada linha de código está fazendo (e custos)
Não sei C ++ bem o suficiente para saber o que cada linha de código está fazendo (e custos)

Sim, estou confortável com C ++, mas eu não sei que, assim como eu faço o padrão C.

Agora, se você pode dizer o contrário do que, bem, use o que você sabe :) Se funcionar, passa nos testes, etc .. Qual é o problema?

Quanto ROM / FLASH você tem?

4kB de RAM ainda pode dizer que há centenas de kilobytes de flash para armazenar o código real e dados estáticos. RAM neste tamanho tende a ser destinado apenas para as variáveis, e se você for cuidadoso com aqueles que você pode caber um grande programa bastante em termos de linhas de código na memória.

No entanto, C ++ tende a fazer colocando código e dados em FLASH mais difícil, devido às regras de construção em tempo de execução para objetos. Em C, uma estrutura constante pode facilmente ser colocado em memória FLASH e acessado como um objeto de hardware constante. Em C ++, um objeto constante exigiria o compilador para avaliar o construtor em tempo de compilação, que eu acho que ainda é além do que um compilador C ++ pode fazer (teoricamente, você poderia fazê-lo, mas é muito, muito difícil de fazer na prática) .

Assim, em um "pequeno RAM", "grande FLASH" tipo de ambiente que eu iria com C qualquer dia. Note-se que uma boa escolha intermediária i C99 que tem a maior parte do bom C ++ apresenta para código não baseada em classe.

Em nenhum geral. C ++ é um conjunto de super C. Isso seria especialmente verdadeiro para os novos projetos.

Você está no caminho certo em evitar C ++ construções que podem ser caro em termos de tempo de CPU e cópia do pé de memória.

Note que algumas coisas como polimorfismo pode ser muito valioso - o são essencialmente ponteiros de função. Se você achar que você precisar deles, usá-los - sabiamente

Além disso, bom (bem concebido) de manipulação de exceção pode fazer seu aplicativo embutido mais confiável do que um aplicativo que lida com as coisas com códigos de erro tradicionais.

A única razão para preferir C IMHO seria se o compilador C ++ para a sua plataforma não está em boa forma (de buggy, otimização pobres, etc).

O livro C ++ para programadores de jogos tem informações sobre quando o tamanho do código será aumentada com base em características de C ++.

Você tem embutido no C99. Talvez você gosta ctors, mas o negócio de ficar dtors direito pode ser confuso. Se a única razão restante para não usar C é namespaces, eu realmente furar a C89. Isso é porque você pode querer porta-lo para uma plataforma embarcada ligeiramente diferente. Você pode mais tarde começar a escrever em C ++ no mesmo código. Mas cuidado com o seguinte, onde C ++ não é um super conjunto de C. Eu sei que você disse que você tem um compilador C89, mas faz a comparação deste C ++ com C99 de qualquer maneira, como o primeiro item, por exemplo, é verdadeiro para qualquer C desde a K & R.

sizeof 'a' > 1 em C, não em C ++. Em C você tem VLA matrizes de comprimento variável. Exemplo: func (int i) {int a [i] . Em C você tem VAM membros da matriz variável. Exemplo:. struct {int b; m int [];}

Apenas quero dizer que não existe um sistema com recursos "ilimitado". Tudo neste mundo é limitada e aplicação CADA deve considerar o uso de recursos não importa se o seu ASM, C, Java ou JavaScript. Os manequins que alocam algumas Mbs "só para ter certeza" faz iPhone 7, Pixel e outros dispositivos extremamente Luggy. Não importa se você tem 4kb ou 40 Gb.

Mas de outro lado para se opor desperdício de recursos - é um tempo que leva para salvar esses recursos. Se demorar uma semana extra para escrever uma coisa simples em C para economizar alguns carrapatos e alguns bytes em vez de usar C ++ já implementados, testados e distribuídos. Porque se importar? É como comprar um hub USB. sim, você pode fazer isso sozinho, mas é ele que vai ser melhor? mais confiável? mais barato se você contar o seu tempo?

Apenas um pensamento lateral - mesmo poder da sua tomada não é ilimitada. Tente pesquisar onde sua vindo e você vai ver principalmente o da queima de alguma coisa. A lei de energia e material ainda é válido:. Nenhum material ou de energia aparece ou desaparece, mas sim transformadas

Por questão de alocação de memória, eu posso recomendar usando Plataforma Quantum e sua abordagem máquina de estado, como ele aloca tudo que você precisa no momento da inicialização. Ele também ajuda a aliviar problemas de contenção.

Este produto é executado em C e C ++.

Depende do compilador.

compiladores Nem todos incorporados implementar todos C ++, e até mesmo se o fizerem, eles podem não ser bons em evitar inchaço de código (que é sempre um risco com templates). Testá-lo com alguns programas menores, ver se você tiver quaisquer problemas.

Mas dado um boa compilador, não, não há nenhuma razão para não usar C ++.

Eu apenas encontrei um exemplo de como usar ISO C ++ para o desenvolvimento integrado, que poderiam interessante para alguém que está fazendo a decisão sempre que o uso C ++ ou C.

Ele foi fornecido por Bjarne Stroustrup em sua página inicial :

Para uma olhada em como ISO C ++ pode ser usado para sistemas embarcados graves programação, consulte o padrões JSF veículo aéreo C ++ codificação .

Diferentes resposta post para um aspecto diferente da pergunta:

"malloc"

Algumas respostas anteriores falar um pouco sobre isso. Por que você ainda acha que existe chamada? Para uma verdadeira pequena plataforma, malloc tende a não estar disponível, ou definitivamente opcional. Implementação alocação dinâmica de memória tende a ser significativo quando você começa a ter um RTOS no fundo do seu sistema - mas até então, é puramente perigoso.

Você pode ir muito longe sem ele. Basta pensar em todos os velhos programas FORTRAN que nem sequer têm uma pilha adequada para as variáveis ??locais ...

Há uma série de diferentes fabricantes controlador de todo o mundo e quando você dar uma olhada em seus desenhos e os conjuntos de instruções que precisam ser usado para configurar você pode acabar em um monte de problemas. A principal desvantagem de linguagem de montagem é que a máquina / dependente da arquitetura. É realmente enorme pedir para um desenvolvedor de cor todas as instruções estabelecidas lá para realizar a codificação para diferentes controladores. É por isso C tornou-se mais popular no desenvolvimento de sistemas embarcados, porque C é de alto nível suficiente para abstrair os algoritmos e estruturas de dados de detalhes dependentes do hardware, tornando o código fonte portátil através de uma ampla variedade de hardware de destino, arquitetura linguagem independente e muito fácil de converter e manter o código. Mas nós vemos algumas linguagens de alto nível (orientados a objetos), como C, C ++, Python, Java, etc estão a evoluir o suficiente para torná-los sob o radar de desenvolvimento de sistemas embarcados.

Em um sistema tão limitado. Basta ir para Assembler. Dá-lhe o controle total sobre todos os aspectos, e dá nenhuma sobrecarga.

Provavelmente muito mais rápido também desde um monte de compiladores embutidos não são os melhores otimizadores (especialmente se se compara com estado dos compiladores de arte, como as que temos para o desktop (Intel, estúdio visual, etc))

"sim, sim ... mas c é reutilizável e ...". Em tal sistema limitado, as chances são que você não vai re-uso muito do que o código em um sistema diferente de qualquer maneira. No mesmo sistema, assembler é tão re-utilizável.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow