11) La der des der !

Parallèle un peu osé, j’oserais dire que la programmation et la guerre ont un point commun. La modification ultime est la der des der. Malheureusement, force est de constater que pour les déchirements en ce bas monde, un nouveau vient toujours remplacer le dernier. Le programme est terminé, il tourne comme une planète sur son orbite. On peut enfin passer à autre chose. Et puis Pafffff, c’est l’idée géniale qui surgit. Le « dommage que je n’y ai pas pensé avant ». En puis mince … on craque et on remet ça. C’est ce qui c’est passé lorsque je rédigeais ce didacticiel. Au moment d’aborder le chapitre sur les regrets, j’ai basculé du coté obscur de la force et décidé d’ajouter une nouvelle fonction. Pas vraiment une révolution, mais un petit plus bien commode.

Check-list pour le préambule.

Trop souvent, au moment où l’on teste un fichier que l’on va soumettre à la pyrograveuse, on se rend compte qu’avec toutes les manipulations effectuée, à un moment où à un autre on a loupé un détail. Il n’y a plus qu’à tout recommencer. Aussi, un module d’aide qui pas à pas nous imposerait d’initialiser tous les paramètres du futur texte serait bien appréciable, surtout quand on n’a plus utilisé le compilateur depuis trois mois. L’idée est simple : Les commandes du début ont été un peu chamboulées pour dégager une lettre de commande possible. La commande retenue est « $H«  pour HELP. La Fig.39 donne une idée du déroulement « linéaire » des opérations. Comme on enchaîne ensuite plusieurs actions, pour ne pas se fourvoyer le programme exige en 1 une confirmation. Si on valide, alors point par point on va devoir « remplir les cases ». Avant d’obtenir ce comportement du programme, il faut ajouter, on s’en doute, le code nécessaire au listage source. Hors la débauche de consommation d’octets pour remplir la mémoire de l’ATmega328 ne laisse plus assez de place. Avec cette manie de vouloir remplir totalement la zone flash, quand on veut modifier le programme, il faut faire de la place. Fastoche … on enlève l’une des deux fleurs dans les commandes surprise dont il sera question au prochain chapitre et basta, de la place on en retrouve à revendre.
Hips, je l’aimais bien cette fleur surprise, c’est bien dommage …

Lorsque l’on valide cette fonction en 1, l’enchaînement des séquences est inexorable, sauf si l’on écourte la procédure en déclenchant un RESET. En 2 le programme nous demande le numéro de l’image. Tout autre symbole qu’un chiffre compris entre 0 et 9 provoquera un BIP d’alerte et attendra un nouveau caractère. Le titre que l’on désire donner au fichier.gco est saisi puis analysé. S’il est trop long il sera tronqué à 16 caractères puis affiché en 3. Comme il peut de ce fait ne plus correspondre à ce que l’on désire, le programme va boucler en 3 jusqu’à ce que l’on valide en 4 par oui. La saisie enchaîne alors sur les deux options d’encadrement en 5 et en 6 attendant comme réponse un ‘o‘ ou un ‘n‘. Enfin on termine en 7 par la valeur de la grandeur souhaitée pour les caractères. Tant que la réponse ne sera pas comprise entre 1 et 9 il y aura génération d’un BIP d’alerte et attente en saisie d’un nouveau caractère.

Entièrement renseigné pour les diverses options du texte à pyrograver, en 8 le programme nous informe que d’autorité il valide les coordonnées optimales pour la position de l’Origine Image et en 9 liste les diverses données pertinentes. Sans qu’il ne le précise, il sauvegarde ces données utilisateur. Si on valide par erreur un texte nous savons que les données de base sont réinitialisées. De ce fait on perd celles qui étaient présentes. Il suffit d’envoyer la commande « $r«  pour les retrouver. Action :
• RESET sur le compilateur puis « $h«  suivi de ‘o‘.
• Pour l’exercice proposez les valeurs de la Fig.39 comme paramètres souhaités.
• Quand en 10 on poursuit les saisies proposer « $z«  pour réinitialiser les valeurs par défaut.
• Enfin, la commande « $r«  restitue les valeurs sauvegardées par la fonction « $s« .

