www.flipjuke.fr

Bonjour,

après 2 ans de pause, le projet PIN² reprend son activité par un brainstorming sur les spécifications d'une troisième version.

Troisième déjà ? Eh oui ! après une V1 ayant servit à réaliser les premiers programmes et une V2 donc le fonctionnement au salon de Chailly 2008 a été un exemple, il est aujourd'hui temps de faire le point sur ce qui a fonctionné et ce qui a merdé , pour enfin (!) aboutir à la réalisation d'un vrai flipper.

Ce fil est dédié aux spécifications pour cette V3, toutes les idées sont les bienvenues. Avant toutes choses, je vous encourage tout de même à un peu de lecture :
Carte d'interface PIN² V1
Brainstorming : Interface PIN² V2

Voici, pour me citer, les raisons poussant à l'étude d'une V3 :

Romain a écrit:Aujourd'hui, il est nécessaire de repartir sur une phase de spécifications hardware/software en intégrant ce qui a été un peu mis de côté auparavant. Je pense notamment à la partie alimentation (on fait mieux que des transfos aujourd'hui...) et à la partie software sur PC. Le soft embarqué mérite d'être réécrit, et les cartes d'interfaces d'être un peu plus intelligentes (détection lampes, bobines grillées etc.).

Ainsi que la remarque de Pascal :

Papo06 a écrit:Le tout comme tu disais est d'avoir un vrai projet de flip et construire le soft déjà pour celui là ça serait un bon début

Bon allez faut bien commencer par quelque chose ...

Alors disons pour la cpu :
Mettre un pic 18F4550 (USB Natif) ... Version 40 broches car facile à monter sur support ou si vraiment besoin de plus de pattes ... 18F8722 mais la ... c'est moins facile à souder.
Prévoir la possibilité de programmer de "on board" serait bien.

(Sinon il y a Les DSPIC, mais + chers ...)

Bonjour,

Déjà la v3 ?

Pour la cpu, voire même beaucoup plus, pourquoi pas tout simplement un pc ?

Je ne parle pas de la tour stockée au fond la, qui fait 10 kilos hein ? je parle de carte mini itx par exemple

pourquoi ?

Parce que pour 100 euros, on a :

- l'alimentation,
- des tonnes de soft de developpement,
- un processeur puissant, surtout comparé aux 6502,6809,pic, etc..
- le son
- la video
- des interfaces de tout type : usb, reseau, wifi, ....

et ce ne sont que quelques avantages..

Alors bien sur il ne faut pas faire comme le regretté Williams qui n'a rien trouvé de mieux qu'une carte la plus incompatible PC possible.
Une carte PC, en plus c'est quasiment universel.

Voila, c'est mon avis..

Alain

flip78 a écrit:Alors disons pour la cpu :
Mettre un pic 18F4550 (USB Natif) ... Version 40 broches car facile à monter sur support ou si vraiment besoin de plus de pattes ... 18F8722 mais la ... c'est moins facile à souder.
Prévoir la possibilité de programmer de "on board" serait bien.

(Sinon il y a Les DSPIC, mais + chers ...)

Le problème de l'USB natif a déjà été évoqué, et ce dès la V1. L'isolation galvanique entre l'interface et le PC me semble indispensable. Depuis 2 ans, des opto-coupleurs USB ont vu le jour. Tu peux peut-être faire une veille technologique sur ces composants et nous donner des infos ?
J'avais l'intention de passer sur une archi 16bits (voilà qui va faire plaisir à pascal !) et je pensais justement aux dsPIC. Vu que l'objectif est pour le moment de faire une (1) machine, le coût n'est pas une grosse contrainte...

alain91 a écrit:Je ne parle pas de la tour stockée au fond la, qui fait 10 kilos hein ? je parle de carte mini itx par exemple

Es-tu bien au fait de ce qu'est le projet ?
L'objectif est de réaliser l'électronique (et le logiciel) pour pouvoir lire les contacts et allumer les ampoules du flipper à partir d'un PC (PINball Pc INterface=PIN²). Il y a donc un PC prévu, son format étant laissé libre (desktop, carte mini-ITX, portable, etc.)
Ce qu'on appelle la "CPU" sera une carte mère, basée sur un micro-contrôleur pour les tâches les plus simples et répétitives (balayer les matrices, piloter les bobines, etc.). Cette CPU sera pilotée par le PC via USB.

