Python et Ethernet/UDP

Python est le langage de prédilection du Raspberry Pi

Modérateurs : Francois, Manfraid

destroyedlolo
Raspinaute
Messages : 1585
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: Python et Ethernet/UDP

Message par destroyedlolo » mar. 4 juil. 2017 20:18

Pinhapple a écrit :Avec cette structure, ça te paraît correct ?
J'aurai fait différemment, mais a partir du moment ou ça marche avec ton cahier des charges et la bande passante dispo (et, a nouveau, il faut que tu vérifie) ...
Pinhapple a écrit :Le fait que ce soit une structure n'ajoute pas d'octet au total de la taille de mes variables ?
Elle envoie le contenu du sizeof(). Mais comme je le disais plus haut, tu rajoute les entetes et le jam ... mais tu ne peux rien y faire d'où ce qui a été dit plus haut.
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Python et Ethernet/UDP

Message par Pinhapple » mer. 5 juil. 2017 09:08

destroyedlolo a écrit :J'aurai fait différemment, mais a partir du moment ou ça marche avec ton cahier des charges et la bande passante dispo (et, a nouveau, il faut que tu vérifie) ...
Ok, donc en partant sur cette structure à base de short, ça me fait du 2 * 4 = 8 octets par structure (sur Arduino, la taille d'un short est de 16 bits = 2 octets), si je ne me trompe pas.

J'ai 2 ko de SRAM où sont créées et manipulées les variables (doc Arduino), donc je pourrais y stocker en théorie 250 de ces structures, sauf que j'utilise déjà un peu de place pour d'autres variables (adresse IP, adresse MAC, port local, etc.) ; admettons que j'en stocke déjà 100 (pour un total de 800 octets donc).

Si je prends deux buffers (tableaux de mes structures, chacun de taille 100 du coup), et que je souhaite remplir l'un pendant que j'envoie l'autre, ça signifie que je dois alterner les envois de tableau tous les 100 bips mesurés, et que j'ai un peu moins de l'équivalent de 100 bips pour envoyer un tableau, soit 0,025 s = 25 ms.

Pour résumer : j'ai 800 octets et des bananes à envoyer en 25 ms => débit de 32 000 octets/s = 32 ko/s.

Voilà pour le raisonnement, est-ce qu'il vous paraît correct ?
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

destroyedlolo
Raspinaute
Messages : 1585
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: Python et Ethernet/UDP

Message par destroyedlolo » mer. 5 juil. 2017 09:55

Y'a juste un truc que tu n'as pas pris en compte : c'est que tu es limité aussi par ton éthernet.
Si tu regarde dans la doc, tu verras que tu ne peux pas transférer la taille que tu veux ...

As-tu pensé à la stratégie pour remplir / transférer tes buffers ?
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Python et Ethernet/UDP

Message par Pinhapple » mer. 5 juil. 2017 10:37

destroyedlolo a écrit :Y'a juste un truc que tu n'as pas pris en compte : c'est que tu es limité aussi par ton éthernet.
Je suis sur du 10/100 Mb/s, à la fois pour le shield Arduino et pour le Raspberry Pi. Pour être plus précis, la doc Arduino indique qu'une DEL "100M" s'allume en présence d'un réseau 100 Mb/s, ce qui est le cas sur ma liaison. Il y a sûrement des choses que j'oublie, mais 100 Mb/s ça me paraît pas mal non ?
destroyedlolo a écrit :Si tu regarde dans la doc, tu verras que tu ne peux pas transférer la taille que tu veux ...
Je parcours la doc Arduino, mais je ne trouve rien... Tu parles d'une limitation due à une fonction de la bibliothèque UDP ? Ou a une limitation du shield ? Ou même de l'Ethernet en général ?
destroyedlolo a écrit :As-tu pensé à la stratégie pour remplir / transférer tes buffers ?
Remplissage du buffer A sur une des interruptions, envoi dès que le buffer A est plein, le buffer B prend le relais avec les mêmes étapes que le A, et on recommence.

Je vais avoir trois interruptions : bip "tour" montant, bip montant, bip descendant. Le bip "tour" montant va me permettre de compter les tours (encore à débattre, car faisable côté RPi comme tu l'as souligné précédemment, à voir si je dois gagner en performances le moment venu) ; le bip montant va me permettre d'incrémenter mon compteur de bips, ainsi qu'à déclencher un timer pour avoir un t0 pour la durée d'impulsion et un tn pour l'écart entre bips ; le bip descendant va me permettre de déclencher un autre timer pour mesurer la durée d'impulsion.

Du coup, je ferais du remplissage de buffer dès que j'aurais les deux valeurs à mesurer, donc dans l'interruption bip descendant, pour avoir la durée du bip écoulé, et son écart par rapport au bip précédent (il y aurait du coup un bip sans bip précédent, mais qui serait dans le "tour incomplet initial" dont j'ai parlé précédemment, donc pas très grave.) ; l'envoi se ferait dans la même interruption dès que mon buffer serait plein. Voilà pour la théorie, c'est ce que j'ai en tête pour l'instant.

Je n'ai finalement que deux valeurs à mesurer, les deux autres ayant été jugées inutiles (d'où mon dernier modèle de structure allégé). Je conserve donc la mesure de largeur d'impulsion de chaque bip, ainsi que l'écart entre les fronts montant de deux bips successifs. Au final, je conserve donc : numéro du tour, numéro du bip, largeur du bip, écart entre deux bips consécutifs.

Il faut aussi que je garde en mémoire vos remarques à propos du SPI qui fait le lien entre l'Arduino et le shield Ethernet. Le SPI est rapide, donc je ne sais pas si ça risque de poser problème, mais il faudra au moins que je l'évoque dans mon rapport.
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

destroyedlolo
Raspinaute
Messages : 1585
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: Python et Ethernet/UDP

Message par destroyedlolo » mer. 5 juil. 2017 11:32

Pinhapple a écrit :Je suis sur du 10/100 Mb/s, à la fois pour le shield Arduino et pour le Raspberry Pi. Pour être plus précis, la doc Arduino indique qu'une DEL "100M" s'allume en présence d'un réseau 100 Mb/s, ce qui est le cas sur ma liaison.
Sauf que j'ai lu qq part (il me semble dans la doc de l'UDP (*)), que le shield limite la taille maxi des données qu'il peut envoyer, ce qui est normal vu les limites de l'arduino. Ne pas oublier de vérifier les limites de chacun des composants.

(*)conditionnel, je ne suis pas sur ce que ce soit celle la. Je n'utilise pas ce genre de shield vu le prix de la chose par rapport a un ESP ou un simple OrangePI-0.
Pinhapple a écrit : l'envoi se ferait dans la même interruption dès que mon buffer serait plein.
Non, non et encore non :P
Comme je le disais précédemment, le code d'une interruptions DOIT ETRE LE PLUS COURT POSSIBLE. Envoyer une trame pas SPI n'a rien de court.
De plus, le transfère va générer lui-même ses propres interruptions qui risque de mettre la grouille dans tes mesures.
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Python et Ethernet/UDP

Message par Pinhapple » mer. 5 juil. 2017 11:47

destroyedlolo a écrit :Comme je le disais précédemment, le code d'une interruptions DOIT ETRE LE PLUS COURT POSSIBLE. Envoyer une trame pas SPI n'a rien de court.
Ça ne me laisse pas beaucoup de choix du coup, je vais devoir déplacer la partie envoi dans le loop(), et m'arranger pour la déclencher dès qu'un buffer est rempli.
destroyedlolo a écrit :De plus, le transfère va générer lui-même ses propres interruptions qui risque de mettre la grouille dans tes mesures.
Ce qui explique peut-être pourquoi je passe de 16 384 bips mesurés sans envoi via UDP à 16 377 bips mesurés dès que j'envoie des valeurs.
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

destroyedlolo
Raspinaute
Messages : 1585
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: Python et Ethernet/UDP

Message par destroyedlolo » mer. 5 juil. 2017 12:02

Pinhapple a écrit :Ça ne me laisse pas beaucoup de choix du coup, je vais devoir déplacer la partie envoi dans le loop(), et m'arranger pour la déclencher dès qu'un buffer est rempli.
Il y a des API qui permettent ce genre de synchro : a voir si elles existent sur Arduino.
Pinhapple a écrit :
destroyedlolo a écrit :De plus, le transfère va générer lui-même ses propres interruptions qui risque de mettre la grouille dans tes mesures.
Ce qui explique peut-être pourquoi je passe de 16 384 bips mesurés sans envoi via UDP à 16 377 bips mesurés dès que j'envoie des valeurs.
Ben j'ai dit depuis le début qu'il restait une épée de Damoclès au niveau des échanges.
Cependant, je pense surtout qu'il y a un pb dans ton code au niveau de ce qui est fait dans les interruptions ou de la quantité de données transférées.
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Python et Ethernet/UDP

Message par Pinhapple » mer. 5 juil. 2017 14:09

destroyedlolo a écrit :Il y a des API qui permettent ce genre de synchro : a voir si elles existent sur Arduino.
Des noms à me donner ? Histoire d'avoir de quoi chercher pour l'Arduino.
destroyedlolo a écrit :Ben j'ai dit depuis le début qu'il restait une épée de Damoclès au niveau des échanges.
Cependant, je pense surtout qu'il y a un pb dans ton code au niveau de ce qui est fait dans les interruptions ou de la quantité de données transférées.
Le test qui me fait perdre ces quelques bips consistait juste à envoyer, avec un print() par contre, le numéro de tour et le nombre de bips, séparés par un tiret, donc autant dire pas grand chose, même pour un print().
En ce qui concerne le code Arduino, est-ce qu'un forum RPi est le meilleur endroit pour le poster ? :D
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

destroyedlolo
Raspinaute
Messages : 1585
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: Python et Ethernet/UDP

Message par destroyedlolo » mer. 5 juil. 2017 14:51

Pinhapple a écrit :Des noms à me donner ? Histoire d'avoir de quoi chercher pour l'Arduino.
J'utilise pas mal evenfd() mais je ne suis pas sur qu'il soit adapté ici. Sinon en passant par un pipe (qui n'existe sans doute pas sur un arduino) ... ou simplement un signal.
Pinhapple a écrit :Le test qui me fait perdre ces quelques bips consistait juste à envoyer, avec un print() par contre, le numéro de tour et le nombre de bips, séparés par un tiret, donc autant dire pas grand chose, même pour un print().
Double conversion et surtout envoie d'une trame UDP ... t'as eu déjà sans doute de la chance que ca marche.
Pinhapple a écrit :En ce qui concerne le code Arduino, est-ce qu'un forum RPi est le meilleur endroit pour le poster ? :D
Ben sans doute tout autant que des pb de filtrages analogiques :P :P :P
Plus sérieusement, un forum arduno apportait sans doute d'autres idées/solution plus en lien avec ce chips.

Mais nous, on veut connaitre le fin mot.
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Python et Ethernet/UDP

Message par Pinhapple » mer. 5 juil. 2017 15:47

destroyedlolo a écrit :J'utilise pas mal evenfd() mais je ne suis pas sur qu'il soit adapté ici. Sinon en passant par un pipe (qui n'existe sans doute pas sur un arduino) ... ou simplement un signal.
Merci !
destroyedlolo a écrit :Double conversion et surtout envoie d'une trame UDP ... t'as eu déjà sans doute de la chance que ca marche.
Double conversion, je comprends le problème, mais pas pour la trame UDP. Au final, il faudra bien que j'en envoie des trames UDP, non ? :?
destroyedlolo a écrit :Ben sans doute tout autant que des pb de filtrages analogiques :P :P :P
Plus sérieusement, un forum arduno apportait sans doute d'autres idées/solution plus en lien avec ce chips.

Mais nous, on veut connaitre le fin mot.
Certes ! :D
Ne t'en fais pas, j'ai dit que de toute manière je tiendrai au jus en fin de stage (début août), voire même après la soutenance (début septembre) pour donner des nouvelles. ;)

Nouveau souci : je suis en train de rédiger un programme Arduino représentant l'état maximum atteint à ce jour (c'est essentiellement une fusion de plusieurs programmes), et je me rends compte que la bibliothèque que j'utilise comme "amélioration" de la fonction micros() (qui pour rappel a une résolution de 4 µs : ses valeurs retournées sont des multiples de 4) a un léger souci dans mon cas : sa fonction get_count() s'utilise soit avec un float (4 octets), soit avec un unsigned long (4 octets également), donc deux octets de plus que les 2 prévus avec un short. Reste la possibilité de convertir, mais dans ce cas il y aura autant de conversions que de valeurs ; dans les deux cas, ce n'est pas folichon pour la rapidité...
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

Répondre

Retourner vers « Python »