Il y a quand même quelque chose que je ne comprend pas :
Si ptr pointe sur l'adresse de la variable "valeur" il devrait avoir la même adresse .
Vous faites
ptr = &valeur ;
Serial.printf("adresse valeur = %p \n", &valeur);
Serial.printf("adresse ptr = %p \n", &ptr);
Quand vous regardez valeur, c'est une variable et vous avez alloué 4 octets (uint32_t) pour stocker le nombre (48 ici). Ces 4 octets sont rangés quelque part en mémoire, la première case mémoire est ce qu'on appelle l'adresse de la variable (et l'ordre des octets dans ces cases dépend de l'architecture little ou big endian).
Il en va de même pour ptr. C'est une variable, donc comme toute variable il a besoin d'espace mémoire pour ranger son contenu qui ici sera l'adresse mémoire de la variable valeur. Ce contenu se trouve à une certaine adresse
donc dans les octets réservés pour la variable ptr1, vous avez l'adresse de valeur et ces octets sont stockés forcément ailleurs. c'est pour cela que ce n'est pas le même nombre que vous imprimez.
si vous aviez imprimé le contenu du pointeur et non pas son adresse
printf("adresse valeur = %p \n",&valeur);
printf("adresse ptr = %p \n",ptr1);
là vous devriez voir la même adresse mémoire.
Or je remarque que sur le PC l'adresse du pointeur est décallé de +2 et sur l'ESP32 elle est décalée de -4.
Non pas +2 
Vous avez oublié que vous êtes en hexadécimal donc après 9 il y a A,B,C,D,E,F avant le 0
donc ce que vous voyez
valeur initiale = 48
adresse valeur = 0x5637d64ef048
adresse ptr = 0x5637d64ef050
valeur finale pt1 = 56
qui veut dire que c'est rangé comme cela en mémoire.
Sur l'ESP32 vous voyez ceci
valeur initiale = 48
adresse valeur = 0x3ffc00b8
adresse ptr = 0x3ffc00b4
valeur finale valeur = 56
qui veut dire que c'est rangé comme cela en mémoire.
Le nombre d'octet pour représenter une adresse dépend de la plateforme: sur un UNO c'est 2 octets, sur un ESP32 c'est 4 octets et sur votre PC vous êtes en architecture 64 bits et c'est 8 octets.
De plus à la compilation l'endroit où on range les données peut se faire de bas en haut ou de haut en bas dans l'ordre où on les rencontre et elles ne sont pas forcément contigües le compilateur aimant bien que les adresses tombent sur des multiples de la taille de l'architecture donc sur le PC de 8 en 8 et sur l'ESP de 4 en 4. c'est pour cela que le pointeur et la variable valeur sont côte à côte en mémoire sur l'ESP alors qu'il y a un "trou" (mémoire non utilisée) sur le PC entre les 2.
Pour ce point
Quand j'ai tenté d'appliquer aux registres de l'ESP j'obtenais un message d'erreur que j'obtiens toujours avec les indications de J-M-L.
volatile uint32_t *TIM0_BLOC0 = 0x3FF5F000;
void setup() {}
void loop() {}
J'obtiens le message d'erreur :
registres_timer_forum1:5:34: error: invalid conversion from 'int' to 'volatile uint32_t* {aka volatile unsigned int*}' [-fpermissive]
volatile uint32_t *TIM0_BLOC0 = 0x3FF5F000;
^
exit status 1
invalid conversion from 'int' to 'volatile uint32_t* {aka volatile unsigned int*}' [-fpermissive]
c'est effectivement que le compilateur est un peu plus sensible et qu'il faut sans doute faire un cast de la valeur numérique en adresse mémoire lors de l'affectation. essayez
volatile uint32_t* TIM0_BLOC0 = (uint32_t*) 0x3FF5F000;
void setup() {}
void loop() {}
concernant
J'obtiens quand même l'accès en lecture en utilisant un #define TIM0_B0 0x3FF5F000 comme j'en ai vu l'emploi dans le fichier soc.h.
....
Par contre dès que je veux modifier le contenu de ce registre (fonction configT0B0) j'obtiens le message d'erreur :
c'est normal, souvenez vous qu'un #define est remplacé syntaxiquement avant la compilation donc votre
uint32_t modif= 0b1100000000000000;
TIM0_B0 |= modif;
va devenir
uint32_t modif= 0b1100000000000000;
0x3FF5F000 |= modif;
--> 0x3FF5F000 est vu comme un entier et un entier ne peut pas se trouver à gauche d'une affectation. avec
volatile uint32_t* TIM0_BLOC0 = (uint32_t*) 0x3FF5F000;
vous devriez pouvoir effectuer un
const uint32_t modif= 0b1100000000000000;
*TIM0_BLOC0 |= modif;
PS/ notez que pour imprimer un uint32_t avec printf on utilise pas %d qui serait bon pour un entier signé (même si ça va marcher dans votre cas car les octets seront au bon endroit et vous n'avez pas une grande valeur) mais on doit utiliser %ul
.
