Étape 3: Test de l’écran
Maintenant que nous avons déménagé notre affichage à 4 chiffres à son propre Conseil d’administration, nous avons besoin de le tester pour vérifier qu’il fonctionne (et de corriger les problèmes inévitables). Cela signifie que nous voulons écrire un pilote simple qui affichera juste un certain nombre et vérifier tous les segments sur chaque chiffre. Une fois que nous sommes convaincus que tout fonctionne comme il faut puis nous peuvent travailler sur notre code de communication.
La façon dont nous allons écrire le code de test est afin que nous puissions continuer à l’utiliser plus tard en ajoutant simplement les routines de communication. Nous copier notre code de 4 chiffres-affichage du dernier tutorial et supprimer tous les trucs qui avait à voir avec l’ADC, puisque nous n’utiliser que plus. Nous avons également changé les broches de l’anode afin qu’ils utilisent PC0 par PC3 puisqu’elle fait de câblage et de codage plus facile.
Je joins le code et une image du fonctionnement de l’écran externe.
J’ai pas besoin d’aller à travers tous le code ligne par ligne, puisque c’est pour la plupart des modifications simples des choses que nous avons déjà fait. Cependant, il y a une chose, que je tiens à souligner.
Nous allons finalement besoin d’afficher des chiffres de 0000 à 9999 sur notre écran à 4 chiffres. Cela signifie que nous avons besoin de place pour 10 000 numéros. Toutefois, un registre de 8 bits ne va que jusqu'à 255. Donc nous allons avoir besoin de plus de bits consacrés au numéro nous souhaitons afficher. Nous allons faire un rapide calcul pour savoir combien de bits, que nous allons avoir besoin. Chaque chiffre est une puissance de 2 et nous voulons donc voir quelle puissance de deux nous donne 10 000. Pour cela, nous utilisons le « logarithme népérien » :
2 ^ x = 10000
x ln (2) = 4 ln(10)
x = 4 ln(10)/ln(2) = 13.288
Cela me dit que pour afficher 10000, nous devons plus de 13 bits. Donc si j’utilise 14 bits puis je vais avoir plus qu’assez. Comme un chèque (ou venez de le faire en premier lieu si vous ne pensez pas math est amusant), il suffit d’aller au « math est un plaisir » site automatique convertisseur ici :
http://www.mathsisfun.com/binary-Decimal-hexadecim...
et figurer dehors en convertissant tout simplement. Vous y trouverez que 14 chiffres peuvent afficher des nombres jusqu'à 16383 et 13 chiffres seulement jusqu'à 8191. Notre calcul est donc correct, que nous avons besoin de plus de 13 chiffres et moins de 14. Donc nous utilisons 14. En fait, 9999 en binaire est : 0b10011100001111 qui est de 14 bits, mais n’a pas besoin de toutes ces sur.
Bon, pour inscrire de la façon dont nous résoudre le dilemme d’avoir besoin de plus de 1 consiste à utiliser 2 d'entre eux. Cela nous donne 16 bits et est par conséquent beaucoup d’afficher n’importe quel nombre Qu'on jette à l’affichage à 4 chiffres.
Mais quand nous envoyons les nombres à travers notre interface de communication, qu'ils seront au format binaire. Comment est-ce nous convertir un nombre binaire en décimales à afficher ? C’est pas presque aussi facile qu’on pourrait penser à première vue. Nous allons le comprendre.
Nous commençons par un nombre compris entre 0 et 9999 et nous voulons les 4 chiffres de ce nombre, afin que nous puissions les afficher. Il n’y a pas de fonction en langage assembleur qui va faire que pour nous alors que nous devons faire un nous-mêmes. Le numéro commence par un nombre binaire de 2 octets. Permet de l’appeler X pour l’instant. Nous aimerions comprendre chaque chiffre à son tour, du plus élevé au plus bas. La façon dont nous trouvons le plus haut est comme ce schéma de code :
chiffres = 0
départ :
X > 1000 ?
OUI :
X = X - 1000
chiffres ++
Goto début :
NON :
Retour à chiffres
Comme vous pouvez le voir, cela semble assez simple. On décolle juste 1000 un à la fois et chaque fois que nous augmentons la valeur du "chiffre". Une fois que X n’est donc plus plus grand que 1000 nous aurons le nombre 1000 stockées dans "digit" et nous le retourner. Cela nous donnera le premier numéro de notre écran. Alors nous pouvons faire la même chose que ci-dessus à la valeur résiduelle de X sauf avec 100 au lieu de 1000 et ceci nous obtiendra le nombre de 100, puis nous faire encore une fois avec quelques dizaines et enfin lorsqu’il n’y a pas quelques dizaines à gauche, le montant restant dans le X se situera entre 0 et 9, et donc ce sera notre dernier chiffre. Voilà donc comment nous pouvons obtenir nos 4 chiffres.
Cependant ! C’est pas aussi simple en langage d’assemblage ! Une énorme clé est jetée dans ce plan en raison du fait que nous avons besoin de deux octets pour représenter notre numéro de 14 chiffres binaires. Comment nous soustrayons 1000 ? En termes de 2 octets, 1000 est représenté par 0b0000001111101000 et vous voyez que certaines d'entre elles est dans le premier octet et certaines d'entre elles est dans le deuxième octet. Ainsi, au lieu de X = X-1000, nous pourrions écrire X comme les deux octets XH et XL ainsi que X = XH:XL et ensuite faire notre soustraction comme suit :
XH = XH - high(1000)
XL = XL - low(1000)
Cela semble assez simple droit ? Eh bien, il est encore pire ! Supposons que nous avons commencé avec X = 2001 et nous trouvons notre premier chiffre (2) en soustrayant de 1000. Nous allons voir comment cela fonctionne :
Nous testons X et trouver qu’il est > 1000 et donc nous soustraire, depuis 2001 = 0b0000011111010001 en binaire notre soustraction fonctionnerait comme suit (mettant les numéros) :
XH = high(0b0000011111010001) - high(0b0000001111101000)
XL = low(0b0000011111010001) - low(0b0000001111101000)
qui devient
XH = 0b00000111 - 0b00000011 = 7-3 = 4
XL = 0b11010001 - 0b11101000 = 209-232 = - 23
Nous avons un problème ! L’octet de poids faible ne contient-elle pas assez pour manipuler la soustraction ! Si vous pensez que ce n’est pas un problème étant donné que le langage assembleur peut gérer des négatifs, mais il ne peut gérer jusqu'à -128 et il y aura certainement des moments où le résultat de la soustraction de la XL est plus négatif que celle. Alors, que faisons-nous ?
Eh bien, la façon dont nous traitent de cela est la même manière que nous le faisons en toute soustraction de la 5e année. Nous avons besoin de prendre l’un des chiffres de XH. N’oubliez pas que chaque chiffre binaire en XH est en fait égal à 256. Nous faisons cela avec la commande « sbc » qui soustrait avec carry.
Puis, une fois que nous avons réussi à se débarrasser de la 1000 nous passer à la 100 ' s et faire la même chose. Dans ce cas, nous avons le même problème que nous aurons besoin d’emprunter de l’octet haut de 1 jusqu'à ce que notre résultat est moins de 256 donc nous continuons à utiliser le sbc à subract l’octet haut.
Enfin, quand on arrive aux dizaines et les taches de la 1 que nous n’avons plus à vous soucier d’emprunt des chiffres plus et les choses sont plus simples, nous pouvons soustraire tout le registre grave.
Donc, maintenant que vous voyez comment nous sommes obligés de faire choses jetez un oeil sur le code et vous devriez maintenant être en mesure de comprendre comment il fonctionne. Notez qu’il y a certaines choses que nous devions faire pour afficher des nombres entre 768 et 999. Pouvez-vous penser pourquoi cela peut être ? En tout cas, nous commençons en lui donnant simplement un numéro à afficher de sorte que nous pouvons tester notre affichage. Nous allons simplement utiliser 9876. Plus tard, nous aimerions que le nombre à venir depuis un autre microcontrôleur via l’interface de communication 2 fils.
Exercice 1: Comprendre comment fonctionne le fragment de code ci-dessous.
Voici le code explicit que j’ai utiliser pour la conversion de deux octets binaires décimales pour l’affichage de chiffres :
loadCash: ; this computes the digit for each 7-seg of the display<br>cli ; disable interrupts while loading digits<br>push playercashH ; store high byte of playercash<br>push playercashL ; store low byte of playercash<br>ldi tempH,high(1000) ; set tempH:L to 1000<br>ldi tempL,low(1000) <br>rcall computeDigit ; find the 3rd digit<br>mov digit3,digit ; store the new 3rd digit<br>ldi tempH,0 ; set tempH:L to 100<br>ldi tempL,100 <br>rcall computeDigit ; find the 2nd digit<br>mov digit2,digit ; store the new 2nd digit<br>ldi tempH,0 ; set tempH:L to 10<br>ldi tempL,10 <br>rcall computeDigit ; find the 1st digit<br>mov digit1,digit ; store the new 1st digit<br>mov digit0,playercashL ; remaining is 0th digit<br>pop playercashL ; restore low byte of playercash<br>pop playercashH ; restore high byte of playercash<br>sei ; re-enable interrupts<br>ret
computeDigit: ; interrupts are already disabled while here<br> clr digit compareHigh: cpi playercashH,0 ; if both playercashH brne PC+3 cpi playercashL,0 ; and playercashL are zero then done breq returnDigit cp playercashH,tempH ; otherwise continue brlo returnDigit ; if less then move to next power of 10 brne PC+3 ; if high is greater then subtract cp playercashL,tempL ; if highs are equal and lows are less, brlo returnDigit ; then playercash is less so move to next power of 10 clc sub playercashL,tempL ; otherwise subtract power of 10 sbc playercashH,tempH ; otherwise subtract power of 10 inc digit ; and increment the current digit rjmp compareHigh ; and go back up to test again returnDigit: ; digit will now be the one to display in this spot ret
Ensuite, nous allons introduire quelque chose de nouveau--communications TWI.
