L'interface USB a dépassé sa fonction initiale de simple liaison de données dans les systèmes embarqués, devenant un bus système offrant des capacités de communication à haut débit, de gestion d'alimentation, d'identification de périphérique et une abstraction de pile protocolaire. L'ESP32-S2 est le premier SoC d'Espressif à intégrer un contrôleur USB 2.0 OTG (On-The-Go) pleine vitesse natif. Ce module n'est pas implémenté via un pont UART ou un PHY externe ; il est directement intégré dans la puce, composé d'une machine à états matérielle, d'un contrôleur DMA, de mémoires tampons de points d'extrémité et d'un moteur de protocole USB. Il supporte le taux de transfert pleine vitesse USB 2.0 (12 Mbps) et offre les deux modes, périphérique et hôte, sans nécessiter de puce PHY USB externe. Cette caractéristique redéfinit fondamentalement la topologie matérielle et la répartition logicielle des applications USB embarquées traditionnelles.

Dans la pratique, la valeur centrale de l'USB natif repose sur trois piliers : l'efficacité des ressources, le découplage de la pile protocolaire et la réutilisabilité fonctionnelle.

• Efficacité des ressources : Contrairement aux solutions de caméra utilisant des interfaces DVP/MIPI, une caméra USB ne nécessite pas un grand nombre de GPIO, de lignes de données parallèles ni de signaux de synchronisation d'image dédiés (VSYNC/HSYNC/PCLK). Seules deux lignes différentielles (D+/D-) et l'alimentation VBUS sont nécessaires pour le flux vidéo. En prenant l'exemple d'une caméra USB OV5640, la capture d'un flux JPEG sur ESP32-S2 réduit l'occupation des GPIO de 18–22 broches (pour une solution DVP) à zéro, et diminue la bande passante mémoire SRAM d'environ 40 %, libérant ainsi des ressources pour le décodage JPEG local et le rafraîchissement d'un écran LCD.
• Découplage de la pile protocolaire : En mode périphérique USB, l'ESP32-S2 peut être reconnu par un PC comme un périphérique standard de classe CDC ACM (port série virtuel), MSC (stockage de masse), HID (interface homme-machine), etc. Le système d'exploitation charge automatiquement les pilotes génériques, ce qui évite au développeur d'écrire des pilotes spécifiques pour Windows, Linux ou macOS. En mode hôte, la pile protocolaire hôte USB intégrée à la puce peut énumérer les périphériques USB standard (comme les claviers HID, les caméras UVC, les dispositifs de stockage UAS), évitant ainsi la dépendance à un microcontrôleur ou une puce de pontage externe.
• Réutilisabilité fonctionnelle : La même ressource matérielle USB peut prendre en charge plusieurs formes d'applications : téléchargement de firmware, débogage par port série virtuel, caméra USB, partage d'une clé USB via un point d'accès Wi-Fi, saisie par pavé tactile. Ces fonctions ne sont pas mutuellement exclusives ; elles peuvent être commutées dynamiquement via une configuration au moment de l'exécution. Par exemple, dans l'exemple usb_device_msc, l'interface USB monte une carte SD comme un périphérique MSC ; dans l'exemple usb_device_cdc_acm, les mêmes broches D+/D- sont reconfigurées en un périphérique de classe CDC pour l'impression sur le port série. Cette réutilisabilité provient du mécanisme de définition logicielle des descripteurs USB et de la capacité de mappage flexible des points d'extrémité.

Il est essentiel de noter que le module USB de l'ESP32-S2 est une unité matérielle indépendante de la bande de base Wi-Fi/BT. Sa source d'horloge (sortie du PLL à 48 MHz), son vecteur d'interruption (USB_INTR_SOURCE) et ses canaux DMA sont physiquement isolés de la couche MAC Wi-Fi. Cela signifie que l'émission et la réception de données USB et le traitement des trames Wi-Fi peuvent être planifiés en parallèle sous FreeRTOS, sans se disputer les tranches de temps du CPU. Dans des projets réels, nous avons déployé la capture d'un flux JPEG de caméra USB (mode périphérique USB), la transmission d'images par Wi-Fi (mode STA) et le stockage JPEG sur carte TF (SPI Master) dans la même tâche. L'adresse du buffer JPEG obtenu par USB était poussée dans une file d'attente via xQueueSendToBack, puis consommée par une tâche indépendante pour être distribuée vers l'écriture sur socket Wi-Fi et le thread d'écriture SDIO. Avec une fréquence CPU de 240 MHz, l'occupation du processeur se stabilisait entre 68 % et 72 %, sans perte d'image ni ralentissement.