Les mystères de la programmation sont impénétrables !

Certainement que vous avez remarqué ces informations assez incongrues et étranges coloriées en gris et repérées 11 sur la copie d’écran. Ces valeurs entre parenthèses comme (111) ou (110) suivent l’affichage du caractère qui a été frappé lorsque l’on doit répondre par ‘o‘ ou par ‘n‘. Si vous utilisez d’autres caractères, ces nombres changent et vous allez vous rendre compte qu’il s’agit en réalité des codes ASCII des caractères précisés en décimal. Autant dire que pour l’aspect opérationnel on peut se passer royalement des ces informations « parasites » qui surchargent inutilement l’affichage. Et bien … on va les conserver sauf si Kékun trouve la solution !
L’origine de ce problème réside dans la procédure void Attendre_o_ou_n() qui du reste intègre des commentaires pour préciser l’étonnant problème.
Impossible de faire fonctionner correctement le test if (!(Caractere == ‘o‘ || Caractere == ‘n‘)) si l’instruction n’est pas précédée de la ligne de code Serial.print(byte(Caractere)) alors que fondamentalement cette dernière ne modifie aucune donnée. Dans le test j’ai tenté de remplacer ‘o’ par byte (‘0‘), char(111), toutes les variantes qui me sont venues à l’esprit, rien à faire. Le test ne se comportait pas correctement. Du reste c’est par hasard en faisant afficher les codes ASCII pour visualiser des valeurs nulle, vides etc lors de la recherche de l’origine de ce problème que j’ai trouvé cette solution. Ce n’est pas idéal, ça manque d’élégance … mais ça fonctionne. On persistera à conserver ce « sparadrap » sauf si une personne trouve une réponse plus logique …

La richesse engendre l’abus et le gaspillage !

Optimisé à outrance, lorsque le programme à été achevé, et que je ne trouvais plus de nouvelle fonctions pour faciliter l’exploitation, une foule d’aides sous forme de textes affichés à l’écran a été ajoutée dans le listage. Restait encore une place considérable non occupée en mémoire électronique. Aussi, n’ayant plus d’idée pour « consommer intelligemment » de la place, j’ai franchi le coté obscur de la force et ajouté les commandes « $1«  à « $7«  qui ne servent qu’à tracer des petits dessins naïfs. Et tant qu’il y avait de l’espace vital, j’ajoutais un nouveau dessin. Ce ne sont que des petits plaisirs sans plus, la cerise sur le gâteau, le luxe, une orgie déliresque !

Grosse bêtise issus d’une frénésie de consommation d’octets, vouloir absolument saturer la mémoire de programme de l’ATmega328 a fait perdre la raison. Idée un peu brutale et non réfléchie, tête baissée j’ai programmé les petits dessins directement par les coordonnées des points à joindre pour construire les petites surprises. Hors chaque point à préciser impose deux floats soit 64 octets. Avec cette stratégie seuls deux dessins étaient possibles, et j’avais vraiment envie d’en avoir deux ou trois de plus. C’est à ce moment là que l’exagération de floats à révélé un manque sérieux de réflexion, car pour le codage des caractères il était évident que les valeurs des déplacements pouvaient se coder sur des bytes. Au prix d’une refonte complète des séquences de code concernées, maintenant on dispose de sept petits dessins « libres ». Libre veut dire ici que leur codage est structuré de façon à ce que vous puissiez facilement les remplacer par les vôtres.
Le menu de la Fig.20 a un peu évolué et devient celui de la Fig.40 pour prendre en compte ce complément « artistique » logé dans le programme. Dans la zone des diverses Consignes opérationnelles a été ajoutée et délimitée la section rose clair Z qui affiche l’inventaire de ces petits dessins. Sur la version personnelle j’ai également « $0 » qui trace mon avatar en tout petit, logo qui ne vous concernera certainement pas raison pour laquelle dans le logiciel mis en ligne l’appel à void Minuscule_Avatar() est passé en remarque. Le valider dépasse les 30720 octets de disponibles. Sur le logiciel personnel je me suis contenté de passer en remarques les commandes « $b«  et « $o«  et d’enlever les deux lignes d’affichages sur la Fig.40 dans la zone des Consignes d’aide au Programmeur pour que ce minuscule logo soit possible.

