MCP45HV51 Le registre ne change pas

le_audio

MCP45HV51 Le registre ne change pas


J’utilise un potentiomètre numérique MCP45HV51 pour le contrôle du gain. (Fiche technique: http://ww1.microchip.com/downloads/en/DeviceDoc/20005304A.pdf )

J’ai configuré l’appareil selon la fiche technique et le contrôle avec un Raspberry Pi via I2C.

Le poti a l’adresse 0x3e.

Pour certains tests initiaux, j’utilise la console avec

i2cset -y 1 0x3e 0x00 0xff

Le poti atteint son maximum. valeur: 5k

i2cset -y 1 0x3e 0x00 0x00

Le poti passe à son minimum. valeur: ~ 0,25 k

Quand je lis les registres du poti avec

i2cdump -y 1 0x3e

il n’y a pas de changement notable.

Je ne comprends pas, pourquoi le poti réagit mais le registre ne change pas sa valeur. Quelqu’un peut-il m’aider avec ça?

Merci d’avance!

Console

Circuit

le_audio

Tu as tout à fait raison. Je l’ai corrigé

SamGibson

Salut, Y a-t-il une raison pour laquelle vous avez « refusé » ma réponse aujourd’hui? Je pensais que votre problème a été résolu par mon explication il y a 3 mois, comme l’a confirmé notre discussion. Si vous avez découvert un nouveau problème, veuillez l’expliquer et nous verrons s’il peut être traité dans cette question, ou s’il devrait s’agir d’une nouvelle question. Merci.

le_audio

Ça doit être arrivé par accident. L’accepter à nouveau, désolé!

SamGibson

D’accord, j’étais inquiet au cas où il y aurait un nouveau problème. Merci beaucoup d’avoir expliqué et accepté à nouveau 🙂

Réponses


 SamGibson

Je ne comprends pas, pourquoi le poti réagit mais le registre ne change pas sa valeur. Quelqu’un peut-il m’aider avec ça?

La raison en est que bien que les commandes d’ écriture I2C vers la famille MCP45HVX1 soient simples et puissent être exécutées à l’aide d’ i2cset , le format des commandes de lecture est légèrement plus inhabituel.

Vos commandes i2cset pour définir la position de l’essuie-glace du potentiomètre répondent aux exigences de sa fiche technique et, comme vous l’avez trouvé, elles changent la position de l’essuie-glace (puisque vous avez mesuré le changement de résistance).

Cependant, la commande i2cdump que vous avez utilisée n’utilise pas la séquence correcte d’octets I2C pour lire les valeurs de registre de ce périphérique, vous ne lisez donc pas réellement la valeur d’essuyage. C’est pourquoi les valeurs affichées par i2cdump n’ont pas changé, même si la valeur d’essuyage a changé.

Résumé: Je pense avoir construit une commande i2cget qui devrait fonctionner pour afficher le registre d’essuie-glace volatile que vous souhaitez voir. Tous les détails du problème sont expliqués ci-dessous.


Les principaux problèmes qui causent des problèmes de compatibilité entre i2cdump (et, dans une moindre mesure, i2cget ) et la famille de potentiomètres numériques MCP45HVX1 sont:

  • Toute valeur lue à partir du potentiomètre doit être de 2 octets, où le premier (MSB) lu est toujours 0x00 et la valeur « réelle » est dans le 2ème octet lu. Votre commande i2cdump était en mode d’accès octet, donc tous les octets qui ont été lus n’étaient que les octets MSB principaux, qui seront zéro, et votre affichage montrait en effet toujours des valeurs de 0x00.

    Voir ce commentaire en suivant la carte mémoire dans la fiche technique (et voir également les exemples ultérieurs de commandes de lecture):

    Déclaration que la lecture I2C contiendra 2 octets - de la fiche technique MCP45HVX1

  • Le registre d’essuie-glace volatile (que vous souhaitez lire) est le registre 0x00. Par conséquent, si vous pouviez persuader i2cdump de simplement lire 2 octets dans une séquence I2C à partir du périphérique, à moins que vous n’ayez précédemment spécifié une valeur de registre différente pour le périphérique, vous liriez le registre 0x00 que vous souhaitez, comme indiqué dans ce diagramme:

    I2C Lire le dernier registre - de la fiche technique MCP45HVX1

    Malheureusement, pour autant que je puisse voir en regardant dans le code source i2cdump et i2cget , ils ne liront qu’au format 2 octets (c’est-à-dire mot), si une « adresse de registre » est également spécifiée sur la ligne de commande. Cependant, comme je l’explique au point suivant, la valeur d’adresse que vous devez envoyer n’est pas seulement une « adresse de registre » sur cette famille de potentiomètres.

  • L’octet I2C qui spécifie l’adresse du registre dans le potentiomètre (dans la fiche technique, ils l’appellent un octet de commande ) contient non seulement la valeur réelle de l’adresse du registre (comme cela est typique avec d’autres appareils I2C) mais également deux bits qui spécifient le type d’accès (Écriture de données, lecture de données, incrémentation d’essuie-glace, décrémentation d’essuie-glace). Vous devez comprendre comment définir correctement cette valeur avec le logiciel que vous utilisez pour accéder au bus I2C.

    Format d'octet de commande - de la fiche technique MCP45HVX1

    Lorsque vous spécifiez une adresse de registre pour le périphérique, la séquence d’octets I2C requise devient plus compliquée, comme dans le diagramme suivant:

    Lecture aléatoire I2C - à partir de la fiche technique MCP45HVX1

    Cependant, je crois i2cget peut être persuadé d’effectuer cette séquence, si nous calculons le « bon octet de commande » à utiliser à la place de « l’adresse de registre » sur la ligne de commande

Dans votre situation, je vois deux options:

  • Écrivez votre propre code Linux, ou programmez un MCU, ou utilisez quelque chose comme un pirate de bus pour envoyer exactement la séquence correcte d’octets I2C, nécessaire pour lire les valeurs de registre de cet appareil.

    Ou:

  • Sans avoir un système Linux approprié et votre appareil à tester, je ne peux pas être sûr de la suggestion suivante. Cependant, sur la base d’un examen rapide de la source i2cget , essayez de l’utiliser comme suit, pour envoyer la séquence I2C illustrée à la figure 7.5 ci-dessus, à partir de la fiche technique:

    i2cget -y 1 0x3e 0x0c w

    L’octet 0x0c envoyé comme « adresse de registre » par i2cget se décompose en binaire 0000 1100 où:

    • Le quartet le plus significatif de 0000 est l’adresse de registre réelle dans votre appareil ( AD0 à AD0 dans la figure 7.5 ci-dessus), qui est le registre d’essuie-glace volatil que vous souhaitez lire.
    • Les deux bits suivants sont 11 spécifiez qu’il s’agit d’une commande de lecture.
    • Les deux derniers bits sont effectivement « indifférents » selon la fiche technique, car ce sont des bits de données inutilisés.

    Le w final est nécessaire pour lire les valeurs de 2 octets ( w ord) du périphérique, comme expliqué précédemment.

    (Il est possible que i2cdump -r 0x0c-0x0c -y 1 0x3e w fonctionne également.)

  • Si vous rencontrez toujours des problèmes, l’utilisation d’un oscilloscope (pour afficher la qualité du signal analogique I2C), puis l’utilisation de l’oscilloscope ou l’utilisation d’un analyseur logique avec décodage I2C pour afficher les données I2C, vous aideront à trouver où la séquence réelle d’octets I2C sur le bus ne correspond pas à la fiche technique.

le_audio

Merci pour cette très aimable explication de RTFM. J’espère que vous acceptez mes excuses que je suis très nouveau dans le domaine du contrôle I2C et comme le manuel contient beaucoup de pages, j’ai évidemment manqué certaines choses. Votre suggestion avec i2cget -y 1 0x3e 0x0c w fournit la valeur correcte du registre. Merci beaucoup!

SamGibson

@le_audio – Vous êtes les bienvenus 🙂 Aucune excuse nécessaire! Avec le temps et l’expérience, vous verrez comment trouver les détails importants d’I2C cachés dans les pages d’une fiche technique. Je suis heureux que la ligne de commande i2cget fonctionné pour vous. Bonne chance!

 

#pas, change, Le, MCP45HV51, ne, registre»

 

google

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *