[WIP 60%] Normaliser un signal vidéo

poup a écrit:Ha mince, courage. Si tu es bloqué chez toi, ça te laissera du temps pour explorer tout ça.

Je bosse de chez moi, mais ça me laisse un peu de temps quand même

theWave a écrit:Hey Bouz, bricolage propre l'alim, c'est net.

Si tu as reçu 2 puces identiques c'est peu probable que tu aies cramé les 2... Je pencherai plus sur contrefaçon ou signal pas bon.
Tu les as prises sur Ebay ?

Oui, commandé sur eBay. Vu que ça ne court pas les rues et que c'est relativement cher, j'en ai pris 8.
Pour ce qui est du signal, il faudrait peut-être que je teste avec une source composite standard, et pas avec un signal de synchro d'arcade bricolé avec une diode zener.
Il faut que je trouve ça parmi mes vieux machins!
La 1881 se comporte bien avec un signal de synchro nu. J'espère que je ne vais pas devoir générer un signal composite à partir du RGBS du JAMMA juste pour isoler la synchro derrière!
J'ai les puces SONY qu'il faut pour ça, mais ça va complexifier un peu le montage pour rien!

Et je projet est de retour...
Quelques révélations ces derniers jours / heures!

Tout d'abord, la qualité pourrie de l'image sur mon banc de test...
Après avoir fait ma carte JAMMA intermédiaire pour mon twin stick, et la petite carte vidéo qui va avec pour brancher sur une télé en Péritel RVB, je suis retombé sur une image pourrie. A la limite de la folie, après un samedi après-midi complet d'investigation, j'ai fini par trouver que je suis un boulet et que les câbles Péritel croisent les fils sync in et sync out! J'ai changé de pin et l'image était parfaite ! Ca, c'est fait.

Maintenant, restent les ondulations. Si quelqu'un a regardé la mini vidéo, on voit le signal généré rouge faire des petits sauts temporels alors que le signal source bleu ne bouge pas.
Et ça, je viens de comprendre pourquoi! Ce n'est pas lié, comme je le pensais, au temps d'exécution d'une instruction (même si ça joue un peu). C'est au fait que, pour produire des pulsations hsync pendant un VBL, ma boucle principale passe absolument tout son temps à lire un timer, pendant que le gestionnaire d'interruption reproduit avec un déphasage les impulsions d'entrée.
Eh ben cette lecture de timer en boucle nécessite le calcul d'une valeur gérée par un timer hardware, et nécessite de couper les interruptions le temps du calcul (mais ça, on ne le voit pas, on appelle juste une fonction).
Du coup, vu qu'on ne fait que ça en boucle, eh ben on retarde la prise en charge de l'interruption déclenchée par le hsync, de manière différente suivant à quel moment l'interruption est déclenchée.
Ajoutons à cela que pour pouvoir utiliser ces fonctions de gestion du temps sur un microcontrôleur, on active de fait un gestionnaire d'interruptions matérielles sur un timer qui turbine, multipliant les moments où le système d'interruption n'est pas dispo pour s'occuper de nous!

Bon, en résumé, je dois:
- désactiver les fonctions de gestion de temps le noyau des deux microcontrôleurs (celui qui sépare hsync et vsync en produisant les hsync manquants, et celui qui génère un nouveau signal déphasé)
- réécrire mon algo de suivi de synchro en n'utilisant plus de fonctions temporelles, mais des séquences d'instructions en assembleur de durée connue.
Me voilà bien.

En tout cas, ça relance le truc, je suis bien content, il commence à durer un peu, ce projet!
OK, je ne suis pas sûr d'avoir été clair.

Cool bon courage !

Tests effectués une partie non négligeable du week-end...
- remplacement de toutes les temporisation par des timers hardware pour plus de précision
- des interruptions matérielles lancent des timers hardware
- tout le reste du code tourne à temps constant, sans se faire parasiter par des interruptions
- la stabilité du signal est visiblement bien meilleure à l'oscillo
- des décalages de l'ordre de quelques centaines de nanosecondes sont visibles
- je remets tout sur le circuit soudé précédemment
- j'essaie
- je peux régler la position au pixel près horizontalement, ce qui n'était pas le cas avant (c'était plutôt de l'ordre de 4 à 8 pixels)
- ça ondule toujours horizontalement à l'écran, bordel de flûte!

