Python et Ethernet/UDP

[spourre]

Arg, bien vue : excellent
Je corrige ...

C'était ma contribution pour remettre un peu de bonne humeur (et d'humour) sur ce fil qui tourne au concours de celui qui aura la plus grosse (byte ?) ou pissera le plus loin

Je n'interviens pas sur le fond car je trouve qu'effectivement on tourne un peu en rond et que reviennent les mêmes interrogations et les mêmes suggestions.

Comme je l'ai déjà indiqué dans d'autres fils, sauf si le choix du Raspberry était imposé et que l'on considère qu'un échec bien analysé et argumenté est formateur, on a bien mis la charrue avant les bœufs. La "bonne" pratique consiste à définir les contraintes du projet puis de choisir une architecture sinon, comme le dit l'adage, quand on a comme seul outil un marteau, tous les problèmes ressemblent à un clou

Toutes les suggestions sur les contraintes du temps réel, du déterminisme, de la latence et du traitement de tous les événements ont déjà été abordés (essentiellement par Bud et moi-même). On a réussi à passer au compilé mais en prévenant que cela ne suffirait certainement pas.
J'ai proposé des approches (et des liens) pour utiliser la bibliothèques bcm qui est plus proche du hard que la wiringpi, les extensions RT de Linux voire le passage au bare métal.

Je garde un œil pour voir si d'autres idées surgissent mais je suis assez pessimiste.

Sylvain

[destroyedlolo]

Salut,