Mode Périphérique USB : Téléchargement de Firmware et Débogage par Port Série Virtuel

Le mode périphérique USB de l'ESP32-S2 est sa fonction la plus basique et la plus fréquemment utilisée, directement liée à l'efficacité du développement et du débogage. Comparé à la méthode traditionnelle de téléchargement par UART, le téléchargement par USB offre trois avantages irremplaçables : un débit plus élevé, un matériel plus simple et une robustesse accrue.

Principe du Téléchargement USB et Connexion Matérielle

Le téléchargement par USB repose sur le chargeur de démarrage (Bootloader) ROM intégré à la puce. Après une réinitialisation, le ROM BL vérifie d'abord l'état de la broche GPIO0 : si elle est à l'état bas, il entre en mode de téléchargement USB ; si elle est à l'état haut, il saute vers le programme utilisateur dans la Flash. Ce processus est entièrement contrôlé par la logique matérielle, sans aucune intervention de code utilisateur. Le téléchargement USB utilise les descripteurs standard de classe USB CDC ACM. Le PC le reconnaît comme un port série compatible Silicon Labs CP210x ou FTDI (selon les pilotes installés), mais la communication réelle est gérée directement par le contrôleur USB intégré de l'ESP32-S2, sans passer par le périphérique UART.

La connexion matérielle est très simple : il suffit de connecter les quatre fils D+ (GPIO20), D- (GPIO19), VBUS (5V) et GND de l'ESP32-S2 à une prise USB de type A. Attention : VBUS doit être alimenté en 5V, car le mode périphérique USB exige que la puce soit alimentée par le bus pour maintenir la tension de fonctionnement du PHY USB (le régulateur 3.3V LDO est généré par l'abaissement du VBUS). Si seul le câble de données USB est branché (sans alimentation VBUS), la puce peut bien s'énumérer, mais le PHY USB ne pourra pas verrouiller son horloge, ce qui entraînera un échec du téléchargement ou des déconnexions fréquentes du périphérique. En pratique, lorsque la tension VBUS est inférieure à 4,75 V, le taux de succès de l'énumération USB tombe en dessous de 30 %.

Comparaison des Performances de Téléchargement et Données de Test

Sur un même PC (Intel i7-10875H) et avec le même firmware (hello_world.bin, 128 Ko), une comparaison entre les téléchargements UART et USB donne :

Type d'interface	Débit / Vitesse	Débit réel	Temps de téléchargement	Nombre de tentatives
UART	921600 bps	~850 Ko/s	152 ms	0
USB	Full Speed (12 Mbps)	~980 Ko/s	133 ms	0

Le débit USB est amélioré d'environ 15 %, mais la véritable valeur réside dans le démarrage "zéro configuration" : le téléchargement UART nécessite de mettre manuellement GPIO0 à l'état bas et de réinitialiser, tandis que le téléchargement USB nécessite seulement de maintenir GPIO0=0 après la mise sous tension. Le ROM BL entre alors automatiquement en mode de téléchargement, sans aucune action manuelle sur un bouton. Dans les scénarios de test de production automatisée, cette fonctionnalité peut réduire le temps d'intervention humaine de 2 à 3 secondes par appareil.

Implémentation du Débogage par Port Série Virtuel (CDC ACM)

Le port série virtuel est une extension du mode périphérique USB. Il simule un périphérique série standard sur l'interface USB, permettant ainsi à la sortie printf d'être directement dirigée vers le terminal du PC. Son implémentation est basée sur le composant usb_serial_jtag d'ESP-IDF, mais il est important de noter ses différences fondamentales avec l'UART traditionnel :

