[WIP] Outil de déclenchement pour oscillo

[f4brice]

Bonjour.

Voilà, je me lance dans le WIP de fabrication d'un outil qui me manque quand je dépanne un PCB.
En effet, il arrive qu'un bug graphique ou tout autre problème ne soit présent qu'à un endroit de l'écran.
Lorsque je promène la sonde de mon oscilloscope ici et là sur le PCB malade, le déclenchement de l'affichage de l'oscillo se fait au p'tit bonheur la chance.
C'est à dire que je suis certain de ne jamais voir 2 fois la même chose car les différentes RAM, ROM et autres composants sont utilisés en permanence pour générer l'image.
En pratique, je vois un signal logique qui change à toute vitesse et qui n'a rien de cohérent.

Ce dont j'ai besoin, c'est d'un outil qui analyse l'image (en tout cas son signal de synchro) et qui puisse me permettre de piloter le déclenchement de mon oscillo à partir de la N^ième ligne affichée...
Ainsi, si au milieu de la N^ième ligne affichée se trouve un sprite buggé, alors je pourrais analyser les signaux électroniques du PCB au moment exact où il est en train de générer cette N^ième ligne, et non pas tout autre instant aléatoire.
Là, normalement, j'ai une chance d'observer le PCB tenter de lire les data du sprite en RAM ou en ROM et de comprendre pourquoi il y a un problème.

L'outil en question, je l'ai baptisé "LineTrigger".

Voici ce que je pense réaliser :

• affichage en clair du numéro de la ligne en cours de synchro
• affichage en clair du délai (probablement en µs) supplémentaire pour synchro au milieu de la ligne choisie
• utilisation de boutons pour facilement changer le numéro de la ligne et le délai
• composants pas trop chers, et facile à trouver
• tout mon travail sous license GPL / Creative Common

Voici l'état d'avancement :

• un microcontrôleur PIC modèle 16F84A-20 sera utilisé (coût : 6,00 €)
• un afficheur LCD de 2 lignes de 16 caractères sera utilisé (coût : 6,00 €)
• je pense me simplifier la vie en utilisant un séparateur de synchro LM1881 (coût : 4,30 €)

La réalisation actuelle :

Le PIC est sur un support "ZIF" (Zero Insertion Force) de récupération, car il fait de nombreux aller-retours entre la plaque d'essais et le progammateur !

La procédure d'initialisation de l'afficheur est faite, avec les bons timings !
J'utilise mon analyseur logique pour examiner de près ce que j'envoie à l'afficheur LCD, et avec quels timings.
J'utilise une machine virtuelle Zindoz XP car le logiciel fourni avec l'analyseur ne fonctionne que sur ce système d'exploitation.

Le pilotage de l'afficheur semble correct !

À suivre...

[AsPiC]

Ce genre d'outils n'existe pas déjà
Dans tous les cas bravo pour ta démarche participative

Je trouve vraiment le petit monde de l'arcade française super dynamique en ce moment

[gottlieb]

Magnifique le projet/travail que tu réalise F4brice 

Dans tous les cas bravo pour ta démarche participative

Je trouve vraiment le petit monde de l'arcade française super dynamique en ce moment

Quand je vois les réalisations et compétences en électronique de certaines personnes du forum, j'en serais presque "jaloux    " Mais je suis fière de faire partie de cette communauté qui s'investissent dans des projets fou, faisant avancer tout ce qui touche notre passion commune l'ARCADE et sa préservation 

Encore un projet que je vais suivre en essayant de comprendre et en me torturant les neurones 

 

Gottlieb

[spectroman]

bravo, super projet.

j'ai pas compris un point :
comment tu fais pour régler le numéro de la ligne qui a le défaut?
tu ne connais pas précisément le numéro de la ligne qui a le bug que tu vois a l'écran.

tu procède par réglage successif?

est-ce risqué de mettre 3 sorties en collecteur ouvert sur les signaux RVB pour générer une trainé noire au temps réglé?

[Little_Rabbit]

Salut,

Génial ce projet F4brice, ce sera effectivement un outil super pratique !!

Je trouve la suggestion de spectroman intéressante (mais ne mesure pas forcément son incidence sur la charge des signaux RVB...).

Au niveau IHM, ce qui serait top pour sélectionner le n° de ligne, ce serait d'utiliser une molette à base de roue codeuse !  Bon OK, ça complique et c'est plus cher . Un bouton poussoir avec accélération progressive du n° sélectionné fera déjà très bien l'affaire .

Bon courage pour ce WIP, et merci d'avance pour le partage !

A+

[aje_fr]

Salut.
 Tu t'embetes pas avec ton pic ?
 Si tu avais utilisé un monostable précis déclenché sur la synchro sur le JAMMA.
 Genre un 4538 avec un potar pour regler le bon moment.
A plus

Ps je vois à peine l'utilite d'un tel outil.

[f4brice]

Bonsoir.

J'ai avancé sur le schéma :

