Detecter un silence de 3,5 octets sur UART

[invitedf53f6be]

Bonjour!
Je suis en train d'implementer le protocole Modbus dans un microcontroleur (un pic 18F2520)
La fin de la trame requête venant d'un maître est définie par un silence de 3.5 octets. C'est à ce moment là que je traite la trame du maitre, ect...
Je ne parviens pas à imaginer un système pour compter ce silence, est-ce que quelqu'un aurais une ou deux pistes?
Pas besoin du programme, juste une idée.
Je pensais démarrer un timer à chaque réception d'un octet, mais quelle est la durée d'un octet ?

Merci à vous !
-----

[Seb.26]

mais quelle est la durée d'un octet ?

> TU as combien de bits dans un de TES octets ?

> TU envois/reçois TES bits à quel débit ?

... ensuite une bête multiplication devrait suffire ...

[invitef86a6203]

baud = bit par seconde
avec 1 start et 1 stop ça fait 10 bits
1200 bauds fait 1200/10 = 120 octets à la seconde
pour 3 faire
1/1200 x (3 x 10) = 25 ms

mettre en route le timer pour ce temps et au dépassement traiter.

[invite8699d527]

> TU as combien de bits dans un de TES octets ?

heu par définition un octet c'est pas 8 bits par hasard?

[A voir en vidéo sur Futura]

[Seb.26]

heu par définition un octet c'est pas 8 bits par hasard?

désolé, je croyais que tout le monde était assez malin pour comprendre ce que je voulais dire ...
( petite boutade ... )

[polo974]

heu par définition un octet c'est pas 8 bits par hasard?

C'est comme les petits pois:

• il y a la valeur nette égouttée (8) ,
• la valeur nette (plus parité),
• et la valeur brute (plus start et stops)...

