PIN²IDE : Interface Haut Niveau + moteur graphique

romain · Message par **romain** » lun. 21 01, 2008 12:16

Bonjour à tous,

le projet ayant trouvé un heureux volontaire pour la création de l'interface Haut Niveau, nous allons discuter ici de sa mise en place et de son fonctionnement.

Encore un grand merci à Pascal qui fait don de son temps pour que le projet continue d'avancer.
La carte prototype que j'ai réalisé et dont j'ai commencé le codage a été envoyée à Pascal la semaine dernière. Cela lui a permis de commencer la communication avec quelques contacts et son interface haut niveau.

Cette interface sera le "moteur" du flipper, c'est elle qui traitera les switchs et activera bobines, lampes en fonction du programme exécuté.

Je laisse à Pascal la liberté de vous expliquer tout ça dans les moindres détails et de résumer son travail effectué jusqu'ici.

@+ et bon flip

Papo06 · Message par **Papo06** » mar. 22 01, 2008 15:18

Je vais faire un petit résumé rapide du système et de ce que j'ai fait qui regroupe un peu ce que j'ai dit éparpillé dans divers messages.

Donc j'ai récupéré le hard de romain qui m'a fourni les sources et ce qu'il faut pour bricoler le code du microcontroleur, pour simplifier ce hard est constitué:

- d'une interface de sortie USB=>Matrice de lampes et sorties Bobines
- d'une interface d'entrée Matrice de Contacts=>USB