J'utilise la suite d'outils open-source "gEDA" : http://www.geda-project.org/.
Rien de bien compliqué une fois que les concepts essentiels ont été compris, mais c'est la première fois que j'utilise ce genre d'outils. D'habitude, je fais ça "à la main" avec les transferts Mecanorma...

Juste pour voir, j'ai commencé aussi le futur PCB :

Rien d'extraordinaire, à part que j'ai dû faire moi-même l'emprunte ("footprint") de plusieurs éléments :

• l'afficheur LCD Seiko L1652 acheté chez Électronique Diffusion
• la résistance variable pour le contraste du LCD (je ne comprends par pourquoi ça n'existait pas)
• les boutons poussoirs

J'ai simplement tenté un routage automatique à la barbare...
Les pistes seront à reprendre en manuel pour améliorer tout ça.

J'ai aussi commencé à mettre en oeuvre le LM1881.
Là, il y a un fonctionnement que je ne comprends pas...
Je l'ai câblé comme sur mon schéma plus haut.
Je lui injecte sur sa broche #2 à travers un condo de 100 nF le signal de synchro généré par un PCB qui fonctionne parfaitement bien.
En sortie, sur sa broche #3, je devrais avoir un signal débarrassé des tops de synchro horizontale.
Pourtant, voici ce que je mesure :

J'ai vérifié à l'oscillo, et ce n'est pas une erreur de l'analyseur logique.
J'ai essayé avec un 2e LM1881 et aussi avec 2 autres PCB, j'ai toujours le même fonctionnement.

Si quelqu'un a une idée du pourquoi mon LM1881 ne filtre pas les top de synchro H, je suis preneur de l'explication !

Si je ne peux pas faire fonctionner le LM1881 comme je le pensais (extraire la synchro verticale sans transpirer), je risque de devoir le faire en pur logiciel et là ça risque d'être tendu (mais intéressant)...

À suivre...

[gc339]

Si quelqu'un a une idée du pourquoi mon LM1881 ne filtre pas les top de synchro H, je suis preneur de l'explication !

Une piste à explorer :

Le LM1881 est prévu pour fonctionner avec un signal vidéo composite d'entrée dont l'amplitude, pour une ligne complètement blanche, est comprise entre 0,5 Vpp et 2 Vpp.
Le top de synchro représente 30% de cette valeur, l'amplitude des impulsions de synchronisation seules devrait donc être comprise entre 150 mV et 600 mV.
L'amplitude du signal de synchronisation en sortie du connecteur Jamma étant au minimum celle d'un signal TTL, c'est à dire comprise entre 5 volts et ≈3,5 volts, un atténuateur devrait normalement être inséré pour abaisser le niveau à une amplitude compatible avec les exigences du LM1881.

[kaitan]

alors ca en est où ?

je suis curieux !

[f4brice]

Bonjour.

Ca avance à la vitesse d'un escargot, mais ça avance, bien que je ne l'aie pas touché depuis un moment.
J'ai réussi à faire tomber en marche le LM1881, mais il nécessite un réglage assez fin de la résistance connectée à sa broche 4.
Vu que c'est incompatible avec l'usage de l'outil (je le veux simple et sans réglage électronique), j'ai décidé de me passer du LM1881.

J'ai réussi à me passer du LM1881 en injectant directement le signal de synchro du JAMMA sur le PIC.
Avec un bout de logiciel bien pensé, j'arrive à différencier le top de synchro trame parmis tous les top lignes.

Reste à faire :
- mesurer la durée entre 2 tops de synchro trame (l'unité est le nombre de ticks de 1/512e de ms)
- mesurer la durée entre 2 tops de synchro ligne (l'unité est le nombre de ticks de 1/4096e de ms)

Dès que j'aurai ces deux valeurs qui correspondent à une durée (donc exprimée en sous-multiple de seconde), le reste est déjà là : j'ai écrit le code (toujours en assembleur) qui permet grosso-modo de calculer la fréquence avec la formule "fréquence = 1 divisé par période" :
- la fréquence trame (en BCD et en dixièmes de Hz) ; exemple : "10385 ticks de 1/512e de ms" => 0x040903 => 49,3 Hz
- la fréquence ligne (en BCD et en centièmes de kHz) ; exemple : "2622 ticks de 1/4096e de ms" => 0x01050602 => 15.62 kHz
Ensuite, c'est du gâteau à afficher sur le LCD.

J'ai également terminé la gestion des 4 boutons "plus", "moins", "précédent", "suivant".
Ils permettent de choisir manuellement :
- le numéro de la ligne où l'oscillo doit être déclenché
- un délai supplémentaire de déclenchement (en µs)

Donc pour résumer, restent à faire :
- mesure durée trame
- mesure durée ligne
- comptage nombre de lignes
- réaliser le déclenchement de l'oscillo

Pour le moment, le logiciel utilise 47% de l'espace disponible dans le PIC, malgré l'utilisation de MACROs pour simplifier l'implémentation d'une algèbre 24 ou 32 bits sur un processeur 8 bits.