Une sonde de température RF433 autonome plus d'un an pour 6€

Ayant du arrêter mon blog, je n'ai pas pu finaliser cet article. Etant donné qu'il contient tout de même des informations qui peuvent être utiles, je le publie dans un état de brouillon.

Dans cet article nous allons réaliser une petite sonde de température sans fil, pas chère et disposant d'une autonomie supérieure à un an.

Les temps des premières récoltes est enfin arrivé!

Depuis quasiment un an, ceux qui me suivent de manière régulière, et je les en remercie, ont supporté de long et fastidieux articles avec beaucoup de théorie. Il y a un an je me suis donné comme objectif d'acquérir les connaissances et les compétences minimales pour construire des objets connectés autonomes. Avec tous ceux parmi vous qui m'avez suivi, et je vous en remercie, nous avons du (ICI) apprendre comment faire communiquer un microcontrôleur avec un ordinateur pour pouvoir programmer et déboguer. Nous avons ensuite transpiré des heures durant pour comprendre comment suivre la consommation électrique d'un microcontrôleur (ICI) et la courbe de décharge d'une pile (ICI). Puis nous avons cherché à économiser cette précieuse énergie et nous avons étudié (ICI) comment nos chers ESP8266 pouvait entrer en mode sommeil quand ils ne font rien. Ce qui nous a permis de nous rendre compte que pour réaliser une sonde sur pile disposant d'une autonomie de plusieurs mois, la connectivité wifi des ESP8266 n'était pas bien adaptée. Pour nous remettre de cette déception, nous nous sommes un peu détendus en étudiants différents composants capables de mesurer une température. Et nous avons repris notre courage à deux mains et avons cherché LE microcontrôleur qui pourrait nous ouvrir les portes de cette autonomie longue durée. C'est alors que nous l'avons croisé, LUI, si petit, si mignon, si beau, si adorable avec ses 8 petites pattes, sa mémoire de poisson rouge mais surtout sa sobriété de chameau! LUI c'est l'attiny85. Alors nous l'avons étudié pour en comprendre les fondamentaux (ICI) et nous avons mis en place les bases pour le programmer (ICI). C'est ainsi que petit à petit, nous avons semé les graines de connaissance et nous avons cultivé nos compétences qui aujourd'hui, en cette belle journée de printemps, va nous permettre de récolter notre premier objet connecté. Et ceux qui me suivent, et je les en remercie, l'auront certainement deviné par rapport à ma passion des capteurs de température, ce premier objet connecté vraiment opérationnel sera une sonde de température.

Allez! On se lance ...

1. Prérequis

Bien qu'à priori tout le monde pourrait comprendre cet article et construire la sonde en suivant pas à pas les explications, quelques prérequis seront tout de même nécessaires afin de pouvoir en comprendre la conception. De plus, je l''ai développée et testée pour qu'elle puisse s'intégrer dans mon écosystème. Je pense qu'elle pourra aussi s'intégrer assez facilement dans un un différent du miens mais c'est quelque chose que je ne pourrai pas le valider. Quelques prérequis seront également nécessaires concernant votre capacité pour programmer et téléverser un programme vers un attiny. Et les derniers prérequis concerneront les librairies disponibles dans l'IDE Arduino ainsi que le matériel/composants qu'il vous faudra posséder. Nous allons regarder tout ça de plus prêt.

1.1 Écosystème de fonctionnement validé

J'ai développé et mis en place cette sonde pour avoir une remontée de température dans mon serveur domoticz. J'utilise une version 2020.2 qui tourne sur un Raspberry PI 3 modèle B+. J'ai aussi une version plus ancienne (la 4.11665) qui tourne sur un Raspberry PI modèle B. Dans les deux cas cela fonctionne mais dans les deux cas une petite modification pour activer la fonction de suivi graphique des log sera nécessaire. Je vous montrerais comment faire. C'est très simple et il y a juste deux lignes à modifier dans des fichiers du serveur domoticz.

La sonde est prévue pour envoyer les informations de température en utilisant un émetteur RF433. De plus, le protocole utilisé est le X10 et le matériel simulé correspondra à un équipement de type RFXSensor. Le RF433, ainsi que le protocole X10 et les équipements RFXSensor sont captés et reconnus de manière native par les boîtiers RFXCOM connectés en USB au Raspberry PI. Il faudra vous assurer que le protocole X10 est bien activé pour votre dispositif.

