Por que o Embedded Strictly C / C ++ [fechado]

15

Não gostei dessa pergunta, pois ela não pode ser facilmente respondida, mas talvez eu possa reformular: "O que impede o Embedded de mudar de idioma?"

Por exemplo, vemos praticamente C / C ++ para incorporado (acho que também ouvi o ADA mencionado antes? Corrija-me se estiver errado)

Mas o que exatamente impede o mundo incorporado de mudar de idioma? Será que C é muito fácil de usar ou simplesmente não existe uma "necessidade" de mudar uma vez que C faz tudo bem?

Isso sempre meio que me deixou perplexo, não que eu esteja reclamando. Como mantê-lo em alguns idiomas mantém as coisas padronizadas. Mas ainda permanece a questão.

Sei que essa é uma pergunta subjetiva, no entanto, minha pergunta principal é "Por que" e não "SE / QUANDO"


fonte
2
Existe uma linguagem de nível superior específica que você gostaria de ver em sistemas embarcados? EDIT: ou melhor, em quais recursos de idioma você está interessado que o C não fornece?
Jon G
1
@ JonL - Há um monte de recursos de baixo nível que eu gostaria que C tivesse. Por exemplo, melhor manipulação de bit / nibble / byte / word dentro de ints grandes. Melhor suporte de segurança, por exemplo, os tipos de recursos que Ada possui.
Rocketmagnet
3
Incorporado é não estritamente C. Aqui são um bando de linguagens de alto nível para sistemas embarcados: electronics.stackexchange.com/questions/3423/...
Kellenjb
1
"Incorporado" tem significados diferentes. Um microcontrolador de 4 bits executando uma torradeira é diferente de uma ECU ou Set Top Box. Esse espectro dificulta sua resposta.
21812 Toby Jaffey
1
E, como esperado, isso foi fechado. Eu esperava que essa pergunta recebesse respostas de alta qualidade e as pessoas trabalhassem para mantê-la como uma ótima pergunta, esse não é o caso. Em vez disso, estamos recebendo muitas respostas que são uma frase que recebe vários votos positivos, temos uma resposta em prosa que tem uma guerra de votos negativos com bandeiras em abundância e as outras respostas geraram mais bandeiras em um dia do que o resto do site combinado . A questão é que, para muitas pessoas, existem muitas respostas certas diferentes sobre por que elas não mudaram.
21412 Kortuk

Respostas:

18

Primeiro de tudo: esqueça "incorporado", pois essa não é uma distinção útil. A propriedade importante é "com recursos limitados". O recurso mais importante é geralmente o tempo; nesse caso, falamos de sistemas em tempo real, mas também pode ser memória ou energia.

  • A adoção de novos idiomas é difícil e rara. Requer treinamento, novas ferramentas e encontrar uma boa maneira de trabalhar com o novo idioma. Isso é caro, especialmente para os primeiros adotantes. Também é um problema de galinha e ovo: sem uma grande base de usuários, não haverá ferramentas e bibliotecas de boa qualidade, mas sem elas não haverá uma grande base de usuários. Portanto, um novo idioma deve ter uma grande vantagem sobre os existentes, caso contrário, não terá chance.

  • A maioria dos novos desenvolvimentos "recentes" em idiomas vem preenchendo a lacuna entre a energia disponível da CPU e o que o usuário precisa. Em outras palavras: eles podem ser ineficientes em velocidade, mas compensam sendo mais fáceis para o programador. Pense na ascensão de linguagens como Java, Python, Perl, Tcl que são essencialmente executadas por um intérprete (talvez após alguma compilação) e faça uso pesado do gerenciamento dinâmico de memória. Mas isso não combina bem com o mundo com recursos limitados, onde queremos obter a) o máximo dos recursos disponíveis, mesmo à custa de mais esforço de programação eb) um uso previsível dos recursos.

  • C e C ++ (ou um subconjunto adequado) ainda são as linguagens de mais alto nível em uso comum (o suficiente para que boas ferramentas, programadores treinados e bibliotecas extensas estejam disponíveis) que atendam aos requisitos previsíveis de espaço e tempo que não estão longe do que é possível no hardware atual. Acho que o único candidato é Ada, mas sofreu um início ruim: as primeiras implementações foram (percebidas como sendo?) Muito lentas e ineficientes, e agora (apesar de boas implementações estarem disponíveis) a linguagem ficou um pouco atrasada recursos (em comparação com C ++). Pessoalmente, acho que é uma pena, outras coisas sendo iguais. Prefiro voar em um avião programado em Ada do que em um que foi feito em C ou C ++.

