Python et Ethernet/UDP

[romaxx]

Avec le DMA pas besoin de thread.. ni d'interruption..c'est justement le but de décharger le proc.
ton maitre de stage a quelles qualifs ?

[Bud Spencer]

Un simple

Code : Tout sélectionner

unsigned long int toto = 0xaabbccdd;
write(fd, &toto, sizeof(toto);

ne donnera pas le même résultat si l'un est écrit par un gros-boutiste (68000, Spark, ...) et lu sur un petit-boutiste (x86) ou l'inverse car l'octet de poids fort ne se trouve pas au même endroit.

Tout à fait vrai, mais tu n’as rien compris ou pas tout lu. D'ailleurs en parlant de lecture fiable, tu aurais du me reprendre. J'avais malencontreusement écrit 'L'ordre des bits' alors que j'aurais dut écrire 'l'ordre des bytes' . Heureusement que tu m'a cité, sinon je le l'aurais même pas vu. J'ai donc corrigé mais ca ne change rien au raisonnement.

Petit rappel pour ceux qui se mélangent les pinceaux ou qui comme moi tape un peu trop vite : 1 byte = 1 octet = 8 bits

Explication du pourquoi on s'en fout de la taille de l'indien:
Quand on découpes une variable codée sur plusieurs octets pour construire un tableau de bytes, on décide arbitrairement de la position de chaque byte dans le tableau. Apres que le system qui envoi soient little ou big endian, on s'en fout puisque tous les protocoles /ip sont fort heureusement normalisé (big-endian) et c’est le processus IP propre au destinataire qui a la charge de mettre les bytes dans le bon ordre pour sa propre interprétation. C’est exactement ce qui se passe quand on envoies une chaine de caractères sur un socket /IP. On ne peux le faire qu’en précisant le type d’encodage et si celui-ci est codé sur plusieurs octets (genre utf32), c'est justement l'encodage qui va construire un tableau de bytes ordonnée obligatoirement big-endian. A destination, Les bytes sont remis dans le bon ordre toujours par le processus IP du destinataire et la reconvention en caractère est faite en précisant localement l’encodage (qui doit être du même type qu'a l'envois sinon ca fait des gribouillis dans le texte ). Dans notre cas, il n’existe pas (ou pas encore …) d’encodage PinHapple16 ou PinHapple32, donc on ordonnes suivant … notre humeur du moment ou nos habitudes et la seul chose qui importe, c'est que l'on décode de la même façon. C'est comme cela que ca fonctionne et c'est justement ce qui permet à n'importe quel système de dialoguer /IP avec n'importe quel autre sans avoir a se soucier de tout ca.

Seuls les int8_t, int16_t, int32_t sont normalisés (mais pas forcement supporté par les anciens compilos) : int, long int, ... dépendent de l'archi spécialement dans l'embarqué.

Qui t’as parlé de compiler quelques chose. On ne parle pas de compilation mais de transmission de données UDP/IP entre un client python ARM et un serveur C konsefoutdecekecest (Relire le titre du sujet). Tu n’envoies pas des Int signés ou pas, codés sur 8,16 ou 32 bits ou je ne sais quoi d’autre, tu n’envois que des tableaux de bytes que tu as toi-même ordonné au moment de la construction. A réception, quel que soit le système, tu auras EXACTEMENT le même tableau de bytes. Suffit ensuite de réattribuer en bonne place suivant les types utilisés localement (qui ont toutes les chances d’être complétement diffèrent que ceux utilisés avant la construction du tableau). Je persiste donc à dire que dans le cas qui nous intéresse, les types on s'en fout royalement. L'important, c'est que les valeurs des types finaux soient conforme aux valeurs des types initiaux et si ca chante le développeur d'aller loger une valeur qui était au départ un int16 dans un word, un long ou un int32, ca marchera tout pareil pour peut qu'il fasse attention à la signature.

Si il y a des choses que tu ne comprends pas, n'hésite pas a demander.

Pour en revenir au sujet :
Juste une question parce que ca me taraude quand même : Tu comptes faire quoi à l'arrivé des données sur ton PI ? Même si j'ai dit qu'on s'en foutait pour l'instant, ca peut quand même avoir de l'incidence sur la méthode d'envoi a choisir.

PS HS : J'étais un peu en rade d'idée pour aller mettre une nouvelle leçon sur le tuto des app. web dynamiqueviewtopic.php?f=44&t=3033/ mais tout ca m'a éclairé. Dès que j'ai le temps, je vais coder un petit client UDP. Ca devrait être instructif pour beaucoup et ca pourra faire la base d'un bon petit outils d'analyse

après recherches, on parle de durée de l'ordre de la milliseconde pour l'écriture, même avec une "bonne" carte...

Nouveau problème. Comment enregistrer des données plus vite qu'on ne les reçois sur un système qui reçoit plus vite qu'il ne les enregistres ?
Décidément, T'as pas choisi un projet facile

[destroyedlolo]

Un peu de révision des bases semble nécessaire: ce que tu tente d'expliquer est vrai lorsque tu utilises un protocole "formaté" tel que le SNMP ou pour les entêtes des trames ethernet ou des protocoles au dessus.
Sauf que quand tu fais un write () comme dans mon message précédent, ton payload contient des données brutes telles qu'elles étaient présente en mémoire, donc opaques et la couche Ip n'a strictement aucun moyen de savoir ce qu'elle transporte (et à vrai dire, c'est ce qu'on lui demande, d'être agnostique) et ne fait donc aucune conversion.
C'est au "récepteur" de convertir ce champ de bytes brutes en en données structurées, et ce, quel que soit le langage utilisé.

