Précipitation : Les oubliés pourrait être le titre de ce chapitre. Le thème précédent commençait péremptoirement par l’assertion : il faut absolument consacrer du temps pour déterminer relativement finement ce que l’on désire exactement. Et bien cette section à pour but d’illustrer « le manque à gagner » si l’on bâcle cette étape primordiale. En effet, nous allons voir que si l’on avait muri un tout petit fifrelin « le cahier des charges », notre produit serait nettement plus riche. Dans ce but on va téléverser P06_Demonstrateur_B_pour_V1.ino identique à P05 mais dans lequel quelques idées nouvelles ont apporté des perfectionnements et surtout dévoile quelques techniques de programmation supplémentaires et très commodes.
Doubler par logiciel le nombre de touches d’un clavier.
Parmi les techniques de programmation que je vous propose dans ces lignes, c’est l’une des plus séduisante à retenir à mon avis, et j’en abuse souvent. L’idée initiale est simple et fait appel à la notion de clic court et de clic long. (En fait je n’ai rien inventé, puisque sur les claviers d’ordinateur, avec un clic court on frappe une lettre, avec un clic long la touche passe en répétition.) Cette technique est très avantageuse et s’applique aussi bien à un B.P. isolé qu’à un clavier multiplexé.
C’est expérimentalement que l’on définit la durée de 0,8S à partir de laquelle l’analyse transite de Clic court vers Clic long. Pour illustrer ce propos, nous allons ajouter à notre démonstrateur une option gadget. Durant les essais qui précèdent, j’ai été séduit par les battements de cÅ“ur de la boucle de base. Cependant, durant des heures ce petit Tic/Tac peut devenir insupportable. D’un autre coté, le supprimer me « chagrine » un tantinet. Aussi, pour résoudre cette contradiction, il suffit de basculer sa présence en option. Mais je ne désire pas encombrer la façade d’un B.P. supplémentaire. C’est précisément ici que doubler artificiellement le nombre de touches matérielles prend tout son sens.
Strictement sans rien changer au matériel, téléverser P06_Demonstrateur_B_pour_V1.ino qui apporte à son prédécesseur A un certain nombre de modifications. Avant d’effectuer le changement du skech … vous avez tourné le potentiomètre vers « GND » ! Maintenant, la LED 13 clignote comme avant toutes les secondes confirmant le déroulement de la boucle de base. Toutefois, l’appareil est discret et l’on entend plus battre son petit cÅ“ur. Tester un clic un peu retenu sur le bouton poussoir et au relâcher le « stéthoscope » est redevenu actif. Cliquer plusieurs fois avec insistance pour constater l’effet de bascule et le comportement prévu pour cette option nouvelle. En observant la procédure Traiter_activation_du_BP() vous constaterez que pour mesurer la durée d’appui on réutilise la fonction millis() presque incontournable quand on désire gérer des temporisation sans enliser le logiciel avec delay() qui immobilise le microcontrôleur.
Rampe lumineuse ou index ponctuel.
Variante envisageable, au lieu d’une rampe partant du bas jusqu’à la valeur affichée, on peut se poser la question de l’utilisation d’un index ponctuel. Ce n’est que lorsque les deux possibilités auront été expérimentées que l’on votera pour celle qui nous semblera la plus agréable. Pour ne pas avoir à modifier le démonstrateur, on profitera de l’option de battement du cÅ“ur de la boucle de base pour inverser les deux modes d’affichage. Suite à ce test, pour ma part je préfère la Rampe à l’Index qui correspond mieux au « mercure du thermomètre ». C’est donc cette option qui sera retenue pour la suite.
Fiabilité des mesures.
Comme nous en sommes à imaginer des possibilités pour enrichir notre produit, pourquoi ne pas avertir l’utilisateur que les mesures ne sont pas fiables car l’appareil ne chauffe pas depuis un minimum de deux heures ? Nous savons que le fournisseur du capteur MQ135 précise qu’il faut 24H de préchauffage pour obtenir des mesures certifiées dans la plage de précision du dispositif. Par expérience nous avons diminué cette période à deux heures, valeur qui sera adoptée dans le démonstrateur P06_Demonstrateur_B_pour_V1.ino. L’idée consiste à faire clignoter rapidement la LED 13 tant que deux heures ne se sont pas écoulées depuis le dernier RESET. Chaque redémarrage engendrera ce comportement. Puis, le rythme de croisière sera établi et les changements d’état de la LED Arduino seront effectués une fois par seconde.
PROBLÈME : Pour la mise au point du programme, chaque nouveau test va exiger deux heures. IMPENSABLE ! Aussi, la durée d’attente est fixée dans la constante Duree_chauffage repérée en tête de programme par le classique //@@@@@@@@@@@@@@@@@. Sa valeur initiale est réduite à dix secondes, délai largement suffisant pour vérifier le comportement du logiciel.
Quatre heures correspondent à 4 x 3600 = 14400 secondes. (Fastoche !) Dans le programme « définitif » il suffira de remplacer le 10 par 14400 et le délai d’avertissement sera alors de quatre heures.
Fiabilité de l’appareil dans son ensemble.
Permettre à l’utilisateur de vérifier son produit à tout moment me semble indispensable, tout au moins si ça ne complique pas trop le matériel et surtout s’il nous reste de la place pour loger du programme. Dans la version qui précède, la taille est d’environ 21% de l’espace disponible. Quand on compile P03 pour effectuer les mesures on consomme 24%. Alors nous n’arriverons pas avec cette version à dépasser les 50%. Aussi on peut gaspiller des octets à outrance. D’où l’idée qui consisterait à maintenir dans le matériel un potentiomètre pour pouvoir simuler les trois paramètres. Le bouton de cet organe n’aurait pas forcément sa présence sur la façade, mais sur le coté par exemple.
Comment ajouter une option, sans pour autant exiger un B.P. de plus ? (Car on ne veut pas encombrer davantage la petite face avant de l’appareil.) Il suffit de tripler l’utilisation du B.P. actuel, artifice qui peut s’appliquer également à tout un clavier.
Pour concrétiser ce concept la procédure void setup() se termine par un test pour analyser si le B.P. est actif. Dans ce cas un booléen nommé Mode_TEST est forcé à false ou à true. Noter que ce n’est pas dans la procédure Traiter_activation_du_BP() qu’est géré cette option car elle ne doit être mise à jour qu’une seule fois suite à un redémarrage. Aussi, il faut ajouter un autre booléen BP_actif qui signale que durant Traiter_activation_du_BP() le bouton poussoir était bien dans l’état travail. Dans ce démonstrateur, nous avons ajouté quatre options qui n’avaient pas été envisagées initialement. Aussi, quitte à trouver que j’insiste lourdement, quand on commence 
à élaborer un projet, il est indispensable de mobiliser du temps pour bien le définir et ne pas se précipiter. Ce n’est pas si naturel que ça, car l’idée globale ayant amorcé notre faim, nous avons hâte de nous y mettre au détriment des études préalables. Pourtant ce sont ces dernières qui coûtent le moins, car on n’a pas encore commandé le moindre composant, mais qui engagent le plus l’avenir. Nous avons tous les éléments pour coder la première version de l’appareil. Il suffit globalement de remplacer dans P06 la simulation de la Fig.32 en A par des mesures effectives.
La suite est ici.