Vantagens dos microprocessadores de 32-48 Mhz de 48 bits (como no Arduino Due)

10

Parece que o Arduino Due (SAM3X8E baseado em ARM-Cortex-M3 de 32 bits, 84 Mhz) foi lançado hoje.

Além disso, claramente há uma infinidade de processadores nessa categoria (32 bits / 48-96 Mhz / ARM), bem como placas de prototipagem correspondentes:

  • NXP LPC1768 / mBed
  • STM32 / Discovery
  • PIC32 / ChipKit
  • Hélice PIC32 / Parallax
  • Barra de ativação LM4F120 / TI
  • etc.

Estou tentando entender o apelo desses microprocessadores "intermediários", que para mim parecem estar entre o AVR / MSP430 / etc de baixo custo. (profissionais: barato, de baixo consumo de energia, tamanho reduzido) e o ARM7 / etc de alta qualidade (profissional: capaz de obter instruções muito maiores por segundo).

Em que situações ou maneiras os microprocessadores baseados em 32 bits / 48-96 Mhz / ARM são uma escolha adequada? Mais especificamente, pergunto-me em quais aplicativos ou em quais parâmetros eles seriam uma escolha superior durante o projeto, tanto nos microcontroladores de 8 bits de ponta quanto nos processadores ARM7 de ponta alta.

Thomas E
fonte
Bem, em primeiro lugar, na minha opinião, você pode processar fluxos de vídeo ao vivo - onde o Arduino não pode lidar com isso. Ele também permite algoritmos de criptografia avançados ou hash (mais rápido e fácil do que no Arduino). Surpreende-me que o Arduino tenha lançado uma plataforma de 32 bits, mas apenas mostra a você - Algumas pessoas só querem fazer mais do que controlar um relé. É um ótimo dia para o Arduino!
Piotr Kula
Você não fará mais que o processamento trivial de vídeo ao vivo em um processador <100 MHz, a menos que faça isso em um núcleo de função especial anexado. E, especialmente, não na RAM on-board bastante limitada desses dispositivos. Um ponto mais realista é que o custo desses chips não é substancialmente mais alto do que o de peças de 8 bits; pode ser realmente menor do que um ATMEGA com flash e ram comparáveis.
Chris Stratton
3
Até onde eu sei, o Parallax Propeller é um chip personalizado sem relação com o PIC32. Alguma fonte de conexão?
precisa saber é o seguinte

Respostas:

12

Este é um daqueles assuntos que podem se tornar altamente debatidos. Existem muitos pontos de vista diferentes, e coisas diferentes são importantes para pessoas diferentes. Vou tentar dar uma resposta abrangente, mas entendo que sempre haverá alguém que discorda. Apenas entenda que aqueles que discordam de mim estão errados. (Só brincando.)

Resumo rápido:

Essa resposta será longa, então deixe-me resumir isso com antecedência. Para a grande maioria das pessoas, a última safra de chips ARM Cortex-M0 / M3 / M4 oferece a melhor solução, os melhores recursos pelo custo. Isso é verdade mesmo ao comparar esses MCUs de 32 bits com seus ancestrais de 8 e 16 bits, como o PIC e o MSP430s. Os M0 podem ser comprados por menos de US $ 1 / cada e os M4 por menos de US $ 2 / cada, portanto, exceto pelas aplicações muito sensíveis ao preço, as soluções ARM são muito agradáveis. Os M0 são de potência muito baixa e devem ser bons o suficiente para a maioria das pessoas. Para aqueles que são muito sensíveis à energia, o MSP430s ainda pode ser uma escolha melhor, mas vale a pena considerar os M0s mesmo para essas aplicações.

Se você estiver interessado em uma análise mais aprofundada, continue lendo, caso contrário, poderá parar de ler agora.

Agora, examinarei cada área e compararei os diferentes MCUs:

Velocidade de Execução