Je suis désolé de devoir sortir de telles évidences, mais si elles t’échappent encore, fait sur des sockets un

Code : Tout sélectionner

unsigned long int toto = 0xaabbccdd;
write(fd, &toto, sizeof(toto));

Sur un Amiga ou un Sparc
Puis, a l'autre bout, un

Code : Tout sélectionner

unsigned long int toto;
read(fd, &toto, sizeof(toto));
printf("%lu\n", toto);

sur un PC ou un VAX et tu verras que ce n'est pas le même résultat.
Et comme les ARM supportent à la fois les big et les littles endiant, un test initial est nécessaire pour s'assurer que l'arduino et le PI vont se comprendre.

Dans le cas contraire, la solution est soit de recoder les données à un moment ou un autre (a nouveau, la couche IP ne le fera pas), soit de passer en chaine de caractères mais tu perd du temps et de la place, soit de passer par des protocoles de plus haut niveau typés.

Et non, ca ne concerne pas que le C car certains les langages interprétés dépendent de la manière dont ils ont été compilés : des langage comme Lua peuvent avoir des formats différents pour les nombres suivant qu'on privilégie la vitesse ou la précision (je ne sais pas si c'est le cas de Python, ne l'utilisant pas car il trop obèse et lent pour ce que je fais).

Envoyé de mon E2303 en utilisant Tapatalk

[Bud Spencer]

.. la solution est soit de recoder les données à un moment ou un autre (a nouveau, la couche IP ne le fera pas), soit de passer en chaine de caractères mais tu perd du temps et de la place, soit de passer par des protocoles de plus haut niveau typés.

C’est ce que je m’efforce d’expliquer mais tu u persiste à vouloir envoyer des types composés pour récupérer les même à l’autre bout donc forcément tu ne t’en sortiras jamais.

Exemple de valeurs maxi : 16384, 125,250 stocké dans des types non signé composé de 4 bytes (pour des besoins quelconques). Total 12 bytes
Décomposes tout ça en bytes et place uniquement les bytes nécessaires au valeurs maxi dans un tableau de bytes en définissant arbitrairement la positions de chacun (quel que soit le system, c’est toi qui décide ou sont placé les octets fort et faible des valeurs composées). Total 4 bytes
A la réception tu recois un tableau de 4 bytes et tu disposes d’un type u de 2 bytes pour ta valeur 16384 et de deux type u de 1 byte pour les 125 et 250. Il te suffit de replacer correctement les 2 octets de ta valeur composées en fonction de l’endian local et tu vas retrouver exactement les mêmes valeurs qu’au départ, dans des types complétement diffèrent et ce, quel que soit l’endian des 2 systèmes.

