Python et Ethernet/UDP

[Pinhapple]

Mais on tourne en rond, on va arreter là : l'important est que Pinhapple sache que le pb doit être pris en compte et on a décrit plusieurs méthodes pour y palier.

Oui, j'ai de quoi faire là !

Nouvelle question : est-ce que la communication UDP doit se faire sous la forme "envoi d'un message de requête -> réception et traitement -> envoie d'un message de réponse", ou est-ce que je peux "attraper" ce qui passe dans le câble Ethernet avec mon RPi sans avoir envoyé de requête ?

Pour être plus concret : actuellement, mon RPi envoie, en Python, un message "rq", que l'Arduino reçoit, et envoie en réponse un message "pouet" ; tant que "rq" n'est pas reçu, "pouet" ne part pas. Du coup je me pose la question de savoir si je ne perds pas de temps à envoyer une requête et attendre la réponse, puis recommencer, et si ce n'était pas possible d'émettre "pouet" en continu avec l'Arduino et de lire à la demande avec le RPi.

[destroyedlolo]

C’est clair que je ne saisis pas tout. Je n’arrive pas à comprendre comment on peut être moins couteux en s’affranchissant de milliers de conversions de valeur entière en str par seconde et en réduisant de façon considérable le trafic.

La preuve que tu ne lis pas se qu'écrivent tes interlocuteurs : j'ai abordé le MQTT une fois avec un GROS conditionnel, ca fait un bout de temps qu'on ne parle plus de chaine. Ca pose d'ailleurs des questions sur la compréhension voir de la logique même du propos vu qu'on a aborder la question du boutisme en basculant sur des échanges binaires

La bonne nouvelle c’est que tu as enfin compris comment on pouvait très facilement faire l’abstraction de l’order et des types (il a fallu quand même 2 page d’écriture).

Mais après, ces 2 pages, tu n'as toujours pas compris qu'elle pouvait se faire aussi bien sur du memory mapping, et vu le profile dont tu t'affuble, c'est pour le moins étonnant ... surtout que si je me souviens bien, ca faisait parti d'un cours que j'ai eu y'a bien longtemps à l'IUT, remis sur le tapis les années suivantes (soit dit en passant, les profs de maitrise qui en parlaient étaient chercheurs qui pondaient des sondes pour les accélérateurs du CERN, donc je pense que oui, ils savent de quoi ils parlent).

Il te reste à te documenter ou à réfléchir encore un peu pour comprendre qu’il a parfois de l’intérêt à créer et utiliser une son propre protocole d’échange sans avoir à subir la surcharge et les contraintes d’une couche protocolaire systématiquement normalisée.

Va juste falloir que tu relise les pages précédentes pour te rendre compte qu'on en parle plus depuis déjà quelques postes !
Il va juste falloir que tu comprennes enfin que ca ne sert à rien de sortir la grosse berta pour échanger 3 entiers. Va juste falloir que tu comprennes que quitte a mettre en place son propre protocole d'échange autant qu'il soit le plus léger possible et qu'il supprime toute manipulation inutile ... surtout lorsqu'on parle de chips aux ressources réduites.
Puis temps qu'a parler de documentations, je te laisse voir comment on communique avec un RFXCom, comment fonctionne les échanges mémoire avec un DSP ou une carte graphique, voir même les RFC de pas mal des protocoles qu'on utilisent et qui ont pour certaines plusieurs décennies !

Après, on est capable de comprendre comment ça marche et de faire ou pas, mais ça, c’est une autre histoire.

En effet, ca pose des questions en effet ... comme le fait de sortir des inexactitudes avec un aplomb digne d'un avocat (le coup de éthernet qui garanti le boutisme est juste risible et montre une méconnaissance totale des couches OSI), que tous les échanges finissent invariablement par des insultes et par le manque de concertation/compréhension avec les opposants.

J'ai tenté une nouvelle approche ... mais on reste dans les mêmes travers.
Aller, PLONK !

[destroyedlolo]

