Qual é o lugar dos microcontroladores de 8 e 16 bits? Por que 32 bits não assumiu o controle?


9

Qual é o ponto de corte real em termos de compensação entre custo e desempenho para a seleção de microcontroladores de 32 bits?

Em outras palavras, com o surgimento e o domínio das arquiteturas ARM, por que ainda estamos usando microcontroladores de 8 e 16 bits? Eles ainda são muito mais baratos?

Entendo que dispositivos muito simples não precisam dos recursos oferecidos por arquiteturas maiores e mais complexas. No entanto, qual é a verdadeira motivação para continuar a usá-los se os custos parecerem convergir para o mesmo intervalo?


11
Consumo de energia?
Leon Heller

7
O µC de 32 bits mais barato no Digikey que vejo é de cerca de US $ 0,64, o de 8 bits mais barato é de US $ 0,35. Se você é uma grande empresa que vai construir um milhão de widgets simples, é uma grande diferença.
Samuel

@LeonHeller À primeira vista, tenho a tendência de concordar, mas observe o que fiz nos comentários da resposta proposta.
Bruno Morais

2
Olhar até mesmo preços em massa no DigiKey não é um guia brilhante; para micros minúsculos em aplicativos embarcados de baixo consumo de energia que estão sendo produzidos em massa, ninguém os compra do DigiKey e é provável que eles estejam comprando matrizes para não um pacote de chips para soldar em uma placa. Um micro de 8 bits sempre será menor, mais simples, portanto, mais barato e com menor potência do que um de 32 bits de construção equivalente. Sim, a margem está caindo para o ponto de insignificância para muitas pessoas, mas em volumes de massa até 1/10 de um centavo economizado vale a pena.
John

Aqui está um artigo relevante que me deparei no site da Electronic Design: 8 bits ou 32 bits? Escolhendo o MCU do seu próximo projeto
Garth Wilson

Respostas:


17

Talvez um ano atrás, havia uma diferença significativa entre os low-end de 8 bits e os mais baratos de microcontroladores de 32 bits. Não é mais o caso.

Com base nos preços em massa da Digi-Key, você pode obter um PIC10F200 de 8 bits por 35ȼ em quantidades de 2500 em um pacote SOT-23-6. Você obtém um CY8C4013SXI-400 de 32 bits (ARM Cortex-M0) por 36ȼ em 2500 quantidades em um pacote SOIC-8. (O preço em massa da Digi-Key não é realista em termos do que os fabricantes realmente pagam, o que provavelmente é muito menor, mas acho que é válido usá-lo para uma comparação aproximada de preços entre produtos diferentes e quantidades semelhantes.)

Então o OP está certo, eles estão convergindo.

Então, por que os chips de 32 bits não estão sendo mais usados? Bem, como eu disse no meu primeiro parágrafo, essa paridade de preço e tamanho só aconteceu no último ano ou em 18 meses. E eles ainda têm um longo caminho a percorrer antes que haja fichas suficientes para serem competitivos.

Dos 6875 chips ARM disponíveis na Digi-Key, existem apenas quatro em estoque com preços por quantidade inferiores a um dólar. Quatro . Enquanto isso, existem centenas de chips de 8 bits abaixo de um dólar para os engenheiros escolherem.

Mas digamos que houvesse pelo menos algumas dezenas de micros de 32 bits disponíveis. Eles seriam escolhidos automaticamente sobre os de 8 bits?

Primeiro de tudo, você precisa informar os engenheiros. Sempre há muita resistência à mudança. Coisas novas a aprender - do ponto de vista do hardware, aprendendo a incorporar o novo chip em um circuito. Existem novas ferramentas, como programadores em circuito, novos compiladores, etc. Para os engenheiros de firmware, aprendendo a usar um novo conjunto de periféricos e timers (principalmente layouts de registros e significados de bits).

32 bits é bom e tudo isso, mas a menos que seja necessário fazer muita computação pesada, qual é o objetivo? Se você tiver apenas quatro pinos GPIO, acessá-los internamente como um registro de 32 bits não oferece vantagem sobre o uso de um registro de 8 bits.