• Aucun périphérique UART physique n'est impliqué : les données de journal sont envoyées directement au PC par la fonction esp_usb_console_write via le DMA du contrôleur USB, contournant le FIFO de l'UART et le réglage du débit en bauds.
• Gestion différente du tampon : le CDC USB utilise un tampon de point d'extrémité (Bulk IN) de 64 octets. Lorsque la réception côté PC est plus lente que l'envoi, le contrôleur USB déclenche automatiquement un signal NAK, suspendant le jeton IN de l'hôte, évitant ainsi la perte de données. En revanche, l'UART supprime les caractères suivants lorsque son tampon est plein.
• Moment crucial de l'initialisation : l'appel à usb_serial_jtag_init() doit être effectué dans app_main(), et il faut s'assurer que l'option CONFIG_USB_SERIAL_JTAG_ENABLE est activée dans menuconfig. Si l'initialisation n'est pas effectuée avant la création de la tâche main_task, l'appel à printf échouera silencieusement.

Lors de tests pratiques, nous avons constaté que lorsque le port série virtuel USB coexiste avec le mode Wi-Fi STA, un dépassement de délai DHCP pendant la connexion Wi-Fi peut entraîner un blocage temporaire du point d'extrémité IN USB. La solution consiste à ajouter une vérification de délai avant l'appel à usb_serial_jtag_write :

// Remplacer le printf original par une vérification de l'état du point d'extrémité USB
void safe_usb_printf(const char* format, ...) {
    if (usb_serial_jtag_is_connected()) { // Vérifier l'état de la connexion USB
        va_list args;
        va_start(args, format);
        usb_serial_jtag_vprintf(format, args); // Utiliser le printf dédié à l'USB
        va_end(args);
    }
}

Cette fonction se dégrade automatiquement en ESP_LOGI lorsque l'USB est déconnecté, garantissant ainsi que les informations de débogage ne soient pas perdues.

Mode Hôte USB : Connexion de Caméra et de Module 4G

Le mode hôte USB donne à l'ESP32-S2 la capacité d'interagir avec des périphériques USB standard. Les défis techniques résident dans l'énumération des périphériques, l'adaptation des pilotes de classe et le traitement des flux de données en temps réel. ESP-IDF fournit le composant usb_host, mais le développeur doit comprendre la structure en couches de la pile protocolaire USB : la couche inférieure est le pilote de contrôleur hôte (HCD), la couche intermédiaire est la librairie hôte USB (USB Host Core), et la couche supérieure est le pilote de classe (comme UVC, CDC-ACM).

Processus de Connexion d'une Caméra USB (UVC)

UVC (USB Video Class) est le protocole standard pour les caméras sans pilote. L'ESP32-S2 supporte la spécification UVC 1.1 et peut se connecter à la plupart des caméras USB plug-and-play (comme Logitech C270, Microsoft LifeCam). Le processus de connexion se déroule en quatre étapes :

(1) Conception de la connexion matérielle et de l'alimentation

Les caméras UVC ont généralement une consommation électrique élevée (>200 mA). La capacité de sortie VBUS de l'ESP32-S2 est limitée (100 mA typique). Il est donc nécessaire d'alimenter la caméra avec une source 5V externe ; l'ESP32-S2 fournit uniquement les signaux D+/D-. Dans la conception du circuit, il faut noter que :