Le hard ne gère (pour l'instant en tout cas) que le très bas niveau, c'est à dire:

- Scan de la matrice de switch sur les 8 colonnes, si un ou plusieurs switch d'une colonne changent d'état on envoie la valeur de la colonne complète sur l'USB

- Gestion rapide (par interruption) d'une ou 2 lignes particulières de switch non matricés, pour les boutons des flips + EOS + les boutons tests par exemple comme sur les WMS. Le fait que cette ligne ne soit pas matricée la rend très rapide pour éviter les temps morts quand on appuie sur les flips

- Gestion basique d'une matrice de lampes, le PC indique simplement les lampes allumées et éteintes et le hard gère le balayage

- Si une demande d'activation/désactivation d'une bobine est demandée, mise à jour des sorties bobines (aucune intelligence à part lire la valeur depuis l'USB pour le sortir sur le port bobines)

Ce qui pourrait être interressant d'intégrer également dans le hardware à court terme:

- En premier lieu la gestion interne des flips, le PC indique simplement si les flips sont actifs ou non et reçoit simplement un évènement quand on appuie sur le bouton de flip (pour jouer un son ou gérer un mode video par exemple), mais le PC ne gèrera plus directement la bobine, ni le EOS, ni la bobine de maintiens, donc réactivité des flips instantanée.

- Ajout d'un CRC d'un mécanisme de ACK pour les fonctions importantes, par exemple si le PC dit "Active les Flippers" le hard devrait répondre "Flips activés OK". ça permet de gérer les erreurs de transmission par retry. Inutile pour les lampes car vu que ça clignotte sans cesse si une transmission est raté c'est pas grave ça sera corrigé à la prochaine fois, mais ça peut être utile pour les flips et aussi pour les bobines, pour être sur par exemple que l'ordre d'arret d'une bobine a bien été pris en compte (sinon ça brule...)

A plus long terme:

- Gestion des niveaux d'illumination, comme sur les pinball2000, il n'y a plus de GI mais 2 matrices complètes donc 128 lampes qui servent aussi bien à l'éclairage que pour les inserts sur 8 niveaux (7 + Off)

- Gérer les bumpers/slingshots en interne si on constate que l'activation des bumper via le PC est trop lente/molasse

Pour l'instant le Hardware est limité à 6 ports donc 48 entrées/sorties, pour faire un système ultra complet avec 64 switchs matricés (2 ports), 16 switch directs (2 ports), 24 bobines/flash (3 ports), 2 matrices de 64 lampes (3 ports) il faut 10 ports, donc il faudrait ajouter 2 circuits d'extension 16 bits.

Donc dans un premier temps je vais simplifier l'architecture au strict minimum vital:

- 1 matrice de 64 switch (2 ports)
- 1 matrice de 64 lampes (2 ports)
- 16 bobines/flash (2 ports)

- Pas de switch directs
- Pas de gestion interne des flips
- Pas de gestion de l'illumination générale (elle sera réalisée avec une des sorties bobines)

Pascal

Papo06 · Message par **Papo06** » mar. 22 01, 2008 16:05

Je continue, après le petit rappel du hardware j'en viens maintenant à la partie interface Pin²Ide

Pour l'instant ça se résume à un éditeur ultra sommaire qui permet de charger un script écrit au choix en C# (qui ressemble plutôt à du Java/C++) ou en Visual Basic (qui ressemble très fortement aux VBScript utilisé dans Future Pinball/Visual Pinball).

Pour ma part je préfère de loin le C# car je travaille avec tous les jours et je suis allergique à la syntaxe du VB qui m'horripile, mais celà n'a aucune importance, que vous fassiez le script en VB ou C# le résultat compilé sera strictement identique.

Je n'ai pas trop envie de passer du temps à faire un IDE complet parce que sincèrement ça ne sert strictement à rien de perdre du temps vu qu'il est également possible de lier simplement la dll Pinball.dll avec du code maison et en utilisant soit Visual C# Express Edition 2005 (ou 2008 peu importe) ou bien la version Visual Basic Express et jamais je n'arriverais à faire un IDE aussi complet et pratique puisqu'on peut même débugger avec.

C'est entièrement gratuit et on peut les télécharger ici:

version 2008

http://www.microsoft.com/express/

version 2005

http://www.microsoft.com/express/2005/

L'autre avantage ENORME par rapport à un simple script c'est qu'on fait absolument tout ce qu'on veut, vous avez envie d'ajouter un mini-jeu en flash ? no problemo. Vous voulez afficher de la 3D temps réel ? no problemo. Vous voulez ajouter une partie de gestion réseau et lier des flips entre eux ? faire un système de chat ? afficher la vidéo d'une webcam du joueur incrusté ? no problemo.

Pour un flipper maison, on en a rien à cirer de faire "comme si" c'était un pauvre dot matrix de 128x32 points monochrome, là on peut jouer des anims en couleurs en haute résolution, appliquer des effets, afficher des objets 3D via directX, faire du son en 5.1 si ça vous chante, gérer etc je ne vais pas vous faire la liste de ce qu'on peut faire ça serait trop long.

Bon tout ça c'est de la théorie marrante mais que trouve-t-on donc dans cette fameuse DLL ? c'est très simple, la Pinball.dll contient tout ce qu'il faut pour gérer le hardware Pin² et émuler une table Future Pinball (du moins en partie) en simulant les objets de Future Pinball. Ce n'est bien entendu pas complet c'est juste un début, mais j'ai pu compiler avec succès des script FP simples.

Elle contient aussi des fonctionalités propres aux flippers réels qui n'existent pas dans Future Pinball comme par exemple la gestion du stockage de billes (Through) et de tous les problèmes qui vont avec (bille qui disparait, valeurs aléatoires des switch quand une bille tombe dans le chargeur, idem quand on éjecte une bille dans le lanceur, etc)

Le modèle de programmation est le même que celui de FP ou VP, c'est à dire entièrement orienté évènements, c'est à dire qu'il n'y a aucune "boucle" principale, uniquement des fonctions appelées quand un contact est fermé ou qu'un timer a expiré, que l'afficheur a fini d'afficher du texte, etc et il est fortement déconseillé de faire des boucles d'attentes car elles bloquent les autres évènements, il faut toujours utiliser des timers et gérer une machine d'état au sein de chaque méthode qui est appelée suite à un évènement.

Je ne vais pas faire un cours car c'est exactement comme dans Future Pinball, donc je vous suggère de lire la doc et les tutoriaux des scripts FP pour voir comment on fait.

L'idéal, c'est de fabriquer un flip virtuellement avec Future Pinball, et une fois que vous êtes satisfait vous exportez le script et vous le compilez avec Pin²Ide et vous avec votre moteur de flip réel.

Il faut quand même ajouter des choses qui n'existent pas dans FP à savoir déclarer les switch, bobines et lampes physiques: dans FP c'est automatique, le fait d'ajouter une lampe sur le plateau virtuel va automatiquement créer un objet Lamp, mais sur un flip réel il faut créer manuellement cet objet Lamp en déclarant le numéro de la lampe.

Pareil pour les contacts, dans FP on a des objets "magiques" comme par exemple un Bumper, qui cache le fait que c'est une Lampe+Bobine+Switch, donc dans Pin²Ide il faudra créer un Bumper mais en donnant les numéros de la lampe, du switch et de la bobine physique.

en dehors de cette déclaration, le script est le même, il est donc très facile de convertir un script FP en script Pin².

Pascal

Madmax61 · Message par **Madmax61** » mar. 22 01, 2008 16:09

Je n'ai pas tout comprit mais votre projet à l'air de bien avancer et je vous en félicite !!!

J'espère ne pas poser des question déjà posée mais :
- Avez vous une idée pour la date de sortie de la première version finale ?
- Qu'avez vous prévu comme affichage ? de l'alpha numérique ou du dot ? ou encore un écran "classique" lcd ou crt ?

Que ferez vous de votre projet une fois fini ? commercialisation de flippers sur mesure ou commercialisation du projet ou projet "libre" distribué gratuitement à tous ?

Bon courage à ce beau projet !

romain · Message par **romain** » mar. 22 01, 2008 16:15

Madmax61 a écrit :Je n'ai pas tout comprit mais votre projet à l'air de bien avancer et je vous en félicite !!!

J'espère ne pas poser des question déjà posée mais :
- Avez vous une idée pour la date de sortie de la première version finale ? pas avant que ce soit terminé
- Qu'avez vous prévu comme affichage ? de l'alpha numérique ou du dot ? ou encore un écran "classique" lcd ou crt ? pour l'instant l'affichage sera fait sur le PC uniquement

Que ferez vous de votre projet une fois fini ? commercialisation de flippers sur mesure ou commercialisation du projet ou projet "libre" distribué gratuitement à tous ? aucune idée, nous y reflechissons; le but etant de permettre à tous de concevoir sa propre machine, il n'y aura pas de commercialisation de flippers.

Bon courage à ce beau projet ! merci!

romain · Message par **romain** » mar. 22 01, 2008 16:34

Pour ajouter mon point de vue technique sur ce qu'a dit Pascal :

les contacts directs n'étant plus indispensables, ils pourraient donc disparaitre ce qui permettrai, pourquoi pas, de doubler la taille de la matrice des contacts.

L'idée des flips gérés par la carte ainsi que les actions directes (slingshots, bumpers) a déjà été évoquée dans le sujet à propos de la matrice des contacts. C'est une idée excellente qui à mon avis changera tout dans le fonctionnement du flipper.
Cependant, ceci reste de l'optimisation et à ce propos il y a une citation que j'aime particulièrement : « Il faut oublier l'efficacité pour disons 97% du temps : l'optimisation prématurée est à la source de tous les maux. » (Donald E. Knuth)

Concernant l'interface, jusqu'à 8 circuits d'extension peuvent être adressés sur le bus I²C, ce qui fait 8x2 + 2 = 18 ports d'entrée/sortie de 8 bits chacun. Cette carte comporte déjà l'essentiel et ce qui fonctionne pour 2 circuits peut très facilement être étendu pour 8.
Je tiens à dire en plus, que les fonctionnalités offertes par une telle carte sont bien plus grandes que par une Driver de flip :
-gestions de servomoteurs, gestion de moteurs continus/pas à pas, reconnaissance de couleur, mesure de vitesse, calcul de distances etc....

Pour résumer : il n'y aura pas de limitation au niveau du PC comme l'a dit Pascal, il n'y en aura pas non plus pour la commande.

Chacun pourra donc en faire ce qu'il veut (même un flip méca si ça lui chante

).

Papo06 · Message par **Papo06** » mar. 22 01, 2008 16:44

Comme dit Romain: date de sortie inconnue, puisque je fais ça un peu le soir après le boulot quand j'ai 5 minutes et que j'ai quand même une vie à coté comme tout le monde.

Voyons déjà si on arrive à faire un truc simple, viable et qui marche

Pascal

damien d. · Message par **damien d.** » lun. 28 01, 2008 12:31

Ben c'est déja cool de voir que ca avance!

Merci Papo :)

