réparation d'une déchiqueteuse

Je viens de compléter la réparation d'une déchiqueteuse de marque STAPLES modèle SPL-TXC12A

1. Approche du problème
2. Reverse engineering
3. Description du circuit
4. Fonctionnement du TRIAC

Approche du problème

Après avoir ouvert le boitier et extrait le circuit imprimé il est apparut évident que le fusible était brulé. Il ne suffit pas de le remplacer, il faut se demander pourquoi il a brûlé? Même si on ne possède aucune information sur le circuit on peut figurer que la cause la plus probable est une déficience dans le circuit de puissance. Il y a 2 composants montés sur des dissipateurs de chaleur. Il faut donc chercher à identifier ces composants et vérifier si l'un d'eux ou les 2 ne serait pas la cause de la défectuosité.

Circuit imprimé, fusible F1 et TRIAC retiré. Le pont redresseur est monté sur le petit dissipateur de chaleur et le boitier orange est un relais.

J'ai d'abord porté mon attention sur le composant au format TO-220 monté sur le plus gros dissipateur de chaleur. Sur le circuit imprimé c'est inscrit in sur la broche de gauche, out sur la broche du centre et g sur la broche de droite. Je croyais qu'il s'agissait d'un régulateur de tension pour alimenter le circuit intégré. l'ohmètre indiquait un court circuit entre les broches in et out. Je l'ai donc retiré du circuit. L'indication ne me disait rien, je m'attendais à quelque chose comme 7805 pour un régulateur linéaire de 5 volt, mais ce n'était pas ça.

composant mystère

SanRex? T8E6?. Recherche dans l'internet, rien! pas de datasheet sur le site du fabriquant! Examen du circuit imprimé, je vois que ce composant est branché au neutre de l'alimentation 120 VAC à travers une résistance de puissance de 0,1 ohm qui arrive sur sa broche in et que sa broche out va sur une broche de l'autre composant de puissance monté sur un dissipateur de chaleur. Ce composant avec ces 4 broches ressemble à un pont redresseur que je me dis. Vérification de l'étiquette du moteur, c'est un moteur qui fonctionne à 120VDC. Ça fait du sens, le AC doit-être redressé pour alimenter le moteur et il faut contrôler sont alimentation et le composant que j'ai retiré ne peut-être qu'un TRIAC dans ce cas car il est monté du côté AC du pont redresseur et on utilise normalement un TRIAC pour contrôler une alimentation AC en puissance.

120V/60hertz convertie en DC

Je suis donc au prise avec un TRIAC inconnu que je dois remplacer. L'étiquette à l'arrière de la déchiqueteuse indique que l'appareil consomme 3 ampères. Le fusible est de 5 ampères. Donc un TRIAC capable de passer un courant 8 ampères (paramètre It(rms)) et d'un voltage de coupure répétif maximum (paramètre Vdrm) de 600VAC devrait faire l'affaire. Il me reste à vérifier comment est alimenté le gate du TRIAC. Reverse ingeneering du circuit. Je constate qu'il est alimenté directement par le micro-contrôleur HT46R47 par la broche GPIO PA5 à travers la résistance R4 de 200 ohm. J'ai trouvé le feuillet de spécification du microntrôleur dans l'internet et j'ai pu vérifier que les GPIOs peuvent sourcer un courant (paramètre Ioh) maximum de 10mA lorsque le MCU est alimenté à 5Volt. Donc il me fallait un TRIAC avec les paramètres suivants:

• Vdrm (repetitive peak off state voltage) minimum de 400VAC pour avoir une marge de sécurité.
• It(rms) (non repetitive on state current) minimum de 5 ampères pour avoir une marge de sécurité.
• Igt (gate trigger current) maximum de 5mA pour avoir une marge fonctionnelle.

J'ai arrêté mon choix sur le BT127-600D.

• Vdrm 600 volt
• It(rms) 8A
• Igt maximum 5mA
• De plus le gate est conçu pour être branché directement à un microcontrôleur comme indiqué dans le feuillet de spécifications:
  This very sensitive gate "series D" triac is intended to be interfaced directly to microcontrollers, logic integrated circuits and other low power gate trigger circuits.

Composants commandé et reçus. Fusible et TRIAC installé appareil réparé.

Reverse engineering

