Codificando Seu Próprio Equipamento de Teste em Rede

Mark Harris
|  Criada: January 18, 2024  |  Atualizada: February 9, 2024
Codificando Seu Próprio Equipamento de Teste em Rede

Introdução

Se você já passou tempo testando manualmente lotes de componentes, sabe o quão trabalhoso e demorado todo o processo é. Cada teste segue os mesmos passos básicos repetidos para cada item que você está testando. Você também entenderá o poder de usar equipamentos de teste que você pode programar para realizar esses passos por você, então é simplesmente o caso de configurar tudo e conectar tudo para que você possa pressionar um botão para realizar um teste. Você pode economizar ainda mais tempo automatizando a configuração de todos os seus equipamentos de teste com um clique do mouse do computador.

No entanto, e se você quiser criar equipamentos de teste personalizados para adicionar ao seu conjunto de testes automatizados? Este guia passo a passo mostrará como escrever código que permite configurar seus equipamentos de teste em rede a partir do conforto do seu computador.

A automação em rede elimina a necessidade de configurar cada peça de equipamento de teste separadamente e economiza tempo se você precisar repetir os mesmos testes no futuro. O bônus é que restaurar as configurações após qualquer corte de energia ou desligamento acidental do equipamento é rápido e simples.

Introdução ao SCPI

Se você não está familiarizado com equipamentos de teste em rede, você precisa conhecer os Comandos Padrão para Instrumentos Programáveis (SCPI). No passado, a Hewlett-Packard desenvolveu o conceito de um barramento de interface padrão que permitiria a qualquer computador com a interface correta se conectar a qualquer peça de equipamento de teste. Este padrão HPIB ficou conhecido como o Barramento de Interface de Propósito Geral (GPIB) com sua própria designação de padrão IEEE 488. Essa padronização permitiu que cada peça de equipamento de teste em rede respondesse a comandos do computador para realizar funções como emitir um sinal ou realizar uma medição.

O SCPI expandiu o princípio da padronização em rede de equipamentos de teste adicionando uma camada adicional para o padrão IEEE-488 regular os comandos de computador que o equipamento de teste poderia entender. Essa abordagem agora significa que um osciloscópio feito pela HP responderá aos mesmos comandos que um osciloscópio feito pela Keysight. Antes da padronização dos comandos, muitas vezes diferentes modelos produzidos pelo mesmo fabricante reagiriam a comandos diferentes. Essa padronização significa que o programa de controle do equipamento de teste em um computador funcionará com qualquer marca e modelo de equipamento de laboratório, então mudar uma fonte de alimentação de bancada em rede, por exemplo, para um modelo melhor não exigirá mudanças no programa de controle.

Essa padronização também significa que qualquer código escrito para este guia passo a passo funcionará em qualquer outro laboratório se você tiver os mesmos tipos de equipamentos de teste em rede ligados a um computador adequado.

Introdução ao SCPI

Os comandos SCPI estão na forma de strings ASCII simples que são razoavelmente intuitivas de ler e entender. Por exemplo, enviar o comando “*RST” para um item de equipamento de teste irá reiniciá-lo; enviar o comando “*WAI” irá instruí-lo a esperar.

Os comandos SCPI podem instruir o equipamento de teste a realizar uma ação ou solicitar informações dependendo do seu formato. Por exemplo, o comando “TIM:ACQT 20ms” mudará o tempo de aquisição de um osciloscópio para 20ms, enquanto o comando “TIM:ACQT?” fará com que ele retorne seu tempo de aquisição atual.

Pontos importantes a considerar são que os comandos não são sensíveis a maiúsculas e minúsculas e suportam formas abreviadas, então, por exemplo, “TRIG SOUR CH1” e “Trigger source Channel1” são ambas alternativas válidas do mesmo comando. Você também pode concatenar comandos, então, por exemplo, “TRIG SOUR CH1”, “TRIG LEVEL1 10” e “TRIG POL INV” podem ser escritos como “TRIG:SOUR CH1;LEVEL1 10;POL INV” já que todos os comandos se aplicam ao mesmo TRIG. Esses comandos definem o canal de origem, seu nível em volts e a polaridade. Este exemplo define o nível do canal 1 para 10V com polaridade invertida. Você não precisa especificar seu gatilho 1, pois isso é presumido, mas você poderia usar “TRIG1:” para evitar ambiguidade.

O Projeto de Codificação