Panneau de configuration domoticz du matériel RFXCOM

Concernant le boitier RFXCOM, si vous n'en avez pas, je vous conseil de prendre le modèle XL qui désormais est quasiment le seul que l'on trouve. L'ancien modèle, le RFXtrx433E fonctionnera mais sera moins performant et ne vous coûtera pas moins cher.

Le RFXTRX433XL se trouve:

Sur Amazon: ICI.
Sur eBay: ICI

Cet équipement n'est pas donné mais si vous voulez faire de la domotique avec pas mal de sondes par trop chères il se révélera vite rentable et indispensable. Dans ma configuration la version logiciel de l'équipement est la EXT/1025.

Pour la réception des trames RF433, à la place d'un RFXCOM, vous pouvez avoir un RFLink mais je n'ai pas testé si cela fonctionne.

1.2 Environnement logiciel

1.2.1 Logiciels utilisés

J'ai développé le programme de la sonde en utilisant l'IDE Arduino version 1.8.12. Il a été compilé pour attiny85. Il ne pourra pas être porté (sans modifications en tout cas) sur un Attiny45 à cause de sa taille qui dépasse les 4096 ko.

Je vais donc supposer qu'en prérequis vous savez utiliser l'IDE Arduino. Si ce n'est pas le cas ce n'est pas très compliqué, il suffit de l'installer, de copier le code du programme que je vous donnerai et de compiler. Enfin ... après quelques heures passer à bidouiller pour résoudre tous les problèmes que vous allez rencontrer.

Je vais aussi supposer que vous savez compiler pour un microcontrôleur attiny. Si ce n'est pas le cas vous pourrez tout trouver dans mon article sur les fondamentaux de l'attiny ICI.

Et bien sur je suppose que vous savez téléverser un programme. Cela sous entend avoir connecté l'attiny sur un programmeur ISP, lui même raccordé au PC. Et si vous n'avez pas de programmeur ISP vous pouvez suivre le mode d'emploi que je vous donne pour en fabriquer un magnifique dans mon article ICI.

1.2.2 Librairies à installer

Notre sonde va devoir gérer deux composants électroniques:

Un capteur DS18B20, qui est un capteur "Dallas" (c'est le nom de la société qui l'a créé) et qui fonctionne sur un bus de données 1-wire (on peut aussi écrire OneWire). Si vous avez envie de découvrir plus en détail ces capteurs et le protocole 1-wire, vous trouverez pas mal d'informations dans l'article ICI ou nous nous étions amusés à ajouter un de ces capteurs directement sur les broches GPIO de notre Raspberry PI.
Un émetteur RF433. Dans mon cas c'est un FS1000A mais tout émetteur RF433 générique devrait fonctionner de la même manière.

Afin d'écrire un programme le plus simple possible, nous allons utiliser des librairies disponibles qui nous offriront les fonctions nécessaires pour contrôler ces composants.

