Hackable n°27 est chez votre marchand de journaux

Voici venir le nouveau numéro de Hackable pour la période de novembre et décembre. En sujet principal de cette édition, la réalisation et l’utilisation d’un réseau mesh à base d’ESP8266.

Vous connaissez certainement la problématique wifi consistant à tenter de couvrir au mieux une surface donnée afin que vos différents montages puissent aisément communiquer, aussi bien dans votre salon qu’au fond du jardin. La plupart du temps, ceci sera solutionné par l’ajout d’un, voire plusieurs, points d’accès wifi, mais cela suppose un accès au réseau filaire. Il existe pourtant une autre solution : un réseau maillé ou mesh.

Cette architecture, basée sur l’intercommunication des éléments du réseau permet de n’utiliser qu’un seul point d’accès wifi, chaque élément ou nœud se connectant aux autres et format un maillage, comme un filet de pêche. On peut alors étendre le réseau en ne faisant qu’ajouter des nœuds, jusqu’à couvrir une distance bien supérieure à la portée du point d’accès Wifi.

Dans ce numéro 27 nous verrons comment utiliser des cartes ESP8266 (Wemos D1 Mini) pour former un tel réseau, mais nous pencherons également sur la création d’un pont avec votre réseau local, permettant à tous les nœuds de remonter d’éventuelles mesures à un brocker MQTT. Inversement, il sera également possible d’envoyer un message au broker et celui-ci sera alors relayé par le pont à un ou plusieurs nœuds du réseau maillé.

Bien entendu, ce sujet n’est de loin pas le seul thème abordé dans ce numéro dont je vous laisse découvrir le sommaire complet :

  • Equipement
    • p.04 :Pilotez des écrans e-paper à trois couleurs !
  • Ardu’n’co
    • p.26 : Une jauge analogique MQTT pour afficher vos mesures et valeurs
  • En couverture
    • p.36 : Réseau mesh : étendre facilement son réseau sans fil pour ses montages
  • Repère & Science
    • p.56 : Contrôlez vos NeoPixels en 3,3 volts
  • Démontage, hacks & récup
    • p.64 : Ordinateur 8 bits Z80 : on prend les mêmes et on recommence
  • Embarqué & Informatique
    • p.72 : Robotique et électrons : mesurer une consommation avec le Rpi
  • Tensions & courants
    • p.80 : Étude d’un traqueur solaire

