ABCelectronique : portail d'information dans le domaine de l'électronique

Merci de ne pas poster des messages en relation avec le piratage.


    Forums de Abcelectronique > Electronique Analogique et Numérique
  » Transmission trame de 16 octets sur 1 fil
Identifiant Se souvenir de moi ?
Mot de passe
Répondre     Nouvelle discussion
Transmission trame de 16 octets sur 1 fil

 

picman123
picman123 ★★★☆☆☆☆ 05/07/2017, 07h59 #1  
Bonjour,

Sur un contrôleur, sans utiliser de périphérique, quel type de protocole pus-je utiliser pour avoir une transmission la plus optimale possible pour envoyer en permanence des trames de 16 octets (je veux faire un sérialiseur/désérialiseur 128bits). Je cherche à faire une transmission unidirectionnelle avec des I/O type TTL.
L’émetteur et le récepteur ne sont pas forcément allumés en même temps et il peut y avoir une séquence de synchronisation.
Je pensais faire un codage Manchester avec une séquence de start mais ça veut donc dire que pour une trame de 16 octets je dois envoyer un peu plus de 32 octets de données : n'existe t-il pas une méthode plus optimisée ?

Merci d'avance
aurelienr
aurelienr ★★★★★★ 05/07/2017, 08h28 #2  
Posté par picman123

avoir une transmission la plus optimale possible pour envoyer en permanence des trames de 16 octets


Ca veut dire quoi optimal ? Quel débit ?
Quelles contraintes sur le stream, doit il être continu ou bien les paquets de 16 peuvent ils être légerement espacés ?

Posté par picman123

Je pensais faire un codage Manchester avec une séquence de start mais ça veut donc dire que pour une trame de 16 octets je dois envoyer un peu plus de 32 octets de données


Tu fais une synchro de taille fixe à l'instar d'un bit de start d'un UART, suivi d'un codage manchester pour tes données.
La considération 16/32 octets n'a pas de sens.

Aurélien
dspix
dspix ★★★★★★★ 05/07/2017, 08h28 #3  
Salut,

voir le protocole 1-wire de dallas. Le codage est basé sur la durée des niveau haut et bas. C'est facile a implémenter en soft. Mais il faut u µC des 2 cotés.
__________________
A+
Damien
aurelienr
aurelienr ★★★★★★ 05/07/2017, 09h13 #4  
Il ne veut pas de module spécial, sinon un UART fait le job !
guy92
guy92 ★★★★★★ 05/07/2017, 11h23 #5  
Il manque tout le contexte pour donner une réponse censée.
A quel débit? A 50bits/s ce ne sera pas les mêmes soucis qu'a 10Mbits/s
Sur quelle distance?
Combien de trames a la seconde?

Faire une liaison asynchrone avec une longueur de trame de 128 bits demande une précision minimum sur la différence de fréquence des horloges (émission et réception) de (1/128*4 ) c'est faisable mais cela dépends beaucoup de la vitesse et de la longueur et type de câble qui vont introduire une gigue de phase et des soucis avec les temps de propagation. pourquoi vouloir faire des trames aussi longues?
Quel besoin au niveau du taux d'erreur? Vu que c'est de l'unidirectionnel pas de correction d'erreur possible
__________________
More the knowledge lesser the Ego, lesser the knowledge, more the Ego
atlantus
atlantus ★★★☆☆☆☆ 05/07/2017, 11h39 #6  
Posté par guy92

Faire une liaison asynchrone avec une longueur de trame de 128 bits demande une précision minimum sur la différence de fréquence des horloges (émission et réception) de (1/128*4 )



C'est effectivement un problème important à prendre en compte.

A noter que pour s'affranchir de ce problème de précision des horloges, il est possible de s'inspirer de la méthode "bit-stuffing" utilisée sur du bus CAN, ce qui permet de resynchroniser le récepteur en cours de trame.

Pour le reste, je rejoins ce qui a déjà été dit : il manque beaucoup d'informations pour pouvoir répondre
guy92
guy92 ★★★★★★ 05/07/2017, 11h47 #7  
Posté par atlantus

C'est effectivement un problème important à prendre en compte.

A noter que pour s'affranchir de ce problème de précision des horloges, il est possible de s'inspirer de la méthode "bit-stuffing" utilisée sur du bus CAN, ce qui permet de resynchroniser le récepteur en cours de trame.

Pour le reste, je rejoins ce qui a déjà été dit : il manque beaucoup d'informations pour pouvoir répondre




Bonjour Atlantus
Tu dis: "C'est effectivement un problème important à prendre en compte."
Et c'est pas le seul...

Depuis que l'on fait des protocoles et des échanges entre systèmes, il me semble qu'il y a déjà suffisamment de solutions standards parfaitement fonctionnelles sans avoir besoin de ré-inventera la roue.

Sans rien connaitre du contexte, j'admire ceux qui proposent des solutions...
__________________
More the knowledge lesser the Ego, lesser the knowledge, more the Ego
aurelienr
aurelienr ★★★★★★ 05/07/2017, 12h37 #8  
Posté par guy92

