Hackable n°24 est chez votre marchand de journaux

Dans ce nouveau numéro, daté mai/juin, nous nous pencherons à nouveau sur le domaine de la domotique et en particulier sur le contrôle de votre éclairage d’intérieur.

Le point de départ de cette mini-aventure se résume par l’acquisition de prises télécommandées semblant être un peu plus évoluées que celles qu’on trouve dans les magasins de bricolage. En effet, plutôt que de permettre simplement le choix des canaux via un sélecteur mécanique, ces prises sont programmables et associables à n’importe laquelle des télécommandes compatible. Il est ainsi possible de contrôler plusieurs prises avec un bouton d’une télécommande, mais également de commander une prise via plusieurs boutons de plusieurs télécommandes. Bref, on peut faire tout ce qui nous plaît sans être limité !

Il est donc possible de gérer des « scénarios » d’ambiance très facilement mais ça, c’était avant qu’on y ajoute notre grain de sel : remplacer une télécommande par un ESP8266 pour un pilotage en Wifi (via un module radio ou tout simplement en vampirisant l’émetteur de l’une des télécommandes), automatiser le basculement d’un mode d’ambiance à un autre, fournir une interface web pour commander les prises et même intégrer une extension dans Chrome/Chromium pour commander l’éclairage directement depuis la barre d’outils du navigateur.

Mais ceci n’est que l’article vedette de ce 24ème numéro. Dans les 96 pages vous trouverez, comme toujours, différents sujets abordés, allant cette fois de l’automatisation d’équipement de labo (générateur de fréquences et oscilloscope) au hack d’une puce sonore d’un Commodore 64 pour créer un lecteur de musique rétro (chiptunes) en passant par la programmation avancée des ESP32, un décryptage des normes vidéos analogiques ou encore la suite de nos expérimentations autour du processeur Z80…

Au sommaire de ce numéro 24 :

  • Equipement
    • p.04 : Automatisez vos mesures en utilisant l’USB
  • Ardu’n’co
    • p.18 : ESP32 : développez vos croquis Arduino sans l’IDE Arduino
  • Repère & Science
    • p.30 : Signaux vidéos analogiques : comment vous y retrouver ?
  • En couverture
    • p.40 : La télécommande Arduino, le retour version ESP8266 !
  • Embarqué & Informatique
    • p.64 : Robotique et électrons : mesurer une tension avec le Rpi
  • Retro Tech (Nouvelle rubrique)
    • p.72 : Pilotez le mythique MOS SID avec un Arduino pour jouer vos chiptunes
  • Démontage, Hacks & Récup
    • p.88 : Et si on faisait communiquer notre Z80 ?

 

