Probleme bizarre avec LM35 dans une boucle

Bonjour à tous.
Je travaille actuellement sur un projet assez lourd qui me tient à coeur.
J'en suis à la phase des derniers tests et tout semble fonctionner parfaitement, excepte .... Mais plutot qu'un long discours je poste un exemple de ce qui se passe (ce n'est pas le PDE complet, mais le fonctionnement et ce qui me semble un bug reste identique) :

#define pinTemp 0                                /* analog pin                                          */
int temp ;                                       /* temperature                                         */
#define Ref 1.1                                  /* Analog Reference interne = 1.1V                     */
int samples[10];                                  /* variables pour une meilleure precision precision    */
int k ;                                                                            /* compteur de boucle */



int MesureTemp()
{
  int tempc=0;
  for(int i = 0;i<=10;i++)                                           /* 10 echantillons de la temperature */
   {
     samples[i] = ( Ref * analogRead(pinTemp) * 100.0) / 1024.0;
     tempc = tempc + samples[i];
     delay(200);
   }
  tempc = tempc/10 ;
  return tempc ;
}


void setup()
  {
   
    analogReference(INTERNAL) ;                         /* tension de reference fixee a 1,1V en interne */
    Serial.begin(19200) ;    /* POUR DEBOGUAGE  */
  }
 
 
 void loop()
   {
     temp=MesureTemp() ;
     Serial.print("Temperature = ") ;
     Serial.println(temp) ;
     delay(2000) ;
     k++;
     Serial.print("k = ") ;
     Serial.println(k) ;
     if (k==90) ;
       {
         k=0 ;
       }
     
   }

j ouvre le terminal pour suivre l'evolution des choses et ô surprise ..... Mais surveillez le comportement de la variable de boucle "k".

le delay(2000) est necessaire dans mon PDE complet et je ne peux pas utiliser une boucle for(...;...;...) , d'ou la structure pas tres orthodoxe de ma boucle .

Si quelqu'un a une explication de ce phénomène , et mieux , s'il peut me dire comment résoudre le problème, je suis preneur..

Je précise que j'utilise une Diecimila (donc avec un ATmega168) et le capteur de température est un LM35DZ

j ouvre le terminal pour suivre l'evolution des choses et ô surprise ..... Mais surveillez le comportement de la variable de boucle "k".

Euh j'ai pas compris, c'est quoi ton soucis en fait ? qu'est-ce qui ne fonctionne pas ?

Je te laisse la surprise si tu as un peu de temps devant toi. Cela vaut son pesant de cacahuetes.
Regarde simplement comment évolue la variable de boucle "k" .

Je me bats avec ce problème depuis 2 jours et je m'arrache les cheveux (deja qu'il ne m'en reste plus beaucoup !)

je pense qu il faut l 'essayer pour voir si cela se produit uniquement dans mon cas (ce serait peut etre une defaillance de mon ATmega)

Bonsoir,

if (k==90) ;
Sans le ; après le if, la variable k se comporte bien :slight_smile:

C'est vrai, mais ça ne resoud pas mon pb, car je l'ai dans mon pde complet. Je continue a investiguer et si j ai la reponse je la posterai ici.
merci quand même.
Je suis confus pour le ";" apres le if.

Déjà je vois un problème :

int samples[10]; et for(int i = 0;i<=10;i++)

L'index max pour "samples" est 9 (numérotation à partir de 0) donc dans ta boucle, quand i=10 binnnn il accède à un secteur mémoire hasardeux ...

il accède à un secteur mémoire hasardeux

et comme k et déclaré juste après samples[10] ....

Bonjour,

Effectivement, ton problème se situe dans ton 'for'. Tu déclares un tableau de 10 int, puis un int, pour ensuite accéder à la 11ème valeur du tableau quand tu fais samples [ i ] = ... avec i = 10.
Si tu arrêtes ton for à 9, tu résous par là même ton problème.

A condition également d'enlever le ';' après ton if(k==90), sinon, tu neutralises la remise à zéro de k.

En espérant t'avoir aidé,

Bonne journée.


Stéphane

Tout d'abord, merci à tous et bravo pour votre aide
Je précise que le ";" n'etait pas en cause dans mon programme. Il s'est invité dans ce topic de façon inattendue.
Le "samples[10] me parait beaucoup plus en cause. Je vais tester ça en fin d'aprés midi, mais je crois que la réponse est là. La seconde solution serait un ATmega Hanté, mais je n'y crois pas trop :slight_smile:

Re-merci à tous et à bientot