Brainstorming : Interface PIN² V3

[Papo06]

Oui c'est exactement à ça que je pensais, en gros, implémenter les classes bumper, flash, lampe, ejecteur, slingshot, etc dans le pic au lieu que ça soit le pc qui émule ces blocs comme c'était le cas dans le tout premier proto que j'avais fait, il y a juste à initialiser chaque ensemble et le µc les gèrerait de façon autonome, c'est très facile à faire, c'est juste une question d'avoir assez de cycles pour pas tout ralentir.

Avec le cpu d'origine il n'y avait pas assez de puissance pour faire trop de truc entre 2 balayages de matrice switch mais si vous partez sur un µc pas trop sous-dimentionné on peut faire énormément de choses.

Autre idée des optimisations comme par exemple bufferiser l'envoi des switch: imagine 2 billes qui rebondissent entre des bumpers très vite, avec la version actuelle il me semble que le µC envoie chaque switch quand il s'active, il se peut qu'on ait des séquences du style sw1, sw2, sw1, sw1, sw2, sw1, sw2, sw2, etc dans un laps de temps très court voir même plusieurs fois le même switch à la suite (si sw1 c'est un bumper et sw2 un autre), dans ce cas, au lieu d'envoyer N fois chaque fois que le switch est activé on envoie le n° de switch et le nombre de fois où il a été activé depuis les dernière 250ms (au pif j'en sais rien c'est juste pour donner une valeur faudra trouver une valeur ni trop grande, ni trop petite, mais 1/4s ça me parait un bon début), imagine la même séquence que précédemment sur 0,5s ça donne: [0s]sw1:3, sw2 [250ms] sw2:3, sw1 [500ms] on envoie que 4 octets au lieu de 8 : on encode le N° de switch sur les bits 0-5 (1 à 64) et le nombre sur les bits 6 et 7 (1 à 4) et si ça dépasse 4 appuis tant pis en renvoie un octet avec la suite, mais ça devrait pas arriver trop souvent.

J'avais été assez déçu aussi par les perfs de l'i2c, c'est vachement couteux comme protocole en cycles d'horloge, la gestion des 2 extensions 16 e/s bouffait aussi pas mal de ressources, alors plus il y a de sorties natives sur le µc, mieux c'est (en même temps sur on passe d'un 16877 à 5mips à un arm à 100 mips c'est plus la même histoire :-) )

Pascal

[damien d.]

Ouip, ca me parait être une vachement bonne idée pour l'optimisation que de regrouper ensemble ("au même instant t" ) tout ce qui se passe en fait en t+ "temps imperceptible pour un humain".

[flip78]

Bonjour,

J'avais été assez déçu aussi par les perfs de l'i2c, c'est vachement couteux comme protocole en cycles d'horloge, la gestion des 2 extensions 16 e/s bouffait aussi pas mal de ressources, alors plus il y a de sorties natives sur le µc

J'ai constaté exactement la même chose sur un proto que je réalisais : les MCP23017 sont trop lents pour certaines applications.
(Du coup j'ai du revoir complètement mon proto en utilisant un technologie + viellotte mais terriblement efficace : Une eprom pour faire un encodeur ultra rapide 2*8 segments -> 2*4 bits dans un projet d'affichage en sortie des cartes CPU GTB.)

J'ai vu les 2 cartes présentées, effectivement il y a du potentiel !
Si malgré tout il manque des I/O ... On pourra toujours en ajouter mais de préférence avec des latches paralleles !

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? ...
dans une sorte de fichier .ini et tout ceci est réenvoyé au µC, a chaque boot du flip?

Bonne idée : En plus avec avec la carte présentée par pascal ... Il y a une MicroSD ... On pourrait même stocker cela dedans.
Il faudra (juste ) écrire un analyseur de syntaxe (Sans tomber dans lex & yacc ...) pour 'digerer' le fichier de configuration (.ini), avec affichage d'une led en cas d'erreur d'interprétation ! (Le même programme devra être dispo sur le PC pour afficher les lignes en erreur : Si on choisi le 'c' comme outil de dev ... ce sera simple à porter de l'un à l'autre).

Tu peux peut-être faire une veille technologique sur ces composants et nous donner des infos ?

Avec plaisir !
Après recherche ... Il en existe quelques uns ... Le problème étant plutot la disponibilité pour le grand public :
Par exemple celui ci : ADUM4160BRWZ
http://fr.farnell.com/analog-devices/ad ... dp/1858056
Je n'ai pas mieux pour le moment ... Et encore faut voir la disponibilité ! (Pas en stock en ce moment )