17 commentaires sur “Hackable n°24 est chez votre marchand de journaux

  1. J’ai vu un tout petit problème:
    lors de l’installation par compilation de rtl_433, l’invocation de cmake devrait être précédée de « cd build » (la ligne de commande précdente devrit être donc :
    « mkdir build && cd build » .
    Ceci est confirma par le readme de rtl_433 (la séquence de ligne de commandes pa 47 peut marcher si on a chargé deux fois rtl_433, dont une fois dans rtl_433).
    sinon, ce numéro approche de la perfection.

    Il y a une dernière petite chose qui peut poser problème à terme :
    si vous envisagez de mettre une vraie RAM -certaines atteignent 32 k- à votre Z80, le principe :
    génération de *.ihx -> conversion en binaire -> génération de code pour Arduino (côte PC)
    puis l’Arduino transfère son code
    bloque la taille du code transmis (s’il est en RAM: moins de 2k; s’il est en flash : moins de 32 k).

    Une autre façon de faire consisterait à décoder au vol les lignes de l’*.ihx , tâche dont l’arduino peut très bien s’acquitter. Elle impliquerait pyserial côté PC -c’est le plus simple- pour transmettre ligne après ligne l’*ihx et mange peu de code (suivant mes premiers essais pour nourrir en instructions un 89S8252 (au lieu du Z80), où beaucoup de fils sont soudés … à l’interieur) côté Arduino -peut être 300 lignes, checksum et vérifications incluses, faisant moins de 2 k de code et quelques octets de variables auxilliaires -hors tableau de réception )

  2. Bonjour,

    Merci pour la suite de l’article sur le Z80. Je n’arrive pas à le faire marcher, mais le problème vient peut être de moi :)

    J’ai une question sur la ligne « #define B_IO A5 // écriture » dans le code Arduino. Elle est utilisée dans la fonction « loop() », mais sur le schéma présent dans l’article, elle n’est branchée nulle part. J’ai supposé qu’elle est connectée à la broche /IORQ (Z80) et /CS2 (PC1650DN).

    Sans ce branchement, la ligne RCLK reste à l’état haut, et avec ce branchement j’ai quelque chose sur cette ligne, à une fréquence quasi-égale à 156 kHz (9600 x 16). Par contre :
    – A5 branché : le moniteur série ne me sort que des lignes  » !!!!! »
    – A5 débranché : le moniteur série passe par les lignes « IOREQ R:  »

    Dans tous les cas, je n’ai strictement rien sur SOUT (à part un état haut permanent).

    Des idées pour me sortir de tout ça ? :)

    • Je viens de faire une série de tests avec un vrai oscilloscope, pas le « jouet » que j’avais sous la main.

      – Côté quartz, je considère que c’est OK, j’ai pu trouver la bonne paire de condensateurs (et régler mes problèmes de faux contacts). Je mesure une fréquence de 14,7450 MHz. Je ne suis pas certain que les 0,0006 MHz de différence changent quelque chose.
      – Par contre, sur la broches RCLK / /BAUDOUT, c’est calme plat à l’état haut permanent, que Arduino_A5 soit branché ou non à /IOREQ. Il arrive parfois que j’ai un signal carré (enfin, rectangulaire) présent, mais dans ce cas c’est du 99% haut / 1% bas, pas du 50/50 comme je m’attends à trouver sur un signal d’horloge.

      Donc je confirme, là je bloque :(

      • Et finalement, ça marche.

        Donc :

        – Y’a pas à dire, les breadboards c’est la fête aux contacts foireux :/
        – La broche A5 de l’Arduino doit bien être connectée à /IORQ
        – Le signal assymétrique sur RCLK / /BAUDOUT, c’est normal (en tout cas ça ne gêne pas le fonctionnement de l’ensemble).

        En tout cas, merci pour l’article :)

        • Je suis heureux que finalement tout fonctionne de votre côté.
          En effet, /IORQ est connecté à A5 côté Arduino pour surveiller le comportement du montage et ceci n’est pas présent sur le schémas. Cette absence de connexion cependant ne devrait gêner que le comportement du moniteur et non l’émission de caractères côté Z80 (le /CS2 du 16550 étant bien connecté à /IORQ). Un commentaire à ce propos aurait toutefois mérité de trouver place dans l’article, vous avez raison.
          J’ai également constaté que le signal présent sur /BAUDOUT n’était pas carré mais constitué de courtes impulsions. La documentation ne précise pas la forme du signal.
          Et, oui, les breadboards c’est l’enfer pour ce genre de choses, quand ce ne sont pas des problèmes de contacts, ce sont les capacités parasites qui sèment le chaos…

  3. J’ai appris avec beaucoup de plaisir et un peu d’espoir qu’il était possible d’installer par compilation l’IDE ESP32 sur RPi (et donc, sur nanoPi).
    Naturellement, j’ai essayé la procédure d’installation après m’être muni de quelques glaçons et d’un ventilateur 5v -branchable à chaud; faible puissance-05 w- – pour limiter les problèmes de surchauffe -a priori, le nanoPi m3 -un octocore- peut moduler la fréquence CPU en fonction -décroissante (…actuellement …) – de la température, aussi ai-je gardé mon nécessaire de refroidissement pour le cas où une estimation au toucher de la température CPU -je n’ai pas trouvé comment y accéder par logiciel…- serait douloureuse.
    Pour limiter les risques de surchauffe, voire de brûlures, sans moyens externes, j’ai regardé dans la doc de CT-NG si on pouvait limiter le nombre de processes lancés lors de la génération; ceci est possible par la commande « ./ct-ng xtensa-esp32-elf.4 #on garde au frais 4 processeurs, en tolérant d’être au pire 2 fois plus lent
    (ça devrait marcher/se traîner aussi pour RPi, en allouant 2 processes au lieu de 4 par « ./ct-ng xtensa-esp32-elf.2 »).
    LA génération a pu se passer sans encombre en 102 minutes (-hors téléchargements- mais, si la modulation de fréquence en fonction de la température est effective, ça peut être plus rapide l’hiver … et plus lent en période de canicule, abstraction faite des performances de la carte SD), une fois que les deux problèmes ont été réglés :
    il faut passer par menuconfig pour faire installer gmp-5.1.3 au lieu de gmp-6.0.0a, et mpfr-3.1.2 au lieu de mpfr-3.1.3 (un dépôt git, avec mises à jour fréquentes, ne peut pas mettre à disposition des listes pleinement fonctionnelles 100% du temps).
    La liste des caches de téléchargement s’établit alors (c’est dans un répertoire caché… mais on peut les trouver) ainsi :

    fa@NanoPi3:~$ ls ESP32/crosstool-NG/.build/tarballs/
    binutils-2.25.1.tar.bz2 gmp-6.0.0a.tar.xz ncurses-6.0.tar.gz
    expat-2.1.0.tar.gz isl-0.14.tar.xz newlib-2.2.0.tar.gz
    gcc-5.2.0.tar.bz2 mpc-1.0.3.tar.gz xtensa_esp32.tar
    gdb-7.10.tar.xz mpfr-3.1.2.tar.xz
    gmp-5.1.3.tar.xz mpfr-3.1.3.tar.xz
    fa@NanoPi3:~$

    A l’issue de la compilation, un programme très simple pouvait être compilé (avec génération d’assembleur, et comparaison avec l’assembleur ARM {option –save-temps} et sans lien avec crt et librairies {option -c}, en desactivant l’optimisation portant sur les variables (déclarées volatiles, comme dirait le Canard). Naturellement, la question qui vient à l’esprit est « où y a-t-il une description de l’assembleur esp32 »?-

    Mais ça a l’air de fonctionner….et ça vaut donc la peine d’acheter un ESP32 (ou d’attendre que leur prix baisse encore)

  4. Hello Maître Bodor ! Je profite du mot de la fin de l’article Z80 du nr24 pour quelques modestes suggestions. Pour passer outre la limitation du nombre de broches disponibles sur l’arduino, j’utilise un Atmega32A programmé en C (qui pourrait par ailleurs être intégré dans l’IDE arduino) et un programmateur arduino ISP. On peut ainsi se passer des 2 chips 74HC164 et de l’UART 16550. On dispose également pour le futur de connexions ISP/I2C pour utiliser des périphériques modernes (dont par exemple un écran LCD SPI). Pour réduire davantage la salade de câbles, on pourrait envisager d’empiler des perfboards avec des stackable headers qui permettraient également de regrouper des ports data / adresses / signaux de contrôle. Toute contribution, conseil ou guidance seront vraiment appréciés ;-) … Et un énorme merci pour votre série d’articles sur le Z80 qui m’ont permis de me lancer dans l’aventure !

  5. L’article sur le CAN SPI avait le mérite de présenter un convertisseur extrêmement simple (pas de voie de contrôle -> mobilise 3 fils au lieu de 4), rapide (un Arduino en esclave SPI ne peut echantillonner que 10k examples par seconde; un MC 3008 va jusqu’à 250 k/s) et à haute résolution (12 bits au lieu de 10 dans les deux autres examples).
    Cependant, il reste quelques points qui posent question:

    * une alimentation séparée -ça en fait 3 en tout – pourrait, en imposant un niveau haut à un port du RPi, l’endommager si le RPi cesse d’être alimenté. On peut supposer, en lisant la note d’application, qu’en l’absence d’horloge, MISO est en 3
    états (haute impédance).

    * l’explication du bruit par le secteur (page 66) pourrait inciter un gros malin à alimenter tout le monde … sur accus. Ce ne suffirait pas à faire l’économie d’un condensateur de 100 nF (recommandations standard de TI) , câblé au plus près des bornes d’alimentations (l’inductance parasite d’un fil de 3 cm est de 30 nH – http://www.consultrsr.net/resources/eis/induct5.htm – peut gêner la fourniture de courant à haute fréquence -pour répondre à un fonctionnement par impulsions- , et l’inductance parasite augmente avec la longueur des fils d’alim).

    * le test avec une LED (a une faible résistance série) nécessite un grand doigté. Je protègerais la LED (voire le CAN : si la LED grille, il est soumis à la tension de l’alim) avec une résistance série de 500 Ohm entre l’alim et la LED, même si l’alim a un potentiomètre multitours (ou alors, il faut être sûr de démarrer à 0 volts et tourner doucement)

  6. Bonjour M. Bodor,

    Lecteur fidèle et abonné depuis de nombreuses années (Linux Mag, Opensilicium 1 puis 2 et maintenant Hackable Mag), je suis avec intérêt vos articles et vos éditoriaux.
    De niveau moyen, il m’est agréable de constater que nos avis peuvent converger ce qui, compte tenu de votre niveau, ne peut que me conforter dans certains de mes choix.

    C’est ainsi que dans le HM N° 22, page 42, vous écrivez:
    « Je ne vois pas l’intérêt (e compiler l’IDE ) dans le sens où je ne considère en rien le Raspberry Pi comme une machine de travail et encore moins comme une machine de développement Arduino digne de ce nom »

    C’est le point de vue que je soutiens régulièrement sur l’excellent BLOG de Framboise314 (où nous nous sommes croisés). Pour moi, l’absence d’un bus SATA, des ressources CPU limitées et une mémoire vive rikiki, alliées à une Debian obèse et mal paramétrée par défaut (swap sur la carte SD), sont rédhibitoires (c’est pour cela que je me tourne vers Buildroot après avoir testé CT-NG).

    Ma surprise est donc grande de constater que 2 numéros plus tard, dans l’article ESP-IDF (page 18), le Raspberry Pi est devenu une machine de développement digne de ce nom puisque vous indiquez la marche à suivre. Vous précisez bien que c’est une opération qui prend énormément de temps et consomme presque toutes les ressources du Pi. Vous recommandez même de le refroidir avec un Ventirad mais vous oubliez de préciser qu’il faudrait mieux faire cela avec un disque dur. En effet, la compilation génère une multitude d’écritures, de fichiers temporaires, et c’est précisément ce que ne supporte pas la carte SD.

    Comme le Raspberry ne s’est pas transformé, d’un coup de baguette magique, en foudre de guerre, qu’est qui peut bien avoir motivé ce revirement à 180 ° ?
    Cordiales salutations.

    Sylvain POURRE

    • Je ne considère toujours par la Pi comme un support « vivable » en tant qu’environnement de développement. Mon avis n’a pas changé.

      La raison pour laquelle j’ai détaillé la construction d’un environnement de développement pour ESP32 sur cette plateforme est triple et toute autre :
      1 – Le fait que l’environnement existe pour GNU/Linux (amd64 ou x86) et non pour une autre architecture, comme ARM. Le fait est qu’un nombre non négligeable de lecteurs possèdent un PC uniquement sous Windows et que leur Pi est la seule plateforme dont ils disposent sous GNU/Linux.
      2 – Le peu de documentation existant et de descriptions de la manipulation complète. Cela n’avait pas beaucoup de sens de reconstruire l’environnement pour une plateforme alors que des binaires étaient proposés au téléchargement.
      3 – Pour le défi et la beauté de la manipulation (oui, bon, ok… parce que c’était amusant à faire).

      Je dirai donc que cette partie de l’article étaient donc présente pour fournir une méthode testée et approuvée aux personnes qui n’ont que la Pi comme « machine » GNU/Linux. Même sans être une « plateforme de développement » digne de ce nom, c’est toujours mieux que rien. Le problème ne se pose pas avec l’IDE Arduino, puisque celui-ci est disponible également pour Windows.

      C’est un peu le même raisonnement pour la radio logicielle. Beaucoup d’outils ne sont disponibles que sous GNU/Linux et une Pi n’est pas vraiment adaptée pour ce genre de choses. Mais là encore, pour certains, c’est la seule solution à portée de main, sans avoir à installer un système en dual-boot ou jouer avec WSL (et encore, tout le monde n’est pas sous Windows 10).

      PS : Le fait que je traite d’un sujet entre parenthèse dans un article ne doit pas forcément être vu comme une quelconque approbation ou validation. La preuve, dans l’article sur les télécommandes en sujet principal du numéro 24, j’ai même fait du HTML et dieu sait que je déteste tout ce qui touche de près ou de loin au développement Web ;)

    • Il y a un petit problème dans votre critique du RPi : si le swap est inclus dans la carte SD, il est très facile de l’en retirer (et ainsi d’éviter des risques d’usure localisée de la Sd) .
      Dans le cas des nanoPi, le problème est résolu, faute de swap (on peut, par des manips triviales d’un autre millénaire, le … rasouter *** sur un disque externe***, si besoin (compilation de opencv-3.x ou -incl- de dlib; ces manips peuvent aussi servir sur RPi à remettre un swap sur disque externe).

      Dans le cas de la compilation du cross compilateur extensa sur arm :
      il n’y a pas besoin de swap sur nanopi (la manip que j’utilise aussi sur RPi débarassé de son swap, n’a pas lieu d’être); comme les nanopi M3 ont exactement la même taille de RAM que le RPI -et sans la possibilité simple de … retirer le bureau, libérant 100 M de RAM, manip possible sur RPi….- , les risques de pénurie de RAM sont identiques : avec 4 processeurs sur 8 -cross tools permet de contrôler le nombre de processes, je l’ai utilisé pour limiter la dissipation thermique- , j’arrive à reproduire à peu près le fonctionnement (même les temps, à 20% près…- ) d’une RPI avec un (demi) nanoPi M3 -et à avoir une réserve de puissance de calcul, permettant -via « top » – de vérifier qu’on était loin d’une pénurie de RAM….

      Ce qui reste à éclaircir de mon côté : est ce que les binaires générés sur nanoPi M3 peuvent être copiés sur un autre nanoPi, moins puissant (comme si c’était un tar pour PC?) ou sur RPi? (parce que, même si attendre 1h 30 n’est pas la mer à boire -surtout si on peut dormir en toute confiance!), si on a beaucoup de nanoPis ou de RPis -pour des raisons de fiabilité ou d’amouur- ménerait à des situations fastidieuses et répétitives .

      Quant à l’utilisation de RPi (ou de ses clones) comme plate forme de développement :

      * un RPI avec 4 coeurs est équivalent, en terme de traitement d’images, à un PC vieux de 5 ans (sans processeur graphique utilisable) …
      * les scripts Arduino (on ne peut pas mettre beaucoup de code dans un 328) sont suffisament courts pour qu’une compilation monopolise beaucoup moins de temps qu’une relecture / recherche de bugs, du moins pour mon cerveau lent…
      * Je ne sais pas ce qu’il en est pour l’IDE espressif (recompile beaucoup: j’attends d’en avoir acheté un pour tester et voir si c’est supportable -notion un peu subjective-)

      • La possibilité de copie des binaires est dépendante de deux choses : l’architecture utilisée et donc la compatibilité du binaire lui-même (« readelf » et « file » donnent les informations utiles), et les bibliothèques dynamiques liées (commande « ldd ») qui doivent être présentes, identiques (ou compatibles) comme la LibC, LibM, LibStdc++, etc.

        Ensuite, la définition de « plateforme de dev » est propre aux préférences de chacun.
        En ce qui me concerne, la même plateforme ou machine doit permet de développement pour toutes les cibles que j’utilise, être également ma machine d’utilisation courante et aussi le lieu de stockage de mes dépôts Git locaux, code de test, documentation, etc. La machine de dev est aussi la machine de travail et de recherche, et donc celle d’utilisation quotidienne courante. Parmi les fonctionnalités indispensables pour ce faire, j’ai besoin de : puissance CPU maximum (double Xeon E5520), des tonnes de RAM (24 Go), tous les outils de dev et de mise au point pour toutes les cibles, une connectivité réseau gigabit, le dual-screen, etc. Autant de choses qu’une plateforme SBC ARM est encore loin de pouvoir me fournir.

  7. J’avais été accidentellement surpris par le fait qu’un binaire (lié à OpenCv -3.x, qui est beaucoup plus lent à compiler et requiert plus de ressources qu’un cross compilateur) pouvait être copié d’une machine arm à une autre et rester utilisable (et c’est bien pratique : un nanoPI m3 , avec 1G de RAM , peut compiler opencv sans être considérablement en swap; un nanoPi m1 -512 M- ne peut pas compiler opencv – serait en swap continuel- et on peut être bien content d’avoir généré un binaire récent (j’ai des ocv 3.4; je ne sais pas si debian en est au 3.0).

    La procédure pour s’affranchir du swap sur RPi est décrite dans https://www.pyimagesearch.com/2017/09/04/raspbian-stretch-install-opencv-3-python-on-your-raspberry-pi/ …. en augmentant la taille du swap -passage de 100 M -est inutile- à 1G (voire en retirant le bureau)..

    Une autre solution (testée sur nanoPi -livrée sans swap- et RPi) consiste à retirer le swap s’il existe, et à le recréer (utilitaires util-linux /swapon) sur un disque externe (3 lignes de shell…)…. si on en a besoin…

    L’argument de Spourre « le swap est sur le SD, donc c’est mauvais » disparaît donc, une fois le swap déplacé (les manips sur le swap sont connues depuis … le millénaire dernier) ou si on s’aperçoit à l’usage (cas de la génération d’un cross compilateur) …. qu’il n’y a pas besoin de swap…

    A noter que , si des écritures fréquentes sur une carte SD suffisaient à la corrompre, les « smart » « phones » ne pourraient pas …stocker de vidéo (cadences plus infernales qu’une compilation, le compilateur n’étant pas une bête de course). Il faut, pour corrompre une carte SD , écrire
    souvent
    ***physiquemement**
    au même endroit
    , un certain nombre de fois (10 000 fois sur un Arduino, où la structure de la carte impose une écriture physique au même endroit -sinon, elle ne pourrait pas démarrer!- ).
    Dans le cas de la génération d’un cross compilateur, qui mobilise au final 2.5 G (comparaison avant/ après par df -h) pour un ensemble de binaires de moins de 200M, on est sûr que les écritures ont rarement lieu au même endroit (la partition de swap impose une écriture au même endroit, ailleurs, on peut écrire là où il y a de la place…).
    De plus, à moins de synchroniser tout le temps, les écritures sont rarement des écritures physiques et restent dans des buffers s’il y a des réserves de RAM (cas de la génération d’un cross compilateur).

    On aboutit donc, sur la base d’un besoin tout à fait respectable d’une personne, à des généralisations hâtives (« Linux n’est pas fait pour les gameurhs » ;  »
    Linux n’est pas fait pour la bureautique » -slogans datant de la guéguerre avec W$ -, « RPi n’est pas fait pour développer », « python est LE langage de programmation de la RPi »).

    Tant que ce ne sont pas des prophéties autoréalisatrices (dans le cas du RPi,
    ça serait paradoxal: RPi a été conçu pour permettre à des étudiants désargentés de se former et de commencer à développer (arduino et python étant idéaux pour ça- ;
    et ça commence à se réaliser : les versions d’Arduino disponibles sont parmi les plus obsolètes dont on puisse rêver dans ses plus noirs cauchemards)
    et que ce n’est pas sur des bases factuelles branlantes (cas du swap et de la génération de fichiers ruinant la SD), ce n’est pas gênant.

  8. Bonjour
    Adaptateur + Prise de terre
    acheter une rallonge multiprise allemande
    remplacer la fiche mâle (type F) par une fiche mâle (type E)

  9. Bonjour,

    Excellent numéro qui semble susciter beaucoup de commentaire ci-dessus. 15, un record !

    J’ ai vu dans ce numéro 24 une référence a l’analyseur logique saleae logic. Ca ma fait relire le numéro 5 et le très bon article sur les analyseurs logiques. Bon ça date, mais j’ ai pu remarquer qu’a cette époque (2015) en effet saleae faisait partis du monde des hackers. Je veux dire par la du matos a moins de 300 euros. Ce n’est plus le cas aujourd’hui …
    En outre j’ai vu que dans ce numéro 5 vous faisiez référence a un truc qui s’appelle « bus pirate » kezako?

    Cordialement.

    • Le Bus Pirate est une petite carte connectée en USB/série permettant d’inspecter un bus SPI, i2c ou 1-wire en dialoguant avec l’interface série. Très intéressant pour dialoguer interactivement avec des composants sur ces bus pour les prendre en main avant de s’attaquer au développement d’un code pour les mettre en oeuvre. De plus, le tout est scriptable. Le Bus pirate peut également servir de programmateur AVR ou PIC et même faire office de sonde JTAG avec OpenOCD.
      Les versions les plus récentes permettent aussi d’utiliser d’autres bus : UART, MIDI, PS/2, etc.

Les commentaires sont fermés.