Tous les articles par Matmook

Du mieux sur les lampes

Bon, allumer toutes les lampes d’un coup, c’est bien…pouvoir choisir lesquelles allumer, c’est mieux…

Hier soir, j’ai réussi à mettre en place une routine permettant d’allumer les lampes en fonction de leur état dans un tableau… pas très propre, gourmand en mémoire (c’est un Arduino, pas un pc…) et par certains côtés, pas logique…

Azizzzz … LIGHTS !!!

Pour ceux qui n’aurait pas reconnu, c’est une célèbre réplique du 5ème élément !!

Après une longue série de tests, je me suis rendu compte que si je continuais de travailler sur les lampes en mode bit à bit , ça n’allait pas le faire…

Sur A5 (Lamp Driver) : 16 lampes x 4 contrôleurs = 64 commandes

Sur A9 (Auxiliary Lamp Driver) : 8 lampes  x 4 contrôleurs =32 commandes

Par commande : 12 changements d’état (4 pour le choix du contrôleur, 4 pour le choix de la lampe, et 4 pour générer 2 fronts montant pour activer la chose)

ça nous donne du 1152 modifications de bit … le tout 25 fois par secondes…. o_O

Va stocker ça correctement dans un tableau pour tout redécouper… Pfiouuu !

Et surtout, changer les entrées une à une, c’est pas génial et le résultat n’est vraiment pas terrible du tout (ça ne commute pas comme il faut). Du coup je me suis penché sur les « Register » de l’Arduino (si seulement je l’avais vu avant …).

Ces registres permettent de manipuler en 1 seule opération les 8 bits d’un registre (représentant un ensemble de 8 broches de l’Arduino )… Génial !!! SAUF QUE : Je n’ai pas câblé mes entrées/sorties en fonction de ces registres… (et puis la doc pèche un peu là-dessus, j’ai du fouiller dans les .h pour trouver des infos…)

De toutes façons, elle commençait à me gonfler cette nappe IDE … j’ai tout changé pour correspondre aux registres et j’en ai profité pour connecter l’Arduino directement sur le circuit :

Ah ouais, c'est beau !!

C’est bien plus simple à connecter et en plus toutes les I/O de l’Arduino sont accessibles sur le circuit !

Un code refait à zéro et j’ai pu… enfin … allumer toutes les lumières d’un coup (bon, j’en ai quelques une à changer) :

ça déchire !!

 

Par contre, plus rien de jouable pour le moment. snif. Je vais remettre la gestion des switchs et coller l’ensemble switchs/lampes dans une sympatique interruption (c’est le plan en tout cas…reste à trouver comment…)

 

Gestion câblée des lampes

Voilà, j’ai terminé l’ajout de le gestion des lampes sur mon circuit (pour la gestion des cartes contrôleur A5 et son extension A9) :

A3, A5, A9 et les switchs câblés!

J’ai commencé à écrire la routine de gestion des lampes. Grosse particularité : ça fonctionne exactement comme un tube cathodique, c’est à dire qu’il faut constamment « rafraîchir » l’état des lampes.

En gros : Je suis en 50Hz sur le secteur. Pour ne pas avoir trop de scintillement, je vais devoir tout rafraîchir 25 fois par secondes.  Chaque lampe doit être commandée séparément, ce qui me donne 120 commandes x 25 par seconde.

Il va être nécessaire de lancer cette routine à intervalle très régulier sinon ça risque de clignoter à tout bout de champs (rien qu’en attendant la fin de course d’un solénoïde…).

Bon, c’est pas un écran, il n’y a pas de VBL pour taper sur le 50Hz mais une petite interruption contrôlée par un timer devrait faire l’affaire… faut voir.

Edit du 27/09/2013 :

Hmm, ça ne fonctionne pas comme prévu. je vais me fabriquer un banc de tests pour valider  le fonctionnement de ces cartes une à une… J’ai une lampe qui reste allumée en permanence, que je l’active ou non…peut-être une puce de grillée…

