Auteur Sujet: [WIP] - Ampli Video - Console vers jamma  (Lu 103136 fois)

Hors ligne ckf92

  • Accro
  • *
  • Messages: 211
    • Voir le profil
[WIP] - Ampli Video - Console vers jamma
« Réponse #208 le: Vendredi 06 Novembre 2009, 09:32:38 am »
alle zmoi je UP fort pour ce projet! tu as tous mes encouragements!

Hors ligne gc339

  • Beta Testeur
  • *
  • Messages: 2193
    • Voir le profil
[WIP] - Ampli Video - Console vers jamma
« Réponse #209 le: Samedi 07 Novembre 2009, 00:41:08 am »
Il apparait sur un des schémas que tu donné dans un de tes posts. J'ai cru que tu le connaissais personnellement...

J'ai procédé préalablement à une recherche sur le net de tout ce qui concernait les PIC et la vidéo et je suis tombé sur la description de Bruno Gavand qui avait beaucoup de points commun avec ce projet.



Ce qu'il restait à faire :
 
  • Déterminer pourquoi le chronométrage est toujours hors fenêtre en réel alors que tout va bien avec le simulateur intégré.
  • Gérer le chien de garde.
  • Lire les cavaliers de configuration et appliquer les paramètres pour chaque fréquence ligne à filtrer.
  • Oblitérer une impulsion ligne sur deux dans le cas de la pseudo conversion 31 kHz vers 15 kHz.

Le chronométrage était mauvais car j'avais mal positionné le compteur prescaler, il prédivisait 2 fois de trop.
Ce compteur prescaler est inséré entre le signal d'horloge général et le Timer 0, il permet de prédiviser l'horloge appliquée au Timer 0 dans un rapport que l'on peut programmer entre 21 à 28.
En tout cas cela m'a permis de mieux connaître le délai de prise en compte de l'interruption, le datasheet n'étant pas très précis sur le sujet.
  • Le chronométrage théorique devant être de 160 (64µs ÷ 0,4µs), 0,4µs étant la période de l'horloge appliquée au Timer0.[/i] )
  • Le délai entre deux interruptions est effectivement chronométré à 158.
La différence entre les deux correspond au temps de prise en compte de l'interruption soit 2 × 0,4 µs = 0,8 µs. Ce temps de 0,8 µs correspond à 4 cycles d'instruction, un cycle durant 0,2 µs pour ce PIC cadencé à 20 Mhz.

Après avoir solutionné ce premier problème un autre s'est manifesté.
Si l'on détaille de plus près les impulsions de synchronisation des deux standards à trames entrelacées :

            

On peut s'apercevoir que l'impulsion de synchronisation trame :
  • Dans le cas du 625 lignes européen :
    • Pour la 1ère trame :
      • Débute en même temps que la 1ère ligne.
      • Se termine au milieu d'une ligne, la 3ème.
    • Pour la 2ème trame :
      • Débute au milieu de la 313ème ligne.
      • Se termine en même temps que la dernière ligne de l'image, la 625ème.
    Une impulsion trame durant en fait 2,5 lignes soit 160 µs.
  • Dans le cas du 525 lignes américain :
    • Pour la 1ère trame :
      • Débute en même temps que la 4ème ligne.
      • Se termine en même temps que la 6ème ligne.
    • Pour la 2ème trame :
      • Débute au milieu de la 266ème ligne.
      • Se termine au milieu de la 269ème ligne.
    Une impulsion trame durant 3 lignes dans ce standard. Ce système utilise une numérotation des lignes différentes, la ligne 1 ne correspond pas au début d'un top de synchro verticale mais au début de la période de suppression trame pendant laquelle les tops d'égalisation sont insérés.
Le début ou la fin de ces impulsions de synchro trame étant toujours synchronisé sur le front descendant des impulsions de synchro ligne ou des impulsions d'égalisation.
Ce début ou cette fin d'impulsion trame en plein milieu d'une ligne est la signature des trames entrelacées, les trames progressives debutent ou finissent toujours en parfait synchronisme avec les impulsions ligne.