Le capteur DS18B20 sera contrôlé par une fonction de la librairie "DallasTemperature". Cette dernière se trouve sur GitHub ICI (ne vous précipitez pas sur ce lien car il y a plus simple pour l'installer).

Et la librairie "DallasTemperature" a besoin d'une librairie pour gérer le protocole 1-wire. Il faudra donc installer la librairie "OneWire" que vous pourrez trouver ICI (mais attendez aussi).

Si vous voulez vous simplifier la vie, ces deux librairies sont connues dans le gestionnaire de bibliothèque de l'IDE Arduino. Pour les installer c'est simple. Allez dans l'IDE Arduino et dans le menu:<Croquis> / <Inclure une bibliothèque> / <Ajouter la bibliothèque .ZIP>

Ensuite vous n'aurez plus qu'a chercher "DallasTemperature", l'installer et puis "OneWire" et l'installer également. Voici une image de ce que j'ai chez moi avec les deux librairies installées.

En ce qui concerne l’émetteur FS1000A, ce dernier va être utilisé par la librairie X10rf qui gérera la communication en radio fréquence 433Mhz. Pour l'installer je vous invite à vous reporter au paragraphe 3.1.3 de l'article "Les bases pour programmer un attiny".

Les autres librairies qui sont utilisées par le programme font partie du "core" de la carte et devraient être utilisables sans avoir besoin d'installation spécifique.

1.3 Liste du matériel nécessaire

Un attiny85 et un connecteur socket: 1€50

Je commande les MCU par lots de 10 car ça sert toujours et ça revient moins cher unitairement. Voici le lien de ma dernière commande (ICI). Ca revient à 1€45/attiny. Concernant les connecteurs DIP8, je commande par 100, comme ICI. Cela n'a aucun sens de prendre moins étant donné l'écart de prix. Unitairement cela revient à 0,05€.

Un émetteur RF433 FS1000A: 0,45€

On trouve des kits de 10 ICI. J'ai aussi commandé ICI. Mais dans ces lots on a toujours un emetteur et un récepteur. Le recepteur dans le cas de notre sonde de température ne servira pas. Pour calculer le coût de revient je vais diviser le prix unitaire (0,9€) par deux. Soit 0,45€.

Un capteur de température DS18b20: 0,57€

Il en existe de plusieurs formats. Pour souder sur une plaque PCB il faut prendre le type TO-92. En fouillant un peu vous devriez trouver des lots de 10 pour moins de 7€. Comme ICI ou ICI.

Les piles (ou accu) avec un boitier: 2€70

C'est certainement ce qui va coûter le plus cher. Comme nous le verrons plus loin, notre montage pourra être alimenté sur une tensions allant de 5,5V à 3,3V. Pour ma part j'ai choisi de placer un accu 18650 car ils répondent aux exigences suivantes:

Taille: Sans être au niveau d'une pile bouton, la taille est correcte pour avoir un résultat final suffisamment petit.
Tension: Tension diminuant au fil du temps de 4,2V à 3V.
Capacité: il existe de nombreuses versions mais pour ma part j'ai trouvé des 2000mAh pour pas très cher. Et même si je considère qu'en réalité je n'aurais que la moitié cela suffira pour alimenter la sonde sans besoin de recharger pendant au moins un an.

Pour acheter ces accus il faut rechercher "18650" sur les sites marchands. Les offres varient et c'est compliqué de vous donner un liens sur une offre intéressante qui soit viable dans le temps. Actuellement j'ai trouvé un lot de 10 pour 16€ ICI. Soit 1€60 par batterie.

Il vous faudra aussi un boitier. Vous pouvez regarder ICI. Vous devriez en trouver pour 1€10 environ.

Pour charger ces accus, et toutes les piles rondes, je me suis fait plaisir et je me suis acheté un magnifique chargeur de geek qui indique le niveau de charge pour chaque accu. De plus, via une connectique USB, il peut faire office de stockage externe. Si vous en voulez un c'est ICI.

Le petit matériel: moins de 1€

Pour finir, comme dans tout montage électronique, vous aurez besoin de petit matériel. Des plaques de PCB pour souder les composants, des résistances, dont impérativement une de 4,7kΩ et des condensateurs (en option). Je ne vais pas vous donner des liens vers chaque composants car vous savez que je conseil toujours de prendre des kits qui apportent une diversité souvent bien utile. Vous trouvez quelques kits que je considère comme essentiels dans mes outils de jardin ICI. Surtout si vous ne deviez en prendre qu'un choisissez celui avec les PCB, les connecteurs et les broches (ICI) car vous en aurez besoin à l'avenir.

Au total nous allons réaliser une sonde température pour environ 6€.

Je vous laisse quelques liens sur Amazon:

2. Les secrets du sommeil profond

Bon, d'accord, jusqu'à présent cet article ressemble beaucoup à un tuto classique, qu'on trouve en quantité sur internet et qui explique étape par étape comment réaliser quelque chose. On commence par faire la liste du matériel nécessaire, les prérequis, ensuite on fait un schéma du montage, on donne un fichier avec le code du programme et c'est terminé! Si on a bien suivi la recette, dans le meilleur des cas, on a rien compris mais ça fonctionne. Dans le pire des ça ne fonctionne pas et on se retrouve incapable de corriger car justement on a rien compris. Mais nous ne sommes pas dans ce genre de blog. Ici c'est un blog de culture domotique ... un blog potager ou l'on aime semer, labourer, creuser avant de récolter. Alors avant de reprendre le fil d'un tuto classique, avec le montage électronique à réaliser et le programme du microcontrôleur, nous allons un peu faire travailler nos neurones et chercher à comprendre quels sont les secrets pour qu'un petit capteur de température puisse devenir une sonde domotique avec plus d'un an d'autonomie. Comme disait ma grand mère, "il va falloir se réveiller!"

Nous allons parler du sommeil ... 😁

2.1 Fonctionnalités et justifications

Ne rêvez pas (que je suis drôle!), je ne vais pas parler du sommeil sans avoir expliqué pourquoi nous allons parler que de ça et pas des nombreuses autres technologies qui seront implémentées dans notre sonde.

2.1.1 La sonde

Qu'est-ce qu'une sonde de température ? Je pense que chacun d'entre nous connait la réponse à cette question. Mais je la pose pour que nous parlions tous de la même chose. Pour moi, dans le contexte de cet article, une sonde de température est un montage électronique qui est capable de mesurer une température et de diffuser l'information sur la base d'un protocole spécifique.

De fait, tous les équipements qui auront accès à ce protocole et seront en capacité de recevoir le signal, devront pouvoir identifier la sonde et ainsi il pourront connaitre la température relevée.

Et toujours dans le contexte de cet article, la sonde est un objet électronique qui est alimenté sur accu, donc autonome.

2.1.2 Ses fonctionnalités

Selon ce que je viens de dire, pour répondre aux critères attendus, la sonde devra embarquer les fonctionnalités suivantes:

Etre en capacité de relever la température ambiante: nous utiliserons un capteur de température DS18B20.
Intégrer cette température dans un protocole de communication qui pourra être reconnu par des récepteurs: nous utiliserons le protocole X10.
Etre en capacité de se faire reconnaître en tant que sonde de température par un système domotique centralisé: nous simulerons les trames envoyées par les appareils RFXSensor.
Envoyer en radio fréquence les trames de données: nous utiliserons un émetteur radio sur la fréquence 433Mhz de type FS1000A.
Utiliser l'énergie de la pile uniquement pour remplir ses fonctions essentielles: en dehors de ses cycles de fonctionnement le circuit devra être placé dans un mode de fonctionnement qui ne consomme quasiment pas d'électricité (le deep sleep ou sommeil profond).

L'utilisation du DS18b20 ainsi que l'envoie des données en RF433 sera simplement réalisé par des fonctions fournies par les librairies que nous avons installé précédemment. J'ai déjà parlé dans d'autres articles des capteurs Dallas, du protocole 1-wire et du protocole X10. Je ne reviendrais donc pas dessus ici. Par contre, la chose vraiment nouvelle et inintéressante que nous allons devoir détailler ici, c'est l'utilisation du mode sommeil pour les microcontrôleurs AVR et en particulier pour notre cher attiny.

2.1.3 Justifications des choix

On m'a toujours dit que quand on est dans la vérité on a pas besoin de se justifier. Je n'ai pas la prétention de détenir la vérité et pour une bonne

compréhension de la suite de cet article, je vais expliquer rapidement les choix que j'ai fait pour répondre aux fonctionnalités requises de la sonde.

Le DS18B20: j'aurais pu choisir un capteur de type DHT11 (ou DHT22). J'aurais aussi pu choisir un BMP280 (BME280). L'un comme l'autre auraient donné en plus de la température l'hygrométrie (voir la pression dans le cas du BME280). J'ai choisi le DS18b20 pour plusieurs raisons:

Sa petite taille sous forme de composant TO-92.
Sa faible consommation électrique.
Son faible coût.
Sa précision bien meilleure qu'un DHT11.
Pour réaliser une première sonde et continuer sur ma courbe d'apprentissage progressive, je préférais me concentrer sur des données uniques de température plutôt que d'avoir à intégrer d'autres informations comme l'humidité.
Le fait qu'il communique en 1-wire permet d'utiliser une seule broche de données du microcontrôleur et d'ajouter plusieurs de ces capteurs dans une même sonde.
La disponibilités de librairies compatibles avec l'attiny85 pour le programmer facilement.

Le protocole X10 et les RFXSensor: Dans l'article précédent sur la programmation des attiny, j'ai cherché longtemps comment envoyer facilement des données à mon serveur domoticz en RF433. Beaucoup de protocoles reconnus par le binôme domoticz/capteur RFXCOM étaient assez complexes à implémenter. Puis j'ai trouvé la librairie X10rf qui implémente le procotole X10 et qui fourni une fonction nativement d'envoie de température vers domoticz en simulant un appareil RFXSensor. X10 et RFXSensor étant tous deux reconnus par le boitier RFXCOM et donc faciles à intégrer dans domoticz. Plus tard, je développerais des sondes plus complexes, de type Oregon par exemple. Mais pour le moment, la performance et la facilité d'usage du protocole X10/RFXSensor me semblent parfait pour développer de petites sondes pas chères et évolutives qui pourront être placées un peu partout.

Le FS1000A: Dans le petit monde des émetteurs RF433 il n'y a pas beaucoup de choix. Le FS1000A est l’émetteur low-cost que l'on trouve partout, qui est hyper standard et en plus j'en avais sous la main. Je pense que si vous avez d'autres émetteurs RF433 cela devrait fonctionner de manière identique.

Le deep sleep: Ici il ne s'agit pas vraiment d'un choix car pour développer une sonde fonctionnant sur batterie il faut absolument économiser l'énergie. Et pour un microcontrôleur, le seul moyen d'économiser de l'énergie au mieux, c'est de se mettre en sommeil lorsque le traitement attendu est réalisé. Un attiny85 consomme en moyenne 4mAh en fonctionnement normal. Ce qui nous donnerait moins de 10 jours d'autonomie, lui tout seul avec une pile le 1000 mAh, sans aucune stratégie d'économie d'énergie. C'est bof! Par contre en mode sommeil, l'attiny85 consomme moins de 6μAh. En restant en sommeil, avec la même pile de 1000mAh, n'autonomie deviendrait environ 16 ans! C'est top!

Dans la suite de ce chapitre nous allons donc essayer de comprendre comment fonctionne le mode sommeil de l'attiny.

2.2 Théorie du sommeil

Pour bien comprendre la mise en sommeil d'un microcontrôleur on peut faire le parallèle avec chacun d'entre nous.

Déjà, il est facile de comprendre que lorsqu'on dort, on ne consomme quasiment pas d'énergie. Toutes nos actions et les fonctions de notre organisme les plus consommatrices sont mise au repos. Seules les fonctions vitales restent actives.

De plus, si nous voulons vraiment économiser de l'énergie en dormant, il faudra penser à bien éteindre les lumières, la télé ainsi qu'a baisser la température des chauffages.

Par contre, économiser de l'énergie c'est bien, mais il faudra le faire uniquement quand notre travail sera terminé (on ne s'endors pas au bureau n'est-ce pas?). Et une fois endormi, il ne faudra pas oublier de se réveiller au bon moment afin de retourner travailler et surtout d'arriver à l'heure.

Pour un microcontrôleur c'est exactement la même chose:

La consommation d'énergie va être très faible en mode sommeil par rapport au mode de fonctionnement nominal (un il y un rapport de 1000 sur un attiny par exemple).
Le passage en mode sommeil doit être fait une fois l'action principale réalisée.
Avant de s'endormir, les fonctions non essentielles qui consomment de l'énergie devront être éteintes.
Il faudra trouver un mécanisme permettant le réveil au moment nécessaire.

Nous allons donc regarder comment réaliser toutes ces actions sur un attiny85. Mais toutes cette théorie ainsi que les exemples pratiques devraient fonctionner de manière identique sur tous les attiny et de manière plus large sur les microcontrôleur AVR (donc avec un Arduino).

2.2.1 Les registres du MCU

Nous allons commencer notre exploration de la théorie de la mise sommeil, par une notion qui n'est ni théorique et qui n'est pas directement liée à la mise en sommeil. On commence fort! Je voudrais vous parler des registres du microcontrôleur. Pourquoi parler de cela me direz vous ? Tout simplement parce que sans cette connaissance nous ne pourrons pas comprendre la suite de ce chapitre. Sans compter que dans la programmation des microcontrôleurs cette notion est omniprésente et aucune programmation des fonctionnalités de bas niveau de la puce n'est possible sans la maîtriser.

Dans l'article précédent nous avions parlé des fusibles. Si vous vous souvenez, il s'agissait d'octets (byte en Anglais, ne pas confondre avec bit) situés dans une zone de mémoire spécifique, dont la valeur permettait de contrôler des fonctionnalités de base du matériel. Par exemple, par une combinaison de 4 bits sur un des fusibles, on pouvait fixer la fréquence d'horloge. Ces fusibles ne s'efface pas lorsque l'on débranche la puce et pour en modifier les valeurs il faut passer par un programmateur spécifique. Ce qui signifie que le programme du microcontrôleur ne peux pas modifier ces fusibles.

Qu'est-ce que c'est un registre ?

Les registres ressemblent un peu aux fusibles dans le sens ou ce sont également des octets dont la valeur régissent des fonctions très spécifiques. Chacun de ces octets est constitué de 8 bits (logique!) et ces bits sont individuellement (ou en combinaison) associés à une fonction régulant le fonctionnement du MCU. Pour le attiny25/45/85 ces registres sont au nombre de 32.

A la différence des fusibles, ils sont accessibles par le programme en lecture et en écriture. Toutefois pour être modifiés certains nécessitent un mode opératoire spécifique: par exemple modifier un autre registre autorisant la modification du second.

A quoi ça ressemble un registre ?

Pour imager un peu la chose, un registre est un peu comme une ligne de disjoncteur dans votre tableau de distribution électrique.

Imaginons qu'une des lignes représente le premier étage de ma maison. Sur ce premier étage j'ai des prises électriques, des luminaires et l'alimentation de la VMC.

Comment on modifie un registre?

Si je veux allumer toutes les lumières, il va falloir que j'active tous les disjoncteurs associés à celles ci. Et dans la ligne de disjoncteurs, il peut s'agir du premier, du second et du dernier. En raisonnant sous forme de bits, si je veux allumer les lumières, je vais devoir mettre les deux premiers bits et le dernier à 1. Tout cela sans modifier les autres. On voit donc tout de suite les difficultés que nous attendent pour manipuler individuellement des bits indépendant sur un octet. Il va falloir que nous révisions notre logique booléenne.

Comment on accède aux registres et aux bits qui le constituent?

L'accès en lecture et en écriture se fera tout simplement dans le programme comme s'il s'agissant de variables. Saut que nous ne devrons pas oublier que la valeur globale de la variable n'a aucun sens et qu'il faudra toujours considérer que c'est la valeur de chacun des bits qui représente quelque chose.

Pour simplifier l'accès aux registres, ils ont tous un nom qui est connu par le compilateur gcc-avr.

De plus, pour certain registres, les bits ont aussi reçu un nom.

Par exemple il existe un registre qui permet de connaitre la cause d'un reset. Ce dernier a été appelé MCUSR (comme MCU State Register).

Registre MCUSR

Comme vous pouvez les voir dans l'image ci-dessus qui est extraite du datasheet de l'attiny, les bits 0 à 3 ont des noms également: WDRF, BORF, EXTRF et PORF. Et chacun de ces noms est l'abréviation de sa fonction. Par exemple WDRF signifie "Watch Dog Reset Flag". Ce bit est à 1 lorsque le MCU reboot suite à une interruption du Watchdog (nous verrons plus loin de quoi il s'agit).