Nouvelle question : est-ce que la communication UDP doit se faire sous la forme "envoi d'un message de requête -> réception et traitement -> envoie d'un message de réponse", ou est-ce que je peux "attraper" ce qui passe dans le câble Ethernet avec mon RPi sans avoir envoyé de requête ?

La question est de savoir si tu peux te permettre ou non de perdre des données, et de ce que tu fais si tu en perd.
Car détecter un trou est une chose, pouvoir ré-émettre et en assurer la cohérence en est une autre.

Exemple concret :

• Si tes bips correspondent à la vérification de la vitesse du radar, ce qui devient interessant est de connaitre le nombre de loupés et l'impacte (typiquement, 1 donnée sur 1 tour alors que toutes les autres valeurs sont bien a 120mS, on s'en fout)
• si par contre le bip correspond à un hit radar, c'est évident qu'on ne peut pas en faire abstraction ... mais alors se posera à toi non seulement la question de l'acknowledgement mais aussi le problème du stockage en local et de la ré-émission des données manquantes ... puis de leur incorporation parmi les données qui continuent a etre transmises.

Tien nous au jus

[domi]

SVP Messieurs

Avoir ses idées c'est bien, mais ici nous sommes là pour aider Pinhapple, alors merci a chacun de rester courtois, et de revenir sur le but premier de ce forum

[Pinhapple]

La question est de savoir si tu peux te permettre ou non de perdre des données, et de ce que tu fais si tu en perd.
Car détecter un trou est une chose, pouvoir ré-émettre et en assurer la cohérence en ait une autre.

Je ne peux pas me permettre de perdre des données, c'est dans les fonctionnalités requises : Arduino comme RPi, je dois tout avoir. Ce serait ballot de réussir à tout avoir avec l'Arduino et de perdre des trucs en chemin vers le RPi !

• Si tes bips correspondent à la vérification de la vitesse du radar, ce qui devient interessant et de connaitre le nombre de loupés et l'impacte (typiquement, 1 donnée sur 1 tour alors que toutes les autres valeurs sont bien a 120mS, on s'en fout)
• si par contre le bip correspond à un hit radar, c'est évident qu'on ne peut pas en faire abstraction ... mais alors se posera à toi non seulement la question de l'acknowledgement mais aussi le problème du stockage en local et de la ré-émission des données manquantes ... puis de leur incorporation parmi les données qui continuent a etre transmises.

Les 16 384 bips correspondent aux impulsions radars émises à chaque tour (donc environ 45,5 bips par degré <=> environ 0,022 dégré entre deux bips).

Les problèmes s'accumulent : pour mesurer les durées avec l'Arduino, j'ai le choix entre

• Faire le delta de deux micros(), mais avec une résolution de 4 µs, contrainte du microcontrôleur (les valeurs retournées par micros() sont des multiples de 4)
• Utiliser pulseIn(), fonction prévue pour faire de la mesure de largeur d'impulsion, précise à la microseconde, mais bloquante (donc pas moyen de mesurer signal A et B en pseudo-même temps).

Je vous tiens au jus !

[Bud Spencer]

SVP Messieurs

Avoir ses idées c'est bien, mais ici nous sommes là pour aider Pinhapple, alors merci a chacun de rester courtois, et de revenir sur le but premier de ce forum

C'est ce que j'ai fait depuis le début et pas de raison que ca change
Il y a des gens avec qui on peut parler et d'autres qui ne comprennent rien à rien qui savent tout et qui on toujours raison, c'est comme ca.
Celle la je l'adore : "le coup de éthernet qui garanti le boutisme est juste risible et montre une méconnaissance totale des couches OSI"
Alors que j'ais passé 2 pages d'écriture pour essayer de lui faire comprendre qu'il y avait une différence entre envoyer un long tout cru et envoyer un tableau d'octets formatés arbitrairement. C'est balaise hein ...
Aller moi aussi replonk, mais bien vissé cette fois ci