Le logiciel en cours d'écriture se synchronisant sur les impulsions de synchro ligne, la présence ou l'absence du signal de synchro trame n'était testée qu'à chaque interruption.
  • Ceci ne pose pas problème quand il y a des impulsions d'égalisation dans le signal de synchro ligne, car il y a alors une interruption en milieu de ligne pour venir lire l'état de la synchro trame.
  • Ce n'est plus le cas quand ces impulsions d'égalisation ne sont pas présentes dans le signal de synchro ligne comme par example sur la DreamCast.
    • La durée lue des impulsions de synchro trame sera écourtée de la durée d'une demi-ligne pour le 625 lignes européen
    • La durée lue de l'impulsion de synchro de la 2èmetrame du 525 lignes US sera amputée de la durée d'une ligne
    Car il n'y a pas d'interruption générée en milieu de ligne pour pouvoir venir lire l'état de cette synchro trame.

Il faut donc trouver une autre solution ...
Comme utiliser l'interruption sur changement d'état (interrupt-on-change) de la broche GP3 sur laquelle est appliqué le signal de synchro trame.
  • Il vaut mieux différencier temporellement l'interruption due à la synchro ligne de celle due au changement d'état de la synchro trame
    • Les changements d'état de la synchro trame étant synchrones avec le front descendant du top de synchro ligne, l'interruption due à la synchro ligne devra plutôt être activé par son front montant.
    • L'interruption due à la synchro trame précédera donc celle due à la synchro ligne de quelques µs, théoriquement 4,7 µs en 525 ou 625 lignes, 3,8 µs dans le cas du VGA à 31 kHz.
      Le traitement de l'interruption due au changement d'état de la synchro trame devra donc être optimisé au maximum car elle devra être exécutée en moins de 3,8 µs ÷ 0,2 µs soit moins 19 cycles d'instruction, ce qui ne laissera que 15 cycles maximum pour ce traitement compte tenu du délai de prise en compte de cette interruption !
  • Le fait que le circuit soit verrouillé ou pas autorisera ou inhibera l'interruption due au changement d'état de la synchro trame en plus du traitement du by-pass.
  • L'adresse de traitement des deux interruptions étant commune il va falloir d'entrée les différencier pour traiter en premier celle due au changement d'état de la synchro trame car le temps est compté.

Problème aussitôt identifié, solution aussitôt imaginée, programme aussitôt modifié et testé avec le simulateur intégré au MPLAB IDE, qui soit dit en passant disfonctionne ostensiblement sur le traitement de l'interruption "interrupt-on-change".
L'expérimentation réelle montre que le signal trame n'est plus inséré tronqué d'une demi-ligne avec le mode 15 kHz de la DreamCast, reste à tester comment se comporte cette modification avec les autres fréquences ligne, surtout avec le 31 kHz et ses 3,8 µs de top ligne...



Ce qu'il reste à faire :
 
  • Gérer le chien de garde.
  • Lire les cavaliers de configuration et appliquer les paramètres pour chaque fréquence ligne à filtrer.
  • Oblitérer une impulsion ligne sur deux dans le cas de la pseudo conversion 31 kHz vers 15 kHz.

A suivre ...




« Modifié: Samedi 07 Novembre 2009, 12:15:28 pm par gc339 »
Le repos, c'est fait pour les jeunes. Ils ont toute la vie devant eux. J. Gabin/M. Audiard



Hors ligne f4brice

  • ✌(◕‿◕)✌ Donateur 2018
  • Arcade Kingmaster
  • *
  • Messages: 4052
  • « Matériel inconnu ? Touche à ton cul ! »
    • Voir le profil
[WIP] - Ampli Video - Console vers jamma
« Réponse #210 le: Samedi 07 Novembre 2009, 09:23:41 am »
Bonjour.

La réalisation d'un logiciel sur micro-contrôleur n'est pas chose facile, d'autant plus quand (je parle de mon expérience, pas du projet ici) :
  • on a pas encore l'expérience avec le micro-contrôleur choisi
  • la doc est fausse
  • le simulateur est foireux
  • l'électronique autour du µC est buggée
  • on utilise des protocoles propriétaires (Kro$oft) mal documentés et incomplets
  • on te demande d'émuler les bugs de la version précédente (!!!)