Si nous voulons remettre l'ensemble de ces flags à zéro* après un reboot, il faudra simplement faire dans le programme:

MCUSR = 0;

*On voit que les bits 4 à 7 sont en lecture seule (R). On ne s'en préoccupe par car quelque soit l'opération que nous ferons ils ne seront pas adressés.

Si nous voulons parler du bit 3 nous pourrons parler du bit WDRF, ce qui dans un code sera plus parlant et surtout plus facile à se souvenir.

Comment mettre un bit de registre à 1?

Comme nous venons de le voir, pour utiliser les registres nous allons devoir manipuler les bits de manière unitaire dans les octets. Pour cela le langage C nous offre quelques fonctionnalités qu'il faut connaitre. Pour comprendre il faut absolument que vous connaissiez un minimum le calcul avec les opérateurs booléen et essentiellement les tables de vérité du AND ( & ) et du OR ( | ):

En observant ces tables on constate que faire un OU d'une valeur A avec un 0 donnera toujours A. Faire un OU d'une valeur A avec un 1 donnera toujours 1. Faire un ET d'une valeur A avec 0 donnera toujours 0. Faire un ET d'une valeur A avec un 1 donnera toujours A.

En résumé :

A & 0 = 0.
A & 1 = A
A | 0 = A
A | 1 = 1

