Les forums français du Raspberry Pi
http://forums.framboise314.fr/
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.destroyedlolo a écrit :Un simplene 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.Code : Tout sélectionner
unsigned long int toto = 0xaabbccdd; write(fd, &toto, sizeof(toto);
). 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.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.destroyedlolo a écrit : 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é.
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 ?Pinhapple a écrit : après recherches, on parle de durée de l'ordre de la milliseconde pour l'écriture, même avec une "bonne" carte...
Code : Tout sélectionner
unsigned long int toto = 0xaabbccdd;
write(fd, &toto, sizeof(toto));Code : Tout sélectionner
unsigned long int toto;
read(fd, &toto, sizeof(toto));
printf("%lu\n", toto);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.destroyedlolo a écrit :.. 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.
.Oui alors non, pas exactement.Bud Spencer a écrit :1 byte = 1 octet = 8 bits
Code : Tout sélectionner
struct dt {
unsigned short int compteur;
unsigned char bas, haut;
};
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.prérequis :
[*] les systèmes utilisent-il le même "boutisme"
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.romaxx a écrit :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.
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)destroyedlolo a écrit :J'ai très bien compris
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.destroyedlolo a écrit : ce que tu veux faire.
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 rommaxdestroyedlolo a écrit :
je ne vois strictement pas l’intérêt de réordonner systématiquement l'ordre de ses octets
)destroyedlolo a écrit : 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 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.Bud Spencer a écrit :Faut essayer. Elle est connectée au cpu comment ta SD ? SPI ? 4 Bits ? Quel Format de fichier ?
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.destroyedlolo a écrit :Ben celle qui te sert a envoyer les données.
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.romaxx a écrit :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 ?
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.Bud Spencer a écrit :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.
Problème qui n'en est plus un du coup : je n'essaie même pas de poursuivre avec la SD !Bud Spencer a écrit :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
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).Bud Spencer a écrit :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.destroyedlolo a écrit : ce que tu veux faire.
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.destroyedlolo a écrit :...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 ...