Un coup parti je n'allais pas m'arrêter là. Comme le circuit imprimé est simple face qu'il y a peu de composants j'ai décidé de faire le reverse engineering du circuit.

Description du circuit

Il s'agit d'un appareil conçu pour l'Amérique du nord et fonctionne donc sur une alimentation secteur de 120VAC. Il y a 2 protections contre les accidents réalisées par les microswitch SW1 et SW2. La première (schredder on bin) coupe l'alimentation lorsque la déchiqueteuse est soulevée du bac de réception. La deuxième (emergency key) coupe l'alimention lorsque la clé rouge est retirée de sa fente.

Au point de vue électrique, il y a 2 protections:

1. Le fusible F1 de 5 ampères a bien joué son rôle lorsque le TRIAC a flanché pour devenir court-circuit.
2. Le fusible F2 est une protection contre la surchauffe du moteur et ouvre le circuit au cas ou il y a surchauffe. Le microcontrôleur mesure le courant qui passe à travers la résistance de 0,1 ohm et lorsque le TRIAC est commandé mais qu'aucun courant n'est détecté dans le circuit le MCU en détuit que F2 est possiblement ouvert et indique une surchauffe en allumant la LED over heat.

Il y a 2 opto-coupleurs.

• Paper detection est installé en travers de la fente de réception des feuilles et informe le MCU qu'il faut démarrer le moteur. Tant qu'il y a détection de papier le moteur tourne.
  
• bin full detection est installé au fond de l'unité de déchiquetage et lorsque le bac est plein la LED full s'allume.
  photo détecteur bac plein

Le relais avec contacts DPDT sert à inverser la rotation du moteur lorsque l'appareil et en mode REV. Cette fonction est ulitisée lorsqu'il y a bloquage de l'appareil et qu'on veut faire ressortir les feuilles bloquées.

L'alimentation du MCU est régulée par la zener diode ZD3. Une seule diode 1N4007redresse la tension AC, donc le redresseur fonctionne en demi-phase ce qui nécessite un bon filtrage assuré par plusieurs condensateurs. Il y a les 2 électrolytics E3 et E4 de 470µF/16V ainsi que les condensateurs céramiques montés en surface C5 et C6.

Le relais nécessite 24VDC pour contrôler sa bobine. Cette alimentation est fournie par les composants D5 diode redresseuse. E2 électrolytique de 220µF/35V et régulé par 2 zener en série ZD1 et ZD2.

La bobine du relais est contrôlée à travers le transistor Q3 de type PNP qui lui-même est contrôlé par le transistor Q1 de type NPN. C'est la sortie GPIO PA2 du MCU qui contrôle la base de Q1.

Le MCU possède 4 entrées de convertion analogique/numérique.

AN0 utilisée par l'optocoupleur qui détecte un bac plein.

AN1 mesure le courant à travers la résistance de 0,1 ohm. Le MCU allume la LED over heat s'il n'y pas de de courant.

AN2 pas utilisée.

AN3 utilisée par l'optocoupleur qui détecte la présence de feuille dans la fente.

Fonctionnement du TRIAC

symbole du TRIAC

Par Auteur inconnu — Source inconnue, Domaine public, Lien

Les cadrants

By <a href="//commons.wikimedia.org/wiki/User:Krishnavedala" title="User:Krishnavedala">Krishnavedala</a> - <span class="int-own-work" lang="en">Own work</span>, CC0, Lien

Cette image nous montre la polarité du gate et de A2 par rapport à l'électrode A1, aussi nommée MT1. selon les différents modes d'opérations. Dans le cas de cette déchiqueteuse le TRIAC est utilisé dans les modes (cadrants) 2,3. Si on regarde la schématique on constate que le Vdd du MCU est connecté au neutre de l'alimentation secteur et que Vss est négatif par rapport au neutre. Bien que j'ai oublié de l'indiqué sur la schématique l'électrode du TRIAC du côté de la résistance est A1 et celle du côté de F2 est A2. Ceci est nécessaire pour que le MCU puisse contrôler le TRIAC car comme on le voie sur l'image dans les cadrants 2 et 3 G doit-être négatif par rapport à A1 pour faire entrer le TRIAC en conduction. Donc lorsque le MCU veut bloquer le TRIAC il met la GPIO PA5 à Vdd et lorsqu'il veut déclencher la conduction du TRIAC il envoie une impulsion négative sur la broche.