De toute façon il y aura autant d'avis que de personnes pour le choix du µC, 8, 16, 32 bits, en fait ça change pas grand chose on est pas dans le domaine du calcul, n'importe quel modèle rapide avec beaucoup d'E/S fera l'affaire, le plus possible d'ailleurs pour éviter d'avoir plein de circuits d'extension à gérer.

J'aime bien les atmel pour ma part pas trop cher et très performants, en version de luxe pour 50 euros il y a des cartes sympa toute faites exemple j'ai trouvé ça avec 80 E/S il y a de quoi faire 2 matrices de lampes (24 e/s), une matrice de switch (16 e/s) et il reste encore 40 e/s pour les flash/bobines. juste à faire un driver et pluger ce truc dessus:

http://www.myavr.info/download/produkte/myavr_stamp/techb_schaltplan-myavr-stamp.png

http://shop.myavr.com/Additional%20modules/myAVR%20Stamp64%20PLUS%20%28SMD%20equipped%29.htm?sp=article.sp.php&artID=100060

Mais bon, les pics sont plus connus donc ça fait moins peur, pour ma part ça ne change rien j'ai aucune religion, tout le monde programme en C de nos jours sauf les vieux réfractaires qui ne jurent que par l'asm alors quelque soit le modèle ça n'a pas d'importance :-)

quelques idées en vrac pour le soft du µc:

gestion complète de lampes et flash évitant au pc d'envoyer sans cesse la matrice, il configure juste le mode d'allumage (fixe / clignotant /etc, fréquence, luminosité min/max, rapport cyclique, etc)

gestion complète des bumpers, slingshot et doigts de flips, flash: on envoie simplement la conf au pic par bumper/slig/flip en associant une sortie solénoide à un switch et une ampoule (éventuellement) et il gère tout sans le pc, avec réglage de la dureté de l'impulsion fire et hold, idem pour les flash on peut imginer simplement envoyer une commande de conf indiquant sur si switch12 activé alors on flashera 3 fois à 5 hz la solenoide7. Le pc n'aura plus besoin de réagir forcément très vite aux switch grace à ça.

détection de pc 'mort' si plus de commandes reçues, la carte passe en mode standby et éteint toutes les lampes/flash/solenoides. détection des switchs coincés actifs, par exemple si on détecte un switch de bumper toujours actif alors que la commande de la bobine est coupée pendant plus de 1 seconde c'est qu'une bille est coincée dans le bumper ou que la bobine a cramée, idem avec le fin de course du doigt de flip (encore que celui là il est pas utile)

ça serait bien de pas avoir un port série trop limité en vitesse, quand j'avais fait des tests 115k c'était vraiment le minimum et encore, un port à 256kbit voir 512 ou 1mbit ça serait top.

etc...

Pascal

romain a écrit:

alain91 a écrit:Je ne parle pas de la tour stockée au fond la, qui fait 10 kilos hein ? je parle de carte mini itx par exemple

Es-tu bien au fait de ce qu'est le projet ?
L'objectif est de réaliser l'électronique (et le logiciel) pour pouvoir lire les contacts et allumer les ampoules du flipper à partir d'un PC (PINball Pc INterface=PIN²). Il y a donc un PC prévu, son format étant laissé libre (desktop, carte mini-ITX, portable, etc.)
Ce qu'on appelle la "CPU" sera une carte mère, basée sur un micro-contrôleur pour les tâches les plus simples et répétitives (balayer les matrices, piloter les bobines, etc.). Cette CPU sera pilotée par le PC via USB.

ok, je pensais que vous repartiez de zero

Alain

Bravo de continuer ce projet

Même si je ne participe pas au développement je vous lirai régulièrement.

Je fais travailler un groupe d'étudiants sur le contrôle d'un flipper avec une carte à microcontrôleur 18F2520 et I/O expander deux MCP23016.
Un IO expander c'est 16 E/S, nous en utilisons un pour les bobines et un pour les lampes.

