PIN² : Vos remarques et idées

[ax879456]

merci de rester dans le constructif et de rester dans le thème du sujet ...
:-*:

[damien d.]

Hééé, c'est moi l'modo ici!!!

"Merci de rester dans le thème du sujet!"

[pascal j]

voici ce que j'ai trouvé sur un site américain style "system D" :

http://store.makezine.com/ProductDetail ... MKCONTRLLR

http://store.makezine.com/ProductDetail ... MKARDNGUSB

ça a l'air d'être des petits cartes multi-I/O USB à tout faire, et en opensource !

[pascal j]

la photo de la 2è carte..

[romain]

Salut Pascal,

elles ont l'air sympa ces cartes et elles ne sont pas trop chères qui plus est !!
Pour ceux qui ont l'oeil, vous avez remarqué quel composant CMS est à côté de la fiche USB ?? oui, oui un FTDI !

Ce sont des cartes à base de processeurs à coeur ARM, la programmation est bien plus compliquée que sur PIC, mais les performances ne sont pas comparables La programmation se fait par bus JTAG, il faut donc compter le programmateur USB en sus je présume...

En revanche, pour atteindre plus d'une cinquantaine de sorties, il va en falloir des cartes !! bien que ce genre de processeurs en ait plus d'une centaine, c'est étrange...

merci Pascal pour l'info !!

[pascal j]

de rien Romain ! j'ai pensé que ça vous intéresserait peut-être, au moins au début pour valider rapidement la faisabilité du projet en utilisant des cartes déjà toutes prêtes sans trop se casser la tête sur tous les sujets à la fois.

oui la puce FTDI (que je connaissais aussi et ai failli utiliser au boulot) a l'air d'être un best-seller. à mon humble avis les gens l'emploient car les pilotes sont dispo sur leur site, donc pas de programmation d'interface USB compliquée (même pour faire un HID il faut pondre un peu de code) à faire ni du côté du micro ni du côté PC. ça compte énormément ! maintenant, il faut quand même un port USB ou SCI sur le micro lui-même, ou à défaut émuler la liaison série avec un timer (basse vitesse donc).

tu as parfaitement raison, c'est étonnant que vu le nombre d'I/O dispo, il n'y en ait pas plus de "tirées" sur le PCB. mais peut-être que l'examen d'une vraie carte apporterait pas mal de réponses ? si ça se trouve les signaux non utilisés sont routés vers un connecteur qu'on ne voit pas sur la photo :

[romain]

de rien Romain ! j'ai pensé que ça vous intéresserait peut-être, au moins au début pour valider rapidement la faisabilité du projet en utilisant des cartes déjà toutes prêtes sans trop se casser la tête sur tous les sujets à la fois.

le plus dur est de concevoir totalement une carte en ne partant de rien (c'est pas à toi que je vais apprendre ça )
Maintenant que ma carte est réalisée, le reste n'est qu'extension... ainsi, que j'ai 2 circuits d'extension ou 8 ça ne change plus rien car j'ai réalisé mes fonctions de dialogue de façon générique !!
La carte que j'ai avec moi aujourd'hui est donc totalement équivalente à cette carte à vendre. A la seule différence : le prix... (et les capacités de calcul OK... )

oui la puce FTDI (que je connaissais aussi et ai failli utiliser au boulot) a l'air d'être un best-seller. à mon humble avis les gens l'emploient car les pilotes sont dispo sur leur site, donc pas de programmation d'interface USB compliquée (même pour faire un HID il faut pondre un peu de code) à faire ni du côté du micro ni du côté PC. ça compte énormément ! maintenant, il faut quand même un port USB ou SCI sur le micro lui-même, ou à défaut émuler la liaison série avec un timer (basse vitesse donc).

en effet la marque FTDI est LA SEULE référence en la matière. C'est une puce utilisée dans TOUS les cables de conversion USB-R232 et dans de nombreux programmateurs de PIC USB.
Au pire, pour un matériel ne possédant las de port USB, je pourrai réaliser une petite carte avec un MAX232 ou 233 à brocher à la place du convertisseur. On pourrait ainsi relier la carte à un port COM normal.

tu as parfaitement raison, c'est étonnant que vu le nombre d'I/O dispo, il n'y en ait pas plus de "tirées" sur le PCB. mais peut-être que l'examen d'une vraie carte apporterait pas mal de réponses ? si ça se trouve les signaux non utilisés sont routés vers un connecteur qu'on ne voit pas sur la photo :

je ne sais pas, sur les cartes de développement (plus de 300€ pièce) que nous avons à l'école (et sur lesquelles on a eu l'occasion de se faire la main) il devait y avoir... 5-8 ports 32bits de mémoire. Je pense que ces processeurs sont montés sur un mini PCB autonome qui lui peut-être branché sur une carte plus grande, utilisant ou non toutes les pattes du CI. On dira qu'après il suffit de changer la carte hôte ! (ce qu'avait fait le club robot car la carte de développement était trop grande pour eux, ils en ont réalisé une toute petite mais très limitée).