Sans rien connaitre du contexte, j'admire ceux qui proposent des solutions...


Il part d'un contrôleur mais ne veut pas utiliser de périphériques, donc il envoie des trames en soft.
Ma proposition par exemple permet de résoudre le pb de synchro et de s'adapter à différentes couches physiques (notamment radios). S'il veut de la distance, il passe le tout en RS422..tu peux monter à plus d'1Mbps sans souci..mais peu probable qu'il veuille aller si haut s'il veut tout faire en soft. Apres, avec un peu de logique associée, il peut monter plus haut et cadencer un peu le tout avec son micro.

Aurélien
picman123
picman123 ★★★☆☆☆☆ 05/07/2017, 17h20 #9  
Rebonjour,

Effectivement, il manquait des précisions... et en plus je viens de me rendre compte que je me suis trompé sur la description : je n'ai pas un fil mais deux et la distance est très courte (sur le même PCB).
J'ai 128 entrées que je veux déporter via une liaison 2 fils : un ligne pour l'horloge et une ligne pour la data unidirectionnelle.
Le système est donc synchrone et je veux que le taux de rafraichissement soit le plus court possible
DAUDET78
DAUDET78 ★★★★★★★ 05/07/2017, 18h06 #10  
Posté par guy92

Faire une liaison asynchrone avec une longueur de trame de 128 bits demande une précision minimum sur la différence de fréquence des horloges (émission et réception) de (1/128*4 )

C'est inexact ! le calcul de l'erreur de fréquence admissible est indépendant de la longueur de la trame transmise.

Avec une transmission asynchrone, la synchronisation se refait après chaque octet transmis (soit 11 bits réels)
Donc il faut que l'échantillonnage du bit stop tombe après son début et avant sa fin
A l'émission, le bit stop est produit au bout d'un temps Tse compris entre 10*Te et 11*Te
A la réception, le bit stop est testé au milieu du onzième bit donc au bout d'un temps Tsr donc à 10,5*Tr

Il faut donc que 10,5*Tr soit dans la fourchette 10*Te et 11*Te

Donc l'erreur de fréquence max admissible théorique, entre émission et réception, est de 4,76% (avec driver/receiver/câble parfait)
__________________
L'age n'est pas un handicap .... Encore faut-il arriver jusque là!

Dernière modification par DAUDET78 05/07/2017 à 18h11.
maî
maî ★★★★★☆☆ 05/07/2017, 18h39 #11  
bonjour

pourquoi le pas utiliser Horloge pour faire le Top depart
arrêt horloge a zero et reste a zero tant que ..
envoie de données front haut de H détecter sur pin H de la réception (peu faire une int cote réception par exemple)

et c'est parti, envoie des (16 datas)*128 au rythme de H puis arrêt de H apres 2018 coup de H la bien sur aucun contrôle sur les données reçu

le plus dur dans ton probleme c'est de lui dire j'ai une trame a envoyer

A+
__________________
le souffle du vent passe ...........
tontonchristobal
tontonchristobal ★★★★★☆☆ 05/07/2017, 21h20 #12  
Bonsoir PICMAN
Comme dit par les collègues, sans connaitre tes contraintes on peut uniquement te proposer des idées. Regarde ce que tu peux faire avec le bus LIN, c'est une liaison "one wire" utilisée en automobile (gestion des portières rétroviseurs, lève vitre etc...).
__________________
La seule certitude que j’ai, c’est d’être dans le doute. (Pierre DESPROGES)
dspix
dspix ★★★★★★★ 06/07/2017, 13h24 #13  
Salut; Si ça reste sur le même pcb et que tu as 2 fils en unidirectionnel, tu peux faire du SPI. Le plus compliqué dans l'affaire, c'est de savoir ce qu'il doit être brancher de chaque coté... Si tu ne veux pas "d'intelligence déporté" alors tu cascades des registres à décalage...

Mais bon, y'a quand même des composants dédié spour ça... des I/O expander en i2C... voir le célèbre pcf8574 en version 8 bits.
__________________
A+
Damien
stef.web
stef.web ☆☆☆☆☆☆ 08/07/2017, 23h42 #14  
Comme ça tu ne réinvente pas la roue, déjà utilisé et ça fonctionne très bien même dans un environnement bruité.

http://www.pjon.org/
jarek
jarek ★★★★★☆☆ 10/07/2017, 09h52 #15  
Posté par stef.web

Comme ça tu ne réinvente pas la roue, déjà utilisé et ça fonctionne très bien même dans un environnement bruité.

http://www.pjon.org/


Un réseau avec arduino pour une liaison unidirectionnelle ?
__________________
Sauf erreur ou omission . . .
picman123
picman123 ★★★☆☆☆☆ 10/07/2017, 14h55 #16  
Posté par dspix

Salut; Si ça reste sur le même pcb et que tu as 2 fils en unidirectionnel, tu peux faire du SPI.


Pour le SPI, il ne faut pas 3 fils (4 si bidi) ?
- CLK
- SDI
- SDO
- SS
=> car sans ligne SS, comment on fait pour détecter le premier octet ?

Je pense que je vais partir sur une liaison de type LIN
Répondre