Hackable n°20 est chez votre marchand de journaux !

C’est la rentrée, fini les vacances ! Mais ce n’est pas une raison pour se priver de prendre du bon temps tout en apprenant de nouvelles choses qui font un peu « voyager »… Et c’est là précisément l’objet de l’article « vedette » de ce 20ème numéro de Hackable.

Notre objectif sera de construire un dispositif lumineux qui peut paraître simple à première vue : une lune en relief présentant les phases de la lune en fonction de la date et de l’heure.

Pour ce projet qui mélange code, électronique et bricolage DIY, nous parlerons de portage de code (opération consistant à reprendre un bout de programme fonctionnant, par exemple, sur PC, et le rendre utilisable sur, par exemple, Arduino), de taille de variables, de calculs complexes, de pilotage de leds blanches, de lecture d’une date/heure depuis une RTC (horloge en temps réel), mais aussi et surtout des limitations des cartes Arduino à base de microcontrôleurs Atmel AVR (limitations qui nous pousseront finalement à nous diriger vers une autre carte/plateforme, de type ESP8266).

De leds il sera également question un peu partout dans ce numéro (et tout le monde aime les leds, n’est-ce pas) puisqu’on y découvrira comment afficher du texte et des images sur celles du Sense Hat de la Raspberry Pi ou encore la charge processeur de votre Pi sur celles du sympathique Pimoroni Piglow.

Mais parmi les autres articles de ce numéro, il en est un qui me tient particulièrement à cœur, puisqu’il concerne un composant qui titille la fibre nostalgique propre à tout amateur ayant connu la glorieuse époque des ordinateurs familiaux 8 bits. Cet article vous détaillera la toute première étape d’une épopée fantastique consistant à construire un ordinateur 8 bits tout en bénéficiant de l’assistance d’une carte Arduino. Vous découvrirez ainsi, dans ce numéro, comment connecter, contrôler et « piloter » un processeur Z80 tout en faisant connaissance avec les principes de base qui sont masqués, mais néanmoins importants lorsque vous programmez pour votre Arduino par exemple. Il sera question de bus, d’horloge, de signaux, d’interruption, d’opcodes, d’assembleur, de mémoire, de périphérique, et de tout un tas d’autres choses que vous utilisez souvent sans même le savoir…

Au sommaire de ce numéro de septembre/octobre :

  • Équipement
    • p.04 : Fabriquez vos câbles/jumpers pour platines à essais
  • En couverture
    • p.12 : Créez une lampe lunaire : préparation
    • p.24 : Créez une lampe lunaire : en route !
  • Embarqué & Informatique
    • p.38 : Visualisez la charge processeur de votre Pi avec Pimoroni Piglow
    • p.50 : Sense HAT pour donner de la couleur et plus à votre Raspberry Pi
  • Démontage, Hacks & Récup
    • p.70 : Créez votre ordinateur 8 bits sur platine à essais : le processeur
  • Tensions & Courants
    • p.76 : Prenez de bonnes mesures ! Et si dès la rentrée on se mettait au courant ?

Ce numéro 19 de Hackable est d’ores et déjà disponible chez votre marchand de journaux et dans notre boutique en ligne. Le sommaire du numéro (et l’édito) sont par ici.

