A la question de l'AVR et des records du monde

Faites bien, ça va mal tourner

La raison de la publication était récente (lorsque j'ai commencé à rédiger cette publication, elle était vraiment récente, mais quelque chose a duré longtemps dans le dossier Unfinished) sur Habré concernant les aspects de la mise en œuvre du logiciel UART sur le MK d'AVR. Les questions soulevées par elles-mêmes ne sont pas sans intérêt, mais des réponses si étranges sont données qu'elles jugeaient de son devoir de faire les explications nécessaires. Le sujet est marqué, ceux qui veulent lire sur «les rois, le chou et les chaussures», c'est-à-dire les exigences des normes, lire la documentation technique (correcte) et les enregistrements dans la programmation en langage assembleur pour AVR, peuvent cliquer sur le bouton ci-dessous.

Décrivons la question plus en détail - est-il possible d'implémenter IRPS (le nom habituel de l'interface, au nom de UART), sur un AVR de type MK (spécifiquement, c'était Tiny13) lorsque vous travaillez à partir d'un générateur interne. Le fait est que ce générateur n'a pas de très bons indicateurs de la précision de rétention de fréquence, c'est pourquoi cette question se pose. Je dois faire une réservation tout de suite que cela n'a pas d'importance si nous considérons une implémentation logicielle (comme suggéré dans le post original) ou si nous utilisons des blocs matériels MK. Les résultats d'une méthode (en termes de paramètres de précision dans le temps) sont presque entièrement traduits dans une autre.

La question fondamentale est de savoir si le générateur interne peut fournir la précision de fonctionnement requise, car dans le cas d'une réponse négative à cette question, d'autres études perdent leur sens. Pour comparer les deux quantités indépendantes, nous devons connaître les deux, nous allons donc commencer par déterminer la précision requise du confinement de fréquence et les capacités fournies par ce MK particulier dans cette partie. Une remarque importante à la phrase précédente - cela ne signifie pas un cas spécifique, «donné à nous dans des sensations», mais un type spécifique de MK, qui est présenté par sa description technique.

Pour commencer, nous trouverons quelque chose de plus facile à trouver (enfin, je le pensais) - des exigences pour la précision des paramètres temporels de l'interface. Nous allons ouvrir la norme pour RS232 et voir tout ce dont vous avez besoin tout de suite. Il s'est avéré que "vous ne pouvez pas simplement le prendre et ..." car la norme est payante et toutes les copies sur le Web sont illégales. D'accord, nous apportons la version domestique de GOST au joint C2 et nous n'y trouvons aucun paramètre de temps, à l'exception de la durée du front et de la coupure de l'impulsion. Au début, cela a provoqué une légère vague - comme cela pourrait être - mais ensuite, il est venu à comprendre que le joint C2 ne décrit que la partie interface de l'IRPS et que les exigences devraient être dans cette dernière. En principe, tout est logique, on ne sait pas seulement pourquoi cela n'est pas explicitement décrit dans GOST, mais, en fin de compte, vous pouvez parfois penser par vous-même, bien que cela ne soit toujours pas "bien obtenu".

Bien sûr, connaissant le protocole de transmission, il est possible, à partir de considérations générales, de trouver le décalage maximal admissible entre les vitesses de l'émetteur et du récepteur (0,5 / 9,5 = 5,2%), mais ce sera une enquête sur le cheval sphérique, vous savez où, car:

1. les exigences de la norme peuvent et doivent être plus strictes qu'un calcul théorique similaire de l'inadéquation maximale admissible;
2. connaître le chiffre final de non-correspondance ne nous donnera en aucun cas le budget de l'émetteur et du récepteur.

L'errance sur Internet a conduit à AppNote d'Atmel (enfin, puisque nous utilisons toujours le MK de cette société), qui parle explicitement d'un décalage admissible de 2% avec un budget égal, ce qui conduit à l'exigence de précision du maintien de la fréquence d'émission de 1%. Nous ferons confiance à une entreprise réputée et supposerons qu'elle ait accès à des documents classifiés et ce chiffre est correct, d'autant plus qu'il semble plausible. Je comprends la vulnérabilité d'un tel poste, mais pour être honnête, je suis fatigué de chercher la réponse exacte à une question aussi simple, et j'ai hâte de passer à la partie suivante.

La moitié suivante de la réponse se trouve à l'intérieur du MK et est déterminée par la documentation technique correspondante. D'abord, un peu sur le dispositif du générateur interne, d'autant plus qu'il est plus ou moins décrit. Le générateur utilise une chaîne RC comme élément de réglage de l'heure et, comme la tâche de former un condensateur intégré d'un condensateur exact et d'une résistance exacte est très simple, la fréquence finale d'une instance à l'autre du MK différera considérablement. Pour rendre ce paramètre plus prévisible, les fabricants ont ajouté un nœud matériel contrôlé via un octet d'étalonnage. Cette unité vous permet de changer la fréquence du générateur sur une large plage et, par conséquent, d'obtenir la valeur souhaitée avec une précision beaucoup plus élevée.

Il serait intéressant de savoir exactement comment le contrôle est implémenté dans le matériel, je vois une option soit avec le contrôle de la tension de charge du condensateur via le DAC ou le contrôle de la tension de comparaison sur le comparateur. Ces deux options conduisent cependant à une non-linéarité significative des caractéristiques de contrôle, bien qu'elles soient simples à mettre en œuvre. Mais établir l'implémentation interne du générateur ne fait pas partie de notre tâche, nous nous intéressons à ses paramètres externes.

Nous ouvrons donc la documentation (vous pouvez ouvrir le fichier dans la visionneuse, mais j'ai une version typographique de la description imprimée par le fabricant lui-même - oui, elle l'était auparavant) et recherchons la section appropriée. Les paramètres qui nous intéressent se trouvent dans la section «Oscillateur RC interne calibré», puis suivez les liens si nécessaire. Et ici, nous (pour sûr, je ne suis pas sûr de vous) attendions la première déception - je travaille avec les produits Atmel depuis longtemps (environ 15 ans) et j'ai toujours cru qu'ils avaient une bonne documentation pour MK. Selon les psychiatres, «il n'y a pas de personnes en bonne santé, il n'y a pas de personnes inexplorées» et une étude approfondie de la section pertinente a confirmé cette vérité, car je n'avais pas remarqué de tels échecs dans la documentation auparavant. Pour ma défense, je peux seulement dire que:

1. Je n'ai jamais utilisé de générateur interne dans les données MK, donc je ne l'ai pas étudié particulièrement attentivement;
2. quand j'ai commencé à travailler avec ces députés (il y a bien plus de 10 ans), j'étais jeune (enfin, certainement plus jeune que maintenant) et stupide et je ne comprenais pas pleinement le besoin d'une bonne documentation (compréhensible, complète et sans ambiguïté);
3. Je suis prêt à me pardonner beaucoup, tout simplement parce que je me pardonne beaucoup, et toutes mes lacunes ne sont pas fatales (le dernier argument est particulièrement convaincant, n'est-ce pas).

Donc, après avoir fini de m'épousseter la tête avec de la cendre, je vais commencer à faire valoir mes prétentions à la documentation et il n'y a aucune excuse pour le fabricant. Nous ouvrons la section ci-dessus et commençons à l'étudier attentivement, en allant aux pages nécessaires si nécessaire (vous cliquez toujours sur les liens). Ensemble, nous rechercherons les paramètres suivants caractérisant les caractéristiques temporelles du générateur: précision nominale, influence de la tension d'alimentation, influence de la température et paramètres de vieillissement - il s'agit de l'ensemble minimal nécessaire pour évaluer les paramètres de précision de tout générateur.

La première partie du ballet Marleson est la précision nominale.

Nous trouvons immédiatement le paramètre souhaité - le tableau de précision de réglage du générateur, dans lequel nous voyons deux lignes «Calibré en usine» avec la valeur spécifiée ± 10% et «Calibrage manuel» avec le même paramètre ± 2%.

Concernant ces données, un certain nombre de questions se posent immédiatement - que signifient-elles et comment sont les mesures de ce paramètre. Pour la première ligne, le tableau indique la température (de l'environnement ou du MK lui-même - ce n'est pas clair, mais c'est un caprice de ma part) et la tension d'alimentation, en plus, la note dit (à mon avis, ce n'est pas nécessaire) que cette mesure est effectuée à un endroit spécifique dans l'espace conditions extérieures. On peut supposer que dans ce cas, nous devrions utiliser le facteur d'étalonnage enregistré chez le fabricant, bien qu'il serait préférable de l'indiquer explicitement dans la note. Tout est plus ou moins clair et est interprété presque sans ambiguïté (bien que dans le contexte de l'étude de la documentation technique, il faut dire que tout est flou et permet des variations dans les interprétations, ce qui est inacceptable, mais si nous le faisons, le sujet de la discussion disparaît simplement (et ce qui va suivre) écrivez, il n'est pas clair, par conséquent, faites preuve d'indulgence).

Mais avec la deuxième ligne du boîtier, c'est pire - les limites des changements de température et de tension d'alimentation sont données et on fait valoir qu'en utilisant une sorte de procédure d'étalonnage magique, vous pouvez obtenir des résultats nettement meilleurs que le résultat d'usine dans toute la gamme. Ma question se pose immédiatement - si cela peut être réalisé partout (à n'importe quel point de la température et de l'alimentation) et que le fabricant sait comment le faire, alors pourquoi ne l'a-t-elle pas fait elle-même lors de l'étalonnage en usine à un moment précis des conditions? Nous passons à la description de l'octet d'étalonnage et voyons qu'il prend 128 valeurs et cela couvre la plage de 50% à 200% de la valeur nominale, ce qui correspond à 150/128 ~ 1,17% du changement de fréquence par valeur d'étalonnage unitaire, ce qui devrait donner la précision attendue mieux que dans 1% Mais alors, nous devons tenir compte du fait que la caractéristique d'ajustement n'est clairement pas linéaire et dans la plage des grandes valeurs d'étalonnage, nous avons 60% / 32 ~ 2% de l'étape (données tirées du graphique, j'ai exprimé à plusieurs reprises mon attitude envers une méthode similaire de représentation des paramètres techniques, mais je le répète - c'est inacceptable la méthode, bien que, bien sûr, est meilleure que rien), ce qui donne une précision de 1% et si nous tenons compte de la monotonie de la caractéristique d'ajustement (oui, c'est ce que dit la documentation, elle n'est pas dessinée dans le graphique, mais clairement indiquée dans le texte. Je refuse catégoriquement de comprendre à , et surtout pourquoi, la compagnie voulait faire une loi d'ajustement, mais il a réussi), qui est clairement indiqué dans les lignes directrices, il est nécessaire de tenir compte de la précision de 2% est tout à fait réalisable. Je n'aime pas vraiment que je doive regarder le graphique, mais ce n'est pas nécessaire et les données tabulaires sont suffisantes. Dans cette partie, la documentation doit être considérée comme parfaitement compréhensible et cohérente, le critère d'exactitude est en dehors de l'étendue de notre compétence.

La deuxième partie du ballet Marlezon. - l'influence des conditions extérieures.

Et puis commence «les ordures, les fumées et la sodomie». Au lieu de tableaux de valeurs, nous sommes invités à regarder des images (pour une raison quelconque, on les appelle des graphiques de valeurs typiques dans la documentation) et, comme vous le savez, "le principal avantage de la représentation graphique des informations est sa visibilité, et elle n'a pas d'autres avantages". Il serait possible d'utiliser même de telles informations et de supprimer les valeurs limites du graphique («bien que cela soit offensant pour l'équipe») si ce graphique n'était pas donné dans la section «Caractéristiques typiques». Je ne sais pas comment quelqu'un, personnellement, je suis profondément convaincu que pour indiquer des significations typiques (ou typiques, je ne sais pas comment être plus correct, dans un film, ils ont dit "apparence typique"), au moins sous la forme d'un graphique, même dans le tableau, cela n'indique tout simplement rien. Ils ne peuvent pas être guidés dans la conception, car ces paramètres ne sont pas clairs sur ce qu'ils signifient et tout écart par rapport aux valeurs typiques est acceptable, contrairement aux valeurs minimales et maximales, dont la transition indique un dysfonctionnement de l'appareil.

Eh bien, nous sommes passés, nous allons essayer d'extraire au moins quelques informations et voir que lorsque la température passe de -40 à + 80 ° , la fréquence du générateur change de ± 4%. Une image similaire avec la tension d'alimentation - uniquement des graphiques typiques et l'erreur résultante en -6 + 2% de 3,3 à 5,5. Les données sur le vieillissement du générateur ne sont tout simplement pas fournies, ce qui, en général, est logique, car dans le contexte des paramètres déjà donnés, la précision d'un pour cent pendant 5 ans (une valeur caractéristique pour le silicium) ne dérange personne.

Nous avons maintenant toutes les données pour répondre à notre question initiale - lors de l'étalonnage en usine, le générateur ne répond pas aux exigences d'interface pour la précision, lorsqu'il est étalonné pour des conditions d'application spécifiques - il répond aux exigences des limites, mais ne répond pas à la norme. Il convient également de tenir compte du fait que si l'étalonnage de la tension d'alimentation et d'un MK spécifique peut être effectué dans la fabrication de l'appareil et espère qu'ils ne changent pas dans le temps, la température ne peut être prise en compte qu'à la volée et nécessite une norme de temps externe d'une précision appropriée. Étant donné que le développement d'appareils doit être guidé par la règle `` nous croyons en Dieu, tout le reste nécessite une preuve '', et nous n'avons pas prouvé la possibilité de répondre aux exigences, la bonne réponse est qu'il est impossible de garantir la mise en œuvre d'IRPS qui répond aux exigences de la norme dans ce MC avec un générateur interne. Notez que nous avons fait la conclusion ci-dessus lors de l'analyse de la documentation et l'avons formulée de manière à souligner que sur une instance spécifique de MK, tout peut et se passera si les étoiles montent avec succès. Autrement dit, notre conclusion contredit le post mentionné précédemment, comment cela pourrait-il arriver, parce que tout fonctionne très bien pour une personne - essayons de le comprendre.

Maintenant, la critique du poste ci-dessus va commencer. Tout d'abord, réfléchissons à la façon dont nous pouvons nous assurer que l'appareil est vérifié pour la conformité aux exigences d'une interface particulière. Je peux suggérer les moyens suivants:

1. Un bon moyen est de mesurer les paramètres critiques de l'interface de l'appareil et de les comparer avec les exigences de la norme - cela peut être fait en utilisant des instruments universels (dans notre cas, l'oscilloscope et la longueur de l'intervalle de bits ou la transmission complète), ou en utilisant un appareil spécialisé certifié pour tester cette interface.
2. Moyen moyen - pour organiser l'interaction avec un autre appareil qui implémente la partie réponse de l'interface et qui a fait ses preuves (répond aux exigences de la norme). Bien sûr, un tel contrôle est complètement insuffisant et peut plutôt être appliqué davantage pour confirmer le dysfonctionnement de l'appareil testé, mais fait au moins quelque chose.
3. La mauvaise façon est d'implémenter indépendamment la partie réponse de l'interface (dans le même appareil ou dans un autre) et d'interagir avec elle. Les deux appareils n'étant évidemment pas prouvés, l'utilité d'un tel contrôle est très, très douteuse. Un bon exemple de cette approche est l '"écho" sur un canal série, qui ne prouve rien et ne rapporte guère plus que rien sur la vitesse de l'appareil, en principe, n'est pas cassé et est capable de transmettre quelque chose d'une manière ou d'une autre.
4. Une façon terrible est de prendre comme testeur un appareil qui ne répond pas du tout aux exigences de la norme (ou plutôt, qui les contredit) et de fonctionner comme au paragraphe précédent.

C'est cette dernière méthode qui a été utilisée dans l'article à l'étude - un récepteur logiciel de canal série est mis en œuvre, qui, contrairement aux exigences de la norme, change de fréquence, s'adaptant au signal d'entrée (en particulier, la longueur du bit de départ), ce qui permet de recevoir de manière stable un signal de mauvaise qualité en termes de paramètres temporels. Cela ne veut pas dire que cela ne devrait jamais être fait, en outre, dans les modems analogiques, le réglage de la vitesse entrante a été adopté, qui a été mis en œuvre de la même manière, mais c'était précisément la commutation de la fréquence en changeant le diviseur, et ce n'est clairement pas notre cas. Et c'est dans cette version que tout est parfaitement obtenu et que les informations sont transmises de manière stable dans toutes les conditions extérieures. Par conséquent, si nous parlons de la possibilité de transmettre des informations entre deux MC fonctionnant à partir de générateurs internes à l'aide d'une interface qui rappelle à distance l'IRPS, la réponse est oui. Si nous parlons d'interagir avec des appareils externes qui répondent aux exigences de la norme et rien de plus, nous nous attendrons à de nombreuses surprises désagréables.

La conclusion générale de ce qui précède:

1. lors de la conception des appareils, vous devez vous concentrer sur la documentation (RTFM),
2. vous devez étudier la documentation et interpréter correctement ce que vous lisez (RTFMF),
3. gardez à l'esprit que dans notre temps la documentation peut être des malentendus, des inexactitudes (et même des erreurs), donc
4. vérifier la cohérence et la crédibilité des informations reçues, et
5. utiliser les informations obtenues expérimentalement uniquement pour confirmer les conclusions tirées de l'analyse de la documentation,
6. choisir soigneusement les méthodes d'expérimentation pour tester les équipements afin d'obtenir un résultat fiable.

Eh bien, en conclusion, comme promis, un petit assembleur. Je me suis permis de réécrire l'extrait de code cité par l'auteur sous une forme normale, car l'assembleur intégré à GCC n'est rien d'autre qu'une moquerie du programmeur, je peux nommer. Non, bien sûr, je comprends que les développeurs du compilateur ont été guidés par de bonnes raisons, mais le résultat ressemble douloureusement à la phrase «eh bien, ça fonctionne».

.equ delay=15 TX_Byte: cli ; ld r18,Z+ ; cp r18,r1 ; breq Exit_Transmit ; dec r1 cbi port, TX_line Delay_TX: ldi r16,delay Do_Delay_TX: nop dec r16 brne Do_Delay_TX TX_Bit: sbrc r18,0 sbi port,TX_line sbrs r18,0 cbi port,TX_line lsr r18 lsr r17 brcs Delay_TX sbi port, TX_line ldi r16,delay Stop_Bit_TX: nop dec r16 brne Stop_Bit_TX Sei 

Et immédiatement une erreur dans le programme attire votre attention - à la ligne 3 (commentée), la valeur du registre 1 doit être nulle, mais l'affectation n'est pas explicitement écrite dans la fonction. Après un cycle de transfert d'un seul octet, cette valeur est garantie par la ligne 12, mais pas lors du premier passage. Par conséquent, l'initialisation doit être ajoutée, ce qui nécessitera une augmentation de la taille du code.

Le deuxième inconvénient est la formation réelle du niveau dans les lignes 4 à 7, car la méthode adoptée par l'auteur pour émettre le bit suivant entraînera une gigue avant pendant 2 cycles d'horloge à différentes transitions (0-1 et 1-0), ce qui entraînera une augmentation des exigences de précision de maintien de la fréquence. Non pas que cela donnerait une très forte influence, mais si vous pouvez corriger un défaut sans étendre le programme, alors pourquoi pas - voir l'épigraphe. La version originale a pris 4 mots et a été réalisée en 4 mesures, la nouvelle a pris 4 mots et a été réalisée dans les mêmes 4 mesures. Oui, la version corrigée nécessite une étude plus approfondie de l'architecture MK, mais qui a dit que ce serait facile. En revanche, dans la première version, la modification du port est atomique, et dans la seconde elle ne l'est pas, dans ce cas cela n'a pas d'importance (nous avons explicitement interdit les interruptions), mais le sédiment reste. Si le MK en question avait un vrai processeur de bits, comme dans l'architecture 51, alors nous pourrions écrire un fragment idéal combinant tous les avantages des deux approches (et même être un peu plus court), mais que pouvons-nous rêver d'un rêve de pipe ...

Le troisième inconvénient est la question de plus de style. J'ai exprimé à plusieurs reprises mon attitude envers les constantes magiques que nous voyons dans le préambule de ce programme. J'insiste encore une fois - du fait que l'auteur fixe une constante dans le préambule du programme, et non directement dans l'opérateur, la «magie de rue ordinaire» ne va nulle part. Le fait est que nous devons explicitement présenter au lecteur la méthode de formation d'une valeur spécifique, et non créer un synonyme de la valeur obtenue de manière inconnue. Vous pouvez, bien sûr, écrire un commentaire sur une ligne avec une valeur dans laquelle spécifier la formule de calcul, mais il est préférable d'utiliser explicitement la formule de calcul pour former la constante et alors vous n'avez tout simplement pas besoin d'un commentaire (bien sûr, avec les noms parlants des constantes appliquées). Cela se fait dans le texte ci-dessous, et notez que nous ne convertissons en entier qu'au dernier moment et arrondissons correctement, ce qui nous permet de ne pas perdre la précision du résultat.

Il y a une autre erreur - la longueur du bit de départ est quelque peu différente de l'intervalle de bits pour les données. Bien que l'écart ne soit pas trop important (3 cycles d'horloge), néanmoins, à des débits binaires élevés, où l'intervalle binaire dure environ 90 cycles d'horloge, il s'agit déjà d'une erreur de quelques pour cent, ce qui est inacceptable. Cette erreur peut être facilement corrigée en ajoutant des commandes pour générer un retard supplémentaire, mais cela augmentera la longueur du programme, de sorte que nous corrigeons simplement sa présence et que nous nous assurons ensuite que l'architecture correcte du programme (c'est-à-dire que même ce court terme s'applique à ce concept) élimine automatiquement.

Eh bien, maintenant que nous avons corrigé les erreurs (sauf la dernière), nous allons essayer d'améliorer le programme dans le sens du critère principal (pour atteindre un record, dans ce cas particulier) - la longueur du code. La première chose qui attire votre attention est la présence de deux retards, ce qui est mauvais car il viole le principe DRY (exigence générale) et augmente la taille du code (exigence spécifique). Il serait possible d'organiser ce fragment sous la forme d'un sous-programme et nous gagnerions toujours en longueur, car nous ajoutons 3 mots de code (1 pour chaque appel à deux endroits et 1 pour le retour), et nous en économisons 4, mais il y a une manière beaucoup plus belle - soignée l'organisation du cycle de transmission d'octets, que l'on peut voir dans le texte suivant.

 .equ delay=15 TX_Byte: cli sec ;   - clt ;  - TransBit: ;    in r17,port bld r17,Tx_line out port,r17 Delay_TX: ;     ldi r17,delay Do_Delay_TX: nop dec r17 brne Do_Delay_TX TX_Bit: bst r16,0 ror r16 clc brne TransBit ;    brcs TransBit ;  - Exit_Transmit: Sei 

Notez comment nous utilisons l'octet transmis avec le bit de retenue comme compteur de bits, une belle solution, mais elle a un inconvénient - la durée du dernier bit de données sera plusieurs (2 cycles) plus longue que les autres, en raison du retard dans la transition. Si nous parlions d'un bit d'arrêt, alors "ne vous en souciez pas et oubliez", car nous n'avons pas reçu l'intervalle minimum entre les transferts, mais c'est un bit significatif, et nous venons de critiquer le programme d'origine pour un tel comportement. Nous ne serons pas comparés au caractère biblique de la parabole de la paille aux yeux des autres et prendrons des mesures pour l'éliminer. Ce phénomène pourrait facilement être compensé en introduisant un retard de 2 mesures, mais la longueur du code augmentera, et c'est un paramètre clé. Par conséquent, passons à la méthode classique et modifions l'heure de la mémoire - nous utilisons un registre séparé pour organiser le compteur des bits transmis, et nous obtenons exactement les mêmes intervalles de bits avec la même taille de code.

L'amélioration suivante est associée à la formation de la durée de l'intervalle de bits, qui dans le programme d'origine est effectuée sur un cycle de 4 cycles. Si nous le faisons à 3 heures (le plus petit possible dans ce MK), nous pouvons économiser un octet de code et potentiellement améliorer les paramètres de précision, car la discrétion du retard deviendra moindre (l'écart ne dépasse pas la moitié de la taille du discret avec un arrondi approprié). Mais il ne faut pas oublier que dans un cas particulier, nous pouvons perdre la précision, tout dépend des données source. Une autre circonstance qui pourrait affecter le choix d'une telle durée de cycle - la taille de retard maximale pour un compteur d'octets est de 256 valeurs - pour l'option disponible, vous pouvez utiliser des vitesses de 9600 bauds et plus, mais avec un retard de 3 cycles, ce n'est pas possible. Il serait très agréable de refléter cette circonstance (la vitesse minimale autorisée du port) dans les commentaires du programme et en même temps d'afficher un message d'avertissement en cas de violation de cette exigence. Eh bien, apportez les modifications appropriées aux macros de formation des paramètres pour former un retard, sans oublier d'utiliser des noms "parlants" pour indiquer les variables.

 .equ Freq = 8000000 .equ BaudRate = 115200 .equ PayLoad = 9 ;     .equ CycleTime = 3 ;    .equ delay=((Freq*2/BaudRate - PayLoad*2)+CycleTime)/(CycleTime*2) TX_Byte: cli ldi r18,10 sec ;   - clt ;  - TransBit: in r17,port bld r17,Tx_line out port,r17 Delay_TX: ldi r17,delay Do_Delay_TX: dec r17 brne Do_Delay_TX TX_Bit: bst r16,0 ror r16 dec r18 brne TransBit Exit_Transmit: sei 

Examinons maintenant le résultat - la taille du code a diminué de 20 à 16 mots (si nous ne prenons en compte que la transmission elle-même, puis de manière encore plus frappante - de 18 à 14, la gigue des fronts a disparu (bien sûr, seul le composant de gigue, qui est causé par les fonctionnalités du programme, sur le composant matériel, nous nous ne contrevenons pas), la précision du maintien des intervalles de temps s'est améliorée, le programme est devenu plus visible et plus facile à comprendre (grâce aux commentaires, car même un programme d'assemblage bien écrit n'est généralement pas auto-documenté).

La conclusion de la dernière partie est que si nous voulons établir des records du monde dans la programmation en langage assembleur, nous devons étudier l'architecture d'un MK particulier très en profondeur et appliquer les connaissances obtenues pour obtenir le résultat idéal, en faisant attention à toutes les subtilités.

Eh bien et en conclusion - la tâche d'écrire du code de la taille minimale semble de nos jours quelque peu artificielle, mais, de manière tout à fait inattendue, reçoit la confirmation de sa vitalité. À la fin de l'année dernière (2016, c'est depuis combien de temps cet article attend son tour), un nouveau MK de la famille MSP430 a été annoncé, qui avec le prix exceptionnellement bas (26 cents - nous attendons l'apparition d'appareils chinois basés sur lui) a également une taille de mémoire de programme exceptionnellement petite - 512 octet (non, je ne me suis pas trompé, la lettre "k" immédiatement après le numéro ne l'est pas). La taille du code peut donc s'avérer critique lors de l'utilisation de cet appareil, et l'écriture de tels programmes extrêmes nécessite généralement une étude approfondie de MK et "le travail en lui-même est une bénédiction".