Tests unitaires en C++

Monsieur Jourdain: Adieu Sganarelle, quoi de prévu pour aujourd’hui?

Sganarelle: Les tests unitaires.

Monsieur Jourdain: Ah… Mais vous êtes au courant que même si l’on sait que c’est bien, on n’aime pas faire ça…

Sganarelle: Ouais, mais là j’ai un argument choc: le développement sur microcontrôleurs!

Monsieur Jourdain: …

Ça annonce du lourd, n’est-ce pas?

J’ai eu très récemment besoin d’écrire une classe de pilotage de moteur pas à pas pour un microcontrôleur type Arduino (Teensy pour être exact, mais là n’est pas la question).

La classe en question doit gérer l’accélération et décélération du moteur en début et fin de mouvement.

Vous allez me dire, il existe déjà des bibliothèques pour ça. Hé bien oui, mais vous commencez à me connaitre, et j’étais très curieux de développer mon propre contrôleur de moteur. C’était d’ailleurs très instructif de se replonger dans les maths de terminale S pour calculer tout ce bordel; notamment réapprendre la notion d’intégrale pour calculer la distance parcourue pendant la durée du mouvement, avec une accélération et décélération constantes en début et fin de mouvement.

J’en ai aussi profité pour découvrir des outils mathématiques en ligne extrêmement pratiques, comme Desmos ça, c’est la courbe de vitesse par rapport au temps

En résumé, j’ai dû écrire une série de fonctions de calcul purement mathématiques pour calculer la durée d’accélération, le nombre de pas selon l’accélération et la vitesse max, ce genre de trucs.

J’aurais pu y aller empiriquement, et débugger avec des traces dans la console Arduino, à base de Serial.println(), mais franchement… franchement… C’est super relou de débugger sur ce genre de plateforme…

Alors dans un premier temps, j’ai écrit ces fonctions en Python (oui, je m’y suis mis et je kiffe pas mal), et comme Python dispose en standard d’un environnement de tests unitaires, c’était cool.

Puis, une fois mes fonctions validées en Python, je les ai transposées en C++ dans une classe statique. Mais là, c’est méga chiant, parce que les langages sont quand même très différents :/

J’ai cherché un environnement de tests unitaires en C++ (j’en avais de mauvais souvenirs en termes de dépendance, et c’est essentiellement pour ça que je suis passé par Python). Et j’ai trouvé la perle: Catch

C’est HYPER simple à mettre en place. Aucun héritage, ni nommage conventionnel à faire. Juste UN fichier d’en-tête à inclure, et une syntaxe à la cool pour écrire les tests 🙂

Imaginons que j’aie à tester une classe qui permet d’effectuer des opérations très complexes, telles qu’ajouter deux nombres, calculer une puissance ou pire, diviser deux nombres (float).

Pour info, REQUIRE arrête l’exécution des tests en cas d’erreur, alors que CHECK indique l’erreur et continue avec les autres tests. Pour plus de détails (notamment sur l’approximation des nombres à virgule flottante), voir la documentation officielle.

Et qu’est-ce qu’il dit?

Déclencheur pour réflex Canon à base d’Arduino

  • Bonjour Pierre, vous connaissez ma femme?
  • Oui, chef…

  • Elle est belle hein?

  • Oui, chef…

Et en plus d’être belle, elle a des envies lubies obsessions photographiques très précises, comme prendre des dominos en train de tomber, pour figer le mouvement. Le truc, c’est que prendre ce genre de photos, c’est assez chaud, pour les raisons suivantes:

Fonctionnalités très appréciables dans l’IDE Arduino

Adieu l’équipe!

J’avais envie d’écrire un petit article pour saluer les évolutions de l’IDE Arduino.

Par rapports aux débuts, il y a eu à mes yeux deux avancées majeures: le gestionnaire de cartes et le gestionnaire de librairies.

Le gestionnaire de cartes

Aujourd’hui, l’IDE Arduino est utilisable avec de nombreux microcontrôleurs, par forcément Atmel.

Parmi les cartes notables que j’ai pu utiliser, il y a la Teensy 3.x et l’ESP8266.

