Python et Ethernet/UDP

[Pinhapple]

C'est la différence avec le print() où là, il est expressément indiqué qu'il envoie une chaîne

Effectivement : "the number 123 is sent as the three characters '1', '2', '3'".

Ben as-tu compris en quoi ca consiste ?
Car c'était le sujet du dialogue de sourd précédent :

• D'un coté, tu utilises un buffer ou tu met toi-même les info a un emplacement que tu spécifies ... ce qui implique que tu t'amuses à placer à la mano les informations. C'est simple si tu as que des entiers tenant sur un octet, ca demande plus de réflexion avec des entiers "multi-octets".
• De l'autre coté, tu utilises et envoie des structures C donc c'est le compilo qui fait tout ce travail pour toi ... mais tu as a faire attention à ce que les entiers "multi-octets" soient compris de la même facons des 2 cotés.

Comme tu l'auras compris, je suis partisan dans ton cas de la seconde méthode qui est très largement répendue : elle a l'avantage d'être une méthode banalisée (utilisable aussi ailleurs que dans des communications réseau), demandant moins de manipulations explicites et surtout, conserve la sémantique des données qui transitent. Si tu as la "chance" d'avoir le même boutisme des 2 côtés, c'est aussi la plus rapide.

Les structures en C décrites précédemment, comparables à des objets en POO ? Je pense voir ! Pour des entiers multi-octets (admettons un nombre AB, avec A l'octet 0 et B l'octet 1), je dois donc m'assurer que si j'envoie AB, le nombre reçu soit bien AB et non BA.

Ainsi que la méthode pour les remplir et basculer de l'un à l'autre (ce qui est triviale).

C'est en cours ! Je vais essayer dans un premier temps de mettre en buffer les durées de chaque bip et les écarts entre deux bips consécutifs, je verrai par la suite pour les bips "tour" qui sont moins intéressants. Je vais faire une structure comme expliqué précédemment, et remplir un tableau de ces structures.

Heu, non la, je ne suis pas d'accord avec toi.
A moins que l'Education Nationale ait bien changé, ils s'attendent justement à ce que tu ailles plus loin que ce que tu as appris : la curiosité, l'envie d'aller plus loin, les méthodes de recherches, l'ouverture d'esprit ... voila tout ce qui fait la différence entre un bon ingénieur et un gars qui ne sera bon qu'a appliquer une procédure (ce qui n'a rien de péjoratif : c'est nécessaire aussi).

On approfondissait les sujets vus en cours. Là où j'aurais pu tomber sur l'étude des microcontrôleurs dans mes recherches, c'est en première année lorsque l'on a étudié l'architecture des processeurs ; et même si ça a été mentionné, j'avoue ne pas être allé plus loin à l'époque. Depuis je fais ça de mon côté, grâce à des livres et Internet, avec l'amateurisme que ça implique...

Tout n'est pas négatif : tu as quand même résolue les pb de communication avec les échanges précédents (même si je t'avoue ne pas comprendre pourquoi tu n'es pas parti directement sur du différentiel ... si le radar te fourni ça, il y avait une raison ).
Et tu arrive a mesurer les valeurs. Reste à le faire de manière efficace et à les envoyer.
Tu es aussi aller chercher de l'aide quand tu en avait besoin ce qui est aussi un plus.

J'ai perdu beaucoup de temps à vouloir "faire simple et rapide" en pensant que lire un seul signal de chaque paire du différentiel pourrait suffire. Là c'était dû un manque de connaissance en matière de filtrage et d'électronique en milieu parasité, et j'ai voulu griller des étapes en me disant que ça suffirait.

On ne peut cacher non plus qu'il y a eu quelques errements qui t'on fait perdre du temps et tu as squizer la partie "étude de l'existant", "reflexion sur les méthodes" ... que qui t'as mis un peu (beaucoup ?) dans le gaz.
Combien de temps te reste-t-il ?

J'avais une idée de comment faire, je me suis lancé tête baissée sans faire d'analyse. Il me reste un mois plein avant la fin du stage et la remise du rapport, ça me laisse, je pense, suffisamment de temps pour terminer.

