Quel est le bon moyen pour le MCU de déterminer sur quelle version matérielle il s'exécute?

Je travaille sur une nouvelle conception de produit et il y aura probablement de petites ou grandes modifications / corrections matérielles au cours de la vie du produit. Pour les futures mises à jour du firmware sur le terrain, j'ai besoin d'un moyen de déterminer la révision du matériel. Qu'est-ce qu'une bonne stratégie?

Je tire actuellement deux broches de rechange vers le haut / bas avec des résistances externes et vérifie le motif. Cela ne permet que 4 révisions matérielles, mais cela pourrait suffire à des fins pratiques. Cela pourrait devenir un problème si j'ai besoin de l'une ou des deux de ces broches dans une future révision matérielle.

Je suppose qu'un moyen plus économique pourrait être d'avoir un diviseur de résistance connecté à une broche ADC. Chaque révision matérielle peut avoir des résistances de valeur différente. Malheureusement, je n'ai pas d'ADC de rechange dans ma conception actuelle.

Je suppose qu'une autre façon pourrait être de coder le numéro de version du matériel dans une EEPROM ou le flash mcu pendant la production? (Nous n'avons pas cette installation pour le moment.)

Je suppose que je suis à la recherche de suggestions pour une méthode flexible et robuste.

[ÉDITER]

Ré. suggestion de @ trav1s: Je n'ai pas de bus d'adresse en soi mais j'ai une EEPROM 24LCxx sur le bus I2C. Les 3 bits bas de l'adresse esclave sont câblés. Je suppose que je pourrais changer les bits d'adresse et rechercher l'EEPROM lors du démarrage.

C'est quelque chose que je traite régulièrement. Nous avons du matériel très complexe qui est dans le domaine depuis près de 10 ans, avec différentes versions de divers sous-systèmes. Certains sous-systèmes ont un code 2 bits, mais comme vous l'avez mentionné, ce n'est pas toujours suffisant.

La suggestion d'EEPROM est bonne, mais elle nécessite de programmer l'EEPROM et de remplir la carte avec la bonne version.

Ce que je suggérerais, c'est un registre à décalage de sortie série parallèle 8 bits comme un 74HC166. Le numéro de version peut être défini sur l'entrée par la carte PC elle-même liant les entrées HIGH ou LOW, puis vous n'avez besoin que de 3 broches pour charger et lire le registre à décalage à partir d'un MCU.

Je n'utiliserais pas un numéro de version programmé dans le microcontrôleur. À moins que le logiciel ne soit différent pour différentes versions de carte, mais la version de la carte me semble superflue. Avoir le moins de versions du logiciel du microcontrôleur possible, idéalement une seule. Chaque version différente peut entraîner des problèmes logistiques.

Le code EEPROM est une bonne idée, car il permet de nombreux codes de carte différents, mais sortez-le du microcontrôleur, dans un appareil séparé. L'EEPROM est cher pour les grandes capacités (beaucoup plus cher par bit que Flash), mais pour quelques octets, vous pouvez les trouver à bon marché. Celui-ci ne coûte que 16 cents en 100 et n'a besoin que d'une ligne d'E / S.

Un moyen de réduire le risque d'erreurs est d'avoir un package différent pour chaque version de carte. Vous devez donc programmer un lot d'EEPROM avec un numéro de version 1 dans SOT-23, la prochaine version 2 dans MSOP, etc. Vous ne pouvez donc pas avoir une EEPROM de version 1 sur une carte de version 2.

Une option qui n'utilisera que deux broches numériques est quelque chose comme ceci:

En modifiant les valeurs R1 et C1, vous pouvez avoir des temps de charge différents pour le condensateur que vous pouvez mesurer pour déterminer la version matérielle.

S'il y a de l'espace inutilisé dans le bus d'adresse, vous pouvez placer un registre ROM sur le bus qui peut être lu par le MCU. Le registre contiendrait le numéro de version du matériel. Lorsque le MCU lit à partir de cette adresse, le registre écrit sa valeur sur le bus de données. Le registre peut être câblé sur la carte ou si vous voulez pouvoir changer le numéro de version à mains nues, vous pouvez créer des broches qui peuvent être attachées / fermées comme vous le faites maintenant.