O vídeo que acompanha este artigo mostra como criar seu próprio equipamento de teste em rede que usa comandos SCPI. Isso se baseia em um vídeo anterior mostrando como se comunicar com equipamentos de teste para automação.

Este exercício visa permitir que hardware de teste personalizado se encaixe perfeitamente em qualquer software de teste existente que possa lidar com comandos SCPI, como aqueles que usam as LAN eXtensions for Instrumentation (LXI) ou a Virtual Instrument Software Architecture (VISA). O objetivo final é desenvolver um dispositivo de teste integrado e abrangente, incorporando um microcontrolador ao hardware de teste automatizado.

Codificando Seu Próprio Equipamento de Teste em Rede

O coração do projeto é o Infineon XMC4700 Relax Kit development board, feito para aplicações industriais. O board inclui um microcontrolador com memória estática e dinâmica, relógios, fontes de alimentação, interfaces padrão e controles básicos. Ele também inclui uma conexão ethernet onboard com um endereço de controle de acesso à mídia (MAC) para rede.

Um benefício chave dessa configuração é a disponibilidade do ambiente de desenvolvimento integrado Digital Application Virtual Engineer (DAVE) que a Infineon fornece. O DAVE é uma ferramenta de desenvolvimento de software e geração de código baseada em C para aplicações de microcontrolador. Ele permite a simplificação do processo de codificação, lidando convenientemente com a maioria das tarefas de configuração para que você possa se concentrar na implementação de comandos SCPI.

O código de teste que criaremos lerá a posição de um botão e controlará o estado de um LED. Este teste simplista oferecerá um exemplo fácil de entender e fornecerá um ótimo ponto de partida para uma exploração mais aprofundada do poder e dos benefícios do teste automatizado.

Guia de Codificação Passo a Passo

Configuração do Projeto:

Codificando Seu Próprio Equipamento de Teste em Rede Um Guia Passo a Passo

Ao usar a ferramenta DAVE para um novo projeto, o primeiro passo é criar um novo arquivo de projeto usando a sequência de comandos “Arquivo -> Novo -> Projeto DAVE”. Esta ação abrirá uma nova janela onde você pode selecionar a opção “Projeto DAVE CE” e dar um nome apropriado.

Codificando Seu Próprio Equipamento de Teste em Rede Um Guia Passo a Passo

Você então precisará escolher seu hardware alvo; neste caso, o XMC4700 Relax Kit.

A menos que seu projeto vá ser limitado por recursos, é sempre uma boa prática usar a biblioteca padrão newlib completa em vez da opção de tamanho nano.

Codificando Seu Próprio Equipamento de Teste em Rede Um Guia Passo a Passo

O próximo passo é configurar os periféricos para o projeto usando o comando “DAVE -> Adicionar Novo APP”.

Codificando Seu Próprio Equipamento de Teste em Rede Um Guia Passo a Passo

A primeira configuração a ser definida é a conexão de rede, e você faz isso com o comando “Ethernet -> ETH_LWIP”, que adiciona uma pilha de protocolo de internet leve (IP) ao projeto para lidar com essa interface.

Codificando Seu Próprio Equipamento de Teste em Rede Um Guia Passo a Passo

Você também precisa adicionar as interfaces de entrada/saída (IO) para o equipamento de teste, o botão e o indicador LED neste exemplo. Ambos são componentes discretos, então você deve adicionar dois aplicativos “DIGITAL_IO” sob a opção de comando do Sistema, um para cada elemento.

Teste

É uma boa prática renomear os aplicativos de IO para identificar suas funções em seus nomes para facilitar a vida e evitar o acesso acidental ao aplicativo errado. Esse erro pode ser difícil de identificar ao tentar depurar um programa de teste que está se comportando de maneira inesperada.

Testando

Você também deve configurar a pilha IP para a conexão Ethernet clicando com o botão direito do mouse no “ETH_LWIP App” e clicando em “Configurar Instância do APP”. Você verá que o XMC4700 Relax Kit já vem pré-configurado, o que economiza tempo. Você precisará alterar o endereço IP estático na página de configurações de IP para corresponder à sub-rede do computador que está usando para seus testes automatizados. Além disso, o protocolo de datagrama de usuário (UDP) não é necessário neste exemplo, então você pode desativá-lo na aba de configurações do protocolo.

Testando

Finalmente, você precisa fornecer o mapeamento entre as configurações de pinos do APP e o hardware do microcontrolador usando a opção de alocação manual de pinos para cada componente. Para configurar o botão discreto, você clica com o botão direito do mouse sobre o botão e seleciona o comando “Alocador Manual de Pinos”.

Testando

Você pode então escolher o número de pino apropriado para o botão no Relax Kit a partir do menu suspenso, que convenientemente fornece etiquetas para tornar isso direto. Configurar o LED e a conexão Ethernet segue o mesmo processo. Você verá que a função de alocação de pinos simplifica esse processo, permitindo que você selecione apenas pinos com a funcionalidade necessária. A ferramenta fornece automaticamente todas as etiquetas do XMC4700 Relax Kit para tornar isso direto.

Essas etapas completam a configuração do seu projeto de teste automatizado, e agora você está pronto para escrever o código de teste.

Codificação do Aplicativo do Projeto

Teste

Você pode gerar o código para os Apps simplesmente clicando no botão “Gerar Código” na barra de ferramentas do DAVE e então aguardar até que a operação seja concluída.

Antes de começar a programar seriamente, um passo recomendado é transferir o console do microcontrolador para o computador, proporcionando fácil acesso ao `printf`. Isso permitirá que você formate e imprima dados para tornar a escrita e depuração do código mais rápidas e fáceis. Você pode fazer isso ativando o “GDB Semi-Hosting” nas configurações. Isso pode ser feito navegando até as “Propriedades do Projeto”, prosseguindo para “C/C++ Build” e então selecionando “Configurações”.

Testando

Em “ARM-GCC, C Linker, Diversos”, você precisará adicionar “–specs=rdimon.specs” às “Outras” bandeiras. Este passo incorpora a configuração de semi-hosting para o linker.

Teste

Você pode então ir para a seção “ARM-GCC C Compiler, Preprocessor” e adicionar um novo símbolo definido de “XMC_DEBUG_ENABLE”. Esta configuração garante o redirecionamento do console na configuração de build de depuração.

Testando

Você precisará, nas configurações do projeto, desmarcar a caixa de seleção que fornece “chamadas de sistema newlib padrão” sob as configurações de “ARM-GCC C Linker, Geral”. Se você deixar isso marcado, descobrirá que isso interrompe a inicialização do manipulador de monitor e causa a falha na construção.

Em seguida, você precisa inicializar o monitoramento, o que pode ser feito adicionando “extern void initialise_monitor_handles(void);” ao início do seu código. Esta função precisa ser chamada após a chamada DAVE_Init();.

Note que a grafia de “initialise” é a variante do inglês britânico, já que a base da ARM está em Cambridge, Inglaterra. Usar a grafia americana causará um erro que pode ser difícil de resolver se você não notar a sutil diferença de grafia.

Codificação de Rede do Projeto

O primeiro passo para fazer a rede Ethernet funcionar é habilitar a pilha Lightweight IP para verificar novas mensagens regularmente. Você pode fazer isso adicionando uma chamada à função “sys_check_timeouts();” dentro do seu loop while infinito que roda após a inicialização estar completa.

Esta função precisará de depuração para permitir que ela seja executada no microcontrolador. Você pode fazer isso criando uma nova configuração de depuração. A recomendação é desativar a opção “Definir ponto de interrupção em: main” para permitir que o código seja executado assim que o microcontrolador iniciar. Selecionar a opção de depuração carregará seu novo código no microcontrolador.

Testando

Você pode confirmar que o código está sendo executado ao abrir um console do Windows no seu computador e fazer um ping para o endereço IP da placa de desenvolvimento, que neste exemplo, é o XMC4700 Relax Kit. A placa de desenvolvimento deve responder a cada ping, confirmando que a placa está operando e a conexão de rede está funcionando.

O código do Lightweight IP stack lidará automaticamente com as funções do Protocolo de Mensagens de Controle da Internet (ICMP). No entanto, você deve criar código para lidar com conexões e dados de entrada do Protocolo de Controle de Transmissão (TCP). Você pode fazer isso usando declarações de código padrão do Lightweight IP stack que não são específicas do microcontrolador.

Agora que você completou a configuração da conexão de rede, você pode configurar o bloco de controle de protocolo para escutar na porta 5025, que o código SCPI usa para comunicações. Você deve configurar o Lightweight IP stack para delegar todas as novas conexões a uma função chamada client_accept, que você precisará estender para lidar com novos clientes. Todos os dados recebidos precisarão ser redirecionados para uma função de processamento separada que também emitirá uma mensagem de depuração para indicar o recebimento de uma nova conexão.

