serin, serout, inapropriés ?

PapyJP

Senior Member
Je souhaite programmer des échanges (TX/DX) avec un périphérique dont les caractéristiques sont les suivantes:

Les échanges se font, dans les deux sens, à 1200 bps .
La trame est composée de dix bits: 1 bit Start suivis de 8 bits de données et d'un bit Stop.
Le débit maximum est donc de 120 caractères par seconde.
Le premier bit est le bit " start ".
Les sept bits suivants correspondent à un caractère ASCII tandis que le huitième est le bit de parité.
La parité est paire c'est à dire que le nombre de bits de donnée en 1, y compris le bit de parité lui-même, doit être pair.
Le premier bit de donnée qui suit le bit Start est le bit de plus faible poids (LSB), le huitième est le bit de parité (MSB).
Les lignes de transfert TX et RX sont au +5V au repos ( non activité ); le bit Start est donc toujours un zéro volt pendant la durée d'un bit.
Le bit Stop est toujours au +5V pendant la durée d'un bit.

Ne serait-ce que parce que ni serin ni serout ni sertxd ne gèrent la parité, ces instructions ne me semblent pas utilisables.
Reste donc
- Pour Tx : à écrire une sous-routine qui mette la trame en forme puis la transmet au rythme voulu sur une pin out
- Pour Rx : une autre en IT pour la réception.
Il faudrait une table des caractères ASCII ...........
Bref c' est une usine à gaz !

Toute idée et commentaires biens venus !
 

fuse

Senior Member
Bonjour PapyJP,

Pourriez vous vérifier vos messages privés, pour cela : il faut se connecter et regarder les notifications.

Cordialement
 

PapyJP

Senior Member
serin,serout

Pourriez vous vérifier vos messages privés
Nouveau sur le Forum, merci de m' expliquer ce subtil distingo.
Fallait-il que je pose la question ainsi:
Peut-on utiliser serx à 1200 baud ( baud est horrible et ne veut rien dire ) ?
Peut-on forcer la parité
................
 

fuse

Senior Member
Oui , il est possible de fonctionner à 1200 bauds. Tout dépend de la fréquence de fonctionnement du Picaxe.
Pour PapyJP, merci de regarder les messages privés :
il faut se connecter et regarder les notifications en haut de la page.
 

PieM