Wouter van Ooijen
fonte
+1 - boa resposta. Ada parece uma linguagem interessante, existem compiladores Ada para pequenos micros por aí?
precisa
Existe o GNAT, o compilador GCC Ada. Mas o AFAIK não tem sido muito usado em micros, portanto, é difícil encontrar algo que seja lido para executar.
Wouter van Ooijen
Sim, eu vi o GNAT mencionado na página do Wiki. Você está certo, não existe muito para micros pequenos, mas parece haver um bom suporte (como seria de esperar) para itens de missão crítica em 68k, x86, MIPS, etc. (por exemplo, DDCI )
Oli Glaser
Vejo que há SPARK Ada também, como mencionado por Deek abaixo. Vou ter que verificá-la quando eu tenho algumas das coisas que elusiva que eles chamam de tempo ...
Oli Glaser
2
Ada, na forma de Gnat, funciona muito bem no microprocessador AVR, como visto no Arduino. O menor executável do Gnat que construí foi de 65 bytes. É certo que tudo o que fez foi piscar um LED, embora o esboço equivalente do Arduino estivesse acima de 1K. Quando meu executável atingiu 600 bytes, ele estava acionando 2 motores de passo de forma independente ... Você não precisa do SPARK - a menos que queira provar que o pisca-pisca LED está formalmente correto!
Brian Drummond
9

Com sistemas embarcados baseados em microcontroladores de 8 e 16 bits, é mais fácil desenvolver software que possa se encaixar nos recursos limitados dessas limitações de armazenamento muito modestas (talvez alguns 100 bytes de RAM para microcontroladores de 8 bits low-end , com 2-8 KiB de ROM ou EPROM / Flash para armazenamento de código).

Nesses casos, linguagens pequenas como C ou assembly tendem a ser as linguagens de desenvolvimento mais usadas. Como uma comparação relativamente aproximada, um montador completo e um compilador C99 podem caber em um único disquete, enquanto você precisa de vários MiB para um sistema de desenvolvimento C ++ moderno (com STL, etc.).

Quando você olha para micros de ponta ( DSP de 16 bits e principalmente de 32 bits, com 64 bits bastante raros) e DSP em ambientes incorporados, as restrições enfraquecem e o desenvolvimento de software pode constituir a maior parte do desenvolvimento. esforço, portanto, faz sentido usar as ferramentas de desenvolvimento mais produtivas, incluindo linguagens mais avançadas com recursos como linguagens de programação orientada a objetos (OOP), como C ++, e linguagens mais recentes (Java, Perl, Ruby, Python).

É possível, na montagem e C, prever quanta memória está sendo usada, para que um projeto com restrição de espaço seja viável, mas recursos avançados, como modelos, manipulação de exceções e vinculação em tempo de execução, tornam impossível conhecer exatamente o espaço de memória necessário para um programa C ++ padrão antecipadamente. Não sei o suficiente sobre o MISRA C ++ , que é um subconjunto do C ++, para comentar.

Idiomas baseados em máquinas virtuais executando código de bytes (Java, Perl, Python) são menos maduros na experiência do desenvolvedor incorporado e, como esses idiomas são projetados para isolar o programador do hardware específico, também torna mais difícil ter consciência de limitações e restrições do sistema de hardware incorporado. Esse é um problema menor nos processadores rápidos de 32 bits (por exemplo, ARMv7) com MiB, se não com GiB de RAM.

Todas as implementações do BASIC que eu conheço são bastante simplistas nos recursos da linguagem, permanecendo amplamente fiéis ao legado do Dartmouth BASIC dos anos 1960. Isso significa que o idioma não possui bibliotecas de tempo de execução complexas ou manipulação de exceções, e um intérprete ou compilador é bastante simples de escrever e também é pequeno no tamanho do arquivo. A maioria dos microcontroladores tem pelo menos um compilador BASIC disponível para ele.

Espero que descreva de maneira geral os motivos pelos quais você encontrará C e montagem usados ​​principalmente em sistemas embarcados menores ou mais antigos, e com as limitações dos novos sistemas embarcados de médio a alto nível diferem apenas ligeiramente dos computadores pessoais de mesa tradicionais.

mctylr
fonte
5