Eu acho que o consumo de energia sempre será favorável aos micros de 8 bits.

Por exemplo, o PIC10F200 consome 175 µA rodando a 4 MHz e 2v e 100 nA no modo de suspensão. O CY8C4013SXI-400 consome aproximadamente 800 µA funcionando a 4MHz e 2v e 1 uA no modo de suspensão. (A folha de dados do CY8C4013SXI não tinha números para 4 MHz ou 2v, então eu tive que fazer algumas estimativas - a folha de dados diz que ele usa 2 ma @ 6 MHz e 3,3v.)

Assim, o ARM consome 4,5 vezes mais corrente quando acordado e 10 vezes quando dorme. Não parece muito, mas é a diferença entre rodar em uma célula de moeda por 3 meses ou por um ano. (Suponho que ambos os microcontroladores estejam na maioria das vezes fazendo sincronização, atualizando portas etc. e não realizando computação pesada. Se este for o caso, e o micro de 8 bits tiver que fazer muita aritmética de vários bytes por um período prolongado com o tempo, perde parte de sua vantagem.)

É interessante que o ARM consome cerca de quatro vezes mais corrente que o 8-bit e, por sua vez, possui registros internos e caminhos de dados que são quatro vezes maiores. Eu não acho que isso seja uma coincidência. Para o CMOS, o consumo de energia é aproximadamente proporcional ao número de transistores sendo trocados, e o ARM está obviamente fazendo muito mais por instrução executada.

À medida que mais fornecedores de ARM lançam chips de baixo custo, eu não ficaria surpreso se fornecedores como Microchip baixassem ainda mais seus preços. De qualquer forma, com preços mais ou menos iguais, pacotes de tamanho semelhante, mas com muito menos chips de 32 bits para escolher, acho que os microcontroladores de 8 bits ainda estarão disponíveis por algum tempo - principalmente porque você familiarizou dezenas de milhares de engenheiros.


Para o consumo de energia com os modos de suspensão implementados, você também precisará considerar a eficiência do código. Se o MCU acordar por um gatilho, executar algum código e voltar a dormir, o número de tiques necessários para concluir o trabalho será bastante relevante. Eu acho que a maior parte do consumo atual de um MCU vem do oscilador funcionando a toda velocidade. Para fazer o mesmo trabalho que um 32-bit, um 8-bit provavelmente precisará de cerca de cinco vezes a quantidade de ciclos, simplesmente porque eles geralmente têm muito menos código efetivo, mesmo quando fazem aritmética simples.
Lundin

(E isso não é tanto porque eles têm um barramento de dados de 8 bits, mas, principalmente, porque todos os principais 8-bitters do mercado têm antigos projetos do núcleo da CPU dos anos 70 e 80.)
Lundin

11
@Lundin eu digo isso na minha resposta - se o 8-amargo tiver que fazer muita matemática sofisticada no ISR, ele ainda perderá parte de sua vantagem. Mas se for apenas definir alguns sinalizadores ou atualizar um registro, será mais eficiente.
tcrosley

5

Três pontos principais:

  • Preço
  • Tamanho
  • Consumo de energia

50 ¢ quando você está comprando 10.000 fichas, é bastante dinheiro. Ainda mais quando você está comprando 100.000 chips.

Você pode obter chips de 8 bits consideravelmente menores que os de 32 bits, como o PIC10, disponível em um pacote SOT23-6.

Os chips de 32 bits, porque geralmente têm um clock mais rápido e consomem mais, consomem muito mais energia do que um pequeno chip de 8 bits. As baterias descarregam mais rapidamente, os sistemas de energia precisam fornecer mais corrente (e, portanto, ser mais dispendiosa) etc.

Afinal, por que você compraria um juggernaut para tomar um copo de açúcar ao lado?


