Foncer tête baissée dans le développement d’un programme est la technique la plus mauvaise que l’on peut adopter. On commence par un schéma électronique initial. Puis on développe les premières séquences. Les essais remettent en cause les choix initiaux ou font émerger de nouvelles idées. Il faut entièrement revoir l’affectation des broches d’E/S. (Etrées/Sorties) Puis on poursuit sur la lancée pour à nouveau penser à de nouvelles fonctionnalités qui encore obligent à tout remanier. Au final, en écrivant rapidement les premières routines on croit aller rapidement vers notre but, et ne pas avoir suffisamment défini le projet on s’engage dans des pertes de temps considérables. Aussi, avant de programmer il faut absolument consacrer du temps pour déterminer relativement finement ce que l’on désire exactement obtenir et éventuellement en prouver la faisabilité.
Un cahier des charges fonctionnel « ambitieux ».
Par « ambitieux » il faut comprendre que l’on va se faire plaisir au maximum, quitte à réduire les exigences en fonction de la faisabilité et des compromis qu’il faudra consentir au cours des études de faisabilité et des contraintes rencontrées lors du développement. Si la place en mémoire de programme n’était pas suffisante, on abandonnerait certaines fonctions. La Fig.17 présente une idée générale de ce que pourrait être le coffret de l’appareil qui reste relativement dépouillé. En particulier on opte pour une sobriété dans le nombre de boutons de commande en façade.
Liste des fonctions et options envisagées :
01) Limiter à quatre boutons poussoir et un potentiomètre l’encombrement de la façade de pilotage.
02) Présence d’une LED triple pour afficher l’état de l’appareil.
03) Présence d’une LED jaune entre les boutons poussoir pour attester d’un Clic long.
04) Protection de l’entrée si surcharge en tension ou inversion de polarité.
05) Présence de deux LEDs pour indiquer un débordement de trace vers le haut ou vers le bas.
06) Pouvoir passer en pause librement.
07) Envisager la présence d’un petit bruiteur passif pour la gestion du clavier et des incidents.
08) Envisager deux calibres de sensibilité en entrée.
09) Base de temps avec large plage de vitesses d’échantillonnage.
10) Synchronisation du déclenchement en option.
11) Synchronisation avec choix du seuil et de la transition.
12) Fournir en permanence un signal étalon.
13) Pouvoir sauvegarder une trace en EEPROM et la réafficher à convenance.
14) Option d’effacement de la trace présente en EEPROM. (Si place possible en zone programme.)
15) Pouvoir exporter un enregistrement sur la ligne série USB vers le Moniteur de l’IDE.
16) Option d’affichage des états des commandes actuelles. (Synchronisation, base de temps etc.)
17) Enregistrement de « quatre écrans de large » avec affichage fenêtré.
18) Envisager l’indication de la valeur efficace du signal affiché dans la fenêtre.
19) Envisager la sauvegarde en EEPROM de quatre fenêtres indépendantes.
20) Option d’affichage des caractéristiques du signal.
21) Pouvoir postsynchroniser le déclenchement de l’enregistrement par satellite. (Usage de la 4G.)
Manifestement cette liste donne dans la démesure. Le programme aura beau être optimisé à outrance, il est peu vraisemblable que nous puissions satisfaire toutes ce prévisionnel. Toutefois, c’est au tout début d’un projet que l’on doit balayer large quitte par la suite à restreindre les ambitions. Autant il n’est pas dramatique de faire l’impasse sur certains « petits luxes », autant élaborer dès le début un schéma complet pouvant satisfaire tous les critères fait par la suite gagner un temps considérable. Dans cette optique optimiste, nous pouvons passer aux études préliminaires.
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. Dans ce cas l’appareil aura huit commandes par usage de son clavier.
Multiplier par sept (Ou plus.) les commandes de chaque touche.
C’est l’artifice standard omniprésent sur nos appareils lorsque l’on doit gérer des menus conduisant à de nombreuses possibilités. On prévoit dans le projet un codeur rotatif. Généralement on fait usage à un codeur incrémental à encliquetage sans limite de rotation angulaire. Dans notre cas d’une réalisation ludique et modeste, on va minimiser l’investissement en composants. (Clause n°01 de notre cahier des charges.) Comme il faudra impérativement intégrer un potentiomètre pour le traitement des tensions alternatives, autant se servir de la position de ce dernier lorsque l’on veut invoquer une fonction ou une option. Par exemple un clic long sur une touche génère un effet qui sera fonction de la tension potentiométrique. Comme on va le voir par la suite sept « indexages » sont facilement possibles et fiables sur la plage angulaire du potentiomètre. Potentiellement avec quatre touches c’est comme si nous avions un clavier à 28 touches, sans compter que l’on peut faire pareil avec un clic court ce qui double les possibilités. En principe nous en aurons assez. Il aurait été possible de se contenter de seulement deux touches, mais avec quatre l’usage sera plus convivial.
L’attribution des E/S d’une carte microcontrôleur est une phase cruciale qui va induire des conséquences importante pour toute la suite du projet. Si les choix initiaux sont judicieux, nous allons gagner un temps considérable lors de l’élaboration du programme d’exploitation. Aussi, sans être exhaustif, on peut déjà citer plusieurs critères de choix :
Programmer avec méthode : Commencer par vérifier le matériel.
Lorsque l’on va développer le programme d’exploitation de cette petite application on ne veut pas risquer des pertes de temps à rechercher une erreur logicielle, alors que l’un (Ou plusieurs !) des composants à été mal branché. Aussi, concevoir un programme qui permet de vérifier rapidement l’ensemble du câblage est à mon sens un incontournable. « avec méthode » commence par choisir des identificateurs « évidents », la première qualité d’un logiciel quel qu’il soit est sa LISIBILITÉ. Envisager que votre « production » doit être compréhensible par « tous », et surtout par vous si vous devez reprendre l’ouvrage quelques semaines ou quelques années plus tard. Un skech comportera inévitablement des calculs non évidents, ou des astuces d’optimisation. Dans ce cas il sera primordial de les expliciter avec des commentaires. Éviter autant que possible les séquences très longues imposant des défilements du listage sur l’écran de l’ordinateur. Idéalement, une procédure ou une fonction ne devrait « jamais » dépasser en longueur la possibilité d’affichage de l’écran pour avoir toutes les instructions simultanément visibles. Pour illustrer ces conseils nous allons utiliser le démonstrateur P05_Test_materiel.ino qui ne sera pas commenté informatiquement.
Bien que ce ne soit pas une obligation du tout, il est fortement recommandé de placer toute fonction ou procédure avant celle qui y fait appel. Ainsi, en déverminage, on sait que si une séquence est invoquée, il faut la rechercher en amont. Cette recommandation qui est une obligation en langage PASCAL par exemple fait gagner un temps fou quand on dévermine ou quand on améliore un programme « long » c’est à dire incluant des centaines d’instructions.
La suite est ici.