Evidemment, le protocole d’upload des programmes vers l’un ou l’autre des microcontrôleurs est différent, et l’IDE doit savoir comment communiquer.

Pour cela, on a le menu Outils>Types de cartes, et on peut sélectionner la bonne. Mais quid des cartes non listées dans ce menu?

Et bien c’est pas compliqué.

Avant tout, il faut éventuellement ajouter la source du package pour obtenir le driver de cette carte, dans les préférences de l’IDE:

arduino-esp-preferences

Puis on va dans Outils>Types de cartes>Gestionnaire de cartes et nous avons à disposition une liste de cartes pour lesquelles on peut installer le driver, et paf! il n’y a plus qu’à la sélectionner dans le menu pour la programmer. Sympa! (bon, pas de pot, la Teensy n’apparait pas dans cette liste, il faut installer Teensyduino, un complément disponible sur le site du constructeur). Donc plutôt pratique le gestionnaire de cartes.

arduino-esp-boards

Le gestionnaire de librairies

Alors là c’est encore mieux! Tu as dégoté un nouveau composant et tu n’as pas le cœur à te farcir la datasheet pour comprendre comment discuter avec lui? Comme je te comprends… Prenons à tout hasard le DHT22, qui est un capteur de température/humidité assez répandu. Hé bien pas de prise de tête: on va dans Croquis>Inclure une bibliothèque>Gérer les bibliothèques. Une liste se charge, on tape DHT22 dans le filtre en haut, et paf! on tombe sur DHT sensor library by Adafruit.

arduino-dht22-librairy

Il n’y a plus qu’à cliquer sur le bouton installer, et on se trouve non seulement avec la librairie disponible, mais il y a aussi des exemples disponibles dans Fichier>Exemples! C’est-y pas beau, ça? Hein?

arduino-dht22-exemples

J’ai particulièrement apprécié cette fonctionnalité avec un capteur que j’avais acheté il y a quelque temps, et qui est une vraie merde à programmer: le MLX90614. C’est un thermomètre IR directionnel. Ça permet d’obtenir la température d’un objet sans contact. Mais alors pour communiquer avec, amuse toi si tu n’as que la datasheet sous la main… C’est un protocole I2C modifié, le truc bien relou. Hé bien l’autre jour j’ai tapé MLX dans le champ de recherche du gestionnaire de librairies, et j’ai eu le plaisir de pouvoir utiliser le capteur hyper simplement. Merci à Adafruit d’avoir écrit cette classe… Et d’ailleurs en regardant le code, c’est pas si long… Respect 🙂

Piloter Grbl par le port série

Hey, j’ai une bonne nouvelle : ma Shapeoko arrive à fonctionner, et surtout ne plus planter, et ce avec ma carte maison! Wouhouuu c’teu fête!

J’ai bagarré pour en arriver là. J’attends la carte « nouvelle mouture » du fabricant, mais impatient que je suis, je n’ai pas pu résister à la tentation de la faire fonctionner moi-même…:)

Le point sensible, d’après les forums et mes constats, c’est la liaison USB entre le PC et l’Arduino sur laquelle tourne Grbl. Alors je me suis dit que je pourrais utiliser une autre Arduino entre les deux, qui communique par liaison série.

J’aurai donc:

PC<– liaison USB –> Arduino 1 (relais) <– Liaison série (Rx/Tx) –> Arduino 2 (Grbl)

L’Arduino 1 est une Arduino Mega 2560, largement surdimensionnée mais j’en avais une en stock alors ça m’allait bien 🙂

Entre les deux Arduini (pluriel d’Arduino?), on a juste besoin de 3 fils: Rx Arduino 1 vers Tx Arduino2, Tx Arduino 1 vers Rx Arduino 2, et relier les masses entre elles (Gnd).

En fin de compte, sur l’Arduino « relais », j’avais besoin d’un port usb en entrée et un port série en sortie (la Mega 2560 en a 3, en plus du port zéro qui correspond à l’entrée USB). Quoique, ça devrait aussi fonctionner avec la librairie SoftwareSerial pour émuler un port série.