[stephxi]

A tous les participants,
Belle chose que de vouloir remplacer l'électronique par l'informatique. En effet, l'informatique de nos jours est synonyme d'efficacité et de robustesse (les composants aussi).
Enfin, bien que je suis totalement dépourvu de connaissances de développement, j'ai aimé la simple idée du clavier (255 possibilités). Moui, c'est vrai que le pilote du clavier ne sait pas gérer les accès simultanés, en revanche son buffer (vitesse de tape) peut peut-être aider.
J'ai moi-même une idée. Certes, certainement saugrenue, toutefois, avez vous penser à l'utilisation d'une base de données ? Vu de ma paroisse, je vois les choses comme cela
- Contact émis, se transforme en une requète
- La requète s'execute dans la DB et apporte le résultat (action)
- le résultat s'exécute (lumière, points.....).
Avec ce principe, nullement besoin d'une routine circulaire de recherche de changement des contacts (un peu comme le Token Ring : réseau IBM), mais, bel et bien de l'évenementiel.
Voilà, peut être que cela pourra vous aider et surtout sans remettre en cause le hardware si durement étudié.

[damien d.]

Merci pour les encouragements!

Mais le problème du clavier, et d'un flipper, viens du fait que pas mal de contacts sont naturellement normalement fermés, par exemple, le chargeur.
Un clavier ne suporte pas l'appuie de 3 touche simultanées, autant dire qu'avec un jeu a 3 bille, l'appuie du bouton start sera inhibé! (c'est ballot).
Et donc, il n'y aurai pas d'évenement du tout....

Apres au niveau de la gestion de la chose sur le PC c'est en effet une possiblitié a entrevoir.

[romain]

Salut,

la carte d'interface à base de microcontrôleur et la liaison USB permettent absolument tout type de fonctionnement software derrière, c'est le but.

Ton idée est bonne, mais j'avoue ne jamais m'être penché sur le problème de cette manière, mais tu as raison : le mode de programmation doit être bien plus simple pour qui ne connait rien à l'informatique.
Cependant, ceci relève du fonctionnement de Haut Niveau et en aucun cas de l'interface avec le matériel.

Je réexplique la différence : le programme bas niveau se charge de dialoguer en direct avec la carte branchée sur le flipper. Ce dialogue est lourd et fastidieux à gérer et sa connaissance est absolument inutile pour l'utilisateur lambda (comme on se fout du kernel windows quand on surf sur le net).
Ce programme rapatrie donc toutes les infos de la carte vers le PC qui peuvent alors être traitées par n'importe quel logiciel ou programme fait maison.
Or aujourd'hui il n'existe tout simplement pas ! son rôle est donc joué par Vpinmame pour l'instant.

Si tu t'y connais en programmation évènementielle, on pourrait approfondir le problème et trouver un environnement de programmation adapté et une BDD efficace (MySQL for example...).

Avec ce principe, nullement besoin d'une routine circulaire de recherche de changement des contacts

indispensable lors de contacts matriciels, mais l'interface de bas niveau peut générer une interruption si un contact est détecté modifié... :-°: ce qui reviendrait sensiblement au même.