NXP i.MX · Rockchip RK3588 · Qualcomm QCS6490

Plataformas ARM Mini-ITX para controlo incorporado, visão computacional e IA de ponta

Compare as plataformas ARM em termos de controlo em tempo real, maturidade do BSP, pipeline de câmara, E/S industrial, capacidade da NPU e suporte de software de produção.

  • i.MX 93 · 0,5 TOPSLinux + Cortex-M33
  • i.MX 8M Plus · 2,3 TOPSISP duplo + Cortex-M7
  • RK3588 / QCS64906 TOPS / até 12 TOPS
Comparar SoCs ARM Verificar os meus requisitos do ARM
Plataforma ARM Mini-ITX para controlo incorporado, visão artificial e IA de ponta

Comparação de SoC da ARM

Escolha o SoC com base na função do sistema, e não apenas nos TOPS

As plataformas ARM diferem no que diz respeito aos núcleos em tempo real, ao processamento de imagem, às interfaces industriais, ao software dos fornecedores e às cadeias de ferramentas de aceleração. A melhor escolha é o SoC cujos recursos nativos reduzem a complexidade da placa e o risco associado ao software.

Plataforma Recursos essenciais Melhor ajuste Escolha outra plataforma quando
NXP i.MX 93 2× Cortex-A55 a 1,7 GHz · Cortex-M33 a 250 MHz · 0,5 TOPS Gateways orientados para o controlo, IHM, medição, E/S remotas, aprendizagem automática leve Precisas de uma aceleração gráfica mais potente ou de multimédia mais exigente
NXP i.MX 8M Plus 4× Cortex-A53 a 1,8 GHz · Cortex-M7 a 800 MHz · 2,3 TOPS Visão industrial, juntamente com controlo determinístico, CAN FD, TSN e funcionamento com duas câmaras É necessário um desempenho substancialmente superior da CPU, GPU e NPU
Rockchip RK3588 4× Cortex-A76 + 4× Cortex-A55 · 6 TOPS Múltiplos ecrãs, conteúdos multimédia de classe 8K, processamento de imagem e IA local O coprocessamento industrial em tempo real ou a política relativa ao ciclo de vida dos fornecedores constituem a principal restrição
Qualcomm QCS6490 CPU de 8 núcleos até 2,7 GHz · até 12 TOPS · até 16 GB de LPDDR5 IA multicâmara conectada, robótica e sistemas de ponta de alta integração É necessária uma BSP mais simples e orientada para o controlo ou a gestão nativa de CAN/TSN

Linux · RTOS · BSP

Na ARM, a pilha de software faz parte da decisão relativa ao hardware

O bootloader, o kernel, a árvore de dispositivos, o firmware da GPU/NPU, os controladores da câmara e o código do RTOS determinam se as interfaces de uma placa ARM funcionam de forma fiável em produção.

Área O que congelar Porque é que é importante
Linux / Android Ramo do kernel/BSP, correções, controladores, árvore de dispositivos, módulos Uma atualização pode alterar o comportamento das interfaces PCIe, USB, MIPI e Ethernet, bem como o comportamento de suspensão/retoma ou de arranque
Domínio em tempo real Propriedade de periféricos, imagem do RTOS, watchdog, método de comunicação entre processos (IPC) O i.MX 93 permite combinar o Linux no A55 com o controlo do M33; o i.MX 8M Plus permite combinar o Linux com um M7 a 800 MHz
Tempo de execução da IA / Câmara Compilador/ambiente de execução da NPU, pilha ISP, controladores de sensores, percurso de conversão de modelos O TOPS tem pouco valor se os operadores, sensores ou fluxo de trabalho de câmaras necessários não forem suportados
Imagem de produção Bootloader, sistema de ficheiros, configuração, imagem de recuperação, pacote de atualização As revisões de hardware devem manter-se compatíveis com a versão de referência do software lançada

Câmara · ISP · CAN · TSN

Utilizar interfaces ARM nativas sempre que estas permitam eliminar controladores adicionais

Os SoCs da ARM atingem o seu máximo potencial quando as suas interfaces nativas para câmara, em tempo real e industriais se adaptam ao produto. Isto permite reduzir o número de dispositivos de ponte, o consumo de PCIe, a área ocupada na placa e a complexidade dos controladores.

Recurso Referência numérica / padrão Valor de seleção
Câmara i.MX 8M Plus 2× MIPI CSI · ISP duplo · até 12 MP · até 375 MPixels/s Útil quando é necessário que duas trajetórias de câmara e o processamento local de imagens coexistam com o controlo em tempo real
Câmara QCS6490 Direção da plataforma multicâmaras · até 4 MIPI CSI nas implementações atuais Útil para sistemas de visão conectados, em que a integração de câmaras, IA e tecnologia sem fios é predominante
CAN FD Carga útil de até 64 bytes, contra 8 bytes no CAN clássico Reduz a sobrecarga do protocolo quando são necessárias mensagens industriais ou de veículos de maior dimensão
ISO 11898-1:2024 Referência sobre a ligação de dados e a codificação física do CAN Utilizar como referência de protocolo; o transceptor, o isolamento, a terminação e a compatibilidade eletromagnética (EMC) continuam a ser decisões a tomar ao nível da placa
TSN / IEEE 1588 Sincronização de tempo assistida por hardware, quando suportada Verificar o MAC/PHY, o controlador, a pilha PTP, a topologia do comutador e a precisão de temporização medida