Je suis habitué aux PIC mais des collègues m'ont fait découvrir un produit qui semble attractif, connaissez vous cette carte : LPC1768 ?

Intérêts : Outils de développement en ligne gratuits. Très grosses bibliothèques de fonctions, exemples multiples. Pas trop cher (environ 60euros TTC en France). Grosse puissance de calcul : ARM7 à 100MHz. Beaucoup d'E/S.

http://fr.farnell.com/nxp/om11043/kit-c ... dp/1761179

Le prix Farnel = 48,80 euros HT

Quelques caractéristiques :

* Convenient form-factor: 40-pin DIP
* Drag-and-drop programming, with the board represented as a USB drive
* Best-in-class Cortex-M3 hardware:
o 100 MHz ARM with 64 KB of SRAM, 512 KB of Flash
o Ethernet, USB OTG
o SPI, I2C, UART, CAN
o GPIO, PWM, ADC, DAC
* Easy-to-use online tools:
o Web-based C/C++ programming environment
o Uses the ARM RealView compile engine
o API-driven development using libraries with intuitive interfaces
o Comprehensive help and online community

Dimensions: 44mm x 26mm

http://www.coolcomponents.co.uk/catalog ... 1e7a9d7598

Papo06 a écrit:[...]Mais bon, les pics sont plus connus donc ça fait moins peur, pour ma part ça ne change rien j'ai aucune religion, tout le monde programme en C de nos jours sauf les vieux réfractaires qui ne jurent que par l'asm alors quelque soit le modèle ça n'a pas d'importance :-)

N'oublions pas que le développement n'est pas forcément lié au hardware. Les périphériques sont souvent ressemblants sur les petits µC, ce qui facilite la portabilité. Aux développeurs d'anticiper ce point lors de l'écriture du code (une petite couche HAL/drivers serait suffisante).

Papo06 a écrit:quelques idées en vrac pour le soft du µc:[...]

Merci pour ces suggestions. Avec Damien c'est effectivement ce qu'on avait relevé comme principales limites à la V2. La liaison série était très (trop?) chargée par des infos redondantes (matrice des lampes), ce qui retardait d'autant les actions sur les bobines/flashs.
L'automatisation switch/bobines est une excellente idée (et a d'ailleurs été utilisée à Chailly 2008, en tant que patch à cause de la forte latence du PC). Cependant son implémentation devra être judicieuse, le firmware de la carte d'interface ne devant pas être spécifique à une machine selon moi.

Pour l'interface USB, certains transceiver USB/UART sont paramétrables jusqu'à 1Mbps. Le software sur PC doit cependant utiliser directement le driver et non plus un port série émulé. Une petite recherche peut aussi être faite pour connaître les débits espérés avec un µP USB natif.

fred_c a écrit:Bravo de continuer ce projet

Merci Fred J'y consacrerai cependant moins de temps que pour les deux premières versions. Si des membres du forum souhaitent s'y investir, ce projet pourra continuer.

Elle est sympa cette carte, ça ressemble très fortement à la fameuse BeagleBoard, en moins couillue. On programme en natif là-dessus (pas d'OS) ?
Reste à voir si ça correspond à nos contraintes/besoins pour la V3 (contraintes à définir d'ailleurs, qui s'en charge ?).

Regardez aussi la carte que j'ai citée plus haut, elle dispose d'une palanquées d'e/s (80) et pas cher non plus 49 euros ttc avec même un lecteur microsd.

Pascal

romain a écrit: le firmware de la carte d'interface ne devant pas être spécifique à une machine selon moi.

N'y a t'il pas moyen d'uploader le firmware a chaque boot, afin que le dévellopement de l'appli sur le PC soit totalement transparent avec celui du firmware?
Je m'explique, dans le script qui gère les règle sur le PC, on dit :
Bumper 1
{
contact = 34
bobine = 45
]
flipper gauche
{
contact de caisse = 11
contact de fin de course = 23
bobine puissance = 17
bobine maintient = 18
}

dans une sorte de fichier .ini et tout ceci est réenvoyé au µC, a chaque boot du flip?