Hackable n°22 est arrivé chez votre marchand de journaux !

Pile avant Noël et les fêtes,  voici venir le 22ème numéro de Hackable avec, au programme, une découverte de la nouvelle plateforme ESP32. Ceux d’entre vous qui connaissent l’ESP8266, dont nous avons déjà très largement parlé dans nos pages, savent que la société Espressif nous a déjà gratifié d’un très sympathique « cadeau ».

Si vous ne connaissez pas l’ESP8266, sachez qu’il s’agit d’une puce équipant un module lui-même placé sur un circuit imprimé… s’utilisant comme une carte Arduino, mais offrant quelques avantages non négligeables : une connectivité Wifi, une rapidité impressionnante (comparé à une carte Arduino comme la UNO), plein de mémoire (vive et flash) pour vos croquis et surtout un coût excessivement bas.

Mais si tout cela ne vous impressionne pas, sans doute le serez-vous avec le grand frère (ou la grande sœur, je n’ai pas vérifié) de l’ESP8266, l’ESP32 : double cœur,  Wifi, Bluetooth (classiques et BLE), convertisseur analogique/numérique, et numérique/analogique, système d’exploitation intégré pour le multitâche, plein plein plein de GPIO, plusieurs ports série…

L’ESP32 se présente d’ores et déjà comme une solution très peu chère, ultra-puissante et surtout compatible avec l’environnement Arduino… à condition de savoir installer correctement le support avec son système préféré (GNU/Linux, Windows, macOS). Mais ça, en plus de la découverte de la plateforme elle-même, c’est précisément le job de l’article vedette de ce numéro 22 ! On a testé, on a utilisé, on a installé et on a détaillé et la seul chose que vous regretterez c’est de ne pas avoir, ou avoir eu, un (ou plusieurs) ESP32 sous le sapin, ou à un autre endroit où vous aimez ranger vos cadeaux avant de les utiliser (moi c’est plutôt… heu… dans la boîte à lettres).

Mais ce numéro très hivernal (vous avez vu, il est rouge et blanc) ne parle bien sûr pas que de l’ESP32. Vous retrouvez dans cette édition de quoi vous équiper à bas coût en fer à souder nomade USB (oui, oui, USB), utiliser le hat Pimoroni Unicorn avec votre Pi, alimentez vos projets avec un accu Li-ion facilement, hacker la mémoire de vos ESP8266 de première génération (ESP-01) et bien d’autres choses.

Sans oublier, bien entendu, la suite de l’aventure Z80, avec cette fois la prise en charge de l’émulation de la RAM afin de pouvoir utiliser toutes les fonctionnalités du processeur et en particulier la gestion de la pile et donc des sous-routines. C’est là une étape indispensable pour atteindre notre prochain objectif : écrire, compiler et exécuter le premier code en C pour notre ordinateur 8 bits !

Au sommaire de ce numéro :

  • Equipement
    • p.04 : Un fer à souder USB à moins de 6 ? Pourquoi pas ?
  • Ardu’n’co
    • p.10 : Un clone chinois de Digispark pour animer une bande de leds RGB
  • En couverture
    • p.34 : L’ESP32 : l’ « Arduino » économique ultime avec Wifi et BLE ?
  • Embarqué & Informatique
    • p.48 : Mise en oeuvre de la matrice de leds Pimoroni Unicorn sur votre Raspberry Pi
  • Tensions & Courants
    • p.68 : Alimentez votre projet avec un accu Li-ion sans vous ruiner
  • Démontage, Hacks & Récup
    • p.76 : Mettez à jour la mémoire de vos ESP-01
    • p.84 : Votre ordinateur 8 bits sur platine : de la RAM, une pile… cap vers le C !

Ce numéro 22 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.