Seleção da camada física RS-232 / RS-422 / RS-485 → Seleção de uma plataforma preparada para IA após a definição do percurso da câmara →

Arranque Seguro · OTA · Ciclo de vida

Congelar o contrato de software-hardware da ARM antes da produção

Cadeia de arranque segura

Defina quais as chaves que assinam o bootloader, o kernel, a árvore de dispositivos, o firmware e o pacote de atualização. As funcionalidades de segurança da plataforma só são eficazes quando toda a cadeia é implementada e mantida.

Atualização e recuperação

Utilize um procedimento definido de reversão ou recuperação, para que uma atualização OTA mal sucedida ou uma falha de energia não impeça o arranque de um equipamento sem supervisão.

Manutenção do BSP

Atribuir a responsabilidade pelas CVEs do kernel, pelas correções do bootloader, pelo firmware da GPU/NPU, pelo firmware sem fios e pelas atualizações do BSP dos fornecedores ao longo de todo o período de suporte.

Controlo de revisões do quadro de administração

As substituições de memória, armazenamento, PMIC, PHY, módulo sem fios e câmara devem continuar a ser compatíveis com o BSP e a imagem de recuperação já lançados.

Validar em conjunto o software de arranque, de recuperação e de produção →

Seleção da plataforma

Mudar para outro SoC ARM apenas quando surgir uma restrição mensurável

Requisito principal Comece aqui Mover quando
Linux + controlo determinístico, CAN/TSN, aprendizagem automática leve i.MX 93 É necessário um melhor desempenho da câmara/ISP ou da IA
Visão com duas câmaras + controlo em tempo real com o M7 i.MX 8M Plus 2.3 O desempenho do TOPS ou do A53 torna-se o estrangulamento
Conteúdos multimédia de classe 8K, múltiplos ecrãs, IA local de 6 TOPS RK3588 A integração de várias câmaras nas áreas da segurança, do ciclo de vida ou a nível empresarial assume cada vez mais importância
IA multicâmara conectada, até 12 TOPS QCS6490 O CUDA / TensorRT / JetPack passa a ser obrigatório
O ecossistema CUDA é imprescindível Plataforma NVIDIA Não escolha outro SoC ARM apenas porque utiliza a mesma família de conjuntos de instruções da CPU

Análise da plataforma ARM

Envie primeiro as restrições de software e de E/S

Indique a preferência em termos de SoC, Linux/Android/RTOS, sensores de câmara, CAN/serial, Ethernet, ambiente de execução de IA, memória/armazenamento, alimentação, caixa, quantidade e objetivo de ciclo de vida.

Enviar os requisitos da plataforma ARM

Plataformas de partida

Comece pelo ecossistema mais próximo da pilha de software de produção

Direção A melhor razão para começar por aqui Congelar antes do protótipo
i.MX 93 Linux com enfoque no controlo + arquitetura M33 Variante do SoC, memória, armazenamento, propriedade da CAN/TSN, BSP, firmware do M33
i.MX 8M Plus Visão + controlo em tempo real num único SoC Sensores da câmara, canais MIPI, tempo de execução da NPU, ramo do Linux, partição M7
RK3588 Elevada densidade multimédia e IA de ponta com 6 TOPS BSP do fornecedor, suporte a ISP/sensores, tempo de execução da NPU, armazenamento e conceção térmica
QCS6490 IA multicâmara conectada e forte aceleração integrada Conjunto de câmaras, BSP/SO, ligação sem fios, ambiente de execução de IA, arranque seguro e ciclo de vida
Plataforma de referência ARM personalizada Nenhuma placa padrão disponibiliza o mapa de recursos do SoC necessário Alocação esquemática, árvore de dispositivos, BSP, lista de materiais (BOM), âmbito de validação e responsabilidade pela atualização

FAQ

Perguntas frequentes sobre a plataforma ARM Mini-ITX

Por que razão a escolha de uma placa-mãe ARM depende mais do software do que a de uma placa-mãe x86?

As placas ARM estão normalmente mais intimamente ligadas ao BSP do fornecedor, à árvore de dispositivos, aos controladores da câmara e da NPU, ao PMIC, ao bootloader e às entradas/saídas específicas da placa. O hardware e o software devem ser validados em conjunto.

Em que situações é que o i.MX 8M Plus é mais útil do que um SoC com um valor de TOPS mais elevado?

Escolha-o quando 2,3 TOPS forem suficientes e o projeto beneficiar de um ISP duplo, duas vias MIPI CSI, um Cortex-M7 a 800 MHz, CAN FD e Ethernet compatível com TSN numa única arquitetura industrial.

Um valor mais elevado de TOPS da NPU garante uma inferência mais rápida?

Não. Os operadores do modelo, a precisão, o tempo de execução, as transferências de memória, o pré-processamento, o fluxo de trabalho da câmara, o modo de consumo energético e a temperatura constante determinam a latência e o débito reais.

O que deve ser congelado antes da produção do ARM?

Congelar o SoC, a memória, o armazenamento, o PMIC, o mapa de E/S, os sensores da câmara, o bootloader, o ramo do kernel/BSP, a árvore de dispositivos, o firmware do RTOS, o ambiente de execução de IA, as chaves de segurança, o método de recuperação e as substituições aprovadas.

Informações úteis para sistemas incorporados baseados em ARM

Mantenha-se atualizado com o que há de mais recente em integração de SoC ARM, dicas de design em nível de placa e estratégias de implantação no mundo real - de IA de borda de baixo consumo de energia a controles industriais robustos.