Implementar um método client_recv copiará os dados recebidos em um buffer para processamento. Esta função também deve verificar conexões sem dados, o que indica que o host remoto fechou a conexão. Para esta condição, o código pode realizar ações de limpeza para remover quaisquer artefatos indesejados deixados pela conexão fechada.

Compilar o código gerará uma compilação funcional se não houver erros de codificação para depurar.

Codificação do Projeto IO

O próximo passo é a configuração dos “Aplicativos de IO Digital” para realizar suas operações requeridas.

Teste

Clique com o botão direito em cada App e selecione a opção “Configurar Instância do App”. A configuração padrão para componentes IO é uma entrada tristate, perfeita para o botão. No entanto, para o LED, você precisará mudar as configurações para “Entrada/Saída” com uma condução forte e borda suave. Esta configuração de condução forte garante que a placa produza corrente de condução suficiente para iluminar o LED. A configuração de borda suave refere-se à velocidade de transição de borda do pino. Uma borda suave alivia quaisquer efeitos transitórios na rede de distribuição de energia e reduz o risco de um impacto adverso na conformidade eletromagnética. Usar esta opção para saída discreta é uma boa prática, a menos que você precise de um sinal com taxas de borda de nanossegundos.

Regenerar o código atualizado adicionará essas novas mudanças à construção funcional. É importante lembrar de sempre regenerar o código após fazer quaisquer alterações em um DAVE App.

Codificação do Projeto SCPI

Com as funções de configuração e inicialização completas, a codificação do projeto pode finalmente avançar para implementar os comandos SCPI para testes. Não há necessidade de implementar os comandos SCPI do zero; uma excepcional biblioteca SCPI-Parser de Jan Breuer está disponível no GitHub como ponto de partida.

Você pode aproveitar este recurso extraindo a pasta libscpi para a pasta Bibliotecas do seu projeto. Em seguida, extraia as pastas scpi-def de “exemplos -> comum” para a pasta do seu projeto. Este passo importa a biblioteca SCPI-Parser e fornece um bom ponto de partida para implementar seu projeto.

Você precisará deletar a pasta de testes e o makefile na biblioteca libscpi dentro do ambiente de desenvolvimento integrado do DAVE, pois estes serão incompatíveis com a biblioteca ARM-GCC em uso.

Testando

Em seguida, volte para a janela de propriedades do projeto em “Build, Settings, Compiler, Directories” e adicione uma referência à pasta de inclusões do libscpi.

Você também precisará abrir o arquivo scpi-def.c e adicionar uma declaração de inclusão para “dave.h” para vincular suas funções IO ao arquivo scpi-def.

Como uma nota à parte, este arquivo inclui uma fantástica implementação de demonstração de um Multímetro Digital e funções para testes automatizados. Infelizmente, essas funções são incompatíveis com o compilador ARM usado para este exemplo, e portanto precisam ser removidas. No entanto, se você precisar implementar suas próprias funções no futuro, pode referir-se aos arquivos originais para referência.

Ao editar o arquivo, delete todas as funções DMM e de teste no bloco de configuração de comando, mas mantenha o código para o comando TST e todas as declarações seguintes, junto com os comandos SCPI padrão que a biblioteca irá tratar.

Você pode definir as informações de identificação para a configuração do teste no arquivo “scpi-def.h”, assim usando o comando SCPI *IDN retornará informações úteis em resposta a qualquer solicitação de identificação.

Você pode configurar os comandos SCPI no arquivo “main.c” do projeto. Será necessário adicionar o contexto SCPI à função principal usando a propriedade user_context para passar uma referência ao bloco de controle do protocolo Lightweight IP permitindo a inicialização da biblioteca SCPI. Então, você precisa adicionar suas funções para habilitar a libscpi a se comunicar através da conexão de rede. Neste exemplo, as seguintes funções precisam ser definidas:

  • A função “SCPI_Write” permite que a libscpi envie dados através da conexão de rede.

  • A função “SCPI_Flush” notifica a pilha Lightweight IP para enviar quaisquer dados no buffer imediatamente.

  • A função “SCPI_Error” oferece um meio de lidar com erros SCPI. Para este exemplo básico, você pode contornar isso com uma simples chamada à função printf.

  • A função “SCPI_Control” é um recurso opcional que permite escrever no canal de controle na porta TCP 5026, o que você não precisará para este exemplo.

  • A função “SCPI_Reset” é chamada em resposta a receber um comando de reset, revertendo todos os instrumentos de teste para suas configurações padrão. Não há equipamento de teste conectado para este exemplo básico, então você pode contornar isso com uma simples chamada à função printf.

