Fonction ADC avec un AVR

**PIC sur PAC** · 25/02/2011, 22h00

Et avec la ref interne, ça donne quoi?

Si tu parles de la tension de 2.56 interne je n'ai pas testé. Par contre aucune différence entre AVCC et Aref comme source. L'instabilité est du même ordre (au ratio près de AVCC/Aref)

Par contre si Aref est donné à partir du même 5V pourri, on peux parfaitement calculer la variation du ratio de résistance

c'est ce que je fais (j'ai testé les deux solutions potar ou zener).

Ce qui est quand même surprenant c'est que c'est "stable" pour des niveaux hauts mais par pour des niveaux bas!!

**PIC sur PAC** · 25/02/2011, 22h02

Envoyé par DAUDET78

sorry, sur ton schéma, c'est une zener qui donne le Aref ... et c'est pas bon!

on fait que de se croiser dans les explications

invite98765423456 · 25/02/2011, 22h12

Envoyé par PIC sur PAC

Ok je fais cela et je fouille mon code. Je me doute bien que le compliateur n'est pas buggé mais je suis encore loin de maitriser la suite AVRstudio comme:
- Pourquoi ne peut-on pas voir certaines variables (en faite je pense que je viens de trouver la solution dans ta réponse: car elle n'existe pas suite à l'optimisation j'ai gagné

?).
- Pourquoi ne peut on pas voir les variables lorsque l'on est en mode simulation ??? Là pas d'idée

Tu dois aller dans project-> configuration options ->optimisation qui est mis à -Os par défaut et le remettre à -O0.

Il se peut peut des autres raisons:
- déclare systématiquement tes variables en "volatile" afin que le compilo ne les élimine pas si il *croit* qu' elles ne servent à rien
- Les variables locales des fonctions C sont placées sur la pile, elles n'existent donc pas en tant que telles tant que le programme n'est pas rentré dans la fonction.

Thierry

PS: je te recommande encore le bouquin Elektor, tu vois maintenant que c'est cela .. ou une perte de temps ?

**PIC sur PAC** · 25/02/2011, 22h32

PS: je te recommande encore le bouquin Elektor, tu vois maintenant que c'est cela .. ou une perte de temps ?

je l'ai

et je l'ai lu (presque en entier) mais il n'y a pas grand chose sur la partie ADC (c'est que cla doit être trivial

). Par contre c'est dedans que j'ai trouvé le problême des variables en VOLATILE vis à vis des fonctions sur interruption.
bon voici le code qui merde

Code:

if ((choix_aff==1)&((ihm_flag||0x0F)==0))
    sprintf(texte,"%4d",val_capt[indice+3]);    