Papo06 · Message par **Papo06** » lun. 28 01, 2008 15:43

Bon ce we j'ai vaguement fini une version utilisable du code du microcontroleur, j'ai bien galéré avec des comportements totalement aléatoires et du code qui faisait vraiment n'importe quoi jusqu'à ce que je comprenne que quand j'emet des octets via le buffer série le contenu du buffer se retrouve éparpillé un peu partout dans toutes les autres variables globales, le truc de fou, et en particulier dans le tableau des lampes

pourtant le code avait l'air correct sans dépassement des indices du buffer, le buffer est en bank1 les lampes en bank0, et je pense qu'il y a une chiure du compilo qui switche pas les banques entre elles et du coup fait n'importe quoi dans les interruptions, je viens de me farcir la doc complète apparement faut déclarer toutes les varibles globales en "volatile static" sinon ça chie, je vais retester ça ce soir pour voir si c'est mieux car pour l'instant j'ai diminué le buffer pour éviter les overlap mémoire mais c'est minable et indigne comme bug fix

Enfin bref, ça marchotte quand même, j'ai changé tout le protocole pour me simplifier la vie surtout pour que je puisse le tester via un terminal même sans programme juste en tapant les commandes au clavier et j'ai ajouté de quoi vérifier l'état des bobines, des switch et des lampes.