Les petits et les grands.

Toute une famille est disponible pour chaque dessin. Dans le codage des tables de coordonnées les valeurs des déplacements relatifs sont doublées par rapport à ce que l’on désire pyrograver. Ainsi, en divisant par deux au moment de piloter le traçage, on dispose des demi-millimètres tout en codant ces mouvements avec des bytes. (On divise ainsi par 32 la place occupée en mémoire par chaque petit dessin.) Comme on disposait d’espace programme à profusion, il aurait été dommage de ne pas en profiter pour que le coefficient Grandeur soit pris en compte. Du coup chaque dessin est potentiellement disponible en neuf tailles différentes … à condition toutefois qu’en augmenter les dimensions ne déborde pas de la surface opérationnelle du LASER.

Les mensurations possibles.

Chaque dessin élémentaire possède des dimensions en largeur et en hauteur qui lui sont propres. Les plus petits ne déborderont pas des limites machine y compris en Grandeur = 9. Ce ne sera vrai que si l’Origine Image est correctement placée. Par exemple testez l’expérience suivante : « $g9« , suivi de « $7«  qui va tracer la note de musique en taille maximale. Examinons sur la Fig.41 le déroulement des événements. En 1 la commande « $g9«  impose un facteur Grandeur de 9, c’est à dire le maximum possible. Sur RESET l’Origine Image sur Y’Y est de 190. Comme à cette taille les caractères déborderaient vers le haut, d’autorité en 2 le programme descend la valeur à 157.0 comme visible en 3. Puisque le programme a pris une initiative, il le signale par les affichages, et pour attirer l’attention de l’opérateur il génère un BIP sonore. À partir d’ici, en 4 il y aura rappel de cette valeur puis en 5 le programme attend une nouvelle commande. En 6 on frappe la commande « $7«  qui demande de compiler le petit dessin ainsi référencé. Immédiatement le logiciel calcule la largeur et la hauteur de cette image qui seront égales à celle de base multipliée ici par 9 la valeur de Grandeur. Les dimensions « hors tout » sont alors affichées en 7. (En taille unitaire la petite image fait 6mm x 10mm d’où les valeurs calculées en 7 sur la copie d’écran.) Pour aider au maximum l’opérateur, dans toute la zone rose 8 le programme calcule les positions extrêmes de l’Origine Image pour tous les coefficients d’agrandissements possibles. Si la plus grande taille compatible avec les performances de la machine est inférieure à neuf, seules les lignes valides seront affichées. Par exemple sur la Fig.44 la tulipe la plus grande possible est obtenue avec l’amplification de cinq. Seules les cinq premières lignes sont affichées.

Toujours dans le but d’assister au maximum le travail de l’usager, le programme se rend compte qu’avec une ordonnée de 157.0 on va sortir des limites de la machine, en 9 un message d’alerte est déclenché. L’opérateur sait qu’il importe de diminuer sur Y’Y la valeur de la position de l’Origine Image avec un maximum à ne pas dépasser de valeur 112.0 pour la Grandeur adoptée de 9. Rien n’interdit naturellement de choisir une valeur plus faible comprise entre zéro et e seuil critique de 112.0. Puis en 10 le programme résume les conditions actuelles et en 11 attend une nouvelle commande. On remarquera au passage que c’est l’opérateur qui reste maître de la position de l’objet cible sur le plateau de la machine, le programme ne fait que fournir des informations pertinentes.