Pour peu que le systeme arrive a suivre et a transférer les info du signal 4khz (ce qui reste à démontrer) et s'il n'y a pas besoin d'une grande précision sur le second signal, il y a peut etre une solution sans remettre en cause l'archie.
Mais on ne connait toujours pas la finalité du truc ... (mais j'ai peut-être loupé qq chose).

Il manque aussi une bonne "gestion projet" : ca part un peu dans tous les sens, ca manque de découpage et c'est a mon avis pour ca que ca cafouille.
C'est pour ca que c'est sans doute le moment de prendre du recule et surtout de se focaliser l'objectif ... (sans non plus donner forcement les solutions : ca reste un "projet scolaire" )

A+

[Pinhapple]

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.

Je pense comprendre : si j'ai une requête, je peux m'assurer d'avoir une réponse ; mais sans requête, je prends ce qui passe, sans aucune garanti d'avoir ce qu'il me faut.

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 .

• 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 ?

Merci pour le lien ! J'aime bien ce blog, il est bourré d'articles intéressants qui donnent souvent de l'inspiration !
L'idée de mon outil serait d'avoir un listing des durées précisées précédemment (longueur d'impulsion et écart entre deux impulsions) afin d'analyser un signal radar, pour permettre de détecter des écarts et de les signaler. Avoir toutes les données est une contrainte imposée par mon maître de stage, et s'explique par le fait d'avoir toutes les données pour être sûr à 100 % de leur fiabilité (S'il me manque une dizaine de valeurs et que des écarts s'y trouvent, c'est problématique).

Je me met à la place de Pinhapple qui a posé une question, et qui subit tout cela alors qu'il attend une assistance.

Pas de souci, ça me fait beaucoup d'informations techniques d'un coup, ce qui me fait de la lecture et du boulot !

[*]Est-ce que tu as (ou peut) atteindre ton objectif sur le signal de 4khz ?

A l'heure actuelle, j'arrive à compter les tours les impulsions grâce aux deux signaux que je lis (après traitement de signaux différentiels). De plus, à l'aide d'une bibliothèque externe, je peux mesurer à la microseconde près la durée d'une impulsion du signal A OU du signal B, mais pas les deux en même temps (fonction bloquante ?). Le tout avec une Arduino Uno ; et j'avais suggéré d'utiliser une Arduino Due suite à une discussion sur un forum (ici ou Arduino, ça m'échappe), afin de tout faire sur l'Arduino, y compris le stockage (éventuellement shield SD) et l'affichage.

[*]Ton signal A arrivant toutes les 4s, est-ce que tu peux être moins précis que le B ?[/list]

C'est-à-dire "moins précis" ? Il faut que je les détecte tous pour savoir que je commence un nouveau tour, et connaître leur durée et les écarts les séparant.

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 ...

Je prouve que c'est chaud avec l'UDP et je tente en TCP !

Comme je l'ai déjà indiqué dans d'autres fils, sauf si le choix du Raspberry était imposé et que l'on considère qu'un échec bien analysé et argumenté est formateur, on a bien mis la charrue avant les bœufs. La "bonne" pratique consiste à définir les contraintes du projet puis de choisir une architecture sinon, comme le dit l'adage, quand on a comme seul outil un marteau, tous les problèmes ressemblent à un clou

Choix du RPi imposé ! Intuitivement, ce n'est pas le support que j'aurais choisi, mais au moins j'ai essayé.

Toutes les suggestions sur les contraintes du temps réel, du déterminisme, de la latence et du traitement de tous les événements ont déjà été abordés (essentiellement par Bud et moi-même). On a réussi à passer au compilé mais en prévenant que cela ne suffirait certainement pas.
J'ai proposé des approches (et des liens) pour utiliser la bibliothèques bcm qui est plus proche du hard que la wiringpi, les extensions RT de Linux voire le passage au bare métal.

Oui, j'ai bien retenu vos interventions sur mes sujets précédents.
L'article que tu m'avais transmis sur le temps réel sur RPi était touffu mais intéressant, et concluait surtout qu'avoir de la précision en dessous de 10 µs sur RPi n'était pas possible, ou en tout cas pas expliqué dans le texte. A partir de là, comment suis-je censé avoir une précision à 1 µs près...
Pour du tout électronique, c'est la voie royale comme tu l'avais dit, mais là on sort de mes compétences pour aborder de la bonne grosse électronique, et je ne suis pas au point là-dessus (qu'on ne m'en veuille pas, je suis dév' de formation ! ).

Il manque aussi une bonne "gestion projet" : ca part un peu dans tous les sens, ca manque de découpage et c'est a mon avis pour ca que ca cafouille.

Je reconnais que je suis parti dans les manipulations sans trop prendre de temps pour lister les possibilités du matériel, les contraintes techniques, etc., mais à ma décharge, j'ai dès le début émis des doutes sur les possibilités qu'a le RPi de traiter un signal "aussi rapide", mais c'est bien de pouvoir le prouver. Si en deux jours j'avais pondu un rapport ayant pour titre "comment le travail qu'on m'a donné ne peut pas fonctionner", je serais peut-être passé pour un mec qui ne veut pas bosser !
Plus sérieusement, j'exagère un peu, mais là j'ai du concret pour dire que ce n'est pas possible avec le matériel actuel et mes compétences. Avec le recul, j'aurais dû plus me renseigner en amont sur ce qu'il est possible et impossible de faire avec le RPi, en tirer les conclusions qui s'imposent, et faire remonter mon travail : si ça passe, tâche suivante ; sinon, mains dans le cambouis et je prouve la même chose en ayant manipulé.

C'est pour ca que c'est sans doute le moment de prendre du recule et surtout de se focaliser l'objectif ... (sans non plus donner forcement les solutions : ca reste un "projet scolaire"

Je vais mettre les choses au propre dans un beau document reprenant tout le travail effectué (et il y en a !), présenter les solutions suggérées et mises en place, conclure, et indiquer quelles solutions on pourrait tenter pour résoudre le problème à l'avenir.

Par curiosité, j'ai mesuré la durée d'envoi de mes paquets UDP depuis l'Arduino : pour envoyer [numéro du tour]-[nombre d'impulsions] (exemple : "1-16384") : environ 560 µs (dont 360 de parsePacket(), et 180 µs de beginPacket(), print(), endPacket()). Pour mes tests sans brancher le RPi, mon Arduino m'indique 16 384 bips par tour ; dès que je branche le RPi avec envoi de requêtes, l'Arduino m'indique 16 377 bips.

C'est pas gagné !

[destroyedlolo]

Yo !

Par curiosité, j'ai mesuré la durée d'envoi de mes paquets UDP depuis l'Arduino : pour envoyer [numéro du tour]-[nombre d'impulsions] (exemple : "1-16384") : environ 560 µs (dont 360 de parsePacket(), et 180 µs de beginPacket(), print(), endPacket()).

Coté PI n'est-ce pas ?
As-tu essayé le buffering comme suggérer ? J'espère aussi que tu envoie des binaires plutot que des chaines comme aussi discuté avant que ca ne parte en boudin.

Si j'ai bien compris, ton système sert à détecter d'éventuels défauts/frictions/cequetuveux dans l’entraînement et le roulement du radar ? J'ai juste ?
Dans ce cas, j'ai du mal à voir l’intérêt de mesurer précisément le bips "tour" qui arrivent tout les 4s. Dans ce cas aussi le nombre de bips sur l'autre signal est fixe par tour n'est-ce pas ?

J'espère aussi que tu as compris qu'avec ta méthode bloquante, tu ne peux mesurer à la fois la durée haute, basse surtout si tu veux les 2 signaux ?

1/ Si par contre, tu es sur que le signal 4s est haut lors du front montant du 4k ou encore haut au front descendant ... tu as une solution.
2/ Si tu as sur ton Arduino des compteurs suffisamment précis ... tu as une solution.

3/ reste la communication : le buffering pourrait améliorer les choses, et si ca ne passe pas, tu peux encore améliorer ton datamodel. Mais ca reste le point dur et même si tu optimises, il reste un risque lié à la façon dont fonctionne l'éthernet de l'Arduino.

Je te laisse approfondir ...

[Pinhapple]

Coté PI n'est-ce pas ?

Non, côté Arduino. Je fais la différence de deux micros(), un de chaque côté du code à mesurer.

As-tu essayé le buffering comme suggérer ? J'espère aussi que tu envoie des binaires plutot que des chaines comme aussi discuté avant que ca ne parte en boudin.

Non, faute de multi-threading. Je peux remplir un tableau avec mes valeurs du tour en cours puis envoyer le tout, mais alors là c'est bien plus de 560 µs qui seront nécessaires.
Là pour mon test, j'envoie juste deux int séparés par un char (print(numTour); print('-'); print(nbrBips);). Pour envoyer du binaire, je caste en byte mes valeurs à envoyer ? Je viens d'essayer avec des casts : ça prend plus de temps que si j'envoie les int bruts.

Si j'ai bien compris, ton système sert à détecter d'éventuels défauts/frictions/cequetuveux dans l’entraînement et le roulement du radar ? J'ai juste ?
Dans ce cas, j'ai du mal à voir l’intérêt de mesurer précisément le bips "tour" qui arrivent tout les 4s. Dans ce cas aussi le nombre de bips sur l'autre signal est fixe par tour n'est-ce pas ?

Il sert à détecter des écarts significatifs entre ce qui est attendu et la réalité, qui peuvent en effet être dus à des défauts, frictions, cequejeveux.
Le nombre de bips par tour est supposé fixe, mais là aussi l'outil doit permettre de détecter des écarts. Mesurer le bip "tour" me permet de savoir qu'une nouveau tour commence, donc qu'en théorie 16 384 bips vont suivre. Si ce n'est pas le cas : boum, écart détecté.

J'espère aussi que tu as compris qu'avec ta méthode bloquante, tu ne peux mesurer à la fois la durée haute, basse surtout si tu veux les 2 signaux ?

Oui, même avec des interruptions qui se gèrent "toutes seules", je me doute bien que je suis limité, d'autant plus que le bip "tour" survient en même temps que le bip 0 de l'autre signal.

1/ Si par contre, tu es sur que le signal 4s est haut lors du front montant du 4k ou encore haut au front descendant ... tu as une solution.
2/ Si tu as sur ton Arduino des compteurs suffisamment précis ... tu as une solution.
3/ reste la communication : le buffering pourrait améliorer les choses, et si ca ne passe pas, tu peux encore améliorer ton datamodel. Mais ca reste le point dur et même si tu optimises, il reste un risque lié à la façon dont fonctionne l'éthernet de l'Arduino.

Je ne peux faire tout ce que je veux côté Arduino : séparément oui, mais tout dans le même programme non, ou alors avec des contraintes. A partir de là, si je rajoute encore des contraintes en ajoutant un RPi... Autant obtenir ce que je peux avoir de mieux sur l'Arduino, et je verrai ensuite pour tout envoyer.

Je vais faire de la doc là, histoire de résumer tout ce projet !

[destroyedlolo]

Coté PI n'est-ce pas ?

Non, côté Arduino. Je fais la différence de deux micros(), un de chaque côté du code à mesurer.
Là pour mon test, j'envoie juste deux int séparés par un char (print(numTour); print('-'); print(nbrBips);). Pour envoyer du binaire, je caste en byte mes valeurs à envoyer ? Je viens d'essayer avec des casts : ça prend plus de temps que si j'envoie les int bruts.

Tu n'envoie donc pas du binaire mais une chaine.
La solution est d'utiliser write() sur des structures binaires comme je l'indiquais précédement : tu n'as pas plus rapide.
Inserer un '-' ne sert à rien si ce n'est perdre du temps.

As-tu essayé le buffering comme suggérer ?

Non, faute de multi-threading. Je peux remplir un tableau avec mes valeurs du tour en cours puis envoyer le tout, mais alors là c'est bien plus de 560 µs qui seront nécessaires.

Tu n'as pas besoin de multi-threading si tu as une gestion correcte et intelligente des interruptions, et la seule chose qui t'importe alors est d'envoyer un buffer plus rapidement que l'autre ne se rempli.

J'espère aussi que tu as compris qu'avec ta méthode bloquante, tu ne peux mesurer à la fois la durée haute, basse surtout si tu veux les 2 signaux ?

Oui, même avec des interruptions qui se gèrent "toutes seules", je me doute bien que je suis limité, d'autant plus que le bip "tour" survient en même temps que le bip 0 de l'autre signal.

Et non
Si tu mesure à la fois les durées basses et hautes avec ta fonction bloquante pulseIn() ... quand va-tu trouver le temps d'envoyer les données ?
Avec des interruptions, tu devrais pouvoir mesurer la 2 durées tout en ayant (peut-être) le temps d'envoyer les données.
(tips du jour : une fonction bloquante n'a rien à faire dans une interruption).

1/ Si par contre, tu es sur que le signal 4s est haut lors du front montant du 4k ou encore haut au front descendant ... tu as une solution.
2/ Si tu as sur ton Arduino des compteurs suffisamment précis ... tu as une solution.

Je ne peux faire tout ce que je veux côté Arduino : séparément oui, mais tout dans le même programme non, ou alors avec des contraintes.

Je pense (avis perso donc, rien de péremptoire) que c'est là qu'est ton probleme : dans le "tout dans le même programme"
Il ne faut pas le prendre mal (car l'école est fait pour ... apprendre ), mais tu es passé à côté de ce qu'est une interruption et surtout de tout le potentiel qu'elles ont.
Avec un chips qui rempli le point 2 ci-dessus, et qui est suffisamment rapide pour faire un peu de manipulation mémoire pendant les 8khz qui sépare 2 changements d'état (mais bon, un simple 68000 le faisait alors ...), ce qu'on te demande est réalisable ... et encore plus si le point 1 est aussi rempli.

Comme je le disais, le seule point dur est au niveau de la com. Ethernet / fast serial / ... a toi de calculer les timings pour voir ce qui passe. Si l'Ethernet est la solution, la seule épée de Damoclès se situe au niveau de la conception de l'adaptateur.

[Pinhapple]

Tu n'envoie donc pas du binaire mais une chaine.
La solution est d'utiliser write() sur des structures binaires comme je l'indiquais précédement : tu n'as pas plus rapide.

Qu'appelles-tu "structure binaire" alors ? Je crois que je m'embrouille, entre les structures du C et les binaires du style 0b01010101.

Inserer un '-' ne sert à rien si ce n'est perdre du temps.

Le séparateur qui me permettrait de faire la différence entre "116384" et "1-16384".

Tu n'as pas besoin de multi-threading si tu as une gestion correcte et intelligente des interruptions, et la seule chose qui t'importe alors est d'envoyer un buffer plus rapidement que l'autre ne se rempli.

Je vais essayer ça, mais vu comme ça prend trois plombes d'envoyer un truc léger actuellement, j'imagine même pas ce que ça donnera quand le buffer sera plein... A voir ce que ça donne avec tes "structures binaires" !

Et non
Si tu mesure à la fois les durées basses et hautes avec ta fonction bloquante pulseIn() ... quand va-tu trouver le temps d'envoyer les données ?
Avec des interruptions, tu devrais pouvoir mesurer la 2 durées tout en ayant (peut-être) le temps d'envoyer les données.
(tips du jour : une fonction bloquante n'a rien à faire dans une interruption).

Qu'appelles-tu "durées basses et hautes" ? Je fais mes mesures non-bloquantes entre deux fronts montants et entre un front montant et un front descendant, donc j'imaginais envoyer les données entre le front descendant du dernier bip du tour n et le front descendant du premier bip "nouveau tour" du tour n+1.
Ça tombe bien pour le tip, je n'ai rien de bloquant des mes interruptions ! (j'ai déjà essayé et c'était le boxon, donc j'ai retenu la leçon.)

Je pense (avis perso donc, rien de péremptoire) que c'est là qu'est ton probleme : dans le "tout dans le même programme"
Il ne faut pas le prendre mal (car l'école est fait pour ... apprendre ), mais tu es passé à côté de ce qu'est une interruption et surtout de tout le potentiel qu'elles ont.
Avec un chips qui rempli le point 2 ci-dessus, et qui est suffisamment rapide pour faire un peu de manipulation mémoire pendant les 8khz qui sépare 2 changements d'état (mais bon, un simple 68000 le faisait alors ...), ce qu'on te demande est réalisable ... et encore plus si le point 1 est aussi rempli.

Je ne le prends pas mal, t'en fais pas ! J'ai découvert les interruptions pendant ce projet de stage, on n'a jamais vu ça en cours, et ce n'était pas le but (pas "d'embarqué" au programme autre que d'un peu d'Arduino). Je fais de l'Arduino et du RPi chez moi, pour le plaisir et la bidouille, sans jamais avoir eu à utiliser d'interruptions. Je suis là pour apprendre aussi !

[Bud Spencer]

Là pour mon test, j'envoie juste deux int séparés par un char (print(numTour); print('-'); print(nbrBips);). Pour envoyer du binaire, je caste en byte mes valeurs à envoyer ? Je viens d'essayer avec des casts : ça prend plus de temps que si j'envoie les int bruts.

Parce que tu n’as pas lu ce que je t’avais écrit. Il ne faut pas faire un cast de tes données. Il faut dimensionner un tableau du type attendu, pousser les valeurs décomposées en bonne place dedans dès l’acquisition de chacune et ensuite le transférer (au moment le plus opportun que tu trouveras). Tu n’as pas besoin de mettre de séparateur puisque que tu connais précisément la taille de ton tableau et sa composition. c'est ce qui va te permettre de recomposer tes valeurs à l'arrivée.

Ref doc arduino :
UDP.write(buffer,size) ;
Buffer : an array to send as series of bytes (byte or char)
Size the lenght of the buffer.

Ton tableau est le buffer et la taille de ton tableau est la valeur de size.

[Pinhapple]

Parce que tu n’as pas lu ce que je t’avais écrit. Il ne faut pas faire un cast de tes données. Il faut dimensionner un tableau du type attendu, pousser les valeurs décomposées en bonne place dedans dès l’acquisition de chacune et ensuite le transférer (au moment le plus opportun que tu trouveras). Tu n’as pas besoin de mettre de séparateur puisque que tu connais précisément la taille de ton tableau et sa composition. c'est ce qui va te permettre de recomposer tes valeurs à l'arrivée.

Ref doc arduino :
UDP.write(buffer,size) ;
Buffer : an array to send as series of bytes (byte or char)
Size the lenght of the buffer.

Ton tableau est le buffer et la taille de ton tableau est la valeur de size.

Habile. J'avais pas compris ça comme ça.

[destroyedlolo]

Qu'appelles-tu "structure binaire" alors ? Je crois que je m'embrouille, entre les structures du C et les binaires du style 0b01010101.

Si tu envoie le nombre 125, ton print() va envoyer '1' puis '2' puis '5' donc 3 octets pour tes données : c'est donc une chaine de caractères.
Le write() envoie directement le nombre telle que le stock le microP, à savoir le chiffre 125 qui lui peut etre codé sur 1 octets : un nombre binaire.

A ce sujet, le caractère 'A', les valeurs 65, 0x41 ou 0b1000001 sont ... la même chose ! (heu, ca par contre devrait faire parti des cours).

La "discussion" qui a eu lieu précédemment est pour le cas où la valeur nécessite plus d'1 octet : dans ce cas, l'ordre des octets qui permettent de stocker l''entier peut changer d'un proc à l'autre. Le dialogue de sourd précédent tournait autour de cette problematique.

Tu n'as pas besoin de multi-threading si tu as une gestion correcte et intelligente des interruptions, et la seule chose qui t'importe alors est d'envoyer un buffer plus rapidement que l'autre ne se rempli.

Je vais essayer ça, mais vu comme ça prend trois plombes d'envoyer un truc léger actuellement, j'imagine même pas ce que ça donnera quand le buffer sera plein... A voir ce que ça donne avec tes "structures binaires" !

Sauf que :

• les trames sur ethernet ont une longueur minimum largement plus grande que tes quelques octets. Donc même si tu penses envoyer 5 octets, t'en envoie beaucoup plus (jam + padding) ... cherche "trame ethernet" ou MTU.
• se rajoute les entetes qui prennent aussi de la place.

Les buffers te permettent de mutualiser ces "surcharges".
Bref, ton problème de bande passante est justement que tu n'envoie que des petits bouts

Qu'appelles-tu "durées basses et hautes" ? Je fais mes mesures non-bloquantes entre deux fronts montants et entre un front montant et un front descendant, donc j'imaginais envoyer les données entre le front descendant du dernier bip du tour n et le front descendant du premier bip "nouveau tour" du tour n+1.

Donc, l'un dans l'autre ca revient au meme : tu mesure la durée totale du cycle et la durée pendant qu'il est a l'état haut.

Je ne le prends pas mal, t'en fais pas ! J'ai découvert les interruptions pendant ce projet de stage, on n'a jamais vu ça en cours, et ce n'était pas le but (pas "d'embarqué" au programme autre que d'un peu d'Arduino). Je fais de l'Arduino et du RPi chez moi, pour le plaisir et la bidouille, sans jamais avoir eu à utiliser d'interruptions. Je suis là pour apprendre aussi !

Ha ???? Heu, peut être que t'on prof s'attendait à ce que tu te renseigne pas toi même alors, parce que si on souhaite faire de l'acquisition de signal comme dans ton projet, les techniques bas niveau sont quand même le B.A.-BA ...
Parce qu'il est évident que ca peut marcher (avec beaucoup de difficultés) en faisant du busy waiting mais bon ... c'est gaspiller les ressources pour rien et ca fait très amateur.