[WIP 60%] Normaliser un signal vidéo

Ce soir, j'ai pris mon courage à 2 mains et j'ai fini par souder les deux registres à décalage qui vont donner les valeurs de référence aux compteurs,  et le paquet de fils qui vont avec.
J'ai viré tous les fils qui indiqueraient la valeur des compteurs sur les LED, ça ne servira à rien plus tard.
J'ai aussi installé le 3ème GAL en série pour avoir un compteur 12 bits.
Accessoirement, j'ai réussi à faire marcher mes vieux GAL Latice (ça n'existe plus) dont j'avais acheté un stock pas cher.  J'ai pu les mettre à la place des GAL Atmel un peu trop biens (chers) pour servir de compteurs. Il y a une feinte sur ces GAL qui fait que quand on marche en mode registre (avec une ligne d'horloge), ça active d'office une ligne Output Enable. Chez Atmel, elle est True par défaut. Chez Latice, elle est à False. Résultat: je n'avais pas de sorties visibles et j'en avais déduit que ces vieux machins ne fonctionnaient pas. J'ai eu un pin à raccorder à la masse pour faire marcher tout ça.
Et puis histoire de garder de la marge, j'ai anticipé une éventuelle recherche de précision supplémentaire et j'ai tenté d'envoyer un signal d'horloge à 40MHz au lieu de 20 dans le système. Résultat: toute la chaîne fonctionne bien, mais on bouffe pas mal de parasites.
Ma prochaine action sera donc d'ajouter des condensateurs de découplage sur toutes ces puces.
Ça tombe bien, j'en avais acheté une bonne centaine en Chine. Par contre, je ne sais pas où j'ai mis le sac. Avec les travaux à la maison, c'est la foire aux composants dans toutes les pièces.

La suite, ce sera d'écrire l'algo de génération de HSync décalé. Je vais commencer en gérant uniquement les HSync, et j'utiliserai mon générateur de fonctions pour simuler un signal 15kHz qui ne fait que sauter à la ligne suivante et ne génère jamais de VBL.
Après ça, je ferai le code du microcontrôleur qui va piloter les 3 GAL via les 2 registres à décalage, puis je me casserai la tête sur le code du GAL qui va générer le signal HSync en s'appuyant sur le 3ème GAL (parce qu'ils sont chaînés, trop fort).
Après ça, je pense pisser de joie,  puis attaquer la gestion du VSync, qui est toujours douloureuse parce que chaque PCB fait ce qu'il veut en la matière!