É claro que os MCUs de 32 bits serão mais rápidos. Eles tendem a ter uma velocidade de clock mais rápida, mas também trabalham mais para cada um desses relógios. MCUs como o ARM Cortex-M4 incluem instruções de processamento DSP e podem até ter suporte a ponto flutuante no hardware. As CPUs de 8 e 16 bits podem operar em números de 32 bits, mas não são eficientes. Fazer isso consumirá rapidamente registros da CPU, ciclos de clock da CPU e memória flash para armazenamento do programa.

Facilidade de Desenvolvimento

Na minha opinião, esse é o motivo mais valioso para o uso de MCUs modernos de 32 bits - mas também o mais subestimado. Deixe-me primeiro comparar isso com os PICs de 8 bits. Esta é a pior comparação de casos, mas também a melhor para ilustrar meus pontos.

Os PICs menores exigem basicamente que a programação seja feita em linguagem assembly. É verdade que existem compiladores C disponíveis até para as PICs de 8 bits, mas esses compiladores são gratuitos ou bons. Você não pode obter um compilador que seja bom e gratuito. A versão gratuita do compilador é prejudicada, pois sua otimização não é tão boa quanto a versão "Pro". A versão Pro custa aproximadamente US $ 1.000 e suporta apenas uma família de chips PIC (chips de 8, 16 ou 32 bits). Se você quiser usar mais de uma família, precisará comprar outra cópia por outros US $ 1.000. A versão "Padrão" do compilador faz um nível médio de otimização e custa cerca de US $ 500 para cada família de chips. Os PICs de 8 bits são lentos para os padrões modernos e exigem boa otimização.

Por comparação, existem muitos bons compiladores C para MCMs ARM gratuitos. Quando existem limitações, esses limites geralmente estão no tamanho máximo da memória Flash suportada. Nas ferramentas Freewale Codewarrior, esse limite é de 128 KB. Isso é suficiente para a maioria das pessoas neste fórum.

A vantagem de usar um compilador C é que você não precisa se preocupar (tanto) com os detalhes de baixo nível do mapa de memória da CPU. A paginação no PIC é particularmente dolorosa e é melhor evitar, se possível. Outra vantagem é que você não precisa se preocupar em entregar números de 16 e 32 bits em um MCU de 8 bits (ou números de 32 bits em um MCU de 16 bits). Embora não seja muito difícil fazer isso na linguagem assembly, é uma dor na parte traseira e é propenso a erros.

Existem outros compiladores não-ARM C que funcionam bem. O compilador MSP430 parece fazer um trabalho razoável. As ferramentas Cypress PSoC (especialmente PSoC1) são de buggy.

Modelo de memória plana

Um MCU que paginou RAM / registradores / Flash é simplesmente estúpido. Sim, estou falando dos PICs de 8 bits. Burro, burro, burro. Isso me afastou tanto dos PICs que eu nem me preocupei em olhar para as novidades deles. (Isenção de responsabilidade: isso significa que os novos PICs podem ser aprimorados e eu simplesmente não o conheço.)

Com um MCU de 8 bits, é difícil (mas não impossível) acessar estruturas de dados maiores que 256 bytes. Com um MCU de 16 bits, aumenta para 64 kbytes ou kwords. Com MCUs de 32 bits que vão até 4 gigabytes.

Um bom compilador C pode esconder muito disso do programador (você também conhecido como You), mas mesmo assim afeta o tamanho do programa e a velocidade de execução.

Existem muitos aplicativos MCU para os quais isso não será um problema, mas é claro que existem muitos outros que terão problemas com isso. É principalmente uma questão de quantos dados você precisa (matrizes e estruturas) na RAM ou no Flash. Obviamente, à medida que a velocidade da CPU aumenta, aumentam as chances de usar estruturas de dados maiores!

tamanho do pacote

Alguns dos PICs pequenos e outros MCUs de 8 bits estão disponíveis em pacotes realmente pequenos. 6 e 8 pinos! Atualmente, o menor ARM Cortex-M0 que eu conheço está em um QFN-28. Enquanto um QFN-28 é pequeno o suficiente para a maioria, não é pequeno o suficiente para todos.