A maioria das respostas já indicava os motivos históricos (bem conhecido, todo mundo usa, não seria fácil mudar os hábitos, etc.). Embora eu concorde com eles, devemos ter em mente que há outra razão importante.

É não que "C é uma escolha ruim ou desatualizado, mas ainda usá-lo por força do hábito" (como os teclados QWERTY).

O C é, por si só, uma escolha muito boa para o desenvolvimento incorporado, especialmente em aplicativos de tempo crítico. Por quê?

  • é de nível baixo o suficiente para ser facilmente usado para implementar programas em tempo real. Se você precisar medir o tempo em nanossegundos, precisar interromper a cada 5 microssegundos ou usar exatamente 64 bytes de RAM total, então, com uma linguagem de nível muito alto, na maioria das vezes seria impossível ou muito difícil resolvê-lo . C oferece um controle muito melhor sobre o hardware do que as linguagens de nível superior. Essa é uma das diferenças mais importantes entre o desenvolvimento para o incorporado e o PC.

  • é alto o suficiente para ser rápido e fácil de codificar, em comparação com o Assembly.

Portanto, C é o melhor (ou um dos melhores) compromisso entre a velocidade e o acesso direto ao hardware do Assembly, e a fácil leitura e compreensão de linguagens de alto nível.

vsz
fonte
1
Eu acho que um aspecto importante a favor de C é que ele permite otimizar o código para uma plataforma específica, enquanto permite que esse código seja executado (talvez não com tanta eficiência) em outros. Em algo como um PIC, muitas instruções C se traduzem previsivelmente em instruções da máquina; um loop como unsigned char i=63,j=128; do {something;} while(--j); while(--i);não será tão legível quanto unsigned int i=16000; do {something;} while(--i);, mas será executado mais rapidamente e será mais eficiente no PIC. Se o código fosse movido para o ARM, a segunda abordagem seria mais eficiente, mas a primeira ainda funcionaria.
Super12
4

É exatamente a mesma razão pela qual na programação regular as linguagens (mais usadas) não mudam (realmente):

  1. Grande quantidade de código existente (bibliotecas / implementações existentes)
  2. Grande conjunto de ferramentas que pode trabalhar com esses idiomas (IDEs, simuladores, ...)
Sam
fonte
4

No mundo incorporado, pode ser muito mais difícil (ou impossível) fornecer atualizações de software e, portanto, é ainda mais crítico garantir a correção. Infelizmente, C fornece muito pouca ajuda nesse sentido e permite que o programador toque rápido e solto.

Dói-me usar C para sistemas embarcados, e gostaria de pelo menos passar para C ++ pelos muitos benefícios que ele oferece na forma de restrições como const, referências, digitação por stringer, etc.

Acho que a resposta é simplesmente que estamos presos a C porque a mudança não é comercialmente viável. Todo mundo conhece C, existem muitos compiladores, bibliotecas e ferramentas para gerá-lo. Com um novo idioma, estaríamos começando do zero.

Eu acho que é por isso que as pessoas ainda usam PHP .

Martelo de garra dupla PHP.

Rocketmagnet
fonte
Se você quiser discutir a pergunta, use comentários ou meta, se desejar dar um tapinha nas costas do usuário para uma boa pergunta, com uma votação positiva ou comentário.
Kortuk
Você sempre pode usar Pascal - parece ter as limitações adicionais que você está procurando :-). Ou alguma forma de Super-Lint.
Russell McMahon
2
Uma razão provavelmente muito significativa para C é que é MUITO mais fácil escrever um compilador C básico do que um compilador C ++. Trabalhei em um por um tempo antes de tarefas mais importantes me afastarem. Coisas divertidas! Escrevendo um compilador C ++? Ugh. Eu prefiro C ++ como usuário.
51112 darron
1
@RussellMcMahon - Não consigo usar o Pascal, porque não existe um compilador Pascal para os MCUs que estou usando.
Rocketmagnet
@ Darron - Esse é um ponto muito bom. No entanto, existem muito bons compiladores C ++ de código aberto, como o gpp. Eles só precisariam escrever um back-end para isso.
Rocketmagnet
4

Ninguém aqui ouviu falar do SPARK Ada?

Esta é uma versão "pequena" da linguagem Ada e ferramentas de desenvolvimento relacionadas para sistemas embarcados, por exemplo, aviônicos e outras aplicações críticas de segurança, como equipamentos médicos.

Os estudos mostram apenas uma perda de 5 a 10% na velocidade de processamento em comparação com o C / C ++ com a codificação SPARK mais confiável.