2
Basta comparar dois chips do mesmo fabricante - por exemplo, o PIC18F25K20 e o PIC32MX250F512 da Microchip. Ambos os MCUs modernos. Ambas as folhas de dados têm Idd x velocidade do relógio. O gráfico de 8 bits chega a 5mA, o de 32 bits chega a 20mA. Se você pensar bem, uma operação de 8 bits faria algo com 8 travas - uma de 32 bits faria o mesmo (ou equivalente) a 32 travas. São 4 vezes as travas que precisam ser manipuladas, portanto, 4x o consumo de corrente típico.
Majenko

2
A corrente inativa para os 32 bits está entre ~ 0,5mA e 7mA. O gráfico de 8 bits para corrente inativa é medido na escala µA e atinge 7 µA - meros 4 µA ao operar em temperatura ambiente normal ...!
Majenko

3
Desenterrar algumas folhas de dados e procurar por si mesmo.
Majenko

2
Isso pressupõe que tudo o que o chip está fazendo é o processamento. As coisas demoram um tempo que não dependem da velocidade do chip, como a leitura de dados de sensores externos, etc. Uma CPU de 80MHz de 32 bits não lê um dispositivo I2C de 100KHz mais rápido do que uma CPU de 16MHz e 8 bits.
Majenko

3
Não se esqueça do software legado (especialmente para sistemas que exigem certificação) e da familiaridade do desenvolvedor, seleção de componentes periféricos / RAM / flash (um design de microcontrolador com um processador de alto desempenho usará mais área de chip para memória; um Cortex-M com 256 bytes de RAM parece improvável em breve) e opções de pacote / tensão. Uma boa resposta também deve explicar por que o mercado de 16 bits não está indo melhor (e os ISAs de 8 bits mais modernos, como o AVR) e por que o mercado de 4 bits é aparentemente muito restrito (relógios e o que mais?).
Paul A. Clayton

2

Os aplicativos da uC que desenvolvi para produtos comerciais quase nunca lidavam com tamanhos de dados maiores que 8 bits; portanto, mesmo que 32 bits amarelos tenham o mesmo preço que 8 bits amarelos, ainda assim não haverá benefício. Como alguém disse, procuramos o que é familiar, para que possamos dar um soco mais rapidamente. O último que desenvolvi, no entanto, acabou levando o PIC16 que eu costumava ao limite em todos os aspectos - mas isso não foi por causa do tamanho dos dados. Se eu fizer mais assim, realmente devo aprender o ARM.


Eu diria que, para a maioria das pequenas aplicações micro, o maior tamanho de dados necessário seria 16 bits ou talvez 24. A maioria dos aplicativos não precisará fazer muito com coisas maiores que 8 bits, mas precisará fazer alguma coisa. Por outro lado, quase todos os microcontroladores de 8 bits já feitos (se não absolutamente todos) têm um sinalizador de transporte que possibilita o uso de uma sequência de operações para executar um de 16 bits (ou até maior).
Supercat 5/14

2

Eu esperaria que os chips ARM assumissem a maioria das funções em que algo se comporta como um "computador". Por outro lado, muitos microcontroladores de 8 bits se acostumam a fazer coisas que poderiam ser feitas com um dispositivo lógico programável relativamente simples ou com um número moderado de portas, mas que na verdade podem ser mais baratos e / ou com menor consumo de corrente usando um micro de 8 bits simples. Ao projetar aplicativos mais complicados, geralmente é mais fácil usar um micro de 32 bits do que um de 8 bits, mas se todo o objetivo de um chip é, por exemplo, observar e debitar uma determinada entrada e, se for alta, começar a produzir 200 pulsos em uma determinada saída em intervalos de 1ms, depois 100 em 2ms, depois 100 em 3ms, pausar por 100ms e continuar fazendo isso até que a entrada fique baixa, projetar o código para isso pode ser realmente mais fácilem um micro de 8 bits do que em um de 32 bits. A diferença de custo entre micros de 8 e 32 bits pode não ser mais suficiente em muitos casos para justificar o esforço adicional de engenharia para tornar um projeto "adequado" a um micro de 8 bits, mas nos casos em que uma parte de 32 bits não para economizar qualquer esforço de engenharia, não há razão para gastar nem um centavo a mais.