Cependant ... Je ne suis pas persuadé que cette isolation galvanique soit nécéssaire ... si l'on regarde les cartes présentées par pascal et fréderic ...
USB direct !

A suivre ...

[damien d.]

Bonne idée : En plus avec avec la carte présentée par pascal ... Il y a une MicroSD ... On pourrait même stocker cela dedans.

Oué, mais si il faut enlever la MircoSD, copier le fichier dessus, remettre la MicroSD a chaque modification du bidule, bof bof l'ergonomie.

Je ne suis pas persuadé que cette isolation galvanique soit nécéssaire ... si l'on regarde les cartes présentées par pascal et fréderic ...
USB direct !

Ben oui mais ces cartes ne sont pas forcément conçue pour piloter tout un tas de bobines, parceque bonjour les parasite.
Sachant que, j'en ai fait l'experience, le simple fait de poser un camescope numérique sur le cable de mon clavier USB arrive a générer des tas de comportement incohérant due au interférences

[Papo06]

Mais non tu peux peux programmer le µc directement via le port usb et ils contiennent tous des eeprom c'est à dire que tu peux envoyer la config une fois et la stocker dans l'eeprom. (la gestion du outhole/stockage peut aussi être automatisé dans le µc, en fait on peut lui faire faire pas mal de macro-fonctions autonomes sans qu'il ait besoin de discuter avec le pc, du coup le pc se contente de gérer le son, les animations, les scores, le changement de joueur, etc mais ne s'occupe plus de faire clignoter les lampes, ni gérer les bumper, les flips, etc etc il reçoit juste les infos des switch actif et envoie quelques commandes comme flips on/off, commande les séquences des lamps mais pas leur clignottement, le µc peut même gérer tout seul un ball saver par exemple c'est basique comme fonction, etc...) le lecteur sd j'avoue que ça servirait à rien (avec 64k voir 512k de flash sur les µc cités + des eeprom de 2ko, on peut mettre un paquet de trucs sachant qu'on gère ni les afficheurs, ni le son ! voir même initialiser les blocs logiques à chaque boot depuis le pc ça coute rien du tout donc même sans eeprom et même sans lecteur sd ça revient au même.

je pense qu'il faut surtout partir sur un cpu qui patate et qui a le plus d'i/o possibles, peu importe la marque, quand tu regardes un peu les datasheet ils offrent tous les mêmes fonctionalités même trop pour ce qu'on veut faire avec, st, atmel, arm, pic, motorola, que sais-je encore le principal c'est la vitesse et les e/s, les cartes citées ont l'avantage du tout-en-un avec des connecteurs pour les sorties, c'est assez tentant, le prix peut paraitre cher mais bon, 50 euros c'est pas énorme non plus.. sauf si t'en crame 10 à la suite

flip78 je suis assez d'accord avec toi, un latch ça patate le problème c'est le nombre de pistes à tirer en bus, 8 + les fils de chip select, c'est nettement plus chiant pour le pcb.

Pascal

[romain]

Salut tout le monde,

certaines des cartes proposées sont très puissantes et ont un nombre d'IO plutôt conséquent, mais cela correspond-t-il aux contraintes (qui restent à définir, personne ne s'y penche) ?
Le fait d'avoir de telles cartes pousse d'après moi à utiliser un petit OS embarqué (ou pas). C'est pas que j'y suis réfractaire, mais est-ce qu'on a besoin d'un linux pour balayer 2 matrices ?
Pour le grand nombre d'IO, il y a plein d'avantages : un seul circuit logique (pas de circuits d'extension), une rapidité maximale, et une sécurité en fonctionnement très intéressante (pas de bus). Dans les inconvénients je vois que ça oblige à sortir des montagnes de lignes (fils) pour aller sur les cartes driver.... à étudier.

En solution, le MCP23S17 (SPI) est très intéressant, car beaucoup plus rapide (SPI) que le 23017 (I²C). En contrepartie, le bus chainé n'es plus envisageable. Les cartes filles devront être câblées (SPI) en étoile autour de la carte principale (seul inconvénient).

Pour la carte SD, même réponse que pour l'OS si c'est pour charger un tableau de correspondance avec 10 switchs et 10 bobines... .
Je préfère par exemple déclarer un char[10] et le charger via UART, plutôt qu'un FS FAT32, mount, ouverture du fichier, un parser (XML soyons fou) pour au final charger un tableau ^^. Bon après, si c'est pas moi qui le code vous faites ce que vous voulez

Après recherche ... Il en existe quelques uns ... Le problème étant plutot la disponibilité pour le grand public :
Par exemple celui ci : ADUM4160BRWZ
http://fr.farnell.com/analog-devices/ad ... dp/1858056
Je n'ai pas mieux pour le moment ... Et encore faut voir la disponibilité ! (Pas en stock en ce moment )

Ce circuit est un opto numérique apparemment... L'idée c'était de trouver des optos USB. Je te laisse nous trouver ça .

Damien, si on se penchait plutôt sur le "but" de cette V3 ? Je te laisse le soin de nous récapituler ce que tu envisages niveau plateau/méca; nous adapterons l'interface en conséquence !

[flip78]

Bonsoir Romain,

Le circuit cité est bien un isolateur opto usb ...
http://www.analog.com/en/interface/digi ... oduct.html
(Je n'ai pas vraiment trouvé autre chose et pourtant j'ai cherché ... mais ils ne sont pas nombreux ceux disponibles ... et à l'unité !)

J'ai déja essayé le MCP23S17, c'est clair que cela va plus vite que l'I2C, un bon compromis serait d'avoir les switch matrix en direct sur le micro-controleur, et les lampes et solénoids sur des MCP23S17. (Inconvénient = plein de fils qui reviennent vers la cpu, avantage, vitesse de lecture).

Pourquoi dis-tu que le MCP23S17 ne peut être mis en bus chainé ? Il se comporte comme l'I2C avec ses 3 entrées de sélection d'adresse.
(Il y a certes une init particulière pour profiter de ces 3 bits d'adresse, sinon tous les circuits répondent en même temps)

Et oui d'accord aussi avec papo06 ... des cpu qui on la pêche et des i/o y'en a quelques uns ... et en plus ils sont sur-vitaminés en flash et eeprom ...
Mais l'avantage d'une carte 'toute faite' ... est qu'elle est justement toute faite ... pas besoin de circuit imprimé galère a tirer ... qaund au cout de revient faut voir : à 50 euros la carte ... Faut faire le calcul du prix du micro + C.I + periphèriques ... on risque de ne pas être très loin des 50 euros).

A+

[damien d.]

Damien, si on se penchait plutôt sur le "but" de cette V3 ? Je te laisse le soin de nous récapituler ce que tu envisages niveau plateau/méca; nous adapterons l'interface en conséquence !

Ho non m'implique pas la dedans, j'était si bien moi a glandouiller a coté

[romain]

Je crains qu'il n'y ait pas de notion d'adressage série en SPI. Il y a en revanche un signal "chip select" qui doit être envoyé indépendamment à chacun des circuits. La topologie est donc en étoile, vu qu'il faut autant de "CS" que de chips (à moins de véhiculer 20 "CS" dans un câble).

En ce qui concerne de tirer des CI, cela ne me pose aucun problème. S'il y a des alternatives, pourquoi pas mais il faut se poser les bonnes questions : à quoi ça sert d'avoir une carte ARM avec 50 I/O ? il faudra bien faire une carte d'interface de toutes façon...

Après une petite visite sur Nice (merci à Pascal & Michel pour leur accueil), Papo06 et moi avons eu l'occasion de discuter de PIN² de vive voix. Ce qu'il en est ressorti c'est qu'il faut avant tout faire simple et fonctionnel, on verra pour les améliorations plus tard : si elles sont vraiment indispensables.

Si on définissait la base, le nécessaire pour commencer ? =)

[flip78]

Je crains qu'il n'y ait pas de notion d'adressage série en SPI. Il y a en revanche un signal "chip select" qui doit être envoyé indépendamment à chacun des circuits. La topologie est donc en étoile, vu qu'il faut autant de "CS" que de chips (à moins de véhiculer 20 "CS" dans un câble).

Le MCP23S17 a bien un chip select, mais il peut être commun à 8 circuits MCP23S17.
L'adresse de réponse de chaque circuit est fixée par les 3 les 3 bits A2...A0, exactement comme en I2C.
Il faut impérativement initialiser le registre IOCON.HAEN pour profiter de ce décodage d'adresse interne.
Du coup il ne faut que 4 fils (Contre 2 en I2C) pour communiquer en SPI avec 8 MCP23S17. (Soit un total 128 I/O ... cela devrait suffire, sinon on véhicule 2 Chip Select !)

Il faut des Chips Select distincts si on utilise d'autres circuits que les MCP23S17, ceux qui n'ont pas ces 3 bits d'adresse.

En fait de combien de ciruits aurait-on besoin ?
2 pour la matrice de contact (16*16) = Matrice 128 contacts.
2 pour les lampes (16*16) = Matrice 128 lampes.
2 pour les bobines = 32 bobines sans multiplexage ?
1 pour les lampes flash = 16 lampes sans multiplexage ?
1 pour ... ???? = 16 I/O
-> Ceci est une suggestion ...