La solution ?
Pour un particulier : le courage et la persévérance.
En milieu professionnel : le développement piloté par les tests : lien Wiki et la méthodologie eXtrem-Programming.

Hors ligne ckf92

  • Accro
  • *
  • Messages: 211
    • Voir le profil
[WIP] - Ampli Video - Console vers jamma
« Réponse #211 le: Lundi 30 Novembre 2009, 11:07:22 am »
Pas de news?

Hors ligne xam

  • Pilier
  • *
  • Messages: 716
    • Voir le profil
[WIP] - Ampli Video - Console vers jamma
« Réponse #212 le: Samedi 12 Décembre 2009, 19:40:58 pm »
z etes quand meme des grands malades serieux ...  ^-^

Hors ligne liodel

  • Hardcore Gamer
  • *
  • Messages: 1958
    • Voir le profil
[WIP] - Ampli Video - Console vers jamma
« Réponse #213 le: Lundi 14 Décembre 2009, 20:20:21 pm »
Projet de remplacement du µC Cypress.

Mon choix s'est porté sur le µC 12F635 de Microchip (...)
  • Dans un premier temps, pour la mise au point, je vais utiliser un boîtier horloge extérieur à 20 MHz. Si j'arrive à maîtriser les timings avec l'horloge interne à 8 MHz, je réutiliserais cette broche pour par exemple allumer une LED.
(...)
  • Les broches restantes GP0 et GP1 seront utilisées pour les cavaliers de configuration, une combinaison binaire de l'absence/présence de ces cavaliers sera nécessaire pour les 4 configurations possibles, par exemple :
    • absent, absent : 15 kHz.
    • absent, présent : 24 kHz.
    • présent, absent : 31 kHz.
    • présent, présent : 31 kHz --> 15 kHz.
  • Cette organisation des E/S n'est pas figée, l'affectation des signaux aux différentes broches pourra être modifiée pour mieux optimiser les temps de réponse du programme.

Bonsoir,

Afin d'avancer sur l'évolution du routage, j'aurais voulu savoir si :
- je partais sur ce boitier horloge qui me prends une place monstre  :D ou si un quartz plus petit serait installable ?
- l'idée des cavaliers est maintenue comme évoqué précedemment (cad un jumper 2x2) ?
- je place une led et sa résistance quelque part ?[/list][/list]

"Chuck Norris a déjà compté jusqu'à l'infini. Deux fois." - "Chuck Norris ne se mouille pas, c'est l'eau qui se Chuck Norris." - © Chuck Norris facts - fr

Hors ligne pitufo

  • Toufaises !
  • Game Cheater
  • *
  • Messages: 2413
  • ...
    • Voir le profil
[WIP] - Ampli Video - Console vers jamma
« Réponse #214 le: Mardi 15 Décembre 2009, 17:43:45 pm »
up

Hors ligne liodel

  • Hardcore Gamer
  • *
  • Messages: 1958
    • Voir le profil
[WIP] - Ampli Video - Console vers jamma
« Réponse #215 le: Mardi 15 Décembre 2009, 17:51:02 pm »
up
=:)) =:))
J'aurais pensé "foutaises" plutôt  :D

"Chuck Norris a déjà compté jusqu'à l'infini. Deux fois." - "Chuck Norris ne se mouille pas, c'est l'eau qui se Chuck Norris." - © Chuck Norris facts - fr

Hors ligne gc339

  • Beta Testeur
  • *
  • Messages: 2193
    • Voir le profil