7 commentaires sur “Hackable n°20 est chez votre marchand de journaux !

  1. J’ai beaucoup apprécié, dans le précédent numéro, le fait de pouvoir « mélanger des dépôts » Debian (ou plutôt forcer l’installation, à la demande, de logiciels plus récents que les dépôts de sa distribution). J’ai pu le tester avec succès sur nanoPi -théoriquement, celà ne dépend que de la façon dont les dépôts sont gérés, et non de l’architecture destinatrice des binaires…-.

    Le numéro actuel répond à la question qui me tracassait sur les « floats » Arduino .
    Mais il y a des points qui me tracassent:
    page 40, pour visualiser la charge CPU d’un RPi avec PiGlow, il faut installer i2c-tools; cet ordre d’installation est répété page 41 (normalement, le secont ordre ne sert à rien et génére des grognements timides de apt-get).
    En plus, page 41, on signale que i2cdetect … ne sert à rien (il ne detecte rien) mais que le périphérique i2c « fonctionnera très bien » . On se demande alors à quoi sert cette détection (et ça mériterait une clarification , parce que là, j’ai l’impression que ça fonctionne par magie ou miracle, domaines qui dépassent mes pauvres et éventuelles compétences)

    • En effet, la double installation d’i2c-tools est une maladresse qui n’a pas été détectée à la relecture de l’article.

      En ce qui concerne l’utilisation d’i2cdetect ceci aurait en effet pu nécessite une note/remarque. Il n’existe en réalité pas de méthode fiable permettant de détecter un composant sur un bus i2c, ceci n’est tout simplement pas dans les spécification techniques du standard. Il faut en principe connaître l’adresse du composant auquel on veut « parler ».

      i2cdetect n’est donc pas fiable dans le sens où il ne fait que parcourir les adresses et tenter de « parler » aux composants qui sont peut-être là, mais ceux-ci ne répondent pas forcément à des commandes standardisées SMBus. i2cdetect peut donc en principe être utilisé pour scanner un bus i2c puisqu’il va afficher l’adresse des composants qui répondent, mais il ne fait pas de miracle.

      Tous les composants qu’il affiche sont donc bien présent, mais tous les composants présents ne sont pas forcément affichés. C’était là l’intérêt d’utiliser cette commande dans l’article : Montrer que, parfois, même si i2cdetect ne voit rien, le composant peut être là et utilisable.

      • Bonjour, et merci beaucoup pour les renseignements concernant i2cdetect.

        Suivant l’étrange toile, i2cdetect détecte le pyglow à l’adresse 0x54 … ou pas.

        http://wiringpi.com/dev-lib/piglow/ recommande d’utiliser i2cdetect pour confirmer l’adresse 84 : « Use the i2cdetect program to scan your I2C bus to make sure the Pi can see the SN3218 which will show up as 0x54. »

        http://forums.pimoroni.com/t/piglow-on-raspberry-pi-2/661/13 spécifie que « Not seeing PiGlow/Dot3k when using i2cdetect -y 1 is normal- PiGlow is a write-only device, so it doesn’t respond to the reads that i2cdetect normally uses to try and detect devices. » (celui qui poste, dans un forum tenu par le constructeur de piglow, est décrit comme faisant partie de l’équipe…)

        Mais alors, si j’ai bien compris, i2c-tools (qui n’ ajoute « que » 3 commandes, i2cdetect, i2cset et i2cdump et dont seule i2cdetect est utilisée dans cet article … sans succès…) ne sert à rien dans ce cas … si ce n’est, peut-être, à fournir des morceaux de python-smbus (je n’ai pas pu le vérifier)

        Si le second lien que j’ai donné est réaliste (i2cdetect ne fonctionne pas avec des périphériques qui ne font que recevoir des ordres), ce qui est compatible avec l’article de Hackable, il est possible que des écrans LCD sous I2C -ont peu de fils – soient dans le même cas de figure (périphérique non détecté et utilisable) ….

        • Les outils i2c-tools sont initialement prévus pour les configurations PC et en particulier pour les réseau de capteur intégrés aux cartes mères. Ces capteurs sont en réalité compatible avec les spécifications SMBus qui est construit sur i2c. Selon ce principe, des composants i2c sur un bus SMBus fonctionnent mais ne répondent pas forcément à toutes les spécifications du standard et donc aux commande SMBus utilisées par i2cdetect.

          i2cdetect ne fonctionnera pas à coup sûr avec tous les composants i2c. Ceci est précisé dans la page de manuel de la commande (« man i2cdetect ») : « As there is no standard I2C detection command, i2cdetect uses arbitrary SMBus commands (namely SMBus quick write and SMBus receive byte) to probe for devices. By default, the command used is the one believed to be the safest for each address. »

          En gros, si i2cdetect voit un composant c’est qu’il est bien présent, mais si i2cdetect ne voit rien, ceci ne veut pas dire qu’il est effectivement absent.

    • Le Z84C00 est la version CMOS du Z80, par opposition au Z8400 qui est NMOS. En dehors de la technologie utilisée pour les transistor du processeurs le comportement général doit être identique, en dehors de deux petits points explicités ici : https://faqwiki.zxnet.co.uk/wiki/Z80#Differences_between_NMOS_and_CMOS_Z80s

      Nous avons d’une part un bug présent dans le Z8400 concernant le comportement de deux instructions LD (« LD A,I » et LS A,R », charger la valeur du registre I ou R dans A) lors d’une interruption. Ce bug n’est pas présent dans la version CMOS. Et d’autre part l’instruction non documentée « OUT(C),0 » (écrire 0 sur le port C) qui se comporte comme un « OUT(C),255 » avec un Z85C00 mais correctement avec un Z8400 (NMOS donc).

      Ce sont là des choses à savoir si on va très loin dans l’écriture de code pour le Z80, ce qui n’est pas le cas, loin de là, du premier article sur le Z80 piloté par Arduino. Ces différences risquent très certainement de ne jamais impacté le contenu de mes articles sur le sujet, et absolument certainement pas celui présent dans le numéro 20 ou les quelques uns qui suivrons.

      En conclusion Z8400 (NMOS) ou Z84C00 (CMOS), cela ne change rien pour cet article et les suivants.

Laisser un commentaire