Pour qu'un TRIAC demeure en conduction il faut qu'un courant minimum circule entre A1 et A2. Comme en courant alternatif le voltage repasse à zéro à toutes les demi-période il faut que le MCU envoie une impulsion sur le gate au début de chaque demi-cycle, c'est à dire 120 fois par seconde. Dans le but de synchroniser ces impulsions avec le fréquence du secteur la ligne est monitorée au point A par le MCU sur l'entrée PA4 à travers les résistances R10 et R11.

POMME-I, le désassembleur

Le moniteur possède maintenant un désassembleur accessible avec la commande @. L'affichage pause à chaque page et il faut appuyer sur la barre d'espacement pour voir la page suivante. Toute autre touche revient à la ligne de commande du moniteur. Le STM8S207K8 possède un boot loader en ROM à l'adresse 0x6000. Voici les premières lignes de code tel que désasssemblées par stm8_dasm.

#6000@

6000: 9B
6000	9B               SIM
6001	AD 0C            CALLR 600F 
6003	25 19            JRC 601E 
6005	CE 48 7E         LDW X,487E 
6008	A3 55 AA         CPW X,#55AA 
600B	27 11            JREQ 601E 
600D	20 16            JRA 6025 
600F	C6 80 00         LD A,8000 
6012	A1 82            CP A,#82 
6014	27 06            JREQ 601C 
6016	A1 AC            CP A,#AC 
6018	27 02            JREQ 601C 
601A	99               SCF
601B	81               RET
601C	98               RCF
601D	81               RET
601E	C6 48 00         LD A,4800 
6021	A1 AA            CP A,#AA 
6023	26 09            JRNE 602E 
6025	5F               CLRW X
6026	4F               CLR A
6027	4B 28            PUSH #28 
6029	86               POP CC
602A	AC 00 80 00      JPF 8000 

La prochaine étape est l'écriture d'un assembleur simple. Lorsque l'assembleur sera intégré au moniteur je vais changer les commandes du moniteur. Toutes les fonctions qui ne font pas parti du moniteur de base comme S,] et @ seront accessible par une interface de commande dérivée accessibles par la lettre X. X pour extension puisque que ces fonctionnalités ne faisait pas partie du p1Monitor à lorigine.

Cette version V1.3R0 est disponible sur le github mais je vais attendre que l'assembleur soit complété avant de présenter un vidéo de démonstration.

POMME-I, V1.2R4 , améliorations du moniteur

Dans la version précédente du moniteur, assembler le code pour les appels système était un peu compliqué et encore plus compliqué lorsqu'il s'agissait d'opérations sur les fichiers. J'ai simplifié tout ça en ajoutant la commande S. De plus j'ai ajouté la commande ] pour assembler l'instruction machine RET qui indique la fin du programme en langage machine et le retour vers le moniteur.

En MS-DOS il y avait un programme appellé debug.exe qui était un moniteur avec un assembleur et un désassembleur ainsi que d'autre fonctions pour examiner et modifier la mémoire RAM. Il y avait 2 types de fichiers exécutables en MS-DOS, les fichiers *.COM et les fichiers *.EXE. L'application debug.exe permettait de créer des fichiers *.COM. Avec le p1Monitor mon objectif est de m'approcher des fonctionnalités de debug.exe en permettant de créer des fichiers en assembleur qui pourront être chargés et exécuter à partir de p1Monitor. Le désassembleur existe déjà puisque je l'avait créé en 2019 avec le projet MONA, ce ne sera pas trop compliqué d'intégrer ce désassembleur à p1Monitor et ensuite il ne me restera qu'à créer l'assembleur.

Démonstration de la commande S de p1Monitor

POMME-I V1.2R2 sauvegarde d'un programme en langage machine.

Dans le vidéo suivant je montre comment:

• créer un programme en langage machine dans le moniteur en se servant des appels aux services noyau.
• Comment créer un autre petit programme pour sauvegarder le premier comme fichier binaire.
• Comment recharger dans le moniteur le fichier binaire pour l'exécuter.

POMME-I version 1.2r0

Ces derniers jours j'ai apporté plusieurs améliorations au projet.