Custo

O PIC mais barato custa cerca de um terço do preço do ARM Cortex-M0 mais barato. Mas isso é realmente US $ 0,32 vs. US $ 0,85. Sim, essa diferença de preço é importante para alguns. Mas eu afirmo que a maioria das pessoas neste site não se importa com essa pequena diferença de custo.

Da mesma forma, ao comparar MCUs mais capazes com o ARM Cortex-M0 / M3 / M4, geralmente o ARM Cortex sai "aproximadamente uniforme" ou no topo. Ao considerar as outras coisas (facilidade de desenvolvimento, custos do compilador, etc.), os ARMs são muito atraentes.

Segundo Resumo

Eu acho que a verdadeira questão é: Por que você NÃO usaria um ARM Cortex-M0 / M3 / M4? Quando o custo absoluto é super importante. Quando o consumo de energia super baixo é crítico. Quando é necessário o menor tamanho de embalagem. Quando a velocidade não é importante. Mas para a grande maioria dos aplicativos, nada disso se aplica e o ARM é atualmente a melhor solução.

Dado o baixo custo, a menos que haja um bom motivo para não usar um ARM Cortex, faz sentido usá-lo. Isso permitirá um tempo de desenvolvimento mais rápido e fácil, com menos dores de cabeça e margens de projeto maiores do que a maioria dos outros MCUs.

Existem outros MCUs não ARM Cortex de 32 bits disponíveis, mas também não vejo nenhuma vantagem neles. Há muitas vantagens em usar uma arquitetura de CPU padrão, incluindo melhores ferramentas de desenvolvimento e inovação mais rápida da tecnologia.

Obviamente, as coisas podem e mudam. O que eu digo é válido hoje, mas pode não ser válido daqui a um ano ou até um mês. Faça sua própria lição de casa.


fonte
11
Para acessar qualquer local de memória com o ARM, é necessário primeiro carregar um registro com um endereço dentro de 4K; Muitos dispositivos de E / S são alocados com mais de 4K de espaço de endereço, embora muitos usem apenas alguns endereços discretos. Por outro lado, os PICs 18Fxx podem operar diretamente na maioria dos locais de E / S com uma única instrução, independente do estado do banco. O meio pelo qual a maior parte da RAM é depositada é bastante irritante, mas para certos tipos de troca de bits (o objetivo para o qual a arquitetura PIC foi projetada na década de 1970), a arquitetura PIC funciona muito bem.
Supercat 24/10
11
BTW, acho curioso que, enquanto um microprocessador popular de 8 bits da década de 1970 pudesse processar com eficiência estruturas de dados arbitrariamente alinhadas de 256 bytes, e um processador popular de 16 bits funcionasse bem com estruturas de dados de 65.536 bytes alinhadas em 16 limites de bytes ou estruturas de dados alinhadas arbitrariamente, quase que grandes e novos processadores de 8 e 16 bits, dificultam a escrita de códigos eficientes que ultrapassam os limites de páginas / bancos.
Supercat 24/10
@supercat O intervalo de endereços 4K para uma instrução "LDR / SRT Immediate Offset" é verdadeiro, mas geralmente não é um problema. Discordo do resto do seu comentário. Observando os documentos do Freescale M4, cada periférico não ocupa mais de 4K do intervalo de endereços; portanto, um único "ponteiro de endereço base" é suficiente para acessar todos os registros nesse periférico. Há também 32 registros de uso geral, qualquer um dos quais pode ser usado como um ponteiro de endereço base - portanto, acessar vários periféricos rapidamente na mesma seção de código é relativamente indolor.
11
@supercat Seu segundo ponto aborda todo o debate entre RISC e CISC. O ARM é uma CPU RISC, o que significa que está otimizado para executar as tarefas mais frequentes. Tarefas que não são frequentes, como acessos desalinhados, exigem mais trabalho ou demoram mais tempo (dependendo do arco da CPU). Eu vejo isso como algo positivo, não negativo. É por isso que obtemos MCUs rápidos de 32 bits pelo preço de um 8 bits mais antigo. Mesmo com essas peculiaridades, eu usaria uma dessas CPUs em um PIC a qualquer dia.
Eu errei; Eu não pretendia sugerir que um registro base não pudesse lidar com um periférico inteiro, mas sim que um registro frequentemente teria que ser carregado para cada periférico (portanto, não era possível, por exemplo, simplesmente deixar um registro com IO_BASE_ADDR o tempo todo ) Para alguns tipos de código, a capacidade de definir um bit de E / S em um único ciclo com uma instrução como "bsf LATA, 4", sem precisar pré-carregar nenhum registro primeiro, pode ser muito útil. Eu gosto do ARM, mas o mapeamento direto de E / S no PIC pode ser bastante bom (muito ruim o acesso a outras memórias não é tão bom).
Supercat 24/10
3