Il me reste 3 solutions:
- lâcher l'affaire (pas encore)
- tenter ça avec un microcontrôleur plus rapide, pas cher, et dual core (un ESP32) => plus probable
- basculer sur FPGA: j'ai de quoi commencer à m'amuser, mais même si ça fonctionne, le coût du machin est rédibitoire pour moi pour un projet qui semble si basique.

Prochaine étape, donc: je gratte autour de l'ESP32, ses timers, ses interruptions. J'avais eu de mauvaises surprises l'année dernière, alors je croise les doigts!

Je suis ne train d'en finir avec ls tests ESP32... Les timers sont plutôt prévis (10 nanosecondes d'erreur sur une onde générée à 15kHz).
Mais dès que je commence à mettre du code là-dedans, ça part en vrille et je me retape des glissements temporels très gênants.
On dirait que le FPGA commence à s'imposer, mais je trouve hallucinant qu'il n'y ait pas une solution plus simple!

Ca va être long, je ne maîtrise pas du tout les outils, ça va être un long apprentissage!

Ha merde c'est con qu'un contrôleur classique puisse pas faire l'affaire. Je trouve ça même étrange.
Le fait de pouvoir régler au pixel et tout rend le truc ultra prometteur. Je serais vraiment content et intéressé si ça marchait au final.

Je t'avoue que j'ai du mal à copprendre aussi ce qui peut se passer.
La mécanique est plutôt simple, à la sortie. Pour la version ESP32, j'ai juste fait ce test: un timer déclenche une interruption qui change la durée du timer. En alternant entre 2 durées, j'obtiens une suite d'impulsions qui ressemblent à un signal de synchro.
Sans même me caler sur un signal existant, et sans perturbation a priori, j'obtiens un signal carrément instable, avec des variations de période de l'ordre de la centaine de nanosecondes.
Sur ATtiny85, c'est beaucoup plus stable, mais avec 2 microcontrôleurs en cascade qui déphasent chacun d'une demi-période, j'accumule les erreurs.
Ici, par contre, le test des timers est plutôt bon.
Le gros souci tient dans la différence entre générer soi-même le signal de synchro ET les signaux RVB, et générer un signal de synchro seul, qui doit suivre des signaux décorellés, et où chaque erreur se voit.
Les timers sont d'une précision redoutable. C'est le code qui gère les interruptions qui prend un oeu trop de temps. D'un autre côté, je me dis que ce temps est constant et que je ne devrais pas avoir d'ondulation...
Tu as presque réussi à mon convaincre qu'il y a encore un truc qui m'échappe. Comme par exemple:
- un vecteur d'interruption actif sur un autre timer
- l'instabilité de l'ADC qui lit les potars, qui provoque des décalages logiciels.

Je vais peut-être gratter encore un peu, qui sait...
Surtout que c'est trop cool de déplacer l'image à l'écran avec les 2 potars :-)