Bref, le programme est très simple et assure une communication bidirectionnelle: il lit ce qui entre sur le port 0 (le port USB) et l’écrit sur le port 1 (connecté à l’Arduino 2), et il lit ce qui arrive du port 1 pour l’écrire sur le port 0 (connecté au PC).

Le câble USB utilisé mesure 20cm (beaucoup plus court que le câble d’origine, et donc moins sensible aux interférences électromagnétiques). J’ai dû virer l’isolateur galvanique qui posait des problèmes de communication.

Et ça ne plante plus, mon pote. Ca ne plante plus! Enfin jusqu’à preuve du contraire hein, parce que je commence à avoir l’habitude des phases maniaco-dépressives avec cette machine…

L’intérêt de conserver une liaison USB est de pouvoir utiliser bCNC et les autres outils de contrôle pour Grbl. Si j’utilisais une carte SD, je serais limité dans les interactions avec la machine, et je ne pourrais pas bénéficier (entre autres) de l’autoleveling de bCNC.

Shapeoko 3, déconnexions USB et carte de contrôle

Je me bats avec ma Shapeoko 3 depuis à peu près le début, car il y a des déconnexions USB très fréquentes quand on attaque assez fort dans la matière. Par contre ce n’est pas le cas si on n’attaque pas trop fort dans la matière.

Un tour dans les forums et des discussion avec Jorge Sanchez (de chez Carbide 3D) m’ont laissé entendre que ces déconnexions étaient très probablement causées par des interférences électromagnétiques entre les moteurs (pas à pas, ou peut-être la broche) et le câble USB.

J’ai suivi les instructions de Jorge: raccordement de masses, utilisation d’un isolateur galvanique USB, mise à la terre. J’ai cru que c’était réglé, et puis c’est revenu… Ça m’a vraiment saoulé, et j’ai décidé de fabriquer ma propre carte de contrôle pour la machine.

Je suis parti sur des drivers pas à pas Pololu DRV8825, commandés par une Arduino Uno sous Grbl. Rien de très compliqué a priori, puisque j’ai déjà fait quelque chose de comparable avec mon CoreXY, sur 2 axes seulement.

Alors je me suis lancé, et j’ai fabriqué un circuit imprimé avec la Shapeoko elle-même (comme je disais, quand on grave et que ça ne force pas, ça marche!).

Côté design, j’ai utilisé Fritzing et Visolate.

Pour l’envoi sur la machine, j’ai découvert bCNC et croyez-moi c’est VRAIMENT le top. Je ferai certainement un article dessus pour la prise en main. Pour la faire courte, c’est un logiciel qui envoie le G-Code à la machine, mais qui permet de compenser l’axe Z selon les mesures faites au préalable avec un palpeur. C’est trop bien, particulièrement quand on grave un circuit imprimé et qu’on veut avoir une profondeur identique partout!

Bref, voici la fabrication de la carte en images.

Gravure PCB
Gravure des traces. Si si, ça tourne! C’est l’appareil photo qui est trop rapide 🙂

 

perçage pcb
Le perçage avec une mèche de 1mm.

 

bCNC
bCNC en pleine action! On peut voir le quadrillage effectué par le palpeur, avec les différences de hauteur.

 

Le circuit terminé
Le circuit terminé. C’est autre chose que ce que j’avais fait dans le passé!

 

Test pcb
Test avec 3 moteurs Nema17, concluant 🙂

 

J’ai branché les moteurs de la Shapeoko (Nema23) sur la carte, et.. Rien. Enfin si: des réactions, mais des réactions étranges.

En fait j’ai réalisé que les fils n’étaient pas agencés pareil au niveau des connecteurs!