De ces résultats nous pouvons déduire que si nous voulons mettre un bit particulier à 1 sans changer les autres, nous devrons faire un OU logique avec une chaîne ayant des 0 partout et un 1 sur le bit souhaité. Et si nous voulons mettre un bit particulier à 0, nous devons faire un ET logique de la chaîne avec une chaîne ayant des 1 partout sauf à la position du bit que nous souhaitons modifier. Dans les deux tableaux ci-dessous j'ai illustré ce propos. La chaîne initiale est la même: 10101010. Dans le premier cas je souhaite passer le bit 3 à 0. Dans le second je souhaite passer le bit 2 à 1.

En C, on peut écrire une variable sous sa forme binaire en la nommant: 0bxxxxxxx.

Dans notre exemple ci-dessus j'aurais mais deux variables d'opération: 0b11110111 et 0b00000100.

Donc pour reprendre l'exemple du registre MCUSR, si je souhaite mettre le bit 3 (WDRF) à zéro, il faudra que je fasse l'opération:

MCUSR = MCUSR & 0b11110111.

Que nous pouvons écrire en simplifié:

MCUSR &= 0b11110111;

De la même manière, si je veux mettre le bit 2 à un je ferai:

MCUSR |= 0b0000010;

??? ici

On explique comment avoir les valeur par décallage <<