Sens PC => Pin², les commandes sont codées sur 2 caractères:

"x" est une valeur, entre 0 et 255 codé sur un octet

- "RZ" => reset, le hard répond "PIN2 RUNNING" quand il a fini son init.
- "cx" => change la valeur des 8 bobines du premier port par la valeur x
- "dx" => 2ème port = x
- "lx" => change l'état des 8 lampes de la 1ère colonne des lampes avec x
- "mx" => change les 8 lignes de la 2ème colonne avec x
- .... etc
- "sx" => change les 8 lignes de la 8 ème colonne de lampes
- "BxxxxxxxxB" => mode burst recharge d'un coup toute la matrice des lampes avec les 8 colonnes, plus efficace que 1 par 1 si plus de 4 colonnes à changer
- "LP" => demande le status des lampes, le PIC répond "LxxxxxxxxP" x étant le contenu des lignes de chaque colonne des lampes
- "CO" => demande le status des coils, le pic répond "CxxO", x étant la valeurs des 2 ports 8 bits donc des 16 bobines
- "SW" => demande le status des switchs, le pic répond "SxxxxxxxxW", donc toute la matrice des switch

Sens Pin² => PC

- Si demande de status des lampes (LP), le PIC répond "LxxxxxxxxP" x étant le contenu des lignes de chaque colonne des lampes
- Si demande de status des bobines (CO), le pic répond "CxxO", x étant la valeurs des 2 ports 8 bits donc des 16 bobines
- Si demande se status des switchs (SW), le pic répond "SxxxxxxxxW", donc toute la matrice des switch

Le seul cas où le pic envoie 2 caractères tout seul sans répondre à un ordre c'est sur le changement d'état d'un switch:

