Cette librairie est utilisé par le système actuel qui est équipé du même écran. J’avais créé il y a quelques années un tel circuit que je m’apprête à remplacer par un nouveau plus près de ce qui se fait maintenant. Il n"‘y a aucun secret, ce système est l’électronique d’un portail à 2 ventaux. Là où j’utilisai des relais, maintenant ce sera des ponts en H MOSFET.
J’ai mis en doute l’écran que je voulais utiliser, alors j’ai testé avec un autre, pareil, l’écran reste noir.
Delay n’interdit pas les interruptions et votre code bloque aussi… il est juste moins précis que delay()… (et le paramètre serait mieux en unsigned long aussi)
Merci pour la suggestion, et en effet j’aurai pu mettre unsigned long pour le paramètre.
Ce qui a justifié cela jusque là c’est que je n’ai jamais utilisé cette fonction pour de grande valeur.
Par contre je maintient “delay” bloque tout et empêche le processeur d’aller plus loin, j’en ai fais l’expérience il y a déjà longtemps et c’est pour cela que j’utilise ma fonction à la place.
Quoi qu’il en soit, comme je l’ai dis plus haut, le programme fonctionne, le serveur web m’envoit bien les pages etc… Donc le programme ne bloque pas. La seule chose qui doit se passer, c’est que l’écran n’est pas vu par le programme.
J’ai testé les différents écrans à ma disposition avec un programme exemple de la librairie et je n’ai rien. J’ai vérifié, la librairie est compatible et je n’avais jamais eu de problème avec. Je vais tester par un programme qui recherche les objets i2c et donne leur adresse, je verrai si le fabricant de ces écrans a utilisé l’adresse par défaut habituelle. Je reviendrai donner des nouvelles.
Merci à tous.
delay() attend a l’endroit du code où vous l’appelez - tout comme votre boucle qui est bloquante . Donc oui ça bloque le thread a cet endroit. Votre code est à peu près précis mais comme millis() ne l’est pas (on peu sauter une ms de temps en temps) vous êtes moins précis que la fonction delay.
Je suis sûr et certain que delay() n’empêche pas les interruptions . Si vous voulez vous en convaincre essayez ce code
void setup() {
Serial.begin(9600);
Serial.print("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz");
delay(10000);
Serial.print("fin du code");
}
void loop() {}
À 9600 bauds on sort 1 caractère par ms donc il faudra 52 ms pour imprimer tout le message
Print n’est pas bloquant donc quelques nanosecondes après avoir mis le message dans le buffer de sortie de Serial vous appelez delay pour 10s et pendant que le code principal dort, l’impression de fera quand même parce que les interruptions de l’UART (port série) sont tout à fait fonctionnelles et que dès qu’un caractère a été émis il y a l’interruption qui arrive pour aller chercher le suivant .
Avez vous des résistances de pullup adéquates pour l’I2C ?
Bon, voici les dernières nouvelles, j’ai changé de processeur, toujours 38 broches mais en ESP-WROOM-32 au lieu de ESP-32D et l’écran fonctionne bien. Est-ce que le fait d’utiliser “DOIT ESP32 DEVKIT V1” n’est pas adapté, je ne sais pas, ce processeur est plus récent que le WROOM et il faut peut-être utiliser autre chose dans l’IDE Arduino. Je vais rester sur le WROOM puisque l’écran fonctionne, mais le port série c’est pas top, je perd des lignes d’informations.
void setup() {
Serial.begin(115200);
Wait(500);
Serial.println();
Serial.println(F("*** Start ***"));
Serial.flush();
Serial.println(F("Début des déclarations"));
Serial.flush();
pinMode(cdePortail, INPUT_PULLUP);
pinMode(cdeVantail, INPUT_PULLUP);
pinMode(cdeLumExt, INPUT_PULLUP);
pinMode(InfoLumExt, INPUT_PULLUP);
pinMode(Haut, INPUT_PULLUP);
pinMode(Bas, INPUT_PULLUP);
pinMode(relVerrou, OUTPUT);
pinMode(relLumExt, OUTPUT);
pinMode(LEDd, OUTPUT);
pinMode(LEDg, OUTPUT);
pinMode(LED, OUTPUT);
pinMode(pwmRightDroit, OUTPUT); // PWM sens à DROITE moteur vantail droit.
pinMode(pwmLeftDroit, OUTPUT); // PWM sens à GAUCHE moteur vantail droit.
pinMode(pwmLeftGauche, OUTPUT); // PWM sens à GAUCHE moteur vantail gauche.
pinMode(pwmRightGauche, OUTPUT); // PWM sens à DROITE moteur vantail gauche.
analogWriteResolution(pwmRightDroit, 8);
analogWriteResolution(pwmLeftDroit, 8);
analogWriteResolution(pwmLeftGauche, 8);
analogWriteResolution(pwmRightGauche, 8);
analogWriteFrequency(pwmRightDroit, 20000);
analogWriteFrequency(pwmLeftDroit, 20000);
analogWriteFrequency(pwmLeftGauche, 20000);
analogWriteFrequency(pwmRightGauche, 20000);
analogReadResolution(8);
digitalWrite(LED, HIGH);
StopMoteur(0); // 0 = Tous les moteurs
Serial.println(F("Déclarations terminées"));
Serial.flush();
Ceci est le début du SETUP, est-ce que quelques choses n’est pas correcte?
J’ai mis des flush pour forcer l’affichage et malgré tout je n’ai pas les prints dans la console série, bizarre non?
ets Jul 29 2019 12:21:46
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:4744
load:0x40078000,len:15672
load:0x40080400,len:3152
entry 0x4008059c
*** Start ***
Début des déclarations
Je n’obtient que ça.
Que fait ce code ?
Les autres, instructions entre le print et celle-ci ne risquent pas de planter
Pas grand chose en dehors d’arrêter les moteurs (0 pour all)
/* Commande d'arrêt des moteurs */
void StopMoteur(byte Moteur) {
Serial.println(F("Stop moteur"));
if (Moteur == 0) {
analogWrite(pwmRightDroit, 0);
analogWrite(pwmLeftDroit, 0);
analogWrite(pwmRightGauche, 0);
analogWrite(pwmLeftGauche, 0);
}
if (Moteur == MotGauche) {
analogWrite(pwmRightGauche, 0);
analogWrite(pwmLeftGauche, 0);
}
if (Moteur == MotDroit) {
analogWrite(pwmRightDroit, 0);
analogWrite(pwmLeftDroit, 0);
}
}
As-tu fais ce que je t'ai proposé et qui n'est vraiment pas compliqué à faire :
Ça prend 2 secondes :
Juste après la programmation, tu attends que le programme s'exécute.
Constat : Tu ne vois rien.
Alors, sans toucher à rien, tu fais un reset.
Si tu as les affichages, c'est ce que je soupçonne.
Si tu n'as toujours pas les affichages, c'est un autre problème...........ou tu as plusieurs problèmes.
Ne cherchons plus, mea culpa, mea maxima culpa!
J’utilise TX du port série pour la commande d’une LED, du coup le pinMode(1, OUTPUT);
écrase la transmission, j’ai mis en rem cette ligne et j’ai la console série qui fonctionne mieux que bien.
Bon reste à trouver une autre manière de faire, tous les GPIOs disponibles étant utilisés je n’ai pas beaucoup d’options pour cette LED. Je vais peut-être rajouter un CI que je piloterai pour la commande des 3 LEDs. A réfléchir.
Encore merci pour toute l’aide apporté ici et cela m’a fais mettre le doigt sur un processeur à explorer (ESP-32D)
As-tu fais ce que je t'ai proposé et qui n'est vraiment pas compliqué à faire
Oui, j’avais testé sans succès.
Oui, c'est souvent ce qu'il se passe lorsqu'on ne publie que des morceaux de code. Les aidants ne peuvent pas voir ce qu'on ne leur montre pas.
Finalement, je vais utiliser un PCF8574 qui me donne 8 GPIO de plus en I2C. Dommage qu’on ne puisse pas utiliser toutes les pins du module ESP32 8 à 11 sont present mais ne sont pas utilisable car relié à la flash interne, pourquoi les avoir mis alors??? Les concepteurs de module ont de drôle d’idée parfois.
Bon me voila sortie d’affaire, de toute façon, je devais refaire faire mon circuit imprimé à cause d’une bourde qui n’a rien à voir ici.
Merci pour l’aide, parler d’un problème à plusieurs permet de mettre le doigt là où ça fait mal.
Prend plutôt un MP23017 (16 bits, existe aussi en 8 bits)
Le PCF est "un peu vieux" et surtout, galère quand on l'utilise en mode entrée.
Avec le MCP, tu auras l'impression de gérer des gpios de micro.
Il existe aussi en mode SPI.
C'est sûr puisque depuis tu as donné la raison 
Ne cherchons plus, mea culpa, mea maxima culpa!
J’ai déjà modifié mon circuit imprimé, et j’ai aussi des PCF8574 dans mes tiroirs.
Je prend note du MP23017 je regarde le datasheet et je vérifierai si j’en ai pas aussi, sinon je commande, ça peut toujours servir.
Merci.
C'est une très bonne raison pour les utiliser.
Au final, j’ai aussi des MCP23017 en 8 et 16 bits, mais j’ai déjà tout modifié, même le programme.
Merci beaucoup pour tous ces échanges constructifs