if et and

        if (c < 190000 && tft.readPixel(PosX + 10 , 259) != RED)//pression insuffisante
        { 
          for (byte a = 41; a < 60; a++) tft.drawCircle(PosX + 60, 259, a, RED);//Colora le gomme in ROSSO
        }

si c => 190000 est ce que tft.readPixel(PosX + 10 , 259) != RED va être analysé quand même?

Bonjour,

Non.
Si la première partie de la condition est fausse, l'évaluation s'arrête car la condition totale est forcément fausse.

Donc c'est mieux que je invertie le 2 condition. Merci kamill

Qu’est-ce que ça va changer si c => 190000 ? Vous allez faire une opération coureuse en temps pour rien....

Attention à vos valeurs magiques - je serais tenté d’écrire 190000L ou 190000UL pour forcer le type

Vous allez faire une opération coureuse en temps pour rien.

Pas compris!!

La partie complète

        if (c < 190000 && tft.readPixel(PosX + 10 , 259) != RED)//pression insuffisante tft.readPixel(posxa + 6 , posya)
        { 
          for (byte a = 41; a < 60; a++) tft.drawCircle(PosX + 60, 259, a, RED);//Colora le gomme in ROSSO
        }
        else if (c > 249999 && tft.readPixel(PosX + 10 , 259) != BLUE)// Pression elevée
        {
          for (byte a = 41; a < 60; a++) tft.drawCircle(PosX + 60, 259, a, BLUE);//Colora le gomme in BLU
        }
        else if (c < 250000 && c > 189999 && tft.readPixel(PosX + 10 , 259) != GREEN) //pression optimale
        {
          for (byte a = 41; a < 60; a++) tft.drawCircle(PosX + 60, 259, a, GREEN);//Colora le gomme in VERDE
        }

:
Voyons le 3me else
c'est toujours c < 250000
c'est toujours c > 189000
ce n'est jamais tft.readPixel(PosX + 10 , 259) != GREEN (sauf au démarrage quand la partie est encore noire)
J'irais plus loin: le 3me else il faut le mettre en 1er!

je serais tenté d'écrire 190000L ou 190000UL

OK

Je voulais écrire “coûteuse” pas « coureuse » :slight_smile: et Je pensais que vous vouliez inverser le test dans le If, mettre le tft.readPixel() en premier.

Piurquoi ne stockez vous pas le resultat de tft.readPixel(PosX + 10 , 259)?
qui est une opération coûteuse en temps ( et ça éviterait de parier sur les performances d'un optimiseur): appel sous programme, interfaçage avec le tft, retour fonction...)

c'est ce que j'avais fait dans un premier temps en utilisant une variable globale.
Mais comme j'ai des problème "psychologique" avec les variables globales, j'essaye toujours de les supprimer.
Pourquoi? Je ne sais pas!
Je vais revenir à la première méthode.

Je pensais que vous vouliez inverser le test

Oui, oui, c'est ce que je voulais faire!

Pourquoi globale ? Son scope pourrait être limité à la zone des if avec un bloc {}

byte PneuAv = 0

C'etait comme ca:

        if (c < 190000 && PneuAv != 1)//pression insuffisante tft.readPixel(posxa + 6 , posya)
        {
          for (byte a = 41; a < 60; a++) tft.drawCircle(PosX + 60, 259, a, RED);//Colora le gomme in ROSSO
          PneuAv = 1;
        }
        if (............PneuAv != 2)
        {
          .......
         PneuAV = 2;
       }
        if (............PneuAv != 3)
        {
          .......
         PneuAV = 3;
       }

Que se passe-t-il si vous mettez byte PneuAv=0 juste avant son calcul et votre batterie de tests et que voue mettiez un { devant cette declaration (et un } après tous les tests)

Normalement, vous en avez fait une variable locale...
Les contestations liées au fait que les variable globales occupent une place fixe (avantage : on sait ce qu'on consomme en RAM dès la compilation; inconvénient: on se place dans un pire des cas ) n'ont pas lieu d'être pour un byte....

Je pense que je n'ai pas été clair.
byte PneuAv=0 est une variable globale

mise en place pour éviter le coloriage à chaque passage.