On apprend quelques éléments spécifiques à la programmation des registres:

_BV(2) met à 1 le bit de poids 2.

DDRB = ~(_BV(2)) ; // DDRB = 0b11111011

2.2.2 Les interruptions

Une interruption est une fonction qui est exécutée dès qu'un événement survient en prenant le pas sur le programme en cours de fonctionnement. Elle interrompt le programme ! c'est pour cela qu'on l'appelle une interruption.

2.3 Mise en sommeil

La boucle loop minimal pour mettre le mcu en sommeil:

void loop() {
  sleep_enable();
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);  
  sleep_cpu(); 
}

Voir aussi les modes

On apprend comment sortir du mode sleep:

- Interruption sur changement d'état d'une broche : https://arduino.stackexchange.com/questions/70284/how-to-deep-sleep-attiny-atmega-to-run-for-years-with-batteries-but-still-dete

- watchdog : système qui envoi une interruption après un temps donné.

- reset ?

2.4 Ecrire une Interrution ISR

ISR = interrupt service routine (ISR)

ISR (you can use the EMPTY_INTERRUPT compiler macro). If the ISR is empty, execution will pick up on the line after the sleep upon waking.

On apprend ce qu'est la fonction ISR:

Vous pouvez remarquer l'appel à la fonction ISR (WDT_vec) . Il s'agit d'une fonction d'interruption, qui sera appelée lorsque le chien de garde se déclenchera. WDT_vec indique que c'est l'interruption qui sera appelée par le chien de garde. D'autres sources peuvent appeler des interruptions et auront des paramètres _vec différents. Il y a quelques choses à savoir sur les fonctions ISR. Tout d'abord, les interruptions sont désactivées dans les fonctions ISR, donc les fonctions basées sur les interruptions ne fonctionneront pas correctement (par exemple, Serial.write).