Et nous voici donc avec, par ordre d'apparition:
- 1 microcontrôleur Arduino qui lit un décalage sur on potar et le transmet au circuit via...
- 2 registres à décalage qui stockent la valeur du décalage pour que les compteurs puisse s'y référer
- un oscillateur à 20MHz, qui cadense donc les GAL avec une période de 50 nanosecondes.
- 3 GAL programmés en compteurs/ comparateurs 4 bits et collés pour faire 12 bits, qui temporisent après détectuon d'un HSync
- 1 GAL programmé en compteur 9 bits (pourquoi pas 9, j'avais une patte en plus) qui permet d'attendre 8 microsecondes, le temps de générer un HSync
- 1 GAL programmé pour générer des HSync décalés en pilotant les 2 compteurs



J'alimente ça avec un générateur de fonctions arbitraire, lui-même programmé pour sortir des signaux HSync à 15 kHz:



Et tout ça pour produire un HSync crade après 2h de debugging intensif.



C'est moche et ça saute. Je vais ajouter des condensateurs de découplage sur les 2 derniers GAL. C'est déjà fait sous les 3 autres. Ça devrait éviter des pics. Et puis il y a des offsets de tension parce que j'ai une masse qui se promène entre 2 plaques. Et puis je n'ai sûrement pas encore trouvé tous les problèmes !

En tout cas, ça sort quelque chose, et je suis donc déjà plutôt content!

A effectivement la sortie est bruitée. Les condensateurs et le défaut de masse devraient améliorer le truc.
Avec tout ces débuggages, quand le truc sera fini il sera aux petits oignons.

Pour la sortie bruitée, j'ai des éléments de réponse. Le principal souci est que les GAL consomment un max. Avec le précédent montage, ils étaient tous les 5 alimentés par le mini régulateur de l'Arduino, lui-même alimenté par le port USB du PC. Il y avait de la perte de charge à tous les niveaux.
J'ai pu réduire un peu le bruit et régler les problèmes d'alim en basculant l'Arduino directement sur la plaque, sous la forme d'un Pro Mini. Du coup, tout est intégré et alimenté par une alim de labo stabilisée. L'occasion de voir que ce petit monde consomme 2W (400mA). C'est énorme!
Le montage ressemble à ça :



Pour réduire encore plus le bruit, il faudrait que je tire, en plus des pistes existantes, des lignes de masse et d'alimentation en étoile pour chaque GAL.
Je ne pourrai pas faire de miracles dans tous les cas, l'oscillateur injectant du bruit à 20MHz dans les alimentations (d'ailleurs je n'ai pas collé de condo sur son alimentation, il faut que je tente!)

En attendant, si je ne mets pas l'oscillo en mode psychopathe, c'est quand même plutôt lisse:



J'ai zoomé sur un créneau et mesuré la variation temporelle de mon signal produit, histoire de voir si ça tremblerait comme mes montages précédents.
J'observe bien une erreur, mais de l'ordre de 70 nanosecondes (soit un tiers de pixel environ).

Petite démo avec le signal de référence en haut et le signal généré en bas, on voit que ça ne bronche pas. Et puis je joue à le déphaser avec le potar...



Note que je pense aller au bout du test avec ce matériel. Il me reste à gérer les VSync et je pourrai faire un test pour de vrai.
Après ça, j'ai enfin trouvé un adaptateur pour programmer des CPLD, et j'ai commandé une carte de test à 7€ en Chine. Ces trucs sont bien plus puissants que mes GAL actuels, et consomment bien moins. J'espère donc pouvoir m'en servir en lieu et place de ce tas de composants qui chauffent un jour ou l'autre.

2W, si tu ajoutes à ta carte de track'n field, va falloir une alim externe.
Pas con l'idée de la masse en étoile. Sur la plaque c'est relou mais sur une piste finale c'est plus facile.
Espérons que le H et le V n'interagissent pas ensemble, du moins ne se parasitent pas entre eux.

poup a écrit:Espérons que le H et le V n'interagissent pas ensemble, du moins ne se parasitent pas entre eux.

Le H et le V passent sur le même fil. La différence entre les deux est que le VBL est majoritairement au niveau bas (0V), avec des impulsions par ligne, ou pas, en fonction du PCB.
C'est là que le microcontrôleur intervient. Il mesure les alternances et détecte si on est en cours de VBL ou non.
Le souci, c'est le fait que tous les PCB ne l'implémentent pas de la même manière. Certains mettent juste le signal de synchro à 0V pour la durée de 8 lignes de balayage. Et ceux-là, c'est une plaie pour les gérer. Parce que si je veux gérer un offset vertical, il faut, pour certaines lignes, que je synthétise un signal HSync à partir de rien (puisque je n'ai pas de signal de référence).
Bref, ça va être casse bonbons!

Bon, note positive, j'ai reçu l'interface JTAG pour programmer les CPLD et les FPGA. J'ai fait un test avec ma carte FPGA achetée il y a méga longtemps, et... miracle, ça ne plante plus mon Windows ET j'ai pu programmer le FPGA.enfin j'ai allumé 3 LEDS, on ne s'enflamme pas, mais ça marche!
C'est bon pour la suite de ce bricolage et pour les futurs!

Bah oui on est en RGBs et pas en RGBhv je suis con.
Merde c'est la plaie si les PCB ne sortent pas toute le signal de la même façon. Pour recréer le signal tu ne peux pas faire un signal qui retient le dernier qu'il a reçu différent de zéro ?

