L’adage populaire « Le diable se cache dans les détails » prend tout son sens dans ce chapitre. En effet, prendre des valeurs de BdT simples dans la progression classique 1, 2, 5 semblait couler de source. L’affichage adopté dans le démonstrateur P12 va pourtant tout remettre en cause !
Les limites imposées par le cadrage de la grille.
Pour des raisons évidentes de simplification du logiciel et de facilité d’interprétation des graphes, le graticule doit afficher un nombre de cases entier aussi-bien en largeur qu’en hauteur. Comme le calibre en entrée est de 5Vcc, il va de sois qu’en hauteur on va privilégier cinq niveaux. Le nombre de PIXELs par graduations sera donc de 64 / 5 =12,8 qui sera arrondi à 12. En largeur, après divers essais, ce qui semblait le mieux correspondait à une grille dont les éléments sont carrés. En largeur on peut donc en placer 128 / 12 = 10,6 arrondi à 10. La Fig.72 représente le coté gauche de la mosaïque de l’écran OLED avec ses 64 PIXELs de hauteur numérotés 0 à 63. La plus grande hauteur qui sera disponible pour représenter la courbe du signal sans avoir des points cachés par le cadre qui lui est réservé sera de 12 x 5 moins un pour la ligne du bas du cadre. On aura donc une trace qui sera limitée à 59 PIXELs en hauteur.
Pour la largeur on va retrouver une disposition analogue. Les dix graduations de large repérées en verts clair sur la Fig.73 totalisent 12 x 10 = 120 PIXELs. Toutefois, la dernière « colonne graduée » voit son coté droit coïncider avec le cadre repéré en violet pastel. La largeur totale du cadre violet fait donc 121 pavés de largeur et il s’étend des verticales de mosaïques numérotées de 0 à 120. Comme il ne servirait à rien de tracer la courbe du signal « derrière » le cadre, cette dernière en largeur n’occupera que 119 luminophores de la colonne n°1 à la colonne n°119.
Avec des enregistrements qui ne font plus que 476 échantillons on réduit de 36 OCTETs l’encombrement du tableau de stockage. C’est particulièrement avantageux en mémoire dynamique car on réduit d’autant le risque de collision entre la PILE et le TAS sans compter que les temps de traitements à tous les niveaux seront diminués globalement d’environ 7% ce qui n’est pas totalement négligeable, en particulier pour les écritures en EEPROM. Enfin, ces 36 OCTETs en mémoire non volatile seront les bienvenus pour y loger du texte. C’est tout bénéfice !
Nous pouvons constater en tête du listage de P12_AFFICHAGES.ino que l’estimation de la taille des séquences utiles pour l’affichage titille les 4380 Octets de programme et gloutonne environ 14% de l’espace programme disponible. Cette boulimie est assez normale et classique. La génération d’une page écran comme celle de la Fig.65 accompagnée de diverses options impose toujours pas mal de traitements consommateurs de place. Il n’y a donc pas lieu de se formaliser.
Remise en cause des valeurs de la BASE de TEMPS.
Lorsque le démonstrateur P10 a été développé, nous avons choisi des valeurs pour la BASE de TEMPS qui semblaient parfaitement logiques. Hors elles étaient supposées définir la durée entre la saisie de deux échantillons. Il se trouve que l’affichage de la courbe avec une belle grille de repérage des valeurs va chambouler la donne. En effet, ce qui intéresse l’utilisateur c’est l’intervalle de temps correspondant à un « carré en largeur de la grille ». Si par exemple comme sur la Fig.74 la valeur de la BdT affichée est de 5mS, l’opérateur va en déduire que ce temps représente la durée pour un carré de la grille. Comme dans cet exemple une période du signal occupe 5 carrés, l’usager en déduira que la période de la sinusoïde fait 25mS et que la fréquence de ce signal fait 40Hz.
Une CAN avec amplification associée à la sauvegarde de la valeur consomme environ 112µS. De ce fait, le plus court délai pour une graduation de la grille sera de 112µS x 12 échantillons entre deux graduation soit environ = 1,34mS. Les BdT exprimées en µS ne sont plus réalistes. La cadence d’échantillonnage la plus rapide conduira à une BdT de 1.34mS par graduation valeur indiquée par le logiciel. Pour calculer la valeur de la base de temps il faut raisonner sur la largeur complète de la grille soit 121 PIXELs. La valeur du délai pour respecter les BdT exprimées en mS mais utilisant l’instruction delayMicroseconds() se calcule avec la formule :
Les BdT en secondes ne présentant pas un réel intérêt. Du coup les seules unités qui subsistent sont les mS, ce qui va simplifier le logiciel d’application et en particulier la routine d’affichage.
La refonte des séquences de la BASE de TEMPS.
Avant de consacrer du temps à la procédure de saisie des échantillons qui sera certainement assez complexe pour la mise en Å“uvre de la synchronisation, il me semble préférable en préambule de réaliser un autre démonstrateur qui intègrera la procédure simplifiée de l’affichage graphique et la nouvelle séquence du menu de la BASE de TEMPS qui tient compte du tableau de la Fig.75 en optimisant au maximum, on s’en doute, le code de l’ensemble. C’est le démonstrateur nommé P13_BdT_optimisee.ino qui se charge de cette mission. Comme il intègre deux protocoles d’utilisation de l’oscilloscope, il émule un petit MENU de BASE et comme P12, il génère une trace fictive qui dans cet exemple simule un sig
nal binaire qui permet lors des manipulations de mieux cerner l’avantage du mode « surface ». En effet, bien qu’affiché sur la Fig.76 en A le signal est totalement masqué par le graticule alors qu’en B il est parfaitement « présent ». Naturellement, cette fois les valeurs de la BdT sélectionnées par l’utilisateur sont celles relatives à l’intervalle d’un carré sur le graticule. Pour optimiser le code, on se contente lors de la sélection de la BdT d’en représenter la valeur par un Indice nommé I_BdT. Cet indice simplifie la visualisation de l’écran graphique et la saisie des valeurs temporelles. Il permettra en outre de sélectionner dans une liste de constantes les valeurs des délais découlant des calculs de la Fig.75 rangés dans un tableau de constates. Par raison d’homogénéité des commandes dans ce démonstrateur, le retour au MENU de BASE se fait avec la touche DROITE en clic long pour les deux sous-menus. La simplification de la gestion du temps n’ayant que des BdT indiquées en mS et l’abandon des durées supérieures à 500mS engendre un gain de place d’environ 1760 octets ce qui est considérable. Évolution du logiciel adoptée !
La suite est ici.
