Bonjour à tous !
 
Dans le cadre de mon travail, je dois communiquer
avec une pièce (une sonde) dont la mémoire est agencée
selon la typologie Little Endian.
 
Ma question est la suivante :  
 
Si je veux écrire dans la mémoire de cette pièce, dois-je
envoyer les octets sous leur forme Big Endian ou Little  
Endian ?
 
Je me dis que si je les envoies en Big Endian, c'est elle qui les agencera
dans sa mémoire comme elle le veut. Mais je me trompe peut être ?
 
Merci à tous !

Personne n'a de réponse ?

Encore un petit up...  
Peut être que vous n'avez pas compris ce que je demande. Si c'est le cas, dites le moi.

Si tu communiques directement avec la sonde, ca doit être documenté dans le protocole. Si tu écris directement dans sa mémoire, je dirais qu'il faut le mettre dans son format, donc little-endian

Ben justement, non, y'a pas de protocole...
 
Ce serait trop facile sinon ! ^^

aprés verification,little endian est le format des octets des processeurs intel x86 et big endian celui des motorola
donc si la sonde est branché a une carte pci,tu dois avoir un driver pour communiquer avec elle
et si c'est par port parallele ou usb,il te faut developpé un utilitaire en c ou autres pour communiquer avec cette sonde

Merci pour vos réponses.
Je communique avec la sonde via un bus CAN. Autant dire que c'est à moi de gérer ce "petit" problème de communication...

Il y a forcément un protocole documenté ou un pilote, et généralement les 2.
 
Pour avoir moi-même piloté des débimètres et compagnie par bus RS485, les protocoles étaient parfaitement documentés par les fabricants (la disquette du pilote ayant refait surface seulement à 1 semaine de la fin de mon stage, tout avait été réécrit)

Le truc, c'est que le fabriquant, c'est ma société...
Donc, niveau protocole, tout circule de vive voix et c'est pas toujours évident...

 
un petit site a propos du bus CAN  http://www.oberle.org/can-can.html

C'est pas super parlant chibba ça
 
La partie dont il est question ici semble être la couche "application", précisée "à définir par l'utilisateur", ce qui ne fait guère avancer le schmilblik
 
Après, si justement il est question de développer cette couche application ("pilote" interne à la sonde), c'est plus utile.

 
le bus CAN est un protocole reseau et tu n'as pas besoin de pilote pour la sonde
il faut par contre connaitre la programmation des microcontrollers

Ah bon, donc la couche "application", autrement dit le protocole de communication, ça sert à rien?
 
Car à ce petit jeu, l'ethernet est aussi un protocole réseau, et pourtant les TCP/IP et UDP sont quand même bien pratiques quand on veut communiquer avec...  
 
 
Là il faudrait des précisions sur ce que Sancha développe: le firmware de la sonde (son "pilote interne", donc), ou une appli qui doit communiquer avec et tournant sur un PC ou autre système maître ou superviseur.
 
Si c'est le premier cas, savoir la topologie mémoire est important, si c'est le 2e ça dépend du fameux protocole de communication.

 
le protocole est peut etre integré au firmware du microcontroller
 

 
Comment la sonde peut-elle savoir dans quel format on va lui envoyer les données ? Elle ne peut pas deviner en recevant une succession de bits qui arrivent par une liaison série (le CAN) comment réorganiser ce flux en bit en octet et en mots de 32 bits. Les poids forts d'abord, ou les poids faibles ? Little or Big Endian ? Tous les '0' et les '1' se ressemblent...
 
IL y a 2 possibilités:
1.  c'est précisé dans la définition du protocole. Par ex., pour le CAN, les poids forts sont toujours transmis en premier.
2. c'est défini dans le message lui-même qui contient aussi  les données, souvent dans un entête au début. Pour le CAN, c'est le champ 'control field'.
 
'Control field ' contient le nombre d'octets transmis , plus 2 bits non définis pour l'instant et réservés pour des usages futurs.
Comme le format big endian/little endian ne fait pas partie de ce champ de controle, j'en déduis qu'il faut fournir les données à la sonde dans son format naturel qui est little endian.

Merci à tous pour vos réponses !
 
Ma question de départ était :  
"Je me dis que si je les envoies en Big Endian, c'est elle qui les agencera  
dans sa mémoire comme elle le veut. Mais je me trompe peut être ? "
 