J’adore tes projets, tu vises toujours juste!
J’ai un écran pro utilisé en mur auparavant et pas la télécommande d’origine (module central gérant le mur complet) permettant de gérer les décalages ou plutôt les zooms (haut bas gauche droite).
Bidouillage permettant de simuler des états successifs de menu caché jusqu’à un dezoom, mais l’état ne tient pas. En gros il faudrait fabriquer une télécommande comme pour les platine E3/NNC mais aucune doc dispo pour ce matos; ou pouvoir modifier la taille / la position de l’image entre la source et le diffuseur.
L’écran est RGBS, il synchronise sur C-Sync et n’est pas chiant, il prend le c sync d’une console jap, et j’ai même relié Hsync et Vsync d’un vga en 480i, avec ou sans résistance, ça passe.
Il prend du DB9, j’ai fabriqué un adaptateur Peritel femelle vers DB9 et un câble de test qui me permet de modifier au loisir pour lui balancer l’un ou l’autre signal de synchro.

Bref tout est ok quelle que soit la source maintenant mais si je pouvais intercaler un module comme le tien dans la chaîne ce serait du bonheur.

Beau projet!

Sympa, ça ! Mon module permet(tra?) De recentrer l'image, pas de faire des zooms. Je pourrai tester l'impact de la largeur d'impulsion HSync, mais je pense que c'est un réglage de l'écran sur la bobine du balayage horizontal, pas une variation de signal de synchro.
Pour faire du zoom, il faudrait pouvoir modifier le timing des signaux R, G, B mais à part échantillonner et reproduire le signal, je ne vois pas de solution. Et ça, ça implique un peu de perte et du matériel (microcontrôleur, FPGA et un ADC ultra tapide).
Par contre, pour ta bidouille de zoom qui ne tient pas, j'aurais une solution à base d'optogoupleurs pour simuler les appuis de boutons sur la commande. C'est ce que j'ai fait sur mon GBS qui perdait les réglage au reset :

Ca fait 2 fois que j'en parle cette année, tiens!

En fait quand je parle de zoom c’est pour expliquer le rendu.
Techniquement, si on dit que l’écran est en haut à gauche du mur, on agrandit l’image H et décalage à droite, on agrandit l’image V et décalage vers le bas.
Donc la simulation des « zooms » c’est simplement une modification programmée de position(s) et taille(s).
En agissant en amont dans le sens inverse, je pourrais recentrer l’image.
Et repiquer les signaux issus d’autre chose qu’un peigne jamma sur ta carte sera à priori simple.
Là où je n’ai pas tout dit, et c’est aussi pour ça que ta carte semble être une solution, c’est que même avec la bidouille manuelle, ça dépasse encore légèrement.

Je suis ton Topic de prêt

Et un nouvel acteur entre en scène...
La carte de développement CPLD et son interface de programmation qui ne plante pas mon PC!
... plus qu'à apprendre encore un nouveau langage .

... et pour bricoler avec le CPLD, vu que j'ai acheté le modèle le moins cher... je viens de me fabriquer une plaque qui se met dessus et qui propose les fonctionnalités suivantes:
- un connecteur 8 pins avec conversion de signaux 3.3V / 5V bidirectionnel pour brancher le microcontrôleur, le signal vidéo d'entrée et le signal de sortie
- un connecteur d'horloge pour synchroniser sur l'horloge 50MHz du CPLD
- un connecteur de masse parce que c'est toujours pratique
- deux interrupteurs pour jouer avec (raccordés au CPLD)
- 1 LED témoin d'alimentation en 3.3V
- 2 LED pour jouer avec (raccordées au CPLD)

