まこと　の　ブログ

Suite de la conception précédente :

• Pour gagner énormément de temps sur ce sujet, étant donné que je partais de zero, je me suis fait aider par un professeur particulier qui s'appelle Claude, et parfois Gemini aussi.
  

C'est formidable d'avoir « quelqu'un » qui t'explique les choses, et traduit des exemples de code, ce langage obscure, en Français !

J'ai ainsi pu expérimenter ces prompts et me rendre compte du danger qu'ils représentent en terme de capacités cognitives qu'on pourrait vite perdre. Face à un tel outil, le cerveau humain est particulièrement faible, et vite tenté de déléguer trop le travail, au risque de perdre en capacité de réflexions. Sans compter le temps perdu dans des culs de sacs techniques, qui n'auraient pas dû se présenter…

− Dés que je demandais quelques chose du genre « je voudrais faire ça, dit moi comment faire », ça tournait mal. Beaucoup d'hallucinations, de code testés, de ratés, et parfois de code fonctionnel, mais qui décidément ne faisaient pas exactement ce que je voulais. Ça restait pourtant très séduisant pour cette feignasse de cerveau, malgré que je devenais incapable d'ajuster ce code à mon besoin, tout étant allé trop vite, pas eu le temps d'assimiler, ni de comprendre ce qui se présente. Pris dans ces boucles d'incapacités cognitive, obligé de réitérer sans cesse pour en sortir, mélasse dans la tête… wé, pas ouf.
− Par contre dés que j'exposais une directive claire « je veux faire ça, de telle manière, avec ces paramètres, écrit le−moi », ça se passait tout de suite mieux, et « on » me gratifiait au passage d'un « bravo, vous avez raison, ça fonctionnera bien mieux ainsi ». « Oui, je sais… *soupir* ».

Cantonné à un rôle de traducteur où de prof qui m'explique la technique, c'est très bien et moins coûteux pour l'humain que la méthode autodidacte classique. Évoquer des solutions envisageables passe aussi, mais il vaut mieux ne pas en demander plus, et faire le travail d'ingénierie soit même. Pour éviter de finir abruti et de se perdre…

• Bref, à défaut il faudrait vraiment éduquer à employer correctement cette techno, où quelle disparaisse à jamais, ça ne sera pas plus mal.
  
  

Un quatrième circuit d'essais :

Allez-allez là, l'actualité ! Trêve de blabla, passons au concret !

• Suite aux déconvenues précédentes, et ce qu'elles m'ont permis d'apprendre, j'ai tenté un schéma en − presque − tout numérique et de me passer des circuits vidéo spécialisés :
  

− Nous avons donc une adaptation de signaux en entrée, car l'IGS−PGM délivre un C−Sync hors normes à 5V d'amplitude.
− Le RP2040 qui va traiter intégralement le signal d'entrée, afin de sortir un nouveau C−Sync déphasable, par action sur le switch et les potentiomètres.
− Une porte ET logique 74HC08 pour réassembler C−Sync en sortie.
− Et un switch double pour inhiber le circuit, pour le cas où on ne voudrait pas traiter le signal.

Le programme µPython est disponible ici, et en annexe du billet.^[1]
J'ai aussi fait commenter le code Python afin qu'il soit accessible aux grands débutants.

• Description rapide du principe de fonctionnement :

1. Le signal C−Sync entre sur GP0.
   
2. Il est traité par sm4 : StateMachine 0 hsync_flywheel afin « d'extraire » le signal H−Sync. En fait créer un signal respectant la norme vidéo avec une impulsions de 5 µs, calée sur les fronts de C−Sync, et continuant sur ce rythme lorsque les trous formés par V−Sync apparaissent. Le signal est disponible sur GP1 pour débug ou réutilisation opportune.
   
3. C−Sync in est utilisé par sm5 : StateMachine 1 vsync_pio pour « extraire » V−Sync. Donc créer une impulsion longue de 512 µs, calée sur les fronts de C−Sync. Le signal est disponible sur GP2.
   
4. Ensuite, l'action combinée de sm0 : StateMachine 4 front_montant Horizontal et sm1 : StateMachine 5 front_descendant Horizontal vont permettre, lorsqu'on appuie sur le bouton, de lire la valeur du potentiomètre horizontal et de déphaser le signal H−Sync. Ce signal est disponible sur GP3.
   
5. De même avec sm2 : StateMachine 6 front_montant Vertical et sm3 : StateMachine 7 front_descendant Vertical pour déphaser le signal V−Sync. Signal dispo sur GP4.
   
6. Et enfin, sm6 : StateMachine 2 and_gate effectue une opération ET logique entre les deux signaux déphasés afin de reconstruire notre C−Sync déphasé en sortie. (finalement remplacé par une porte logique physique plus fiable)
   

• Voici quelques chronogrammes (avec un déphasage notable en vertical et horizontal) pour voir ce qu'il en est à chaque étapes clef du circuit :

• Et une petite vidéo démonstrative :

• Et de deux !

• Conclusion de l'expérimentation,

On a donc un programme « full states machines » indépendant du CPU du microcontrôleur, ce qui permet une cadence de génération des signaux très précises.
Le CPU n'est là que pour gérer les boutons et la lecture des potentiomètres.

Tout fonctionne bien et sans gigue, pour ce programme tout à fait adapté à l'IGS−PGM, c'est je pense le montage qui constituera la carte fille que je vais donc intégrer à mon péritel multiple !

À moins que… Hum, j'ai testé le montage sur quelques consoles, Sega ou Nintendo, et ça ne fonctionne pas du tout…
J'ai regardé un peu les signaux émis par ces machines, et j'ai eu quelques surprises qui m'ont d'ailleur fait retarder la publication de ce présent article, et dont je parlerais peut-être une prochaine fois.

À suivre…?

Ressources :
https://rocelec.widen.net/view/pdf/en7p9sshgt/GENNS00351-1.pdf
https://zestedesavoir.com/tutoriels/2256/de-la-logique-aux-processeurs/des-maths-a-lelectronique/
https://www.ti.com/lit/ds/symlink/sn74hc08.pdf
https://www.eurobot.org/wiki/fr/informatics/lire_les_codeurs
https://docs.micropython.org/en/latest/library/rp2.StateMachine.html
https://docs.micropython.org/en/latest/library/rp2.html
https://www.onetransistor.eu/2021/02/rpi-pico-pio-state-machine-square-wave.html
https://tutoduino.fr/pio-rp2040/
https://www.developpez.net/forums/d2149816/general-developpement/programmation-systeme/embarque/raspberry-pi/rpi-pico-utilisation-pio/
https://www.raspberrypi.com/news/what-is-pio/
https://gregchadwick.co.uk/blog/playing-with-the-pico-pt4/
https://pip-assets.raspberrypi.com/categories/610-raspberry-pi-pico/documents/RP-008355-DS-1-raspberry-pi-pico-python-sdk.pdf?disposition=inline
https://pip-assets.raspberrypi.com/categories/814-rp2040/documents/RP-008371-DS-1-rp2040-datasheet.pdf?disposition=inline
https://scanlines.xyz/t/tutorials-for-generating-video-sync-signals-with-arduino/104

Suite de la conception précédente :

Le premier circuit ayant donc montré ses limites et défauts, nous allons ici tenter de les corriger.

Un deuxième circuit d'essais :

• À force d'expérimentations, j'ai fini par aboutir à ce schéma :
  

Ce circuit fonctionne relativement bien, mais avant de tirer les conclusions (oui je ne suis pas un politique ou un journaleux qui tire les conséquences, faut arrêter avec ça !), regardons comment il fonctionne, car encore une fois, ce sera salutaire pour la suite à donner.

• Nous avons donc à nouveau l'étage de séparation de synchro basé sur le circuit intégré LM1881, nécessaire pour récupérer le signal V−Sync.
  

Cet étage est cette fois connecté à des PLL (boucle à verrouillage de phase) CD4046, le type de montage à système bouclé dont la théorie me donnait des sueurs froides à l'école… Mais bon c'est plus facile à expérimenter… un peu.

• La PLL est ici employée afin de générer un signal carré d'une fréquence égale au signal d'entrée. Une fois la fréquence « accrochée » par le VCO (oscillateur contrôlé en tension), led témoin allumée par l'entremise du potentiomètre, ce système bouclé va nous permettre de déphaser le signal carré en continuant de jouer du potentiomètre. La limite étant le décrochage du VCO au delà d'une certaine plage de fonctionnement où l'on perd alors la fréquence.
  

Les composants R1, R2 et C1 sont donc calculés et vérifiés expérimentalement pour offrir la plage de fonctionnement la plus large possible sans décrocher de la fréquence d'entrée.
Pour H−Sync et ses 15,625 kHz, R1 = 100 kΩ, R2 = 100 kΩ, C1 = 1 nF.
Pour V−Sync et ses 59 Hz, R1 = 8,2 kΩ, R2 = 18 kΩ, C1 = 1 µF.

• Voici une démo vidéo de la phase d'accrochage de la PLL, avec le signal zoomé sur V−Sync, on regarde la sortie 3 du CD4046.
  

On prend soin d'observer attentivement la valeur de fréquence affichée en bleu sur l'oscilloscope, ainsi que la réaction de la led.

• La sortie de chaque PLL est ensuite envoyé à un monostable, pour, comme nous l'avons étudié précédemment, générer une impulsion de largeur fixée grâce au potentiomètre associé.
  

Voyons cela avec des oscillogrammes :

• Ici nous voyons le déphasage obtenu pour H−Sync. Le signal C−Sync (en jaune), la sortie 3 de la PLL (en bleu), et la sortie Q7 du monostable (en vert) qui déclenche son impulsion sur le front montant du signal de sortie du CD4046.
  

• Et de la même manière, nous voyons le déphasage obtenu pour V−Sync. Le signal V−Sync (en jaune), la sortie 3 de la PLL (en bleu), et la sortie Q9 du monostable (en vert).