Mais, je pense que je peux la reformuler pour que vous puissiez mieux comprendre...
 
En fait, je me demande si l'endianisme n'est pas seulement la résultante du sens de lecture de la mémoire de la sonde.
 
En gros, je me dis : peut être que dans la mémoire interne de la sonde, les données sont agencées comme un Big Endian mais, que c'est la sonde qui lit sa mémoire dans le sens inverse (dans le cas d'un little endian) et qui donc interprète différemment le sens des octets...  
 
Par exemple, à l'adresse 0x495, j'écris 0x27.
A l'adresse 0x496, j'écris 0x10.  
0x2710 fait 10000 en décimal.
 
Mais, si la pièce lit sa mémoire en partant du bas, elle comprendra 0x1027...
 
Donc, dans la logique, je devrais écrire 0x10 à l'adresse 0x495 et 0x27 à l'adresse 0x496 pour qu'elle comprenne 0x2710.
 
Mais je me dis, en lui envoyant 0x2710, étant donné qu'e la sonde lit (peut être) sa mémoire en sens inverse, peut être qu'elle écrit aussi en sens inverse. Et donc, peut être qu'elle mettra 0x27 en 0x496 (la première adresse qu'elle lit) et 0x10 à l'adresse 0x495.  
Du coup, là, les octets sont aussi dans le bon ordre quand la pièce relit sa mémoire...
 
J'espère que vous avez réussi à ma suivre !! ^^

Ca nous renvoie aux 2 questions déjà posées:
 
- qu'est-ce que tu développes? (visiblement un superviseur)
- où est ce foutu protocole de communication, sans lequel tu ne peux rien faire? (que ça soit interne à la société n'a rien à voir là-dedans, quand on conçoit quelque chose, on le documente un minimum... et le protocole de communication c'est une petite partie de ce minimum)

La règle générale c'est de toujours considérer les adresses croissantes à partir de 0.  
Pour des mots de 16 bits, on considère des paires d'adresses N, N+1 (avec N pair). Ensuite c'est le choix du protocole little/big-endian qui va dire ou est l'octer de poids fort et lou est l'octet de poids faible.
 
L'exemple avec les adresses 0x495 et 0x496 ne semble pas bien choisi. 0x494 et 0x495 font partie du même mot de 16 bits, et 0x496/0x497 d'un autre mot.
 
Dans tous les cas, cette sonde doit bien interpréter les données dans sa mémoire et en faire quelquechose qui doit se voir ou se mesurer. En essayant les différents cas possibles, ça doit être possible de confirmer quel est le bon scénario.

le compilateur du langage qui est utilisé pour le developpement de ton application s'occupera de tout ordonné  comme il faut;
tu n'as pas a te preoccupé de savoir s'il faut envoyé du big endien ou little endian,et en plus le bus CAN est un bus serie et il est integré a un microcontrolleur qui gereras la disposition des données.
a moins de programmé en langage machine ,je ne comprend pas du tout ton probleme.
ce n'est pas la memoire qui est big endian ou little endian,c'est le microcontroleur(dans ton cas,c'est un microcontrolleur 16bits), et pour ecrire dans la memoire,tu es obligé de passer par celui çi

Et voilà ! Les informations ont enfin circulé dans ma société et je connais le fin mot de l'histoire !
Cette fameuse sonde s'écrit en Big Endian mais se lit en Little Endian !!!
 
Non, non, ce n'est pas une blague... Pourquoi faire simple quand on peut faire compliquer ?!!
 
En tous cas, merci à tous !

 
donc le microcontroller est big endian et la memoire est toujours little endian (la memoire big endian n'existe pas)

D'accord, c'est noté.
 
Encore merci à vous tous !
 
Dernière petite question : comment fait-on pour mettre le sujet en résolu ? Oui, je sais, je suis un peu chiante ! ^^ Je suis nouvelle sur ce forum...  Alors, soyez indulgent.

Ca me semble tellement illogique que je crois que t'as pas fini d'en baver...

Entièrement d'accord avec toi !!!
 
Merci de compatir... Je suis pas sortie de l'auberge avec toute cette merde...

 
renseigne toi sur le microcontroller qui pilote la sonde,ainsi tu pourras te documenté sur le net sur sa programmation