Avec ça, je devrais arriver à reprendre le circuit existant. Je n'ai pas encore trop d'idée de la capacité du CPLD, maiw il doit y avoir moyen de caser dedans la logique des 5 GAL et des deux registres à décalage.
Et tout ça pour une consommation avoisinant les 30mA a priori (mais pour le moment il ne fait pas grand chose).
Il me tarde de voir ce que je pourrai en tirer (quand je comprendrai le Verilog, bien-sûr .

Ce soirs, petits essais avec ce montage et débuts en Verilog.
J'arrive à diviser l'horloge par 50 000 et à faire clignoter les LEDS en opposition 1 fois par seconde, en inversant leur état avec les 2 boutons.
Je teste des choses pour voir à quelle vitesse se remplit la mémoire du CPLD. Rien que pour faire ça, je bouffe 28% des blocs logiques disponibles!

Et devinez qui est en train de péter un câble en tentant de programmer en verilog un échantillonnage du signal de synchro?
J'y ai passé un nombre d'heures considérable et je tourne en rond. Je dois louper un concept.

Courage car je ne te serai d'aucune aide

Eh ben aujourd'hui, j'ai abandonné le verilog au profit du VHDL.
Ce sont des approches différentes et une syntaxe bien différente, mais les possibilités des deux langages sont censées être équivalentes.
Dans les faits, le compilateur VHDL est moins permissif que le compilateur verilog, et il me remonte des problèmes intéressants.
Bon, concrètement, j'arrive au même résultat bizarre qu'avec verilog, mais j'ai l'impression de maîtriser ce que je fais!

Sisi, tu m'aides. Le support moral, c'est important, merci .

J'ai profité de mes congés loin de chez moi pour bosser sur le code de ce déphaseur de synchro.
J'étais déjà passé du langage Verilog au VHDL (je préfère), et là, j'ai revu toute l'architecture du programme pour que ça ne ressemble justement plus à un programme (c'est une gymnastique mentale à faire!).
Il me tarde de rentrer demain pour tester ça!
A noter que j'en ai profité pour écrire un IO expander de 2x32 bits pour CPLD pour le projet de télécommande BVM. Ca ne se monte pas sur une breadboard, mais ça remplace 4 multiplexeurs et 4 registre à décalage. Et le tout pour 2€ environ. => je commence à aimer ce machin!

Eh ben j'aurais dû partir en congés plus longtemps, parce que ça ne marche toujours pas
Je ne suis pas forcément super loin, mais ce n'est pas bon pour autant...
Je n'arrive pas à avoir des impulsions de 8µs et les impulsions se répètent avec une période du délai de déphasage.
Bref, je bosse dessus, je découvre encore des erreurs à ne pas faire, ça progresse, mais c'est un autre monde...
En tout cas, le déphasage est méga stable pour ce que je peux en voir!

Eh ben comme quoi, le fait de partager...

J'ai fini par comprendre ce qui n'allait pas, j'ai corrigé les différents problèmes, et j'ai intégré la logique pour la configuration du délai de déphasage par un bus série SPI. Comme ça, je peux le piloter avec un micro-contrôleur.
Je me retrouve maintenant exactement dans la même configuration qu'avec ma plaque de la mort, ses 2 registres à décalage et ses 5 GAL qui me bouffaient un courant de plus de 300mA à elles-seules.
Sauf que là, ça marche complètement, tous les cas sont gérés, et tout est intégré dans le CPLD => Ca consomme 36mA!
Prochaine étape: gérer les VBL en entrée, compter les lignes, et gérer les offsets verticaux.
Ca ne va pas être une mince affaire s'il faut gérer toutes mes cartes avec des signaux de synchro à la noix (surtout la 60in1 et son VBL sans alternances, en fait!).

C'est bien plus compact qu'avant. En gros, il faudra, sur le PCB final, un microcontrôleur de 2cm² et un CPLD de 4cm². Le plus volumineux sera la partie boutons de réglage.
Le microcontrôleur ne va servir qu'à mémoriser les réglages. Si j'intègre la logique pour écrire dans une EEPROM, ça me bouffera toute la place restante dans le CPLD (j'en consomme 33% actuellement).

Note: le signal est méga stable et précis au dixième de pixel!

Bouz a écrit:
Sauf que là, ça marche complètement, tous les cas sont gérés, et tout est intégré dans le CPLD => Ca consomme 36mA!

C'est bon ça !
Tu vas devenir multi support.

L'idée est de s'ouvrir d'autres possibilités. On peut faire pas mal de choses avec un micro-contrôleur, et j'ai fait des trucs assez compliqués en le couplant avec des portes logiques et des logiques programmables. La constante est que ça prend plein de place et ça bouffe plein de courant .
Cette évolution permet d'envisager des réactions au moins aussi rapide que les portes logiques, mais en consommant moins de courant, en beaucoup plus compact, et programmable plus facilement (même si c'est bien compliqué quand même).
Le principal inconvénient que je vois pour le moment, c'est que ça demande de se faire fabriquer des PCB. Difficile de travailler avec un nombre important de pins sur un PCB bricolé avec des fils sur une plaque perforée :-(.
Par contre, je me tâte franchement, une fois que j'aurai vraiment fini par m'en sortir avec cette cochonnerie de synchro, à reprendre le module de hack de Hyper Olympic et à le mettre à la sauce CPLD. Ce serait bien plus compact et je pourrais potentiellement dégager la mémoire dual port et repartir sur le chip SRAM d'origine en exploitant les cycles d'horloge non utilisés du jeu!

