Conversion en Hexa vers BCD

[invitec7160702]

salut
comment convertir de l'hexa en BCD (binaire code decimal)

que veut dire BCD
merci
-----

[Gérard]

BCD : binaire codé décimal
ex : 101d = 65h = 1100101b
si tu as un compteur binaire, tu auras une valeur sur 1 octet alors que 101 demande 3 chiffres en BCD.
Il faut convertir l'octet en 3 càd, unités, dizaines et centaines.
Procédure pour la conversion :
;variables
CPT ;octet à convertir
CTN ;centaines
DIZ ;dizaines
UNT ;unités

DEBUT :
CTN = 0
DIZ = 0
UNT = 0

tant que CPT > 100
CPT = CPT - 100
CTN = CTN + 1

tant que CPT > 10
CPT = CPT - 10
DIZ = DIZ + 1

UNT = CPT
;fin de la procédure

Assez clair ?

[invitec7160702]

Bonjour Gerard,
Je suis un nouveau en electronique.
ex:
FF en hexa donnerait 02 05 06
comment on fait?
merci d'avance

[gcortex]

Salut :
si tu fais 8+4, tu obtiens $0C
puis tu fais un ajustement décimal $0C+$06=$12

$FF donne $0256

[A voir en vidéo sur Futura]

[invitec7160702]

salut gcortex,

Tu vas me prendre pour un neuneu.

comment tu passes de FF vers 8+4
et comment $0C+$06=$12

je suis un mecano.

[invite55fe29e6]

Bonjour à tous,
Si mes souvenir son bon,

Par exemple : $FF en Code Binaire si on fais la conversion sa nous donne 11111111 ensuite il est aisé de le passé un code Décimal se qui donne 255 et donc de la on en vient au BCD
Si tu as 255 en décimal et que tu veux le convertir en BCD sa donnera sa

DEC: 2 5 5
BCD: 0010 0101 0101
En faite il faut que tu décompose ton nnombre décimal et que pour chaque chiffre tu le convertisse en binaire voila j'espère ne pas mettre trompé sur le principe parceque c'est loin tout sa!!!

[invite55fe29e6]

Tien je vien trouver une définition je te la donne ne plus parceque si des fois mon explication n'était pas claire sa te fais sa en plus:

Le code BCD (Binary Coded Decimal) conserve la représentation décimale d'un nombre (centaines, dizaines, unités...), mais chaque chiffre de ce nombre est reproduit en binaire.

Etant donné que chaque rang décimal (unités, dizaines, centaines...) peut contenir un chiffre de 0 à 9, chaque rang du code BCD sera représenté par quatre chiffres binaires (de 0000 à 1001), donc quatre bits.

Exemple: 128 en décimal, soit 1 centaine, 2 dizaines et 8 unités. En binaire, 1 s'écrit 0001, 2 s'écrit 0010 et 8 s'écrit 1000. Le résultat, en BCD, est donc: 0001 0010 1000
@+

[Gérard]

Bonjour Gerard,
Je suis un nouveau en electronique.
ex:
FF en hexa donnerait 02 05 06
comment on fait?
merci d'avance

Pas tout à fait juste, FFh = 255d et non 256
avec ma procédure :
255 > 100 ?
OUI
255 - 100 = 155
Centaine = 1
155 > 100 ?
OUI
155 - 100 = 55
Centaine = 2
55 > 100 ?
NON
55 > 10 ?
OUI
55 - 10 = 45
Dizaine = 1
45 > 10 ?
OUI
45 - 10 = 35
Dizaine = 2
....
....
5 > 10 NON
Unité = 5

en sortie tu auras :
Centaines = 2
Dizaines = 5
Unités = 5

[invite2562e666]

Bonjour,

Personellement, je fais cela en deux divisions:

HEX/100 -->resultat + reste
Resultat = centaines
Reste/10 -->resultat+ reste
Resultat = dizaines
reste= unités

th.

[Gérard]

Bonjour,

Personellement, je fais cela en deux divisions:

HEX/100 -->resultat + reste
Resultat = centaines
Reste/10 -->resultat+ reste
Resultat = dizaines
reste= unités

th.

Encore faut-il disposer de la division !

[invitec7160702]

merci les gars

[invitef86a6203]

je confirme que la soustraction est plus rapide que la division au point de vue assembleur et ressource code mémoire,

