Tag Archives: interface

Windows 8 m’a tuer !

Dans ce post, avec une pensée émue pour les utilisateurs, j’aimerais parler d’un point que je pense important pour Windows 8 et son succès, histoire d’éviter le Vista Effect.

Lorsque j’ai installé le système il y a une semaine, la seule formation que j’ai eue en démarrant Win8 concerne son utilisation tactile et les principales gestures. Et c’est tout ce qu’aura un end-user “non informaticien” et découvrant Metro avec son nouveau PC et Win8 en OEM. On se serait au moins attendu à de l’aide contextuelle désactivable à tout moment et mettant en avant les fonctionnalités disponibles. (+/- dispo., mais insuffisant…) Je ne pense pas que les utilisateurs irons passer une aprem’ à lire la philo Metro et faire des labos Win8 pour comprendre comment fermer une application ! Cette simple action, ainsi que le retour au start menu ont demandé à certaines de mes connaissances jusqu’à 20 minutes pour trouver “intuitivement” ! Pour fermer une application on doit prendre le dessus de la fenêtre en full screen et la tirer en bas dans une zone de “fermeture” de sensibilité configurable. Hé oui, plus de petite croix 😉 Et c’est ainsi que seront “largués” la plupart des nouveaux user win8 qui l’obtiendrons via OEM.

Le titre de “Windows 8 m’a tuer” concerne surtout mon poignet droit. Les gestures tactiles à reproduire à la souris sur un dual screen “unifié” 2*24″, même avec une souris très sensible, et on se tue à la tâche. A se demander si l’OS est toujours pensé pour la souris ?

On reconnait tous devant Windows 8 un changement radicale dans l’interaction avec Windows qui rompt avec certaines traditions vielles de 20ans sur les systèmes Windows. Mais est-ce que les utilisateurs s’adapteront à ces changements sans un accompagnement solide ?

Dossier : Reverse engeneering de manette Nes/Snes

Salut à tous, aujourd’hui un peu d’électronique avec un dossier sur le fonctionnement des controllers nes et snes. Le but final étant de l’interfacer en usb (objet d’un prochain article).

La nes

D’abord, ouvrons le controller et voyons ce qui se trouve dedans (désolé pour la qualité des photos, je vais demander à une amie avec un bon appareil si elle veut bien les refaire, mais attendant, faut faire avec ^^):


Bon, rentrons un peu dans le détail…

Le controller se compose de 4 boutons (A-B-Select-Start) et d’une croix multi directionnelle de 4 boutons aussi (haut-bas-droite-gauche) ce qui nous mènent à 8 boutons en tout. Assez joli, ce contrôleur est en plastique gris et noir, bouton rouge, très bien assortit à votre salon… Alors, première précision, un gamepad (ou controller ou manette de jeux) est un élément qui la plupart du temps pourrait être qualifié de « passif », mais j’y reviendrai plus tard.

Coté chip, il contient registre à décalage de 8 bits (4021 8 bit shift registre). Un article sur les registres est en préparation si vous ne savez pas ce que c’est, mais retenez basiquement qu’il s’agit d’un élément capable de stocker une valeur de 8bit. Dans notre cas chaque bits correspondra à l’état d’un bouton. Ainsi 0 signifie que le bouton est relâché et 1 qu’il est enfoncé.

Ensuite concernant les connections, on a un port de 7 fils. Voici la fonction de chacun :

Alors les ports 1 à 4 ne sont pas intéressant en soit. Ce qui l’est plus sont les ports 5 à 7.

Le port 5 sert à synchroniser la console et le gamepad, le port 6 sert à envoyer une demande et le port 7 à répondre. J’en vois qui sont perdu alors un exemple sera plus clair;

Comment la console connait-elle l’état de la manette ?
Et bien déjà on sait qu’on peut stocker tout l’état de la manette sur 8 bit. Chaque bit représentant un bouton. Voici l’ordre des boutons:

Définissons que 1 = off et 0 = on .
La valeur 10111101 signifie : Bouton B et bouton gauche enfoncé
De même 01011111 Signifie : A + Select ^^

Ensuite, une chose doit être bien claire; Contrairement à ce qui pourrait se concevoir dans l’imaginaire collectif, ce n’est pas la manette qui « donne les boutons à la console ». C’est la console qui demande à la manette son état qui lui renvoi ensuite là un buffer, dans notre cas, un buffer de 8 bit stocké dans le registre 8 bit.

Maintenant que le décor est planté, la console veut donc connaitre l’état de la manette.

La console va envoyer un signal sur le Latch. Cela va ordonner au Controller de stocker dans son registre l’état des boutons.

