serin, serout, inapropriés ?

BESQUEUT

Senior Member
Je ne serais pas aussi affirmatif dans la négation...
Il y a certes une bonne probabilité pour que ces bits soient correctement gérés par le Picaxe (c'est ce que j'ai appelé "compatible")
Toutefois, j'ai déjà travaillé sur des engins (certes anciens) particulièrement pointilleux sur la durée du(des) bits de stop...
C'est aussi pour celà que je conseille l'utilisation d'un quartz : on a ainsi une fréquence bien calée et bien stable. Du coup, le problème de synchronisation (puisque l'on est dans le cas d'un protocole asynchrone) est moindre, et le récepteur est plus tolérant sur la durée des bits de stop.
Pour le codage du bit de parité, je regarde ça dès que j'ai un moment. Pour info, la gestion des tableaux en basic Picaxe est...
sommaire.
Code:
EEPROM 0,("ABCDEF")

for b1 = 0 to 5
	read b1,b0			; lecture del'EEPROM
	b9=b0
	bit7=bit0+bit1+bit2+bit3+bit4+bit5+bit6	' parité PAIRE
	sertxd (b9," ",#b9,"=>",#b0," ",#bit7,#bit6,#bit5,#bit4,#bit3,#bit2,#bit1,#bit0)
next b
 
Last edited:

PapyJP

Senior Member
Bonsoir à tous et merci de vos conseils et de vos messages.
Je vous soumets l' état de mes réflexions concernant mon projet dont vous trouverez le cahier des charges en #1.
Ce soir il ne s' agit que de l' émission de caractères du Picaxe vers le périph.
(Pour la réception, to morrow is an other day).

Je comprends que
1/ le Picaxe transmet 8 bits ( 1 start + 7 datas ? )
2/ Il n' y a aucune maîtrise de temps ( #31 )
3/ il n' y a pas d' instruction ' rotate ' ( #10 ).

J' ai donc deux pb à résoudre:
- Ajouter la parité
- Maîtriser le temps

1/ Ajouter la parité.
Dans la trame de dix bits attendue par le périph, le premier ( start ) est toujours à zéro ( je rappelle que la ligne est au +5v au repos ) et le dernier ( stop ) est à un pendant la durée d' un bit ( soit 833 us à 1200 bps ).
Je les oublies.
Reste l' octet à transmettre.
Je propose, AVANT la transmission des trames de recopier l' octet à transmettre dans une case mémoire en lui ajoutant la parité.
Celle-ci est déterminée dans une sous-routine par la méthode des XOR bit aprés bit qui donne "0" si le nombre de 'un' est pair

Ainsi pour chaque octet à transmettre.

2/ Maîtrise du temps ( ? )
Je choisis une pin en output, que je force en "1" au repos. Je l' appelle PIN_OUT
J' écris une sous-routine:
- Envoi du bit Start
low PIN_OUT
timing833
- Envoi de l' octet
lecture bit0 ---> PIN_OUT
timing833
lecture bit1 ---> PIN_OUT
...............
- Envoi du bit Stop
high PIN_OUT
timing833

Cette façon de faire entraine que, lors de l' exécution de la sous routine, le Picaxe ne fait que ça. Un coup de scope devrait alors permettre d' ajuster ' timing833 ' pour obtenir du 1200bps

J' ajoute que généralement le récepteur déclenche un retard de 416 us au flanc descendant du bit start puis des retards de 833 us pour lire l' état de la ligne " au milieu " du créneau d' état des bits.
A 1200 bps, le timing n' est pas critique et le récepteur pas pointilleux

Qu' en pensez-vous ?
A vous lire PapyJP
 

PieM

Senior Member
Bonjour,

votre méthode me paraît un peu ... lourde.
Faites un petit chronogramme , car il manque des choses dans le déroulé des opérations qui risquent de rendre le timing un peu aléatoire.
N'oubliez pas que mettre une sortie à 1 peut prendre plus de 200µs (28X2 à 8MHz) , et la mettre à 0 va demander moins de temps. La lecture d'un bit n'est pas gratuite en temps, non plus.
Comment passez vous de la lecture du bit (x) à (x+1) ?

D'autre part, si vous n'avez à transmettre que des valeurs texte, c'est effectivement moins compliqué. Mais faite l'exercice de préparer une valeur numérique sur 16 bits ( ex: w5= 533241) pour la transmettre en 7bits data + 1 parité ...

Donnez un exemple précis de ce que vous avez à transmettre; si c'est un caractère alpha toutes les secondes c'est une chose. Si c'est une trame GPS c'est autre chose ! :rolleyes:
 

PapyJP

Senior Member
Merci, je vais piocher plus profond.

J' ai en effet omis de préciser qu' il s' agit exclusivement d' échanges de charactères ASCII.
Voici le début d' un article que j' avais écrit pour une revue d' électronique:
>>
Fini le bon vieux Minitel ?
Sûrement pas ! C' est une véritable aubaine, jugez vous même:
c'est un terminal passif qui possède un clavier alphanumérique, un écran de 1000 caractères, une prise péri-informatique et, cerise sur le gâteau, une sortie alimentation pour périphériques extérieurs qui peut délivrer jusqu'à 1 Ampère !
Il est alors possible de concevoir des applications autonomes ( à base de PIC dans notre exemple ), gérées à partir d'un clavier, contrôlées sur un écran, sans alimentation dédiée, sans composants coûteux et sans mobiliser un PC. Le rêve !
Il ne faut qu'une résistance, un câble DIN de type audio, un régulateur de tension à sortie 5 Volt pour réaliser une application complète et autonome autour d'un PIC.
Les échanges ne consomment que peu de ressources: deux lignes d' E/S seulement !
Et à moindre frais: j'ai trouvé plusieurs Minitel à moins de trois euros( prix maximum ) dans des brocantes et des vide-greniers; de construction très robuste ( ils datent des années 80 ), ils ont tous fonctionnés. Ne pas négliger le jour des «*encombrants «*ni les caves et greniers de vos amis et connaissances.
...
<<
Les applications possibles sont la domotique, le modélisme ferroviaire, ...
J' ai programmé pour un ami un PIC 16F84 qui gère, à partir du Minitel, un petit réseau ferroviaire. On commande les aiguillages au clavier et leur état est affiché sur l' écran.
L' interet est d' installer un poste de commande autonome sans être obligé de monopoliser un PC.
L' inconvénient est que l' utilisation d' un PIC nécessite, pour la moindre modif, la connaissance de l' assembleur et le matériel pour le reprogrammer. Mon ami est souvent venu chez moi !
Pour mes débuts, je souhaite me faire les dents en remplaçant le PIC 16F84 par un Picaxe.
Pour une somme modique, mon ami pourra faire ses modifs lui même ( même si nous restons pendus au téléphone pendant l' opération )
Voilà, vous savez tout !.
 

barbudor

New Member
Pourquoi persister à vouloir le faire à la main au lieu d'utiliser serout/sertxd ?

La définition donnée par PapyJP est à 100% celle d'une transmission série asynchrone.
Cherchez un peu sur Google si vous ne connaissez pas ce qu'est une liaison série. Par exemple jetez un coup d'oeil a l'article simple de Christian Tavernier sur son site (http://www.tavernier-c.com/serie.htm).

Donc l'algorithme reste simplement:
- récupérer la donnée 7-bit
- ajouter le bit de parité (soyez astucieux, ne calculez pas le XOR sur chaque bit....)
- serout numpin, T2400_X, bx

N'oubliez pas la liaison série asynchrone est de base en niveau logique (c'est à dire 0V..5V dans le cas du Picaxe) :
- Etat de repos = high = 5V
- Start = low = 0V
- Bit 0 à 7 = en logique positive (True logic d'où le T2400_x) : '0' = 0V, '1' = 5V
- Stop = high = 5V

Le RS232 est quand à lui une norme de transmission qui change les niveaux (normalement via un circuit type MAX232 par exemple)
- Etat de repos : < 0V (typique -8 à -12V)
- Start : > +3V (typique +8 à +12V)
- Bit 0 à 7 : en logique négative (Inverted logic modes Nxxx_x du Picaxe) : '0' > +3V ; '1' < 0V
- Stop : < 0V


Donc, PapyJP, il est important de s'assurer que la liaison série de vos périphérique est bien en mode "logique positive" (mode T2400_x) ou en mode RS232 "inversée" (mode N2400_x).

Au moins dans "serout", même si cela est effectué en soft par le firmware du Picaxe, il s'agit de temps calibrés qui fonctionnent correctement aux bas débit concernés. Faire la sérialisation à la main ne peut conduire qu'à une perte de temps, un résultat incertain.
 

BESQUEUT

Senior Member
Pourquoi persister à vouloir le faire à la main au lieu d'utiliser serout/sertxd ?
Tout à fait d'accord ! J'ai donné dès tas d'explications pour essayer de contourner ces instructions pensant qu'elles ne convenaient pas mais sans réaliser qu'elles n'avaient même pas été tentées ...
Dur dur de passer de l'assembleur à un langage "évolué" ; il faut faire confiance.
J'ai donné #39 un lien qui me semble assez clair sur les trames séries, et en particulier la longueur du bit de stop qui à mon avis est le seul truc qui risque de poser problème (je mise sur une proba de 5/100 ==> il est fort probable que ça marche tout seul)
J'ai donné #41 une façon de calculer le bit de parité en une seul ligne. SI ce n'est pas clair, ne pas hésiter à demander des explications.
Pour aller plus loin, il faudra savoir ce qui doit être transmis...
Cordialement,
 

PieM

Senior Member
J' ai en effet omis de préciser qu' il s' agit exclusivement d' échanges de charactères ASCII.
A condition qu'ils soient limités à $7F (127) !
Quant aux valeurs numériques, il faut penser à les convertir d'une valeur binaire en une suite de valeurs ascii, qui seront à leur tour converties en 7 bits !
Et si c'est une valeur sur plus de 8 bits, il y a un peu plus de travail de mise en forme à faire avant ...
 

PapyJP

Senior Member
Ouais ....
Relisez, svp, mon cahier des charges ( #1 ) et le titre de la discussion " serin, serout inapropriés ? ".
1/ Il s' agit bien sûr des 127 premiers caractères ASCII puisque, dans les 8 bits data de la trame explicitée, 1 est réservé à la parité.
2/ Tout à fait d' accord, il s' agit bien d' une liaison série asynchrone.
Mais lisez bien mon cahier des charges: la trame est constituée de dix bits ( Start + 8 data dont la parité + Stop ).
Or je lis ( manuel2, page 208 à propos de serout ) :
Function:
Transmit serial data output (8 data bits, no parity, 1 stop bit).
Ca fait 9 bits non ?
Il faut donc que je rajoute un bit Start !
" serin, serout inapropriés "
Si je le fais " con la mano ", et en supposant que je sois maître du temps d' application de ce zéro sur la ligne ( ce qui semble déja un pb à lui tout seul ), au bout de combien de temps la ligne sera mise à jour après l' instruction " serout " ?
 

barbudor

New Member
PapyJP

Et vous, avez vous lu les liens donnés sur les explications de ce qu'est une liaison asynchrones ?
Ou avez vous cherché un peu des articles sur Google ?

Par définition une liaison asynchrone comprend :
a) 1 bit de start
b) 7 à 8 bits utiles
c) 1 bit de parité optionnel
d) 1 ou 1.5 ou 2 bit de stop