• La longueur des lignes D+/D- ne doit pas dépasser 15 cm et doit être proche de la prise USB pour éviter la diaphonie ;
• Une résistance de tirage (pull-up) de 1,5 kΩ doit être connectée en série sur la ligne D+ vers le 3,3V (pour l'identification des périphériques à haute vitesse). Cette résistance est déjà intégrée dans l'ESP32-S2, elle n'est donc pas nécessaire à l'extérieur ;
• La masse (GND) de la caméra doit être connectée à la masse de l'ESP32-S2 en un seul point pour éviter les boucles de masse génératrices de bruit.

(2) Énumération du périphérique et analyse des descripteurs

Après l'initialisation de l'hôte USB, le HCD analyse le bus. Détectant l'insertion d'un nouveau périphérique (signal SE0), il déclenche une réinitialisation et lit le descripteur de périphérique. Les champs clés incluent :

• bDeviceClass = 0xEF (Périphérique divers), bDeviceSubClass = 0x02 (Classe commune), bDeviceProtocol = 0x01 (Descripteur d'interface associé) — indique que le périphérique utilise la structure IAD ;
• bNumConfigurations = 1, puis le descripteur de configuration est lu, où bNumInterfaces = 2 (VideoControl + VideoStreaming) ;
• L'interface VideoStreaming a bInterfaceClass = 0x0E (Vidéo), bInterfaceSubClass = 0x01 (VideoControl), bInterfaceProtocol = 0x00 (non défini).

Le composant usb_host d'ESP-IDF effectue automatiquement cette énumération. Le développeur doit simplement enregistrer une fonction de rappel usb_host_event_callback_t, dans laquelle il obtient le handle du périphérique lors de l'événement USB_HOST_CLIENT_EVENT_NEW_DEV.

(3) Initialisation du pilote de classe UVC

Le pilote UVC se trouve dans components/usb/class/uvc. Il faut appeler explicitement uvc_host_init() en lui passant le handle du périphérique. Le pilote analyse les requêtes de l'interface VideoControl (comme GET_CUR pour obtenir la résolution actuelle) et configure le point d'extrémité de l'interface VideoStreaming (qui est généralement un point d'extrémité Bulk IN). Les paramètres clés sont :

• frame_width = 640, frame_height = 480 : choisir la résolution VGA au format MJPEG ;
• frame_interval = 333333 (30 ips) : écrire la valeur dans le champ dwFrameInterval de VideoStreaming via la requête SET_CUR ;
• max_packet_size = 512 : définir la taille du tampon DMA selon le champ wMaxPacketSize du descripteur de point d'extrémité de la caméra.

(4) Capture et traitement du flux JPEG

La caméra UVC émet un flux au format MJPEG. Chaque image commence par 0xFFD8 (SOI) et se termine par 0xFFD9 (EOI). L'ESP32-S2 reçoit en continu les paquets de données via le point d'extrémité Bulk IN. Le pilote place les données JPEG complètes dans un tampon circulaire. Dans un projet réel, il faut être attentif à :

• Stratégie d'allocation mémoire : un JPEG 640x480 compressé fait environ 30–50 Ko. Le tampon circulaire doit être d'au moins 200 Ko pour éviter un débordement dû aux délais d'envoi Wi-Fi ;
• Identification des limites d'image : il ne faut pas diviser par paquets, il faut analyser les marqueurs 0xFFD8 / 0xFFD9. Nous utilisons une machine à états pour l'analyse :

typedef enum { STATE_WAIT, STATE_IN_FRAME, STATE_FOUND_EOI } frame_parse_state_t;
static frame_parse_state_t parse_state = STATE_WAIT;

void parse_jpeg_stream(uint8_t* data, size_t len, void (*on_frame)(uint8_t*, size_t)) {
    static uint8_t* frame_start = NULL;
    for (size_t i = 0; i < len; i++) {
        switch (parse_state) {
            case STATE_WAIT:
                if (data[i] == 0xFF && (i+1) < len && data[i+1] == 0xD8) {
                    frame_start = &data[i];
                    parse_state = STATE_IN_FRAME;
                    i++; // skip 0xD8
                }
                break;
            case STATE_IN_FRAME:
                if (data[i] == 0xFF && (i+1) < len && data[i+1] == 0xD9) {
                    size_t frame_len = (&data[i+2]) - frame_start;
                    if (on_frame) on_frame(frame_start, frame_len);
                    parse_state = STATE_WAIT;
                    i++; // skip 0xD9
                }
                break;
            default:
                break;
        }
    }
}

• Garantie de temps réel : placer la capture JPEG dans une tâche de haute priorité (par exemple, uxTaskPriorityGet(NULL) + 1) et synchroniser la tâche d'envoi Wi-Fi via xSemaphoreTake pour éviter une compétition d'écriture/lecture sur le tampon JPEG.

Connexion et Mise en Réseau d'un Module 4G (CDC ACM)

Les modules 4G (tels que Quectel EC25, SIMCOM SIM7600) utilisent généralement la classe CDC ACM pour le canal de commande AT. L'ESP32-S2, en tant qu'hôte USB, peut communiquer directement avec eux. Le processus de connexion est similaire à celui de l'UVC, mais l'interaction protocolaire est plus complexe :

• Initialisation du canal de commande AT : après l'énumération, il faut envoyer une requête SET_LINE_CODING au point d'extrémité de contrôle de l'interface CDC ACM, configurant le débit en bauds (115200), les bits de données (8), le bit d'arrêt (1) et la parité (none) ;
• Processus de connexion réseau :
  1. AT+CGDCONT=1,"IP","CMNET" — Configurer le point d'accès (APN) ;
  2. AT+CGACT=1,1 — Activer le contexte PDP ;
  3. AT+QIACT — Établir la connexion IP ;
  4. AT+QIAUTH=1,"user","pass" — Si une authentification est nécessaire ;
• Partage Wi-Fi : après avoir établi la connexion 4G, appeler esp_netif_create_ip4_linklocal() pour attribuer une adresse locale de liaison (169.254.x.x) à wifi_ap_netif, puis lancer le serveur DHCP via esp_netif_dhcps_start() pour que d'autres appareils (comme un téléphone) obtiennent une adresse IP et accèdent à Internet via la connexion 4G.

Lors de tests, nous avons constaté que certains modules 4G nécessitent un délai de 5 à 10 secondes après AT+QIACT avant d'obtenir une adresse IP valide. Si le serveur DHCP est démarré immédiatement, les clients peuvent obtenir une passerelle incorrecte. La solution consiste à interroger périodiquement esp_netif_get_ip_info() et à ne démarrer le DHCP que lorsque ip4->ip.addr != 0 :

while (1) {
    esp_netif_ip_info_t ip_info;
    if (esp_netif_get_ip_info(eth_netif, &ip_info) == ESP_OK && ip_info.ip.addr != 0) {
        esp_netif_dhcps_start(wifi_ap_netif);
        break;
    }
    vTaskDelay(1000 / portTICK_PERIOD_MS);
}

Mode Périphérique USB Avancé : Stockage de Masse (MSC) et Interface Homme-Machine (HID)

Les classes USB MSC et HID sont deux types de périphériques hautement standardisés. En tant que périphérique USB, l'ESP32-S2 peut s'interfacer de manière transparente avec les pilotes génériques de PC/Mac/Linux, sans développement sur mesure. Les points clés de l'ingénierie résident dans la gestion du support de stockage et la construction précise du descripteur de rapport HID.

Implémentation du Stockage de Masse USB (MSC)

Le protocole MSC abstrait un périphérique de stockage en tant que LUN (Logical Unit Number). Chaque LUN correspond à un périphérique bloc. L'implémentation MSC sur ESP32-S2 nécessite trois niveaux :

• Couche physique : une carte SD (via SDMMC) ou une mémoire flash SPI (via SPI) en tant que support de stockage ;
• Couche de périphérique bloc : implémenter l'interface diskio_drv_t, fournissant les fonctions read_blocks, write_blocks et ioctl ;
• Couche USB MSC : enregistrer la configuration usb_msc_config_t, spécifiant le nombre de LUN, la taille de bloc (512 octets), le nombre total de blocs.

Prenons l'exemple d'une carte SD :

// Pilote de périphérique bloc pour carte SD
static diskio_driver_t sd_diskio_driver = {
    .init = sdmmc_init,
    .status = sdmmc_status,
    .read = sdmmc_read_blocks,
    .write = sdmmc_write_blocks,
    .ioctl = sdmmc_ioctl,
};

// Configuration MSC
static const usb_msc_config_t msc_config = {
    .lun_num = 1,
    .lun = &(usb_msc_lun_t){
        .block_size = 512,
        .block_count = 15630144, // Carte SD de 8 Go
        .ro = false,
        .removable = true,
        .name = "ESP32-S2 UDISK",
        .vendor = "Espressif",
        .product = "SD Card",
        .revision = "1.0",
        .diskio = &sd_diskio_driver,
    }
};

La couche système de fichiers doit être FAT32 (et non exFAT ou NTFS), car Windows active par défaut la stratégie de retrait rapide uniquement pour les disques amovibles formatés en FAT32, ce qui évite la corruption des données lors du retrait. Pour formater la carte SD, il faut utiliser la commande mkfs.fat -F32 et s'assurer que la taille de cluster est alignée sur la taille de bloc (512 octets).

Le partage de fichiers via Wi-Fi est implémenté à l'aide du composant esp_http_server d'ESP-IDF. Créez un point d'extrémité POST /upload pour recevoir des fichiers, un point d'extrémité GET /download/<filename> pour fournir des téléchargements, et un point d'extrémité /list pour renvoyer une liste de fichiers au format JSON. Les optimisations clés sont :

• Utiliser httpd_req_recv en mode fragmenté lors du téléchargement pour éviter de charger l'intégralité du fichier dans la RAM ;
• Utiliser httpd_resp_send_chunk pour un envoi en continu lors du téléchargement, avec fread depuis la carte SD ;
• Pour éviter les conflits d'accès concurrents, appeler xSemaphoreTake(sd_mutex, portMAX_DELAY) avant fopen et xSemaphoreGive après l'opération.

Développement de Périphériques d'Interface Homme-Machine (HID) USB

L'élément central d'un périphérique HID est le descripteur de rapport, qui définit, sous forme binaire, la structure des données que le périphérique envoie. L'ESP32-S2 prend en charge le protocole de démarrage HID (clavier/souris) et le protocole de rapport (périphérique personnalisé). Ce dernier nécessite le chargement d'un pilote de classe HID sur le PC.

(1) Implémentation d'un Pavé Tactile USB (Souris)

Le pavé tactile doit envoyer les déplacements X/Y et l'état des boutons gauche/droit. Les champs clés du descripteur HID :

• Usage Page (Generic Desktop) → Usage (Mouse) → Collection (Application) ;
• Usage (Pointer) → Collection (Physical) ;
• Usage (X), Usage (Y) → Logical Minimum (-127), Logical Maximum (127) → Report Size (8), Report Count (2) ;
• Usage (Button 1), Usage (Button 2) → Logical Minimum (0), Logical Maximum (1) → Report Size (1), Report Count (2) ;
• Report Count (6) pour remplir les bits restants jusqu'à l'alignement sur un octet.

Dans le code, on construit le paquet de rapport de la souris :

typedef struct {
    uint8_t buttons; // bit0: gauche, bit1: droit
    int8_t x_delta;
    int8_t y_delta;
} __attribute__((packed)) mouse_report_t;

mouse_report_t report = {0};
report.buttons = (touch_pressed) ? 0x01 : 0x00;
report.x_delta = (int8_t)(x_diff * 2); // Facteur d'échelle
report.y_delta = (int8_t)(y_diff * 2);
usb_hid_device_send_report(hid_dev, 0, (uint8_t*)&report, sizeof(report));

(2) Implémentation d'un Clavier Numérique (Keypad)

Le clavier doit suivre la table d'utilisation USB HID Keyboard/Keypad. Les codes de touches doivent utiliser des valeurs standard (par exemple, 0x04 pour 'a', 0x05 pour 'b'). Le descripteur doit déclarer Usage (Keyboard) et attribuer Usage Minimum/Maximum pour chaque touche. L'envoi nécessite la construction d'un rapport de 8 octets :

• Octet0 : touches modificatrices (Ctrl/Maj/Alt) ;
• Octet1 : réservé ;
• Octets2–7 : codes de touches (jusqu'à 6 touches simultanées).

Nous avons implémenté un clavier numérique 3×3, mappant les résultats du balayage de la matrice GPIO en codes de touches HID :

const uint8_t keypad_map[3][3] = {
    {0x59, 0x5A, 0x5B}, // 1,2,3
    {0x5C, 0x5D, 0x5E}, // 4,5,6
    {0x5F, 0x60, 0x61}, // 7,8,9
};
// Envoi de la touche '5' : report[2] = 0x5D; report[3] = 0x00; ...

Attention : le rapport HID doit être envoyé strictement selon le format défini par le descripteur, sinon Windows refusera de le reconnaître. Pour le débogage, on peut utiliser USBlyzer ou Wireshark pour capturer et vérifier le contenu du rapport.

Architecture Coopérative USB et Wi-Fi : Pratique de la Fusion de Données Multimodales

La coopération entre l'USB et le Wi-Fi n'est pas une simple addition de fonctionnalités, mais une conception systémique pour construire un "nœud de calcul en périphérie". La capacité double mode de l'ESP32-S2 permet, tout en connectant un périphérique USB, de transférer les données vers une plateforme cloud ou un terminal local via Wi-Fi, formant ainsi une boucle fermée "Acquisition USB → Traitement local → Distribution Wi-Fi".

Architecture d'un Système de Sonnette Intelligente

Prenons l'exemple d'une sonnette avec caméra USB, le système doit répondre aux exigences suivantes :

• Veille à faible consommation (réveil par capteur PIR) ;
• Capture JPEG haute définition (1280×720) ;
• Transmission d'images en temps réel (flux H.264 ou séquence JPEG) ;
• Stockage local (enregistrement en boucle sur carte TF) ;
• Notification d'événement (notification MQTT sur téléphone).

Diagramme matériel :

Capteur PIR → GPIO → ESP32-S2 → USB D+/D− → Caméra USB OV5640
                              ↓
                          SDMMC → Carte TF
                              ↓
                         Wi-Fi STA → Routeur → Cloud
                              ↓
                         Wi-Fi AP → Téléphone Mobile (Interface Web)

Répartition des tâches logicielles :

• Tâche_Capteur (priorité 10) : Acquisition UVC USB, capture une image JPEG toutes les 2 secondes, stockage dans un tampon circulaire ;
• Tâche_Traitement (priorité 9) : Lecture de l'image JPEG depuis le tampon, appel à esp_camera_fb_get() pour obtenir le buffer d'image, détection de visage (modèle TinyML) ;
• Tâche_Réseau (priorité 8) : Si un visage est détecté, lancement de esp_http_client pour télécharger le JPEG vers un Webhook, et publication d'un message MQTT ;
• Tâche_Stockage (priorité 7) : Écriture du JPEG dans le répertoire /record/ sur la carte TF, organisé par date, conservation des 7 derniers jours.

Le principal défi est la contention de bande passante entre l'USB et le Wi-Fi. Lors de tests, lorsque l'USB capture du JPEG VGA à 30 images/s (taille moyenne de 40 Ko/image), l'envoi Wi-Fi peut entraîner une perte de paquets due à une file d'attente esp_wifi_internal_tx pleine. Les solutions :

• Réduire la fréquence d'acquisition USB à 5 images/s (mode veille) ;
• Passer à 15 images/s (mode capture) après une détection de visage réussie ;
• Utiliser tcpip_adapter_set_default_eth_handlers() pour enregistrer un rappel d'événement ETH_CMDQ_FULL, et ajuster dynamiquement la taille du tampon DMA USB.

Passerelle IoT : Double Redondance de Liaison 4G+Wi-Fi

Sur un site industriel, une seule liaison réseau n'est pas fiable. L'ESP32-S2 peut construire une passerelle double mode avec une liaison 4G (principale) et Wi-Fi (de secours) :

• En fonctionnement normal, le module 4G se connecte et toutes les données MQTT sont envoyées via la 4G ;
• Si AT+QIACT expire ou si le taux de perte de paquets ping > 30 %, le système bascule automatiquement en mode Wi-Fi STA et se connecte à un point d'accès prédéfini ;
• Le processus de basculement doit garantir que la connexion TCP ne soit pas interrompue : utiliser mqtt_client_reconnect_on_failure(true) et déclencher le changement de liaison dans l'événement MQTT_EVENT_DISCONNECTED.

L'USB joue ici le rôle d'interface de configuration : il reçoit via CDC ACM une configuration JSON envoyée par un PC (par exemple, APN, SSID/PSK Wi-Fi, adresse du broker MQTT), la stocke dans la NVS, évitant ainsi de devoir reflasher le firmware à chaque modification. Format de la commande de configuration :

{"wifi":{"ssid":"MyAP","password":"12345678"},"mqtt":{"broker":"192.168.1.100:1883"}}

Après analyse, les données sont écrites via nvs_set_str et le système redémarre pour les appliquer.

Lors du déploiement réel d'une passerelle de surveillance agricole, j'ai rencontré le problème fréquent de déconnexion du module 4G lors de jours de pluie à cause de l'atténuation du signal. En ajustant dynamiquement le seuil d'intensité du signal via USB (AT+QENG="servingcell", de -105 dBm à -110 dBm) et en réduisant le délai de basculement Wi-Fi de 5 à 2 secondes, le temps d'indisponibilité réseau est passé de 12 minutes par jour à 47 secondes. Ce détail souligne l'irremplaçabilité de l'interface de configuration USB dans la maintenance sur le terrain : sans ouvrir le boîtier, un simple câble USB permet d'optimiser les paramètres.

Pièges d'Ingénierie et Astuces de Débogage Pratique

La fonctionnalité USB de l'ESP32-S2 est puissante, mais elle présente plusieurs pièges cachés qui nécessitent une combinaison d'oscilloscope, d'analyseur de protocole USB et de journaux IDF pour un dépannage complet.

Défauts Courants et Analyse des Causes Racines

Défaut	Cause possible	Méthode de vérification	Solution
Le périphérique USB ne s'énumère pas (le PC ne réagit pas)	VBUS non alimenté ou tension insuffisante	Mesurer la tension D+/D- par rapport à la masse (doit être 3,3V±0,3V) avec un multimètre	Vérifier le chemin d'alimentation VBUS, s'assurer que l'entrée 5V est stable
Énumération réussie mais les données sont bloquées	Débordement du tampon du point d'extrémité USB	Capturer les paquets pour voir si le jeton IN est NAK	Augmenter la taille du tampon du point d'extrémité, vérifier le statut de usb_transfer_t
Caméra UVC écran noir	La caméra ne produit pas le format MJPEG	Utiliser USBlyzer pour vérifier si la requête Set Cur renvoie un STALL	Appeler uvc_host_set_format avant uvc_host_stream_start pour définir explicitement le format MJPEG
Réponse AT du module 4G expirée	Point d'extrémité CDC ACM mal configuré	Capturer les paquets pour voir si SET_LINE_CODING est acquitté (ACK)	Confirmer que baud_rate=115200 dans cdc_acm_host_config_t
Le périphérique MSC affiche "Besoin de formatage"	La carte SD n'est pas formatée en FAT32	Utiliser fdisk -l /dev/sdb sous Linux pour voir le type de partition	Reformater avec mkfs.fat -F32 /dev/sdb1

Configuration de la Chaîne d'Outils de Débogage

• Analyse de protocole USB : Recommandation : Ellisys USB Explorer 200. Il peut capturer les signaux différentiels D+/D-, analyser les jetons SETUP, les paquets IN/OUT, les trames SOF, etc. Surveiller particulièrement si la configuration du point d'extrémité après bRequest = 0x09 (SET_CONFIGURATION) est réussie ;
• Surveillance des tâches FreeRTOS : Activer CONFIG_FREERTOS_USE_TRACE_FACILITY, utiliser vTaskList pour afficher la pile restante et le temps d'exécution de chaque tâche, identifier si une tâche USB est préemptée pendant une longue période par une tâche de haute priorité ;
• Journaux USB améliorés : Activer CONFIG_USB_OTG_ENABLED et CONFIG_USB_SERIAL_JTAG_CONSOLE dans sdkconfig. Lors de la compilation, ajouter -DLOG_LOCAL_LEVEL=ESP_LOG_DEBUG pour visualiser les journaux usbh et usbd ;
• Test d'intégrité de l'alimentation : Utiliser un oscilloscope pour observer la chute de tension VBUS au moment de l'énumération. Si la chute est > 0,5 V, placer un condensateur électrolytique de 470 μF et un condensateur céramique de 100 nF en parallèle à l'entrée VBUS.

Pour terminer, voici un cas réel : lors d'un projet client, la caméra USB ne démarrait pas à basse température (-20°C). La capture de paquets a montré que le périphérique retournait un STALL au stade GET_DESCRIPTOR. Après enquête, le cristal interne de la caméra OV5640 avait du mal à osciller à basse température, empêchant la génération correcte du descripteur USB. La solution a été de placer un condensateur de 100 nF entre VCC et GND de la caméra, et d'ajouter un délai de 500 ms dans app_main() avant d'exécuter uvc_host_init() pour permettre à la caméra de se stabiliser. Ce piège nous rappelle que la robustesse de la pile protocolaire USB dépend en fin de compte du maillon le plus faible, qu'il s'agisse d'une puce ou d'un périphérique.