Test di scrittura WinRT I2C (obbligatorio EEPROM)
I test I2C eseguono test funzionali e di stress dei controller I2C esposti alla modalità utente tramite le API WinRT Windows.Devices.I2c. I test sono suddivisi in due parti: test funzionali e di stress di base e test funzionali avanzati. L'ambito dei test funzionali di base include:
- Verifica che un controller I2C con nome descrittivo specificato sia accessibile dalla modalità utente.
- Verifica che i dati vengano scritti correttamente su un intervallo di velocità di clock e lunghezze del buffer fino a 8 byte (dimensioni della pagina EEPROM).
- Verifica che i dati vengano letti correttamente su un intervallo di velocità di clock e lunghezze del buffer.
- Verifica che le sequenze di lettura write-restart-read (WriteRead) vengano eseguite correttamente su un intervallo di velocità di clock e lunghezze del buffer.
- Verifica che quando si tenta di scrivere, leggere o WriteRead a un indirizzo slave non riconosciuto, il driver restituisce STATUS_NO_SUCH_DEVICE. Questo è segnalato da I2cDevice::Write/Read/WriteRead() come HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND) e viene segnalato da I2cDevice::WritePartial/ReadPartial/WriteReadPartial() come I2cTransferStatus::SlaveAddressNotAcknowledged.
- Verifica che le API e i driver funzionino correttamente in condizioni di stress. I test di stress scrivono e leggono da due EEPROMs simultaneamente con handle di dispositivo separati per una durata estesa.
L'ambito dei test funzionali avanzati include:
- Verifica che i dati vengano scritti correttamente per le lunghezze del buffer fino a 16384 byte.
- Verifica che venga generata una condizione di riavvio I2C in risposta a una sequenza WriteRead.
- Verifica che quando il dispositivo slave NAK mentre il master sta ancora scrivendo byte, il driver completa la richiesta con STATUS_SUCCESS e segnala il numero effettivo di byte scritti tramite le informazioni della richiesta. Viene chiamato trasferimento parziale e viene segnalato da WritePartial() e WriteReadPartial() come I2cTransferStatus::P artialTransfer.
- Verifica che l'estensione dell'orologio fino a 500 ms sia consentita e non causi l'esito negativo del trasferimento.
- Verifica che quando il dispositivo slave mantiene bassa la linea di clock per una durata estesa (10+ secondi), il driver completa il trasferimento entro al massimo 10 secondi con un codice di errore. Il codice di errore deve essere STATUS_IO_TIMEOUT, ma non viene verificato per motivi di compatibilità.
I test funzionali di base e i test di stress vengono eseguiti su due EEPROM connessi esternamente. I test funzionali avanzati vengono eseguiti su un LPC1768 mbed che esegue firmware personalizzato. Mbed LPC1768 è una popolare piattaforma di prototipazione microcontroller che può essere acquistata da un'ampia gamma di rivenditori online, tra cui Sparkfun, Digikey e Adafruit. L'aggiornamento del firmware di mbed è semplice come il trascinamento e l'eliminazione di un file. Il codice sorgente del firmware è disponibile in github. Di seguito sono riportate le istruzioni per la preparazione del mbed e l'esecuzione dei test.
Dettagli del test
| Specifiche |
|
| Piattaforme | |
| Versioni supportate |
|
| Tempo di esecuzione previsto (in minuti) | 5 |
| Categoria | Sviluppo |
| Timeout (in minuti) | 10 |
| Richiede il riavvio | false |
| Richiede una configurazione speciale | true |
| Tipo | automatic |
Documentazione aggiuntiva
I test in questa area di funzionalità potrebbero avere documentazione aggiuntiva, inclusi i prerequisiti, la configurazione e le informazioni sulla risoluzione dei problemi, disponibili negli argomenti seguenti:
Esecuzione del test
Esecuzione dei test funzionali e di stress di base
Per eseguire i test, è necessario disporre dell'hardware seguente:
- Atmel AT24HC seriale EEPROMs qt. 2
- 10k resistore qt. 2
- Breadboard
- Cavi
Collegare le EEPROMs come illustrato nel diagramma seguente e connettere SDA e SCL al dispositivo sottoposto a test.
È ora possibile pianificare i test funzionali e di stress di base dal gestore HLK.
Esecuzione dei test funzionali avanzati
I test funzionali avanzati verificano il comportamento NACKing, le condizioni dell'autobus bloccate, l'estensione del clock e l'avvio ripetuto. I test richiedono la connessione di un firmware personalizzato LPC1768 mbed al dispositivo sottoposto a test. Prima di eseguire i test, è necessario caricare il firmware HLK nell'LPC1768 mbed. Ecco come aggiornare il firmware:
- Collegare mbed LPC1768 tramite USB al PC. Verrà visualizzato come unità rimuovibile nel PC.
- Aprire l'unità in Esplora file
- Copiare c:\Programmi (x86)\Windows Kits\10\Hardware Lab Kit\Tests\x86\iot\busses-tester-mbed_LPC1768.bin in mbed
- Premere il pulsante su mbed per reimpostare il microcontroller
Collegare quindi il mbed al dispositivo sottoposto a test. Collegare mbed tramite USB al dispositivo sottoposto a test. Effettuare quindi le connessioni I2C (pinout mbed),
- Connettere mbed pin 9 (P0.0/SDA) al pin SDA nel dispositivo sottoposto a test
- Connettere mbed pin 10 (P0.1/SCL) al pin SCL nel dispositivo sottoposto a test
- Connettere GND mbed a un pin GND nel dispositivo sottoposto a test
Mbed dispone di resistori pull-up interni abilitati nelle linee SDA e SCL e non richiede resistori esterni pull-up.
È ora possibile pianificare i test funzionali avanzati dal gestore HLK.
Risoluzione dei problemi relativi
Per la risoluzione generica degli errori di test HLK, vedere Risoluzione dei problemi di test di Windows HLK.
È consigliabile eseguire i test nella riga di comando per ottenere informazioni dettagliate sugli errori e per eseguire rapidamente l'iterazione sulle soluzioni. Ecco come eseguire i test nella riga di comando:
Copiare %programfiles(x86)%\Windows Kits\10\Testing\Runtimes\TAEF\<arch>\MinTe to c:\data\minte
Copiare Windows.Devices.LowLevel.UnitTests.dll da %programfiles(x86)%\Windows Kits\10\Hardware Lab Kit\Tests\<arch>\iot in c:\data nel dispositivo.
Telnet o ssh nel dispositivo
Modificare le directory in c:\data
Eseguire i test:
minte\te windows.devices.lowlevel.unittests.dll /name:I2c*
Utilizzo dei test della riga di comando:
minte\te windows.devices.lowlevel.unittests.dll [/name:test_name] [/select:select_clause] [/p:I2cFriendlyName=friendly_name] [/p:Duration=duration]
- test_name : nome del test da eseguire che può includere caratteri jolly. Esempi: /name:I2c*, /name:I2cEepromWriteTests#metadataSet0::VerifyWrite#metadataSet0
- select_clause : clausola di selezione TAEF. Esempio: /select:"@name='I2c*' e not(@name='I2cTestsEx*')"
- friendly_name : nome descrittivo del controller I2C sottoposto a test. Se omesso, viene utilizzato il primo controller enumerato. Esempi: /p:I2cFriendlyName=I2C0
- duration : durata dell'esecuzione di test di stress. Esempi: /p:Duration=10s (10 secondi), /p:Duration=1m (1 minuto), /p:Duration=2h (2 ore), /p:Duration=1d (1 giorno)
Esempi:
Per eseguire i test funzionali di base,
minte\te windows.devices.lowlevel.unittests.dll /select:"@name='I2c*' and not(@name='I2cTestsEx*')"
Per eseguire i test funzionali avanzati,
minte\te windows.devices.lowlevel.unittests.dll /name:I2cTestsEx::*
Per eseguire i test su un'istanza specifica del controller I2C, passare il nome descrittivo al parametro di test I2cFriendlyName,
minte\te windows.devices.lowlevel.unittests.dll /name:I2c* /p:I2cFriendlyName=I2C0
Per eseguire un test specifico, passare il nome completo del test al parametro /name:
minte\te windows.devices.lowlevel.unittests.dll /name:I2cNonexistentSlaveAddressTests::TestWriteRead
Per eseguire i test di stress per la durata consigliata di 8 ore, eseguire
minte\te windows.devices.lowlevel.unittests.dll /name:I2cStressTests::StressIoConcurrent /p:Duration=8h
Uno strumento che può essere utile per la risoluzione dei problemi manuali è I2cTestTool. I2cTestTool è un'utilità semplice per interagire con I2C dalla riga di comando.
Altre informazioni
Parametri
| Nome parametro | Descrizione dei parametri |
|---|---|
| I2cFriendlyName | Nome descrittivo del controller I2C sottoposto a test (ad esempio I2C0). |