• Dans le moniteur on peut maintenant entrer une chaîne de caractères directement dans la mémoire RAM sans avoir en convertir en codes ASCII.
• Dans le moniteur on peut afficher une aide rapide sur les codes de service du noyau avec la commande ?.
• Le BASIC a maintenant accès à la mémoire RAM SPI par le tableau XRAM().

Démonstration de la version 1.2

POMME-I: comment je programmais en 1978

Steve Wozniak le créateur du Apple-I a programmé le moniteur de celui-ci sans utiliser d'assembleur. Quelque années après lui j'ai fait la même chose sur le premier micro-ordinateur que j'ai acheté. Ce dernier était basé sur un processeur RCA CDP1802. Pour le programmer il n'y avait qu'un clavier hexadécimal et l'affichage était constitué de LEDs. Dans la vidéo suivante j'utilise le POMME-I pour montrer comment on programmait sans assembleur.

Écrire un programme en utilisant le moniteur.

À travailler de cette façon on mémorise assez rapidement les codes machines ce qui évite d'avoir à consulter le manuel de référence fréquemment. De plus en ce qui concerne l'ordinateur que j'avais le clavier était hexadécimal mais l'affichage LED était binaire donc j'ai aussi appris à traduire les codes binaires en hexadécimal au premier coup d'oeil.

POMME-I version de base

Le projet complet POMME-I comprend 3 modules, l'ordinateur proprement dit basé sur une carte NUCLEO-8S207K8, le terminal basé aussi sur une carte NUCLEO-8S207K8 et enfin l'alimentation 5VDC. Cependant il est possible d'expérimenter le POMME-I simplement en construisant le premier module. J'ai dessiné le schéma de base de ce module.

liste du matériel requis

• 1 Carte NUCLEO-8S207K8
• 1 EEPROM SPI 23LC1024 de 128KO pour sauvegarder des fichiers programmes BASIC et Forth.
• 1 RAM SPI 25LC1024 de 128KO pour augmenter la mémoire RAM.
• 2 résistances de 10Ko 1/4 watt.
• 2 Condenstateur céramique de 100nF
• 1 Petit haut-parleur piézo ou électromagnétique de 130 ohm.
• 1 condensateur électrochimique de 10µF/16Volt.
• 1 Cable USB avec connecteur A et micro C pour connecter la carte à l'ordinateur .

La carte NUCLEO-8S207K8 comprend un programmeur STLINK-V2.1 donc tout ce qu'il faut pour la programmer c'est un cable USB pour la relier à l'ordinateur. Lorsque la carte est reliée à l'ordinateur. Un lecteur apparaît ainsi qu'un port série virtuel qui peut-être utilisé avec un émulateur de terminal pour communiquer avec le POMME-I.

Montage sur carte sans soudure

Pour un montage permanent le circuit peut-être transféré sur une carte comme cell-ci

Programmation de la carte NUCLEO-8S207K8

Dans le dossier dist il y a 2 fichiers binaires

1. pomme_1_hsi16m.bin, c'est le fichier à utiliser si l'option cristal 24Mhz n'est pas utilisée. Le pomme-I fonctionne alors avec l'oscillateur interne de 16Mhz HSI.
2. pomme_1_hse24m.bin, c'est le fichier à utiliser pour faire fonctionner l'ordinateur avec un cristal externe de 24Mhz.

La procédure d'installation est simple il suffit de copier ce fichier sur le lecteur représentant la carte NUCLEO-8S207K8 sur le PC.

Communication avec le pomme-I

Sur Linux Ubuntu j'utilise GTKTerm alors que sur Windows j'utilise Teraterm.
Il faut configurer la communication à 115200 BAUDS 8N1.

p1Forth sur ordinateur pomme-I

J'ai ajouté le langage Forth à l'ordinateur pomme-I.

démo

Dans ce démo je fait une comparaison entre la vitesse d'éxécution du p1BASIC versus p1Forth.

jeu FALL sur stm8 gamepad

J'ai ajouté le jeu **FALL** sur la console stm8 gamepad. Comme le jeu TETRIS est bien connu ça se passe d'explication.

vidéo démonstration

Oui je sais, je joue très mal.

jeu CADENA sur stm8 gamepad

