Equipement

p. 04 Test du fer à souder fixe/nomade TS100
p. 12 Mes conseils, trucs et astuces pour des impressions 3D de qualité

Ardu'n'co

p. 22 Transformez vos vieux lecteurs de disquettes en instrument de musique
p. 30 Interfaçage d’une radiocommande de modélisme à un simulateur de vol

En couverture

p. 24 Faites communiquer vos projets simplement avec MQTT
p. 60 Sécurisez et protégez votre installation MQTT
p. 72 Représentez graphiquement vos données collectées en MQTT

Repère & Science

p. 84 Solar Hammer : pourquoi les tâches solaires menacent les réseaux ?

Retro Tech

p. 88 Ajouter de la mémoire à une vieille imprimante laser

Que faire lorsque son projet est dans une impasse ?

Quel que soit le projet sur lequel vous travaillez, il y a de fortes chances que celui-ci devienne une créature en perpétuelle évolution. Il y a toujours une amélioration à apporter, toujours une fonctionnalité à ajouter, toujours une optimisation à réaliser...

Parfois, les choses se passent bien et votre projet dispose de « l’espace » nécessaire à son évolution. C’est le cas, par exemple, d’un ensemble de capteurs dont nous avions parlé il y a quelque temps. Celui-ci utilisait des ESP-01 très basiques puis ceux-ci ont été améliorés physiquement en remplaçant leur mémoire flash. Plus récemment, grâce à cette évolution, ils ont bénéficié d’une fonctionnalité de mise à jour unifiée (OTA/HTTP) et enfin, leur firmware a été entièrement réécrit pour reposer sur MQTT et non plus sur de simples requêtes web.

Ce projet disposait de l’espace de création nécessaire et n’était pas limité dans ses évolutions, mais ceci ne se passe pas toujours ainsi. Un autre bon (ou déplaisant) exemple concerne la série d’articles sur l’ordinateur 8 bits basé sur le Z80. Dans le dernier article, nous avons atteint une étape importante en pouvant communiquer via une liaison série, avec un programme en C. Mais cette étape est aussi celle nous ayant montré les limites fonctionnelles : le processeur devrait avoir sa propre horloge pour fonctionner à une vitesse acceptable.

Mais il faut également que nous puissions suivre l’exécution du programme. Nous gagnons donc un signal (CLK), mais devons en gérer trois de plus (/MREQ, /WAIT et /M1). Pire encore, comme la carte Arduino ne peut pas émuler la mémoire à une telle vitesse lors de l’exécution normale, s’ajoutent alors deux autres signaux (/BUSRQ et /BUSAK). Soit, trouvons une astuce pour contrôler le bus de données de la même façon que le bus d’adresse, nous récupèrerons des ports, non ? Non, car il faudra asservir les composants supplémentaires. Sans parler de la gestion des interruptions...

La réponse à la question devient alors tristement évidente. Que faire ? Eh bien, se faire une raison et investir le temps nécessaire pour tout reprendre à zéro avec une approche différente. Une approche dont je vous parlerai sous peu...

Denis Bodor