[WIP] - Ampli Video - Console vers jamma
« Réponse #216 le: Mercredi 16 Décembre 2009, 13:32:34 pm »
    Afin d'avancer sur l'évolution du routage, j'aurais voulu savoir si :
    - je partais sur ce boitier horloge qui me prends une place monstre  :D ou si un quartz plus petit serait installable ?
    - l'idée des cavaliers est maintenue comme évoqué précedemment (cad un jumper 2x2) ?
    - je place une led et sa résistance quelque part ?[/list][/list]

    Désolé pour cette réponse tardive, la chose qui me manque le plus en cette période de fin d'année, c'est du TEMPS ! C'est pourquoi la finition du logiciel PIC a pris un peu de retard ...
    • Le boîtier horloge que j'ai utilisé est un LF X356H 20MHz référence 9713018 chez Farnell, c'était un des moins cher. Peut-être il y a-t-il la possibilité d'en trouver un autre moins encombrant. En tout cas il n'est pas possible de remplacer ce boîtier oscillateur par un simple quartz car pour ce faire il faudrait monopoliser une deuxième broche du PIC, ce qui est irréalisable vu le peu de broches disponibles en E/S et la configuration choisie.
    • L'idée des 2 cavaliers pour choisir la fréquence ligne à filtrer est conservée, cependant il n'y plus de broche de disponible pour activer une LED quand le PIC détecte la fréquence ligne filtrée.
      Il faudra donc multiplexer les deux broches restantes GP0(7) et GP1(6) pour réaliser cette double fonctionnalité sans accroître la complexité du schéma.
      J'ai déjà rapidement réfléchi au problème, la solution trouvée n'ajouterai au schéma que deux diodes genre BAT42 en plus de la LED avec sa résistance.
      Je poste le schéma de cet ajout dés que je l'ai expérimenté/validé.
    Le repos, c'est fait pour les jeunes. Ils ont toute la vie devant eux. J. Gabin/M. Audiard



    Hors ligne liodel

    • Hardcore Gamer
    • *
    • Messages: 1958
      • Voir le profil
    [WIP] - Ampli Video - Console vers jamma
    « Réponse #217 le: Mercredi 16 Décembre 2009, 13:57:05 pm »
    Bonjour,

    Désolé pour cette réponse tardive, la chose qui me manque le plus en cette période de fin d'année, c'est du TEMPS ! C'est pourquoi la finition du logiciel PIC a pris un peu de retard ...

    Ah mais y'a pas de souci, tout vient a point...

    "Chuck Norris a déjà compté jusqu'à l'infini. Deux fois." - "Chuck Norris ne se mouille pas, c'est l'eau qui se Chuck Norris." - © Chuck Norris facts - fr

    Hors ligne setsuan

    • Pensionnaire
    • *
    • Messages: 40
      • Voir le profil
    [WIP] - Ampli Video - Console vers jamma
    « Réponse #218 le: Mercredi 23 Décembre 2009, 15:20:36 pm »
    Bonjour à tous et merci aux 2 piliers du topic qui font avancer les choses. Ayant un projet DC2Jamma dans les tuyaux, je viens avec une question qui titille..  :D

    Au début du projet, le but était "simple" : Intégrer extracteur de synchro + ampli couleurs puis plusieurs fonctionnalités annexes sont venues s'y greffer pour le bonheur de nombreux futurs utilisateurs.

    Une fois, le projet global terminé, pensez-vous tirer plusieurs modèles en tenant compte de 2 ou 3 types de projets ??

    Par exemple :
    • Maxi PCB avec toutes les fonctionnalités possibles. -> $$$$
    • PCB du prolétaire avec de quoi booster un signal VGA et RGB seulement.
    • PCB du pauvre avec seulement un ampli RGB (type péritel) + séparateur de synchro.
    • PCB du très pauvre
    avec seulement ampli  RGB + séparateur mais sans connecteur péritel ni sortie jamma, juste des picots pour souder (et c'est cette partie qui m'intéresserait pour mon projet DC).
    [/list]

    J'ai parcouru le topic hier soir pendant environ 2H et je reste ébahi quand à l'avancée de vos travaux. Je pense qu'un petit retour en arrière serait profitable à la communauté afin de valider ne serai-ce que les bases (le 1er PCB monté était de bonne facture non ?). En tirer quelques exemplaires de la PCB du très pauvre ou juste un typon pour les personnes intéressées serait du pain beni pour mettre mon projet sur rails.

    Dans tous les cas, je vous remercie car le topic regorge de petits conseils d'électroniciens et me permet de me replonger dans cette science que j'ai quitté après mon bac (5 ans déjà)..

    PS1 : Liodel, étant aware en électronique je pourrai par exemple reprendre le début de tes travaux pour échafauder le plan de la PCB du très pauvre, le permettrais-tu ?
    « Modifié: Mercredi 23 Décembre 2009, 15:50:57 pm par setsuan »

    Hors ligne liodel

    • Hardcore Gamer
    • *
    • Messages: 1958
      • Voir le profil
    [WIP] - Ampli Video - Console vers jamma
    « Réponse #219 le: Mercredi 23 Décembre 2009, 15:28:25 pm »
    PS1 : Liodel, étant aware en électronique je pourrai par exemple reprendre le début de tes travaux pour échafauder le plan de la PCB du très pauvre, le permettrais-tu ?
    Bonjour,
    le pcb du très pauvre est documenté, et tu peux le trouver sur ce site ici
    http://www.gamoover.net/tuto/schema-de-montage-du-lm1881-séparation-de-la-synchro-du-signal-composite
    il se fait sur une plaque a trous, donc vraiment pour le plus petit budget
    mais si tu veux un schéma format eagle et son pcb, je peux te faire ça easy
    le premier pcb était très bien mais avait déjà l'ampli vidéo sans le clamp du coup les niveaux de couleurs étaient dépendant de la présence de condensateurs dans le câble DC. Donc j'avais déjà avancé vers le pcb du pauvre.
    « Modifié: Mercredi 23 Décembre 2009, 15:29:59 pm par liodel »

    "Chuck Norris a déjà compté jusqu'à l'infini. Deux fois." - "Chuck Norris ne se mouille pas, c'est l'eau qui se Chuck Norris." - © Chuck Norris facts - fr

    Hors ligne setsuan

    • Pensionnaire
    • *
    • Messages: 40
      • Voir le profil
    [WIP] - Ampli Video - Console vers jamma
    « Réponse #220 le: Mercredi 23 Décembre 2009, 15:52:24 pm »
    Précédent post édité, j'avais oublié le mot "ampli" pour la PCB du très pauvre.
    Afin de ne pas faire partir le topic dans toutes les directions , j'ai opté pour le MP vers liodel. Au pire, une fois que quelques informations seront validées, je créerai un topic annexe.

    Hors ligne gc339

    • Beta Testeur
    • *
    • Messages: 2193
      • Voir le profil
    [WIP] - Ampli Video - Console vers jamma
    « Réponse #221 le: Jeudi 24 Décembre 2009, 01:07:33 am »
    Bonsoir

    Voici le bout de schéma concernant la paire de cavaliers de programmation :


    Avec ce schéma multiplexant la lecture des cavaliers il n'est possible de piloter qu'une seule LED.
    En plus de l'indication éteinte/allumée, il va donc falloir la faire clignoter pour afficher une information supplémentaire :
    • Éteinte : Pas de présence d'un signal de synchronisation, by-pass inhibé.
    • Clignotante : Présence d'un signal de synchronisation quelconque, by-pass inhibé.
    • Fixe : Présence du signal de synchronisation attendu, by-pass validé.
    Le clignotement sera réalisé hors temps réel, c'est à dire dans la boucle de fond. De toutes façons le µC ne fait rien d'autre que de boucler indéfiniment pendant qu'il attend une interruption ligne ou trame, autant lui donner un peu d'occupation.

    La lecture des cavaliers s'effectue en deux séquences au moment de l'initialisation après un reset ou un coup de chien :

    • 1er séquence :
      • Le port GP1 est déclaré en sortie et à l'état bas (zéro logique).
      • Le port GP0 est déclaré en entrée avec la résistance interne de "pull-up" validée.
        • Si le cavalier supérieur est présent, le port GP1 impose un niveau logique 0 à travers la diode du haut sur l'entrée GP0.
        • Si ce même cavalier est absent, l'entrée GP0 reste au 1 logique grâce à sa résistance de "pull-up"
      • A noter que la LED s'éclaire intempestivement pendant cette 1er séquence si le cavalier du haut est présent, ce qui n'est vraiment pas gênant car la durée de la séquence est de l'ordre de la µs.

    • 2èm séquence :
      • Cette séquence-ci les rôles sont inversés : C'est le port GP0 qui est déclaré en sortie à l'état bas et le port GP1 qui est déclaré en entrée avec sa résistance de "pull-up" de validée.
      • L'entrée GP1 est forcée au niveau logique 0 à travers la diode du bas si le cavalier inférieur est présent, sinon elle est vue au niveau logique 1.
      • Même genre de remarque pour la LED, elle s'allume intempestivement pendant cette séquence indépendamment de la présence du cavalier inférieur.

    • Ces deux séquences de lecture effectuées, le port GP0 reste déclaré en sortie alors que le port GP1 reste déclaré en entrée, résistance de "pull-up" désactivée.
      Un état bas sur la sortie GP0 allumera la LED alors qu'un état haut la maintiendra éteinte.

    Les diodes seront préférentiellement des diodes schottky genre BAT42 à cause de leur seuil plus faible : 0,3 Volt contre 0,7 volt pour des diodes passe-partout genre 1N4148.


    « Modifié: Jeudi 24 Décembre 2009, 09:03:15 am par gc339 »
    Le repos, c'est fait pour les jeunes. Ils ont toute la vie devant eux. J. Gabin/M. Audiard



    Hors ligne gc339

    • Beta Testeur
    • *
    • Messages: 2193
      • Voir le profil
    [WIP] - Ampli Video - Console vers jamma
    « Réponse #222 le: Mardi 05 Janvier 2010, 01:26:42 am »
    Bonsoir.

    Ce qu'il restait à faire au niveau programme du PIC :
     
    • Gérer le chien de garde.
    • Lire les cavaliers de configuration et appliquer les paramètres pour chaque fréquence ligne à filtrer.
    • Oblitérer une impulsion ligne sur deux dans le cas de la pseudo conversion 31 kHz vers 15 kHz.

    Ce qui a été ajouté depuis :

    • Afficher l'état du discriminateur à l'aide d'une LED :
      • Verrouillé, présence de la bonne fréquence ligne : LED allumée fixe.
      • Présence d'un signal de synchro ligne quelconque : LED clignotante.
      • Absence de tout signal de synchronisation ligne: Led éteinte.



    La gestion de la LED.

    La LED devant être gérée hors temps réel, c'est à dire dans la boucle d'attente, il est très facile de l'allumer ou de l'éteindre en fonction d'un flag positionné par la routine traitant les interruptions.
    Avec le clignotement se pose un petit problème : comment générer la temporisation qui va servir à la faire clignoter ?
     
    La solution la plus simple que j'ai trouvée est celle d'utiliser le Timer1 qui était jusqu'alors inemployé :
    • Le Timer1 est précédé d'un prédiviseur ou "prescaler". Ce prescaler reçoit un signal d'horloge dont on peut choisir la source par programmation.
    • Quand le prescaler du Timer1 est piloté par le signal d'horloge externe au PIC, 20 MHz dans le cas présent, il ne peut l'être que par ce signal prédivisé par 4.
    • Le rapport de division maximum du prescaler est de 23 donc de 8 (4 rapports possibles : 1, 2, 4 et 8 ).
    • Le Timer1 est un compteur à 16 bits, son indicateur de dépassement est donc positionné toutes les 216 soit 65536 impulsions en provenance de son prescaler.

    L'indicateur de dépassement du Timer1 est donc sollicité à la fréquence de : 20 × 106 ÷ 4 ÷ 8 ÷ 65536  soit 9,5 Hz.

    Il suffit donc de faire surveiller cet indicateur de dépassement par la boucle de fond, de lui faire inverser l'état de la LED à chaque fois que l'indicateur apparaît pour qu'elle clignote à une fréquence deux fois moindre. C'est à dire 4,75 Hz, ce qui est tout à fait compatible avec la persistance rétinienne pour bien percevoir ce clignotement.

    Le chien de garde (Watch Dog)

    La temporisation du chien de garde est générée en interne à partir d'un compteur qui évolue à une fréquence d'horloge de 31 kHz. La temporisation peut être choisie comme étant la période de l'horloge à 31 kHz divisée dans un rapport de 25 à 216 soit un rapport de 32 à 65536.
    En choisissant la temporisation la plus petite, donc le coefficient 25 = 32, cette temporisation est de : (32 ÷ (31 × 103 )) = 1,03 × 10-3 soit à peu de chose près 1 ms.
    Le chien aboiera donc au bout d'une période équivalente à ((1 × 10-3 ) ÷ (64 × 10-6 )) soit 16 impulsions de synchronisation manquantes pour une fréquence ligne de 15 kHz et le double soit 32 impulsions manquantes pour une fréquence ligne de 32 kHz.

    Quand le chien a aboyé suite à la disparition du signal de synchronisation, le PIC se réinitialise et le compteur programme est forcé à zéro comme à la mise sous tension.
    Le programme développé ne fait pas la différence entre une réinitialisation suivant la mise sous tension et celle due au chien de garde, le système est déclaré déverrouillé, la LED indicatrice est éteinte, le by-pass interdit, puis il se met en attente des impulsions de synchronisation ligne.

    La vérification du fonctionnement du chien a fait apparaître un dysfonctionnement. Le problème venait de la routine d'interruption : l'adresse de la routine est commune à toutes les interruptions, il faut donc faire un test en entrée pour en connaître la source :
    • Changement d'état du signal de synchronisation trame.
    • Front montant d'une impulsion de synchronisation ligne.
    Ce choix permet d'exécuter la sous-routine correspondante à la source.

    Ce test se faisait préalablement sur le flag "Interrupt-on-change" positionné par le changement d'état du signal de synchronisation trame.
    Une analyse attentive à montré qu'il était impératif de le faire sur le flag de l'interruption due au signal de synchronisation ligne pour une question de séquencement car l'interruption due au signal de synchronisation trame est tributaire de celle due au signal de synchronisation ligne.
    Ce test une fois modifié, tout est rentré dans l'ordre.

    Lecture des cavaliers / paramètres selon fréquence ligne à filtrer

    Le programme de lecture des cavaliers est écrit mais non encore testé.

    Les paramètres suivants ont été chronométrés a partir de :
    • De la DreamCast comme source vidéo pour le 15 kHz et le 31kHz.
    • D'une mesure réalisée par F4brice pour le 24 kHz car je ne dispose pas d'une carte ou d'un système délivrant cette fréquence de balayage.

    Les valeurs chronométrées sont celles lues dans le Timer0 à l'aide d'un petit programme de lecture affichant les bits deux à deux sur les ports GP0 et GP1, sauf pour le 24 kHz évidemment.
    • Chronomètre = 158 pour le 15 kHz (160 théorique).
    • Chronomètre = 77 pour le 31 kHz (80 théorique).
    • Duré ligne = 40,2 µs pour le 24 kHz, soit un chronomètre théorique de 40,2 ÷ 0,4 = 100,5. (0,4 µs étant le pas du chronomètre )
      étant donné que le chronomètre théorique est supérieur de deux ou trois unités au chronomètre réel (temps de prise en compte des interruptions ), une valeur de 98 pour le chronomètre réel semble appropriée.

    Les valeurs retenues pour encadrer la fenêtre du discriminateur sont les suivantes :
    • 158 ± 5 pour le 15 kHz, donc 153/163.
    • 98 ± 4 pour le 24 kHz donc 94/102.
    • 77 ± 3 pour le 31 kHz, donc 74/80.

    En fait je me suis basé sur la tolérance d'un moniteur Hantarex MTC9000, celui-ci accepte une fréquence ligne de 15625 Hz ± 500 Hz, ce qui correspond à une tolérance de 3%. Les valeurs limites choisies pour le chronométrage sont dans cet ordre de grandeur.

    Plus concrètement, pour le 15 kHz par exemple, cela veut dire qu'un signal de synchronisation dont la période chronométrée entre deux impulsions est inférieure à 153 ou supérieure à 163 ne sera pas reconnu comme un signal de synchronisation à 15 kHz. Le PIC ne se verrouillera pas et le by-pass restera interdit.



    Ce qu'il reste à faire :
     
    • Tester le programme de lecture des cavaliers, vérifier que l'on filtre bien la fréquence ligne choisie à partir des cavaliers.
    • Oblitérer une impulsion ligne sur deux dans le cas de la pseudo conversion 31 kHz vers 15 kHz.
    • Tester le discriminateur en place sur le circuit imprimé de l'interface console2jamma

    A suivre ...
    « Modifié: Vendredi 08 Janvier 2010, 23:58:04 pm par gc339 »
    Le repos, c'est fait pour les jeunes. Ils ont toute la vie devant eux. J. Gabin/M. Audiard



    Hors ligne gc339

    • Beta Testeur
    • *
    • Messages: 2193
      • Voir le profil
    [WIP] - Ampli Video - Console vers jamma
    « Réponse #223 le: Vendredi 08 Janvier 2010, 21:50:00 pm »
    Bonsoir.

    Ce qu'il restait à faire :
     
    • Tester le programme de lecture des cavaliers, vérifier que l'on filtre bien la fréquence ligne choisie à partir des cavaliers.
    • Oblitérer une impulsion ligne sur deux dans le cas de la pseudo conversion 31 kHz vers 15 kHz.
    • Tester le discriminateur en place sur le circuit imprimé de l'interface console2jamma



    La gestion de la LED

    La boucle de fond teste en permanence l'indicateur de débordement du Timer1, ce qui se reproduit tous les 1/9em de seconde. Pour simplifier la gestion de la LED, le programme ne modifie l'état de celle-ci qu'à partir de ce moment là :
    • Le programme teste d'abord l'indicateur "locked" qui n'est positionné que par la routine d'interruption :
      • Si cet indicateur est à 1 : La LED est allumée, pour indiquer que le programme a détecté la bonne fréquence ligne.
      • S'il est à 0 : Poursuite du programme avec le test de présence du signal de synchronisation ligne.
    • Le programme à besoin de savoir s'il y a présence d'impulsions de synchronisation ligne. Comme il n'y a aucun indicateur spécifique de prévu au niveau de la routine d'interruption, c'est le bit qui valide le chien de garde qui sera testé car ce dernier est systématiquement réarmé par chaque interruption due au signal de synchronisation ligne :
      • Si ce bit est à 1 : L'état de la LED est inversé afin de la faire clignoter à la fréquence de 4,75 Hz.
      • S'il est à 0 : Il n'y a donc pas de présence d'un signal de synchronisation quelconque, la LED est éteinte.
    • Après avoir modifié l'état de la LED, le programme retourne alors dans la boucle de fond pour attendre un nouveau dépassement du Timer1

    Lecture des cavaliers

    Tout d'abord une petite rectification du schéma + numérotation des cavaliers :


    Voici comment les fréquences seront programmées sur les cavaliers en fonction de leur absence/présence. Il y a donc 4 configurations possibles :

    |Cavalier 2|Cavalier 1|Fréquence|
    |Absent|Absent|15 kHz|
    |Absent|Présent|24 kHz|
    |Présent|Absent|31 kHz|
    |Présent|Présent|31 --> 15 kHz|


    Le programme de lecture des cavaliers a été testé avec succès, aucun débogage ou retouche n'a été nécessaire. Le PIC reconnait bien le 15 kHz et le 31 Khz issus de ma DC et autorise bien le by-pass en conséquence.
    Malheureusement je n'ai pas de source 24 kHz pour le tester, en tous cas avec les cavaliers en position 24 kHz, le PIC rejecte bien le 15 et le 31 kHz.

    Une photo du PIC en cours de test pour illustrer ce post :


    Sur la plateforme à souder on peut reconnaître de bas en haut :
    • La résistance de 510 Ω limitant le courant dans la LED.
    • La LED verte.
    • Les deux diodes shottky BAT42.
    • La résistance de 2,4 kΩ du by-pass.
    • Le condensateur de découplage du +5 volts.
    Seuls les switches 1 et 2 du boitier à 8 switches ont été cablés. Ici, ils sont positionnés pour le mode 31 --> 15 kHz.
    La sonde de l'oscilloscope est connectée en sortie du by-pass pour visualiser la présence et le timing du signal de synchronisation composite restitué.



    Ce qu'il reste à faire :
     
    • Oblitérer une impulsion ligne sur deux dans le cas de la pseudo conversion 31 kHz vers 15 kHz.
    • Tester le discriminateur en place sur le circuit imprimé de l'interface console2jamma

    « Modifié: Vendredi 08 Janvier 2010, 23:47:15 pm par gc339 »
    Le repos, c'est fait pour les jeunes. Ils ont toute la vie devant eux. J. Gabin/M. Audiard