J'ai ajouté un nouveau jeu sur la console stm8-gamepad. Il s'agit d'une variante du jeu Mastermind qui consiste à deviner la combinaison d'un cadena à 4 chiffres. Le joueur dispose de 12 essais et une parti dure 3 manches.

stm8 gamepad v1.1R0

J'ai continué à travaillé sur la console stm8-gamepad

• Ajout d'un splash screen au démarrage.
• Ajout du simulateur du jeu de la vie de John H. Conway.

Vidéo de démonstration

Turing complete

Game of life est Turing complete c'est à dire qu'un ordinateur peut-être réalisé dans un univers game of life et ça a été fait. Dans le vidéo suivant réalisé par Nicolas Loizeau on voit un tel ordinateur ordinateur dessiner un carré à l'intérieur d'un cercle. L'auteur ne nous donne pas la dimension de la grille mais elle est énorme. Ce n'est pas le grenre de truc qui peut-être réalisé dans une grille de 32x22 cellules.

Game of life in Game of life

Et puisque game of life est Turing complete ça veut aussi dire qu'on peut créer un univers game of life à l'intérieur d'un autre. Ça aussi a été fait. .
Imaginez on peut répéter ça à n'importe quel niveau de récursion la seule limitation étant le matériel requis. Jusqu'à quel niveau de récursion pourrait-on aller sur un super ordinateur?

stm8 gamepad

Il s'agit d'une petite console de jeux rétro fabriquée à partir d'un microcontrôleur STM8S207K8 ou d'une carte NUCLEO-8S207K8 qui utilise le même µC mais inclu un programmeur ST-LINK. J'ai fabriqué 2 prototypes un de chaque modèle.

Prototype 1

Prototype 2

Spécifications

• Sortie vidéo composite NTSC monochrome
• Résolution graphique de 200x192 pixels
• Sortie son générant des tonalités ou du bruit blanc
• Pad de 6 boutons, croix et boutons A,B.
• Les programmes de jeux doivent-être compilés avec le projet et réside dans la mémoire flash du µC.

Source du projet

Comme tous mes projets celui-ci est sous licence GPLv3 et le dépôt est sur github.

démo

Pour le moment je n'ai écris qu'un seul jeu appellé SNAKE. Dans la vidéo il manque un élément à droite qui a été coupé par Youtube lors de la conversion du format. Il s'agit d'une barre de chronomètre qui décroit. Lorsque cette barre arrive à zéro il y a un TIME OUT et la parti est terminé. Ce chronomètre est réinitialisé chaque fois que le serpent mange la souris.

SNAKE

règles

1. Si le serpent entre en collision avec un des murs la parti se termine.
2. Si le serpent se mort lui-même la parti se termine.
3. Si le serpent entre en collision avec avec une crotte la parti se termine.
4. Le serpent doit manger la souris avant que le chronomètre expire.

Contrôle

• FLÈCHE HAUT Augmente la vitesse du serpent.
• FLÈCHE BAS Diminue la vitesse du serpent.
• FLÈCHE GAUCHE Le serpent vire à gauche.
• FLÈCHE DROITE Le serpent vire à droite.

Pointage

Le nombre de points gagné dépend de la vitesse du serpent. Celle-ci peut-être ajustée entre 1 et 9.
Si la souris est le long d'une barrière le nombre de points est doublé.
Si la souris est dans un coin le nombre de points est triplé.
Pour les vitesses supérieures à 5, le serpent laisse une crotte chaque fois qu'il mange la souris. Ces crottes sont mortelles pour le serpent. La vitesse par défaut est 5.

Vidéo

stm8 terminal

Puisque je viens de mettre à jour le projet stm8 terminal vers la version 1.0R14. Je vais parler de la génération d'un signal composite au standard NTSC à partir d'un microcontrolleur 8 bits.

• Qu'est-ce que le standard NTSC.
• Pourquoi NTSC plutôt que VGA
• Difficultés de la génération d'un signal de qualité.

Qu'est-ce que le standard NTSC

Ce standard prend son origine aux U.S.A. en 1941 pour la première version noir et blanc et en 1953 pour la version couleurs. NSTC est l'acronyme de National Television System Committee. Il s'agit d'un signal vidéo composite, c'est à dire que toute l'information est contenue dans un seul signal, i.e. synchronisation, luminance et chrominance. Il s'agit d'un signal analogique qui à l'origine était transmit par radiodiffusion.