Si tu veux aller plus loin et faire un algo qui soit compilable sur n’importe quel system aussi bien d’un cote que de l’autre , il te suffit de réserver un bit pour indiquer l’ordre des bytes des valeurs composées dans le tableau (ça tombe bien il y en a un de dispo puisque 16384 n’utilise que 15 bits).

C’est quand même pas bien compliqué à comprendre .

[romaxx]

1 byte = 1 octet = 8 bits

Oui alors non, pas exactement.
1 octet = 8 bits oui,
1 byte n'est historiquement pas nécessairement égal à 1 octet (https://fr.wikipedia.org/wiki/Octet à la partie historique), même si des normalisations vont dans ce sens.
Donc svp, n'utilisez pas le mot octet et byte dans la même phrase lorsqu'ils sont égaux... car on penserai que ce n'est pas le cas et c'est pénible.

[destroyedlolo]

J'ai très bien compris ce que tu veux faire, merci.

Ca donne une structure du genre

Code : Tout sélectionner

struct dt {
	unsigned short int compteur;
	unsigned char bas, haut;
};

Sauf qu' on transfère à nouveau une donnée stockée sur 2 octets ... donc a nouveau se pose la question du boutisme : je ne vois strictement pas l’intérêt de réordonner systématiquement l'ordre de ses octets alors qu'il suffit simplement de faire un test préalable pour voir si c'est nécessaire ou pas : ca prend 2 minutes tester (codage compris) et au moins, on sait ou on va ! Et comme on est dans un projet scolaire, ça démontre qu'on pris en compte cette problématique.

prérequis :
[*] les systèmes utilisent-il le même "boutisme"

De plus, le but du projet semble de s'assurer que le radar envoie des données à son rythme nominal. Il serait intéressant de savoir quelles sont les valeurs limites : en cas de problème, on devrait recevoir des durées > 120uS, peut-être même plus stockable sur un simple octets.

@romaxx : je suis aussi partisan de l'utilisation de l'octet, même nos amis anglo-saxon le connaisse.

[Bud Spencer]

1 byte n'est historiquement pas nécessairement égal à 1 octet (https://fr.wikipedia.org/wiki/Octet à la partie historique), même si des normalisations vont dans ce sens.