-"1x" => un switch a été modifié colonne 1, x valeur des lignes de cette colonne
-"2x" => un switch a été modifié colonne 2, x valeur des lignes de cette colonne
- ... etc
-"8x" => un switch a été modifié colonne 8, x valeur des lignes de cette colonne

La détection des switch fonctionne bien, les bobines aussi, les lampes également ainsi que la rotation de la matrice.

Dans cette version ça ne gère pas encore la luminosité lampe par lampe comme savent le faire les derniers wms (p2000) et les stern, j'ai commencé mais j'ai eu tellement de soucis de corruption mémoire à cause de ce buffer série à la con que j'ai perdu un temps pas possible.

D'ailleur faut que je réécrive ce buffer ça va pas du tout il est linéaire et ne tourne pas comme un buffer fifo.

Je me suis basé sur mon revenge pour les fréquences, les switchs sont scannés à 500Hz et la matrice des lampes tourne à 250Hz, j'ai réglé les timer pour avoir à peu près pareil.

Voilà avec ça déjà on peut mettre à jour les bobines, les lampes colonnes par colonnes ou une par une, vérifier l'état des switch des bobines et recevoir automatiquement les switch modifiés

La suite au prochain numéro

Pascal

Papo06 · Message par **Papo06** » mer. 30 01, 2008 11:35

Coucou,

Voilà j'ai terminé le copulage

ou plutôt couplage entre le hardware Pin² et le moteur de flip Pin²Ide.

Ca marche tellement bien que j'ai intégré aussi la gestion de la LUMINOSITE des lampes

, il est possible maintenant par programme d'indiquer une intensité lumineuse sur 4 niveaux (3+Off en fait).

Si "Lit" est positionné on peut régler la luminosité des lampes sur 0%, 30% 60% et 100%.

Ainsi même en laissant "Lit" allumé on peut gérer des animations avec effet de fondu comme les p2000 ou les stern en jouant sur l'intensité lumineuse, c'est rigolo et ça marche assez bien même si il n'y a que 4 niveaux je me suis amusé à faire un K2000 avec trainées ça marche bien.

Léger changement de protocole pour gérer la luma sur 4 niveaux il faut envoyer 2 matrices, chaque ampoule étant codée sur 2 bits

"Bxxxxxxxxyyyyyyyy"

x => bit poids fort, y = bit de poids faible

pour une lampe xy=00 => éteinte, xy=01 => 30%, xy=10 => 60%, xy=11 => 100%

J'ai également ajouté la gestion d'un timeout de transmission au cas ou, même si en pratique pour l'instant ça ne sert à rien j'ai aucun problèmes de corruptions visible sur le port série ni en entrée, ni en sortie.

Maintenant que ça tourne pas trop mal je vais optimiser un peu, booster le port série au maxi et tenter si le hard le supporte de passer le bus i2c en 400kbit aussi car il est à 100kbits et avec la gestion de la luminosité sur 4 niveaux ça quadruple le nombre d'écritures comparé à on/off sur le bus i2c et il est à saturation la matrice tourne à un peu moins de 150Hz environ, or si je veux passer à 8 niveaux off+7 (3 bits de luma par lampe au lieu de 2, donc 8 écritures i2c au lieu de 4) ça ralenti trop la matrice et on voit le balayage c'est pas beau ça fait tomber la rotation à 75hz environ. (pour rappel la matrice des switch tourne à 500Hz et les lampes à 220Hz sur un p2000)

Si luma sur 8 niveaux fonctionne j'ajouterais une 3ème matrice à transmettre au mode burst

"Bxxxxxxxxyyyyyyyyzzzzzzzz"

xyz = 000 = 0%
xyz = 001 = 15%
...
xyz = 110 = 85%
xyz = 111 = 100%

Mais tout ça c'est du détail, le principal est là: ça fonctionne très bien déjà comme ça

Pascal