[Thomson] SDDRIVE
Modérateurs : Papy.G, fneck, Carl
Re: [Thomson] SDDRIVE
Daniel, maintenant que tu as identifié le défaut sur la génération du SCK, il faudrait que tu identifies quel est la ligne d'adresse qui le provoque.
Tu as un analyseur 8 voies, tu peux faire cela en deux fois. Personnellement je pencherai pour incriminer /Axxx, ou /Exxx plus précisément sur TO.
Tu as un analyseur 8 voies, tu peux faire cela en deux fois. Personnellement je pencherai pour incriminer /Axxx, ou /Exxx plus précisément sur TO.
Patrick
Re: [Thomson] SDDRIVE
Bonne idée !
Voici une analyse avec le signal SCK et 7 lignes d'adresse en entrée.
Canal 0 = SCK (sortie du 74LS133)
Canal 1 = /Axxx (inversé ensuite avant l'entrée dans le 74LS133)
Canal 2 = A11 (inversé ensuite avant l'entrée dans le 74LS133)
Canal 3 = A10 (entrée directe dans le 74LS133)
Canal 4 = A9 (entrée directe dans le 74LS133)
Canal 5 = A8 (entrée directe dans le 74LS133)
Canal 6 = A7 (entrée directe dans le 74LS133)
Canal 7 = A6 (inversé ensuite avant l'entrée dans le 74LS133)
On remarque que le glitch se produit quand plusieurs lignes d'adresse changent d'état en même temps, mais c'est probablement sans rapport.
Une explication possible serait un retard pour les lignes /Axxx, A11 et A6, car elles passent par un inverseur dont le temps de propagation n'est probablement pas négligeable. Je vais mesurer précisément ce temps de propagation.
A noter que le glitch montré par l'image ci-dessus ne se produit pas toujours. J'ai trouvé plusieurs endroits où les signaux en entrée sont identiques et la sortie est bonne, mais c'est assez rare : le plus souvent il y a le petit créneau de 42 nanosecondes.
Pub : il y a ici un Hantek 6022 BL à vendre. Il rassemble en un seul appareil un oscilloscope 6022 BE (comme le mien) et un analyseur logique 16 canaux (mieux que le mien).
Voici une analyse avec le signal SCK et 7 lignes d'adresse en entrée.
Canal 0 = SCK (sortie du 74LS133)
Canal 1 = /Axxx (inversé ensuite avant l'entrée dans le 74LS133)
Canal 2 = A11 (inversé ensuite avant l'entrée dans le 74LS133)
Canal 3 = A10 (entrée directe dans le 74LS133)
Canal 4 = A9 (entrée directe dans le 74LS133)
Canal 5 = A8 (entrée directe dans le 74LS133)
Canal 6 = A7 (entrée directe dans le 74LS133)
Canal 7 = A6 (inversé ensuite avant l'entrée dans le 74LS133)
On remarque que le glitch se produit quand plusieurs lignes d'adresse changent d'état en même temps, mais c'est probablement sans rapport.
Une explication possible serait un retard pour les lignes /Axxx, A11 et A6, car elles passent par un inverseur dont le temps de propagation n'est probablement pas négligeable. Je vais mesurer précisément ce temps de propagation.
A noter que le glitch montré par l'image ci-dessus ne se produit pas toujours. J'ai trouvé plusieurs endroits où les signaux en entrée sont identiques et la sortie est bonne, mais c'est assez rare : le plus souvent il y a le petit créneau de 42 nanosecondes.
Pub : il y a ici un Hantek 6022 BL à vendre. Il rassemble en un seul appareil un oscilloscope 6022 BE (comme le mien) et un analyseur logique 16 canaux (mieux que le mien).
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [Thomson] SDDRIVE
Merci Daniel !
Je regarderai maintenant les signaux /Axxx, A11, A6 et leur version inversée, SCK et A5 servant de témoin.
Tu visualiseras ainsi le retard.
Je regarderai maintenant les signaux /Axxx, A11, A6 et leur version inversée, SCK et A5 servant de témoin.
Tu visualiseras ainsi le retard.
Patrick
Re: [Thomson] SDDRIVE
Il n'y a plus aucun doute. La cause du glitch est identifiée, c'est le retard de propagation dans l'inverseur. Je l'ai mesurée pour une seule ligne, /Axxx, mais c'est suffisant pour conclure. La durée du glitch est identique au retard (42 nanosecondes). Pour les deux autres lignes inversées inutile de mesurer, le retard est forcément identique.
Canal 0 = SCK
Canal 1 = /Axxx (avant inversion)
Canal 2= Axxx (après inversion)
Remarque : la durée du retard est mesurée à 42 nanosecondes. C'est la limite de précision de l'analyseur (fréquence d'échantillonnage 24 MHz). En réalité on ne connaît pas exactement la valeur, elle doit être entre 0 et 80 nanosecondes. Il faut donc éliminer tout changement d'état qui ne dure pas plus de 100 nanosecondes et laisser passer au-delà..
Du coup j'ai tout compris : l'origine du glitch, évidente avec l'analyse ci-dessus, et la raison du bon fonctionnement de la démo "Imagine" : quand le programme est en RAM ($9000-$97FF) les lignes /Axxx et A11 ne changent jamais d'état, avec un peu de chance la ligne A6 ne change pas non plus, il n'y a donc jamais de retard de changement d'état. Evident !
Maintenant j'ai besoin de l'aide des électroniciens pour trouver la correction du schéma la plus simple...
(peut-être utiliser le signal CLOCK à 1MHz de l'ordinateur ?).
Canal 0 = SCK
Canal 1 = /Axxx (avant inversion)
Canal 2= Axxx (après inversion)
Remarque : la durée du retard est mesurée à 42 nanosecondes. C'est la limite de précision de l'analyseur (fréquence d'échantillonnage 24 MHz). En réalité on ne connaît pas exactement la valeur, elle doit être entre 0 et 80 nanosecondes. Il faut donc éliminer tout changement d'état qui ne dure pas plus de 100 nanosecondes et laisser passer au-delà..
Du coup j'ai tout compris : l'origine du glitch, évidente avec l'analyse ci-dessus, et la raison du bon fonctionnement de la démo "Imagine" : quand le programme est en RAM ($9000-$97FF) les lignes /Axxx et A11 ne changent jamais d'état, avec un peu de chance la ligne A6 ne change pas non plus, il n'y a donc jamais de retard de changement d'état. Evident !
Maintenant j'ai besoin de l'aide des électroniciens pour trouver la correction du schéma la plus simple...
(peut-être utiliser le signal CLOCK à 1MHz de l'ordinateur ?).
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [Thomson] SDDRIVE
Quelle est la vitesse de propagation de ton inverseur ?
D'après les datasheets que j'ai pu trouvé sur le net le delai n'est pas identique lorsque l'on passe de l'état bas à l'état haut et inversement
C'est beaucoup plus lent de l'état haut à l'état bas de l'ordre de 4 fois plus lent pour la série des 74LS
D'après les datasheets que j'ai pu trouvé sur le net le delai n'est pas identique lorsque l'on passe de l'état bas à l'état haut et inversement
C'est beaucoup plus lent de l'état haut à l'état bas de l'ordre de 4 fois plus lent pour la série des 74LS
Re: [Thomson] SDDRIVE
En fait c'est très peu, de l'ordre de quelques nanosecondes. On ne peut pas le mesurer avec l'analyseur logique 24MHz, ni même avec un oscilloscope échantillonnant à 48MHz. Ci-dessous /Axxx est en jaune, et Axxx (après inversion) est en vert.
Mais peu importe la durée, aussi petite soit-elle il y aura un glitch au changement d'état, car tous les signaux ne peuvent pas basculer rigoureusement en même temps, c'est de la physique et pas des mathématiques ni de l'informatique.
D'où mon idée :
- Quand l'horloge du processeur est à l'état bas, les adresses ne sont pas encore stabilisées. Je ne génère pas à ce moment là le signal SCK pour la carte SD, et j'évite ainsi tous ces phénomènes transitoires.
- Quand l'horloge du processeur est à l'état haut, les adresses sont stables et ne changent pas. Je peux alors générer un signal SCK propre.
Avec cette méthode, le signal SCK durera 0,5µs au lieu d'1µs, mais ça n'a aucune importance pour la carte SD qui peut se contenter de beaucoup moins. La preuve : elle est perturbée par un signal difficilement mesurable de quelque nanosecondes, alors pour elle 500 nanosecondes c'est une éternité.
Mais peu importe la durée, aussi petite soit-elle il y aura un glitch au changement d'état, car tous les signaux ne peuvent pas basculer rigoureusement en même temps, c'est de la physique et pas des mathématiques ni de l'informatique.
D'où mon idée :
- Quand l'horloge du processeur est à l'état bas, les adresses ne sont pas encore stabilisées. Je ne génère pas à ce moment là le signal SCK pour la carte SD, et j'évite ainsi tous ces phénomènes transitoires.
- Quand l'horloge du processeur est à l'état haut, les adresses sont stables et ne changent pas. Je peux alors générer un signal SCK propre.
Avec cette méthode, le signal SCK durera 0,5µs au lieu d'1µs, mais ça n'a aucune importance pour la carte SD qui peut se contenter de beaucoup moins. La preuve : elle est perturbée par un signal difficilement mesurable de quelque nanosecondes, alors pour elle 500 nanosecondes c'est une éternité.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
- Totor le Butor
- Messages : 2224
- Inscription : 07 sept. 2011 16:14
- Localisation : Paris - Mezels
Re: [Thomson] SDDRIVE
Bienvenue dans la face sombre des timings .
Tu peux tenter de mettre un condo d'environ 100 à 470 Pf entre la sortie du ET à 13 entrée et le 0V, il peut être nécessaire d'insérer une résistance de 470 ohms dans la sortie avant le condo, il faut tester car ça dépend de la charge induite par U1.4 et le module SD. Évidemment la clock résultante risque d'avoir une allure patatoïde qui peut ne pas être appréciée par les autres circuits.
Une autre solution qui marche à tous les coups mais ça je pense que tu l'avais dans la tête consiste à insérer une bascule synchrone, genre 7474, en sortie du ET à 13 entrée et de se servir de l'horloge à 1MhZ.
L'entrée sera transférée sur la sortie à chaque front montant de l'horloge, la sortie sera donc stable jusqu'au prochain front montant de l'horloge et ce quelque soit le signal sur l'entrée.
Concrètement tu mets à 1 en permanence les entrées Set et Preset, sortie du ET sur l'entrée D, entrée Clock sur la Clock du 7474 et la sortie Q devient la Clock de U1.4 et du module SD.
Tu peux tenter de mettre un condo d'environ 100 à 470 Pf entre la sortie du ET à 13 entrée et le 0V, il peut être nécessaire d'insérer une résistance de 470 ohms dans la sortie avant le condo, il faut tester car ça dépend de la charge induite par U1.4 et le module SD. Évidemment la clock résultante risque d'avoir une allure patatoïde qui peut ne pas être appréciée par les autres circuits.
Une autre solution qui marche à tous les coups mais ça je pense que tu l'avais dans la tête consiste à insérer une bascule synchrone, genre 7474, en sortie du ET à 13 entrée et de se servir de l'horloge à 1MhZ.
L'entrée sera transférée sur la sortie à chaque front montant de l'horloge, la sortie sera donc stable jusqu'au prochain front montant de l'horloge et ce quelque soit le signal sur l'entrée.
Concrètement tu mets à 1 en permanence les entrées Set et Preset, sortie du ET sur l'entrée D, entrée Clock sur la Clock du 7474 et la sortie Q devient la Clock de U1.4 et du module SD.
Born to bricole
[Rch] Vieux composants électroniques et circuits intégrés toute époque et vieilles cartes .
[Rch] Vieux composants électroniques et circuits intégrés toute époque et vieilles cartes .
Re: [Thomson] SDDRIVE
Eh oui, les amateurs ont encore beaucoup à apprendre. C'est la différence avec les professionnels.
Mais, petit à petit, avec les galères endurées, puis surmontées, on progresse. D'ici une vingtaine d'années je pourrai donner des cours sur les circuits TTL. Malheureusement ça n'existera plus depuis longtemps
Sur ce coup ci, le plus difficile était de mettre le doigt sur le problème.
Maintenant c'est fait, je n'ai plus aucun doute sur l'imminence d'une solution (voir ma signature).
Merci pour tous les conseils, ça m'aide beaucoup.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
- Totor le Butor
- Messages : 2224
- Inscription : 07 sept. 2011 16:14
- Localisation : Paris - Mezels
Re: [Thomson] SDDRIVE
Perso, j'apprends plus quand ça marche pas que quand ça marche .
Ton oscillogramme est curieux car, à bien regarder, je dirais que le signal vert est un petit peu en avance sur le jaune .Born to bricole
[Rch] Vieux composants électroniques et circuits intégrés toute époque et vieilles cartes .
[Rch] Vieux composants électroniques et circuits intégrés toute époque et vieilles cartes .
Re: [Thomson] SDDRIVE
Oui, j'avais remarqué. Mais avec le prix payé pour mon oscilloscope rien ne m'étonne.
[Edit]
Rectification : il y a une erreur dans la description de l'oscillogramme de mon post précédent. C'est le contraire : vert en entrée et jaune en sortie. Nous avons bien vu le décalage et l'oscilloscope n'y est pour rien.
[/Edit]
Sinon, j'ai enregistré le signal d'horloge à 1MHz du processeur (en jaune) et la ligne d'adresse /$Axxx (en vert). On voit bien que les changements d'état se font quand l'horloge est au niveau bas, et que rien ne bouge quand elle est au niveau haut.
J'envisage d'inverser l'actuel signal SCK malpropre, puis de l'envoyer avec le signal d'horloge ci-dessus dans une porte NAND.
Toutes les perturbations se produisant quand l'horloge est au niveau bas, elles seraient ainsi éliminées.
A la sortie je devrais trouver un signal SCK deux fois plus court, mais propre. Mon raisonnement est-il correct ?
[Edit]
Rectification : il y a une erreur dans la description de l'oscillogramme de mon post précédent. C'est le contraire : vert en entrée et jaune en sortie. Nous avons bien vu le décalage et l'oscilloscope n'y est pour rien.
[/Edit]
Sinon, j'ai enregistré le signal d'horloge à 1MHz du processeur (en jaune) et la ligne d'adresse /$Axxx (en vert). On voit bien que les changements d'état se font quand l'horloge est au niveau bas, et que rien ne bouge quand elle est au niveau haut.
J'envisage d'inverser l'actuel signal SCK malpropre, puis de l'envoyer avec le signal d'horloge ci-dessus dans une porte NAND.
Toutes les perturbations se produisant quand l'horloge est au niveau bas, elles seraient ainsi éliminées.
A la sortie je devrais trouver un signal SCK deux fois plus court, mais propre. Mon raisonnement est-il correct ?
Dernière modification par Daniel le 07 déc. 2017 09:05, modifié 1 fois.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
- irios
- Messages : 3396
- Inscription : 04 nov. 2007 19:47
- Localisation : Rochefort du Gard (30)
- Contact :
Re: [Thomson] SDDRIVE
Salut Daniel,
La solution la plus élégante et la moins onéreuse c'est l'utilisation d'un transistor en mode commutation. Le 2N2222 me semble le candidat idéal. Je te laisse le soin de calculer les résistances.
@++
La solution la plus élégante et la moins onéreuse c'est l'utilisation d'un transistor en mode commutation. Le 2N2222 me semble le candidat idéal. Je te laisse le soin de calculer les résistances.
@++
http://irioslabs.over-blog.com/
La connaissance ne vaut que si elle est partagée par tout le monde.
I2C
La connaissance ne vaut que si elle est partagée par tout le monde.
I2C
Re: [Thomson] SDDRIVE
Je veux bien essayer, mais avant je voudrais comprendre...
Où faut-il mettre le transistor ? Entre le 74LS133 et l'entrée SCK de la carte SD, je suppose ?
Comment supprime-t-il le glitch lors du changement d'adresse ? Parce qu'il est lent et n'aura pas le temps de réagir au double changement d'état ?
Où faut-il mettre le transistor ? Entre le 74LS133 et l'entrée SCK de la carte SD, je suppose ?
Comment supprime-t-il le glitch lors du changement d'adresse ? Parce qu'il est lent et n'aura pas le temps de réagir au double changement d'état ?
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
- irios
- Messages : 3396
- Inscription : 04 nov. 2007 19:47
- Localisation : Rochefort du Gard (30)
- Contact :
Re: [Thomson] SDDRIVE
Tu remplaces la porte non et u1.1 signal /Axxx par le transistor. Le 2N2222 est capable de commuter jusqu'à une fréquence de 100MHz. Une autre solution, c'est de positionner le signal /Axxx en tant que signal de validation de la porte non et multi entrées en sortie.
Enfin, pour moi la meilleure solution et après avoir étudié le datasheet, c'est de remplacer le ls133 par un s133. En effet les temps de commutation moyen sera de l'ordre de 8ns au lieu de 40ns. Temps nécessaire du changement d'etat d'un niveau haut vers un niveau bas.
Enfin, pour moi la meilleure solution et après avoir étudié le datasheet, c'est de remplacer le ls133 par un s133. En effet les temps de commutation moyen sera de l'ordre de 8ns au lieu de 40ns. Temps nécessaire du changement d'etat d'un niveau haut vers un niveau bas.
http://irioslabs.over-blog.com/
La connaissance ne vaut que si elle est partagée par tout le monde.
I2C
La connaissance ne vaut que si elle est partagée par tout le monde.
I2C
Re: [Thomson] SDDRIVE
Merci pour toutes ces solutions. Le signal /$Axxx n'est pas le seul inversé en entrée de la porte NAND. Il y a aussi A11 et A6. Il faudrait donc remplacer les trois inverseurs (actuellement des portes NAND 74LS00) par des transistors, pour diminuer le délai de propagation. Ou remplacer le 74LS133 par un 74S133 plus lent.
Je vais étudier successivement ces bonnes idées et celles de Totor.
Tout d'abord j'ai essayé la mienne : une porte NAND avec le signal d'horloge 1MHz et l'inverse de la sortie du 74LS133. Le glitch précédant le signal SCK est complètement supprimé, comme je m'y attendais. Malheureusement un nouveau glitch apparaît de temps en temps juste à la fin du créneau, et ça ne marche pas.
Ensuite j'ai essayé la première solution proposée par Totor : un filtre RC en sortie du 74LS133. J'ai déterminé les valeurs par approximations successives (ou plus exactement au feeling), pour arriver à 100 ohms et 470 pF. Ca marche. Pour la première fois le contrôleur SDDRIVE a réussi à initialiser la carte, trouver le fichier boot.sd, monter la disquette et lancer le programme de sélection SDSEL. Imaginez la joie de voir le logo SDDRIVE s'afficher à l'écran du MO5
Sur l'oscillogramme ci-dessous il y a en jaune le signal SCK en sortie du filtre RC et en vert le signal /$Axxx provenant du MO5. On voit bien l'atténuation du glitch au moment où /$Axxx change d'état (1µs avant la descente de SCK). Le signal SCK lui-même est un peu arrondi mais reste propre.
Je n'en reste pas là, car le glitch n'est pas totalement éliminé. J'ai peur que dans certaines conditions (par exemple un petit écart dans la tension d'alimentation) il provoque une instabilité du contrôleur. Je vais essayer les autres propositions que vous avez faites.
@Totor: Quand on trouvait que le signal inversé avait plutôt de l'avance sur le signal en entrée, ce n'était pas un défaut de l'oscilloscope, mais de l'opérateur qui avait un peu mélangé les deux sondes En fait c'est vert en entrée et jaune en sortie. On voit bien que le signal vert est un peu arrondi par le filtre ajouté à chaque ligne d'adresse. Le signal jaune, en revanche, est la sortie de l'inverseur non filtrée.
Je vais étudier successivement ces bonnes idées et celles de Totor.
Tout d'abord j'ai essayé la mienne : une porte NAND avec le signal d'horloge 1MHz et l'inverse de la sortie du 74LS133. Le glitch précédant le signal SCK est complètement supprimé, comme je m'y attendais. Malheureusement un nouveau glitch apparaît de temps en temps juste à la fin du créneau, et ça ne marche pas.
Ensuite j'ai essayé la première solution proposée par Totor : un filtre RC en sortie du 74LS133. J'ai déterminé les valeurs par approximations successives (ou plus exactement au feeling), pour arriver à 100 ohms et 470 pF. Ca marche. Pour la première fois le contrôleur SDDRIVE a réussi à initialiser la carte, trouver le fichier boot.sd, monter la disquette et lancer le programme de sélection SDSEL. Imaginez la joie de voir le logo SDDRIVE s'afficher à l'écran du MO5
Sur l'oscillogramme ci-dessous il y a en jaune le signal SCK en sortie du filtre RC et en vert le signal /$Axxx provenant du MO5. On voit bien l'atténuation du glitch au moment où /$Axxx change d'état (1µs avant la descente de SCK). Le signal SCK lui-même est un peu arrondi mais reste propre.
Je n'en reste pas là, car le glitch n'est pas totalement éliminé. J'ai peur que dans certaines conditions (par exemple un petit écart dans la tension d'alimentation) il provoque une instabilité du contrôleur. Je vais essayer les autres propositions que vous avez faites.
@Totor: Quand on trouvait que le signal inversé avait plutôt de l'avance sur le signal en entrée, ce n'était pas un défaut de l'oscilloscope, mais de l'opérateur qui avait un peu mélangé les deux sondes En fait c'est vert en entrée et jaune en sortie. On voit bien que le signal vert est un peu arrondi par le filtre ajouté à chaque ligne d'adresse. Le signal jaune, en revanche, est la sortie de l'inverseur non filtrée.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.