Testes de verificação de distância SPI WinRT
Os testes de SPI fazem testes funcionais e de estresse de controladores SPI expostos ao usermode por meio das APIs WinRT Windows.Devices.Spi. O escopo do teste inclui:
- Verificação de que um controlador SPI com o nome amigável especificado está acessível a partir do usermode.
- Verificação de que os dados são enviados e recebidos corretamente em um intervalo de modos SPI, frequências de relógio, comprimentos de bit de dados e comprimentos de transferência.
- Verificação de que não há lacunas entre bytes dentro de uma transferência. Alguns dispositivos, como faixas de LED e analógicos para conversores digitais, exigem um sinal de relógio ininterrupto.
- Verificação de que a velocidade real do relógio usada está dentro de 15% do valor solicitado.
- Verificação de que, quando uma transferência é tentada com um comprimento de buffer que não é um múltiplo do passo, a transferência falha com STATUS_INVALID_PARAMETER e nenhuma atividade é gerada no barramento. O passo a passo é determinado por DataBitLength da seguinte maneira:
| DataBitLength | Passo |
| 4 - 8 | 1 |
| 9 - 16 | 2 |
| 17 - 32 | 4 |
Os testes são executados em um LPC1768 conectado externamente. O mbed LPC1768 é uma plataforma popular de prototipagem de microcontrolador que pode ser comprada de uma variedade de varejistas online, incluindo Sparkfun, Digikey e Adafruit. Programar o mbed com a imagem de firmware de teste é tão simples quanto arrastar e soltar a imagem de firmware para o dispositivo de armazenamento em massa. O código-fonte do firmware está disponível no github. Instruções detalhadas sobre como preparar o mbed e executar os testes são fornecidas abaixo.
Detalhes do teste
| Especificações |
|
| Plataformas | |
| Versões com suporte |
|
| Tempo de execução esperado (em minutos) | 5 |
| Categoria | Desenvolvimento |
| Tempo limite (em minutos) | 10 |
| Requer reinicialização | false |
| Requer configuração especial | false |
| Tipo | automático |
Documentação adicional
Os testes nessa área de recursos podem ter documentação adicional, incluindo pré-requisitos, configuração e informações de solução de problemas, que podem ser encontrados nos tópicos a seguir:
Executando o teste
Você precisará do seguinte hardware para executar os testes:
- mbed LPC1768
- Placa universal
- Cabos de jumper
Primeiro, você deve carregar o firmware de teste no mbed:
- Conecte o LPC1768 mbed via USB ao computador. Ele aparecerá como uma unidade removível no computador.
- Abrir a unidade no explorador de arquivos
- Copie c:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Tests\x86\iot\busses-tester-mbed_LPC1768.bin para a unidade
- Pressione o botão no mbed para redefinir o microcontrolador
Em seguida, conecte o mbed ao controlador SPI em teste. Para ligar o mbed, você pode conectá-lo via USB ao dispositivo em teste ou conectar os pinos VIN e GND diretamente aos pinos de energia em seu dispositivo em teste. Faça as seguintes conexões entre o dispositivo em teste e o mbed: (pinout mbed),
- Conectar o pino mbed 13 (P0.15/SCK0) ao pino SCK em seu dispositivo em teste
- Conecte o pino mbed 30 (P0.4/CAP2.0) ao pino SCK em seu dispositivo em teste (esse pino é usado para medição precisa do relógio)
- Conectar o pino mbed 11 (P0.18/MOSI0) ao pino MOSI em seu dispositivo em teste
- Conectar o pino mbed 12 (P0.17/MISO0) ao pino MISO em seu dispositivo em teste
- Conectar o pino mbed 14 (P0.16/SSEL0) ao pino Selecionar Chip em seu dispositivo em teste
- Conectar o GND mbed a um pino GND em seu dispositivo em teste
Agora você pode agendar os testes no HLK Studio.
Solucionando problemas
Para solucionar problemas genéricos de falhas de teste do HLK, consulte Solução de problemas de falhas de teste do Windows HLK.
É recomendável executar os testes na linha de comando para obter informações sobre falhas e iterar rapidamente em soluções. Também recomendamos conectar um analisador lógico, como um salae. Pode ser difícil ou impossível determinar a causa de uma falha sem a capacidade de inspecionar o tráfego de ônibus.
Veja como executar os testes na linha de comando:
Copiar %programfiles(x86)%\Windows Kits\10\Testing\Runtimes\TAEF\<arch>\MinTe para c:\data\minte
Copie Windows.Devices.LowLevel.UnitTests.dll de %programfiles(x86)%\Windows Kits\10\Hardware Lab Kit\Tests\<arch>\iot para c:\data em seu dispositivo.
Telnet ou ssh em seu dispositivo
Alterar diretórios para c:\data
Execute os testes:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlk*
Uso de teste de linha de comando:
minte\te windows.devices.lowlevel.unittests.dll [/name:test_name] [/p:SpiFriendlyName=friendly_name] [/p:ClockFrequency=clock_frequency] [/p:DataBitLength=data_bit_length] [/p:SpiMode=0|1|2|3] [/p:Length=length] [/p:WriteLength=write_length] [/p:ReadLength=read_length] [/p:ExtraClocks=extra_clocks] [/p:Verbose=true]
- test_name – o nome do teste a ser executado, que pode incluir curingas. Exemplos: /name:SpiHlk*, /name:SpiHlkTests::VerifyClockFrequency#metadataSet0
- friendly_name – o nome amigável do controlador SPI em teste. Se omitido, o primeiro controlador enumerado será usado. Exemplos: /p:SpiFriendlyName=SPI1
- clock_frequency – forçar um teste a usar a frequência do relógio especificada. Por padrão, a frequência do relógio vem dos dados de teste, que foram projetados para fornecer cobertura em uma variedade de frequências. Esse parâmetro deve ser omitido em circunstâncias normais. Exemplo: /p:ClockFrequency=1500000
- data_bit_length – forçar um teste a usar o comprimento do bit de dados especificado. Exemplo: /p:DataBitLength=9
- SpiMode – forçar um teste a usar o modo SPI especificado. Exemplo: /p:SpiMode=2
- length – force um teste a usar o comprimento do buffer especificado para a transferência. Exemplo: /p:length=128
- write_length – force um teste TransferSequential a usar o comprimento do buffer especificado para a parte de gravação da transferência. Exemplo: /p:WriteLength=8
- read_length – force um teste TransferSequential a usar o comprimento do buffer especificado para a parte de leitura da transferência. Exemplo: /p:ReadLength=16
- extra_clocks – especifique um ajuste no número de relógios por byte que os testes usam ao calcular os tempos ativos esperados do relógio para medições de desempenho, detecção de lacunas e validação de frequência do relógio. Por exemplo, o controlador SPI BCM2836 aguarda um ciclo de relógio extra após cada byte, portanto, para compensar esse comportamento, as medidas devem ser ajustadas. Exemplo: /p:ExtraClocks=1.5
- /p:Verbose=true - ative a saída detalhada. Isso fará com que buffers inteiros sejam despejados no console quando ocorrer uma falha. Por padrão, somente o primeiro byte incompatível é exibido.
Exemplos:
Listar testes disponíveis:
minte\te windows.devices.lowlevel.unittests.dll /list
Execute os testes de validação de E/S:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkIoTests*
Execute os testes de detecção de lacunas:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkGapTests*
Execute a validação de frequência do relógio e os testes passo a passo:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkTests*
Execute um teste específico em uma instância específica do controlador SPI:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkIoTests#2::VerifyTransferSequential#metadataSet9 /p:SpiFriendlyName=SPI1
Uma ferramenta que pode ajudar na solução de problemas manual é SpiTestTool. SpiTestTool é um utilitário simples para interagir com SPI na linha de comando.
Mais informações
Parâmetros
| Nome do parâmetro | Descrição do parâmetro |
|---|---|
| SpiFriendlyName | O nome amigável do controlador SPI em teste (por exemplo, SPI0). |