Récemment, les compteurs de vélo dits numériques (ordinateurs de cycle) se sont répandus parmi les accessoires de vélo. Ces appareils sont capables de mesurer de nombreux paramètres, dont les principaux sont la vitesse et la distance. Le principe de mesure de la vitesse est basé sur le calcul de la période de révolution de la roue, et la distance est calculée sur la base de la mesure du nombre de telles révolutions. Souvent, le capteur de révolution des roues est un interrupteur à lames combiné à un aimant sur le rayon de la roue. Selon la fonctionnalité, le prix de ces appareils varie considérablement. Le compteur de vitesse de vélo le moins cher peut être acheté pour environ 500 p.
J'ai toujours eu envie d'avoir un appareil similaire. Dans le même temps, j'ai formulé un certain nombre de mes propres exigences, auxquelles il devrait satisfaire. Tout d'abord, je voulais vraiment voir un graphique des changements de vitesse en fonction de la distance ou du temps accumulé sur une courte période au fur et à mesure de ses déplacements. Et aussi, pour enregistrer (enregistrer) les mesures sur un périphérique de stockage pour un transfert ultérieur des données statistiques vers un ordinateur, leur visualisation plus détaillée. Les modèles bon marché ne répondent pas entièrement à mes exigences, mais je ne veux pas payer trop cher pour des modèles coûteux.
Sur la base de ce qui précède, j'ai décidé de créer mon propre compteur de vitesse de vélo basé sur le microcontrôleur ATmega8. De nombreuses questions ont été posées, notamment sur les périphériques utilisés. Je suis tombé par hasard sur des articles sur l'utilisation de l'écran du téléphone mobile Nokia 3310. Après avoir lu la fiche technique et vérifié qu'il était simple à utiliser, je ne doutais pas que l'indicateur de vitesse serait fabriqué dans le corps du téléphone susmentionné avec son propre écran. Le boîtier est assez bon, et l'appareil lui-même n'est pas difficile à trouver.
En tant que ROM pour l'enregistrement des statistiques de mesure, j'ai décidé de mettre une ROM 24XX512 classique (512 Kbps), qui est contrôlée via l'interface I2C. Je n'ai pas pris la peine d'utiliser une carte mémoire SD / MMC. Une autre fonction importante de l'appareil est la montre. Ils servent à lier certains paramètres spécifiques mesurés (par exemple, la vitesse maximale) à la date et à l'heure, et sont également nécessaires pour enregistrer des horodatages dans les statistiques. En tant qu'horloge, j'ai utilisé une puce d'horloge en temps réel (RTC) distincte du microcontrôleur, qui a une alimentation indépendante de la batterie et communique également avec le contrôleur via I2C.
J'ai implémenté des exigences secondaires supplémentaires dans la fonctionnalité de l'appareil au stade de l'écriture du programme. Cela inclut toutes sortes de problèmes d'organisation: le nombre de boutons impliqués, l'emplacement sur l'affichage de divers éléments, la navigation sur l'interface, etc. En termes de navigation, j'ai décidé à l'avance de ne pas compliquer le programme, par exemple, de ne pas implémenter le menu des paramètres, en particulier les paramètres de date et d'heure. L'horloge est réglée une fois. L'horloge tourne indépendamment dans la puce RTC elle-même, grâce à un quartz à 32,768 KHz et à une batterie qui dure longtemps. Les réglages de la date et de l'heure sont effectués via l'interface UART du compteur de vitesse, connecté au port COM de l'ordinateur en un clic. À travers la même interface, il était censé lire les données statistiques de la ROM sur un ordinateur. Pour tout cela, vous devez écrire le programme approprié pour l'ordinateur. Cependant, comme le montre la pratique, ce dernier a dû être abandonné. Premièrement, il y avait le problème de mettre en œuvre la réception des données du contrôleur vers l'ordinateur au stade de l'écriture d'un programme informatique. Et, encore plus important, le volume du programme pour le contrôleur a augmenté. Il était beaucoup plus intéressant de placer la ROM (dans le boîtier SMIC SOIC-8) sur une plate-forme amovible, proportionnelle à la carte SIM et d'utiliser l'emplacement libre approprié sur le téléphone mobile. Pour ce faire, il est nécessaire de fabriquer un lecteur ROM basé sur un lecteur SIM selon l'un des schémas bien connus du programmeur I2C ROM. Comme il s'est avéré plus tard, cette décision n'a pas causé d'inconvénients inutiles.
Un autre problème important est la sortie d'informations symboliques (y compris numériques) sur un écran graphique. Cela nécessite des informations graphiques sur un symbole particulier. Ces informations sont étroitement liées à un paramètre tel que la taille de la police affichée. Pour afficher le paramètre principal, la vitesse de déplacement, pour une bonne clarté, il est souhaitable d'utiliser une grande police. Cependant, comme nous le montrerons plus loin, de telles informations graphiques sur dix chiffres ne rentreront pas dans la mémoire de MK, et l'utilisation de la même ROM externe plus spacieuse ralentira la vitesse de dessin de la police. J'ai décidé d'utiliser une police d'une hauteur de 8 points comme police la plus grande. J'ai tiré les informations graphiques de cette police du fichier «8X8.FNT» d'un programme de MS DOS, après avoir démêlé sa structure et effectué un traitement ultérieur.
Comme il s'est avéré plus tard dans la pratique, cette taille est assez suffisante pour la clarté de la vitesse. Comme taille pour la police supplémentaire, j'ai choisi la taille 3x5 et dessiné indépendamment les graphiques pour les numéros de cette taille. Ces petits nombres affichent des paramètres supplémentaires: date / heure, vitesse moyenne et maximale, chemin.
Les informations graphiques des deux polices sont stockées dans certains tableaux bidimensionnels. Chaque élément de tableau, d'une taille de 1 octet, indique la distribution de pixels d'une colonne particulière d'un chiffre spécifique. Pour les gros caractères, 8 colonnes sont allouées pour chaque chiffre et 3 pour 3. Pour les petits caractères de taille 3X5, la hauteur formelle n'est pas 5, mais 8 points (arrondi à un octet). Cela vous permet de pré-organiser l'emplacement de la police à 5 positions dans la zone à 8 positions dans le sens vertical en utilisant l'une des 4 méthodes possibles. Ces faits sont bien affichés dans la figure ci-dessous, qui montre la modélisation des graphiques pour les deux premiers chiffres de cette police. Excel est bien connu pour la modélisation. Les données initiales sont la disposition des "unités" dans les champs appropriés pour les graphiques souhaités. Parmi celles-ci, les formules calculent les valeurs des tableaux, jusqu'au code du langage C, qui peut ensuite être copié dans le texte du programme pour le microcontrôleur.
Nous allons maintenant parler des fonctions de contrôle de l'écran utilisé. Cet écran est monochrome et ses dimensions sont de 84 par 48 pixels. Le contrôle de l'affichage à partir du MK s'effectue via l'interface SPI. Les octets transmis par SPI sont interprétés dans l'affichage en deux modes: octets pour l'affichage et octets des commandes de configuration. Ces modes sont définis par le MK lui-même pour une broche d'affichage spécifique (D / C). Une liste complète des commandes est donnée dans la fiche technique à l'écran. Certaines de ces commandes sont utilisées dans mon appareil et sont utilisées pour initialiser l'affichage lorsque l'alimentation est appliquée à l'appareil: coefficient de température, contraste, mode de dessin séquentiel (horizontal ou vertical), etc. Je constate tout de suite que le mode de dessin horizontal est appliqué. Cela signifie que lors du transfert d'un octet en mode d'affichage, l'adresse augmente automatiquement d'une ligne par ligne vers la droite. Lorsque la ligne se termine, l'adresse de position va au début de la ligne suivante. Il suffit d'envoyer d'abord une commande de positionnement spéciale à l'écran à une adresse de ligne et de colonne spécifique (position initiale), puis d'envoyer les octets de données les uns après les autres pour afficher les graphiques. Il convient de noter la caractéristique de l'espace d'adressage et l'interprétation des graphiques, en fonction des octets reçus par l'affichage. Je note que pour les graphiques monochromes, un octet contient des informations sur huit pixels à la fois.
L'affichage en question est divisé verticalement en 6 zones horizontales de 8 lignes chacune (6 * 8 = 48). Chaque colonne de chaque zone correspondra à un octet spécifique, qui sera envoyé avec l'adresse de la colonne correspondante (0 ... 83) et le numéro de zone (0 ... 5). L'adresse n'est pas comptée à partir de un, à partir de zéro. Par exemple, si vous vous positionnez à l'adresse (34; 2) et envoyez un octet de données de 255 (sous la forme binaire «11111111»), alors les 8 pixels s'allument de 16 à 23 verticalement et dans la 35e colonne horizontalement. À mon avis, l'un des inconvénients découle de cette caractéristique: l'incapacité de contrôler l'état de chaque pixel individuellement au niveau matériel. Un octet est la plus petite donnée pour les graphiques. Lorsqu'un octet est transmis à l'adresse actuelle, les 8 pixels correspondants de la zone actuelle sont mis à jour. L'écran ne prend pas en charge la lecture des informations graphiques actuellement affichées vers le microcontrôleur. Par conséquent, si nécessaire, il est nécessaire de stocker à l'avance les informations de sortie dans un tampon dédié et de modifier l'état de tout pixel (bits), d'appliquer des masques de bits pour les octets de ce tampon et de les transférer à nouveau sur l'affichage.
La modélisation et la réflexion sur l'emplacement d'une information graphique particulière sur l'écran ont été effectuées en tenant compte des caractéristiques ci-dessus. Cela a été fait pour simplifier le code lors de l'écriture du programme. Et ce n'est pas par hasard que la taille de la police a été considérée dans la catégorie 8, 16, 24, c'est-à-dire un multiple de 8. J'ai également divisé les informations graphiques, par analogie avec l'affichage, en 6 zones horizontales. Dans la première zone, les valeurs absolues et actuelles (à partir du moment où l'appareil est allumé) sont affichées en petits caractères. Dans la deuxième zone, les valeurs absolues et actuelles du chemin (en kilomètres avec arrondi aux centièmes). Dans la troisième zone - vitesse moyenne. Dans le quatrième - vitesse maximale et en gros caractères - la vitesse actuelle. Dans la cinquième zone, deux barres de progression sont affichées pour indiquer que la ROM est pleine et le nombre d'écrasements. Dans la sixième, dernière zone, la date et l'heure. C'est la cinquième zone qui fait exception lorsque dans la direction verticale de n'importe quelle colonne prise il y a des pixels liés à différentes informations. Par conséquent, ces informations à l'aide de masques de bits sont collectées dans un tampon, dont le contenu est ensuite affiché sur cette cinquième zone. De plus, dans 3 à 5 zones, des informations permettent de tracer un cadre autour de la valeur de vitesse affichée. Dans la dernière zone, chaque premier bit (le moins significatif) de toutes les colonnes est défini sur «1» pour tracer la ligne de séparation (40e ligne). Pour cette simulation et visualisation des adresses, j'ai représenté tout ce qui précède dans des cellules Excel.
Voici à quoi ressemble la première fenêtre d'affichage. Seulement deux fenêtres. La deuxième fenêtre est la sortie du graphique (histogramme) du mouvement. Pour cela, 5 zones sont attribuées (40 lignes) verticalement et les 84 colonnes horizontalement. La sixième zone avec l'horloge est la même pour les deux fenêtres.
Lors de la programmation, j'ai décidé de ne recourir à aucune bibliothèque pour travailler avec cet affichage. Personnellement, il m’est plus facile de comprendre la fiche technique, d’implémenter moi-même une partie des fonctions que de comprendre la bibliothèque. De plus, certains avantages y ont été trouvés. Récemment, après avoir téléchargé une des bibliothèques, j'ai néanmoins découvert ses fonctionnalités. Il est universel, avec son aide, vous pouvez contrôler les pixels individuellement et vous positionner sur la véritable adresse des pixels. Mais la bibliothèque utilise un tampon de 84 * 6 octets, et ce tampon de minuterie est périodiquement envoyé à l'écran, mettant à jour les graphiques. Ainsi, le temporisateur et une partie de la mémoire MK sont occupés. Dans mon cas particulier, il n'est pas nécessaire d'utiliser une bibliothèque, car lors de la modélisation, j'ai pris soin à l'avance de maximiser la séparation des informations entre les zones affichées, qui sont en totale conformité avec les zones d'affichage. Et il n'est pas nécessaire de mettre à jour périodiquement les informations à l'écran: les informations ne sont mises à jour que si et seulement quand elles changent (à chaque rotation de la roue, à chaque pression sur un bouton, etc.). Ainsi, je souligne une fois de plus: selon la tâche, vous pouvez éviter l'utilisation de bibliothèques.
Pour travailler avec un microcircuit d'horloge et une ROM, je n'ai pas non plus recouru à l'utilisation de bibliothèques: toutes les fonctions sont assez simples et implémentées par moi après avoir étudié les fiches techniques de ces composants.
Considérons maintenant le circuit électrique de l'appareil.
La disposition de l'indicateur de vitesse est relativement simple. En plus de tout ce qui précède, le circuit contient un élément IC5 MAX756, qui sert de convertisseur d'alimentation de 3 à 5 volts pour une alimentation fiable à partir de la batterie d'origine du téléphone mobile Nokia 3310. Je n'ai pas mis en œuvre le circuit pour une alimentation de 3 volts en raison du manque de MK et de périphériques appropriés. À l'heure actuelle, je n'ai pas encore acquis le MAX756, et l'ensemble du circuit est toujours alimenté par une batterie externe Krona utilisant le régulateur LM7805 (pas tout à fait la meilleure option). Il se connecte à la prise casque en bas du téléphone. L'interrupteur à lames SF1, qui est un capteur de rotation de roue, est connecté au port d'interruption INT0 MK (broche 32). Il se connecte en toute sécurité du bas du téléphone au port de charge. Les boutons fonctionnels S1-S3 connectés aux boutons «1», «2», «3» du téléphone mobile sont connectés à des ports arbitraires (broches 23, 27, 28). Une broche S4 est connectée à la broche 29 de la réinitialisation MK, qui coïncide avec le bouton d'extrémité supérieur pour allumer le téléphone mobile. Je l'ai fait comme ça. L'appareil lui-même n'a pas de mode veille et se met sous tension. Un écran IC2 et un connecteur pour clignoter X1 sont connectés au port SPI du contrôleur (broches 15-17). Avec le connecteur, que je voulais faire sur la base des «spots» existants sur la carte mère d'origine pour l'appairage avec un PC (au même endroit), j'ai eu un petit hic, et à l'avenir je le transférerai dans un autre endroit. Une interface UART pour la connexion de l'utilisateur à un ordinateur est raccordée au même connecteur, via lequel la date et l'heure sur l'appareil sont configurées (broches 30-31, RX / TX). L'écran est connecté au contrôleur via des diviseurs sur des résistances, qui servent à réduire la tension, car l'écran fonctionne à une tension de 3,3 V.En outre, les broches d'affichage D / C (données / commande), SCE (stroboscope) et RES (réinitialisation de l'affichage) sont connectées à des ports arbitraires MK PB0, PB1 et PB2, respectivement (broches 12-14). L'affichage est alimenté par les diodes D1-D3 et la résistance R6, qui servent à réduire la tension de 5 à 3,3 V, en évitant l'utilisation d'un régulateur linéaire. Le quartz Cr1 cadencé par MK avec une valeur nominale de 4,5 MHz a été choisi au hasard, mais délibérément. Il est juste tombé dans mon bras et j'ai décidé de l'utiliser. Aux ports de MK PD4 et PD5 (broches 2 et 9), des transistors Q1 et Q2 sont connectés, sur lesquels les LED pour le rétroéclairage de l'écran et du clavier sont chargées. Le contrôleur offre la possibilité de contrôler les rétro-éclairages individuellement, comme le prévoit la disposition d'origine du téléphone mobile (c'était au niveau du matériel et non au niveau de l'utilisateur), bien qu'en pratique ce ne soit pas nécessaire. Le bus I2C est connecté aux ports PC2-PC3 (broches 25-26) et, pour plus de simplicité, est implémenté par programme à l'aide de la bibliothèque appropriée (bien qu'il soit connecté aux ports matériels TWI). La ROM IC3 et l'horloge en temps réel (RTC) IC4 sont suspendues sur le bus. Faites immédiatement une réserve pour qu'il n'y ait pas de critique dans les commentaires: je sais que le DS1307 n'est pas la meilleure solution, mais au moment du développement du circuit je ne connaissais pas l'existence du DS3231. La ROM est située sur un connecteur amovible, semblable à une carte SIM. Un port supplémentaire du contrôleur PC1 (broche 24) est utilisé pour recevoir des impulsions d'une fréquence de 1 Hz avec RTC, par lesquelles l'heure sur l'affichage est mise à jour. Tous les composants du kit carrosserie passif - selon les fiches techniques de chaque composant actif.
Tenez compte des considérations mathématiques pour calculer certains paramètres. Comme déjà mentionné au début, le principe de mesure de la vitesse est basé sur le calcul de la période de révolution de la roue, et la distance est calculée sur la base de la mesure du nombre de telles révolutions. Le contrôleur mesure le temps entre l'impulsion précédente et l'impulsion entrante du commutateur à lames. Le résultat de la mesure est converti en valeur de vitesse en divisant la valeur du périmètre de la roue par la période de révolution, et cette valeur est mise à jour sur l'affichage à chaque impulsion (révolution de roue). Il convient de noter ici que, du point de vue de la physique, la vitesse moyenne d'un vélo sur une section de la trajectoire correspondant au périmètre de la roue est calculée. Séparément, le nombre d'impulsions est calculé, puis converti en une valeur de distance. Pour mesurer la période de rotation de la roue, le contrôleur utilise sa propre minuterie. ATmega8 a un temporisateur 8 bits et 16 bits. La plage dynamique de la mesure dépend de la profondeur de bits du temporisateur. Dans mon cas, un temporisateur de 16 bits est utilisé, car 8 bits (256 comptes de comptes) sont catégoriquement insuffisants. La période de mesure maximale (avant que la minuterie ne déborde) correspondra à la vitesse mesurée minimale. Vous pouvez entrer ce que l'on appelle la minuterie logicielle, qui mesurera de grandes périodes. Cependant, pour simplifier le programme, je ne l'ai pas fait. Avec le quartz utilisé de 4,5 MHz et une valeur de diviseur maximale de 1024 dans la configuration de la minuterie, nous avons: (1 / (4500000/1024)) = 0,000227556 sec. Cette valeur correspond à la période minimale du compte. Et la période de compte maximale sera de 0,000227556 * 65536 = 14,913 secondes. La vitesse maximale mesurable correspondant à la période minimale mesurable sera d'environ 30 000 km / h. Cela ne valait même pas la peine d'être stipulé, la «réserve d'en haut» est tout simplement énorme.
Mais la vitesse minimale mesurée correspondant à la période maximale mesurée sera de 2,26 / 14,913 / 1000 * 3600 = 0,54 km / h. Ici 2,26 est le périmètre de la roue de vélo (en mètres) dans mon cas. Je suis assez satisfait de cette valeur mesurée minimale. Si le vélo se déplace à une vitesse inférieure à 0,54 km / h, le compteur de vitesse du vélo enregistrera le manque de mouvement (et le débordement de la minuterie). Avec cette interface UART à quartz de 4,5 MHz, cela fonctionne très bien à une vitesse de 2400 bauds avec une erreur acceptable acceptable. Cette vitesse est également assez suffisante, d'autant plus que j'utilise UART pour les paramètres d'horloge uniques à partir d'un ordinateur (pour copier la date et l'heure d'un ordinateur vers un appareil). Si vous prenez du quartz en fréquence plus élevée, la vitesse minimale mesurable augmentera, ce qui sera inacceptable pour moi,et vous devrez utiliser une minuterie logicielle. Et si vous le prenez ci-dessous, les performances de l'appareil dans son ensemble diminuent. Par conséquent, j'ai décidé de quitter ce quartz particulier.Je note que les valeurs de période et de vitesse sont inversement proportionnelles, et la minuterie du microcontrôleur mesure la période discrètement. Dans notre cas, la plage de mesure (0,000227556 ... 14,913) est uniformément marquée par des points d'un montant de 65535, la divisant en plusieurs intervalles égaux. Et ces points correspondent à toutes sortes de valeurs mesurées. En utilisant la conversion d'intervalles de temps en vitesse, ce système d'intervalles est converti d'uniforme en inversement proportionnel. Par conséquent, la plage de vitesses mesurées de différentes manières est divisée en intervalles inégaux. La longueur de ces intervalles augmente avec l'augmentation de la valeur de vitesse elle-même. Compte tenu de ce fait, l'immense "réserve d'en haut", sur laquelle j'ai écrit un peu plus haut, ne fera pas défaut. En pratique, il suffira de prendre la valeur de 100 km / h pour la vitesse maximale mesurée du vélo.Il s'agit simplement de ne pas introduire de nouveau chiffre (des centaines) et de ne pas augmenter la largeur du paramètre affiché à l'écran. Nous calculons ce que la longueur de l'intervalle entre les valeurs possibles adjacentes à une vitesse voisine est égale, par exemple, à 90 km / h. En utilisant les formules inverses ou la sélection, il est facile de calculer que pour la valeur du temporisateur 397 (sur 65536 possible) la vitesse mesurée correspond à 90,06 km / h. Et avec une valeur de minuterie voisine de 398 - 89,83 km / h. Et la différence entre les vitesses est de 0,23 km / h, ce qui est déjà plus qu'acceptable. Et à des vitesses inférieures, cette différence sera encore plus petite. L'écran affiche la valeur de la vitesse au centième près. Cependant, dans la pratique, l'arrondi à l'entier le plus proche ou aux dixièmes suffit généralement. De ce qui précède, nous pouvons conclure: la non-uniformité de la «grille» des vitesses peut être négligée,car l'erreur de mesure qui en résulte ne dépasse pas l'erreur tolérée.Pour calculer la distance, il suffit de multiplier le nombre d'impulsions (tours) par le périmètre de la roue. Dans ce cas, bien sûr, la distance est calculée avec précision au périmètre de la roue, ce qui est tout à fait acceptable. La vitesse moyenne actuelle est calculée comme le rapport de la distance actuelle parcourue à la valeur de temps à partir du moment où elle a été allumée. C'est le temps que le contrôleur considère en comptant le nombre d'impulsions arrivant une fois par seconde avec RTC. La vitesse moyenne sur l'écran est mise à jour avec la mise à jour de l'heure (une fois par seconde). Tous les autres paramètres sont mis à jour à chaque tour de roue.Maintenant sur les petites fonctionnalités de l'interface. Le premier bouton permet de changer de mode (mode graphique ou mode d'affichage des valeurs). Le deuxième bouton - pour afficher la vitesse maximale absolue (pour tous les temps) au lieu de la relative lorsque vous la maintenez. De plus, la date et l'heure pour atteindre cette vitesse sont affichées à la place de la date et de l'heure actuelles. Et aussi, la valeur de l'adresse ROM actuelle est affichée à la place de la valeur de la vitesse relative (pour le contrôle). Cette valeur peut être estimée par la barre de progression horizontale sur la 38e ligne de l'écran. Sur cette ROM, d'une capacité de 65536 octets (512 kbit), les paramètres mesurés sont enregistrés. Comme on le dira plus loin, il suffit d'enregistrer le paramètre initialement mesuré (la période de rotation de la roue) avec une marque du temps initial.Tous les autres paramètres sont facilement calculés par un programme informatique au stade du balayage de la ROM. Le troisième bouton est utilisé pour contrôler le rétro-éclairage. Contrairement à l'esquisse d'écran ci-dessus, j'ai supprimé plus tard des zéros insignifiants sur les paramètres secondaires pour les afficher plus clairement. En mode graphique, un histogramme de la vitesse de déplacement est tracé de gauche à droite, ce qui montre clairement le processus de changement de vitesse sur une petite portion de la distance de 84 tours de la roue. La valeur de l'histogramme est la vitesse à une échelle de 1 pixel par 1 km / h. Si la vitesse dépasse 40 km / h, l'image est réduite verticalement de 2 fois pour éviter de sortir de l'échelle. Il n'est pas nécessaire de décrire ici les caractéristiques détaillées du comportement de l'appareil.Plus tard, j'ai supprimé des zéros insignifiants sur les paramètres secondaires pour les afficher plus clairement. En mode graphique, un histogramme de la vitesse de déplacement est tracé de gauche à droite, ce qui montre clairement le processus de changement de vitesse sur une petite portion de la distance de 84 tours de la roue. La valeur de l'histogramme est la vitesse à une échelle de 1 pixel par 1 km / h. Si la vitesse dépasse 40 km / h, l'image est réduite verticalement de 2 fois pour éviter de sortir de l'échelle. Il n'est pas nécessaire de décrire ici les caractéristiques détaillées du comportement de l'appareil.Plus tard, j'ai supprimé des zéros insignifiants sur les paramètres secondaires pour les afficher plus clairement. En mode graphique, un histogramme de la vitesse de déplacement est tracé de gauche à droite, ce qui montre clairement le processus de changement de vitesse sur une petite portion de la distance de 84 tours de la roue. La valeur de l'histogramme est la vitesse à une échelle de 1 pixel par 1 km / h. Si la vitesse dépasse 40 km / h, l'image est réduite verticalement de 2 fois pour éviter de sortir de l'échelle. Il n'est pas nécessaire de décrire ici les caractéristiques détaillées du comportement de l'appareil.La valeur de l'histogramme est la vitesse à une échelle de 1 pixel par 1 km / h. Si la vitesse dépasse 40 km / h, l'image est réduite verticalement de 2 fois pour éviter de sortir de l'échelle. Il n'est pas nécessaire de décrire ici les caractéristiques détaillées du comportement de l'appareil.La valeur de l'histogramme est la vitesse à une échelle de 1 pixel par 1 km / h. Si la vitesse dépasse 40 km / h, l'image est réduite verticalement de 2 fois pour éviter de sortir de l'échelle. Il n'est pas nécessaire de décrire ici les caractéristiques détaillées du comportement de l'appareil.Il convient de noter l'une des différences caractéristiques entre mon compteur de vitesse et acheté à bas prix. Elle consiste en la vitesse de mise à jour de l'indication de vitesse sur l'afficheur. Dans mon appareil, il est mis à jour immédiatement, tel que calculé, à chaque rotation de la roue. Dans les appareils achetés, il est mis à jour avec un certain retard. Ce retard est peut-être dû à une tentative de filtrage du bruit de mesure (par exemple, en utilisant la méthode de la moyenne mobile) afin de stabiliser l'affichage de la vitesse sur l'affichage pour une clarté plus détaillée. Ou peut-être que l'affichage est complètement mis à jour à intervalles réguliers (par exemple, deux fois par seconde). Cela peut être pratique, mais je voulais implémenter une mise à jour de la vitesse à chaque révolution de la roue.La carte de circuit imprimé est réalisée par la méthode LUT sous la forme de la carte de circuit imprimé d'origine du téléphone mobile utilisé. Dans la fabrication du circuit imprimé, j'ai utilisé le programme SLayout. En même temps, j'ai pris à l'avance une photo de la carte d'origine des deux côtés du scanner et j'ai mis les images dans SLayout comme modèle. Cela est nécessaire pour dessiner des pads pour connecter l'écran, les boutons et les connecteurs aux endroits exclusivement nécessaires. Lors de la fabrication de la planche, une erreur d'environ 0,5 mm s'est produite. Cette erreur s'est avérée acceptable en termes de combinaison de pads et d'éléments. Cependant, cette erreur a affecté la qualité du rétroéclairage: les LED scellées ont été décalées d'une fraction de millimètres et ne sont pas tombées au centre des mandrins diffusant la lumière. Pour cette raison, la luminosité du rétroéclairage a diminué, ce qui a réduit l'efficacité.Les figures ci-dessous montrent une vue de la carte de circuit imprimé dans SLayout avec trois petites cartes de circuit imprimé pour ROM sous la forme d'une carte SIM. En outre, des numérisations de la carte de circuit imprimé originale de deux côtés sont affichées.
Certains éléments (boutons, connecteurs) sont interconnectés par des cavaliers en fil mince faute de pouvoir tracer des pistes. Il y a une marge pour tous les boutons disponibles, c'est-à-dire qu'il est possible d'utiliser n'importe quel bouton disponible. Il peut être pratique de faire du grand bouton au centre un bouton pour changer les modes d'affichage. Dans le coin supérieur gauche de la carte se trouve une batterie d'alimentation RTC de 3 volts. En général, tous les éléments sur la planche sont placés correctement avec la coordination de leurs dimensions avec les dimensions du boîtier. Contrairement à l'original doré, le panneau interne est enduit de soudure ordinaire. Comme le montre la pratique initiale, le contact avec l'écran et les autres périphériques n'est pas perdu.. , (EEPROM) . EEPROM.
| Address | La taille | Data |
| 0 | 4 | n (for S) |
| 4 | 2 | t_min (for v_max) |
| 6 | 6 | Date of t_min |
| 12 | 2 | Address EEPROM |
| 14 | 1 | EEPROM RW Count |
| 128 | 80 | Digits 8X8 |
| 208 | 30 | Chiffres 3X5 |
Les quatre premiers octets stockent la distance parcourue comme le nombre de tours de la roue. J'ai choisi spécifiquement le type entier 32 bits pour cette variable, car en pratique les valeurs du chemin parcouru sont relativement grandes. Par exemple, une variable entière de 16 bits pourrait enregistrer un maximum de 65 536 tours (environ 148 km), ce qui est naturellement petit. Deux octets suivent pour maintenir la vitesse maximale absolue. En fait, le temps minimum de rotation des roues est enregistré. La variable prend deux octets, car sa valeur est le résultat de la mesure d'un temporisateur 16 bits. Les 6 octets suivants sont la date et l'heure auxquelles la vitesse maximale ci-dessus a été atteinte. Les données sont présentées exactement dans le format dans lequel elles sont lues à partir de la puce RTC (à l'exclusion du jour de la semaine). Ensuite, deux octets qui stockent la valeur de l'adresse actuelle de la ROM externe. Il s'agit d'une sorte de pointeur, qui est nécessaire pour la possibilité de poursuivre l'enregistrement des statistiques sur la ROM après la prochaine mise sous tension de l'appareil. MK doit savoir quelle position de l'espace d'adressage de la ROM externe il a arrêtée pour la dernière fois. À partir de cette position, MK continuera d'enregistrer. Cette valeur est allouée de 2 octets, car l'espace d'adressage de la ROM externe est de 16 bits. Cela découle d'une taille de ROM de 64 Ko. Vient ensuite une variable à un octet qui stocke la valeur du nombre de remplacements de ROM. L'écrasement est le cas lorsque le pointeur ci-dessus atteint la valeur maximale et passe à zéro. Dans ce cas, les informations nouvellement reçues sur la ROM commenceront à être enregistrées dès le début, effaçant les anciennes informations disponibles sur celle-ci. Une variable entière sur un octet est capable de stocker un maximum de 256 valeurs. Je vous rappelle que les valeurs du pointeur d'adresse ROM et le nombre d'écrasements sont visuellement indiqués par deux barres de progression sur l'affichage. De plus, après un grand espace de sauvegarde de l'EEPROM MK, à partir de l'adresse 128, des informations graphiques sur 8x8 chiffres sont stockées. Pour cela, 80 octets sont alloués (8 octets pour chaque chiffre, comme mentionné précédemment). Et enfin, à partir de l'adresse 208, 30 octets sont stockés pour des informations graphiques sur les petits chiffres 3x5 (trois octets par chiffre).
En plus du programme principal pour le microcontrôleur, j'ai écrit trois autres programmes auxiliaires pour l'ordinateur, qui seront discutés ci-dessous. Tous les programmes n'ont pas d'interface graphique et fonctionnent à partir de la ligne de commande de Windows XP.
Le premier programme vous permet de copier la date et l'heure d'un ordinateur vers le compteur de vitesse du vélo via le port COM. Le compteur de vitesse du vélo est connecté à l'ordinateur via la puce MAX232. À l'aide de WinAPI, le programme reçoit la date et l'heure actuelles dans une variable structurelle spéciale de type SYSTEMTIME. Le jour, le mois, l'année, le jour de la semaine, les heures, les minutes et les secondes en format décimal sont extraits de cette variable. Tous ces nombres, à l'exception de l'année, ne dépassent pas deux décimales (moins de 100) et se situent à l'intérieur d'un octet. La valeur de l'année est convertie en un nombre à deux chiffres en lui soustrayant le nombre 2000, la valeur du millénaire actuel. Chacun de ces nombres décimaux à deux chiffres est converti au format décimal binaire caractéristique de la puce RTC. Dans ce format, un nombre à deux chiffres occupe également un volume d'un octet. Les 4 bits les plus significatifs sont codés le chiffre de dizaines, et le moins significatif - le nombre d'unités. Par la suite, un colis de 13 octets est formé à partir de ces numéros, selon un protocole que j'ai déterminé précédemment. Les cinq premiers octets représentent le mot "TIME =" selon le codage ASCII standard. Ensuite, suivez les secondes, minutes, heures, jour de la semaine, jour, mois, année. Le dernier octet est le caractère "#", comme le caractère de la fin du message. Ce package est envoyé de l'ordinateur à l'appareil via le port COM. Le programme du microcontrôleur reçoit le package et vérifie son exactitude, selon le format ci-dessus. Si les cinq premiers octets sont "TIME =" et le dernier est "#", l'envoi est considéré comme correct et les octets à l'intérieur sont interprétés dans l'ordre correspondant. Sans modifier cette chaîne d'octets, le contrôleur l'envoie à la puce RTC via le bus I2C, en la configurant pour la date et l'heure actuelles. Je note que ce microcircuit prend en charge le calcul des jours de la semaine de 1 à 7, bien qu'en tant que calendrier qui détermine la correspondance de la date et du jour de la semaine, il ne l'est pas. Je n'ai pas prévu l'affichage d'informations sur le jour de la semaine dans mon appareil.
Le deuxième programme est conçu pour traiter les données du contenu d'une ROM externe. Initialement, on supposait que ce contenu devait être copié de la ROM vers le fichier image en utilisant un programme bien connu qui fonctionne avec des programmeurs MK et ROM bien connus (par exemple, «icprog»). Cependant, après avoir étudié le principe de fonctionnement I2C plus en détail, j'ai réussi à implémenter cette fonctionnalité et à l'inclure dans mon programme. Le schéma du programmeur ROM de cette série, que j'ai utilisé dans l'appareil, est présenté dans la figure ci-dessous.
La ROM est connectée au port COM de l'ordinateur, qui n'est pas utilisé comme moyen d'échange d'informations via RS-232 (où il suffit d'utiliser les sorties TX, RX, GND), mais comme moyen d'entrée-sortie arbitraire de signaux logiques. Grâce à la borne TX, la ROM est alimentée, qui est stabilisée jusqu'à 5 V par le régulateur 78L05. En contrôlant la sortie TX de l'ordinateur, nous pouvons activer ou désactiver la puce ROM. La ligne d'horloge unidirectionnelle SCL est concentrée sur la broche RTS du port COM, et la ligne de données bidirectionnelle SDA est concentrée sur deux broches: CTS (réception des données) et DTR (transmission des données). Les résistances et les diodes zener D1 et D2 sont utilisées pour limiter le niveau du signal à TTL, sur lequel la ROM fonctionne.
J'ai fait ce programmeur standard pour mon cas spécial, où au lieu d'une prise pour ROM, un lecteur SIM d'un téléphone mobile cassé est utilisé.
Au moyen de WinAPI, le programme accède aux broches du port COM de l'ordinateur, définit les valeurs nécessaires pour celles-ci (0 ou 1) et supprime également la valeur binaire entrante de la ROM de la broche CTS. Sur la base de cette boîte à outils, la fonctionnalité I2C a été implémentée conformément aux spécifications pertinentes, sur lesquelles je n'entrerai pas dans les détails. Le programme peut lire le contenu de la ROM dans une image de fichier (comme un programmeur ordinaire), et également traiter un tel fichier, ou traiter directement les informations de la ROM. Le traitement de l'information consiste à obtenir les fichiers statistiques de sortie dans un format tabulaire prédéterminé sur la base des informations d'entrée de la ROM. Chacun de ces fichiers correspond à un trajet (à partir du moment où le courant est activé jusqu'à la prochaine mise sous tension de l'appareil). Tout d'abord, je décrirai brièvement le format d'entrée que j'ai défini à l'avance. Chaque fois que l'appareil est allumé, deux octets de zéros sont écrits à l'adresse actuelle, qui est lue à partir de l'EEPROM du microcontrôleur. Lorsque la roue commence à tourner (à la première impulsion) après une temporisation ou après avoir allumé l'appareil, la date et l'heure actuelles sont écrites au format décimal binaire (car elles sont stockées dans les registres de la puce RTC). Et puis deux octets de "unités" 0xFF sont enregistrés. Pendant la rotation de la roue, pour chaque k-ème impulsion (k = 2,3, ...), le temps de rotation de la roue entre la (k-1) ème et k-ème impulsion est enregistré sur deux octets (haut et bas). De toute évidence, ces informations sont suffisantes pour relier la distance actuelle (non absolue) parcourue et la vitesse à la date et à l'heure. Le format de sortie est du texte et est un tableau tabulaire dans des fichiers * .csv qui sont ouverts dans Excel en double-cliquant avec la souris. Les lignes de ce tableau correspondent aux révolutions des roues et les valeurs des colonnes sont indiquées ci-dessous.
| ADR | Valeur d'adresse ROM |
| DATE / HEURE | Date et heure de début |
| Déc | Valeur de minuterie décimale |
| le temps | Heure actuelle |
| t | Temps de trajet depuis la mise sous tension |
| v | La vitesse |
| n | La vitesse |
| S | Le chemin |
| un | Le nombre absolu de révolutions (uniquement dans la ROM actuelle) |
| aS | Chemin absolu (uniquement dans la ROM actuelle) |
| n_day | Le nombre de tours pour la journée en cours |
| S_day | Le chemin de la journée en cours |
| v_max | Vitesse maximale pour le trajet en cours |
| av_max | Vitesse maximale absolue (uniquement dans la ROM actuelle) |
| v_mid | Vitesse moyenne pour le trajet en cours |
Une capture d'écran du contenu d'un tel fichier dans Excel est illustrée dans la figure ci-dessous. En outre, des graphiques des changements de la vitesse actuelle, moyenne et maximale dans différentes couleurs dans un système de coordonnées sont affichés. Argument (axe X) - valeurs de vitesse comme données d'entrée. La figure montre les changements de paramètres pour les 730 premières révolutions. La distance parcourue est associée à cette dépendance linéaire variable (730 tours correspondent à environ 1650 m). Par conséquent, nous pouvons dire que les graphiques reflètent la dépendance des vitesses sur la distance (précise à l'échelle horizontale), contrairement à la dépendance traditionnelle de la vitesse sur le temps, à laquelle il convient de prêter attention. Comme déjà mentionné, cette caractéristique est due à l'idéologie et au principe de la mesure de la vitesse par la vitesse des roues. Mais après tout, un certain moment est assigné à chaque révolution de la roue (le moment d'approche de l'aimant et du commutateur à lames). Naturellement, cette séquence d'horodatages n'est pas uniforme. Cependant, pour des raisons de formalité et de commodité, Excel a la possibilité de spécifier un tableau de valeurs d'heure dans le chemin ou l'heure actuelle comme argument pour les graphiques. Mais tout de même, il faut rappeler que la réelle dépendance de la vitesse sur le temps (à intervalles de temps uniformes pour le cas discret) aurait été différente, avec une échelle horizontale variable.
La figure ci-dessous montre la même dépendance de la vitesse sur les révolutions, mais utilise déjà le filtre en utilisant la méthode de la moyenne mobile avec une largeur de fenêtre de 11 révolutions. Tous les graphiques sont construits dans Excel en utilisant des méthodes bien connues.
En comparant les deux graphiques du changement de vitesse, il est évident que la composante haute fréquence est absente dans le graphique filtré, c'est-à-dire bruit supprimé. La largeur de la fenêtre moyenne mobile de 11 tours (environ 25 m), à mon avis, est trop grande. Si vous vous posez vraiment la question du filtrage des lectures du bruit, alors il suffit de prendre une petite largeur de fenêtre, par exemple égale à trois. Cet algorithme peut être intégré au programme de compteur de vitesse de vélo, car il peut être utilisé non seulement pour analyser les lectures, mais aussi pour afficher ces lectures en temps réel. Malgré la simplicité de cet algorithme, je n'entrerai pas dans les détails de sa description, car ce sujet est traité dans le cadre des mathématiques et dépasse le cadre de cet article. Et voici une autre clarification sur la vitesse moyenne. Comme je l'ai déjà écrit, la vitesse moyenne est le seul paramètre mis à jour non pas à chaque rotation de la roue, mais à chaque seconde. J'ai fait cela pour m'assurer que l'affichage montre un changement de vitesse moyenne même avec un mouvement très lent. Par conséquent, les valeurs des lectures sur l'affichage en temps réel différeront légèrement des valeurs calculées à l'avenir par le programme informatique au stade du balayage de la ROM. Les lectures de la vitesse absolue, du chemin absolu et de la vitesse maximale absolue différeront également. L'écran affiche des valeurs vraiment absolues (pour toute la durée de vie de l'appareil) et dans les tableaux de sortie - uniquement dans les limites de la ROM en cours de lecture.
Le troisième programme, en substance, est le même programme pour le microcontrôleur de micrologiciel. Je travaille avec le programmateur STK 200 le plus simple connecté au port LPT de l'ordinateur, ou plutôt avec son analogue, si vous pouvez l'appeler ainsi, car dans le cas le plus simple, le programmateur ne contient aucun élément actif. En fait, MK via l'interface SPI se connecte directement à des broches spécifiques du port LPT et fonctionne comme esclave. Le programme implémente un protocole d'échange de données avec le contrôleur ATmega8 selon sa fiche technique (p. 237). La couche physique SPI est implémentée en gérant les registres de ports LPT à l'aide de la bibliothèque dynamique bien connue «inpout32.dll». Ma bibliothèque n'est pas connectée en tant que projet (car j'ai évité de créer un projet en tant que tel dans «Dev-cpp» en créant un simple «fichier»), mais en utilisant la fonction LoadLibrary en utilisant le type structurel HINSTANCE. La bibliothèque «inpout32.dll» est mappée à une variable de ce type, et les pointeurs vers les fonctions de cette bibliothèque sont ensuite extraits dans des variables distinctes. Inpout32.dll n'a que deux fonctions responsables de l'entrée et de la sortie des données. Ces fonctions sont accessibles à l'aide de pointeurs pré-extraits. Les broches du port LPT sont contrôlées individuellement à l'aide de masques de bits. Dans mon cas particulier, le programme que j'ai écrit fonctionne avec la zone EEPROM du contrôleur et est conçu pour lire, réserver, écrire, corriger et restaurer à partir d'une copie de sauvegarde des données qu'il contient que j'ai peintes plus tôt. Comme tous les autres programmes, le programme s'exécute à partir de la ligne de commande. Dans de tels cas, pour mettre en œuvre la multifonctionnalité du programme, les fonctions «boîtier de commutation» et une boîte de dialogue utilisateur de texte sont utilisées, par exemple, «entrez« 1 »pour l'opération n ° 1, ..., entrez« 0 »pour quitter le programme.» Les données sont affichées dans différents formats qui me conviennent. En plus de ce qui précède, le programme peut afficher un vidage complet du contrôleur EEPROM en 512 octets à l'écran. De plus, le programme peut enregistrer des informations graphiques sur les polices utilisées dans la mémoire du contrôleur. Dans le cas de petits caractères, taille 3X5, le programme prend les informations du fichier texte "Fonts 3X5.txt", qui se trouve dans le même répertoire que lui. Le fichier contient un tableau tabulaire de 30 octets (3 par 10) écrit au format hexadécimal. Si vous le souhaitez, il peut être facilement édité dans un éditeur de texte, changeant ainsi les graphiques de cette police. Comme déjà mentionné, cette petite impression est si simple que changer ses graphiques n'a pas de sens. La seule chose est que son décalage vertical peut seulement être requis, car il y a un stock d'espace en hauteur de 8 pixels, et la police a une hauteur égale à 5. Dans le cas d'une grande police, taille 8X8, qui affiche la vitesse actuelle, j'ai fourni la fonctionnalité beaucoup plus intéressante. Les informations graphiques sur cette police ne sont pas présentées dans un fichier texte sous forme de tableau d'octets, mais dans des fichiers graphiques BMP visuels. Chaque chiffre correspond à un de ces fichiers. Ses paramètres sont la taille 8X8, monochrome avec une palette noir et blanc. Ci-dessous, une capture d'écran de l'éditeur graphique bien connu "MS Paint" avec le fichier "8.bmp" ouvert.
Empiriquement, j'ai étudié la structure des fichiers BMP monochromes obtenus à partir de MS Paint », et sur cette base j'ai pu apprendre à lire chaque pixel d'une image BMP monochrome (hors utilisation des structures et bibliothèques auxiliaires). Au stade de la lecture horizontale ligne par ligne de bas en haut (c'est ainsi que la structure du fichier BMP est organisée), le programme convertit les informations dans le format vertical spécifique à l'affichage utilisé. Cette opération est effectuée en une seule passe, où les masques de bits et l'accumulation de valeurs variables sont utilisés. Ci-dessous, je vais montrer cette section de code pour le i-ème chiffre, en faisant attention à la simplicité du processus.
for(k=0; k<8; k++){ fnt[i][k] = 0; } for(j=0; j<8; j++){ fseek(f, 62+4*j, SEEK_SET); byte = ~fgetc(f); for(k=0; k<8; k++){ if(byte & pow2(7-k)){ fnt[i][k] += pow2(7-j); } } }
Dans la première boucle, les éléments du tableau fnt sont initialisés à zéro. À l'avenir, chaque k-ème élément de ce tableau (k = 0 ... 7) pour le i-ème chiffre (i = 0 ... 9) portera des informations graphiques sur chaque colonne correspondante de chaque chiffre correspondant. Le cycle suivant est l'exécution le long des lignes de l'image du fichier BMP. Avec l'opérateur fseek, on se positionne en octets à l'offset 62 + 4 * j du fichier BMP prédéfini f. La spécificité de la formule de calcul du décalage en fonction du numéro de ligne j est déterminée par la structure du fichier BMP. Dans la variable intermédiaire d'octet, nous obtenons la valeur d'octet au décalage ci-dessus. Cet octet stocke des informations sur les huit pixels d'une image monochrome dans la ligne actuelle j. L'opérateur «~» effectue une inversion au niveau du bit de l'octet, ce qui entraîne une inversion des couleurs de chaque pixel. Cela est dû au fait qu'un pixel noir dans la palette d'un fichier BMP monochrome correspond à un «0» logique et un blanc - «1». Dans l'affichage appliqué, au contraire. Dans une boucle imbriquée, une analyse d'octets de l'octet se produit et en même temps, les informations sont accumulées dans le tableau de sortie fnt. Fonction pow2 - élevant un deux à une puissance entière non négative, écrite indépendamment. Au lieu de cette fonction, vous pouvez utiliser l'opérateur de décalage au niveau du bit plus efficace «<<», mais au moment d'écrire ce programme, je ne l'utilisais pas.
De plus, le programme offre la possibilité d'écrire dans la mémoire de MK l'une des nombreuses options graphiques pour cette police de mon choix. Ces options sont implémentées à l'aide de répertoires (dossiers) avec un nom de la forme «v1», «v2», «v3», etc., qui se trouvent dans le dossier «Fonts 8X8» dans le même répertoire que le programme. Et déjà dans ces dossiers sont les fichiers BMP nécessaires. Grâce à la fonctionnalité ci-dessus, il est possible de corriger ou de dessiner des nombres à partir d'une «feuille vierge» dans un éditeur graphique, en les sauvegardant et en les répartissant entre les répertoires. J'ai trois options de police. La première option est l'original. Le second - comme l'original, mais avec un zéro barré et une unité modifiée (sans trait de soulignement). Le troisième est une police avec une bordure rectangulaire.
Les photos ci-dessous montrent: la carte de circuit imprimé de l'appareil de l'arrière; un appareil sur la table avec une alimentation connectée (avec une version non finale du firmware); un appareil en fonctionnement monté sur un vélo avec un graphique des changements de vitesse affiché sur celui-ci.
Au cours du fonctionnement de l'appareil, cependant, de petits défauts ont été identifiés associés aux caractéristiques de fabrication. Tout d'abord - mauvais contact de l'écran avec les plots de la carte de circuit imprimé. Dans le téléphone portable d'origine, les contacts de la carte sont plaqués or et il n'y a pas d'oxydation. Dans mon cas, ils sont simplement en conserve.
Sur la base de ce qui précède, il a été décidé de refaire l'appareil dans un autre cas, ainsi que de refaire la carte de circuit imprimé, sur laquelle l'écran sera soudé insolemment. J'ai commencé ce processus récemment. Le résultat est une conception plus robuste.
J'ai fabriqué le boîtier de l'appareil à partir d'un morceau de plexiglas de 17 mm d'épaisseur sur une fraiseuse CNC. Pour ce faire, j'ai préalablement esquissé les esquisses du boîtier dans le programme SPlan, ne connaissant presque pas le sujet des dessins, de la CAO, etc.
Ces esquisses sont nécessaires pour la présentation générale et l'obtention des coordonnées des points de contrôle. Sur la base de ceux-ci, un programme est écrit pour la machine CNC, en tenant compte des principes généraux et des séquences de fraisage. J'ai écrit le programme CNC manuellement dans Excel, en utilisant les fonctions de saisie semi-automatique pour des opérations répétées.
J'ai également légèrement corrigé la disposition de l'appareil, elle est présentée dans la figure ci-dessous.
Au lieu du rétro-éclairage déjà inutile du clavier, il y a une LED pour la beauté qui clignote à chaque tour de roue. Les connecteurs sont également redessinés et aucun autre élément n'était nécessaire dans la version mise à jour de la conception. De plus, j'ai trouvé et installé du quartz à 4,433619 MHz, corrigeant légèrement certaines constantes dans le code source de mon propre programme. Quelques modifications mineures ont également été apportées au programme.
Une photographie du produit fini est présentée ci-dessous. L'appareil est alimenté par une batterie qui se trouve à bord du vélo. De là, l'éclairage est également fourni pour les voyages dans l'obscurité.
C'est dans cette conception que l'appareil a fonctionné complètement sans aucun problème. Le seul inconvénient est l'utilisation d'une puce RTC de très mauvaise qualité: en hiver à basse température, le temps presse, il faut l'ajuster une fois par mois.