Générer un signal NTSC monochrome comme pour le projet stm8 terminal est relativement simple et peut se faire même avec le plus petit des microcontrolleurs 8 bits. Dans le passé j'ai réalisé ce genre de signal sur un PIC12F322 pour le projet pong. Comme le projet stm8 terminal ce projet était réalisé entièrement en assembleur.

Comme à l'époque où a été créer ce standard, la télévision était entièrement analogique, l'image était recréé grâce à un tube cathodique par balayage d'un faisceau d'électrons sur une surface phosphorencente appliquée sur la face avant du tube cathodique. Chaque image est constituée de 2 trames entrelacées de 262,5 lignes et le taux de répétition est de 30 images par seconde (60 trames).

Ce qui complique un peu la génération de ce signal est justement cet entrelacement de trames car les trames paires et impaires sont décalées d'une demi-ligne l'une rapport à l'autre.

Le balayage commence en haut à gauche de l'écran en allant vers la droite et se termine en bas à droite.

Par <a href="//commons.wikimedia.org/wiki/User:Cdang" title="User:Cdang">Christophe Dang Ngoc Chan</a> — <span class="int-own-work" lang="fr">Travail personnel</span>, CC BY-SA 3.0, Lien

Chaque ligne horizontal de balayage débute par une impulsion de synchronisation qui dure 4,7µSec. La partie visible qui affiche l'information vidéo dure 52µSec.

Une autre complication est la façon dont la synchronisation verticale qui indique le début de chaque trame est générée. Habituellement j'utilise une minuterie avec sortie PWM pour générer le signal de synchronistation. Hors la synchronisation verticale oblige à reprogrammer la minuterie pour réduire la période de la minuterie de moitier lors de la synchronisation verticale. En plus cette synchronisation se fait en 3 étapes. pré-égalisation, synchronisation, post-égalisation. Et chacune de ces phase oblige une reprogrammation de la minuterie et pour finir il faut revenir à la génération pleine ligne à la fin de la synchronisation. Comme les trames sont décalées d'une demi-ligne l'une par rapport à l'autre, le signal est différent entre trame paire et impaire.

Pourquoi NTSC plutôt que VGA

Pourquoi ne pas utiliser le standar VGA au lieu du standard NTSC ce serait tellement plus simple à générer comme signal, signal de synchronisation plus simple, pas de trames entrelacées. En effet c'est plus simple sauf que la fréquence du signal vidéo est plus élevée. en VGA pour générer 640 pixels par ligne il faut une fréquence de 25.1Mhz (pixel clock frequency). Pour le signal VGA on ne dispose que de 25,4µSec visible pour afficher tous les pixels d'une ligne de balayage. La moitié de ce qu'on dispose en NTSC.

Le mcu du stm8 terminal utilise une fréquence système de 20Mhz et le périphérique SPI utilisé pour sérialiser les pixels sur la ligne vidéo fonctionne à 10Mhz ce qui permet d'afficher 496 pixels par ligne de balayage (62 caractères par lignes). En utilisant le standard VGA on ne pourrait qu'afficher 254 pixels soit 31 caractères par ligne.

Ce que j'ai dit jusqu'ici ne concerne que le NTSC noir et blanc. S'il faut ajouter la couleur à ça, c'est d'autant plus complexe même si j'ai réussi à le faire sur un microcontrôleur PIC12F1572 pour mon projet breakout, ce qui sans me vanter m'a demander de faire preuve d'imagination avec l'utilisation des périphériques.

Donc avec un microcontrôleur à une fréquence système de 48Mhz ou plus il est plus intéressant d'utiliser le standard VGA cependant. Mais en bas de cette fréquence vaut mieux s'en tenir au NTSC malgré la difficulté de générer un tel signal.

Difficultés de la génération d'un signal de qualité.

Je m'en tiendrai ici qu'au monochrome. La façon la plus simple que j'ai trouvé de générer un signal NTSC est d'utiliser une minuterie avec périphérique PWM (Output Compare) pour générer le signal de synchronisation et la sortie MOSI d'un périphérique SPI pour sérialiser les pixels vidéo. Évidemment cette méthode utilisant un SPI n'est valide que pour les signaux vidéo monochromes.

