Convertisseur A/N ADS8344 - Gain de 2 inexpliqué

[SportsEngine]

Bonjour,

Je travaille sur un projet avec un ADC 16 bits ADS8344 de chez Texas Instruments. J'ai un gain de 2 qui apparaît entre la valeur numérique attendue et la valeur numérique lue par le microcontrôleur, et qui ne semble pas être documenté dans la datasheet.

Données :
- Vcc = 5V
- Vref = 4,096V (Référence de tension MCP1541-4.096)
- Mesure en Single ended avec COM relié au plan de masse.
- quantum = Vref/65536 = 62,5µV.
- La routine de lecture de l'ADC se contente de retourner la valeur brute sur un terminal.

Les tensions analogiques d'entrée proviennent d'amplificateurs d'instrumentation INA128 qui ont un gain de 500 (501 en réalité) avec une résistance Rg de 100 ohm 1%. Leur tension de référence est fixée à 1,024V par la référence de tension ISL21010-1.024. Les capteurs sont des jauges de contraintes.

Mesures au voltmètre et oscilloscope :
- Vcc est bien 5V et stable
- Vref de l'ADC est 4,095V, pas de bruit
- Vref INA128 est à 1,023V, pas de bruit
- La tension d'entrée des voies analogiques est comprise entre 1,02V et 1,03V (capteurs en "repos" donc Vout ~Vref)

Calculs :
Donnée = Vanalogique/q
La valeur numérique attendue est donc de l'ordre de grandeur de Vref(INA128)/q, soit 1,024/(62.5e-6) = 16384

Or la valeur numérique lue par le microcontrôleur est le double. Si je fais varier la mesure du capteur, j'arrive bien à balayer la plage 0 - 65535 donc ce n'est pas le MSB qui est bloqué à '1'.

J'utilise le mode de transmission 24 fronts d'horloge (illustré Figure 3 page 12) et j'ignore le LSB qui est normalement transmis au "start" suivant.
Voici ma routine de lecture :

INT32 ADS8344_read(UINT8 channel, UINT8 acquisitionMode, UINT8 powerMode, UINT16*adcResult)
{
  UINT8 configRegister[2];
  UINT8 timeout = 0;
  UINT8 dataRead[2];
  UINT16 readValue = 0;
  char str[32];
  // Set "Configuration register"
  configRegister[0] = 0x80 | channel | acquisitionMode | powerMode;
  // Select SPI device
  ADC_CS = 0;
  // Start conversion
  SPI3_transfer(&configRegister[0], NULL, 1);
  // Deselect SPI device
  ADC_CS = 1;
  __delay_us(1);
  while(ADC_BUSY != 1 && timeout < ADC_TIMEOUT)
    {
      timeout++;
      __delay_us(1);
    }
  if(timeout >= ADC_TIMEOUT)
    return -1;
  else
    {
      // Select SPI device
      ADC_CS = 0;
      // Acquire data
      SPI3_transfer(NULL, &dataRead[0], 2);
      // Convert read bytes into 16-bit result
      readValue = (((UINT16)dataRead[0] << 9) | (UINT16)dataRead[1] << 1); // ignore LSB
      *adcResult = readValue;
      // Send value on debug terminal
      sprintf(str, "ADC read : %u\r\n", readValue);
      UART1_writeString(str);
    }
  // Deselect SPI device
  ADC_CS = 1;
  return 0;
}

Merci.
-----

[jiherve]

Bonjour,
Il y a un truc qui me gêne, ton circuit de réception doit s'attendre à recevoir 2 fois 8 bits et donc ton LSB sera également reçu ce qui fait que comme tu décales de 1 à gauche cela multiplie par 2.
Tu peux faire un test simple : code une tension un peu supérieure à Vref/2 et amha il te manquera le MSB!
JR

[SportsEngine]

En 24-bit, j'envoie 3 octets : l'octet de configuration (bit de start, voie, mode "single ended"), et les deux octets de réception de donnée. SAUF que je ne sais pas comment est conçu l'ADC, mais le MSB du premier octet n'est pas utilisé (il tombe en même temps que le changement d'état de BUSY) ce qui fait que tout est décalé de 1 bit vers la droite, et le LSB n'est disponible que lors de l'envoi du prochain octet de configuration (bit START) :


Et même en admettant que les data soient comptabilisées sur front descendant de la clock, ça ne colle pas.

En décalant les données de 1 bit, j'ai bien une variation linéaire de 0 à 65535 mais facteur 2 entre la tension d'entrée et la valeur numérique. Si je concatène les deux octets tels que je les reçois, certes ma valeur 16384 est bonne, mais je sature à 32767 au lieu de 65535.

Merci

[jiherve]

Bonsoir
Tu n'as pas compris , relis bien la datasheet:
les 8 premiers cycles, en fait juste 4 sont utiles lancent la conversion et l'échantillonage du signal, les 16 coups suivants réalisent la conversion et la sortie des bits, le busy est un drapeau qu'il faut utiliser avec intelligence.
Tous les coups d'horloges sont nécessaires, les bits sont présentés sur front descendant et doivent donc être capturés sur un front montant, en mode clock externe il faut 25 coups d'horloge(lire data sheet) pour effectuer et récupérer une conversion complète.
la datasheet rien que la datasheet, et avec du composant TEXAS c'est du béton!
Donc tu utilises mal le composant!
JR

[A voir en vidéo sur Futura]

[DAUDET78]

la datasheet rien que la datasheet, et avec du composant TEXAS c'est du béton!

+1

[jiherve]

Re
Je savais que cela te ferait plaisir !
JR

[SportsEngine]

Pour ce qui est de Texas, aucun doute j'ai souvent utilisé, et utilise encore souvent leurs composants pour tout un tas d'applications, tout comme Linear, Maxim et Analog je sais qu'ils sont fiables, là n'est pas la question

Je suis en mode clock INTERNE et 24 bits, mais en 32 bits même soucis. La seule différence que je vois entre le mode 24 bits et 32 bits, c'est qu'en 32 bits on envoie un octet vide, alors qu'en 24 bits on envoie l'octet de configuration pour la prochaine acquisition. Dans les deux cas il faut envoyer 4 octets, car le LSB de la donnée numérique correspond au MSB du dernier octet reçu. Donc il faut bien un décalage de 1 bit vers la gauche pour remettre le résultat sur 16 bits :


BUSY est une sortie physique, que je scrute dans ma routine de lecture (fonction bloquante avec un timeout) pour être sûr que la conversion est terminée, je ne pense pas que mon problème se situe à ce niveau.

[jiherve]

Bonsoir
Dans les deux cas il faut 25 coups d'horloges pour activer la conversion et récupérer la donnée, bien sur si ton interface SPI ne sait pas faire!!!
Din et Dout font chambre à part ou presque donc le LSB de l'un peut etre n'importe où par rapport à l'autre.
nota : Il y a un bug sur la data dans la figure 6 amha copier coller intempestif du diagramme de la figure 5.
JR