Du mieux sur les switchs

Bon, petits tests rapides hier soir :

– « Saucer » gauche, une impulsion rapide du doigt :

a) avec condensateur : activé pendant 6s !!!! Autant dire qu’il ne se désactive jamais si la gestion de la solénoïde correspondante est activée…

b) sans condensateur :  activé pendant très peu de temps

J’ai donc, dans un premier temps, coupé les condensateurs de maintient du « saucer » gauche ainsi que des 2 bumpers et déjà, je note un nette amélioration au niveau des détections…

Prochaine étape : trouver un moyen de passer outre les problèmes de boucing …

Matrice, qu’est ce que c’est que cette zone ?

Hop, aujourd’hui soudure, je me suis décidé à en mettre un peu plus sur le circuit définitif . J’ai donc ajouté la gestion des switchs et fait en sorte de n’avoir qu’une seule nappe pour connecter l’arduino … 2h à implanter et souder la chose :

Solénoïdes et matrice de switchs

J’ai ensuite modifié mon code Arduino pour lire l’intégralité des switchs du flipper (40). Résultat bof, résultats étranges … pas glop quoi !

Merci L’Arduino, j’ai mis en place du debug pour pouvoir tester un à un les switchs :

des bugs ou debug ...

Tout fonctionne à peu près. Le « Saucer » de gauche prend bien son temps sur la colonne 2 pour retourner à l’état bas et les cibles 33 et 34 sont actives en permanence sur la colonne 4, c’est probablement pour ça que j’ai des résultats étranges.D’après ce que j’ai pu voir sur le net, certains vieux condensateurs ont tendance à se … court-circuiter… va falloir changer tout ça… ou les supprimer définitivement. Si on regarde de près le schéma de la matrice du pacman, on peut constater que seulement quelques condensateurs sont présents (alors qu’ils sont tous  en place sur mon flipper), je vais donc logiquement pouvoir en supprimer quelques uns :

Problème de matrice

 

Condensateurs ou pas… ces condensateurs sont là pour permettre au signal de rester au niveau haut un peu plus longtemps, le temps de laisser la MPU lire l’état. Ce phénomène était probablement valide sur une carte MPU équipée d’un Motorola 6800 à 1 ou 2MHz, pour lui laisser le temps de lire mais avec le µP à 16MHz de l’Arduino, ce n’est peut-être plus nécessaire… à tester.

Ah oui, petit détail, un fil, désoudé d’un côté et coupé de l’autre trainait sous le playfield…va falloir trouver son origine …

L'ordure !!!

 

Lampes ?

Etude du fonctionnement des cartes Lamp driver et Auxiliary Lamp driver. Ces 2 cartes sont chainées (bus partagé, strobes séparés, 4 bits d’adresse, 4 bits de données). J’ai fait quelques tests à la main mais je n’ai pas encore compris comment cela fonctionnait réellement (en plus, ça emprunte certaines entrées  de la matrice de switchs… électriquement parlant, c’est la misère à décrypter)

Hard oui non ?

Récupération d’un Arduino Mega (merci @HerveThouzard pour son prêt !!! 😉 ) et câblage d’une partie de la matrice de switch et de la carte de gestion des solénoïdes :

Arduino mon ami !

Finalement, j’ai câblé tout ce qui peut bloquer la bille (c’est lourd de devoir enlever la vitre pour débloquer !!!) 😀

J’ai, du coup, fait un mini-programme action (switch) / réaction (solénoïde) permettant une gameplay minimaliste et ça fonctionne !!!! \o/

Play Again

Mise en place d’un « play again » automatique. Un switch étant valide à l’état haut et un solénoïde à l’état bas, j’ai utilisé une porte logique 74LS04 pour inverser le signal. Donc dès que la bille tombe dans le trou, je détecte le niveau haut (je ne teste que ce switch) que je transforme en niveau bas sur le solénoïde pré-sélectionné par des dip-switchs.