Simple Précison
(parce que ,j'ai vu des confusions sur plusieurs posts) ;

Sur un octet il y a 256 valeurs de 0 à 255.
Le 0 étant aussi une valeur surtout en informatique.
Une boucle de 0 à 255 donne 256 boucles.
(si "i" est un int de 2 octets)
for (i=0; i<=255; i++) /* 256 itérations */

Particularité si "i" est un unsigned char (1 octet)
Cette boucle devient impossible (donc infini), car à aucun moment on sera >255, l'incrément de 255 donnant 0.

[invite2562e666]

je confirme que la soustraction est plus rapide que la division au point de vue assembleur et ressource code mémoire,

Bonjour, Freepicbasic

Eh bien non.

Sur pic, peut être, car il faut en plus de chaque soustraction, faire un test genre A>10, ce qui nécessite en fait 2 tests, une sur la retenue et une sur le zéro. Donc si je ne me trompe pas, trois instructions + 1 à 2 goto , soit 4 à 5 "mots" de 14 bits ( = 8 octets) flash minimum et autant de cycles par "soustraction".

Dans la note AN526 microchip : conversion bin - BCD sur 2 digits (soit 99 max) ->10x14bits = 18 octets flash et 81 cycles au maximum.

Sur MC9S08, une instruction "DIV" (= 1 octet flash) qui s'exécute en 6 cycles (= 300 nsec à 20Mhz), à répéter 2 fois.

thierry

[gcortex]

billy 8+4 est un exemple qui n'a rien à voir avec $FF
La correction décimale s'effectue en ajoutant des 6
preuve $0C+$06=$12 c'est bien la valeur BCD de 8+4...

Regarde le détail d'une instruction "ajustement décimal" d'un microcontroleur si tu veux en savoir plus

[invitef86a6203]

Sur pic, peut être, car il faut en plus de chaque soustraction, faire un test genre A>10, ce qui nécessite en fait 2 tests, une sur la retenue et une sur le zéro. Donc si je ne me trompe pas, trois instructions + 1 à 2 goto , soit 4 à 5 "mots" de 14 bits ( = 8 octets) flash minimum et autant de cycles par "soustraction".

Non,1 seul test , on test le dépassement!
AN526 c'est bien à ça que je faisais référence.

->10x14bits = 18 octets flash et 81 cycles au maximum.

Bien mystérieux ce calcul !
Il s'agit de mot de 14bits , quel est le rapport avec 18 octets?
chaque mot coute 1 cycle sauf les goto 2 ou BTF faux.

gtenth movlw .10 ; 1
subwf LSD,W ; 2
BTFSS STATUS,C ; 3
goto over ; 4 si faux sinon 5 et on sort
movwf LSD ; 5
incf MSD, F ; 6
goto gtenth ; 8

8 cycles x 9 = 72
+ le reste du prog on arrive sans doute à 81.

Comparer à ça ;
extrait d'une lib Math.

;
;
; Divide ax by bx
; quotient in cx, remainder in ax
;
function_div	mov	fsr,#-10h
		clr	cl
		clr	ch

:position	jb	bh.7,:loop
		rl	bl
		rl	bh
		ijnz	fsr,:position
		ret

:loop		dec	fsr
		call	neg_bx
		call	add_bx_ax
		call	neg_bx
		rl	cl
		rl	ch
		sb	cl.0
		call	add_bx_ax
		clc
		rr	bh
		rr	bl
		jb	fsr.4,:loop
		ret
;
;
; Negate/Increment bx, make z
;
neg_bx		not	bl
		not	bh
inc_bx		inc	bl
		snz
		inc	bh
		ret

Selon,Les librairies soft sont basées généralement sur la soustraction si la division n'existe pas ...

Oui, c'est vrai il faut spécifier le µp, Le seul cas valable est si la division est dans le jeu d'instruction, d'ailleurs certain Pic l'ont.
ça dépend donc effectivement du processeur.

Mais ma remarque était surtout pour souligner le fait que les opérations mathématiques, engendrent généralement un chargement de librairie qui consomme des ressources, en chargeant des fonctions pas utilisées , donc pas forcément judicieux si on fait qu'une conversion BCD ,
alors à regarder à 2 fois, ce que fait l'assembleur à la sortie.

[invite2562e666]

Re-bonjour, Freepicbasic

Si tu ne testes pas le zero, c'est que les > de la procédure donnée ici plus haut sont des >= Désolé de m'y être fié.

Mais je pense que le > nécessite bien 2 tests en PIC (ou alors, j'ai encore mal compris):
http://perso.orange.fr/doumai/Assembleur/Assembleur.htm
(D'ailleurs en HC08, cela se fait avec une instruction: BHI - Branch If Higher)

Les 10 mots viennent de AN526. 10x 14bits, cela fait 140 bits, et donc 17,5 octets.

Oui, il faut effectivement spécifier le µP, mais je n'ai lu nulle part que l'on avait affaire à un pic. D'ailleurs, je pense que si l'on demande à quelqu'un ne connaissant pas les µC de résoudre ce problème en arithmétique, il aura plutôt mon raisonnement qui me semble plus naturel, plutôt que de se demander directement comment "contourner" la division.

th.

[invitef86a6203]

http://perso.orange.fr/doumai/Assembleur/Assembleur.htm

C'est un test >=
Dans le cas du zéro c'est l'égalité , > c'est pas = alors leur exemple est faux !

Les 10 mots viennent de AN526. 10x 14bits, cela fait 140 bits, et donc 17,5 octets.

Aucun intéret de compter les bits , on compte des lignes.

il aura plutôt mon raisonnement qui me semble plus naturel, plutôt que de se demander directement comment "contourner" la division.

Oui effectivement mais c'est pas le bon réflexe du programmeur système.
Un printf dans un Pic16F84 remplira la memoire entière.
Conclusion un prog d' 1 ligne.
Alors qu'un code Asm pourrait avoir 1000 lignes sur le même µc.
J'ai l'impression que la pholosophie et méthode de K&R de Berkeley ne sont pas enseignées , dommage ...
http://www.berkeley.edu/
Une page histoire du C
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

[Gérard]

C'est un test >=
Dans le cas du zéro c'est l'égalité , > c'est pas = alors leur exemple est faux !
.....

[/url]

Effectivement, je me suis trompé
dans les tests, il faut lire >= au lieu de >

[invitef26bdcba]

Salut Thm,

Chez Freescale l'instruction DIV, ce n'est pas plutôt 7 cycles ???

Sinon, tu n'as toujours pas compris que chez Microchip il faut regarder la colonne K-WORDS pour connaître le nombre d'instructions possibles en flash ?

Chez Freescale, vu que les instructions font soit 8 bits soit 16 bits, il est impossible de parler en K-Words, vu que par définition, c'est le programmeur qui en fonction de son programme va pouvoir mettre plus ou moins d'instructions dans la flash. Ceci impose donc de parler en K-BYTES pour les µC de chez Freescale...

David.