De plus, les variables habituelles ne peuvent pas être modifiées dans les fonctions ISR. Si vous devez modifier une variable dans une interruption, vous devez la déclarer volatile la première fois que vous l'utilisez (voir la section suivante). En général, les fonctions ISR doivent être aussi courtes que possible, pour permettre au flux de programme normal de reprendre aussi vite que possible (n'oubliez pas que les interruptions sont désactivées pendant ISR, donc la réception sur des interruptions en série ou par broches ne fonctionnera pas lors de l'exécution du noyau ISR ).
On commence à voir ici les limites des bibliothèques à usage général pour un contrôle détaillé du comportement du microcontrôleur. Comme un comportement plus spécifique est nécessaire, il devient nécessaire de commencer à creuser dans la fiche technique et les registres de bits pour obtenir un contrôle total sur le microcontrôleur.

Appel de la fonction ISR qui se déclenche sur interruption:

ISR(PCINT0_vect) {
  if (digitalRead(0) == LOW)            # PB0 = pin 5 pressed => LED on
    digitalWrite(4, HIGH);
  else if (digitalRead(1) == LOW)       # PB1 = pin 6 pressed => LED off
    digitalWrite(4, LOW);
  else if (digitalRead(2) == LOW)       # PB2 = pin 6 pressed => LED on
    digitalWrite(4, HIGH);
}