Eu acho que a proliferação de C em sistemas embarcados se deve a razões econômicas:

  • Ele já está lá e geralmente é viável para a maioria das aplicações - e a maioria das aplicações em volume não é crítica, ninguém morrerá se a máquina de lavar roupa se exceder - então por que mudar?

  • O conjunto de ferramentas SPARK será uma despesa adicional por si só e para a equipe de treinamento usá-lo.

  • Os benefícios adicionais do SPARK (ou de outras línguas não C) ao sistema de controlador / gerenciamento incorporado podem não ser suficientes para justificar o prêmio necessário no preço do produto aos olhos do consumidor - especialmente quando eles veem marcas rivais aparentemente "boas" vendendo por um preço mais baixo.

  • A empresa AdaCore tem o cuidado de não se aprofundar nas aplicações do mercado de massa, pois elas inevitavelmente exigirão um grande aumento na equipe de suporte técnico para lidar com questões não essenciais. A AdaCore é uma empresa de alto nível especializada, orgulha-se como tal e lança seus produtos e serviços em empresas de alta tecnologia. É incomum um idioma penetrar em novos mercados, a menos que seus principais interessados ​​realmente desejem.

Então, @ Wouter, você não precisa se preocupar em morrer nos céus por falta de código incorporado Ada!

Já está nos sistemas de aviões há muitos anos. O mesmo para o seu marcapasso.

Mas para a máquina de lavar louça, o sistema de controle de serviços de construção, o controlador de fornos de laboratório e outras arenas não tão rigorosamente regulamentadas - vale a pena ir além da economia?

Deek
fonte
Interessante, obrigado - eu não tinha ouvido falar do SPARK, vai dar uma olhada.
Oli Glaser
Alguns estudos mostram uma aceleração em relação a um aplicativo existente em C - veja o servidor DNS "Ironsides" ...
Brian Drummond
3

Eu acho que o principal motivo da popularidade do C é o primeiro: o C é popular e muitas pessoas o conhecem e o segundo: nenhuma das novas linguagens populares como Java, C # e até muitos aspectos do C ++ são adequadas para o trabalho incorporado. Basicamente, as três outras linguagens que mencionei dependem muito da memória dinâmica, que traz execução não determinística do programa, objetos, que trazem memória dinâmica com eles, grandes requisitos de memória (já que um dos lados mais importantes do OO é o uso de maior número de classes), a crescente popularidade da compilação just in time (e muitas plataformas incorporadas nem sequer conseguem compilar seu próprio código C) ...

Também existe o fato de que muitas das bibliotecas fornecidas com Java ou C # são inúteis para um grande número de projetos incorporados.

Por outro lado, temos idiomas mais antigos, como Pascal ou Basic. Do meu ponto de vista, eles não são tão populares porque C se tornou a linguagem "padrão do setor" e um número muito grande de programadores e engenheiros aprendem C hoje. Em algumas escolas, Pascal ou Basic nem sequer são aprendidos. Também existe o fato de que muitas linguagens populares hoje em dia têm sintaxe do tipo C e o uso do Pascal seria estranho para um programador de C.

Quanto ao FORTRAN, bem, acho que ele entrou em um nicho de campo e é usado principalmente por engenheiros e cientistas que trabalham em áreas onde existe um ecossistema adequado para seu uso. Não vejo nenhum motivo específico (além dos mencionados para Pascal e Basic) que não é usado em sistemas embarcados.

Observe que nesta resposta eu me concentrei principalmente em sistemas menores. Também existem muitos dispositivos embarcados que usam sistemas operacionais mais complexos, como GNU / Linux ou algum outro derivado do Unix, e para programá-los, mais ou menos qualquer linguagem popular pode ser usada.

AndrejaKo
fonte
1
C é popular porque C é popular? :-)
stevenvh
2
@stevenvh Sim, isso é verdade. É uma espécie de loop de feedback positivo. Quanto mais popular, mais popular fica.
precisa saber é o seguinte
3

C é uma linguagem muito simples e já foi mencionada em mais de uma ocasião como linguagem assembly sofisticada . É quase a quantidade mínima de abstração que você pode fornecer acima do código de montagem, pois as construções C são mapeadas diretamente nas construções no nível da máquina.