Tout à fait exact et c'est bien de le rappeler. Pour quelqu'un qui n'aurais pas forcement suivi le contexte d'utilisation des termes, cela pourrait effectivement prêter a confusion. Pour ma part, j'utilises le plus souvent le terme byte comme un type représentant un entier d'un octet (qui peut d'ailleurs être signé ou pas suivant les langages). J'admet que comme tout les dev. j'utilise aussi parfois par facilité le terme byte pour définir un octet, ce qui sans être tout a fait juste n'est plus aujourd'hui forcement faux.

J'ai très bien compris

Je constate que non, mais c'est pas grave. En relisant et en réfléchissant peut être tu y arriveras, parce que la, je ne vois sincèrement pas comment être plus didactique (désolé, mais suis développeur, pas professeur)

ce que tu veux faire.

Petite Nuance : Ce n'est pas 'ce que je veux faire', mais 'ce que je fais' depuis très longtemps comme tous les développeurs qui ont à structurer des échanges entre des unités d'architectures et de systèmes complètement différents. Je n'ai pas la prétention de réfléchir à inventer une combine, je ne fais qu'exposer ce qui se pratique depuis toujours.

je ne vois strictement pas l’intérêt de réordonner systématiquement l'ordre de ses octets

C'est justement ce qui permet 'entre autre' de faire l'abstraction des différents types, ordonnancements et même du nombre de bits qui composent les bytes des différentes entités. (ici, byte au sens historique du terme pour faire plaisir a rommax )

Les octets ne sont pas 'réordonné'. Ils sont placés pour initialiser des types et c'est toute la nuance et peut-être ce que tu ne comprends pas. Il n'est d'ailleurs écrit nulle part que 2 octets qui doivent former un int16 bits doivent se trouver en succession dans le tableau.

Exemple 1 : Le tableau fait X octet et je dois initialiser un int16 avec l'octet Y MSB et de l'octet Z LSB (qui pourrait aussi être l’inverse). Y pourrais se trouver à la position 25 du tableau et z la position 30. L’important, c’est juste de savoir où sont positionnés mes octets dans le tableau et ou les placer les dans mon type finale.

Exemple 2 : 2 valeurs limitées à 12 bits peuvent se suffirent dans 3 octet transmis.

Tout ça optimise le volume de données brutes à transmettre et évite les méthodes genre 'convertion en string' qui effectivement fonctionnent aussi (pas systématiquement), mais qui relève plus de l'amateurisme débutant que du niveau d'étude du PO. De plus compte tenu des contraintes du projet, ça va au-delà de l'utopie et creuser dans ce sens serait forcément une perte de temps (sauf si l'on considère à juste titre que l'échec est formateur). J’admets que pour un codeur amateur cela peut sembler un peu délicats à mettre en œuvre, mais dans la réalité c’est extrêmement simple à faire.

Il serait intéressant de savoir quelles sont les valeurs limites : en cas de problème, on devrait recevoir des durées > 120uS, peut-être même plus stockable sur un simple octets.

La dessus tout à fait d'accord avec toi, mais ça, c'est un autre débat. Jusqu'ici, je n'ai apporté ma pierre que concernant l'encapsulation des valeurs, mais ça ne valide en rien la cohérence du projet tel qu'il est envisagé. Il suffit juste d'une impulsion manquée pour que les valeurs 'théoriques' de durées aillent au-delà de la capacité des types attendus. J'ajoute même que de définir des types plus grand ne resoudrait rien. Tout ça peut être résolu très simplement, mais comme je l'ai dit, c'est un autre débat.

[Pinhapple]

Faut essayer. Elle est connectée au cpu comment ta SD ? SPI ? 4 Bits ? Quel Format de fichier ?

La carte est branchée sur l'adaptateur du shield Ethernet no-name, je serais bien incapable de te dire avec certitude comment elle est reliée au microcontrôleur ; si c'est comme pour le shield officiel Arduino, c'est du SPI. La carte microSD est une Kingston microSDHC 4 Go classe 4, formatée en FAT32. J'ai vu que les vitesses d'écriture dépendaient en partie de la carte (classe, marque), mais que même avec une "bonne" carte, on resterait malgré tout dans les millisecondes pour l'ouverture/écriture/fermeture.

Ben celle qui te sert a envoyer les données.

Ok ça marche, je posais la question car plusieurs bibliothèques externes ont été évoquées précédemment, c'était de l'une d'elles dont tu aurais pu parler.

Avec le DMA pas besoin de thread.. ni d'interruption..c'est justement le but de décharger le proc.
ton maitre de stage a quelles qualifs ?

Bonne question, pourquoi ? Je sais qu'il touche sa bille en Arduino, Raspberry Pi, électronique, et Java. Les choix que je fais viennent de moi, lui ne fait que me guider, ou éventuellement me recadrer si je pars trop loin.

Juste une question parce que ca me taraude quand même : Tu comptes faire quoi à l'arrivé des données sur ton PI ? Même si j'ai dit qu'on s'en foutait pour l'instant, ca peut quand même avoir de l'incidence sur la méthode d'envoi a choisir.

Je comptais stocker ça dans des listes, puis une fois toutes les données demandées réceptionnées (par exemple, sur 10 tours), les écrire ordonnées dans un fichier (par exemple, ligne 1 pour le tour 1, ligne 2 pour le tour 2, etc.). Une fois le fichier complet, on pourra l'analyser (à la main ou avec un autre soft) pour voir les écarts.

Nouveau problème. Comment enregistrer des données plus vite qu'on ne les reçois sur un système qui reçoit plus vite qu'il ne les enregistres ?
Décidément, T'as pas choisi un projet facile

Problème qui n'en est plus un du coup : je n'essaie même pas de poursuivre avec la SD !

Je vois que chacun ici a beaucoup de choses à apporter, même si ça s'éloigne du sujet c'est toujours intéressant à lire, donc merci pour vos messages !

[destroyedlolo]

ce que tu veux faire.

Petite Nuance : Ce n'est pas 'ce que je veux faire', mais 'ce que je fais' depuis très longtemps comme tous les développeurs qui ont à structurer des échanges entre des unités d'architectures et de systèmes complètement différents. Je n'ai pas la prétention de réfléchir à inventer une combine, je ne fais qu'exposer ce qui se pratique depuis toujours.

Ben non ! On touche là le fond de notre problème de communication. Ce que tu décris correspond entre autre aux protocoles répondant à la norme ASN.1 ou dérivé (entre autre car l'ASN.1 fonctionne plus ou moins comme tu le décris, sauf que dans ton explication, c'est toi qui fixe la place de chaque morceau) dont l’implémentation la plus courante est le SNMP (et non SMTP comme je l'écrivais plus haut par erreur, je corrige aussi).
Ce que tu n'arrives pas à saisir, c'est que ca reste couteux et tu fais une généralisation qui n'a pas lieu d'être : non, "tous les développeurs" n'utilisent pas ce que tu décris, loin de là. Et encore plus lorsqu'on touche à de l'embarqué, à de l'IOT, aux systèmes où chaque cycle CPU, chaque octet et chaque uW comptent. Dans ce cas, sont envoyés des memory mapping comme je le décris, memory mapping qui sont convertis si nécessaire par le récepteur généralement n'ayant pas ces contraintes, basé sur le profile de la source.
Alors, in fine, oui, dans tes specs de transmission, tu indiques

• entête
• poid fort compteur
• poid faible compteur
• ...

mais tu fais les specs en fonction de ce qui est le plus pratique pour le périph et non l'inverse (hormis à devoir suivre un protocole imposé).
A l'autre bout, si le développeur est réveillé, il castera son buffer en la dite structure et convertira ce qui doit l'être plutôt que faire des déplacements d'octets pour aucune de valeur ajoutée (et tu ne peux pas dire que ce n'est que ma sauce, car c'est typiquement ce qui est fait pour lire les trames issues des RFXcom : son concepteur fournit directement la structure C correspondante).

Système aussi utilisé pour faire communiquer des "unités de calcul" d'architectures différentes par de la mémoire partagée et, lorsque les perfs sont vraiment critiques, ça passe par de la mémoire à double accès et la conversion des types est fait de manière hardware.

Moi non plus je ne suis pas prof, moi non plus, je n'ai rien inventé, c'est simplement ce qui est utilisé depuis des lustres dans l'industrie et est parfaitement documenté.

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.

[Bud Spencer]

Comme tu le dis, on tourne en rond, et ça n’apporte rien.
Juste pour rappel, on est censé transférer en temps réel les données d’un codeur qui génère un signal à 4 Khz. La question était de savoir quelle méthode utiliser pour optimiser le volume d’informations afin de les transférer d’un appareil a un (des) autre(s) en utilisant une liaison IP/ simpliste (qui aurait aussi pu utiliser une liaison ou un transfert d’un autre type comme rommax l’avait proposé avec uart dma). C’est à cela que j’ai répondu. La solution que je proposais d’essayer est juste une simple optimisation de paquets par tronquage et décalage de bits comme ça se pratique depuis la nuit des temps sur tout type de transport.

...Ce que tu n'arrives pas à saisir, c'est que ca reste couteux et tu fais une généralisation qui n'a pas lieu d'être ...

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. J’arrive encore moins à comprendre comment on peut espérer consommer moins de ressources en hébergeant un broker mqtt qui même avec QoS 0 doublerait au minimum un trafic qui frole déjà l’utopie et comment cela allègerait l’empreinte mémoire des clients à qui l’on aurait besoin d’ajouter une couche protocolaire (totalement inadapté pour le cas). En dernier lieu, je ne comprends pas où est la généralisation quand on prétend apporter une solution spécifique à un problème spécifique. J’ai professionnellement connecté et développé des algos pour des centaines de machines ou périphériques qui utilisaient des protocole propriétaires dictée par les fabricants et c’est encore très souvent le cas aujourd’hui.

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). 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. Après, on est capable de comprendre comment ça marche et de faire ou pas, mais ça, c’est une autre histoire.