8 commentaires sur “Hackable n°22 est arrivé chez votre marchand de journaux !

  1. Bonjour,

    Tout d’abord, merci pour cette continuation des articles sur le sujet Z80.

    Je rencontre tout de même un problème sur l’exécution du code assembleur avec le montage à base de 74HCT165.

    Avec le code Arduino du numéro 22, et le code assembleur de ce même numéro, la sortie série me donne ceci :
    Reset Z80
    Adresse: 0x0000 [0x31]
    Adresse: 0x0001 [0x40]
    Adresse: 0x0042 !!!!!
    Adresse: 0x0043 !!!!!
    Adresse: 0x8080 !!!!!
    Adresse: 0x8081 !!!!!
    … (sans fin, avec incrémentation de l’adresse)

    Dans le doute, j’ai refait l’intégralité du montage, en me basant cette fois sur le schéma électronique en page 96, avec le même résultat.

    J’ai donc testé le même code Arduino, mais avec le code assembleur du numéro précedent, avec pour résultat :
    Reset Z80
    Adresse: 0x0000 [0xC3]
    Adresse: 0x0001 [0x04]
    Adresse: 0x0002 [0x00]
    Adresse: 0x8084 !!!!!
    Adresse: 0x8085 !!!!!
    Adresse: 0x8086 !!!!!
    Adresse: 0x8087 !!!!!
    … (sans fin, avec incrémentation de l’adresse)

    En comparant le code Arduino des numéros 21 et 22, outre le support de l’écriture en mémoire, j’ai pu voir que la dernière ligne du loop (la mise en mode input des broches data de l’Arduino) était commenté dans le numéro 21 et décommenté dans le numéro 22. En commentant à nouveau cette ligne, l’assembleur du numéro 21 fonctionne à nouveau correctement, et celui du numéro 22 fonctionne presque correctement (la valeur de la variable reste à 0x00 au lieu d’être correctement lue et écrite).

    Je comprends bien que cette mise en mode entrée des broches est importante comme expliqué dans l’article, mais je le comprends pas pourquoi elle fait planter le code assembleur qui n’est qu’en lecture seule (pour le numéro 21) ou bien qui n’est pas encore sur les instructions d’écriture (numéro 22).

    Je suis toute ouïe pour les lumières que vous pourriez apporter.

    • J’ai également eu ce genre de comportements étranges et erratiques à un certain stade des expérimentations, mais c’est assez difficile de savoir où se situait effectivement le problème puisque j’avais changé énormément de choses.

      L’un des symptômes était également un changement de comportement en fonction de la fréquence d’horloge appliquée au Z80, ce qui m’avait fait pencher pour un problème de stabilité de l’alimentation. Au final, à ce niveau, j’ai modifié trois points : j’ai mis des condensateurs un peu partout, j’ai alimenté le Z80 avec du +5V ne provenant pas de la carte Arduino et j’ai supprimé la liaison 5V entre l’Arduino et le reste du circuit.

      • J’ai dans un premier temps écarté la piste de l’alimentation instable au vu de la reproductibilité du comportement constaté, au numéro d’adresse près.

        J’essayerai à l’occasion avec une alimentation externe.

  2. Bon, j’ai pu résoudre mon problème comme suit :
    – Commenter la ligne « for( int pin = 0; pin < 8; pin++ ) pinMode(pinsData[pin], INPUT); // input » présente en fin de « loop() »
    – Ajout de cette même ligne en tout début de « getData() »

    Deuxième effet KissCool : je respecte la logique de la mise en place du bus data en output qui est : je change quand nécessaire.

    Je ne vois pas d'effet de bord à cette modification. Par sécurité, j'ai aussi ajouté la ligne « for( int pin = 0; pin < 8; pin++ ) pinMode(pinsData[pin], OUTPUT); // output » à la fin de « getData() », avant le return.

  3. J’ai vu deux, voire trois petits défauts dans ce numéro :

    a) Concernant le Z80: dans le dernier numéro de novembre, son condensateur de découplage est un electrochimique, qui n’a pas d’effet en haute frequence; dans ce numero, le condensateur de decouplage est invisible, caché dans une jungle de lianes colorées? (à mon avis, il faudrait mettre en parallèle un electrochimique pour les BF et un condensateur de 100-300 nF ceramique pour les HF : ceci est classique).

    b) Concernant le ESP 32, et son (absence de ) support sous RPi/nanoPi, la phrase page 44, en dessous de l’illustration de get.py est ambigûe; (« ne » est superflu et « vous venez de télécharger uniquement l’utilitaire annexe … » serait plus facile à comprendre). Cette ambiguité est levée si … on a lu au préalable la page 43,

    c) que je trouve bien sévère avec les RPis (et a fortiori avec les nanoPis, qui sont un peu moins développés) : si compiler une application de quelques (dizaines de) milliers de lignes est héroîque (et même : R, une fois compilé -ça prend une heure s’execute 50% plus lentement sur un nanoPi que sur un vieux -5 ans- PC de bureau, avec les mêmes résultats), les Arduini ont besoin (et les capacités de stockage) de beaucoup moins de lignes et les temps de compilation n’ont rien de choquant (et sont négligeables devant les temps de reflection); il est donc dommage, de mon point de vue, que le support des avrs, extensa et arms (c’est un comble, si on est superficiel) soit négligé à ce point sur les xxxPis.

    • a) Coupler un condensateur électrolytique et un céramique est d’usage pour ce genre de choses, en particulier avec de longs câbles et/ou un bloc d’alimentation fournissant le 5V pour la partie Z80. Tellement d’usage que je n’en ai pas fait mention dans l’article et que cela n’apparaît pas dans les schémas. Mais, oui, en effet, c’est quelque chose qu’il est de bon ton de faire.

      b) Vous avez raison, la phrase est maladroite et est passée au travers des mailles de la relecture.

      c) En effet, « si on veut on peut ». Une Pi est parfaitement capable de compiler bon nombre de logiciels, d’applications et de bibliothèques (quitte à swapper un peu) et même de supporter un environnement de développement complet comme ceux qu’on se compose généralement sur PC. Mais est-ce vraiment agréable ou ergonomique au quotidien ? Je ne pense pas (mais c’est une question de goûts et de concessions toute personnelle). Je trouve qu’une « machine de dev » idéale est celle qui minimise les temps d’attente et donc de compilation, du mieux possible, et ce pour tous types de développement et de plateformes cibles. Certes pour un petit bout de code en C pour AVR ceci ne change pas grand chose que l’on compile sur une Pi ou un bi-Xeon avec 64 Go de RAM, une fraction de seconde tout au plus. Mais je suis d’un naturel plus « qui peut le plus peut le moins » que « si on veut on peut » lorsqu’il s’agit de ce genre de chose. A choisir, je préfère donc cross-compiler en quelque minutes sur une unique et puissante plateforme, qui est aussi ma machine de travail, que d’attendre une heure pour obtenir un binaire ou un paquet. Il en va de même lorsqu’il s’agit de retrocomputing, je trouve plus judicieux de cross-compiler de Linux/i386 vers NextStep 68k, même si, fut un temps la plateforme cible elle-même était conçue pour être une machine de développement.

      • Il y a deux choses qui m’intriguent, l’usage du swap et la cross compilation

        J’ai été récemment et agréablement surpris par le fait que le nanopi Fire 2 (1G RAM, comme le RPi) n’avait pas besoin de swap pour compiler opencv-3.4.0 -et ses ligatures python- , dlib (partiellement) et R (mais je le savais déjà, pour ce dernier-, une fois toutes les dépendances installéées. C’était une surprise d’autant plus agréable que le nanopi n’a pas de swap (vérifié avec « top »), pas d’utilitaires swapon/swapoff (il faut lesinstaller à partir des sources de linux-utils, si ma mémoire est bonne, et créer un fichier de swap sur un disque externe pour pouvoir les utiliser à « bon » escient -le moins possible- )…
        Ce sont des bibliothèques / exécutable plus conséquent-e-s (au moins un facteur 100) que ce que peut contenir un arduino . C’est plus l’usage (on est interessé par les résultats d’un algorithme statistique, ou d’un traitement d’image: si on veut savoir si on a commis une amélioration, il faut un nombre considérable de données, impliquant un temps de traitement très considérable (les temps de compilation sont alors négligeables).
        Ceci rend d’autant plus dommage que le support des arduini soit maltraité (en 2016, les RPi ne reconnaissaient pas les clones faisant appel au ch431 … et les nanopi ne voulaient pas entendre parler des arduini officiels….; ils en sont à la version 1.0.x, les versions ultérieures ayant de nombreuses améliorations) , alors que leur audience est très voisine (vous devez vous en douter, vue la teneur de Hackable…).

        Quant à la cross compilation (qui est nécessaire sur des projets plus complexes, ou des nanopi m1 -512M- ; ce dernier cas semble se règler par …. copie des résultats du nanonopi Fire2),
        hertaville http://www.hertaville.com/development-environment-raspberry-pi-cross-compiler.html l’expliquait en 2014; mais cela impliquait d’avoir des copies bien structurées des header files de son RPi (et que se passe-t-il si on a des RPi et des nanopis, et si on les met à jour?) C’est très prometteur, pour les projets … plus complexes que R ou opencv-3, mais cela implique une structure très complexe….

        • La cross-compilation n’est pas si compliquée si on utilise les bons outils. Si votre distribution x86 est une Debian et votre cible fait fonctionner une distribution similaire (Raspbian, etc) vous pouvez très facilement produire directement des paquets installables sur la cible, avec le support Debian Multi-arch du système de construction et de gestion des dépendances. Une fois tout correctement installé sur la machine de développement, ceci se résume à une simple option pour la commande dpkg-buildpackage, et vous obtenez un paquet installable sur la plateforme cible, tout en respectant l’intégrité sur système de gestion de paquets (contrairement à la copie brutale de binaires).

Les commentaires sont fermés.