David Kessner está correto. Eu gostaria de adicionar o seguinte.

  1. As MCUs de 8 bits são as únicas disponíveis em pacotes PDIP, fáceis de manusear e grudar em uma placa de prototipagem.
  2. As MCUs de 32 bits podem realmente usar menos energia que as MCUs de 8 bits. Não é necessariamente verdade que o MCU <20 MHZ de 8 bits consome menos energia que um Cortex M4.
  3. Os MCUs de 8 bits são frequentemente usados ​​por entusiastas que geralmente não exigem muito do MCU. Talvez algumas centenas de linhas de código C simples.

Concordo que hoje em dia há poucas razões para não usar MCUs de 32 bits. Eu os usaria apenas [MCUs de 8 bits] por 2 razões: eu gosto da facilidade do pacote PDIP (não é necessária solda); Geralmente, não preciso de mais poder / complexidade do que o que um MCU de 8 bits pode oferecer.

O disjuntor é realmente as ferramentas disponíveis.

s5s
fonte
Para prototipagem, existem soquetes para o LQFP, que funcionam razoavelmente bem. E, é claro, você pode soldar o LQFP à mão, basta um pouco de prática. QFN, DFN e BGA Eu não soldaria manualmente, mas todos os MCUs low-end de 32 bits no mercado vêm com LQFP.
Lundin
1

Utilizamos um Freescale MCF52259 relativamente fora de moda, um MCU de 32 bits ~ 80Mhz.

As razões / processo de pensamento para a escolha foram:

  • Ele estava substituindo um dispositivo M.Core de 32 bits, portanto, a portabilidade era relativamente simples
  • Também significava que poderíamos continuar com o IDE existente (CodeWarrior)
  • Precisávamos de bastante IO: controle para passo / direção em 3 motores de passo, 4 canais de PWM, 3 UARTs e I2C e SPI.
  • Havia muita coisa acontecendo (veja o último ponto) e algumas delas precisavam acontecer em tempo hábil; portanto, precisávamos ter certeza de que havia ciclos de CPU suficientes para concluir tudo.
  • O código legado estava colidindo com o tamanho do flash de 256k e a 32k RAM do M.Core, então dobrar o flash e a RAM tornou a vida fácil de começar a funcionar rapidamente.

Atualmente, é mais econômico (e conveniente) sobredeclarar / expandir os recursos do hardware (armazenamento, velocidade, E / S, etc.) do que gastar um tempo valioso de desenvolvimento otimizando o código para se transformar em um MCU marginalmente mais barato / menor, a menos que haja espaço ou poder são grandes questões.

No nosso caso, o dispositivo tinha o dobro da especificação do M.Core pela metade do preço, ir para um MCU mais barato economizaria alguns centavos por placa, mas custaria muito tempo de desenvolvimento e limitaria o potencial de desenvolvimento futuro sem alterar os MCUs novamente.

Se estivéssemos construindo um milhão de placas, valeria a pena fazer o exercício de engenharia de custos para reduzir as coisas, mas, como está, não vale o tempo de desenvolvimento.

John U
fonte