La gigue

La précision de la synchronisation du signal vidéo est fondamentale pour obtenir un signal de qualité. Le problème est d'obtenir un délais constant au niveaux des interruptions vidéos. En effet le temps de réponse aux interruptions, ce qu'on appelle la latence, n'est pas constant. Alors que pour les µC PIC cette latence ne varie que d'un cycle pour les STM8 elle peut variée de plusieurs cycles car l'instruction en cours d'exécution au moment ou le signal d'interruption est généré doit-être complétée avant de répondre à l'interruption. Pour les µC PIC le temps d'exécution des instructions est constant sauf pour les sauts et appels de sous-routine qui prennent un cycle de plus. Pour les µC STM8 le temps d'exécution d'une instruction varie entre 1 et 5 cycles. Il y a donc une plus grande variabilité de la latence. Ce qui génère la gigue (jitter en anglais). Dans le cas d'un signal vidéo cette gigue est très visible et embêtante. Heureusement il y a une méthode pour la contrecarrer.

Dans la routine ntsc_video_interrupt qui est une interruption générée par la minuterie TIM1 qui synchronise le signal vidéo. j'utilise le code suivant pour annuler la gigue.

     ld a,TIM1_CNTRL 
    and a,#7 
    push a 
    push #0 
    ldw x,#jitter_cancel 
    addw x,(1,sp)
    _drop 2 
    jp (x)
jitter_cancel:
    nop 
    nop 
    nop 
    nop 
    nop 
    nop 
    nop
 

Le principe de fonctionnement est le suivant. Le compteur de la minuterie demeure régulié même si le temps de latence varie. Donc si au moment d'entrée dans la routine d'interruption on lit la valeur du compteur (il suffit de lire l'octet faible), le compte va varier en fonction de la latence. Si la latence prend 3 cycles supplémentaire le compte aura augmenter de 3. Comme cette latence ne variera jamais plus que de 5 cycles on ne tiens compte que des 3 derniers bits avec l'opératipon and a,#7. On charge le registre X avec l'adresse cible jitter_cancel. On fait un saut indirect en utilsant la valeur dans X indixé par la valeur des 3 bits les moins significatifs du compteur. Si le compte est nul 6 instructions nop seront exécutées avant de débuter l'envoie des pixels vidéo. Chaque nop s'exéctute en un seul cycle. Si le compte est de 7 le saut se fera après les nop. Il s'agit donc de créer un délais supplémentaire variable inversement proprotionnel à la durée de la latence pour annuller la variabilité de celle-ci. Ainsi l'envoie des pixels vidéo débute toujours au même point par rapport au début de la ligne de balayage.

Interférence

Un problème plus difficile à résoudre est celui des interruptions qui se produisent avant le début d'une ligne vidéo et n'ont pas le temps de se terminer avant le début de la ligne vidéo. La révision V1.0R14 de stm8 terminal avait pour but de corriger un tel problème causé par l'interruption de la minuterie TIM4 qui était générée à un intervalle de 1 msec. Cette interruption se produisait donc plusieurs fois pendant la période visible du signal vidéo ce qui produisait un glissement des pixels vidéos sur les lignes affectées par cette interruption. La seule façon que j'ai trouvé de régler ce problème est de simplement ne plus utiliser la minuterie TIM4. Celle-ci ne servait qu'à synchroniser le clignotement du curseur texte. Hors cette opération pouvait tout aussi bien être réalisée en utilisant l'interruption de la minuterie TIM1 qui sert pour générer la synchronisation vidéo. J'ai donc modifier le code dans ce but.

Problèmes non résolus

Il reste 2 problèmes qui interfèrent encore avec le signal vidéo et pour lesquels je n'ai pas de solution. Le premier est l'interruption de lecture du clavier PS/2 et le second est l'interruption sur réception d'un caractère sur le UART.

1. Sur l'ordinateur pomme I qui utilise le stm8 terminal, si on écris un programme BASIC qui envoie en boucle des caractères au terminal sans arrêt on voit très nettement que la réception de ces caractères crée de l'interférence dans l'affichage vidéo.
2. Lorsqu'on saisie une ligne au clavier sur le pomme I on voit aussi que le signal vidéo est perturbé mais dans une moindre mesure.