Aller au contenu


Photo
- - - - -

Communication Série PI - Arduino

UART Raspberry PI Arduino

  • Veuillez vous connecter pour répondre
7 réponses à ce sujet

#1 Elharion

Elharion

    Membre

  • Membres
  • 66 messages

Posté 28 mars 2018 - 01:33

Bonjour bonjour,

 

Après avoir lu attentivement le topic d'Oliver17 et ayant moi même pour objectif de mettre en place le même type de com, je poste ici pour pas polluer son topic ( http://www.robot-maker.com/forum/topic/11890-gcom-communication-pi-arduino/?p=92084).

 

Je me suis documenté sur l'UART et j'ai des idées que je voudrais partager avant de me lancer dans le code ^^. Ca me permettra aussi de vérifier que j'ai bien compris le principe.

 

Grosso modo les liaisons UART ne sont pas réellement structurées (par opposition à l'i2c par exemple). La ligne est à 1 au repos, quand quelqu'un prends la parole il fait un silence et ensuite transmet un octet.

 

A l'autre bout de la ligne on va donc recevoir un octet qu'on va stocker dans un buffer que le programme va traiter dans un second temps. Le hic c'est qu'on ne sait pas ce que cet octet représente (ni même le type de variable). Dans le cas d'une info sur plusieurs octets on se sait même pas où est la fin de l'information.

 

Ceci dit, l'intérêt de l'UART c'est qu'on en fait ce qu'on veut ( ou presque, l'UART cuira pas ma pizza).

 

Du coup est il imaginable de structurer mes messages de la façon suivante :

 

Octet 1 : integer de 0 à 255 indiquant un type d'information :

 

A la façon d'une ENUM on a une table de correspondance dans le soft, par exemple :

 

001 : commande de déplacement

002 : information du sonar

003 : angle du servo tartampion

 

Octet 2 : Integer de 0 à 255 indiquant le nombre d'octets qui vont suivre...

 

Octet 3 à i : l'information en elle même.

 

Comme ça quand je lis le buffer, je sais ce que je lis. Qu'en pensez vous ?

 

 

 


  • Oliver17 aime ceci

#2 levend

levend

    Pilier du forum

  • Membres
  • PipPipPipPipPip
  • 5 572 messages
  • Gender:Male
  • Location:Vendée
  • Interests:Robotique, informatique, architecture et patrimoine...

Posté 28 mars 2018 - 02:04

C'est un peu comme ça que l'on faisait pour la communication entre les différents appareils sur mon projet de BTS (il y a un bail :D ).

Par contre la seule chose que je peux te dire actuellement c'est que pour ton octet 2, n'utilise pas la valeur jusqu'à 255, il vaut mieux envoyer plusieurs petite message (ou trames) qu'un grand message donc il faudrait peut-être ajouter un octet indiquant le numéro de trame et un autre pour indiquer le nombre total de trames pour avoir le message complet. Ceci-dit quand je regarde ton type d'information (octet 1) les messages ne seront jamais très longs.


Imprimante 3D : Prusa i3 (MK1) + CR-10S + CR-10 S5 + Artillery Sidewinder X2 + CR-30 + Elegoo Mars + Anycubic Wash & cure 2 + Phrozen Sonic Mega 8K + Phrozen Cure Mega

#3 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 934 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 28 mars 2018 - 02:11

Oui c'est très bien résumé =) 

 

Il y a ensuite différentes méthodes utilisée pour : 

"Organiser la trame envoyée"  parser,  trame de taille fixe, indicateur de longueur de trame en début de trame, données en Byte ou "lisible"  ...
"S'assurer de la qualité de la trame" byte de start et de stop checsum
"Utiliser les données envoyées" machine à état, banque de donnée, fonction bloquante et indicateur de disponibilité ...


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#4 Elharion

Elharion

    Membre

  • Membres
  • 66 messages

Posté 28 mars 2018 - 02:22

C'est un peu comme ça que l'on faisait pour la communication entre les différents appareils sur mon projet de BTS (il y a un bail :D ).

Par contre la seule chose que je peux te dire actuellement c'est que pour ton octet 2, n'utilise pas la valeur jusqu'à 255, il vaut mieux envoyer plusieurs petite message (ou trames) qu'un grand message donc il faudrait peut-être ajouter un octet indiquant le numéro de trame et un autre pour indiquer le nombre total de trames pour avoir le message complet. Ceci-dit quand je regarde ton type d'information (octet 1) les messages ne seront jamais très longs.

 

C'est bien noté pour la longueur des messages. Après, a par envoyer un tableau de mesures complet je vois pas ce qui m’emmènerait à 255.

 

 

Oui c'est très bien résumé =) 

 

Il y a ensuite différentes méthodes utilisée pour : 

"Organiser la trame envoyée"  parser,  trame de taille fixe, indicateur de longueur de trame en début de trame, données en Byte ou "lisible"  ...
"S'assurer de la qualité de la trame" byte de start et de stop checsum
"Utiliser les données envoyées" machine à état, banque de donnée, fonction bloquante et indicateur de disponibilité ...

 

Merci =)

 

Pour le byte de stop ce qui m'inquiète c'est que nécessairement une valeur qui peut être dans le message et donc mal interprétée. Sur mon schéma papier il y était mais je l'ai enlevé ^^

 

Je vais jeter un oeil aux pistes que tu me donnes ;)



#5 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 758 messages
  • Gender:Male
  • Interests:Glenn

Posté 28 mars 2018 - 02:39

Cool, je vais suivre ton post, ça m'aidera surement ;)


signature_01.png -->

 

Mon Tipeee
 


#6 Elharion

Elharion

    Membre

  • Membres
  • 66 messages

Posté 28 mars 2018 - 03:09

Cool, je vais suivre ton post, ça m'aidera surement ;)

 

Même si nos projets sont différent on utilise le même matos et on rencontre les même problématiques ^^



#7 R2D21995

R2D21995

    Membre passionné

  • Membres
  • PipPipPip
  • 385 messages

Posté 28 mars 2018 - 03:12

Super merci beaucoup de ton partage. ça va surement beaucoup m'aider


Il faut toujours viser la lune, car même en cas d’échec, on atterrit dans les étoiles


#8 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 758 messages
  • Gender:Male
  • Interests:Glenn

Posté 28 mars 2018 - 03:50

@Elharion : ça me rassure un peu si on rencontre les mêmes problèmes :)
 


signature_01.png -->

 

Mon Tipeee
 






Aussi étiqueté avec au moins un de ces mots-clés : UART, Raspberry PI, Arduino

1 utilisateur(s) li(sen)t ce sujet

0 members, 1 guests, 0 anonymous users