ESP32-S3 et liaison série : sans ou avec HardwareSerial ?

Bonsoir !

Ce message s'adresse surtout à ceux qui connaissent bien le fonctionnement de l'ESP32 (un S3 dans le cas présent)
Je suis en train de faire communiquer un module GPS avec un ESP32-S3 Lilygo T7-S3 dont voici le brochage :

J'ai essayé ce code avec HardWareSerial :

// Essai module GPS avec ESP32 avec HardwareSerial

const int RXPin = 44, TXPin = 43;  //  GPIO44 et GPIO43
const uint32_t GPSBaud = 19200;

HardwareSerial gps_serial(1);  // 1 = UART 2, 2 = UART 3

void setup()
{
  Serial.begin(115200);
  delay(1000);
  gps_serial.begin(GPSBaud, SERIAL_8N1, RXPin, TXPin);
  delay(1000);
  gps_serial.println("$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28");
}

void loop()
{
  while (gps_serial.available() > 0)
  {
    // réception des données
    byte gpsData = gps_serial.read();
    Serial.write(gpsData);
  }
}

J'ai aussi essayé ce code sans HardwareSerial :

// Essai module GPS avec ESP32 sans HardwareSerial

const int RXPin = 44, TXPin = 43;  // GPIO44 et GPIO43
const uint32_t GPSBaud = 19200;

void setup()
{
  Serial.begin(115200);
  delay(1000);
  Serial1.begin(GPSBaud, SERIAL_8N1, RXPin, TXPin);
  delay(1000);
  Serial1.println("$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28");
}

void loop()
{
  while (Serial1.available() > 0)
  {
    // get the byte data from the GPS
    byte gpsData = Serial1.read();
    Serial.write(gpsData);
  }
}

Ce qui m'étonne c'est que les deux versions fonctionnes parfaitement !
Dans la version avec HardwareSerial je peux changer la commande HardwareSerial gps_serial(1); en HardwareSerial gps_serial(2); ça fonctionne toujours

Dans la version sans HardwareSerial je peux remplacer Serial1 par Serial2 et ça fonctionne encore.

Dans les deux cas, je peux remplacer les GPIO 43 et 44 (GPIOs par défaut pour Rx et Tx d'après le brochage de ma carte) par d'autres GPIO ça fonctionne toujours, autant en émission qu'en réception (j'utilise les deux)

En fait j'aimerai bien comprendre comment l'ESP32-S3 interprète les deux sketchs.
Est-ce que dans le cas sans HardwareSerial il va quand même l'utiliser en "comprenant" le code ?
Où est-ce qu'il y a une différence dans la manière de fonctionner qui m'échappe ?

Et autre question, y a-t-il une vraie raison que sur un ESP32-S3 il y ait des GPIO (43 et 44 ici) qui sont indiqués comme Rx et Tx ?

Merci d'avance à ceux qui pourront m'éclairer !

Roland

Il est intéressant de regarder le fichier HardwareSerial.h qui définit pas mal de choses :

Par exemple, il définit des valeurs par défaut de RX0, TX0, RX1, TX1 en fonction de l'ESP32 utilisé :
pour RX0

#ifndef SOC_RX0
  #if CONFIG_IDF_TARGET_ESP32
    #define SOC_RX0 (gpio_num_t)3
  #elif CONFIG_IDF_TARGET_ESP32S2 || CONFIG_IDF_TARGET_ESP32S3
    #define SOC_RX0 (gpio_num_t)44
  #elif CONFIG_IDF_TARGET_ESP32C2
    #define SOC_RX0 (gpio_num_t)19
  #elif CONFIG_IDF_TARGET_ESP32C3
    #define SOC_RX0 (gpio_num_t)20
  #elif CONFIG_IDF_TARGET_ESP32C6
    #define SOC_RX0 (gpio_num_t)17
  #elif CONFIG_IDF_TARGET_ESP32H2
    #define SOC_RX0 (gpio_num_t)23
  #endif
#endif

On retrouve le 44 pour l'ESP32S3, idem pour le TX0 à 43, RX1 à 15 et TX1 à 16. Pour ces deux là, c'est différent de ce qui est écrit sur ta carte (18 et 17) et dans la datasheet du ESP32S3. Je ne sais pas pourquoi...

Le begin est ici :
void begin(unsigned long baud, uint32_t config=SERIAL_8N1, int8_t rxPin=-1, int8_t txPin=-1, bool invert=false, unsigned long timeout_ms = 20000UL, uint8_t rxfifo_full_thrhd = 112);
Visiblement, tu peux définir les GPIO que tu veux.

Il semble (je n'ai pas testé) que si tu donnes 0 pour le baudrate, il le détecte automatiquement.

Bonsoir

ce que j'ai compris

'avec ou sans hardware serial' ? choix résultant de l'évolution du core ESP32 dans le sens de la simplicité.
A partir d'un certaine version il est devenu possible de ne plus passer explicitement par hardwareSerial pour accéder au second UART ou au troisième s'il existe comme dans le cas de la version -S3
On peut utiliser désormais au choix l'ancienne ou la nouvelle méthode (inconnue des 'vieux tutos' :wink:)

'Pourquoi indiquer RX et TX en un endroit précis si les E/S des Uarts peuvent être logées n'importe ou ? '

En amont du code , le bootloader utilise le premier UART sur 2 GPIO spécifiques pour son fonctionnement, il faut l'indiquer sur la carte pour savoir par où flasher le code si on ne souhaite pas le faire par l' USB natif.
GPIO43 et GPIO44 correspond à ce choix pour ce premier Uart qui , correspond par la suite dans nos codes à Serial()

Dans mon cas les GPIO 43 et 44 sont ceux branchés sur le module GPS (HardwareSerial(1) ou Serial1), et je visualise à l'écran par Serial
Ce n'est pas par le même UART que Serial à priori.
Donc d'après toi l'UART qui sert à télécharger le code serait sur les GPIO 43 et 44 (sur lesquels est déjà le GPS qui "crache" ses données toutes les secondes) ?
P.S. Je ne mets pas en doute ce que tu dis, j'aimerai juste comprendre !

Roland

les choses sont un peu moins simples qu'écris au dessus....
elles dépendent du fait d'activer ou pas 'cdc_on_boot ' dans l'IDE si mes souvenirs sont bons

si activé Serial est attribué non pas à un Uart mais au port série par l'usb natif (ton cas)
Si non activé Serial() correspond au premier uart débouchant en 34 et 44

j'avais fait ce genre de constatation avec une carte ESP32-S2 dotée de deux embases USB

CDC on boot est bein "énablé" chez moi. Sinon le moniteur série ne fonctionne pas !

Roland

pas avec ta carte actuellement vu que le flashage se fait par l'usb natif, (GPIO 19 et 20)
mais si tu connectais un adaptateur usb série (FTDI ou equiv) en 43 et 44 je pense que tu devrais pouvoir aussi flasher par cette voie !
genre de choses qu'on peut s'amuser à faire avec des cartes DevkitC ESP32-S3 a deux embases USB

Merci à vous deux @lesept et @al1fch pour vos éclairages !

Si je comprends bien, je peux donc utiliser les 2 méthodes (avec ou sans HardwareSerial) sans problème.

Roland

je ne vois pas de problème, utilises la méthode que tu préfères

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.