3 commentaires sur “Hackable n°27 est chez votre marchand de journaux

  1. J’ai été intrigué par l’utilisation d’une interruption pour déclencher le signal !wait du Z80:
    en effet, une interruption Arduino nécessite de stocker (empiler) le compteur de programme, de se dérouter, de stocker quelques registres (sdcc a l’option « naked »qui permet de ne stocker que les registres que l’on veut; je crois que gcc évite cette reflexion fastidieuse et source d’erreurs en ne stockant que quelques registres).
    Tout cela avant de positionner le niveau logique de la patte correspondant à !wait.

    Si l’empilement et le déroutement font 4 cycles Arduino à 16 Mhz , cela fait déja 1 cycle Z80 à 4 Mhz -NOP ne doit pas manger trop de cycles- qui risque fort de ne pas être interrompu. Si le stockage de registres supplémentaires et le calcul du nouveau PORT B -lire PORTB, le masquer par une constante et le mettre à jour doivent manger au moins 3 cycles- , il n’est pas étonnant que de gros problèmes surgissent quand on essaye de mettre au pas ou en pas à pas le Z80…
    Par contre, mes hypothèses expliquent qu’on rate un cycle Z80 sur deux ou trois, mais pas … un sur quatre (à moins que gcc ne fasse stocker d’office beaucoup de registres de l’Arduino quand il a à compiler une interruption… ce qui serait un non sens). Par ailleurs, l’appel à une fonction classique -non « inlined » depuis une interruption stocke vraiment beaucoup de registres, plus qu’une interruption – certains registres se trouvant empilés deux fois- )
    Avec sdcc, il est assez facile de voir le code généré (option par défaut, IIRC du 8952 qui a de la mémoire préssoudée, lui) et de compter les vélos, si nécessaire…
    Avec l’arduino (et donc g++/gcc), je ne sais comment faire pour voir le code généré…dans des repertoires temporaires.

    • Bien vu. Effectivement le croquis Arduino n’est pas assez rapide (et c’est encore pire avec digitalWrite()). J’avoue ne pas avoir réellement creusé dans le sens de l’optimisation du code Arduino/GCC, si ce n’est avec quelques essais simples.
      D’une façon ou d’une autre, même en optimisant, ceci ne pourra pas suffire si l’on décide de monter en gamme au niveau du Z80 (certaines version CMOS peuvent aller jusqu’à plus de 10 Mhz) et l’approche logicielle me paraît intrinsèquement mauvaise pour déclencher un /WAIT suite à un /M1. De plus, une approche matérielle permet d’aborder des concepts plus intéressants, tout en ayant même l’opportunité de laisser de côté la carte Arduino, pour ceux qui le souhaitent.
      L’article faisant suite à celui-ci est déjà rédigé et est assuré d’être présent dans le prochain numéro. Il y sera question d’un circuit single step, très différent de ce qu’on trouve généralement sur le web (à base de 555).

      • J’ai l’impression que j’ai été trop optimiste (je pensais que les Z80 allaient « seulement » jusqu’à 4 Mhz -cohérent avec les traces de l’oscilloscope et ma mémoire du millénaire dernier- c’était alors vu comme rapide).

        Ce qui compte dans une routine d’interruption de ce genre (insére le plus vite possible une attente) , c’est le temps de démarrage :
        déjà, mes calculs liés à l’empilage sont faux (optimistes)
        * une ISR empile au moins 3 registres https://www.avrfreaks.net/forum/isr-prologueepilogue-optimization-avr-gcc
        ce qui fait 6 vélos https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_PUSH.html -donne 2 cycles par registre, et je pensais qu’un empilage était plus rapide-
        Rien que ça fait qu’il est illusoire (à moins de viser une horloge du Z80 à disons 0.5 Mhz…) de chercher à la faire marcher par optimisation, et valide votre idée d’une solution « purement  » matérielle (je garderais peut être l’arduino comme IO -serie, analogique, I2C, timers : tout ça, plus ce que j’oublie, manque au Z80-)

        PAr ailleurs, j’ai été très surpris qu’une variable partagée qui sert à activer réellement la partie utile de l’interruption (ou pas) soit déclarée comme int (16 bits): je l’aurais déclarée uint8_t, byte ou (je crois que avr-g++ est sympa) … boolean. Ca aurait accéléré le test qui est fait avant de mettre en attente le Z80 (ce test a-t-il lieu d’être?)
        Les comparaisons entre les diverses façons de positionner une patte font valoir un gain d’un facteur 10-15 en faveur de l’emploi de BV -est une macro-https://arduino.stackexchange.com/questions/24452/pin-toggle-speed au lieu de la fonction arduino (empile encore plus qu’une ISR; de plus, elle arrête s’il y a lieu des fonctionalités liées aux timers https://forum.arduino.cc/index.php?topic=4324.0 -il faut écarter l’idée d’un arduino pilotant à toute vitesse toutes les pattes d’un port, devenant un oscillateur à 8 sorties sous 4 Mhz: piloter individuellement une patte mène à 2.6 Mhz -soit 190 nsecondes pour commuter une patte) .

        A ce propos, j’ai été très content de pouvoir lire -certes, avec une loupe- les unités de temps des traces de l’oscilloscope -j’avais tiqué à la lecture du programme, ayant bien du mal à lire les légendes -fort pâles- des figures, je n’avais pas regardé en première lecture l’oscillogramme double trace).

        Mais pourquoi les figures accompagnant les paramètres de moteurs ou les orientations des servos ne sont elles pas horodatées (je pense que gnuplot le permet) dans les autres articles : les échelles de temps pourraient être suggérées en légende, si le logiciel de tracé de séries temporelles est réfractaire à l’affichage d’une échelle de taon, permettant de se faire un idée des cadences des divers automates -et ainsi, de mieux les admirer-

Laisser un commentaire