Por esse e vários outros motivos, é muito fácil implementar um compilador C em um novo chip. Muito do trabalho já está feito, há relativamente pouca complexidade ou coisas que dão errado, e o controle de baixo nível permite que você lide facilmente com quaisquer peculiaridades do seu hardware.

O C ++ pode ser (na verdade originalmente foi) implementado como uma camada de tradução de código-fonte sobre C, o que significa que você obtém C ++ (ou pelo menos uma versão dele) gratuitamente com seu compilador C.

Com C e C ++, você faz um bootstrap praticamente de tudo o que precisa para seu novo chip, tornando-o o local lógico para começar.

tylerl
fonte
3

Alguns motivos pelos quais os outros não mencionaram:

  • Espaço do problema: C é adequado para sistemas pequenos e simples. Se tudo o que você faz é reagir a sinais externos e pressionar alguns números, então C funciona bastante bem (sem estruturas de dados complexas, sem malloc, sem manipulação de erros complexa).

  • Volume de produção: se você tiver grandes execuções de produção, é economicamente sensato economizar em cada unidade de hardware e gastar mais em programadores, porque a programação é um custo único.

starblue
fonte
2

Eu acho que é porque C / C ++ são as linguagens de nível mais baixo e mais alto.

Amit Tomar
fonte
1

De fato, para pequenos sistemas embarcados, o C é muito mais popular que o C ++. E o motivo disso é o mesmo que não usar outros idiomas. O C ++ requer um tempo de execução, a menos que você ofereça a maioria dos recursos que o tornam diferente de C.

Além do assembly, C é o único idioma que eu sei que compila para o código nativo e para o qual ter um tempo de execução é opcional. Portanto, é garantido o menor espaço ocupado e o menor tempo de execução em um ambiente restrito (exceto se você usar montagem).

Por outro lado, em sistemas embarcados médios e grandes (com o que quero dizer mais memória e relógio, tamanho de palavra maior), não diria que C (ou C ++) é tão prevalente. Eu já vi sistemas suportando Python, Forth ... até Java.

Mas é claro que você quase sempre tem a opção de usar C / C ++, obviamente, pelas mesmas razões que mencionei acima. E tendo a opção e sendo você alguém que já se sente confortável com o C para pequenas embarcações, por que você escolheria outro idioma?

fceconel
fonte
4
O C ++ pode gerar muita sobrecarga, mas o compilador C ++ totalmente compatível que usei para o MSP430 não exigia um tempo de execução, o C ++ compilou no código nativo. Sinto muito, dizer aos outros é um desserviço e eu diminuí o voto. Você pode remover o voto negativo fornecendo referências que me convencem de que estou incorreto (o que será difícil, li a lista de montagem do C ++ compilado para meus projetos, parte para garantir uma compilação eficiente) ou você pode excluir sua resposta, o que removerá o efeito em sua reputação (embora neste momento você receba +8 rep net) #
Kortuk
3
Concordo plenamente com Kortuk. Algumas partes do C ++ exigem amplo suporte em tempo de execução, mas a parte que não é ainda um C muito melhor (e totalmente OO). A restrição a esse subconjunto é facilmente imposta por algumas opções de compilador e vinculador. Em algumas partes (o printf temido por exemplo) C ++ tem pelo menos o potencial linguagem a necessitar de apoio muito menos tempo de execução (se apenas std :: cout foram implementados com pequenos sistemas em mente ...)
Wouter van Ooijen
1
@ Kortuk, desculpe por não estar claro lá, mas quando eu disse que "C é a única linguagem que ..." não significava que C ++ não tem essas duas coisas, eu quis dizer que C tem a combinação dos dois e C ++ tem um deles. Minha ênfase estava na parte do tempo de execução. Também não estou dizendo que é completamente impossível usar C ++ sem tempo de execução, mas é bastante incomum. Não vejo como é possível ter coisas como manipulação de exceção e RTTI sem tempo de execução, por exemplo, e esses são recursos muito importantes. Mas peço desculpas se a maneira como expressei isso levou a possíveis equívocos.
Fceconel 5/07
@fceconel, nunca usei C ++ com um ambiente de tempo de execução, e estamos discutindo sistemas embarcados aqui, nunca usei um tempo de execução em meus microcontroladores. Esta questão é um pouco diferente do que você já deve ter lido, está perguntando por que C / C ++ são as únicas opções predominantes, não por que C em vez de C ++. Admito que, usando algo tão simples como cout nunca acontecerá no meu micro, tenho alguns pinos gratuitos, não uma tela.
Kortuk