Bon, en attendant, j'avance sur la synchro vidéo. Atelier du soir, programmation du générateur de fonctions pour qu'il me sorte quelque chose qui ressemble à s'y méprendre à un signal de synchro 15hKz avec du VBL de 8 lignes pour un total de 256 lignes.
Ca me permettra de faire mes tests sans utiliser de PCB JAMMA. Juste le générateur de fonctions, l'oscillo et mon montage. Ca va être bien plus confortable que ce que je faisais avant.
Voilà la tête de l'appareil:



Et voilà la tête du la courbe à l'oscillo, avec un trigger comme je peux (mon oscillo n'a pas d'entrée trigger, je dois bricoler pour m'attacher à peu près sur les phases de VBL en triggant sur une largeur d'impulsion minimum  >10µs).



Plus qu'à programmer la détection de VBL, le compteur de lignes et le déphasage vertical. Tout ça avec les 66% de place restante sur le CPLD...
Si ça ne rentre pas, il faudar envisager de déléguer le comptage des lignes au microcontrôleur ou de prendre un CPLD plus costaud (ou un FPGA?)

On croise les doigts pour que tu ne consommes pas trop de place.
Vite, le prochain épisode !

Et pour pas beaucoup plus cher (j'en suis à 40%), j'ai un nouveau compteur qui attend 35µs après une impulsion. Si au bout de 35µs on a un niveau haut, alors on est sur une ligne normale. Si on a un niveau bas, alors on est sur un VBL.
Ca donne ça: (en bleu l'original, en rouge ce que je sors)



Et puis du coup, si j'essaie de générer un signal complet, seulement déphase horizontalement, ça donne un truc dégueu dans le genre:



Je pense que si j'injecte ça dans un écran, ça devrait faire l'illusion .
Bon, ceci dit, je vais maintenant intégrer un compteur de lignes pour savoir combien j'en ai en tout, et savoir où je dois placer mes VBL maison pour le décalage vertical. Le résultat devrait être parfaitement régulier la prochaine fois.

Et sinon, hier soir, j'ai cru que j'allais tout envoyer voler parce que la communication entre le microcontrôleur et le CPLD ne marchait plus. Ce soir, j'ai bien lu tous les warnings du compilo et j'ai compris que 2 signaux étaient apparentés à des horloges. J'ai modifié mon "shield" pour diriger 2 de mes 8 plots de tests sur 2 pins d'horloge du CPLD, et sans rien changer d'autre, tout s'est mis à marcher impec!

Bah oui mais si tu écoutes pas ton compilateur...

poup a écrit:Bah oui mais si tu écoutes pas ton compilateur...

Ce qui est perturbant, c'est que le même code marchait la veille! Il y a un côté non déterministe perturbant sur ce machin.
Note aussi que le compilo sort une centaine de lignes d'info/warning en vert sur fond blanc à chaque exécution. Difficile de dire ce qui est un problème et ce qui est de l'info!
Bon, en tout cas, ça a plus de chance de continuer à marcher comme ça.

J'ai rajouté la configuration d'offset vertical et le compteur qui va avec.
Ca commence à sentir bon, cette histoire.
Pour le moment, la config d'offset vertical est en dur dans le CPLD. Ca doit pouvoir se faire configurer par le microcontrôleur sans trop de soucis, comme l'offset horizontal.
On observe 2 pics disgracieux de 20ns qui ne devraient pas être là. Je suis dessus.
Il faut dire que mon signal d'entrée de test n'est pas top. Mais il y a probablement des cartes qui pourraient en sortir des comme ça !



Edit: on voit ici le signal légèrement décalé à droite (donc image à gauche) et le VBL décalé de 12 lignes à droite ( donc image vers le haut).
Tout ça est calculé à 100% par le CPLD, et ça bouffe 60% de sa capacité mémoire, parfait!