Vérifications faites: RAS au niveau des ADC, pas d'interruptions cachées...
Par contre, j'ai trouvé quelque chose d'intéressant du côté du prescaler du compteur.
Présentation rapide d'un compteur... on va parler de l'un de ceux de l'ATtiny85, et même d'une configuration particulière... quasiment tous les microprocesseurs et microcontrôleurs ont des timers.
Ce timer précis compte à une vitesse de 16MHz. Le compteur fait 8 bits. Donc quand il arrive à 256, il repart à 0.
On peut régler le système pour que le timer nous prévienne quand il atteint une certaine valeur.
Si on veut attendre pendant une durée très précise, on va calculer à combien d'incréments de compteur elle correspond, on configure le compteur pour qu'il nous prévienne à l'arrivée, et c'est parti...
Le souci, c'est que le timer compte vraiment très vite, et que le compteur n'est vraiment pas grand. Il déborde très très vite. A 16MHz, il va arriver à boucler en 16 microsecondes.
Vu que moi, je veux déphaser des signaux vidéo à 15kHz, une ligne fait environ 64 microsecondes. Si je veux m'approcher du cycle suivant en 2 bonds (d'où les 2 microcontrôleurs), je dois pouvoir compter jusqu'à environ 40 microsecondes. Trop long pour le compteur.
Et c'est là qu'intervient le prescaler! Un prescaler, c'est en gros un compteur intermédiaire. On va lui donner une certaine taille, et à chaque fois qu'il atteint cette taille, il ca incrémenter notre compteur. Cela revient à diviser la vitesse du timer par la taille du prescaler pour alimenter le compteur.
Dans notre cas précis, j'ai pris un prescaler de 8. Je peux donc patienter 8x plus longtemps, soit 256 microsecondes, avant que le compteur ne déborde.
Banco.
Et c'est là que j'ai fait une erreur... lors de chaque impulsion reçue, je programme un timer pour être notifié 40 microsecondes plus tard.
Pour ça, je configure ma valeur de référence du compteur en fonction du prescaler et de la vitesse d'horloge (80 incréments en l'occurrence, sisi), je remets le compteur à zéro, et c'est parti.
Sauf que.... je mets le compteur à zéro, mais pas le prescaler... au moment où je lance mon compteur, je peux donc avoir une fraction de temps déjà écoulé. Mon prescaler peut avoir n'importe quelle valeur entre 0 et 7, et cela injecte donc dans mes timings un décalage aléatoire entre 0 et 500 nanosecondes environ.
500 nanosecondes, pour une ligne de 360 pixels (pas tous affichés) qui s'affiche en 60 microsecondes, ça fait loin de 3 pixels de vibration.
Et vu que j'ai fait la même bourde sur les 2 microcontrôleurs, ça me double l'amplitude d'erreur, et hop, 6 pixels de vibration horizontale !

Bon, dans les faits, c'est bien plus joli qu'avant, mais il reste toujours de la vibration dont je ne connais pas l'origine...
Je vais chercher encore un peu...

Désolé que tu n'ai pas trouvé mais merci pour tes précisions sur le fonctionnement des timing.
Je n'y connaissais rien et désormais pas beaucoup plus mais pas rien.
Je pense que tu auras trouvé l'origine, le final sera nickel tellement tu auras cherché partout.

Eh ben je viens de trouver une nouvelle piste, en me câblant directement sur la génération PWM (pulse wave modulation). C'est le système qui permet de générer des ondes carrées nativement, avec un cycle de service configurable.
La particularité de ce truc est qu'il mèle intimement les timers et l'état des pins. Autrement dit, de l'état du timer dépend directement le niveau logique des pins. Je devrais pouvoir faire sauter une partie des aléas observés jusque là, mais il va encore falloir changer de manière de réfléchir.
Il m'aura quand même appris 2-3 trucs, ce projet, en effet!

Petite révélation cette nuit.... Ca rejoint un peu la réflexion ci-dessus, ça tombe bien.
Plutôt que d'essayer de caler mon signal sur le début de chaque ligne, comme je l'ai fait jusqu'à présent avec un succès mitigé, je devrais plutôt essayer de me caler en début de trame, et générer un signal PWM régulier, entièrement piloté par un timer du microcontrôleur.
Si je fais ça, je vais accumuler les erreurs, ligne après ligne, et me retrouver avec un gros décalage en bas de l'écran. L'idée sera alors d'ajuster, en cours de route ou à la fin de la trame (à voir) les valeurs du timer pour se caler sur le timing d'affichage.
Je n'ai pas d'idée précise sur les possibilités d'ajustement et l'impact que ça pourra avoir sur l'affichage, mais intuitivement, je pense que j'aurai le même niveau d'ondulations qu'avant, mais à l'échelle d'un balayage complet d'écran (et non d'une ligne).
Il a falloir tenter ça.

Bon, eh ben je viens de générer un PWM à 15kHz et de l'ajuster pour tout pile 64 microsecondes et un cycle de service de 7.5%. De loin, ça ressemble furieusement à un signal HSYNC.
L'ATTiny85 a un registre de calibration qui permet d'ajuster la fréquence de l'horloge interne. Je comptais m'en servir pour asservir le PWM en fréquence, basé sur la fréquence du signal source.
Hélas:
- un incrément du registre OSCAL a un impact trop important sur la période du signal généré, de l'ordre de la microseconde. C'est trop.
- Le signal PWM n'est curieusement pas franchement stable, ça bouge dans tous les sens!
=> il faut passer à autre chose, j'ai encore des idées :-)