Nouvelle question : est-ce que la communication UDP doit se faire sous la forme "envoi d'un message de requête -> réception et traitement -> envoie d'un message de réponse", ou est-ce que je peux "attraper" ce qui passe dans le câble Ethernet avec mon RPi sans avoir envoyé de requête ?

Pour être plus concret : actuellement, mon RPi envoie, en Python, un message "rq", que l'Arduino reçoit, et envoie en réponse un message "pouet" ; tant que "rq" n'est pas reçu, "pouet" ne part pas. Du coup je me pose la question de savoir si je ne perds pas de temps à envoyer une requête et attendre la réponse, puis recommencer, et si ce n'était pas possible d'émettre "pouet" en continu avec l'Arduino et de lire à la demande avec le RPi.

Pour te répondre concrètement, oui tu peux tout à fait envoyer tes pouet en continu sur un socket UDP. Pas la peine d’aller chercher d’autres protocoles ou d’extrapoler sur toutes un tas de grandes théories inutiles et complétement à côté du sujet, c’est ce que tu pourras faire de plus rapide en transfert de donnée. En revanche tu n’auras aucune garantie que toutes les données arrivent bien au destinataire et qu’il a pu les traiter. Le fait de demander un acquittement te permet d’aviser pour les requêtes qui n’aurait pas eus de réponse en temps voulu (c’est ce que je t’expliquais pour le timeout). Le problème, c’est que pendant ce temps tu ne peux rien envoyer d’autre sur ton socket puisque qu’il est bloqué en attente d’une réponse.

Perso, je ni connais rien en radar, mais j'imagine que si tu veux récupérer les infos de temps d'impulsion, c'est peut être pour pouvoir retracer (graphiquement ?) le signal enregistré. Je t'ai trouvé ca : http://www.semageek.com/diy-un-analyseu ... n-arduino/
Ca n'est pas le même projet que toi, mais ca pourrait peut être te donner des idées .

[domi]

Bien justement,

Chacun aide avec ses connaissances, personne n'est infaillible, mais ce forum n'est pas fait pour régler ses comptes.
Je me met à la place de Pinhapple qui a posé une question, et qui subit tout cela alors qu'il attend une assistance.
Si cela continu, je me verrai obligé de verrouiller ce sujet, chose que je ne voudrai pas, car le plus frustré et le plus embêté sera notre ami Pinhapple. Alors merci pour lui et pour la bonne entente du forum.

[destroyedlolo]

Bon repassons à des choses plus intéressantes

Les problèmes s'accumulent : pour mesurer les durées avec l'Arduino, j'ai le choix entre

• Faire le delta de deux millis(), mais avec une résolution de 4 µs, contrainte du microcontrôleur (les valeurs retournées par millis() sont des multiples de 4)
• Utiliser pulseIn(), fonction prévue pour faire de la mesure de largeur d'impulsion, précise à la microseconde, mais bloquante (donc pas moyen de mesurer signal A et B en pseudo-même temps).

Je pense qu'a ce stade, il faut remettre les choses à plat et te poser les questions suivantes :

• quel est le but ? Parce que tu nous a bien expliqué que tu mesurais les durées, mais ... quel est le but final de ton projet ? Les impacts s'ils manquent des données ? (j'avoue avoir vite laisser tomber le sujet précédent devant l'étalage de confiture).
• Est-ce que tu as (ou peut) atteindre ton objectif sur le signal de 4khz ?
• Ton signal A arrivant toutes les 4s, est-ce que tu peux être moins précis que le B ?

Ensuite, si tu veux utiliser des acquittements avec tes trames UDP, peut-être devrais-tu passer au TCP qui l'implémente directement dans le protocole ...

[spourre]

(j'avoue avoir vite laisser tomber le sujet précédent devant l'étalage de configure).
...

TROLL ON

J'ai essayé de faire ./confiture mais j'obtiens un "syntax error", est-ce normal ?

TROLL OFF

Sylvain

[destroyedlolo]

Arg, bien vue : excellent
Je corrige ...