C'est pourquoi j'avais indiqué qu'il restait une épée de Damoclès au niveau de la carte réseau Il aurait été bien que cette réflexion (le goulet du au SPI) vienne de toi.
Comme indiqué, tu ne devrais transférer qu'un maximum de 100ko/s (je te laisse voir si ca passe avec tes technos ) et si tu te penche sur les données vraiment utiles, tu verras facilement que tu peux tomber à un peu plus que 32 ko/s.

Maintenant ça me paraît évident à regarder mon shield sur la carte, mais j'ai vraiment pas vu le coup du SPI venir !

Je vois la pertinence de tes questions évoluées depuis 3 de tes sujets auxquels je participe, donc que ton projet soit un succès ou un échec ne change finalement pas grand-chose. L’important sera d’avoir appris et si il y a échec, d'être en mesure d'expliquer techniquement pourquoi.

C'est sérieux quand je dis que j'apprends des choses, je me contente pas de lire en espérant trouver une solution toute faite ! Je me dis également qu'au pire du pire, si ce travail se retrouve dans les mains de quelqu'un d'autre, j'aurais déjà pas mal dégrossi le sujet avec plusieurs tentatives, et ça servira à quelqu'un. Mon précédent projet (les fameuses 4 000 valeurs par seconde à récupérer si tu te souviens bien ) a avorté car mes responsables ont tranché : Sense HAT pas assez précis pour l'utilisation requise, trop de dérive, pas assez de vitesse. Du coup j'ai rédigé un document expliquant ce qui avait été testé, les résultats obtenus, et les explications des échecs. Mission accomplie, même si je suis frustré de ne pas avoir produit un outil fonctionnel. Mais je manipule, j'apprends des choses, et ça me donne envie de bidouiller (je change de logement bientôt, j'ai de la domotique en tête !).

Tout ça fait partie d'une longue la liste de petits détails que l’on à vue totalement négligés au profit de grandes théories qui peuvent être parfois certes intéressantes, mais qui finalement offusque totalement la réalité des contraintes du projet et qui n’apporte rien de concret. Moi y’en a idiot, mais idiot a tout de suite comprit qu’avec 16384 cycles par tours, un seul octet de plus par cycle, c’est tout de suite 16384 octets de plus par tour à transférer mais aussi à gérer de l’autre coté (ça c’est pour les surprises qui t’attendent coté PI …). Pas besoin d’étaler des kilomètres² de mélasse ou d’avoir fait les grandes écoles pour comprendre ça.

Ça aussi ça me perturbe : multiplier les supports (Arduino, auquel s'ajoute le RPi, auquel s'ajoute l'Ethernet, etc.) c'est potentiellement multiplier les surprises que tu mentionnes, et là je ne sais même pas si c'est faisable avec ce que je sais actuellement. Qu'on me dise "tu as ça, ça, ça, c'est sûr à 100 % que c'est jouable, en avant", je veux bien, mais là y a beaucoup de trucs à prendre en compte, et je ne suis pas au bout de mes surprises !

Mais on en revient à ce que je disais : au moins j'expérimente, je manipule, etc. ; à moi de faire en sorte de tirer quelque chose de ces "échecs".

Je vais tout reprendre posément et je vous tiens au jus, merci pour les réponses !

[destroyedlolo]

Heu, le repas portant conseil, je me suis gouré : pas 100ko/s mais 100Ko sur 4 secondes soit 25ko/s en mode non optimisé et moins de 1 ko/s en optimisé.

Les structures en C décrites précédemment, comparables à des objets en POO ? Je pense voir ! Pour des entiers multi-octets (admettons un nombre AB, avec A l'octet 0 et B l'octet 1), je dois donc m'assurer que si j'envoie AB, le nombre reçu soit bien AB et non BA.

Voila, mais tu peux faire le genre de test suivant sans avoir besoin de réseau (si les short int sont en 16 bits ce qui est généralement le cas, sinon je te laisse modifier) :

Code : Tout sélectionner

#include <stdio.h>

int main(){
        char x[2];
        *(unsigned short *)x = 0x1234;

        printf("%02x %02x\n", x[0],x[1]);

        return 0;
}

(code crade, hein, je n'ai pas vérifier).
Si tu as le même résultat sur ton Arduino et sur le PI, tu n'as pas de problème et donc rien à faire (mais tu peux le mettre dans ton rapport si tu choisie de passer par des structures, ca fera bien : "le mec qui y a réfléchit" ou plutot "le mec qui a réussi a trouver les conseils qui vont bien" ).

C'est en cours ! Je vais essayer dans un premier temps de mettre en buffer les durées de chaque bip et les écarts entre deux bips consécutifs, je verrai par la suite pour les bips "tour" qui sont moins intéressants. Je vais faire une structure comme expliqué précédemment, et remplir un tableau de ces structures.

Peux-tu la copier ici qu'on voit ce que ca donne ? ... ainsi que ton estimation de la volumétrie que ca engendre

J'ai perdu beaucoup de temps à vouloir "faire simple et rapide" en pensant que lire un seul signal de chaque paire du différentiel pourrait suffire. Là c'était dû un manque de connaissance en matière de filtrage et d'électronique en milieu parasité, et j'ai voulu griller des étapes en me disant que ça suffirait.

Il est rare qu'en analogique "griller des étapes" fonctionne

Ça aussi ça me perturbe : multiplier les supports (Arduino, auquel s'ajoute le RPi, auquel s'ajoute l'Ethernet, etc.) c'est potentiellement multiplier les surprises que tu mentionnes,

Ben c'est le cas de la majorité des projets : le but de "l'architecte" est alors d'éviter d'étoffer le millefeuille avec des trucs parfaitement inutiles (c'est ce qu'à fait malheureusement mon client actuel, ce qui nécessite après des réunions a rallonge qui ne servent à ... rien et me laisse donc le temps de te répondre )

et là je ne sais même pas si c'est faisable avec ce que je sais actuellement. Qu'on me dise "tu as ça, ça, ça, c'est sûr à 100 % que c'est jouable"

Ben personne ne peut répondre à ta place vu que tu es le seul à avoir la visibilité sur ce que tu fais . La seule chose que je peux te dire, c'est qu'il existe au moins une solution qui te permet d'arriver au bout avec ton matos actuel ...

En tout cas, projet interessant, et tu t'accroche ... ce qui est motivant dans mon cas (on sort des sempiternels "comment je peux stopper mon rPI" et autre "j'ai grillé ma SD" ).

[Bud Spencer]

Les structures en C décrites précédemment, comparables à des objets en POO ?

Non. Même si une class qui ne contiendrait que des types pourrait être assimilée à une structure (ou l’inverse), ça n’a absolument rien à voir. Considère une structure comme une variable personnalisée composée de plusieurs types. Ni plus, ni moins.

Pour des entiers multi-octets (admettons un nombre AB, avec A l'octet 0 et B l'octet 1), je dois donc m'assurer que si j'envoie AB, le nombre reçu soit bien AB et non BA.

Encore à perdre du temps avec ces guignoleries. Pourquoi tu tiens tellement à stocker tes valeurs dans des vars 16 bits alors que ta fonction d’envois ne sait reconnaitre que des valeurs sur 8 ? Tu crois peut être que tu vas passer une structure composée directement à ta fonction udp.write et que tout va se faire tout seul ? Même pas en rêve mon gars. Si tu as dans ta structure des vars sur 16,32 … bits, avant de transférer tout ça, tu vas devoir passer par une étape de découpage pour transformer tout ça en …. en …. ? bhé oui, en série de vars codées sur 1 octet. Après, soit tu laisses le système décider de l’ordonnancement en fonction de sa propre architecture en comptant sur la chance pour que ce soit nativement compatible avec tous tes clients potentiels ou alors tu lui en imposes un spécifique qui te garantit la portabilité, à toi de voir ...

Finalement, 4 pages de mélasse pour en revenir à ça, c’est ballot hein

Du coup j'ai rédigé un document expliquant ce qui avait été testé, les résultats obtenus, et les explications des échecs. Mission accomplie

Bien vu. C'est exactement l'attitude qu'il faut avoir pour marquer des points sur un échec. A mon sens, expliquer pourquoi un problème est insoluble (au regard des moyens à disposition bien entendu) est aussi gratifiant que d'en résoudre un qui a une solution.

... et je ne suis pas au bout de mes surprises !

Ca je ne te le fais pas dire. Tu sais ces petits détails auxquels personne ne pensent dont je t’ais déjà parlé ? J’en ai encore plein sous le coude. Je les gardes pour les sortir au moment opportun, sinon ce n’est pas drôle et on dirait que je détourne le sujet

[Pinhapple]

Voila, mais tu peux faire le genre de test suivant sans avoir besoin de réseau (si les short int sont en 16 bits ce qui est généralement le cas, sinon je te laisse modifier)

Ça me renvoie "34 12" de chaque côté !

Peux-tu la copier ici qu'on voit ce que ca donne ? ... ainsi que ton estimation de la volumétrie que ca engendre

Dans un premier temps, je suis sur l'envoi à chaque nouveau tour du numéro de tour ainsi que du nombre de bips pour ce tour écoulé, ce qui donne :

Code : Tout sélectionner

struct elapsedLap
{

	unsigned int lapNbr; // Numéro du tour écoulé. Commence à 0 afin d'inclure sans les compter les bips du tour incomplet avant le premier bip "tour". 
	unsigned int bipNbr; // Nombre de bips radars du tour écoulé.

};

Je suis parti sur du unsigned int pour les numéros de tour, car mon soft serait amené à tourner pendant une heure, donc le type byte était trop petit ; et unsigned int toujours pour les bips radars, qui au maximum (ça dépend des radars) tiendraient dans la plage [0 ; 65 535].

En tout cas, projet interessant, et tu t'accroche ... ce qui est motivant dans mon cas (on sort des sempiternels "comment je peux stopper mon rPI" et autre "j'ai grillé ma SD" ).

Ha ha, il fallait que tu en parles : j'ai ma microSD qui est en fin de vie là, je dois rebooter 3 ou 4 fois chaque matin en arrivant !

Pourquoi tu tiens tellement à stocker tes valeurs dans des vars 16 bits alors que ta fonction d’envois ne sait reconnaitre que des valeurs sur 8 ?

C'était juste pour être sûr que j'avais bien compris l'explication précédente, t'inquiète !
En revanche, mes int sont stockés sur 2 octets, donc 16 bits ; je ne tiens pas particulièrement à stocker mes valeurs dans des vars 16 bits, mais à moins d'utiliser des bytes, je vais toujours être à au moins 16 bits, non ? (32 bits pour un long, 64 bits pour un long long, etc.)

Ca je ne te le fais pas dire. Tu sais ces petits détails auxquels personne ne pensent dont je t’ais déjà parlé ? J’en ai encore plein sous le coude. Je les gardes pour les sortir au moment opportun, sinon ce n’est pas drôle et on dirait que je détourne le sujet

J'ai hâte !

J'ai refait mon soft en Python en C, en me disant que ce serait plus pratique d'envoyer et de recevoir des structures dans le même langage. J'ai suivi ce tuto que j'ai adapté, et j'arrive à recevoir en C la même chose qu'avant en Python, donc ça va.

Maintenant je m'attaque à envoyer mes valeurs dans la structure par l'Ethernet. Comme d'hab', je vous tiens au jus.

[destroyedlolo]

Ça me renvoie "34 12" de chaque côté !

Cool : nous venons de prouver que les 2 procs utilisent le meme boutisme.
Le second truc a verifier est qu'ils ne forcent pas les alignements et donc qu'il n'y a pas de padding (je te laisse cherche sur le web quel est ce pb).

Tu peux le voire en créant une structure du genre

Code : Tout sélectionner

struct {
	char toto;
	short tata;
	long titi;
};

que tu remplis de données connues.
Le sizeof() de cette structure doit être le même ainsi évidement le contenu.

Code : Tout sélectionner

struct elapsedLap
{

	unsigned int lapNbr; // Numéro du tour écoulé. Commence à 0 afin d'inclure sans les compter les bips du tour incomplet avant le premier bip "tour". 
	unsigned int bipNbr; // Nombre de bips radars du tour écoulé.

};

Heu ..

• C'est une très très très très mauvaise idée d'utiliser de int comme ça : il faut au minimum mettre des short int, des long int, ou des types définis dans les includes dont la taille est connue : un int peut avoir des tailles différentes suivant le compilo et les options utilisés
• au niveau optimisation, le but étant de transférer le moins possible (nous n'avons pas encore parlé des limites des Arduino), ces infos sont-elles vraiment pertinentes ?

Je suis parti sur du unsigned int pour les numéros de tour, car mon soft serait amené à tourner pendant une heure, donc le type byte était trop petit ; et unsigned int toujours pour les bips radars, qui au maximum (ça dépend des radars) tiendraient dans la plage [0 ; 65 535].

Ha ha, il fallait que tu en parles : j'ai ma microSD qui est en fin de vie là, je dois rebooter 3 ou 4 fois chaque matin en arrivant !

Nnnnnaaaaaaannnnnnnnnn

Maintenant je m'attaque à envoyer mes valeurs dans la structure par l'Ethernet. Comme d'hab', je vous tiens au jus.

Sans vouloir être désobligeant, vu ce que j'ai du mettre ci-dessus à propos des types, je te conseille fortement de faire des jeux de tests en créant tes structures des 2 cotés, en les remplissant de valeurs connues et a vérifier que tu obtiens bien les mêmes valeurs des 2 cotés.
Évidemment, nous pourrions t'indiquer les écueils voir les best practice,mais comme c'est un projet scolaire, je pense que ca doit venir de toi et j'en ai déjà dit trop
De même, lorsque tu vas établir tes schémas de données, il est souhaitable qu'avant tu te familiarise avec les limitations de ton matos ... en particulier l'Arduino.

[Pinhapple]

Le second truc a verifier est qu'ils ne forcent pas les alignements et donc qu'il n'y a pas de padding (je te laisse cherche sur le web quel est ce pb).

Article intéressant sur Wikipédia.
En faisant le même test que dans l'article (en utilisant des short à la place des int) sur mon Arduino, j'obtiens 10 et 10 ; côté RPi en C, j'obtiens 24 et 16. C'est inattendu, d'autant que je ne vois pas comment arriver à 10 octets coté Arduino (1 char + 1 double + 1 short + 3 char : 1 + 8 + 2 + 3 * 1 = 14 octets au mieux), et la doc Arduino confirme les tailles de ces types.

C'est une très très très très mauvaise idée d'utiliser de int comme ça : il faut au minimum mettre des short int, des long int, ou des types définis dans les includes dont la taille est connue : un int peut avoir des tailles différentes suivant le compilo et les options utilisés

En effet, 2 ou 4 octets selon les OS/processeurs/compilateurs. J'imagine que ça n'aurait pas été gênant si je n'essayais pas de communiquer avec un autre système et que je restais uniquement sur l'Arduino. Je vais utiliser des short, merci pour la remarque !

au niveau optimisation, le but étant de transférer le moins possible (nous n'avons pas encore parlé des limites des Arduino), ces infos sont-elles vraiment pertinentes ?[/list]

Pertinentes dans quel sens ? Pour mes tests ?
Si c'est pertinent par rapport au projet, ces deux infos seront à transférer (c'est requis dans les spec), donc si je peux faire mes tests dessus, ce sera ça de fait. De plus, ça me permet de voir si ce que je reçois est cohérent plutôt que d'envoyer des valeurs fixes ou aléatoires.
Sinon dis-moi, ce serait pas la première fois que je fais un truc un peu en décalage !

Nnnnnaaaaaaannnnnnnnnn

T'en fais pas, après avoir flingué trois Verbatim d'affilée (au passage, je déconseille cette marque pour le RPi), j'ai pris l'habitude d'avoir du stock et de faire des images de mes cartes ; je vais pas créer de sujet ici à propos de ma SD grillée !

Sans vouloir être désobligeant, vu ce que j'ai du mettre ci-dessus à propos des types, je te conseille fortement de faire des jeux de tests en créant tes structures des 2 cotés, en les remplissant de valeurs connues et a vérifier que tu obtiens bien les mêmes valeurs des 2 cotés.

Pas de souci, je ne suis pas là pour qu'on me dise que ce que je fais est bien si ce n'est pas le cas. Concernant le test que tu suggères, j'ai toujours mes sizeof() à 24/16 et 10/10 cités précédemment ; mes autres valeurs correspondent entre Arduino et RPi, à l'exception du double de mes structures (auquel j'attribue la valeur 6.8) qui me renvoie 6.80 côté Arduino et 6.800000 côté RPi.
Pour le tableau de char (un string donc), j'ai un doute : j'attribue 'p' et 'i' aux index 0 et 1, et '\0' à l'index 2 (caractère de fin de string), ce qui me renvoie la même chose des deux côtés. C'est correct de faire ça ?

[destroyedlolo]

Yo !

En faisant le même test que dans l'article (en utilisant des short à la place des int) sur mon Arduino, j'obtiens 10 et 10 ; côté RPi en C, j'obtiens 24 et 16. C'est inattendu, d'autant que je ne vois pas comment arriver à 10 octets coté Arduino (1 char + 1 double + 1 short + 3 char : 1 + 8 + 2 + 3 * 1 = 14 octets au mieux), et la doc Arduino confirme les tailles de ces types.

Ben pas sur celle que j'ai trouvé https://www.arduino.cc/en/Reference/Double

En effet, 2 ou 4 octets selon les OS/processeurs/compilateurs. J'imagine que ça n'aurait pas été gênant si je n'essayais pas de communiquer avec un autre système et que je restais uniquement sur l'Arduino. Je vais utiliser des short, merci pour la remarque !

Même dans ce cas, ca peut merder, car il y a des options du compilo qui te permettent de le changer (ce qui peut etre le cas surtout dans l'embarqué).

au niveau optimisation, le but étant de transférer le moins possible (nous n'avons pas encore parlé des limites des Arduino), ces infos sont-elles vraiment pertinentes ?[/list]

Pertinentes dans quel sens ? Pour mes tests ?
Si c'est pertinent par rapport au projet, ces deux infos seront à transférer (c'est requis dans les spec), donc si je peux faire mes tests dessus, ce sera ça de fait. De plus, ça me permet de voir si ce que je reçois est cohérent plutôt que d'envoyer des valeurs fixes ou aléatoires.

Ben ... le nombres de tour ne t'es pas fourni par le radar : c'est toi qui le calcul. Alors le faire coté PI ou coté Arduino ne change en rien le processus ... a partir du moment ou tu as une connexion réseau fiable.

Concernant le test que tu suggères, j'ai toujours mes sizeof() à 24/16 et 10/10 cités précédemment

Vas-tu transférer des flottants ? J'en doute. C'est pourquoi il faut que tu te focalise sur les structures que tu vas utiliser. Sinon, tu risque de perdre du temps sur des problèmes qui ne te concernent pas

; mes autres valeurs correspondent entre Arduino et RPi, à l'exception du double de mes structures (auquel j'attribue la valeur 6.8) qui me renvoie 6.80 côté Arduino et 6.800000 côté RPi.

Et ??? Ben on s'en fou, ce n'est que de la cosmétique.

Pour le tableau de char (un string donc), j'ai un doute : j'attribue 'p' et 'i' aux index 0 et 1, et '\0' à l'index 2 (caractère de fin de string), ce qui me renvoie la même chose des deux côtés. C'est correct de faire ça ?

Oui.

[Pinhapple]

Ben pas sur celle que j'ai trouvé https://www.arduino.cc/en/Reference/Double

J'ai lu la phrase pour l'Arduino Due... "On the Uno and other ATMEGA based boards, this occupies 4 bytes" du coup, mea culpa.

Ben ... le nombres de tour ne t'es pas fourni par le radar : c'est toi qui le calcul. Alors le faire coté PI ou coté Arduino ne change en rien le processus ... a partir du moment ou tu as une connexion réseau fiable.

Vas-tu transférer des flottants ? J'en doute. C'est pourquoi il faut que tu te focalise sur les structures que tu vas utiliser. Sinon, tu risque de perdre du temps sur des problèmes qui ne te concernent pas

Là comme ça, si je devais faire une structure complète à froid pour mon cas, je partirais sur du

Code : Tout sélectionner

struct bip
{

	unsigned short lapNbr;    // Numéro de tour.
	unsigned short bipNbr;    // Numéro du bip concerné.
	unsigned short bipLength; // Durée (µs) de l'état haut du bip concerné.
	unsigned short bipGap;    // Durée (µs) entre le front montant du dernier bip et le front montant du bip concerné.

};

Du unsigned partout car aucune de mes valeurs ne peut être négative ; et du short partout car aucune de ces valeurs ne devrait dépasser la limite du unsigned short. Je suis même tenté de mettre du byte pour mes bipLength et bipGap,

Et ??? Ben on s'en fou, ce n'est que de la cosmétique.

Sait-on jamais, je précisais au cas où ! Mais oui, mathématiquement, 6.8 = 6.80 = 6.800000.

Oui.

Nickel. Je préfère demander un truc tout bête plutôt que de me rendre compte dans deux semaines que je me suis planté.

[destroyedlolo]

Faut que tu calcule maintenant la bande passante nécessaire ... et que tu compare par rapport aux limites de timing de ton projet et de ton matos ...

[Pinhapple]

(J'ai posté mon message au lieu de sauvegarder le brouillon, d'où la phrase en suspens...)

Donc, pour reprendre où j'en étais :

Ben ... le nombres de tour ne t'es pas fourni par le radar : c'est toi qui le calcul. Alors le faire coté PI ou coté Arduino ne change en rien le processus ... a partir du moment ou tu as une connexion réseau fiable.

Je pourrais effectivement calculer le nombre de tours côté RPi à partir des numéros de bips, un retour à zéro signifiant forcément un nouveau tour. Tant que je suis sûr à 100 % d'avoir tous mes bips du tour, ça me va.

Vas-tu transférer des flottants ? J'en doute. C'est pourquoi il faut que tu te focalise sur les structures que tu vas utiliser. Sinon, tu risque de perdre du temps sur des problèmes qui ne te concernent pas

Là comme ça, si je devais faire une structure complète à froid pour mon cas, je partirais sur du

Code : Tout sélectionner

struct bip
{

	unsigned short lapNbr;    // Numéro de tour.
	unsigned short bipNbr;    // Numéro du bip concerné.
	unsigned short bipLength; // Durée (µs) de l'état haut du bip concerné.
	unsigned short bipGap;    // Durée (µs) entre le front montant du dernier bip et le front montant du bip concerné.

};

Du unsigned partout car aucune de mes valeurs ne peut être négative ; et du short partout car aucune de ces valeurs ne devrait dépasser la limite du unsigned short. Je suis même tenté de mettre du byte pour mes bipLength et bipGap, étant donné qu'il y a peu de chances que ces valeurs dépassent 255. Si j'ai mis du short, c'est justement au cas où l'outil soit utilisé sur un autre type de radar ayant une forme de signal différente. Si ça peut me faire gagner de la place, je peux me faire confirmer ce point et changer mes types en fonction de la réponse.

Faut que tu calcule maintenant la bande passante nécessaire ... et que tu compare par rapport aux limites de timing de ton projet et de ton matos ...

Avec cette structure, ça te paraît correct ? Le fait que ce soit une structure n'ajoute pas d'octet au total de la taille de mes variables ?