Bon, ben ça y est, plus besoin d'attendre. Comme quoi c'était pas complètement idiot, comme concept:
https://www.smallcab.net/image-positioning-card-screen-p-2047.html?osCsid=dl6vov5fnb83l5anuq0qlrso52
Si ça ne coûtait pas un bras, j'en achèterais un pour voir comment c'est fichu

Bon, mon Pang tire franchement à droite et il me manque un bout d'image. C'est l'occasion de voir si j'ai fait des progrès en électronique depuis l'année dernière!
Je relance donc le projet, youpi!

J'ai passé une petite heure aujourd'hui à bricoler des équations logiques pour programmer une série de GAL (logiques programmables).
Le but est de mettre en place un super eur et de synthétiser un signal de synchro super précis.
Avec tout ça cadencé à 20MHz, ça me donnerait une précision de l'ordre du tiers de pixel, donc mieux que les 4 pixels que j'obtenais avec un microcontrôleur.
Je me suis lancé dans la programmation d'un compteur 8 bits, avant de m'apercevoir que la vieille techno sur laquelle reposent les GAL ne permet pas assez d'opérations pour plus de 5 bits!
L'architecture reposera donc sur le matériel suivant:
- un microcontrôleur, probablement 8 bits, probablement ATMEL, probablement un Arduino pour commencer et autre chose par la suite
- 3 GAL ATF16V8 programmées comme des compteurs comparateurs en cascade de 4 bits avec retenue.
- 1 GAL ATF22V10 qui va récupérer les infos des 3 autres et celles du microcontrôleur pour synthétiser le signal de synchro
- 2 registres à décalage 74HC595 pour configurer les compteurs.

La logique sera de chaîner les 3 compteurs pour avoir de quoi compter le temps entre 2 lignes.
On donnera à ces compteurs une valeur de référence, et ils lèveront la main quand ils l'auront tous atteinte.
On commence à compter quand on détecte une synchro, et on en produit une quand le compteur atteint la valeur demandée.
Il suffit alors de faire varier les valeurs pour induire un décalage plus ou moins important dans le temps (et donc de gauche à droite à l'écran).
Les registres à décalage servent à donner les valeurs de référence aux compteurs. Le microcontrôleur ne peut pas le faire tout seul parce qu'il n'a pas assez de pattes.
Comme toujours, cette fois, j'y crois .

Back in the business !
Vivement les résultats

Eh ben voilà déjà la simulation pour l'un des compteurs/comparateurs.
Spoiler, j'ai le cerveau qui fume.
J'ai un doute sur la manière dont la retenue va passer d'un GAL à l'autre, vu que tout est synchrone. Il va falloir que je câble ça, que je programme 2 GAL et que j'essaie.

Respect pour ta ténacité !
Mug

Mug Superstar a écrit:Respect pour ta ténacité !
Mug

Merci ;-)

Bon, ça ne paie pas de mine, mais voilà déjà un début de plaque de développement custom avec un compteur/comparateur à 4 bits dessus, qui se comporte comme dans la simulation.
Prochaine étape: en mettre 2 et régler cette question de propagation de la retenue. Si je ne peux rien faire avec le GAL, j'utiliserai une porte logique quelconque pour ralentir la retenue, et je la lancerai un cycle plus tôt (!).

C'est quoi que tu appelles la retenue ?
Ca se voit où sur les courbes que tu as mis ?

Sur les courbes, ça s'appelle "Carry". C'est le bit qui passe à 1 quand le compteur déborde et revient à 0. C'est comme une retenue quand tu fais une addition. Ca veut dire qu'il faut reporter 1 sur le digit suivant.
En l'occurrence, vu que je vais chaîner 3 compteurs pour avoir 3 chiffres, ça veut dire qu'il faut incrémenter le compteur suivant.
La subtilité étant que le compte est synchrone sur les 3 compteurs, déclenché par l'horloge à 20MHz. Il faut donc que la retenue soit prise en compte par le compteur n+1 sur le cycle où elle a été produite par le compteur n.
Je pense donc la générer au cycle précédent et lui mettre un petit retard pour qu'elle soit présente au cycle attendu.

Et on dirait bien que la retenue est gérée correctement! Je l'ai envoyée au moment où je passe à la valeur 0xF. Et quand l'horloge passe par là, la bascule à 0 s'opère, et la retenue disparait après que sa valeur ait été prise en compte par le GAL suivant!
J'ai aussi pu tester la logique de remise à 0 des compteurs. Ca, c'est bon.
Et j'ai aussi pu tester la logique de détection d'égalité avec le compteur de référence. C'est bon aussi.

Je me retrouve donc avec 2 GAL en série, tout ça pour compter jusqu'à 256, qu'on peut remettre à 0, et qui préviennent quand ils ont atteint une valeur attendue.
On va maintenant compter jusqu'à 4096 (ce qui est 2 fois trop) e ajoutant un nouveau GAL avec le même code.

Il va ensuite falloir ajouter un 4ème GAL qui va gérer la logique de génération de l'impulsion de VSync et de VBL.

Après ça, il faudra mettre des registres à décalage dans la boucle, les piloter avec un microcontrôleur, et on aura toute la chaîne pour générer ce signal de synchro déphasé!

Ca va être bien casse bonbons, mais je crois que j'ai évacué toutes les difficultés techniques et je le sens bien, ce coup-là!

Edit: testé avec une horloge à 20MHz, et ça fonctionne.

Je ne vois pas, ignare que je suis en électronique, ce que cette validation de la retenue va te permettre pour le réglage.
C'est un test qui te permet de voir que tu ne changes pas le signal source ?

Ca me permet de voir que je peux chaîner 3 GAL en mode compteur, et compter à une vitesse de 20MHz (potentiellement 40, j'ai pas essayé).
Ces compteurs permettent de temporiser après la détection d'un signal de synchro, afin de le reproduire plus tard.
L'intérêt de le faire à grande vitesse permet de se positionner précisément alors même que l'oscillateur n'est pas synchrone avec le signal vidéo. En gros, il ne se passera pas plus de 50ns entre le déclenchement du signal et sa détection par le système. sachant qu'une ligne met 64µs à se dessiner pour environ 360 points, on est de l'ordre du tiers de pixel d'erreur.
C'est beaucoup mieux que ce que je pouvais faire avec des interruptions et des timers sur un microcontrôleur, à la même fréquence, pour le coup.
Le microncontrôleur sera toujours là pour piloter le GAL responsable de la génération de la synchro, mais il n'interviendra qu'une fois par ligne pour faire de la configuration VSYNC/HSYNC (et donc gérer le décalage vertical), et pour envoyer la consigne de décalage horizontal sur les GAL. Il sort de l'équation du "temps réel" pour mon plus grand soulagement.

Par contre, je m'aperçois que j'aurai besoin de 3 GAL pour compter, d'un autre pour piloter le signal de synchro, et de 2 autres pour générer la temporisation de 8µs d'un signal HSync. Ca va faire du monde sur la carte!
J'ai regardé les circuits intégrés qui gèrent du comptage en 12 bits (il me faut 10 bits pour une ligne), et ça coûte plus cher que mes 3 GAL, même si c'est plus satisfaisant. Ca doit consommer moins, par contre!
En tout cas, je continue comme ça, ça permettra de valider la solution avant d'éventuellement l'améliorer.
Idéalement, il me faudrait programmer un CPLD. J'ai tenté l'aventure avec un FPGA et le kit de programmation JTAG pas cher me plantait mon Windows. Par contre, clairement, pour une solution élégante, on doit pouvoir faire ça avec un CPLD, un microcontrôleur et 2 potars. Ce serait bien plus classe.

Bouz a écrit:
Idéalement, il me faudrait programmer un CPLD. J'ai tenté l'aventure avec un FPGA et le kit de programmation JTAG pas cher me plantait mon Windows. Par contre, clairement, pour une solution élégante, on doit pouvoir faire ça avec un CPLD, un microcontrôleur et 2 potars. Ce serait bien plus classe.

Sûr que ça ferait très pro et rien consommer.

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!