

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Premier test de votre carte microcontrôleur
<a name="qual-steps"></a>

Vous pouvez utiliser IDT pour FreeRTOS pour tester lors du portage des interfaces FreeRTOS. Après avoir porté les interfaces FreeRTOS pour les pilotes de périphériques de votre carte, vous pouvez exécuter les tests AWS IoT Device Tester de qualification sur votre carte microcontrôleur. 

## Ajouter des couches de transfert pour les bibliothèques
<a name="add-port-layer"></a>

 Pour transférer FreeRTOS sur votre appareil, suivez les instructions du Guide de portage de [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/).

## Configurez vos AWS informations d'identification
<a name="cfg-aws-afr"></a>

Vous devez configurer vos AWS informations d'identification AWS IoT Device Tester pour pouvoir communiquer avec le AWS Cloud. Pour plus d'informations, voir [Configurer les AWS informations d'identification et la région pour le développement](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html). Des AWS informations d'identification valides doivent être spécifiées dans le fichier `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/config.json` de configuration.

**Topics**
+ [Ajouter des couches de transfert pour les bibliothèques](#add-port-layer)
+ [Configurez vos AWS informations d'identification](#cfg-aws-afr)
+ [Créer un pool d'appareils dans IDT pour FreeRTOS](cfg-dt-dp.md)
+ [Configurer les paramètres de création, de flash et de test](cfg-dt-ud.md)

# Créer un pool d'appareils dans IDT pour FreeRTOS
<a name="cfg-dt-dp"></a>

Les appareils à tester sont organisés dans des groupes. Chaque groupe d'appareils se compose d'un ou de plusieurs appareils identiques. Vous pouvez configurer IDT pour FreeRTOS afin de tester un seul appareil dans un pool ou plusieurs appareils dans un pool. Pour accélérer le processus de qualification, IDT for FreeRTOS peut tester des appareils avec les mêmes spécifications en parallèle. Il utilise une méthode séquentielle pour exécuter un groupe de tests différents pour chaque appareil d'un groupe.

Vous pouvez ajouter un ou plusieurs appareils à un groupe d'appareils en modifiant la section `devices` du modèle `device.json` dans le dossier `configs`.

**Note**  
Tous les appareils du même groupe doivent avoir les mêmes spécifications techniques et la même référence.

Pour permettre des compilations parallèles du code source pour différents groupes de test, IDT pour FreeRTOS copie le code source dans un dossier de résultats à l'intérieur du dossier extrait d'IDT pour FreeRTOS. Le chemin du code source dans votre commande build ou flash doit être référencé à l'aide de la `sdkPath` variable `testdata.sourcePath` or. IDT pour FreeRTOS remplace cette variable par un chemin temporaire du code source copié. Pour plus d'informations, voir,[IDT pour les variables FreeRTOS](dt-vars.md).

Voici un exemple de fichier `device.json` utilisé pour créer un groupe comprenant plusieurs appareils :

```
[
    {
        "id": "pool-id",
        "sku": "sku",
        "features": [
            {
                "name": "WIFI",
                "value": "Yes | No"
            },
            {
                "name": "Cellular",
                "value": "Yes | No"
            },
            {
                "name": "OTA",
                "value": "Yes | No",
                "configs": [
                    {
                        "name": "OTADataPlaneProtocol",
                        "value": "HTTP | MQTT"
                    }
                ]
            },
            {
                "name": "BLE",
                "value": "Yes | No"
            },
            {
                "name": "TCP/IP",
                "value": "On-chip | Offloaded | No"
            },
            {
                "name": "TLS",
                "value": "Yes | No"
            },
            {
                "name": "PKCS11",
                "value": "RSA | ECC | Both | No"
            },
            {
                "name": "KeyProvisioning",
                "value": "Import | Onboard | No"
            }
        ],

        "devices": [
          {
            "id": "device-id",
            "connectivity": {
              "protocol": "uart",
              "serialPort": "/dev/tty*"
            },
            ***********Remove the section below if the device does not support onboard key generation***************
            "secureElementConfig" : {
              "publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key",
              "secureElementSerialNumber": "secure-element-serialNo-value",
              "preProvisioned"           : "Yes | No"
            },
            **********************************************************************************************************
            "identifiers": [
              {
                "name": "serialNo",
                "value": "serialNo-value"
              }
            ]
          }
        ]
    }
]
```

Les attributs suivants sont utilisés dans le fichier `device.json` :

**`id`**  
Un ID alphanumérique défini par l'utilisateur qui identifie de façon unique un groupe d'appareils. Les appareils appartenant à un groupe doivent être du même type. Lorsque vous exécutez une suite de tests, les appareils du groupe sont utilisés pour paralléliser la charge de travail.

**`sku`**  
Une valeur alphanumérique qui identifie de façon unique la carte que vous testez. La référence est utilisée pour effectuer le suivi des cartes qualifiées.  
Si vous souhaitez mettre votre carte en vente dans le catalogue des appareils AWS partenaires, le SKU que vous spécifiez ici doit correspondre au SKU que vous avez utilisé lors du processus de mise en vente.

**`features`**  
Tableau contenant les fonctionnalités prises en charge par l'appareil. AWS IoT Device Tester utilise ces informations pour sélectionner les tests de qualification à exécuter.  
Les valeurs prises en charge sont :    
**`TCP/IP`**  
Indique si votre carte supporte une TCP/IP pile et si elle est supportée sur puce (MCU) ou déchargée vers un autre module. TCP/IP est requis pour la qualification.  
**`WIFI`**  
Indique si la carte contient des fonctionnalités Wi-Fi. Doit être défini sur `No` s'`Cellular`il est défini sur`Yes`.  
**`Cellular`**  
Indique si votre carte est dotée de fonctionnalités cellulaires. Doit être défini sur `No` s'`WIFI`il est défini sur`Yes`. Lorsque cette fonctionnalité est définie sur`Yes`, le FullSecureSockets test sera exécuté à l'aide d'instances EC2 AWS t2.micro, ce qui peut entraîner des coûts supplémentaires pour votre compte. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/).  
**`TLS`**  
Indique si votre carte prend en charge TLS. Le protocole TLS est requis pour la qualification.  
**`PKCS11`**  
Indique l'algorithme de cryptographie à clé publique pris en charge par la carte. PKCS11 est requis pour la qualification. Les valeurs prises en charge sont `ECC`, `RSA`, `Both` et `No`. `Both` indique que la carte prend en charge les algorithmes `ECC` et `RSA` .  
**`KeyProvisioning`**  
Indique la méthode d'écriture d'un certificat client X.509 approuvé sur votre carte. Les valeurs valides sont `Import`, `Onboard` et `No`. La mise en service de clés est requise pour la qualification.  
+ Utilisez `Import` si votre carte autorise l'importation de clés privées. IDT créera une clé privée et l'intégrera au code source de FreeRTOS.
+ Utilisez `Onboard` si votre carte prend en charge la génération d'une clé privée embarquée (par exemple, si votre appareil dispose d'un élément sécurisé ou si vous préférez générer vos propres certificat et paire de clés d'appareil). Veillez à ajouter un élément `secureElementConfig` dans chacune des sections de l'appareil et indiquez le chemin absolu vers le fichier de clé publique dans le champ `publicKeyAsciiHexFilePath`.
+ Utilisez `No` si votre carte ne prend pas en charge la mise en service de clés.   
**`OTA`**  
Indique si votre carte mère prend en charge la fonctionnalité de mise à jour over-the-air (OTA). L'attribut `OtaDataPlaneProtocol` indique le protocole de plan de données OTA pris en charge par le périphérique. L'attribut est ignoré si la fonctionnalité OTA n'est pas prise en charge par le périphérique. Lorsque `"Both"` est sélectionné, le temps d'exécution du test OTA est prolongé en raison de l'exécution de tests MQTT, HTTP et mixtes.  
À partir de IDT v4.1.0, `OtaDataPlaneProtocol` accepte uniquement `HTTP` et en `MQTT` tant que valeurs prises en charge.  
**`BLE`**  
Indique si la carte prend en charge Bluetooth Low Energy (BLE).

**`devices.id`**  
Un identificateur unique défini par l'utilisateur pour l'appareil testé.

**`devices.connectivity.protocol`**  
Le protocole de communication utilisé pour communiquer avec cet appareil. Valeur prise en charge : `uart`.

**`devices.connectivity.serialPort`**  
Le port série de l'ordinateur hôte utilisé pour se connecter aux appareils testés.

**`devices.secureElementConfig.PublicKeyAsciiHexFilePath`**  
Chemin absolu vers le fichier contenant la clé publique d'octets hexadécimaux extraite de la clé privée embarquée.  
Exemple de format :   

```
3059 3013 0607 2a86 48ce 3d02 0106 082a
8648 ce3d 0301 0703 4200 04cd 6569 ceb8
1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac
6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0
41b7 345c e746 1046 228e 5a5f d787 d571
dcb2 4e8d 75b3 2586 e2cc 0c
```
Si votre clé publique est au format .der, vous pouvez l'encoder directement en hexadécimal pour générer le fichier hexadécimal.  
Exemple de commande pour la clé publique .der pour générer un fichier hexadécimal :  

```
xxd -p pubkey.der > outFile
```
Si votre clé publique est au format .pem, vous pouvez extraire la partie codée en base64, la décoder au format binaire, puis l'encoder en hexadécimal pour générer le fichier hexadécimal.  
Par exemple, utilisez ces commandes pour générer un fichier hexadécimal pour une clé publique .pem :  

1. Retirez la partie codée en base64 de la clé (supprimez l'en-tête et le pied de page) et stockez-la dans un fichier, par exemple nommez-la`base64key`, exécutez cette commande pour la convertir au format .der :

   ```
   base64 —decode base64key > pubkey.der
   ```

1. Exécutez la `xxd` commande pour le convertir au format hexadécimal.

   ```
   xxd -p pubkey.der > outFile
   ```

**`devices.secureElementConfig.SecureElementSerialNumber`**  
(Facultatif) Numéro de série de l'élément sécurisé. Indiquez ce champ lorsque le numéro de série est imprimé avec la clé publique de l'appareil lorsque vous exécutez le projet FreeRTOS demo/test .

**`devices.secureElementConfig.preProvisioned`**  
(Facultatif) Réglez sur « Oui » si l'appareil possède un élément sécurisé préconfiguré avec des informations d'identification verrouillées, qui ne peut pas importer, créer ou détruire des objets. Cette configuration ne prend effet que lorsqu'`features`elle est `KeyProvisioning` définie sur « Onboard » et sur « ECC ». `PKCS11`

**`identifiers`**  
(Facultatif) Un tableau de paires nom-valeur arbitraires. Vous pouvez utiliser ces valeurs dans les commandes de création et flash décrites dans la section suivante.

# Configurer les paramètres de création, de flash et de test
<a name="cfg-dt-ud"></a>

Pour qu'IDT for FreeRTOS puisse être créé et testé automatiquement sur votre carte, vous devez configurer IDT pour exécuter les commandes de compilation et de flash pour votre matériel. Les paramètres de création et flash sont configurés dans le modèle de fichier `userdata.json` situé dans le dossier `config`.

# Configurer les paramètres pour tester un seul appareil
<a name="config-settings-device"></a>

Les paramètres de création, de flash et de test sont définis dans le fichier `configs/userdata.json`. Nous prenons en charge la configuration du serveur Echo en chargeant les certificats et les clés du client et du serveur dans le`customPath`. Pour plus d'informations, consultez la section [Configuration d'un serveur Echo](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html) dans le Guide de *portage de FreeRTOS*. L'exemple JSON suivant montre comment configurer IDT pour FreeRTOS afin de tester plusieurs appareils :

```
{
    "sourcePath": "/absolute-path-to/freertos",
    "vendorPath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name",
    // ***********The sdkConfiguration block below is needed if you are not using the default, unmodified FreeRTOS repo. 
    // In other words, if you are using the default, unmodified FreeRTOS repo then remove this block***************
    "sdkConfiguration": {
        "name": "sdk-name",
        "version": "sdk-version",
        "path": "/absolute-path-to/sdk"
    },
    "buildTool": {
        "name": "your-build-tool-name",
        "version": "your-build-tool-version",
        "command": [
            "{{config.idtRootPath}}/relative-path-to/build-parallel.sh {{testData.sourcePath}} {{enableTests}}"
        ]
    },
    "flashTool": {
        "name": "your-flash-tool-name",
        "version": "your-flash-tool-version",
        "command": [
            "/{{config.idtRootPath}}/relative-path-to/flash-parallel.sh {{testData.sourcePath}} {{device.connectivity.serialPort}} {{buildImageName}}"
        ],
        "buildImageInfo" : {
            "testsImageName": "tests-image-name",
            "demosImageName": "demos-image-name"
        }
    },
    "testStartDelayms": 0,
    "clientWifiConfig": {
        "wifiSSID": "ssid",
        "wifiPassword": "password",
        "wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
    },
    "testWifiConfig": {
        "wifiSSID": "ssid",
        "wifiPassword": "password",
        "wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
    },
    //**********
    //This section is used to start echo server based on server certificate generation method,
    //When certificateGenerationMethod is set as Automatic specify the eccCurveFormat to generate certifcate and key based on curve format,
    //When certificateGenerationMethod is set as Custom specify the certificatePath and PrivateKeyPath to be used to start echo server
    //**********
    "echoServerCertificateConfiguration": {
      "certificateGenerationMethod": "Automatic | Custom",
      "customPath": {
          "clientCertificatePath":"/path/to/clientCertificate",
          "clientPrivateKeyPath": "/path/to/clientPrivateKey",
          "serverCertificatePath":"/path/to/serverCertificate",
          "serverPrivateKeyPath": "/path/to/serverPrivateKey"
      },
    "eccCurveFormat": "P224 | P256 | P384 | P521"
    },
    "echoServerConfiguration": {
        "securePortForSecureSocket": 33333, // Secure tcp port used by SecureSocket test. Default value is 33333. Ensure that the port configured isn't blocked by the firewall or your corporate network
        "insecurePortForSecureSocket": 33334, // Insecure tcp port used by SecureSocket test. Default value is 33334. Ensure that the port configured isn't blocked by the firewall or your corporate network
        "insecurePortForWiFi": 33335 // Insecure tcp port used by Wi-Fi test. Default value is 33335. Ensure that the port configured isn't blocked by the firewall or your corporate network
    },
    "otaConfiguration": {
        "otaFirmwareFilePath": "{{testData.sourcePath}}/relative-path-to/ota-image-generated-in-build-process",
        "deviceFirmwareFileName": "ota-image-name-on-device",
        "otaDemoConfigFilePath": "{{testData.sourcePath}}/relative-path-to/ota-demo-config-header-file",
        "codeSigningConfiguration": {
            "signingMethod": "AWS | Custom",
            "signerHashingAlgorithm": "SHA1 | SHA256",
            "signerSigningAlgorithm": "RSA | ECDSA",
            "signerCertificate": "arn:partition:service:region:account-id:resource:qualifier | /absolute-path-to/signer-certificate-file",
            "signerCertificateFileName": "signerCertificate-file-name",
            "compileSignerCertificate": boolean,
            // ***********Use signerPlatform if you choose aws for signingMethod***************
            "signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF",
            "untrustedSignerCertificate": "arn:partition:service:region:account-id:resourcetype:resource:qualifier",
            // ***********Use signCommand if you choose custom for signingMethod***************
            "signCommand": [
                "/absolute-path-to/sign.sh {{inputImageFilePath}} {{outputSignatureFilePath}}"
            ]
        }
    },
    // ***********Remove the section below if you're not configuring CMake***************
    "cmakeConfiguration": {
        "boardName": "board-name",
        "vendorName": "vendor-name",
        "compilerName": "compiler-name",
        "frToolchainPath": "/path/to/freertos/toolchain",
        "cmakeToolchainPath": "/path/to/cmake/toolchain"
    },
    "freertosFileConfiguration": {
        "required": [
            {
                "configName": "pkcs11Config",
                "filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/core_pkcs11_config.h"
            },
            {
                "configName": "pkcs11TestConfig",
                "filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/iot_test_pkcs11_config.h"
            }
        ],
        "optional": [
            {
                "configName": "otaAgentTestsConfig",
                "filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/ota_config.h"
            },
            {
                "configName": "otaAgentDemosConfig",
                "filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_demos/config_files/ota_config.h"
            },
            {
                "configName": "otaDemosConfig",
                "filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_demos/config_files/ota_demo_config.h"
            }
        ]
    }
}
```

Voici les attributs utilisés dans le fichier `userdata.json` :

**`sourcePath`**  
Le chemin d'accès à la racine du code source FreeRTOS porté. Pour les tests parallèles avec un SDK, ils `sourcePath` peuvent être définis à l'aide du `{{userData.sdkConfiguration.path}}` support. Par exemple :   

```
{ "sourcePath":"{{userData.sdkConfiguration.path}}/freertos" }
```

**`vendorPath`**  
Le chemin d'accès au code FreeRTOS spécifique au fournisseur. Pour les tests série, `vendorPath` peut être défini comme un chemin absolu. Par exemple :  

```
{ "vendorPath":"C:/path-to-freertos/vendors/espressif/boards/esp32" }
```
Pour les tests en parallèle, `vendorPath` peut être défini à l'aide de l'espace réservé `{{testData.sourcePath}}`. Par exemple :  

```
{ "vendorPath":"{{testData.sourcePath}}/vendors/espressif/boards/esp32" }
```
La `vendorPath` variable n'est nécessaire que lorsqu'elle est exécutée sans SDK, sinon elle peut être supprimée.  
Lorsque vous exécutez des tests en parallèle sans SDK, l'`{{testData.sourcePath}}`espace réservé doit être utilisé dans les champs `vendorPath``buildTool`,`flashTool`. Lors de l'exécution d'un test avec un seul appareil, les chemins absolus doivent être utilisés dans les champs `vendorPath`, `buildTool` et `flashTool`. Lors de l'exécution avec un SDK, l'`{{sdkPath}}`espace réservé doit être utilisé dans les commandes `sourcePath``buildTool`, et`flashTool`.

**`sdkConfiguration`**  
Si vous qualifiez FreeRTOS en apportant des modifications aux fichiers et à la structure des dossiers au-delà de ce qui est requis pour le portage, vous devrez configurer les informations de votre SDK dans ce bloc. Si vous n'êtes pas éligible à un FreeRTOS porté dans un SDK, vous devez omettre complètement ce bloc.    
**`sdkConfiguration.name`**  
Le nom du SDK que vous utilisez avec FreeRTOS. Si vous n'utilisez pas de SDK, le `sdkConfiguration` bloc entier doit être omis.  
**`sdkConfiguration.version`**  
Version du SDK que vous utilisez avec FreeRTOS. Si vous n'utilisez pas de SDK, le `sdkConfiguration` bloc entier doit être omis.  
**`sdkConfiguration.path`**  
Le chemin absolu vers le répertoire du SDK qui contient votre code FreeRTOS. Si vous n'utilisez pas de SDK, le `sdkConfiguration` bloc entier doit être omis.

**`buildTool`**  
Chemin d'accès complet au script de création (.bat ou .sh) qui contient les commandes pour générer le code source. Toutes les références au chemin du code source dans la commande de construction doivent être remplacées par la AWS IoT Device Tester variable `{{testdata.sourcePath}}` et les références au chemin du SDK doivent être remplacées par`{{sdkPath}}`. Utilisez l'`{{config.idtRootPath}}`espace réservé pour référencer le chemin IDT absolu ou relatif. 

**`testStartDelayms`**  
Spécifie le nombre de millisecondes que le lanceur de tests FreeRTOS attendra avant de commencer à exécuter les tests. Cela peut être utile si l'appareil testé commence à émettre des informations de test importantes avant qu'IDT n'ait la chance de se connecter et de commencer à se connecter en raison d'une latence réseau ou autre. La valeur maximale autorisée est de 30 000 ms (30 secondes). Cette valeur s'applique uniquement aux groupes de test FreeRTOS et ne s'applique pas aux autres groupes de test qui n'utilisent pas le lanceur de tests FreeRTOS, tels que les tests OTA.

**`flashTool`**  
Chemin d'accès complet au script flash (.sh ou .bat) qui contient les commandes flash pour votre appareil. Toutes les références au chemin du code source dans la commande ﬂash doivent être remplacées par la variable IDT pour FreeRTOS `{{testdata.sourcePath}}` et toutes les références au chemin de votre SDK doivent être remplacées par la variable IDT pour FreeRTOS. Utilisez l'espace réservé pour référencer le chemin IDT absolu ou relatif. `{{sdkPath}}` `{{config.idtRootPath}}`    
**`buildImageInfo`**    
**`testsImageName`**  
Nom du fichier produit par la commande build lors de la création de tests à partir du `freertos-source/tests` dossier.  
**`demosImageName`**  
Nom du fichier produit par la commande build lors de la création de tests à partir du `freertos-source/demos` dossier.

**`clientWifiConfig`**  
Configuration Wi-Fi du client. Les tests de bibliothèque Wi-Fi nécessitent la connexion d'une carte MCU à deux points d'accès. (Les deux points d'accès peuvent être les mêmes.) Cet attribut configure les paramètres Wi-Fi du premier point d'accès. Certains des scénarios de test Wi-Fi exigent que le point d'accès soit sécurisé et qu'il ne soit pas ouvert. Assurez-vous que les deux points d'accès se trouvent sur le même sous-réseau que l'ordinateur hôte exécutant IDT.    
**`wifi_ssid`**  
SSID Wi-Fi.  
**`wifi_password`**  
Mot de passe Wi-Fi.  
**`wifiSecurityType`**  
Type de sécurité Wi-Fi utilisé. Une des valeurs suivantes :  
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
Si votre carte ne prend pas en charge le Wi-Fi, vous devez tout de même inclure la section `clientWifiConfig` dans votre fichier `device.json`, mais vous pouvez omettre les valeurs de ces attributs.

**`testWifiConfig`**  
Configuration Wi-Fi de test. Les tests de bibliothèque Wi-Fi nécessitent la connexion d'une carte MCU à deux points d'accès. (Les deux points d'accès peuvent être les mêmes.) Cet attribut configure le paramétrage Wi-Fi du second point d'accès. Certains des scénarios de test Wi-Fi exigent que le point d'accès soit sécurisé et qu'il ne soit pas ouvert. Assurez-vous que les deux points d'accès se trouvent sur le même sous-réseau que l'ordinateur hôte exécutant IDT.    
**`wifiSSID`**  
SSID Wi-Fi.  
**`wifiPassword`**  
Mot de passe Wi-Fi.  
**`wifiSecurityType`**  
Type de sécurité Wi-Fi utilisé. Une des valeurs suivantes :  
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
Si votre carte ne prend pas en charge le Wi-Fi, vous devez tout de même inclure la section `testWifiConfig` dans votre fichier `device.json`, mais vous pouvez omettre les valeurs de ces attributs.

**`echoServerCertificateConfiguration`**  
L'espace réservé à la génération de certificats de serveur Echo configurable pour les tests de socket sécurisés. Ce champ est obligatoire.    
**`certificateGenerationMethod`**  
Spécifie si le certificat de serveur est généré automatiquement ou fourni manuellement.  
**`customPath`**  
`certificateGenerationMethod`Il s'agit de « Personnalisé » `certificatePath` et `privateKeyPath` obligatoire.    
**`certificatePath`**  
Spécifie le chemin du fichier pour le certificat de serveur.  
**`privateKeyPath`**  
Spécifie le chemin du fichier pour la clé privée.  
**`eccCurveFormat`**  
Spécifie le format de courbe pris en charge par la carte. Obligatoire lorsque `PKCS11` le paramètre est réglé sur « ecc » dans`device.json`. Les valeurs valides sont « P224 », « P256 », « P384 » ou « P521 ».

**`echoServerConfiguration`**  
Les ports configurables du serveur Echo pour WiFi les tests de sockets sécurisés. Ce champ est facultatif.    
**`securePortForSecureSocket`**  
Port utilisé pour configurer un serveur echo avec TLS pour le test des sockets sécurisés. La valeur par défaut est 33333. Assurez-vous que le port configuré n'est pas bloqué par un pare-feu ou votre réseau d'entreprise.  
**`insecurePortForSecureSocket`**  
Port utilisé pour configurer le serveur echo sans TLS pour le test des sockets sécurisés. La valeur par défaut utilisée dans le test est 33334. Assurez-vous que le port configuré n'est pas bloqué par un pare-feu ou votre réseau d'entreprise.  
**`insecurePortForWiFi`**  
Le port utilisé pour configurer le serveur Echo sans TLS à des fins de WiFi test. La valeur par défaut utilisée dans le test est 33335. Assurez-vous que le port configuré n'est pas bloqué par un pare-feu ou votre réseau d'entreprise.

**`otaConfiguration`**  
Configuration OTA. [Facultatif]    
**`otaFirmwareFilePath`**  
Chemin d'accès complet vers l'image OTA créée après la génération. Par exemple, `{{testData.sourcePath}}/relative-path/to/ota/image/from/source/root`.  
**`deviceFirmwareFileName`**  
Le chemin complet du fichier sur le périphérique MCU où se trouve le microprogramme OTA. Certains appareils n'utilisent pas ce champ, mais vous devez tout de même fournir une valeur.  
**`otaDemoConfigFilePath`**  
Chemin d'accès complet à `aws_demo_config.h`, disponible dans `afr-source/vendors/vendor/boards/board/aws_demos/config_files/`. Ces fichiers sont inclus dans le modèle de code de portage fourni par FreeRTOS.   
**`codeSigningConfiguration`**  
Configuration de signature de code.  
**`signingMethod`**  
Méthode de signature de code. Les valeurs possibles sont `AWS` ou `Custom`.  
Pour les régions de Pékin et de Ningxia, utilisez`Custom`. `AWS`la signature de code n'est pas prise en charge dans ces régions.  
**`signerHashingAlgorithm`**  
Algorithme de hachage pris en charge sur le périphérique. Les valeurs possibles sont `SHA1` ou `SHA256`.   
**`signerSigningAlgorithm`**  
Algorithme de signature pris en charge sur le périphérique. Les valeurs possibles sont `RSA` ou `ECDSA`.  
**`signerCertificate`**  
Certificat de confiance utilisé pour l'OTA.  
Pour la méthode de signature du AWS code, utilisez l'Amazon Resource Name (ARN) pour le certificat sécurisé chargé sur le AWS Certificate Manager.  
Pour la méthode de signature de code personnalisée, utilisez le chemin d’accès absolu vers le fichier de certificat du signataire.  
Pour plus d'informations sur la création d'un certificat approuvé, consultez [Créer un certificat de signature de code](ota-code-sign-cert.md).   
**`signerCertificateFileName`**  
Le nom de fichier du certificat de signature de code sur l'appareil. Cette valeur doit correspondre au nom de fichier que vous avez fourni lors de l'exécution de la `aws acm import-certificate` commande.  
Pour de plus amples informations, veuillez consulter [Créer un certificat de signature de code](ota-code-sign-cert.md).   
**`compileSignerCertificate`**  
Défini `true` si le certificat de vérification de signature du signataire de code n'est pas fourni ou flashé, il doit donc être compilé dans le projet. AWS IoT Device Tester récupère le certificat sécurisé et le compile dans. `aws_codesigner_certifiate.h`  
**`untrustedSignerCertificate`**  
L'ARN ou le chemin de fichier d'un deuxième certificat utilisé dans certains tests OTA en tant que certificat non fiable. Pour plus d'informations sur la création d'un certificat, voir [Création d'un certificat de signature de code](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html).  
**`signerPlatform`**  
Algorithme de signature et de hachage utilisé par AWS Code Signer lors de la création de la tâche de mise à jour OTA. Actuellement, les valeurs possibles pour ce champ sont `AmazonFreeRTOS-TI-CC3220SF` et `AmazonFreeRTOS-Default`.   
+ Choisissez `AmazonFreeRTOS-TI-CC3220SF`, si `SHA1` et `RSA`. 
+ Choisissez `AmazonFreeRTOS-Default`, si `SHA256` et `ECDSA`.
Si vous avez besoin de `SHA256` \$1 `RSA` ou `SHA1` \$1 `ECDSA` pour votre configuration, contactez-nous pour obtenir une assistance complémentaire.  
Configurez `signCommand` si vous avez choisi `Custom` pour `signingMethod`.  
**`signCommand`**  
Commande utilisée pour effectuer la signature de code personnalisée. Vous pouvez trouver le modèle dans le répertoire `/configs/script_templates`.   
Deux espaces réservés `{{inputImageFilePath}}` et `{{outputSignatureFilePath}}` sont obligatoires dans la commande. `{{inputImageFilePath}}` est le chemin d'accès au fichier de l'image créée par IDT qu’il faut signer. `{{outputSignatureFilePath}}` est le chemin d’accès au fichier de la signature qui sera généré par le script.

**`cmakeConfiguration`**  
CMake configuration [Facultatif]  
Pour exécuter des scénarios de CMake test, vous devez fournir le nom du forum, le nom du fournisseur et le `frToolchainPath` ou`compilerName`. Vous pouvez également fournir le `cmakeToolchainPath` si vous avez un chemin personnalisé vers la CMake chaîne d'outils.  
**`boardName`**  
Nom de la carte testée. Le nom de la carte doit être le même que le nom du dossier sous `path/to/afr/source/code/vendors/vendor/boards/board`.  
**`vendorName`**  
Le nom du fournisseur pour le tableau testé. Le fournisseur doit être le même que le nom du dossier sous `path/to/afr/source/code/vendors/vendor`.  
**`compilerName`**  
Le nom du compilateur.  
**`frToolchainPath`**  
Le chemin d'accès complet au compilateur de la chaîne d'outils  
**`cmakeToolchainPath` **  
Le chemin complet vers la chaîne d' CMake outils. Ce champ est facultatif

**`freertosFileConfiguration`**  
La configuration des fichiers FreeRTOS qu'IDT modifie avant d'exécuter les tests.    
**`required`**  
Cette section indique les tests requis dont vous avez déplacé les fichiers de configuration PKCS11, par exemple TLS, etc.    
**`configName`**  
Nom du test en cours de configuration.  
**`filePath`**  
Le chemin absolu vers les fichiers de configuration dans le `freertos` dépôt. Utilisez la `{{testData.sourcePath}}` variable pour définir le chemin.  
**`optional`**  
Cette section spécifie les tests facultatifs dont vous avez déplacé les fichiers de configuration WiFi, par exemple OTA, etc.    
**`configName`**  
Nom du test en cours de configuration.  
**`filePath`**  
Le chemin absolu vers les fichiers de configuration dans le `freertos` dépôt. Utilisez la `{{testData.sourcePath}}` variable pour définir le chemin.

**Note**  
Pour exécuter des scénarios de CMake test, vous devez fournir le nom du forum, le nom du fournisseur et le `afrToolchainPath` ou`compilerName`. Vous pouvez également indiquer `cmakeToolchainPath` si vous avez un chemin personnalisé vers la CMake chaîne d'outils.

# IDT pour les variables FreeRTOS
<a name="dt-vars"></a>

Les commandes permettant de créer votre code et de flasher l'appareil peuvent nécessiter une connectivité ou d'autres informations sur vos appareils pour fonctionner correctement. AWS IoT Device Tester vous permet de référencer les informations du périphérique dans Flash et de créer des commandes à l'aide de [JsonPath](https://goessner.net/articles/JsonPath/). À l'aide d' JsonPathexpressions simples, vous pouvez récupérer les informations requises spécifiées dans votre `device.json` fichier.

## Variables de chemin
<a name="path-variables-frq"></a>

IDT pour FreeRTOS définit les variables de chemin suivantes qui peuvent être utilisées dans les lignes de commande et les fichiers de configuration :

**`{{testData.sourcePath}}`**  
Développe le code source du chemin d'accès. Si vous utilisez cette variable, elle doit être utilisée dans les commandes flash et build.

**`{{sdkPath}}`**  
S'étend jusqu'à la valeur de votre `userData.sdkConfiguration.path` lorsqu'elle est utilisée dans les commandes de compilation et de flash.

**`{{device.connectivity.serialPort}}`**  
Extension au port série.

**`{{device.identifiers[?(@.name == 'serialNo')].value[0]}}`**  
Extension jusqu'au numéro de série de votre appareil.

**`{{enableTests}}`**  
Valeur entière indiquant si la génération est destinée à des tests (valeur 1) ou à des démonstrations (valeur 0).

**`{{buildImageName}}`**  
Nom de fichier de l'image générée par la commande build.

**`{{otaCodeSignerPemFile}}`**  
Fichier PEM pour le signataire du code OTA.

**`{{config.idtRootPath}}`**  
S'étend jusqu'au chemin AWS IoT Device Tester racine. Cette variable remplace le chemin absolu pour IDT lorsqu'il est utilisé par les commandes build et flash.