else
    { ...

la partie IF n'est pas pris en compte si je mets que (choix_aff==1) là cela permet de mettre un pt d'arret dessus.
Mon analyse du C est largement émoussé par des années de MATLAB là je sèche pourtant cela doit être tout C..

invite98765423456 · 25/02/2011, 22h53

Envoyé par PIC sur PAC

je l'ai

et je l'ai lu (presque en entier) mais il n'y a pas grand chose sur la partie ADC (c'est que cla doit être trivial

). Par contre c'est dedans que j'ai trouvé le problême des variables en VOLATILE vis à vis des fonctions sur interruption.
bon voici le code qui merde

Code:

if ((choix_aff==1)&((ihm_flag||0x0F)==0))
    sprintf(texte,"%4d",val_capt[indice+3]);    
else
    { ...

la partie IF n'est pas pris en compte si je mets que (choix_aff==1) là cela permet de mettre un pt d'arret dessus.
Mon analyse du C est largement émoussé par des années de MATLAB là je sèche pourtant cela doit être tout C..

Tu est sûr que ton "&" entre les parenthèses n'est pas plutôt && ??
Tu peux aussi mettre des variables sut les expressions de ton "if" :
tmp1= (choix_aff==1);
tmp2 = (ihm_flag||0x0F);
ou cascader tes "if"
et les examiner individuellement

thierry

Sinon, là, je regarde demain (un peu fatigué)

ftorama · 25/02/2011, 23h14

Code:

if ((choix_aff==1)&&((ihm_flag|0x0F)==0))

me parait aussi plus correct que

Code:

if ((choix_aff==1)&((ihm_flag||0x0F)==0))

double opérande (&& ou ||) c'est l'opération logique

simple opérande, c'est l'opération bit-à-bit, le masquage généralement

invite98765423456 · 25/02/2011, 23h18

Envoyé par ftorama

Code:

if ((choix_aff==1)&&((ihm_flag|0x0F)==0))

me parait aussi plus correct que

Code:

if ((choix_aff==1)&((ihm_flag||0x0F)==0))

double opérande (&& ou ||) c'est l'opération logique

simple opérande, c'est l'opération bit-à-bit, le masquage généralement

c'est ce que suggérais aussi.

Bonne soirée

**bobflux** · 26/02/2011, 08h13

Alors :

- Ton filtrage sur Avcc est inadéquat. Le condensateur est trop petit, et l'inductance va causer une résonance, de plus sa valeur est trop élevée, l'impédance de ton alim dépasse les 150 ohms à certaines fréquences...

J'utilise 100nF + 1uF céramique CMS entre les 2 broches AVCC/AGND, et une résistance de 10 ohms à la place de l'inductance (ou une ferrite). Les lectures ADC ne fluctuent pas (ou alors 1 LSB) alors que le reste de la carte est truffé de convertisseurs à découpage.

- Ta référence analogique est une zener, qui a une dérive en T° importante, et une précision très mauvaise ; utilise une vraie référence, j'ai posté des infos dans l'autre topic...

- La tension que tu mesures (avec ton potar) n'est pas liée à ta référence mais au +5V issu d'un 7805 donc très imprécis.

Si tu as un capteur résistif qui donne un ratio de tensions (Vout = Vin * valeur_à_mesurer) alors si Vout est mesuré par rapport à une référence, il faut que Vin soit lié à cette même référence !... Sinon les erreurs sur le 5V se retrouvent dans la mesure.

Pour un capteur qui donne une tension (genre MCP9701, à 19.5 mV/°C) avec une bonne réjection de la tension d'alim, c'est différent, il suffit de mesurer cette tension par rapport à une référence précise.

Sur platine d'essais, t'as pas de CMS, donc mets simplement une capa de 10-100uF et la résistance de 10 ohms. Et tu soudes un 1u CMS 0805 directement sur le uC, entre AVCC et AGND, et un autre entre VCC et GND : c'est la seule façon d'avoir un découplage robuste sur une plaque d'essais sans soudure.

Aussi, sur ta plaque d'essais, fais très attention aux masses. Si tu ramènes la masse du capteur à l'alim, c'est pas bon, il faut la mettre sur la masse analogique. C'est la même chose sur un circuit imprimé, mais la plaque d'essais accentue encore plus le phénomène...

Ah, j'avais pas vu qu'il y a eu plein de posts entre temps

**PIC sur PAC** · 26/02/2011, 08h29

bonjour,
marche pas mieux avec ton code FTORAMA (je crois que j'avais déjà essayé mais testé tellement de configuration

)
voici le code incriminé:
déclaration:

Code:

volatile  int    val_capt[6];//temperature en 1/10 de degré et en niveau

void val2num(char*,unsigned char);

Code:

void val2num(char* texte, unsigned char indice)
{
int entier,decimal;

if ((choix_aff==1)&&((ihm_flag|0x0F)==0))
    sprintf(texte,"%4d",val_capt[indice+3]);    
else
    {
    entier=val_capt[indice]/10;
    decimal=val_capt[indice]%10;
    if (val_capt[indice]>=0)
        sprintf(texte,"%2d.%d%c ",entier,decimal,0x82);
    else
        sprintf(texte,"%2d.%d%c ",entier,-decimal,0x82);
    }

}

je suis

!!

**bobflux** · 26/02/2011, 08h40

Pourquoi l'as-tu mis en volatile ? Il est mis à jour par une interruption ?

**bobflux** · 26/02/2011, 09h12

Dans le doute je préfère toujours spécifier les tailles des variables (en l'occurence, int16_t ou S16 et non int).

J'ai l'impression que tes valeurs sont mises à jour par une interruption. Or, tes valeurs sont 16 bits et l'AVR est une machine 8 bits, donc si tu fais :

Code:

machin = val_capteur[1];

Il y aura 2 opérations pour copier chaque octet de la valeur 16 bits. Si l'interruption qui met à jour val_capteur survient entre les deux, les 2 octets correspondront à des mesures différentes.

De même :

Code:

    entier=val_capt[indice]/10;
    decimal=val_capt[indice]%10;

Ici, si l'interruption survient pendant ce code, une partie du code aura l'ancienne valeur et le reste la nouvelle, autrement dit, le résultat est n'importe quoi

Solution : il faut stopper les interruptions, mais le moins longtemps possible.

Donc on met un cli() pour couper les interruptions, on copie la valeur dans une variable temporaire, et on réactive les interruptions.

Code:

volatile  S16 val_capt[6]; //temperature en 1/10 de degré et en niveau

void val2num(char* texte, U8 indice)
{
	S16 mesure;
	
	if ( (choix_aff==1) && ((ihm_flag|0x0F)==0) )
	{
		cli();
		mesure = val_capt[indice+3];
		sei();
		
		sprintf(texte,"%4d", mesure );    
	}
	else
	{
		cli();
		mesure = val_capt[indice];
		sei();
		
		S16 entier	= mesure/10;
		S16 decimal	= mesure%10;
		
		if ( mesure >= 0 )
			sprintf(texte,"%2d.%d%c ",entier,decimal,0x82);
		else
			sprintf(texte,"%2d.%d%c ",entier,-decimal,0x82);
	}
}

PS : ton code est peu clair, le comportement de la fonction dépend de 2 variables globales, etc...

**PIC sur PAC** · 26/02/2011, 09h17

Oui,
c'est le résultat de la mesure de mes sondes. La mesure est faite à chaque overflow du timer soit toutes les 1/2s.
Un collègue m' a expliqué de bufferiser les interruptions et de faire le traitement hors de la fonction d'interruption. Mais pour le moment je fais (ou j'essaye) de faire un code opérationnelle après je compte l'optimiser. C'est peut être pas le bon sens.

**PIC sur PAC** · 26/02/2011, 10h39

bon en décomposant le test du if le code fonctionne

.
comprend pas !!!

Code:

void val2num(char* texte, unsigned char indice)
{
int mesure,entier,decimal;
unsigned short cas2;

cas2= (ihm_flag|0x0F);
    
    if ( (choix_aff==1) && (cas2==0) )
    {
        cli();
        mesure = val_capt[indice+3];
        sei();
        
        sprintf(texte,"%4d", mesure );    
    }
    else
    {
        cli();
        mesure = val_capt[indice];
        sei();
        
        entier    = mesure/10;
        decimal    = mesure%10;
        
        if ( mesure >= 0 )
            sprintf(texte,"%2d.%d%c ",entier,decimal,0x82);
        else
            sprintf(texte,"%2d.%d%c ",entier,-decimal,0x82);
    }
}

Ok pour le CLI/SEI actuellement je pense pas qu'il y est une interruption pendant ce moment (car je sors juste de l'interruption à ce moment). Mais dans le doute je mettrais cela en place à chaque manipulation de variable supérieure à 8 bits utilisées dans une interruption.

**PIC sur PAC** · 26/02/2011, 11h10

Dans le doute je préfère toujours spécifier les tailles des variables (en l'occurence, int16_t ou S16 et non int).

A priori je n'ai que SHORT, CHAR, INT (signé ou non évidement)et FLOAT d'utilisable avec AVRstudio et GCC
Donc SHORT et CHAR en 8 bits et int en 16 par défaut

.

**bobflux** · 26/02/2011, 22h36

Envoyé par PIC sur PAC

Un collègue m' a expliqué de bufferiser les interruptions et de faire le traitement hors de la fonction d'interruption. Mais pour le moment je fais (ou j'essaye) de faire un code opérationnelle après je compte l'optimiser. C'est peut être pas le bon sens.

En fait ce que je te conseillais n'est pas une optimisation : vu que l'interruption peut changer la valeur à n'importe quel moment, si tu ne la protèges pas (avec cli()), alors ça risque de ne pas marcher du tout (tu auras des valeurs fausses de temps en temps, ça dépend quand l'interruption arrive).

Pour ce qui est d'optimiser, c'est un thermostat, donc que le temps de réaction soit d'1 seconde ou 0.01s, on s'en fout...

> A priori je n'ai que SHORT, CHAR, INT (signé ou non évidement)et
> FLOAT d'utilisable avec AVRstudio et GCC

Ah oui il faut un header spécial pour les autres. Bon, tant que tu connais bien les types que tu utilises, c'est bon...

> cas2= (ihm_flag|0x0F);

Là, | c'est un "OU binaire" donc "cas2" ne peut jamais valoir 0 puisque tu mets toujours les 4 bits de poids faible (0xF) à 1... à mon avis ce n'est pas trop ce que tu veux...

Sans savoir à quoi correspondent tes indices dans val_capt[] et que veut dire "ihm_flag", j'ai aucune idée de ce que tu veux

mais on dirait qu'il y a un malentendu...

**PIC sur PAC** · 26/02/2011, 23h23

Bonsoir

Là, | c'est un "OU binaire" donc "cas2" ne peut jamais valoir 0 puisque tu mets toujours les 4 bits de poids faible (0xF) à 1... à mon avis ce n'est pas trop ce que tu veux...

je me suis complètement planté sur le masque que je voulais faire!!
Merci bien pour l'aide car sur ce point j'avoue que je comprenais plus rien portant je m'y attendais un peu:

Mon analyse du C est largement émoussé par des années de MATLAB là je sèche pourtant cela doit être tout C..

Maintenant, après test de ça, je retoune sur mes pb d'ADC.
Encore merci

.

**MorpheusPic** · 28/02/2011, 03h10

salut

un conseille essai les tc77 a sortie spi qui mesure de -55 a 125° avec un reso de 0.0625°

jen ai tester 5 et elle ont seulement 0.2° max de difference entre elles
et 0.1° d'erreur de moyenne par rapport a un thermometre correct

avec un regulateur 3.3V par sonde + le tc77 t'en a pour 4 euro a peu pres et la mesure bouge pas d'un poil

la sortie est en spi mais il y a aucune config a faire pour la faire fonctionner

a ceux qui cherche de bonne sondes pas cher c'est a essayer absolument

DAUDET78 · 28/02/2011, 06h19

Envoyé par MorpheusPic

jen ai tester 5 et elle ont seulement 0.2° max de difference entre elles

information rassurante

et 0.1° d'erreur de moyenne par rapport a un thermometre correct

C'est quoi un thermomètre correct ?

Ce genre d'information ne présente aucun intérêt .... simplement de raconter que le produit (enfin celui qui a été testé) est bien dans la spécification du fabricant ... merci, on le savait

**MorpheusPic** · 28/02/2011, 15h35

a lala toujour a raler ^^

non je donne des information sur un produit ,niveau precision ,performance ,simplicitée de mise en oeuvre

pour moi c'est tout vu jais enfin trouver quelque chose de tres bien pour mesurer de la temperature simplement

c'est pour sa que je donne mon avis.

**PIC sur PAC** · 28/02/2011, 16h53

bonsoir,

un conseille essai les tc77 a sortie spi qui mesure de -55 a 125° avec un reso de 0.0625°

Merci pour l'info je garde ça de coté. Je compte m'acheter un lot de différents capteurs pour me faire la main s'ils utilisent en plus différents protocoles cela sera d'autant mieux.

**PIC sur PAC** · 28/02/2011, 16h59

Sinon je n'ai plus de problème de variations importantes de mes mesures avec le CAN. je suis maintenant au lsb.
J'ai identifié l'origine du pb: une simple boucle de masse due à un malencontreux strap sur la plaque d'essai que j'utilise.
J'aime mieux ça!!!

.

ftorama · 28/02/2011, 17h13

Envoyé par PIC sur PAC

Sinon je n'ai plus de problème de variations importantes de mes mesures avec le CAN. je suis maintenant au lsb.
J'ai identifié l'origine du pb: une simple boucle de masse due à un malencontreux strap sur la plaque d'essai que j'utilise.
J'aime mieux ça!!!

.

Y'en a qui méritent des claques quand même

Tu comprends maintenant pourquoi on demande parfois des photos des maquettes...et pourquoi parfois on devrait

**PIC sur PAC** · 28/02/2011, 19h57

Tu comprends maintenant pourquoi on demande parfois des photos des maquettes...et pourquoi parfois on devrait

Tu n'aurais rien vu c'était au dos de la plaque d'essais.
Les pistes d'alimentation sont en deux parties sauf une qui a été strappée par en dessous

.
Encore merci pour votre aide.

ftorama · 28/02/2011, 20h00

Envoyé par PIC sur PAC

Tu n'aurais rien vu c'était au dos de la plaque d'essais.
Les pistes d'alimentation sont en deux parties sauf une qui a été strappée par en dessous

.
Encore merci pour votre aide.

De rien...et content que ça marche

Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Re : Fonction ADC avec un AVR

Discussions similaires

Fonction ADC pour Pic 16F727

Mise en fonction ADC PIC16F887

compatibilté de winAVR avec Easy AVR

fonction c pic, pour adc (sous CSS)

adc avec un PIC12F683