C’est à rien n’y comprendre, la seule explication que j’entrevoie, c’est que le signal Cout/ du dernier compteur arrive trop tôt.
Tout en gardant la même configuration provisoire de 8 bits, il faudrait, si le simulateur le permet, tracer en même temps Q1, Q2, Q3, Q4, Cout/ du dernier compteur (U15) ainsi que le signal Up/Down et les rampes en sortie de U1 (Rfb) sur une période un peu plus longue que deux rampes pour pouvoir voir et analyser ce qui se passe. Ça fait 7 traces simultanées, est ce possible ?
PS : Votre dernier message est apparu au moment où j’allais envoyer celui-ci. J’y réfléchi avant de formuler une réponse.
Bonjour à tous,
Vu le peu d’intérêt que suscite ce projet pour l’ensemble des membres du forum et ce, malgré le nombre de lectures important en peu de temps, il passera en privé avec les intervenants intéressés. :mrgreen:
@Gérard
Réponse par MP.
bonjour a tous
je suis aussi ce projet mais je suis perdu trop compliqué pour moi
j’ai hâte de voire le résultat final en coffret
dans tous les qu’a bravo a tous
Bien! Vu que j’ai eu des demandes, ce fil va continuer… :mrgreen:
Actuellement, il n’y a pas grand chose à publier sauf à dire que le problème de non fonctionnement de la simulation a été cerné et est insoluble dans l’immédiat.
La librairie du CD4516 est buggée au niveau des signaux COUT qui perturbe le fonctionnement.
Il va bientôt y avoir du nouveau avec les essais en réel (mais chut!!!)
Si il y a un « cake » en simulation spice qui pouvait jeter un œil sur cette librairie, qu’il ne s’en prive pas.
Allez une petite capture d’écran avec le défaut dans les chronogramme pour les curieux…
Bon, j’ai relu le datasheet TI du CD4516 et voici ce qui est dit en première page : « If the UP/DOWN input changes during a terminal count, the CARRY-OUT must be gated with the clock, and the UP/DOWN input must change while the clock is high. This method provides a clean clock signal to the subsequent counting stage. »
Si la seconde préconisation est effectivement bien respectée au niveau du flip-flop assurant l’inversion, la première ne l’est plus depuis que les compteurs ont été reconfigurés de « ripple clocking » en « parallel clocking » avec la suppression du OU qu’il soit à diodes ou avec une porte du CD4071. Et c’est vrai que les simulations étaient toutes OK à ce moment là.
Le modèle spice du 4516 est peut-être trop précis et/ou LTspice trop performant au point de générer même les défauts d’un 4516 bien réel. :mrgreen:
Ça vaudrait peut-être le coup de refaire une nouvelle simulation en insérant les deux portes OU d’un CD4071 pour revenir en mode « ripple clocking » sur les deux compteurs extrêmes comme cela est fait sur ce schéma joint dans un message antérieur.
Peut-être faudra-t-il même envisager d’insérer une troisième porte OU entre le Cout/ du dernier compteur et l’entrée clock du flip-flop :
Je l’ai fait hier, d’ailleurs je vous en faisait part dans cet email
Avec 2 portes OU, une fois à diodes puis avec un CD4071. Il reste encore un espoir avec la porte sur le flip-flop.
Je vais tenter de remplacer les CD4516 par des CD4029, qui sait…
Fonctionnement en mode « ripple »
Hier, quand j’ai fait cet essai, je l’ai arrêté trop tôt sans analyser les signaux.
J’aurais du car là on voit nettement l’influence de COUT/ du 2ème CD4516 par rapport au dysfonctionnement.
Sur le front montant de Cout2, Cout3 envoie une pulse négative, fait basculer Up/Down, les bits 9 et 10 ne sont plus synchronisés alors que le bit8 est correct.
Est-ce que ça ne provient pas du compteur 3 avec Q3 et Q4 en l’air.
J’ai aussi essayé avec les compteurs 1 et 2 en mode "ripple " et le compteur 3 en mode synchrone. C’est kif-kif bourricot…
Est-ce qu’on ne pourrait pas se servir du pré-positionnement de ce compteur?
J’avoue, je suis perplexe…
Edité 8h30
Essai avec des CD4029 : même chose…
Edité 8h38
Peut-être un début d’explication :
Apparemment les librairies 4029 - 4510 - 4516 sont toutes basées sur le même modèle (celui du 4029) à quelques variantes près au niveau des pin :
[code]*
*
4 bit synchronous binary/dec up/down counter with asynchronous load
.SUBCKT CD4029B _CIN U_D PE CLK P1 P2 P3 P4 Q1 Q2 Q3 Q4 _COUT B_D VDD VGND vdd1={vdd} speed1={speed} tripdt1={tripdt}
Et en remplaçant les compteurs par des boitiers HC191 ou HCT191 : viewtopic.php?f=14&t=249256&start=90#p417101 si jamais leur modèle spice était disponible et surtout non lié au modèle CMOS problématique.
Attention, le 191 n’a pas d’entrée reset, pour le resetter, il faut le prépositionner à zéro.
De plus en plus curieux
J’ai refait un schéma complet avec le DAC7533 branché comme sur les versions 5.
Évidemment, même symptôme qu’avant, toujours cette pulse audécomptage.
Par acquis de conscience, je me suis servi de Cout2 pour commander le flip-flop en laissant le 3ème CD4516 branché.
Bingo! ça fonctionne
Déjà, on peut en conclure que le modèle spice du 4516 est bon.
Évidemment on ne balaye pas sur toute la plage du DAC, on est normalement que sur 8 bits donc la tension max de la rampe doit être de VCC/(2 puissance 10) * (2 puissance 8) soit 12/1023*127 = 1.49V. Or, sur la courbe on est à 3V soit VCC/(2 puissance 10) * (2 puissance 9) =2.98V.
Pourquoi déborde-t-on sur le bit 9 alors que Cout2 vient d’inverser la rampe ?
Est-ce le même phénomène avec Cout3 qui fait déborder sur le bit11?
Est-ce que, comme je le suppose depuis un moment, il y a conflit entre un comptage sur 12 bits et un DAC 10bits.
Je vais ajouter 2 bits au DAC pour tester…(à mon avis ça va être bon)
Ayant retrouvé dans un « fond de tiroir » un CAN AD7845 acquit il y a des lustres, mais qui n’avait jamais utilisé, plus aucun obstacle maintenant pour câbler le générateur de rampe et tester en réel le schéma sur lequel bogue le simulateur.
Aussitôt dit, presque aussitôt fait, le temps de débarrasser une plaque de récupération de ses composants pour pouvoir y wrapper les nouveaux boitiers.
Un boitier hex trigger de Schmitt CD40106 à été utilisé plutôt qu’un CD4093. Ceci permet d’éviter de câbler directement la sortie de l’oscillateur sur les entrées des compteurs en insérant un des inverseurs de ce boitier dans la liaison, procurant ainsi une séparation entre le premier et les seconds qui devrait être salutaire .
L’oscillateur délivre un signal dont le rapport cyclique est proche de 50% avec une périodicité de 18,4 µs (? = RC = 10 k? × 1 nF = 10 µs) donc une fréquence avoisinant les 55 kHz.
Pour l’instant le câblage des compteurs n’est pas définitif :* Ils sont temporairement câblés en mode « parallel clocking »
Il ne font que compter, les entrées UP/DOWN sont reliées au +5 volts.
Pour l’instant tout semblerait OK à l’oscilloscope. Sauf que, le flip-flop s’inverse toutes les 74 ms alors que le calcul donne ?79,5 ms comme résultat (18,4 µs × 4096). Manquerait-il un pas au comptage? (79,5 ÷ 16 = ?4,7 ms)? Est-ce dû à l’imprécision de la base de temps de l’oscilloscope ou de l’observation ? Va donc falloir sortir l’analyseur logique pour vérifier tout cela.
Bonjour,
Enfin du concret
J’ai essayé plusieurs configurations sur LTspice mais définitivement, ça ne va pas.
Je me demande quand même quelle est l’influence d’un comptage 12 bit avec un DAC 10 bit. J’ai essayé de masquer les bits 11 et 12 avec le preset mais je ne suis pas arrivé à faire fonctionner.
Bon câblage
Quelques soucis avec l’inversion comptage/comptage à rebours.
Déjà le schéma du mode « ripple clocking » est faux, si on le câble comme préconisé, hé bien le dernier compteur reçoit une salve de 16 coups d’horloge au lieu d’un seul.
Ce schéma ne fonctionne que si l’on conserve les liaisons Cout/ Cin/ du mode « parallel clocking » ou que si l’on ramène le Cout/ du premier compteur sur la porte OR qui pilote le dernier compteur, ce qui nécessite le remplacement du OR à deux entrées d’un CD4071 par un OR à 3 entrées d’un CD4075.
Un peu de news de la simulation.
Mon problème était de gérer un DAC 10 bits avec une cascade de 3 compteurs 4 bits (soit 12 bits) et les 2 bits en trop du comptage me généraient des troubles de fonctionnement (peut-être aussi liés au modèles de simulation des compteurs, mais je n’en suis plus aussi sûr).
Après bien des essais, j’ai enfin réussi à avoir une belle rampe variant de 0 à VCC aussi bien en positif qu’en négatif en ajoutant 2 bascules CD4013) à la suite de 2 compteurs CD4516, représentant 10 bits au total.
Il ne me restera plus à présent qu’à inverser le sens de la rampe…
Ben apparemment, inverser le sens de comptage quand on arrive aux extrêmes (0 ou 15) est beaucoup moins évident qu’il pourrait paraître, même en respectant les préconisations des datasheets.
J’y suis arrivé mais la solution ne me plait pas, pas plus qu’elle ne plaira au sieur sylvanus car elle fait appel à une cellule RC retardatrice.
Compteurs câblés en mode « parallel counting ».
Câblage d’un CD4514 sur le dernier compteur pour décoder les positions 0 et 15.
Flip flop actionné par la sortie 15 du décodeur sur son « Set » et par la sortie 0 sur son « Clear ».
Entrée D la deuxième bascule du CD4013 connectée sur la sortie Q du flip flop.
Sortie Q barre de cette deuxième bascule connectée sur les entrées Up/Down des compteurs.
Cellule RC (10 k? / 330 pF soit 1/2 pas d’horloge) insérée entre sortie Cout barre du dernier compteur et entrée d’un inverseur du CD40106, sortie de cet inverseur connectée sur l’entrée « clock » de la deuxième bascule du CD4013.
Accessoirement, entrée "clock et « D » du flip flop à la masse. Entrée « set » de la deuxième bascule à la masse, son « clear » est relié au reset général.
En fait, la simulation a soulevé un drôle de lièvre effectivement beaucoup moins simple à résoudre qu’il n’y paraissait au 1er abord…
Bonne continuation et persévérance.
Doctsf (Modèles & Marques)
Annonces
