Tension de référence d'un ESP32

Bonjour à toutes et à tous,

Je n'ai pas réussi à trouver ce que je cherche : existe-t-il une variable ou une constante qui représente la valeur de la tension de référence corrigée ?

Cordialement.

Pierre.

Bonjour @ChPr

Pourquoi multiplier (= disperser) les fils autour d'un même sujet : la tension de référence des ADC d'un ESP32 ?

Fil de discussion déjà ouvert : https://forum.arduino.cc/t/modifier-la-tension-de-reference-dun-esp32/1329509

en cherchant une réponse fonctionnelle à ta question (récupérer dans le code Arduino la valeur de eFuse Vref) je suis tombé sur autre chose qui te sera peut être utile :

Router Vref vers un GPIO pour mesurer sa valeur :slightly_smiling_face:

faute d'ESP32 d'après 2017 j'ai testé avec un ESP32-S2 avec le code ci dessous
je lis sur GPIO16 avec un multimètre :
pour l'ADC1 1,083 V
pour l'ADC2 1,105 V
(chacun des ADC a sa référence)

// Router Vref vers un GPIO quelconque pour mesurer sa valeur
// source    https://esp32.com/viewtopic.php?t=37920


#include <driver/adc.h>  //ADC driver or include esp_adc_cal.h Both work

void setup() {
  esp_err_t status = adc_vref_to_gpio(ADC_UNIT_2, GPIO_NUM_16);
  if (status == ESP_OK) {
    printf("\nv_ref routed to desired GPIO\n");
  } else {
    printf("failed to route v_ref\n");
  }
}

void loop() {
}

Pour information : la tolérance sur la valeur de la tension de référence 1,1V des ATMega328 est identique à celle des ESP32 (Data Sheet p 261)
image
Reserrer la tolérance nécessitterait un ajustage de chaque wafer (au laser) et augmenterait le coût.

Bonsoir "al1fch"

J'ai essayé le code que tu m'as indiqué : ça me donne tout un tas d'insanités. Ça reboot en permanence pour recommencer ces insanités, et il n'y a rien sur le GPIO16.

J'ai suivi le liens qui est donné (que j'avais vu, mais je m'étais arrêté à la première réponse qui me paraissait trop compliqué pour moi) et je suis allé un peu plus loin et j'ai essayé le code du post #6 :

#include "esp_adc_cal.h"
....
  esp_adc_cal_characteristics_t adc_chars;                                                        //declaring ADC calibration variable adc_chars
  esp_adc_cal_characterize(ADC_UNIT_1, ADC_ATTEN_DB_11, ADC_WIDTH_BIT_12, 1100, &adc_chars);      //characterizing the ADC calibration function ADC_UNIT_1 or ADC_UNIT_2
  Serial.println(); Serial.print("eFuse-Vref:"); Serial.print(adc_chars.vref); Serial.println();  //reading the actual internal refference voltage  // put your setup code here, to run once:

Ce code fonctionne très bien et j’obtiens pour mon ESP32
: 1093 mV.

Cordialement.

Pierre.

:+1:

avec mon ESP32 de 2017 pas de reboot cyclique mais le message indiquant que le routage de Vref a échoué

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:4604
ho 0 tail 12 room 4
load:0x40078000,len:15488
load:0x40080400,len:4
load:0x40080404,len:3180
entry 0x400805b8
failed to route v_ref

pour ce routage de VRef vers un GPIO il y a sans soute des conditions à remplir......

J'ai fait un test de linéarité avec un ESP32 en utilisant les deux méthodes : analogRead() et analogReadMilliVolts(). Je me suis placé en mode 12 bits sans atténuation. Pour la méthode analogRead() j'ai utilisé un coefficient multiplicateur égal à Vréf/4095 où Vréf est la tension de référence réelle retournée par le code vu plus haut, soit 1093 mV.

Les deux courbes sont à peu près linéaire à ceci près :

  • avec analogReadMilliVolts() j'ai un gain sensiblement égal à 1
  • avec analogRead() j'ai un gain de 1.12 !