Ensuite la NES va envoyer 8 signaux haut sur la clock. A chaque signal le contrôler va renvoyer une réponse à la NES sur DATA « l’état du bouton suivant » avec un signal haut si le bouton est relâché et un signal bas sur le bouton est pressé. (En fait le bit en tête du registre vu que c’est du shifted, la notion de bouton suivante étant une vue de l’esprit)

Voici un chronogramme qui résume tout cela :

Et le schéma de connexion du 4021 :

Et pour la snes ?

Coté connectique on reste sur du 7 fils dont 5 utilisés :

Coté registre on passe de 8 à 16bits (plus de boutons ^^)
Il s’agit en fait 2 registre 8 bits en parallèles.

Et sur l’ordre des impulsions :

Conclusion

Voila, s’en est tout pour aujourd’hui. On se retrouvera bientôt pour un article sur le en555, les registres et un sur l’interfaçage en usb de ces deux controller.

Je projette aussi de faire le même reverse sur les controller megadrive, n64 et gamecube.

@ bientôt et n’hésitez pas à poser vos questions

Source

Nes : mes yeux et ma tête.
Snes (pas sous la main donc pas de teste possible…) : http://www.repairfaq.org/REPAIR/F_SNES.html#SNES_003
DataSheet 4021 : http://www.datasheetcatalog.org/datasheet/rohm/bu4021b.pdf
Les diagrammes ont été réalisé avec SDS3.
Les photos et les diagrammes sont sous licence CC by-nc-nd (pas d’utilisation commerciale, obligation de citer l’auteur et pas de modifications)

Les interfaces en Java

Voici un petit cours/tutos sur les interfaces en java. Le but n’est pas d’expliquer en profondeur le fonctionnement des interfaces, cela ayant déjà été fait par pas mal de gens.Pour la théorie je recommande deux ouvrages, le premier, chez Eyrolles, “Programmer en Java” de Claude Delannoy, Ingénieur au CNRS, dans la collection BestOf. Une véritable bible du développeur Java à petit prix (800 pages, 19 € prix couverture) déjà vendu à 250 000 exemplaires, traduit en plusieurs langues (ce qui est remarquable pour un livre technique de ce type). Ce serait un crime de ne pas se jeter dessus. Un second, plus générique, toujours chez Eyrolles, “La programmation Orientée Objet, Cours et Exercices en UML2, Java, C#, C++, Python, PHP et Linq” par Hughes Bersini, Ingénieur physicien et Directeur du Laboratoire sur l’intelligence artificielle à l’ULB (Université Libre de Bruxelles), un pédagogue exceptionnel et ouvert que j’ai d’ailleurs eu l’occasion de rencontrer il y a quelques mois dans le cadre d’un salon sur le logiciel libre. 600 pages +/- à 35 € prix couverture. Bon, ceci étant dit, je pars du principe que la théorie de l’héritage, le polymorphisme, l’abstraction et les règles de bases qui sous-tendent l’OO sont connues (pas forcément maîtrisées). Passons au but de l’article, montrer en quoi les interfaces sont réellement un outil/concept utile à la conception d’un logiciel et offre une réelle abstraction supplémentaire par rapport aux classes abstraites et à l’héritage de classes abstraites. En effet, à la lecture de beaucoup de cours, les interfaces sont souvent très bien expliquées dans la théorie mais pas dans la pratique, ce qui, au final, donne la sensation au lecteur qu’une interface est juste une classe abstraite sans l’implémentation des méthodes de classes.
Pourquoi ? Voici un exemple standard vraiment simple qui ressort dans presque tous les cours/tutos :

Humain.java :

Garçon.java :

Main.java :

Cet exemple est tiré directement d’un cours, considéré comme une référence, paru chez O’reilly (comme la plupart de leurs livres). Ceci ne montre rien des interfaces à part le fait que l’on implémente une interface Humain dans Garçon et que l’on redéfinit la méthode d’interface respirer() dans Garçon. Ensuite on crée un objet Garçon(), nommé Jean puis, on fait respirer Jean. Dans cet exemple, la plupart des lecteurs se disent : “Un Garçon est un humain et il respire… Ok… Mais moi dans mon code, vu que tous les humains respirent, garçons ou filles, et de la même manière, je ne vais pas redéfinir la méthode respirer chaque fois, ça ne me sert a rien ! Hum… Je vais plutôt faire une classe abstraite Humain et Garçon héritera de Humain !” Et cette réaction est légitime, car en effet cet exemple (et la plupart de ceux que l’on trouve) est dénué de sens pour quelqu’un qui aborde le sujet et sort en général du chapitre sur les abstractions. (Dans tous les livres que j’ai, quel que soit le langage, si on parle d’abstraction, le chapitre suivant sera 9 fois sur 10 les interfaces…).