Cablage moteurs pas à pas 4 fils
Codes couleurs des moteurs bipolaires à 4 fils. (honteusement piqué sur http://www.linengineering.com)

 

Avec les fils dans le bon ordre, le fonctionnement est bien meilleur, n’est-ce pas 🙂

Tout content, je lance un job avec des passes de 2.5mm dans du pin. J’y crois, j’y crois, j’y crois. Jusqu’à ce que ça se plante. La même. Exactement la même qu’avec le contrôleur d’origine de la Shapeoko. Autant dire que ma tête a pris successivement toutes les couleurs de l’image ci-dessus.

J’ai tout fait, j’ai essayé sur un PC de bureau (relié à la terre) plutôt qu’un portable, j’ai essayé à tout hasard un autre firmware, rien à faire. C’est relou hein…

Alors hier soir j’ai retenté le contrôleur d’origine, en diminuant la profondeur des passes (1.25mm) et ça va. Pour le moment en tout cas…

Mais c’est frustrant, quand on a une grosse machine, puissante, de devoir se coltiner des passes aussi fines, franchement…

[Edit du soir même] Hééééé ben non. Finalement ce soir elle ne voulait plus. Je commence à en avoir plein mon ass, mais alors vraiment…

[Edit du lendemain] Carbide 3D va m’envoyer une nouvelle carte (une nouvelle mouture, pas juste un remplacement de celle-ci). Même si je râle, j’apprécie énormément leur support, ils ne laissent pas leurs clients dans le mouise. C’est très important.

Si vous avez le même problème que moi, faites-moi signe, que vous l’ayez résolu ou non, ça m’intéresse!

Présentation du microcontrôleur Teensy

Mon Arduino Uno étant dorénavant dédiée à la graveuse laser CoreXY, j’ai cherché un autre microcontrôleur pour bricoler. Notamment pour piloter Ableton Live en MIDI.

Arduino Leonardo m’intéressait pas mal, car elle a la capacité de se faire passer pour un clavier, une souris, ou un périphérique HID quelconque.

Pendant mes recherches, je suis aussi tombé sur la Teensy 3.1. Certes, cette carte n’est pas open hardware, MAIS :

  • Prix similaire à la Leonardo (20$)
  • 256Ko de mémoire flash (32Ko sur la Leonardo)
  • 64Ko de RAM (2.5Ko sur la Leonardo)
  • 72MHz (16MHz sur Leonardo)
  • Des entrées capacitives (« touch »)
  • Une sortie analogique (pas PWM, j’ai bien dit analogique)
  • Une taille ridicule (CMB)
  • Support natif du MIDI par le port USB, sans avoir à installer de driver!
  • Et j’en passe.

Voici une cartographie de la bête:

https://www.pjrc.com/teensy/teensy31.html
Vue de dessus
Source : https://www.pjrc.com/teensy/teensy31.html
https://www.pjrc.com/teensy/teensy31.html
Vue de dessous

Pour la programmer, ça se passe avec une Arduino. On utilise un câble micro USB-B, et le même IDE. Il faut juste installer l’add-on Teensyduino pour pouvoir gérer cette carte.

Donc, avec tous ces avantages, j’ai craqué direct.

Comme je disais plus haut, cette carte a la possibilité d’envoyer des commandes MIDI par l’USB très simplement. Par exemple:

[code]

usbMIDI.sendNoteOn(note, velocity, channel) usbMIDI.sendNoteOff(note, velocity, channel) usbMIDI.sendControlChange(control, value, channel)

[/code]

Pour la liste complète des capacités MIDI de la Teensy, la doc est ici.

Pour une liste des numéros de notes MIDI, c’est par .

Bref, elle a tout ce dont j’ai besoin pour fabriquer un petit pédalier MIDI, qui me servira à sampler des boucles de basse en live!

Des barres, des roulements, des poulies et des ficelles : le Core XY avance

« Prendre des p’tits bouts d’truc et puis les assembler ensemble… »

J’ai enfin monté tout mon petit bazar, et voici l’histoire du Core(X,Y) fishing line édition! Enfin plutôt « butcher line » parce que c’est de la ficelle de boucher.

Core(X,Y) vue de dessus

En bougeant les moteurs à la main, tout a l’air bon, alors j’attaque l’électronique.

Au départ, je voulais utiliser grbl sur mon arduino uno, mais hélas il ne gère pas nativement le CoreXY. Alors j’ai opté pour Teacup, qui le gère et qui propose des sorties PWM (qui vont me permettre de contrôler la puissance de mon laser).

Les Pololu

Bon j’avoue, j’en ai un peu chié avec ces pololu. Au premier essai, j’ai consulté ce schéma, et j’ai laissé flottantes les broches ENABLE, MS1, MS2 et MS3. Mauvaise idée.

Pololu A4988 (https://www.pololu.com/product/1182)
Câblage du Pololu A4988 (https://www.pololu.com/product/1182)

Je vais vous donner la solution directement, c’est plus pratique:

  • ENABLE -> 0V de l’arduino
  • MS1, MS2, MS3 : leur combinaison donne la valeur du microstepping (voir lien au dessus)
  • RESET et SLEEP : les raccorder ensemble
  • DIR et STEP -> sur l’arduino (j’y reviendrai)
  • VDD : +5V de l’arduino
  • GND (celui du bas) : 0V de l’arduino
  • VMOT : +12V de l’alimentation de puissance (alimentation de PC dans mon cas)
  • GND (celui du haut) : 0V de l’alimentation de puissance
Joyeux bordel : arduino uno et pololu
Joyeux bordel : arduino uno et pololu

Teacup

Alors Teacup, c’est d’abord un poil de configuration. Il faut avant tout renommer l’un des modèles de fichiers de config en config.h. Dans mon cas, je n’ai pas de ramps, ni de gen7, ni quoi que ce soit : juste une arduino et deux pololu A4988 pour piloter mes deux moteurs. Je copie donc le config.default.h en config.h.

Pour que ça compile, il faut aussi renommer ThermistorTable.single.h en ThermistorTable.h. On n’utilisera pas de thermistance (enfin pour l’instant… hé hé) donc on s’en fout.

Dans le config.h, il y a un paramètre pour indiquer qu’on utilise une mécanique CoreXY:

[code]

define KINEMATICS KINEMATICS_COREXY

[/code]

Zoom sur l'entrainement
Zoom sur l’entrainement

Après, il faut calculer le nombre de pas par mètre (comme je suis gentil je vous ai fait un calculateur sur une page web), et indiquer les vitesses maximales; là, on peut y aller franco:

[code]

define    MAXIMUM_FEEDRATE_X        20000

define    MAXIMUM_FEEDRATE_Y        20000

define ACCELERATION 2500.

[/code]

Après avoir configuré Teacup, premier test avec les connexions par défaut:

Moteur A AIO0 : X_STEP_PIN (broche STEP du Pololu A) AIO1 : X_DIR_PIN (broche DIR du Pololu A)

Moteur B AIO3 : Y_STEP_PIN (broche STEP du Pololu B) AIO4 : Y_DIR_PIN (broche DIR du Pololu B)

Surprise : seul le moteur B tourne. Bon…

Je modifie les sorties du moteur A dans la config de Teacup (qui deviennent respectivement DIO2 et DIO3) et les deux moteurs tournent. Youpi!

Petit test de mouvement X et Y avec Repetier-host, et je constate que le X+ et X- sont bien, mais Y+ et Y- sont inversés.

J’intervertis les deux moteurs : Moteur A sur les pins Y, et moteur B sur les pins X. Ça marche!

Trop bien 🙂

Vue d'ensemble
Vue d’ensemble

Vitesse

Maintenant, petit test de vitesse et d’accélération en envoyant des commandes G-Code en direct.

Vitesse : 20’000 mm/min (soit 333 mm/s)

Accélération : 2’500 mm/s²

J’aime autant vous dire que ça envoie le pâté, comparé à ma CNC qui monte poussivement à 3 ou 3.5mm/s !

Débattement

  • Y : 300mm
  • X : 250mm, que je vais pouvoir augmenter en arrangeant mes attaches de ficelle.
Le chariot et ses attaches à la one again
Le chariot et ses attaches à la one again

Conclusion

Il me reste donc à arranger mon chariot pour que les fixations des ficelles soient à la même hauteur que les poulies.

Ensuite, faire un support pour le module laser, et contrôler la précision et la répétabilité selon la vitesse.

Enfin, réfléchir à un plateau Z et un support de moteur qui me permettrait de graver des circuits imprimés.

Et ajouter deux endstops pour la mise à zéro, ce ne serait pas un luxe.

Je viens de réaliser que contrairement à grbl et Marlin, Teacup ne supporte pas les arcs (G2 et G3). Dommage…

Découverte du microcontrôleur ATTINY45

Je viens de recevoir une commande de chez Farnell : deux microcontrôleurs Atmel ATTINY45, deux modules XBee, et une caméra pour brancher sur mon Raspberry Pi.

Depuis un certain temps, je réfléchissais à une façon de faire pour programmer un microcontrôleur et l’utiliser dans un projet sans pour autant acheter à chaque fois une carte Arduino. En fait, on peut utiliser toute une gamme de microcontrôleurs Atmel « nus », les programmer à l’aide d’une Arduino et les utiliser tels quels!

Pour les curieux, voici tous les produits fabriqués par Atmel (ça ne s’arrête pas aux microcontrôleurs).

Bref! Voyons comment utiliser notre carte Arduino Uno pour programmer le ATTINY45. La mise en place est relativement rapide.

D’abord, un grand merci à HighLowTech pour cet article.

L’idée de base, c’est d’utiliser une Arduino (dans mon cas, Uno) qui va servir d’interface entre le PC et l’ATTINY45. Manque de bol, depuis la version 1.0 de l’IDE Arduino, les puces ATTINY ne sont plus au menu :

Pour pouvoir les utiliser, il faut aller chercher ici (pour la version 1.0 ou 1.5, selon la version de l’IDE).

Une fois le zip récupéré, il faut créer un répertoire hardware dans votre dossier de sketches (donc pour moi, C:UsersnicoDocumentsArduinohardware). Dans ce dossier hardware, copier le dossier tiny trouvé dans le zip. On y est presque.

Dans le dossier tiny, il y a un fichier nommé Prospective Boards.txt. Renommons-le en boards.txt tout court.

On relance l’IDE, et là :

Yeaaaah baby! En fait, dans le fichier boards.txt, on peut commenter toutes les puces ATTINY dont on ne veut pas se servir, ça évite de polluer cette liste.

Voilà pour la préparation logicielle 🙂

Maintenant, préparons le matériel:

tuto-programmation-des-attiny45-avec-un-arduinoJ’ai honteusement repris le schéma réalisé par Semageek.com. Allez-y, ça vaut le coup!

Voici le schéma de brochage de l’ATTINY45:

Pour le condensateur connecté au reset de l’Arduino Uno, je n’avais pas de 10µF, alors j’ai utilisé un 33µF qui va tout aussi bien.

Prêts? Alors dans l’IDE, chargeons l’exemple ArduinoISP. Nous voulons l’envoyer sur la Uno, donc type de carte > Arduino Uno.

On envoie le programme, et là… Problème de synchronisation. Hé hé hé 🙂 La blague, c’est qu’il faut enlever le condensateur pour pouvoir envoyer un programme 😉

Voilà, l’Arduino Uno est maintenant utilisable comme programmateur pour notre ATTINY!

Nous pouvons reconnecter le condensateur, et dans l’IDE, définir comme type de carte : em>ATTINY@1MHz, et comme programmateur : Arduino as ISP.

Chargeons un programme d’exemple, disons Fade. On va juste changer le pin de la LED, mettons le sur 0. On upload le programme. Dans les messages de l’IDE Arduino, on peut lire ceci :

En fait, ce message, selon des gens avertis, on peut l’ignorer (je ne sais pas vous, mais moi j’ai bien envie de les croire).

Voici une superbe photo pour illustrer cela!ATTINY45-2J’ai connecté la LED bleue au pin 0 (broche 5) de l’ATTINY45. Et elle clignote en mode ‘fade’ 🙂

Pour être sûr, j’ai tout déconnecté (en me servant juste de la Uno comme alimentation :

ATTINY45-1Et ça marche toujours!

Reste maintenant à trouver des applications pour cette bestiole de 4Ko de mémoire, avec ses 3 entrées analogiques et 2 sorties PWM; je suis certain que ça me viendra 🙂

Un grand merci spécial à Michael, Farnell, Semageek et HighLowTech!

Piloter un afficheur LCD avec Arduino

Pour mon baromètre / altimètre, j’avais utilisé un programme fait par je ne sais plus qui (la honte) pour afficher les informations sur un écran LCD 16×2.

Mais j’aime bien faire les choses moi-même, alors j’ai récemment repris la doc de mon afficheur et je m’y suis mis. Finalement, pas bien compliqué!

Le module en question est le ELCD 162, qui dispose d’une communication série à 19200 baud/s.

J’ai écrit une classe qui permet d’initialiser l’engin, de positionner le curseur, d’écrire du texte, de faire un reset, d’afficher ou non le curseur.

C’est assez facile à utiliser. Il faut :

  • Initialiser un port série (j’utilise le SoftwareSerial, comme ça je peux toujours afficher des traces dans l’IDE Arduino avec le port série hardware)
  • Créer un objet LCD, en lui passant notre objet SoftwareSerial
  • Envoyer la purée sur l’afficheur, wouhou!

Voici un exemple de code :

Allez, c’est cadeau !

Voici le fichier la déclaration de la classe :

Et l’implémentation :

Faites-vous plaisir 🙂

*Rhaaaa mais qu’il m’énerve, ce SyntaxHighlighter avec sa perte d’indentation! Tant pis, je laisse comme ça…

Fabriquer un thermomètre / baromètre / altimètre avec Arduino, 2ème partie

Nous avons câblé le capteur, il ne reste plus qu’à écrire le programme qui nous permettra d’obtenir la température, la pression atmosphérique et l’altitude.

La première chose à faire, c’est de pouvoir communiquer avec le module BMP085. Nous aurons besoin de 2 fonctions de lecture, pour lire respectivement des valeurs de 8 et 16 bits.

Nous sommes à présent capables de lire des valeurs du module. Cool! On va en avoir besoin pour lire les 11 coefficients de calibration, stockés dans l’EEPROM du BMP085. Ces valeurs vont nous permettre de calculer la pression absolue. Il suffit de les lire une seule fois, au début du programme. Nous allons les mettre dans la fonction setup().

 

Une fois que les valeurs de calibration sont lues, il nous faut encore deux variables pour calculer la température et la pression : ut et up. Ce sont les valeurs de température et pression non compensées, notre point de départ pour déterminer les valeurs réelles de température et pression. A chaque fois qu’on veut obtenit la température ou la pression, il faut lire au préalable ces valeurs.

La température non compensée est sur 16 bits (type int), la pression sur 32 bits (type long).

 

Dans ces deux fonctions, nous utilisons la fonction delay() pour laisser le temps au BMP085 de terminer ses traitements.

Le paramètre d’oversampling (OSS) indique au capteur de calculer une moyenne de plusieurs mesures, afin d’avoir une précision accrue. Ici, il est désactivé.

La durée d’attente est le maximum indiqué dans le datasheet du module, mais nous pourrions à la place nous baser sur le pin EOC (End Of Conversion) pour connaitre avec précision le moment où le BMP05 a terminé de lire les données. Tant qu’il travaille, le pin EOC est à l’état LOW, et dès qu’il a terminé, il passe à HIGH.

 

Nous avons toutes les variables requises pour calculer la température et la pression. Dans le datasheet, une formule assez cool nous donne la température, et une autre, beaucoup, beaucoup plus barbue, nous donne la pression.

Merci à Jimbo, chez Sparkfun, d’avoir transcrit tout ça en C, ça fait vraiment plaisir 🙂

 

Bon alors là, on est pas mal ! Encore une fonction pour calculer l’altitude à partir de la pression :

 

 

Calculons tout ça dans la boucle principale, et envoyons les résultats dans le port série:

 

 

Et voilà la sortie, au chalet, par cette soirée de février :

Ce qui est assez réaliste aujourd’hui, puisqu’on estime être à 930 m rééls. Mais selon la météo, on se retrouve dans une fourchette de 870 à 1000 et quelques…

 

Je tiens une fois encore à remercier l’article de SparkFun, dont cet article est essentiellement une traduction. Je vous invite à le lire pour plus de précisions. Sans lui, je me serais tapé la tête contre le lambris… J’y serais probablement arrivé, mais en beaucoup plus de temps 🙂