Bonjour je cherche un CI simple à trouver, simple d'utilisation (pas de microproc) pouvant transformer un motif d'entrée de 16 entrées (contacts secs) vers une réduction de codage sur 4 bits. j'ai trouvé du 10 vers 4 en BCD (donc perte de bits) mais pas de 16 vers 4 ! j'ai mal cherché ou il n'y a pas ? merci Sylvain
Ca va être dur à trouver en un boitier (car à l'époque des 74XX les boitiers avec autant de pattes étaient rares et chers...). Par contre c'est facile à faire en chainant deux encodeurs 8 vers 3 du type 74LS148. Il faut quatre NAND en externe et hop ! Cf la datasheet du 74LS148 pour les details, par exemple ici :
sylfranc a tapoté du bout de ses petites papattes :
Bon, je vais faire des supputations pour combler les trous.
Tu as 16 entrées binaires pour quatre sorties binaires. En statique, je ne vois pas comment compresser 16 bits en 4 bits.
Alors je vais combler un trou de la question et supposer *qu'une et une seule* entrée est active en même temps. Déjà ça résoud le problème sur le plan théorique, quoique sur le plan pratique il faut garantir la condition susdite (ou assumer le concept de priorité).
Dans l'idéal, faudrait utilise un 16:4 priority encoder. Mais je ne connais pas ça en monochip (mais ça existe peut-être après tout) donc je te conseille le bon vieux chainage de plusieurs 4:2 ou 8:3, comme dans cet exemple :
formatting link
C'est pas l'exemple le plus simple mais ça donne une idée sur les concepts.
Tu as un autre eexmple plus directement applicables avec deux 8:3 :
Voir le deuxième schéma.
Sinon, tu peux carrément tout faire en portes logiques de base.
Ta question est aussi incomplète parce que tu ne dis pas qu'est-ce qui lit ces 4 bits encodés. L'idéal serait que ce "lecteur" pilote tout simplement un multiplexeur pour récupérer l'état 1 ou 0 de chaque entrée et utilise comme code les 4 bits qu'il envoie. A toi de gérer les priorités par ailleurs :
Donc voilà un topo un peu fatras, qui t'explique pourquoi il y a une infinité de solutions selon le besoin, le contexte, ce qui pilote, etc.
Maintenant tu vois que le besoin de précisions dans la question est indispensable.
Si tu veux absolument jouer au mec qui est certain de savoir ce qu'il veut sans qu'on prenne en compte l'environnement, je te conseille le chainage des priority encoders 4:2 ou 8:3. Les datasheets contiennent certainement des schémas d'applications qui expliquent le chainage plus convivialement (quoique !) que le schéma donné en premier.
Ce n'est pas un circuit disponible sous cette forme. En fait ça ne fonctionnerait que précédé de son inverse, qui assurerait que une seule entrée eszt allumée (ou une seule éteinte, peu importe). Vous auriez en sortie les 4 bits désignant le numéro de l'entrée allumée (éteinte). Dans la vraie vie, il vous faut envisager un comportement prévisible quand de façon stable ou transitoire plusieurs entrées seront allumées (éteintes). Ça s'appelle un encodeur de priorité, demander "priority encoder" à Google. Il vous faudra sans doute cascader deux 8 -> 3.
Comme j'étais fainéant j'utilisait souvent des Uvprom pour faire des trucs dans ce genre, un seul pavé, sans compter que pour le routage c'est le transcodage qui faisait le boulot plutôt que les pistes.
Chouette, une Eprom de 64K pour remplacer 3 chips TTL à quelques centimes ! :) M'enfin l'avantage c'est que tu as plus de 16 millions de cas de figure à peaufiner à la main (ou par soft fépour) histoire de gérer les priorités complexes que peuvent impliquer un doigt (qui dérape éventuellement) sur une branlée de pushbuttons. :D
Perso, j'avoue que la dernière fois que j'ai eu le cas de figure, j'ai pris UNE entrée ADC (enfin si on peut appeler comme ça une entrée joystick de SoundBlaster), j'ai fait un multipont de résistances entre, et un soft étalonnable (température, vieillissement des résistances) capable de décoder quel switch avait été enfoncé, faire l'anti-rebond (sujet pas abordé par l'OP, qui ne se rend pas compte des problèmes que ça peut poser entre du mécanique et du numérique), et détecter le multi poussement de bouton.
audiovalve a tapoté du bout de ses petites papattes :
Si tu deviens méchant dans les vannes, pourquoi pas un PIC avec un registre à décalage ? ;) Ah si je sais, le PIC existe encore et le GAL uniquement en magasins d'antiquités ! Pas mal. ;)
D=E9ja dit mais je r=E9sume : Tu ne peux pas coder 16 bits (65536 possibilit=E9s) sur seulement 4 bits (16 possibilit=E9s) sans restriction sur les 16 bits d'entr=E9e.
Donc je suppose que tu voulais dire : coder un (et un seul) bit parmi 16 entr=E9es vers une sortie sur 4 bits (16 possibilit=E9s) Si, =E0 l'instant de l'encodage 16->4 il y a non pas un seul mais plusieurs des 16 bits qui sont actifs =E0 la fois, alors quel est le crit=E8re de d=E9cision pour ne choisir qu'un (et un seul) de ces bits ?
Ou alors: est-ce que la sortie de 4 bits n'est significative que si (et seulement si) un seul des 16 bits est actif ? Dans ce cas 4 bits ne sont pas assez pour coder l'information qui signifierait =AB aucun des 16 bits d'entr=E9e n'est actif =BB ( il faudrait au minimum 5 bits )
Ou encore: il est possible d'avoir en entr=E9e plusieurs bits activ=E9s, et en sortie on transmet un flux de mots *successifs* de 4 bits dont le N-i=E8me mot code le N-i=E8me des 16 bits d'entr=E9e ? Dans ce cas il faut en plus des bits de synchro pour d=E9signer l'index N de chaque mot de 4 bits.
Le circuit va d=E9pendre de ta r=E9ponse =E0 la question pr=E9c=E9dente.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.