Je ne comprends pas. Dans la mesure où analogReadMilliVolts() utilise aussi la tension de référence réelle, il ne devrait pas y avoir de différence.

Cordialement.

Pierre.

Bonsoir

C'est déjà un bon point pour la fonction analogReadMillivolts() !

Le fonctionnement d'analogRead() est en effet surprennant !!
Quelque chose nous échappe encore, l'étude du code des fonctions analogRead() et analogReadMillivolts() donnerait sans doute des réponses. La seconde fonction est complexe et ne se contente pas de récupérer en mémoire OTP une déviation de Vref par rapport à la valeur nominale

Sans atténuation et avec une résolution de 12 bits quelle est la valeur de la tension pour laquelle analogRead() donne la valeur 4096/2 ?
Un petit test vient de donner avec un ESP32-S2 : 400mV
On peut en conclure que le Vref utilisé en réalité par analogRead() est le double , soit 800mV !!
Reportons cette valeur pour traiter la valeur brute donnée par analogRead() ....
le résultat en mV est très proche de celui donnée directement par analogReadMillivolts()....

analogReadMillivolts() doit faire un peu plus, où plutôt l'étalonage en usine doit faire un peu plus que la simple lecture de Vref.

Je reviens toujours à la datasheel de l'atmega328p qui est une petite merveille si on la compare à d'autres datasheets d'autres constructeurs.

Dans l'atmega328p il est très clairement expliqué les principales erreurs dans la conversion analogique numérique.

Les deux erreurs, systématiques, qui pourrait avoir été "calibrées" sur l'ESP32 sont :
l'erreur de gain et l'erreur de linéarité.

Ces deux mesures peuvent se faire sous pointes avant découpage des puces et mise en boîtier.
Les puces défectueuses reçoivent un "jet d'encre" et sont éliminées par tri optique.

J'ai fait la manip. Pour une valeur numérique de 2048, cela correspond à :

  • 571 mV réels. Ce qui voudrait dire que la tension de référence vaut 1142 mV alors qu'elle m'est donnée à 1093 mV par le logiciel.
  • 545 mV avec analogRead()
  • 553 mV avec analogReadMilliVolts()

Sur cette courbe, on voit que c'est la fonction analogReadMilliVolts() qui donne une pente similaire à la pente théorique avec toutefois un léger décalage d'une vingtaine de mV en moins.

Cela me convient bien car je fais des mesures différentielles par rapport à un point de référence (environ 600 mV) donné par un pont de résistances.

Ce qui me gêne est que cette fonction n'existe pas sur d'autres modules Arduino. Il faut que je mette des balises de compilation au cas où.

Cordialement .

Pierre.

Quel est le but de cette manip? Chercher l'offset entre valeur réelle et valeur mesurée ou établir que la valeur gravée dans la puce est bonne?

Simplement voir ce que donnaient les fonctions analogRead() et analogReadMilliVolts() en rapport avec l'entrée qui est appliquée.

Dans mon cas, comme dit précédemment, tout va bien.

Cordialement.

Pierre.

J'étais juste un peu surpris de la démarche cela correspond plutôt à la documentation fournie de ESP
analogRead()
This function is used to get the ADC raw value for a given pin/ADC channel.
This function will return analog raw value (non-calibrated).

analogReadMilliVolts()
This function is used to get ADC raw value for a given pin/ADC channel and convert it to calibrated result in millivolts.
This function will return analog value in millivolts (calibrated).

Cordialement
Olivier

La conclusion est quand même qu'au final analogReadMillivolts donne la bonne valeur alors qu'analogRead ne la donne pas.

La doc Espressif n'est donc pas juste puisqu'elle ne met pas en garde contre l' imprécision des ESP32.

analogRead, qui ne fait qu'une lecture des registres n'est pour rien au fait que l'électronique des ESP32 est déficiente.

Pour donner la bonne valeur analogReadMillivolts a besoin de mesures individuelles sur Wafer et d'une rustine logicielle qui exploite ces mesures.