Teste

Finalmente, o user_context precisa ser definido para a nova conexão de cliente ao fazer uma conexão com a pilha Lightweight IP. Isso permitirá que os dados passem para a biblioteca SCPI do buffer através da função client_recv para “SCPI_Input” para serem processados. Você precisará notar que esta implementação não lidará com múltiplas conexões simultaneamente, mas representa uma boa prática de configuração de rede.

Compilar o código atualizado e carregá-lo no microcontrolador deve resultar em um sistema de teste que não apenas continua a responder a pings de um Console Windows, mas também deve responder aos comandos SCPI.

Teste de Código SCPI do Projeto

Este projeto de exemplo usou uma aplicação Rohde & Schwarz VISA Tester para testar comandos SCPI.

Teste

Após conectar o aplicativo ao equipamento de teste, o primeiro teste é emitir uma solicitação de identidade (IDN?). Este é um primeiro passo recomendado, e o comando é inteiramente tratado pela biblioteca SCPI, garantindo que as comunicações estejam operacionais e que você configurou a biblioteca corretamente. Isso significa que resolver quaisquer problemas envolvendo testes que requerem uma resposta de um dispositivo periférico ou equipamento de teste pode assumir que as comunicações e a biblioteca não são suspeitas no processo de depuração.

Testar os periféricos requer adicionar novos padrões ao array `scpi_commands` para implementar as funções necessárias. Chamadas para a função “printf” podem ser incluídas para depurar a funcionalidade, fornecendo um método simples de verificar a execução do código.

Teste

No exemplo, o código lê o estado do botão usando a função “scpi_result_t IO_Btn“ na DAVE App previamente configurada para o manipulador do botão com o estado enviado usando a resposta “SCPI_ResultBool”. O valor retornado é invertido, pois este botão é um componente ativo baixo.

Teste

A função de manipulação do LED analisa o parâmetro de estado do botão recebido e define o estado apropriado do LED. Se não existirem parâmetros, então nenhuma ação é tomada para este exemplo. Este passo usa a função “scpi_result_t IO_Led” para realizar sua função.

Com o microcontrolador programado, você pode testar o código usando a aba Console na ferramenta DAVE. Isso demonstrará o recebimento da conexão e operação do comando de solicitação de identidade.

Teste

Você pode verificar o estado do botão enviando uma consulta SCPI e testar a funcionalidade observando que o estado retornado muda quando você pressiona o botão.

Você pode testar a funcionalidade do LED simplesmente enviando comandos de ligar e desligar, observando o estado da luz e monitorando o status do console.

Com o botão e o LED funcionando corretamente, você tem a base de um instrumento conectado à rede totalmente funcional. A conexão de uma plataforma de automação de teste ou escrever seu próprio código de teste permitirá que você verifique remotamente o estado do botão e controle o LED.

Conclusão

O artigo mostra como usar o ambiente de teste integrado DAVE com uma placa de desenvolvimento permitirá que você crie e conecte seu próprio equipamento de teste em rede para integrar com seu equipamento de bancada e automatizar testes de laboratório.

Este guia passo a passo é para uma demonstração de prova de conceito elementar, mas seguir os passos e obter um sistema de teste funcional equipará você com tudo o que precisa para criar seus próprios instrumentos de teste.

Usaremos os princípios que exploramos neste projeto para criar um item prático de equipamento de teste em um futuro próximo, então fique atento para mais desenvolvimentos.

Sobre o autor

Sobre o autor

Mark Harris is an engineer's engineer, with over 16 years of diverse experience within the electronics industry, varying from aerospace and defense contracts to small product startups, hobbies and everything in between. Before moving to the United Kingdom, Mark was employed by one of the largest research organizations in Canada; every day brought a different project or challenge involving electronics, mechanics, and software. He also publishes the most extensive open source database library of components for Altium Designer called the Celestial Database Library. Mark has an affinity for open-source hardware and software and the innovative problem-solving required for the day-to-day challenges such projects offer. Electronics are passion; watching a product go from an idea to reality and start interacting with the world is a never-ending source of enjoyment. 

You can contact Mark directly at: mark@originalcircuit.com

Documentação técnica relacionada

Retornar a página inicial
Thank you, you are now subscribed to updates.