Noter au passage que le titre de l’image est intégré dans la description des divers points qui la composent. On reste toutefois maître du numéro de l’image qui sera indiqué dans le fichier graphique. Il sera donc avantageux de commencer par la commande « $iN« . Le titre de l’image est contenu dans sa description et sera utilisé dans le fichier.gco. Toutefois, le titre actuel n’est pas perdu. Faisons une expérience élémentaire. RESET sur le microcontrôleur suivi de « $p«  pour purger l’écran. Enchaînons les commandes « $i3«  accompagnée de « $tBonjour.«  sans sauvegarder. Puis on impose « $y50«  pour ne pas risquer de débordement vers le haut. Enfin proposons la commande « $7«  qui compile le fichier. On peut vérifier que le titre de l’image en 1 de la Fig.42 est « Noire«  alors que le titre courant affiché en 2 n’a pas été modifié et est resté « Bonjour. » ainsi que le numéro de l’image toujours égal à 3.

Principe du calcul de cadrage optimal des images.

Toutes les origines image sont situées en bas et à gauche du dessins. Aussi, les débordements ne peuvent se produire que vers la droite ou vers le haut, c’est la raison pour laquelle seules les limites Xmax et Ymax sont calculées et affichées sur la Fig.41 en zone 8. Examinons sur la Fig.43 la façon dont sont effectués les divers traitements lorsque l’on saisit les commandes encadrées dans la Fig.44 sur laquelle dans la zone violette se trouve la séquence à copier pour réaliser le fichier image. En 1 et 2 sont visibles le titre et le nombre de lignes précisés dans la table de description du dessin. La grille est composée de carreaux espacés de 10mm, le dessin respecte les proportions. Sur cette vue nous avons tout en bas à gauche l’origine machine en rouge, c’est à dire les coordonnées nulles sur les deux axes. Dans ces explications on prend pour exemple le dessin n°3, soit celui de la tulipe. La plus petite Grandeur conduit à une image de 17mm de largeur et 39mm de hauteur.
Pour la grandeur maximale possible de 5 la largeur passe à 5 x 17 = 85mm et la hauteur devient 5 x 39 = 195mm, valeurs affichées dans l’encadré rose. Le programme pousse au maximum à droite flèche X « contre » la zone limite du LASER. Il en déduit la valeur maximale de l’Origine Image Xmax = 228 – 85 = 143mm. Le dessin est ensuite localisé au maximum vers le haut symbolisé par la flèche Y. De façon analogue nous avons Ymax = 202 – 195 = 7mm. D’où l’Origine Image extrême représentée sur la Fig.43 par le disque violet. Sur ce dessin ont été surchargées les quatre autres grandeurs possibles. Tout en haut à droite on observe en rouge et rose la plus petite dimension correspondant au dessin de base. Dans l’encadré bleu de la Fig.44 on trouve les valeurs imposées par l’opérateur.

Les modifications de dernière minute.

Rédigeant le didacticiel ce qui implique des heures à n’en plus finir, les multiples manipulations peuvent faire émerger un « bug » qui était passé incognito durant le développement. C’est assez fréquent dans des programmes tel que celui-ci comportant un très grand nombre d’instructions. La combinatoire des problèmes potentiels et des cas particuliers non envisagés augmente de façon exponentielle. Aussi, lors des exercices que l’on propose dans le tutoriel on peut découvrir un « couf ». Dans ce cas, la rédaction du didacticiel est suspendue et le programme est remis en chantier.
Par exemple, si vous observez avec une attention particulière la Fig.14, vous allez découvrir que l’encadrement est un peu trop espacé à droite. J’ai remarqué cette verrue tardivement, et expérience à l’appui, traiter l’encadrement et l’option double s’est avéré particulièrement délicat, car un grand nombre de cas particuliers sont à prendre en compte. Bref, certaines modifications ont été apportées au logiciel, du coup il est tout à fait possible que dans certains chapitres la narration ne soit pas totalement conforme à l’actuel logiciel d’exploitation. (Sans compter les vermines qui n’ont pas encore été découvertes !) Par exemple l’invite Saisir une consigne USB : est devenue Saisir une consigne USB > un tantinet plus logique. Des subtilités sont potentiellement non corrigées sur certaines copies d’écran, il ne faudra pas s’étonner parfois d’observer de petites différences.

La suite est ici.