Python et Ethernet/UDP

[Pinhapple]

ça c'est à tester.. quitte à bufferiser coté arduino.

A bien y réfléchir, c'est surtout côté Arduino que ça risque d'être déterminant : deux impulsions sont espacées d'environ 125 µs (signal carré symétrique à 4 kHz), donc il faut en théorie que la création du paquet et son envoi prenne moins de 125 µs, de manière à ne pas louper d'impulsions.

Quelle en serait la volumétrie a transférer par seconde ?
Il faut savoir que de part son architecture, la frambroise est loin d'être un foudre de guerre niveau réseau (parce hub USB interne, et s'est encore pire si tu utilise le disque en même temps).
Cependant, il y a quand même de la marge avant de le saturer.

Un nombre entier (le nombre d'impulsions, typiquement 16 384), [nombre d'impulsions mesurées] nombres entiers (durée de chaque impulsion), [nombre d'impulsions mesurées] nombres entiers (durée entre deux impulsions), donc un total d'environ 1 + 16 384 + 16 384 = 32 769 entiers. J'ai fait un sizeof(int) sur mon Arduino, qui me renvoie 2 (confirmé par la doc Arduino), donc 32 769 * 2 = 65 538 octets = 524 304 bits à envoyer ?

Il n'accelèrera pas le transfère. Mais par contre, il pourra t'éviter de perdre des trames.
Des tests sont a faire ... est-ce qu'un broker tournant sur un PI peut suivre ?
Est-ce que les envoies sont en continus ou as-tu des "pause" entre les batches ?

Ça me fait de la matière sur quoi bosser, merci !

[destroyedlolo]

Un nombre entier (le nombre d'impulsions, typiquement 16 384), [nombre d'impulsions mesurées] nombres entiers (durée de chaque impulsion), [nombre d'impulsions mesurées] nombres entiers (durée entre deux impulsions), donc un total d'environ 1 + 16 384 + 16 384 = 32 769 entiers. J'ai fait un sizeof(int) sur mon Arduino, qui me renvoie 2 (confirmé par la doc Arduino), donc 32 769 * 2 = 65 538 octets = 524 304 bits à envoyer ?

Heu, tu ne disais pas que tu ne pouvais transférer que des chaines ? Dans ce cas, un entier ne prend pas 2 octets mais strlen("65538") soit 5 octets.
Donc si je t'ai bien compris, ca fait :
5 + [nbre]*5 + [nbre]*5
donc au pire (16 384 *2 +1)*5 soit 163845 uniquement pour le payload (s'ajoute les enveloppe ethernet + de la mise en forme car j'imagine que tu envoie aussi des espaces de séparation et des CR/LF).
Bref, ce n'est pas si lourd que ca pour de l'éthernet.

[Pinhapple]

Heu, tu ne disais pas que tu ne pouvais transférer que des chaines ?

C'était une question ! Je ne peux transférer que des chaînes ?
Bien vu pour la remarque en tout cas, je me suis fait avoir !

Bref, ce n'est pas si lourd que ca pour de l'éthernet.

A voir si c'est rapide (inférieur à 125 µs) à envoyer avec l'Arduino.

[romaxx]

A bien y réfléchir, c'est surtout côté Arduino que ça risque d'être déterminant : deux impulsions sont espacées d'environ 125 µs (signal carré symétrique à 4 kHz), donc il faut en théorie que la création du paquet et son envoi prenne moins de 125 µs, de manière à ne pas louper d'impulsions.

En fait l'utilisation de l'Ethernet classique "casse" le déterminisme d'une application sur uC, enfin avec python c'est déjà un peu le cas.., ça me rappel les circuits basicstamp, sinon il faut utiliser des libs Ethernet temps réel avec des temps de réponses garantis.

J'avais pas vu que t'étais de Rouen , j'ai fait une partie de mes études là bas, puis école d'ingé ailleurs puis thèse ailleurs...la vie mouvementé de l'étudiant quoi .. où étudie tu ? car la plupart des écoles préfèrent utiliser des uC "français" (STM8, STM32) pour les étudiants, le raspberrypi c'est un SoC.. ça compte moins

[destroyedlolo]

C'était une question ! Je ne peux transférer que des chaînes ?

Oups, le '?' m'avait échappé.
Évidement, il est beaucoup plus rapide de transférer du binaire, il faut juste s'assurer que les 2 procs ordonnent le bits dans le même ordre.

la plupart des écoles préfèrent utiliser des uC "français" (STM8, STM32) pour les étudiants, le raspberrypi c'est un SoC.. ça compte moins

Mon ancien employeur
Malheureusement, il ne reste plus grand chose de Francais la dedans ...

[romaxx]

Mon ancien employeur
Malheureusement, il ne reste plus grand chose de Francais la dedans ...

Il y a pas mal d'usines STMicro en France, donc elles embauchent sur le sol, alors que arduino c'est Atmel.. racheté par Microchip...

[Pinhapple]

En fait l'utilisation de l'Ethernet classique "casse" le déterminisme d'une application sur uC

C'est-à-dire ? Perte de précision ? Du temps réel ? Peux-tu m'en dire plus ?

J'avais pas vu que t'étais de Rouen , j'ai fait une partie de mes études là bas, puis école d'ingé ailleurs puis thèse ailleurs...la vie mouvementé de l'étudiant quoi .. où étudie tu ? car la plupart des écoles préfèrent utiliser des uC "français" (STM8, STM32) pour les étudiants, le raspberrypi c'est un SoC.. ça compte moins

Je suis à l'eXia, l'école d'informatique du groupe CESI ! Je suis en stage de fin d'études là, ça se termine début août !

Évidement, il est beaucoup plus rapide de transférer du binaire, il faut juste s'assurer que les 2 procs ordonnent le bits dans le même ordre.

Si j'ai des tableaux de char côté Arduino, c'est possible de les envoyer et de recevoir le même type de données en Python ? Ou des listes au pire, ça m'irait très bien.

[destroyedlolo]

Si j'ai des tableaux de char côté Arduino, c'est possible de les envoyer et de recevoir le même type de données en Python ? Ou des listes au pire, ça m'irait très bien.

Un

Code : Tout sélectionner

char toto[15]

oui.

Un

Code : Tout sélectionner

char toto[15][20]

non car toto est en fait un tableau de pointeurs de tableau de char et, comme dans le cas d'une liste, ces pointeurs ne veulent rien dire sur la machine distante.

Il faut faire ce qu'on appele "sérialiser", c'est à dire les convertir en qq chose de transférable. Typiquement, ca peut etre de l'XML ou plus efficace, du JSON.
Cependant, si t'es stressé par les perfs, il reste plus efficace de rester en binaire.

[Pinhapple]

Un

Code : Tout sélectionner

char toto[15]

oui.

Un

Code : Tout sélectionner

char toto[15][20]

non car toto est en fait un tableau de pointeurs de tableau de char et, comme dans le cas d'une liste, ces pointeurs ne veulent rien dire sur la machine distante.

Il faut faire ce qu'on appele "sérialiser", c'est à dire les convertir en qq chose de transférable. Typiquement, ca peut etre de l'XML ou plus efficace, du JSON.
Cependant, si t'es stressé par les perfs, il reste plus efficace de rester en binaire.

Ok c'est noté, merci pour l'info !
Au passage, je me suis bien marré avec ton "stressé par les perfs", j'adore la formulation !

[romaxx]

En fait l'utilisation de l'Ethernet classique "casse" le déterminisme d'une application sur uC

C'est-à-dire ? Perte de précision ? Du temps réel ? Peux-tu m'en dire plus ?

J'avais pas vu que t'étais de Rouen , j'ai fait une partie de mes études là bas, puis école d'ingé ailleurs puis thèse ailleurs...la vie mouvementé de l'étudiant quoi .. où étudie tu ? car la plupart des écoles préfèrent utiliser des uC "français" (STM8, STM32) pour les étudiants, le raspberrypi c'est un SoC.. ça compte moins

Je suis à l'eXia, l'école d'informatique du groupe CESI ! Je suis en stage de fin d'études là, ça se termine début août !

ah oui le CESI... l'important c'est d' être passionné

Temps réel = traitements synchrones, c'est par exemple la différence entre un UART et un USART. Si ton périphérique n'a pas répondu au bout d'un temps bien précis, c'est considéré au niveau hardware comme un évènement que tu peux exploiter dans ton programme.
L'arduino est basé sur le W5500 pour l'Ethernet c'est bien ça ? ce composant communique via le bus SPI, qui peut être synchrone (avec CLKM) ou asynchrone, donc il faut voir comment ça a été géré.
T'aurai pu faire un pont USART mais je viens de voir: "The AVR USART has a "synchronous" mode that you can set up in its configuration register (not directly supported by any Arduino firmware.)"
Arduino t'es imposé ?