a) et d) ne sont pas optionnels et sont géré par serout. C'est comme cela que marche la liaison série ASYNCHRONE RS232 du PC. Et serout marche vers un PC.

La seule chose c'est que les paramètres de serout sont figés :
- 8 bits sans parité : pas de problème on a déjà expliqué comment simuler 7+1 avec 8 bits
- bit de stop 1, ca tombe bien c'est votre besoin

Donc çà fait 3 jours qu'on dit que OUI serout EST APPROPRIE

Pour vous en convaincre, connectez un oscilloscope et regardez par vous même.

Oubliez de gérer une liaison série asynchrone à la main en BASIC : Vous n'êtes pas maitre du temps ! Si vous tenez à le faire, oubliez Picaxe, prenez un PIC brut de fonderie et passez au C ou a l'assembleur, en utilisant interruptions et timer. C'est probablement ce que Picaxe à fait dans son firmware.

L'étape suivante est de déterminer s'il vous faut travailler en mode TRUE (appellé aussi mode TTL) ou en mode INVERSE (appellé aussi mode RS232).
D'après votre premier post vous parlez d'un repos au niveau haut donc apparemment il s'agit du mode TRUE (baudrate Txxxx sur serout).

Maintenant, un dernier point que vous n'avez pas abordé dans votre spec, juste pour être sur avant que vous branchiez le tout, avez vous une spécifications de l'interface électrique ? tension supportées etc ....

Un truc qui aurait fait gagné du temps c'est d'avoir un lien vers la doc des capteurs concernés pour qu'on se fasse une idée.

Bonsoir
 

PieM

Senior Member
En complément pour papyJP, voici de quoi est formée la trame envoyée par un Picaxe si on lui programme un serout xx, N600, ("66"), vu par un analyseur .
La trame comporte bien un bit de start, puis une séquence 01101100 puis un bit de stop. Le 01101100 est bien 6 donc 110110 en binaire, LSB d'abord.

picaxeN600_1.jpg
 

barbudor

New Member
+1

PapyJP, notez bien qu'il s'agit d'un exemple en mode N <inversé> d'ou le repos à l'état bas, le bit de start et le 1er bit "0" transmis par un état haut.
Le mode N est pour une connexion directe avec un périphérique ou ordinateur en RS232 (sans oublier la résistance série de 22K sur l'entrée et le pulldown de 10K si on utilise la même pin que le téléchargement)

En mode T <true> on aurait le contraire.

Code:
______     _._   _._     _.______
      |_._|   |_|   |_._|
       S 0 1 1 0 1 1 0 0 s
Et on n'a pas besoin des résistances, sauf sur pull-down sur l'entrée pour la même raison pour éviter des glitches.

PS: PieM, c'est quoi votre analyseur ?
 

PapyJP

Senior Member
Ok, on avance grâce à vous !
Ceci dit :
Merci à PieM mais sa figure en couleur est illisible sur mon PC ( on ne lui en veut pas, il n' est pas dedans comme disait mon crémier ! )
Ok encore sur la définition d' une liaison asynchrone.
Vous le dites vous même:
La seule chose c'est que les paramètres de "serout" sont figés :
- 8 bits sans parité : pas de problème on a déjà expliqué comment simuler 7+1 avec 8 bits
- bit de stop 1, ca tombe bien c'est votre besoin
Je veux bien croire que "serout" soit précédé d' un bit start, mais par quel miracle ? Le manuel2, page 208 est muet à ce sujet.

Voici comment je programme les échanges en assembleur:
( PIC16F84, "TRAVAIL" reçoit le caractère à émettre, "Réception" est appellé par une IT sur RB0 )
;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
; - Emission vers Minitel d' un caractére ASCII (7 bits) + Parité calculée -
;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
TransfertASCII
movlw 0x07 ;7 bits ==> 7 décalages
movwf INDEX
clrf Parité
;---/ Bit start /--------------------------------
bcf PORTB,1 ;ligne d' émission en zéro
call tempo2 ;pendant la durée d' un bit ( start )
;---/ Emission des 7 bits du code ASCII /--------
Test_bitsASCII
rrf TRAVAIL,f ;rotation à droite via C, le premier bit à sortir est le LSB
btfss STATUS,C ;test de C pour émission du bit
goto EmetZeroASCII
goto EmetUnASCII
EmetZeroASCII
comf Parité,f ;complémente le registre Parité à chaque émission d' un Zéro
bcf PORTB,1 ;émisssion: bit RB1 en Zéro
goto suiteASCII
EmetUnASCII
bsf PORTB,1 ;émission: bit RB1 en Un
goto suiteASCII
;------------------------------------------------
suiteASCII
call tempo2 ;durée 1 bit
decf INDEX,f ;test de l' index
btfss STATUS,Z ;index = 0 ? (Z=1 ?)
goto Test_bitsASCII ;non
;---/ Emission de la parité /--------------------
movf Parité,f ;déplace f dans f mais positionne le bit Z
btfss STATUS,Z ;Z=1 ?
goto ParitéZéro
goto ParitéUn ;si le nbre de zéros est pair, le bit de parité = 1
ParitéUn
bsf PORTB,1
goto Terminé
ParitéZéro
bcf PORTB,1
Terminé
call tempo2 ;durée 1 bit
;---/ Bit stop, Remise à 1 de la ligne ( état repos ) /---
bsf PORTB,1 ; place la ligne en 1 ( non activité )
call tempo2 ; pour au moins la durée d' un bit ( bit Stop )
return
;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
; - Réception d' un octet en série sur RB0 -
;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Reception
call tempo2 ;attente durée 1 bit
btfss PORTB,0
goto zeroreçu
goto unreçu
SuiteReception
decf ComptBits,f
btfss STATUS,Z ;Z=1 ? ( 8 bits reçus ? )
goto Reception ;non
call tempo2 ;attente > bit stop
return
;------------------------------------------------
zeroreçu
bcf STATUS,C
rrf OC_reçu,f ;rotation à droite avec Carry = 0
goto SuiteReception
;------------------------------------------------
unreçu
bsf STATUS,C
rrf OC_reçu,f ;rotation à droite avec Carry = 1
goto SuiteReception
 

PapyJP

Senior Member
Désolé, le " copier-coller " ne respecte pas l' indentation.
Mais vous vous y retrouverez, sûr !
 

PapyJP

Senior Member
Avec un papier calque, gradué grâce aux marqueurs en haut de l' image, et collé sur mon écran je mesure " au pif " les durées ( mais c' est significatif ) en unités arbitraires :
"0" ---> 5
"1" ---> 5,5
"0" ---> 8,5
"1" ---> 5,5
"0" ---> 6
"1" ---> 9
"0" ---> ?
J' ai peut être mal lu sinon le rapport de 5 à 9 me semble incompatible avec une liaison fiable.
On a beau être en liaison asynchrone, le timing est important !
 

PieM

Senior Member
Bonjour,

pour Barbudor, voir ici : scanalogic-2-pro . 4 canaux avec beaucoup de possibilités, et pas très cher !

PapyJP :
J' ai peut être mal lu sinon le rapport de 5 à 9 me semble incompatible avec une liaison fiable.
Vous avez effectivement mal lu ! j'essaierai de vous faire un extrait en T1200 plus lisible ...
 

PapyJP

Senior Member
Merci PieM.
Je reviens " à serout ".
Par définition une liaison asynchrone comprend :
a) 1 bit de start
b) 7 à 8 bits utiles
c) 1 bit de parité optionnel
d) 1 ou 1.5 ou 2 bit de stop
C' est là où je ne suis pas d' accord.
A ma connaissance, une liaison asynchrone n' est pas limitée en nombre de bits à transmettre dans la mesure où émetteur et récepteur sont ' appariés '. Ce peut être 1, 3, ou 47 bits, peu importe. Dans le cas d' une liaison de transfert de caractères ASCII c' est 7 ( 127 premiers caractères ) ou 8 ( table complète )
Donc, quand je lis que serout entraine l' émisssion de 8 data bits+stop, moi je comprends que l' on transmet 8 bits dont le premier est le Start + 7 (demi table ASCII ) + Stop. C' est donc parfaitement compatible.



















=
 

PapyJP

Senior Member
PieM,
C' est bien un chronogramme d' un " serout " à 600 bps ?
Si oui, je décode ( Start + 8 datas + Stop ) soit dix bits en effet.
C' est donc pas comme écrit dans les livres !
J' ai horreur de ça !
 

PieM

Senior Member
Voilà:

sur le même graph, une sortie serout xx, T1200, ($55) soit 01010101 et un T1200, ($AA) soit 10101010. Fait à partir d'un 08M donc sur oscillateur interne.
Il est à noter que l'on peut agir sur la fréquence interne des oscillateurs, par l'instruction basic CALIBFREQ ou POKESFR.
Picaxe_T1200.jpg
 

PieM

Senior Member
PieM,
C' est bien un chronogramme d' un " serout " à 600 bps ?
Si oui, je décode ( Start + 8 datas + Stop ) soit dix bits en effet.
C' est donc pas comme écrit dans les livres !
J' ai horreur de ça !
:) 8 bits data, c'est 8 bits de data Le bit de start est implicite car il existe toujours! par contre on précise bit de parité qui peut être présent ou pas, et le bit de stop qui peut être 1 ou plus.
 

PapyJP

Senior Member
implicite, implicite ... !
C' est mieux en le disant.
La preuve en est que si ça avait été clair ( voir mon interprétation de serout en #57 qui, je pense, n' est pas stupide ) cette discussion serait close depuis longtemps.
J' espère ne pas avoir à " impliciter " avec d' autres instructions. Vous savez autant que moi que la programmation exige une grande rigueur.
J' ai reçu les composants ce matin. Je vais donc pouvoir " maniper ".
Attendez-vous à de nouvelles questions, surtout s' il faut lire entre les lignes ( impliciter ), exercice dans lequel je me découvre mauvais !!!!!!
 

BESQUEUT

Senior Member
... la programmation exige une grande rigueur.
J' ai reçu les composants ce matin. Je vais donc pouvoir " maniper ".
Ca devient quasiment philosophique...
Le monde en général et l'informatique en particulier deviennent si complexes que plus personne n'espère plus une rigueur absolue. Du coup, on essaye : si ça marche, tant mieux. Sinon (et seulement sinon) on essaye de comprendre pourquoi...
Pas très satisfaisant, mais bon, c'est comme ça.
Autre remarque : on n'a pas toujours besoin d'avoir le matos pour travailler et on gagne souvent pas mal de temps avec le simulateur. C'est dans cet état d'esprit que j'ai donné un bout de code pour calculer le bit de parité. Le simulateur est une bonne façon de se faire la main sans forcément aller jusqu'au hardware. Cela permet de tester différents paramètres et/ou différents algorithmes sans se laisser déconcentrer par le transfert et le test in situ. Ce dernier se fera une fois la solution soft au point.
 

PapyJP

Senior Member
Tranche de vie et philosophie.
si ça marche, tant mieux. Sinon (et seulement sinon) on essaye de comprendre pourquoi...
C' est peut-être vrai aujourd' hui, pour les jeunes, qui vont en effet au plus court. Réfléchir est un exercice qui les fatigue.
Moi, toute ma vie, je suis resté curieux et essaye encore et toujours de " comprendre pourquoi "
Entré à l' école d' ingé en 1958 ( vous pouvez estimer l' âge ( canonique ) que j' ai ) , c' était le monde des tubes.
Les premiers transistors ( au Germanium ) étaient réservés aux profs ( de peur que les élèves ne les fusillent, vu leur prix à l époque ).
Une grande partie de ma vie professionnelle a été consacrée à l' étude et à la compréhension des nouvelles technologies, au fur et à mesure de leurs apparitions ( et elles ont été nombreuses en plus de cinquante ans ! ).
Sans curiosité ni compréhension, j' en serais encore à l' âge des tubes.

Concernant votre remarque, je suis mille fois d' accord avec vous.
C' est la ( bonne ) méthode que j' utilise quand je programme en assembleur.
Ceci dit, je brûle d' envie de câbler ces mille-pattes !
 

BESQUEUT

Senior Member
Ceci dit, je brûle d' envie de câbler ces mille-pattes !
Et bien vas-y Papy ! 2 résistances à piquer dans la plaque d'essai, un cordon de programmation et tu peux déjà avoir des datas sur l'écran...
Ca c'est vraiment le bon coté des Picaxes...
 

PieM

Senior Member
Une petite précision s'impose:
si c'est le mode T1200 qui est nécessaire, on ne peut utiliser l'instruction sertxd qui est à N4800 ou N9600, non configurable, mais utiliser serout sur une autre sortie.

D'autre part, à l'initialisation d'un picaxe, la sortie utilisée pour la ligne de com reste au niveau bas. Il faut donc avant le premier serout True, mettre la sortie correspondante au niveau haut pour éviter que le premier caractère transmis soit erroné.
Ensuite, après le bit de stop, la ligne reste à l'état haut.
 

PapyJP

Senior Member
Merci de ces précisions ! ... et de ces encouragements !
Je lance un défi :
Serais-je le doyen du Forum ?
Si oui, vous me devez le respect !
Non, je déconne...................
 
Last edited:

PapyJP

Senior Member
BESQUEUT
Je ne comprends pas votre façon de calculer la parité ( #41 )
bit7=bit1+bit2+...............
car bitx ne peut avoir que deux valeurs.
bitx = 0 ou 1
Ok?

Or le " + " est le signe de l' addition ( manuel2, page 22 ) et n' est un opérateur Booléen ( même page en fin de liste ).
Si j' ai b0 = $65 ( ç' est bien écrit comme ça bien ça, PieM ? ), bit7 est >1 mais ne retourne pas la parité ?????????????
Y aurait-il encore qqchose à impliciter ?
 

BESQUEUT

Senior Member
:) Ca m'étonnais que personne ne me pose ce genre de question...
car bitx ne peut avoir que deux valeurs.
bitx = 0 ou 1
Je confirme, donc ...
0+0=0
0+1=1
1+1=0
etc...
A noter que la formule est valable pour calculer le bit de parité paire.
Si c'est la parité impaire qui est voulue, il faut ajouter 1.
NB : en parité paire, la somme de tous les bits (y compris le bit de parité) doit être paire (donc = zéro en algèbre binaire).
Normalement, on doit pouvoir contrôler le résultat avec le simulateur...
 

PieM

Senior Member
PapyJP,

Vous vouliez calculer la parité avec des XOR ? c'est strictement équivalent sur le plan logique ....

bit7= bit6 xor bit5 xor bit4 xor bit3 xor bit2 xor bit1 xor bit0

Le + est équivalent au AND logique.
 

PapyJP

Senior Member
Votre table de vérité est manifestement un XOR.
Or le " + " est le signe de l' addition ( manuel2, page 22 ) et n' est pas un opérateur Booléen ( même page en fin de liste ).
Cela veut-il dire que "3+4 = 7"
mais que ( si " bit0 = 1 et bit1 = 1 " ) alors " bit0+bit1= 0 ( et non = 2 ) ce qui devrait s' écrire bit0 ^ bit1 = 1 ?
 

BESQUEUT

Senior Member
bit7= bit6 xor bit5 xor bit4 xor bit3 xor bit2 xor bit1 xor bit0.
Excellente remarque !
En vieil habitué du VB (qui ne connait pas le XOR), je n'avais même pas vérifié : mais OUI le picaxe connait aussi les opérations logiques (ce qui est somme toutes assez logique...)
Il faudrait faire des essais, mais il est même probable que cette formulation soit exécutée plus rapidement...
 

BESQUEUT

Senior Member
si " bit0 = 1 et bit1 = 1 " alors " bit0+bit1= 0 ( et non = 2 ) ce qui devrait s' écrire bit0 ^ bit1 = 1 ?
En fait, il est probable que le Picaxe calcule effectivement un deux, puis le convertit en un seul bit en prenant le bit de poids faible qui est un zéro.
La conversion d'un octet en un bit que vous décrivez (XOR sur les bits) n'est pas habituelle en BASIC ; j'ai toujours vu la méthode sommaire décrite ci-dessus et qui permet de travailler sur des bits même si les opérateurs ad hoc ne sont pas dans le langage.
En tout cas, je confirme que l'expression proposée par PieM est plus exacte intellectuellement et sans doute plus rapide, même si le résultat est le même.
 
Last edited:

PapyJP

Senior Member
Je ne vous cache pas que ça commence à m' énerver ( le mot est faible ) d' avoir des manuels, d' ailleurs fort rébarbatifs, qui décrivent formellement la syntaxe et les protocoles mais que l' on peut ( et doit ) contourner !
Après le coup du bit start " implicite ", voici que l' on peut écrire bit0 xor bit1 au lieu de bit0 ^ bit1.
Où est la rigueur ?
Existe-il des tutoriels qui décrivent toutes ces astuces pour contourner les règles décrites dans les manuels ?
Je suis très déçu
 

PieM

Senior Member
Je ne vous cache pas que ça commence à m' énerver ( le mot est faible ) d' avoir des manuels, d' ailleurs fort rébarbatifs, qui décrivent formellement la syntaxe et les protocoles mais que l' on peut ( et doit ) contourner !
Après le coup du bit start " implicite ", voici que l' on peut écrire bit0 xor bit1 au lieu de bit0 ^ bit1.
Où est la rigueur ?
Existe-il des tutoriels qui décrivent toutes ces astuces pour contourner les règles décrites dans les manuels ?
Je suis très déçu
Concernant le bit de start que j'ai qualifié d'implicite, je suis désolé, mais c'est la norme du protocole.
Si vous utilisez de l'I2C, ou du SPI, il y a d'autre signaux qui transitent sans que le manuel soit "explicite" sur le sujet