Concordo, mas ressalto que manter e manter o domínio de duas cadeias de ferramentas envolve esforço de engenharia próprio.
Scott Seidman

2
@ScottSeidman: Verdadeiro. Por outro lado, também vale a pena mencionar que alguns micros de 8 bits podem começar a executar código quase imediatamente na inicialização, enquanto os micros de 32 bits que eu vi demoram um pouco mais.
supercat

Gostaria de saber se algum dia veremos a licença do ARM em plataformas de 8 bits. Existem alguns recursos maravilhosos das implementações do ARM, como a capacidade de simplesmente não sincronizar periféricos e barramentos inteiros, que devem fazer o ARMS de 8 bits rodar em torno de outras plataformas em termos de potência. Se os mfct fazem bibliotecas compatíveis com CMSIS, acho que acabariam com os grandes players.
Scott Seidman

@ScottSeidman: Na verdade, o que eu gostaria de ver seriam projetos que podem ter partes sensíveis a temporização de periféricos (por exemplo, temporizadores, geradores de taxa de transmissão, etc.) executadas com uma base de tempo constante, independente da velocidade da CPU , mas vi apenas um suporte mínimo para esse conceito. Não seria difícil em silício, mas eu acho que as ferramentas de síntese carecem dos meios para fazer essas coisas com eficiência.
Super dec

@supercat Não tenho certeza sobre outros microcontroladores, mas o PIC32 tem o conceito de um relógio de barramento periférico que pode ser configurado para uma velocidade de clock diferente do relógio principal. Então você pode mudar a velocidade da CPU, por exemplo, para economizar energia, e ainda manter o mesmo relógio PB para que você não tem que reprogramar todas as suas taxas de transmissão periféricos etc.
tcrosley

1

Embora eu concorde que o custo da CPU e o consumo de energia sejam os principais motivos, mais uma consideração que ainda não vi listada aqui é o espaço para PCB. Para muitos tipos de sistemas embarcados, como, por exemplo, uma balança eletrônica de banheiro, não há muita necessidade de grande quantidade de E / S, nenhum benefício para um tamanho de barramento maior e nenhum benefício para um processamento mais rápido. No entanto, não éum benefício para um pacote menor com menos pinos, pois torna o layout e o roteamento de uma placa de circuito impresso mais simples e, geralmente, menores. Se uma placa puder ser projetada como uma placa de 2 camadas em vez de uma placa de 4 camadas, haverá uma economia de custos considerável, e as contagens menores de pinos que geralmente vêm com processadores de 8 bits tendem a facilitar essas economias mais facilmente do que 32 processadores de bits que geralmente têm mais pinos e pacotes fisicamente maiores.


Você percebe que esta é uma pergunta de 2 anos e meio, certo?
precisa saber é o seguinte

@Olin Outro ponto de vista não dói.
precisa saber é o seguinte

@OlinLathrop: sim, meu relógio / calendário de CPU de 8 bits está funcionando bem. :)
Edward

0

Mesmo no mundo de 8 bits, sabe-se que os tipos mais novos demoram muito tempo para assumir o controle dos tipos mais antigos - veja o MCS51 ainda vivo em seus nichos e o MCS48 ainda em locais inesperados.

Em muitos casos, a mudança não ocorre porque não traz valor adicional e vem com o custo de aprender uma nova tecnologia que ainda não provou estar lá para ficar e / ou espera-se que ainda seja um alvo em movimento (o que torna é interessante para as pessoas que desejam se concentrar na tecnologia MCU, mas irritante para as pessoas que desejam se concentrar em seus aplicativos e não constantemente consertam e testam novamente o software de produção para adaptar o vintage ARM deste ano!). Para alguns, um componente que não é mais desenvolvido é obsoleto, para outros finalmente se tornou estável e, embora possa precisar de soluções alternativas para erros encravados, ele pelo menos fornece uma plataforma estável para eles. O fluxo de lava nem sempre é o antipadrão em que está rachado - tende a fazer com que as montanhas fiquem no lugar certo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.