Senior Member
Comme le protocole Picaxe est avec 8 bits de data et pas de bit de parité, et si le périphérique en question est figé, je ne vois personnellement pas de solution ... :(
 

PapyJP

Senior Member
Je m' interroge toujours sur la remarque de Fuse: qu' est-ce qu' un " message privé " par rapport à une question ( toute bête bien sûr, mais qui bloque ! ) ?
Y a-t-il deux plateformes de discussion sur le Forum où il faut aller suivant le pb posé ?
Comment choisir l' une ou l' autre ( si elles existent ) suivant l' interrogation que l' on veut soumettre à leurs membres ?

8 bits de data
Ne peut-on imaginer une variable wx sur 16 bits et ne transmettre en série que la trame de dix bits utiles ?
Ce qui me fait peur c' est la table des caractères ASCII au niveau du Picaxe !
Qu' en pensez-vous ?
 

PapyJP

Senior Member
Quand je consulte le manuel 2, à l' instruction " sertxd " il y a un exemple :
sertxd("The value of b1 is",............).
Ce qui veut dire que le message "............." est transféré sur la ligne en code ASCII ( A = H65, B= H66, C= H67, etc ).
Donc la table ASCII existe dans le Picaxe !
Question ( qui j' espère ne fera pas bondir Fuse ) :
Peut-on atteindre la table des caractères ASCII, à quelle adresse ?
 

PapyJP

Senior Member
Reste un dernier ( ? ) pb :
Existe-t-il en basic un instruction du genre " rotate left/right " qui permet de découper un mot bit par bit ( pour l' émission ) ?
D' autres moyens biens venus.
 

fuse

Senior Member
Bonjour PapyJP,
Il n'y a aucun problème, cela ne me fait pas bondir.... Voila une bonne raison pour utiliser quelques fonctions d'un forum... Donc, il est possible d'utiliser une messagerie propre au forum....
Pour cela, il faut se connecter (pseudo et mot de passe ), dès la connexion effectuée, il y a l’apparition en haut de la page de :
Welcome, 'son pseudo' Notifications MyProfile Tableau de bord utilisateur Déconnexion
Cliquer sur 'Notifications' permet de rentrer dans la messagerie. Après c'est un classique de la messagerie.

Remarque : pas de discussion sur le forum pendant 15 jours : je pars en vacances.

Cordialement
 
Last edited:

PieM

Senior Member
Bonjour,

Donc la table ASCII existe dans le Picaxe !
pourquoi ?
si j'écris :
b1 = 65
sertxd ("Bonjour" , #b1,b1) je vais bien obtenir Bonjour65A, mais à quel niveau se fait la conversion en caractère ascii ?
Si j'utilise des afficheurs LCD, la traduction se fait dans l'afficheur et va dépendre de sa table interne...


Existe-t-il en basic un instruction du genre " rotate left/right " qui permet de découper un mot bit par bit ( pour l' émission ) ?
La seule solution, je pense est d'utiliser les variable b0 à b3 (ou w0 et w2), qui sont accessibles bit par bit par les variables bit0, bit1 ... bit31, sauf sur les "vieux" picaxe qui sont limités à bit15.

Voir également les instructions SETBIT et TOGGLEBIT ainsi que la page 26 du manuel 2 où certaines fonctions permettent de manipuler les variables.
 

PapyJP

Senior Member
Donc, il est possible d'utiliser une messagerie propre au forum....
Merci de m' avoir fait découvrir cette fonctionnalité.
ET merci ( et bravo ) pour ces explications extrêmement claires.

Mais je n' en démords pas !
cf votre copie d' écran page 14 ( volt 13 / volt 2 / etc... ).
Vous savez aussi bien que moi que pour transmettre les chiffres de 0 à 9 il faut utiliser les codes H30 à H39.
Donc pour transmettre 13 c' est bien H31 puis H33 qui transitent sur les fils !
Le Picaxe ne peut pas l' inventer !
Il faut donc, de mon point de vue, qu' il y ait, dans le Picaxe, une table de conversion en ASCII.
Votre avis ?

Si oui, à quelle adresse ?

Si elle n' est pas permanente, peut être est-elle chargée à la programmation ?
 

PieM

Senior Member
J'ignore à qui s'adresse votre dernier post, car vous parlez de copie d'écran que je ne connais pas ...
C'est un peu le problème si on mélange messagerie perso et post forum...

Vous parlez de table ascii, mais il y a une différence entre code et le symbole correspondant, qui lui n'est pas figé en particulier dans la table étendue.
Le picaxe, lui ne connait que les codes en hexadécimal.

Si le logiciel de programmation demande d'écrire la valeur 13, il va le traduire par l'envoi d'un 31 et d'un 33 au picaxe.
Ce n'est pas le picaxe qui décide d'écrire 13!
Si le logiciel de programmation demande d'écrire 13 (et non "13") c'est le code 13 d'un Carriage Return qui est envoyé.

Après le picaxe va le restituer sous la même forme, et ce code sera réinterprété par le terminal, fenêtre du PC ou afficheur quelconque, comme étant les symboles 1 et 3 ou un CR.
 

PapyJP

Senior Member
C'est un peu le problème si on mélange messagerie perso et post forum...
J' ai l' impression que vous n' avez pas accès au message que Fuse m' a adressé ?
Bizarre ! Je pensais que toutes les réponses, sous quelques formes qu' elles soient, étaient destinées aux adhérents, sans " discrimination ". Un Forum est fait pour diffuser son savoir !
Bon, passons.

Je crois comprendre ce que vous m' expliquez :
Supposons que le résultat d' une CAD soit, pour nous, 120 sur une échelle de 0 à 255.
Pour le Picaxe c' est, sauf erreur, H78.
C' est donc H78 qui va transiter sur les fils et c' est le terminal qui, possédant la table de conversion, va afficher 120.
C' est bien ça ?
 

PieM

Senior Member
J' ai l' impression que vous n' avez pas accès au message que Fuse m' a adressé ?
Il faut comprendre cette messagerie en tant que messagerie personnelle; un peu comme si vous échangiez des mails ...

Supposons que le résultat d' une CAD soit, pour nous, 120 sur une échelle de 0 à 255.
Pour le Picaxe c' est, sauf erreur, H78.
C' est donc H78 qui va transiter sur les fils et c' est le terminal qui, possédant la table de conversion, va afficher 120.
Non , ce n'est pas exactement ça.

Un calcul interne va se traduire par une valeur en hexa pouvant aller jusqu'à $FFFF pour 65535.
Si une variable b1 par ex, contient la valeur décimale 120 soit $78 tout dépend de la façon dont on veut que le picaxe transmette cette valeur.

C'est ce que j'écrivais dans un post précédent:
si j'écris :
b1 = 120
sertxd ("Bonjour" , #b1,b1) je vais bien obtenir Bonjour120x

#b1 est interprété comme étant la succession des codes correspondant à 1,2,0 soit $31, $32, $30, et b1 est interprété comme étant le code de x ($78).
Ce sont ces codes qui sont transmis, et le terminal ne fait que les traduire bêtement.
 

PapyJP

Senior Member
C' est parfaitement clair, merci.

Sauf que le # ( dièse ) n' apparaît comme préfixe d' une constante ( manuel 2, page 6 ) et semble réservé aux directives ( manuel 2 page 7 à 9 ).
???????????????
 

PieM

Senior Member
Bonsoir,

C' est parfaitement clair, merci.

Sauf que le # ( dièse ) n' apparaît comme préfixe d' une constante ( manuel 2, page 6 ) et semble réservé aux directives ( manuel 2 page 7 à 9 ).
???????????????
Le # en début de ligne est le code d'une directive. Mais placé avant une variable , il traduit la variable en ses valeurs ASCII lors d'une transmission.
 

PieM

Senior Member
" Faut le savoir " car je n' ai pas le souvenir de l' avoir dans les manuels !
Voir page 46 du Manuel 3:

serout 1,N2400,(“Hello”)- Sends a message to the screen.
serout 1,N2400,(10) - Sends a direct ASCII instruction to the screen.
serout 1,N2400,(b1) - Sends an ASCII character stored in variable to the screen.
serout 1,N2400,(#b1) - Sends a number stored in a variable to the screen.

serin 0,N2400,b1 - Receives an ASCII character from a keypress on the keyboard and stores it as the ASCII value in a variable (b1)
serin 0,N2400,#b1 - Receives a real number from the number keys on the keyboard and stores it in a variable (b1)
 

PapyJP

Senior Member
You are right, as usual !

j' avais sûrement zappé ce § du manuel 3 qui traite d' interfaces et pas de protocole. Tout est mélangé ! Galère !

A propos d' interface, je me pose le pb de savoir pourquoi le cable USB <---> Picaxe coûte, à poids égal, le prix d' un bon foie gras ou de cinq kilos de Tripoux ? ( Je suis Lozérien d' origine, PieM comprendra ... ).
Est-il équipé d' un chipset ( Prolific PL2303, Atmega8U2, ... ), ce qui expriquerait cela ?
 

PieM

Senior Member
A propos d' interface, je me pose le pb de savoir pourquoi le cable USB <---> Picaxe coûte, à poids égal, le prix d' un bon foie gras
Voir ici : 2012-02-28 000.jpg .

Il y a effectivement un morceau de truffe dedans ... :)
 

PapyJP

Senior Member
Il y a effectivement un morceau de truffe dedans
... si bien que l' on ne peut s' en passer.
J' imagine que c' est de la truffe sans odeur ... importée d' un pays d' Asie !
 

BESQUEUT

Senior Member
Truffe pour communications série...

... si bien que l' on ne peut s' en passer.
En même temps, ça m'a tout l'air d'un bête convertisseur USB/série donc on doit pouvoir utiliser du FTDI si c'est plus commode :
==> par exemple relier 4 petits PICAXEs sur un seul port USB via un FT4232H Mini Module (montage en cours...)
 

PapyJP

Senior Member
Remarque très interressante, attendons la suite !
Mais
4 petits PICAXEs
08M2 font dèja la moitié du prix de la truffe !
En lisant la description des échanges usb, le flux descendant n' est pas difficile à extraire puisqu' il suffit de considerer soit D+ soit D- .
La où je vois un pb c' est le flux montant qui doit être parfaitement symétrique à qques ns prés.
Qu' en pensez-vous ?
Donnez de vos nouvelles !
 

PapyJP

Senior Member
Moi, Lozérien, je vais vous sembler plus têtu qu' une mûle Bretonne.
Tant pis, j' insiste:
A la page 45 du manuel 3, je lis
Notice that “text” must be enclosed within speech marks. This tells the microcontroller
to convert the text into a string of ASCII codes.
La phrase " This tells the microcontroller to convert the text into a " string of ASCII codes " me fait penser qu au premier speech mark une sous routine est lancée qui convertit le texte en caractères ASCII tant que l' on ne trouve pas un nouveau speech mark qui entraine un " " return ".
Sinon comment distinguer le "H" ( H72 ) de "Hello" de b1=72
Il faut donc une table ASCII dans le Pic !
J' en perds mon latin !
 

PieM

Senior Member
La phrase " This tells the microcontroller to convert the text into a " string of ASCII codes " me fait penser qu au premier speech mark une sous routine est lancée qui convertit le texte en caractères ASCII tant que l' on ne trouve pas un nouveau speech mark qui entraine un " " return ".
Sinon comment distinguer le "H" ( H72 ) de "Hello" de b1=72
Il faut donc une table ASCII dans le Pic !
J' en perds mon latin !
Précision: les valeurs en hexa sont codifiées avec $ en Picaxe. Le code hexa de H est $48

Le texte , ce n'est pas le picaxe qui l'a inventé ! Si il vous sort un "H" sur le terminal, c'est que vous avez mis un $48 ou 72 dans sa mémoire lors de la programmation. C'est donc lui dire de sortir ce $48 en tant que code ASCII, et non comme valeur 72 qui serait $37 , $32
Un afficheur ou un PC ne reçoit que des codes ascii: si c'est $48, il va sortir H. si il reçoit $37 puis $32 il va afficher 72



Concernant le câble convertisseur USB série, vous pouvez toujours essayer d'inventer quelque chose ou d'utiliser votre propre câble avec puce FTDI. Si vous avez du temps à perdre ... Mais si ça ne marche pas avec Programming Editor, ce qui est fortement probable, n'espérez pas trouver de l'aide sur le forum (y compris le forum anglais !)
 

PapyJP

Senior Member
Donc le microcontrolleur ne "convertit" pas comme le dit le manuel ! Ca m' enduit " avec de l' erreur "
Concernant le convertisseur usb<--->série proposé par BESQUEUT, et aprés consultation des spécifs usb, je suis d' accord avec vous .......trés trés difficile ! ...
 

BESQUEUT

Senior Member
Donc le microcontrolleur ne "convertit" pas comme le dit le manuel ! Ca m' enduit " avec de l' erreur "
Concernant le convertisseur usb<--->série proposé par BESQUEUT, et aprés consultation des spécifs usb, je suis d' accord avec vous .......trés trés difficile ! ...
Je précise que le FT4232H comporte 4 convertisseurs indépendants sur un seul port USB. Il n'est pas nécessaire de bidouiller avec le protocole USB. Par contre si les sorties série sont inversées, il faut utiliser un driver adapté (max232 ?), ce qui est de toutes façons nécessaire à cause de la longueur des lignes RS232. Il est aussi possible de faire du bit-bang (et donc de travailler en inversé) mais seulement sur 2 des 4 ports.
Si le port de programmation n'est pas utilisable, reste le port série "normal" qui est correctement normalisé. L'inconvénient est qu'il n'est plus possible de reprogrammer les Picaxes in situ.
 

BESQUEUT

Senior Member
Concernant le câble convertisseur USB série, vous pouvez toujours essayer d'inventer quelque chose ou d'utiliser votre propre câble avec puce FTDI. Si vous avez du temps à perdre ... Mais si ça ne marche pas avec Programming Editor, ce qui est fortement probable, n'espérez pas trouver de l'aide sur le forum (y compris le forum anglais !)
OK pour ça : pour un seul PICAXE et si la ligne est courte, le jeu ne vaut pas la chandelle.
 

PieM

Senior Member
Si le port de programmation n'est pas utilisable, reste le port série "normal" qui est correctement normalisé.
:confused: et vous modifiez le bootloader pour qu'il soit à l'écoute d'un autre port ??

pour un seul PICAXE et si la ligne est courte, le jeu ne vaut pas la chandelle
Je ne comprends pas beaucoup ... en principe P. Editor ne programme qu'un seul Picaxe. Quant à la longueur de ligne, il m'arrive d'utiliser un cable USB sur plus de 8m sans problème.
 

PapyJP

Senior Member
1/ Un conseil svp !
Je reste strictement dans le sujet qui me préoccupe ( voir mon message original ) mais la question que je vais poser le dépasse certainement:
Je souhaite programmer des échanges (TX/DX) avec un périphérique ....[ /QUOTE].
Dois-je continuer la conversation ou ouvrir un nouveau post ?
Quelles sont les habitudes du Forum ?
2/ Question :
En assembleur, avec un Pic cadençé par un quartz 4 MHz par exemple, on sait que 33 des 35 instructions disponibles nécessitent 4 cycles d' horloge, soit 1 microseconde par instruction.
Si bien que l' on est parfaitement maître du temps entre deux évènements.
Si l' on programme un retard par comptage ( équivalent d' un do ... loop until ), en tenant compte du temps du "do" et du "loop until" on peut ajuster le retard obtenu à la us prés.
A ton une idée ( ou mieux une mesure ) du temps nécessaire à l' éxécution des instructions en Basic ?
 

PieM

Senior Member
Bonsoir,

Je crains que votre démarche soit vouée à l'échec. Le Picaxe fonctionne avec un interpréteur basic.
La durée d'exécution des instructions n'a donc rien à voir avec ce qui se passe dans un PIC et son assembleur.

A titre indicatif, un simple LOW 0 demande plus de 250 µs à 4 MHz, et dépend du type de Picaxe.
 

PapyJP

Senior Member
Merci de votre réponse à 2/ ... décevante !
Il faudra faire avec ................
mais quid de la 1/ ?
 

barbudor

New Member
Bonsoir,

Pour la question initiale :
7 bit + 1 bit de parité == 8 bit
Il suffit de gérer "à la main" le bit de parité :
- En émission, créer le 8eme bit (poid 128) pour correspondre à la parité. Par exemple pour envoyer le caractère "H" (soit $48) le 8eme bit doit prendre la valeur 0 (donc le résultat est toujours $48). Pour le caractère "C" $67, le 8eme bit doit prendre la valeur 1 donc le résultat final est $E7.
- En réception, on peut vérifier la parité en comptant le nombre de bits à 1. Si le résultat est impair, le caractère doit être ignoré puisque la parité est fausse. Si le résultat est pair, on continue en ignorant/masquant le 8eme bit pour ne traiter que les 7 bits utiles.

Les circuits gérant la parité, font cela pour vous. Quand ils ne le font pas, on le fait soi-même...
 

BESQUEUT

Senior Member
:confused:principe P. Editor ne programme qu'un seul Picaxe. Quant à la longueur de ligne, il m'arrive d'utiliser un cable USB sur plus de 8m sans problème.
J'ai donné peu de précisions sur mon projet actuel pour ne pas dériver trop du sujet initial ; l'idée est de disperser des "petits" Picaxe un peu partout dans la maison pour des besoins domotiques (température, humidité, alarme, volets roulants,...) et de rapatrier tout ça sur un PC "embeded". A terme, il pourrait y avoir 12 ou plus liaisons série à rapatrier sur le PC. Du coup, j'ai un intérêt à multiplier le nombre de ports série sur un même port USB. Par ailleurs, la longueur des câbles atteint facilement 25 m avec tous les détours nécessaires, et peut voisiner des courants forts. D'où la nécessité d'une bonne immunité aux parasites. (c'est ce que j'ai nommé en raccourci "lignes longues"). Enfin je souhaite pouvoir mettre à jour les Picaxes "in situ" parce qu'ils ne sont pas facilement accessibles... P. Editor peut programmer autant de Picaxes que l'on veut : il suffit de choisir le bon port série.

Pour revenir au sujet initial, je confirme que 7 bits+1 bit de parité=8 bits donc c'est facilement gérable, par exemple en utilisant les variables bits : qquelque chose comme :
bit7=bit0+bit1+bit2+bit3+bit4+bit5+bit6
 
Last edited:

barbudor

New Member
l'idée est de disperser des "petits" Picaxe un peu partout dans la maison pour des besoins domotiques (température, humidité, alarme, volets roulants,...) et de rapatrier tout ça sur un PC "embeded"...... Du coup, j'ai un intérêt à multiplier le nombre de ports série sur un même port USB.........Enfin je souhaite pouvoir mettre à jour les Picaxes "in situ" parce qu'ils ne sont pas facilement accessibles...
Ce n'est pas le sujet lancé par PapyJP, c'est du détournement de de sujet :D Je pense qu'ici comme sur d'autre forums, lancer un sujet séparé semble plus approprié.....

Toutefois, jusqu'à combien de "périphériques" comptes tu connecter à ton PC ? 3, 10, 30, 100 ?
La multiplication des ports série sur le PC n'est pas forcément la bonne solution, non plus que le câblage en étoile que cela impose. As tu envisagé une solution de type réseau. Par exemple regarde ce qui est proposé dans ce sujet http://www.picaxeforum.co.uk/showthread.php?7694-quot-SerialPower-quot-true-two-wire-data-power-network
On y parle d'un réseau à 2 fils transportant à la fois la communication et l'alimentation.

Pour ce qui est de la mise à jour a distance, c'est plus sioux, mais tu devrait pouvoir t'en sortir avec les instructions "disconnect" et "reconnect".
A priori, si tous les PicAxe effectuent un "disconnect" au démarrage, cela désactive la fonction de mise à jour. Il suffit de la réactiver unitairement sur une unité par un message idoine pour que seule cette unité prenne en compte le protocole de mise à jour, et cela même si plusieurs unités sont reliés sur le même "réseau".
 

PieM

Senior Member
Bonjour,

Concernant ce problème de parité, on peut s'amuser à le gérer soit même, mais il faut penser que l'on travaille ni avec un circuit spécialisé, ni avec un Pic.
Les temps de traitement sont relativement longs avec un Picaxe, les peek et poke par exemple, demandent plusieurs centaines de µs.

Et il n'a que peu d'instructions qui permettent de gérer bit à bit.
Comme je le faisais remarquer en #10, les bit0 ... bit32 se limitent au mieux à 4 bytes.
Cela est peut être réalisable en fonction du problème, mais le picaxe va passer son temps à faire du codage /décodage.

Je crois que le plus simple, est que PapyJP donne un exemple de la transmisioon à assurer, avec ses contraintes, et chacun pourra voir si c'est facilement gérable, en proposant le code...

Les circuits gérant la parité, font cela pour vous. Quand ils ne le font pas, on le fait soi-même...
N'hésitez pas à lui proposer le code pour un Picaxe ... :)
 
Last edited:

BESQUEUT

Senior Member
Les temps de traitement sont relativement longs avec un Picaxe
Je crains bien que le problème soit essentiellement là...
En relisant le premier post, il n'y a pas que 7+1 bits de données à traiter...
Il y a aussi un bit de start et un bit de stop (qui bien souvent est un demi bit d'ailleurs...)
voir
http://arsene.perez-mas.pagesperso-orange.fr/transmission/seriel_async/seriel_asynchrone.htm
Avec un peu de chance, le Picaxe génère un signal "compatible" avec le périphérique. Dans ce cas, on s'en sort à moindres frais avec les instructions sertxd (il faut seulement ajuster le bit de parité)
Sinon, il faut aussi traiter les bits de start et de stop et du coup tous les autres...

Le coté positif, c'est la vitesse limitée à 1200 bauds soit 120 caractères x 10 bits par seconde.
Le timing sera sans doute spécialement difficile à mettre au point, mais ça semble à priori jouable avec l'aide de l'oscillo.
Le fun de l'affaire, c'est que la durée d'éxécution de chaque instruction n'est pas documentée. Il faudra donc se renseigner sur Internet...
et expérimenter. L'idée, c'est d'intercaler le calcul du prochain octet dans les temps d'attente de la transmission de l'octet en cours...
on doit donc travailler sur 2 octets en même temps.
Si c'est un peu limite, on peut largement augmenter la vitesse du Picaxe.
C'est sur que le Picaxe va passer pas mal de temps à traiter des bits, mais faire ça ou un "do loop" ça ne lui fait ni chaud ni froid...

Autre problème : il faut aussi la réception... On peut probablement se passer du calcul de parité puiqu'il ne semble pas y avoir de réel protocole pour retransmettre les bits erronés. (ça fait belle lurette (oui c'est la copine de Gai Luron...) que plus aucun périphérique ne retransmet les octets ratés, mais sait-on jamais avec les antiquités ?)
Par contre la synchro sur la trame ne sera pas une partie de plaisir, surtout avec un Picaxe. je conseille l'utilisation d'un quartz externe, qui outre l'augmentation de vitesse permet au moins d'avoir une horloge stable...
Si après tout ça PapyJP est toujours partant, et qu'il arrive à communiquer avec son périphérique, disons avec un PC, ce serait bien d'avoir les images oscillo des trames échangées pour lui proposer des pistes sur la programmation.
 
Last edited:

barbudor

New Member
Je crains bien que le problème soit essentiellement là...
En relisant le premier post, il n'y a pas que 7+1 bits de données à traiter...
Il y a aussi un bit de start et un bit de stop (qui bien souvent est un demi bit d'ailleurs...)
Non.
Le bit de start et le bit de stop font partie intégrante du protocole asynchrone qui est pris en charge par le soft (serout/serin) ou le hard (hserout/hserin) du PicAxe.
Il n'y a besoin de se préoccuper que des données utiles.

Je suis d'accord avec la parité entrante, si on oublie le risque d'erreurs de transmission, on peut l'ignorer. De toute façon, s'il y a des erreurs sur 1 octet, ce n'est pas le protocole asynchrone qui va gérer la retransmission. Il faut une couche supplémentaire.

En émission, si le temps de calcul de la parité est trop important, et si on a assez de mémoire, le plus simple est de faire une table qui renvoie directement la bonne valeur. Index : la valeur utile sur 7 bits à envoyer, Valeur 8 bit avec la parité correspondante.
Je n'ai pas encore regarder en détails comment on gère les tables en BASIC PicAxe, donc je laisse quelqu'un d'autre guider si besoin.
 
Top