Sinon la rigueur est page 22 du manuel 2: et il n'y a aucun contournement de règle ...:)


The mathematical functions supported by all parts are:

AND
&​
; bitwise AND
OR
|​
; bitwise OR (typed as SHIFT + \ on UK keyboard)
XOR
^​
; bitwise XOR (typed as SHIFT + 6 on UK keyboard)



D'autre part quand on écrit bit0 + bit1 si les deux sont à 1, le résultat est effectivement 2 soit 10 en binaire si c'est écrit dans un octet. Mais comme on travaille sur un seul bit, c'est donc le LSB 0 qui sera le résultat. Donc 0.


En tout cas, je confirme que l'expression proposée par PieM est plus exacte intellectuellement et sans doute plus rapide, même si le résultat est le même.
Pas bien certain que ce soit plus rapide ! Si j'ai un peu de temps, je ferais un test ... pour le fun .
 

PapyJP

Senior Member
Et ben !
C' est bien ce que je dis
En ( #71 ) A xor B doit s' écrire " A ^ B " et pas " A xor B " !
Ou alors j' ai rien compris ( as usual )
 

PieM

Senior Member
Et ben !
C' est bien ce que je dis
En ( #71 ) A xor B doit s' écrire " A ^ B " et pas " A xor B " !
Ou alors j' ai rien compris ( as usual )

Lisez Manuel 2 page 22 :
quand on écrit AND & ; bitwise AND , c'est que les deux écritures sont possible comme dans beaucoup de progiciels . Faire un test sur PE est facile ...

un exemple en dessous vous dit :
The modulus (// or %) command returns the remainder of the calculation.
 
Top