2.5 Eteindre les fonctions qui consomment:

J'ai confirmé que l'ADC utilise environ 320µA en sommeil. Il est désactivé dans setup () en appelant:

adc_disable ();

ou

  // disable ADC
  ADCSRA = 0;

ou

 ADCSRA &= ~_BV(ADEN);

Le comparateur analogique, le détecteur de brunissement et la minuterie de surveillance et le tampon d'entrée analogique ne sont pas activés par défaut, il n'y a donc aucun avantage à les désactiver.

Il est généralement recommandé de programmer toutes les sorties en tant qu'entrées avant de s'endormir, mais je n'ai pu mesurer aucun avantage à le faire, je l'ai donc ignoré.

2.5 On parle du watchdog:

Le watchdog se configure avec les registres :

MCUSR (MCU Status Register),
WDTCR (Watchdog Timer Control Register).

Sur MCUSR seul le bit WDRF (Watchdog Reset Flag) est utile ici. Ce bit passe à 1 lorsqu’un reset a été provoqué par le watchdog. Il repasse à 0 par un reset manuel, ou si on le met à 0 "à la main" depuis le programme. C'est donc surtout utile pour détecter un éventuel reset par le watchdog.

C'est donc surtout avec WDTCR que l'on configure le watchdog. Voici rapidement a quoi correspond chacun des de ces bits :

WDIF (Watchdog Timeout Interrupt Flag) : passe à 1 après un déclenchement du watchdog en mode "interruption".
WDIE (Watchdog Timeout Interrupt Enable) : si a 1 alors alors le watchdog déclenche une interruption (et non un reset). Attention, il repasse automatiquement à 0 à chaque déclenchement du watchdog.
WDCE (Watchdog Change Enable) : doit être forcé à 1 pour autoriser un passage a 0 de WDE.
WDE (Watchdog Enable) : permet d'activer ou non le watchdog.
WDP[3:0] Watchdog Timer Prescaler 3, 2, 1, and 0) : configure la fréquence de déclenchement du watchdog.

La table 8.3 présente les différentes configurations de WDP[3:0] et les fréquences de déclenchement associé, la voici reproduite :

Fréquence de déclenchement du _watchdog_

Pour le programme , tout est écrit ici : https://enavarro.eu/exploration-des-sleep-mode-du-attiny85.html

Sur le plan pratique pour changer la valeur des bits des registres:

Pour arrêter le wdt (sinon il ne s'arrête pas) il faut remettre le bit WDE à 0. Mais pour pouvoir mettre WDE à 0 il faut que WDCE et WDE soient passés à un dans une même opération. Ensuite, dans le cycle d'horloge juste après, il est possible de mettre WDE et WDCE à 0.

Lorsque que le timer du watch dog se déclenche, deux choses peuvent arriver: soit c'est un reset qui est effectué (c'est le fonctionnement par défaut), soit c'est une interruption qui est appellée.

Pour que le WDT déclenche une interruption, il faut que le bit WDIE du registre WDTCR soit à 1.
Après chaque interruption, WDIE est remis à zéro. Il faut donc le remettre à 1 si l'on souhaite que la prochaine interruption ne déclanche pas un reset.

Pour activer le watch dog, il faut que le bit WDE de WRTCR soit à 1. Mais pour qu'on puisse le mettre à un, il faut que WDCE soit à un. C'est une protection. WDCE et WDE doivent être mis à un dans la même instruction car le matériel va remettre à 0 WDCE après 4 cycles d'horloge.

On apprend comment activer le WD: voir le code du programme.

Le programme

Plan de câblage:

- J'ai essayé en mode parasite mais cela ne fonctionne pas. La température retournée est toujours de -127 (ie message d'erreur de lecture de la librairie dallas DEVICE_DISCONNECTED)

Mais sur un site j'ai vu qu'il faut charger le bus avec VCC durant 10micro secondes avec un transitor pour que ça fonctionne. C'est aussi décrit dans le datasheet du ds18b20

Montage sur breadboard:

Appairage dans domoticz avec ajout de notifications:

Problème dans l'affichage des logs: