Suite de la conception précédente :
- Avant de tenter de résoudre le problème du trou dans H−Sync, j'ai voulu trouver une solution à la stabilité de la synchro sortante afin d'obtenir une image la plus nette possible, et ce même si le circuit à base de PLL propose une qualité d'image tout à fait correcte.
Mon côté perfectionniste doublé de curiosité m'emmena faire un tour du côté du monde merveilleux de l'Arduino et de l'ESP32. Malheureusement les quelques essais que j'ai pu réaliser n'ont pas donnés les résultats escomptés, et étaient parfois pire qu'avec mon précédent circuit.
- Quelques temps ont passés avant que je sois poussé à m'intéresser au Raspberry Pi Pico, et plus particulièrement la carte de WaveShare RP2040-ZERO.
J'étais passé jusqu'alors complètement à côté de cette puce. Certes j'avais eu vent de son existence et de la « mode » entourant sa sortie, beaucoup de monde s'y mettait, sauf moi. Comme souvent j'ai plusieurs trains de retard sur les technos, que je sais laisser passer tranquillement avant d'en avoir réellement besoin. Idem pour tout ce qui est LLM + prompt d'intelligence simulée, pas besoin. Vous lisez un type qui lit encore sa musique classée dans des dossiers, en local sur son appareil. Pas de méta−données, rien. Pas besoin.
- Bref. J'ai donc découvert le RP2040 et entrevu une potentielle solution pour mon problème, en comprenant ce qu'il en était des States Machines, ces machines intégrées à la puce à qui on s'adresse en assembleur et qui roulent au rythme des cycles d'horloges, indépendamment du code adressé au processeur.
Vraiment très intéressant, quand on sait la vitesse à laquelle c'est capable de monter sans sourciller.
C'est bien simple, j'ai pu coder des exemples de génération de signaux de manière classique, à travers le processeur et demander la même chose aux States Machines et le résultat à l'oscilloscope était sans équivoque tellement meilleurs avec ces dernières.
Pour plus d'info, il y a cette vidéo qui explique très bien ce qu'il en est des Machines à état et cette page aussi..
Je comprend maintenant l'engouement pour ce Raspberry Pi Pico !
Un troisième circuit d'essais :
- J'ai donc envisagé ce schéma, avec une nouvelle fois la structure basée sur le circuit séparateur de synchro LM1881 en entrée, les portes logiques 74LS132 en sortie, mais utilisant le RPi Zero pour le traitement du signal.
- Particularité ici très importante, le RP2040 fonctionnant en logique 0−3,3V, il faut impérativement adapter les signaux qu'on lui applique, ce que je fais ici à l'aide d'un circuit basé sur le transistor MOSFET BS170 montés ainsi en adaptateur de niveau logique.
Je dispose maintenant d'un analyseur logique, ce qui est bien pratique pour montrer facilement les signaux. J'en profite donc pour donner un relevé des signaux d'entrée/sortie du LM1881, agrémentés de diverses mesures intéressantes…
- Après plusieurs itérations, j'ai pu écrire ce programme µ−python pour le RP2040-Zero (dispo aussi en annexe à ce billet), pour déphaser les signaux.
Il utilise quatre State Machines pour déphaser les signaux. Les potentiomètres et le bouton sont gérés par le CPU. Lorsqu'on appuie sur le bouton, on passe en mode lecture de la valeur des pots, ce qui permet donc de décaler l'image en les réglants, puis de mémoriser ces réglages en rappuyant sur le bouton.
- Voyons ce que donnent les signaux :
− En blanc, le C−Sync d'entrée,
− En marron, le V−Sync de sortie du LM1881, qui entre dans le RP2040-Zero en GP5,
− En rouge, le C−Sync de sortie du LM1881, qui entre dans le RP2040-Zero en GP14,
− En orange, le V−Sync déphasé en sortie GP6 du RP2040-Zero, qui entre dans le 74LS132,
− En jaune, le C−Sync déphasé en sortie GP15 du RP2040-Zero, qui entre dans le 74LS132,
− En vert, la sortie du 74LS132, avec V−Sync + C−Sync réassemblés.