Espressif devrait supprimer la fonction analogRead() puisqu'elle donne des résultats faux.

Note :
La référence de tension de 1,1 V des avr n'est pas plus précise (±10%) et ça c'est souvent oublié !
Il y a une grande différence entre AVR et ESP c'est qu'avec un avr :

  • on peut mesurer Vref → voir la datasheet,
  • un avr accepte une référence de tension extérieure comprise entre 1,1 +10 % et Vcc.

Précision de langage : pour moi, la seule référence de tension interne dans un avr est celle à 1,1V.
La position Vref_adc à Vcc tout comme Vref_adc sur connecteur sont toutes les deux des références externes.

Qestion subsidiaire :
Le comportement est-il le même avec les ESP32 basé sur le micro "à terminer" Xtensia comme les premier ESP32 et les ESP32-Sx et les micro RISC-V basés sur "on ne sait pas" quoi comme les ESP32-Cx.

Bonsoir @68tjs

Essai effectué sur un ESP32-C3 : même comportement, même 'rustine', comme si le périphérique ADC avait été conservé avec un passage à un coeur RISC-V .

Changer de coeur en gardant les périphériques (UART, ADC, Timers.....) me parait plausible,

Oui, ce n'est qu'une gestion de bibliothèques, matérielles celles-là.

Avis personnel : si Espressif n'embauche pas des "gens du matériel" et continue à tout faire soit en logiciel, soit en électronique rudimentaire, ils vont se faire doubler.

Leur fuite en avant avec toujours des nouveaux produits, (on en a la tête qui tourne), sans qu'il y ait une amélioration du matériel de base est vouée à l'échec.

Ils ont sniffer un marché.
En partant de rien, ils ont fait un produit adapté et pas cher, bel exploit.
Mais les mastodontes du secteur sont comme un super tanker : ils manœuvrent lentement, mais une fois lancé, ils sont inarrêtables.

Autre avis personnel :
Je ne suis pas convaincu que la solution en un seul CI soit la bonne.
Je verrai plus une solution à deux puces dans un même boitier.

Pour faire de telles affirmations il faudrait déjà partir de bibliothèques actuelles et pas dépréciées et regarder ce qui a été dit à chaque migration

EDIT apparemment les mises à jour sont prises en compte dans analogRead et analogReadMillivolts mais c'est un vrai travail de fourmi pour retrouver les infos

Ce qui compte pour moi, c’est une documentation claire, honnête et accessible sans faire de recherches archeologiques sur le site Espressif.

Le terme me paraît vraiment bien choisi :sweat_smile:

C'est possible, pourtant je ne crois pas qu'il ait vraiment de concurrence sur un µC avec des fonctionnalité de communication WIFI ?
Bluetooth, je n'ai jamais cherché, mais je ne crois pas non plus ?

Il y a , non j’ai vu qu’il y a au moins, un STM32Gxyz qui fait de la radio.
Certes ce n’est pas du 2 GHz, mais c’est un début.

Je persiste à penser que mélanger numérique et analogique sur une seule puce est certes un exploit technique bien réel, mais n’est pas la solution la plus appropriée. Ce n’est que mon avis conforté par certaines réalisations.

L’achat de Cypress, qui fait le WiFi utilisé dans le RP pico W, par Infineon (ex division CI de Siemens) montre que les gros regardent le marché,

Iront-ils plus loin que regarder attentivement, l’avenir le dira.

Bonjour

Fin 2024 pas de concurrence aux divers ESP32 pour un soc pris en charge par un 'core Arduino' et offrant , en 2.4 GHz, WiFi et Bluetooth

Un jour peut être ST , Nordic Semiconductor ou autres en Asie s'aventureront sur ce marché en prenant soin de supporter activement leur core Arduino, à l'image d'Espressif

ST s'en approche , sous le GHz , avec les STM32WL déjà utilisés pour LoRa et/ou Sigfox
Nordic propose des puces intégrant Bluetooth