(protocole de m..., où il faut attendre longtemps pour savoir si c'est fini...)

[invite29971eb1]

C'est comme les petits pois:

• il y a la valeur nette égouttée (8) ,
• la valeur nette (plus parité),
• et la valeur brute (plus start et stops)...

ça y ressemble effectivement

(protocole de m..., où il faut attendre longtemps pour savoir si c'est fini...)

Pour un protocole qui traverse des usines et est destiné par définition à des automates poussifs, faut pas trop se plaindre

[invite8699d527]

je suis d'accord pour dire qu'un paquet (ou mot) à envoyer peut avoir une taille variable mais de la à dire qu'un octet fait plus de 8 bits, faut pas pousser! dictionnaire : "Unité logique en système codé binaire, constituée de huit caractères binaires ou bits". Si tu dis qu'un octet sur telle liaison fait 10bits, c'est faux. Donc si la personne parle en octets sans rien préciser d'autre, c'est des mots de 8 bits et c'est tout. Bon, on va pas aller plus loin. Je pense juste aux gens qui n'y connaissent pas grand chose et qui tombe sur des sujets comme ça et qui voient qu'il existe des octets de taille différentes...

[invitefddea992]

bonjour ,

pour detecter ton silence ... de 3.5 octet
mettre un timer en route ......
des que tu recois ton octet tu met ton timer a zero
tu testes si il a debordé ( par exemple en testant le bit de debordement du timer ) quand tu es en attente de reception si il a deborder ben tu as exedé le temps des 3.5 octets

c est le principe de l homme mort a la sncf

[Seb.26]

My 2 cents :

Evidement blacksword a 100% raison : un octet c'est 8 bits et point barre ...

Mais justement dans la question : << TU as combien de bits dans un de TES octets ? >>
... étant donnée qu'un octet fait par définition 8 bits, ne faut il pas justement chercher un peu plus loin ?! ... ou alors la question n'a aucun intérêt ...

Concernant la question de départ, si la précision voulue est trop grande, une interruption sur changement d'état de la pin Rx peut être nécessaire (si le uCPU le permet) ... mais un timer sur chaque Rx devrait suffire AMA.

[invite8699d527]

ce que notre ami voulais dire je pense c'est comment calculer le temps de réception de 3,5 octets (ce qui se fait en 2s quand on a la vitesse de transmission).
Pour répondre au problème, perso à la fin de réception de chaque octet je lance un timer puis, à la réception de l'octet suivant je teste la valeur du timer comme ça, si le timer est arrivé à la valeur correspondante au silence, c'est gagné, on a détecté le silence, sinon je le remet à zéro et ainsi de suite

[jiherve]

Bonsoir,
permettez à un vieux singe de rigoler!
un octet transmit c'est comme freepicbasic le souligne 1 start ,8 bits(ou 7), éventuellement une parité , et un ou deux stop.
Les stops sont virtuels et correspondent à un état iddle de la ligne.
Donc le problème est résolu en connaissant la vitesse de transmission et en majorant la durée de transmission d'un octet, en l'occurrence il faut donc tabler sur 1+8+1+2 ce qui fait 12 "bit period".
Il y en a que je n'embaucherais pas!
JR

[Jack]

La fin de la trame requête venant d'un maître est définie par un silence de 3.5 octets. C'est à ce moment là que je traite la trame du maitre

Je ne vois pas l'intérêt d'attendre tout ce temps avant de traiter la trame. Au contraire, je la traiterais le plus vite possible, dès la réception du CRC.

A+

[polo974]

Je ne vois pas l'intérêt d'attendre tout ce temps avant de traiter la trame. Au contraire, je la traiterais le plus vite possible, dès la réception du CRC.

A+

Ah-ah..., ça c'est de la triche intelligente: supposer que si le mot reçu correspond au crc attendu, se dire que c'est le crc... (une chance sur 65536 de se planter sans autre information...)

En pré-décodant la commande, on doit sans doute avoir une idée de la longueur du message, ce qui rend la méthode plus fiable.

Tout ça parce-qu'ils ont oublié de mettre la longueur dans l'entête (il devait y avoir un brevet à contourner )...

A blacksword: comme tu indiques, tu ne peux jamais exploiter le dernier message, très mauvaise méthode (acceptation du message n à la réception du début du message n+1...

[invitedf53f6be]

Je ne vois pas l'intérêt d'attendre tout ce temps avant de traiter la trame. Au contraire, je la traiterais le plus vite possible, dès la réception du CRC.

A+

Comme dit juste avant, comment savoir si un octet est un CRC ou une partie du message.
Une autre méthode consisterait à lire des trames de longueur fixe (la trame de lecture (Fct 4) a toujours la même longueur) ça fonctionne très bien quand tu n'as qu'un seul esclave.
Il se trouve que j'en ai deux sur la même ligne et avec cette méthode, ils n'interfèrent l'un l'autre...

Merci freepicbasic, c'est justement baud = bit par seconde que je ne parvenais pas à bien intégrer.

Merci blacksword: c'est vrai que c'est tout simple...

Merci aux autres !

Je vous tiens au courant !

[invite8699d527]

j'ai du mal comprendre alors, ton traitement faut le faire après le silence où dès qu'il commence? Si c'est le premier cas ma méthode marche, dès que le timer est arrivé à la valeur voulue pour le silence (et pas besoin d'attendre de recevoir un octet pour ça) tu fais ton calcul. Si c'est le deuxième cas, à part faire de la divination je vois pas trop

[invitedf53f6be]

nonnon, tu as bien compris. c'est bien comme ça que je compte proceder. j'ai dit autre chose ?

[invite8699d527]

ben non c'est pour ça que je voyais pas pourquoi tu disais que ma méthode est foireuse. T'as pas vraiment le choix, t'es bien obligé de lancer ton timer à la fin de réception de chaque octet et dès qu'il arrive à la bonne valeur (tu peux le faire déborder et gérer l'interruption aussi) tu traites ta trame. Sinon, dès qu'un octet arrive tu remet ton timer à 0 et tu le relance à la fin de la réception. Je vois pas ce qu'il ne marche pas là dedans

[invitedf53f6be]

J'ai pas dit que ta méthode est foireuse, il me semble ... Au contraire, puisque c'est ce que je fait ...

[Jack]

Comme dit juste avant, comment savoir si un octet est un CRC ou une partie du message.

A chaque code fonction correspond une longueur de trame déterminée, non?

A+

[invitedf53f6be]

Pour les lectures et écritures simples, oui.
la longueur d'une ecriture multiple peut varier, même si le neombre de champs à modifier est précisé dans la trame.

[Jack]

un exemple?

A+

[invitedf53f6be]

Bien sûr:
(Extrait de la datasheet)
Fonction 16 (0x10):
Function code 1 Byte 0x10
Starting Address 2 Bytes 0x0000 to 0xFFFF
Quantity of Registers 2 Bytes 0x0001 to 0x007B
Byte Count 1 Byte 2 x N*
Registers Value N* x 2 Bytes value
*N = Quantity of Registers
Voili voilou !

[Jack]

oui, donc aucun problème, il suffit de récupérer la donnée "byte count" pour savoir combien d'octets suivent.

[invitedf53f6be]

c'est vrai, c'est même comme ça que je procedais, en RS232 et avec un seul slave.
Mais bon, en RS485 avec deux slave sur la ligne, c'est un peu différent. Même si je t'accorde que en théorie ça dois marcher en comptant les octets, ça ne fonctionnait pas chez moi, des collisions dans tous les sens, ect ... Je l'ai peut-être mal programmé, va savoir...
Toujours est il que Modbus recommande d'utiliser le silence de 3.5 char pour détecter une fin de trame, ce que j'ai fait et maintenant, ça fonctionne parfaitement.
Merci à tous d'avoir fait vivre le sujet !

[polo974]

ce que notre ami voulais dire je pense c'est comment calculer le temps de réception de 3,5 octets (ce qui se fait en 2s quand on a la vitesse de transmission).
Pour répondre au problème, perso à la fin de réception de chaque octet je lance un timer puis, à la réception de l'octet suivant je teste la valeur du timer comme ça, si le timer est arrivé à la valeur correspondante au silence, c'est gagné, on a détecté le silence, sinon je le remet à zéro et ainsi de suite

Tu dis attendre un octet suivant pour tester le timer, et c'est le pb, mais ensuite, tu décris une autre méthode:

ben non c'est pour ça que je voyais pas pourquoi tu disais que ma méthode est foireuse. T'as pas vraiment le choix, t'es bien obligé de lancer ton timer à la fin de réception de chaque octet et dès qu'il arrive à la bonne valeur (tu peux le faire déborder et gérer l'interruption aussi) tu traites ta trame. Sinon, dès qu'un octet arrive tu remet ton timer à 0 et tu le relance à la fin de la réception. Je vois pas ce qu'il ne marche pas là dedans

Ce qui fonctionne, mais oblige à attendre "un certain temps"...

[Jack]

Même si je t'accorde que en théorie ça dois marcher en comptant les octets, ça ne fonctionnait pas chez moi, des collisions dans tous les sens, ect ... Je l'ai peut-être mal programmé, va savoir...

Ca doit être ça car il ne peut pas avoir de collision avec modbus, vu que ce bus est MONO MAITRE. C'est le maitre qui initie une conversation, il ne doit donc y avoir que l'esclave adressé qui peut répondre.

A+