J’ai donc fait un exemple pour rendre justice aux interfaces et que vous compreniez en quoi la redéfinition de méthode est vraiment utile. Voici la situation à modéliser.

“Je veux un tableau d’objet, ces objets seront des êtres vivants, je veux pouvoir les faire mourir et ressusciter selon le type d’êtres vivants.”

Un besoin très simple, J’ai donc une interface Vivant, cette interface a 3 méthodes, la première retourne une valeur booléenne sur l’état de l’être (true ou false), la seconde le tue, la troisième le ressuscite. L’interface est donc un dénominateur commun de méthodes à tous les êtres vivants. Maintenant il faut implémenter cette interface. Nous allons créer basiquement deux classes, Humain et Chat. Sur ces deux types d’êtres vivants on peut implémenter sans aucun souci les comportements demandés dans le besoin et définis dans l’interface. La où la redéfinition, grâce aux interfaces, sera utile, c’est au niveau de la résurrection. En effet, un humain ne peut ressusciter (ou alors il faudrait créer une classe supplémentaire Saint), par contre un chat a plusieurs vies, on peut donc dire qu’il peut “ressusciter”.

Voici le code que l’on obtient avec l’utilisation correcte des interfaces pour ce besoin :

Vivant.java :

Humain.java

Chat.java :

Main.java

Alors, pour le code de l’interface, rien de bien mystérieux. Sur humain on a donc implémenté Vivant, on a défini un attribut boolean livin sur son état, la méthode is_alive() retourne simplement livin, la méthode kill() vérifie que l’humain n’est pas déjà mort, si ce n’est pas le cas (que livin est a true), on le tue, sinon on prévient qu’il est déjà mort et la méthode ressusciter renvoie simplement que JP n’est pas JC. Pour la classe chat, on a le même attribut livin que sur humain, on a juste un attribut intégré en plus contenant le nombre de vies restant au chat, la méthode is_alive a le même comportement que Humain, kill également, par contre ressusciter a un comportement différent. Sur le premier if, on vérifie que le chat a encore des vies et qu’il est mort, si c’est le cas, on le ressuscite en passant livin a true et on lui enlève une vie, si on veut le ressusciter mais qu’il n’est pas mort ou alors qu’il ne lui reste plus de vie on prévient l’utilisateur selon la situation. Enfin, dans main.java, c’est à ce niveau que tout va se jouer. Dans la plupart des cours on aurait créé un objet Chat et un objet Humain, mais les interfaces jouent un rôle d’abstraction, ce qui veut dire que l’on peut créer (comme demandé dans le besoin) un tableau d’objets du type de l’interface. On peut donc créer un tableau de vivants. On initialisera ensuite chaque objet selon le type de vivant, par exemple un chat ou un humain. Et là où l’abstraction est vraiment utile c’est que, vu que ces classes implémentent les mêmes méthodes, celles définies dans l’interface, on peut dans une boucle for par exemple, appeler ses méthodes sans connaître le type ‘final’ de l’objet sur lequel on travaille. On peut donc tuer tous les êtres vivants du tableau sans savoir si on a affaire à un humain, un chat, un chien, un cochon, de plus ce n’est pas le but, on veut tuer les êtres vivants du tableau, on se moque de savoir de quel être vivant il s’agit. Voici le dernier point qui est souvent mal détaillé dans les cours, l’abstraction que les interfaces proposent, ce qui, en plus de forcer la redéfinition, est la différence fondamentale entre classes abstraites et interfaces. Dans main.java on créé donc un array de size[2], un tableau de vivants que l’on nomme etres_vivant, on crée à l’index 0 un chat et à l’index 1 un Humain. Ensuite on a un for(x;x;x) qui parcourt le tableau et qui sur chaque objet, fait des appels de méthodes :

1. Savoir s’il est vivant

2. Le faire mourir

3. Le ressusciter

4. Le ressusciter

5. Le tuer

6. Le ressusciter

7. Savoir s’il est vivant

Ce qui nous donne dans la sortie standard :

C’est tout pour les interfaces, j’espère avoir pu expliquer clairement une des vraies utilités des interfaces. Les exemples ici sont en Java, mais le fonctionnement et la sémantique restent les mêmes dans la plupart des langages OO permettant l’utilisation d’interface (C# par exemple).

Sur ce…