Problème d'envoi de float sous forme d'octet

Comme je l'ai dit, le logiciel attend la valeur en hexa c'est-à-dire 0x0F pour la valeur 15...

Mais 0x0F comme 4 caractères ASCII ou un flux binaire 0000111 sur un octet ?

Hexa tout seul ne veut rien dire.

Excusez-moi j'étais pas précis. Le logiciel attend des valeurs en 4 caractères ASCII. Pour le moment c'est ce qui est prévu :slight_smile:

Comme a dit @hbachetti

LOL... donc vous voulez un float en HEXA en ASCII .. little endian ou big endian ?

Vraiment n'importe quoi :rofl: :thinking: :upside_down_face:

allez allez, du positif... on avance :slight_smile:

Au fait, nous somme trois personnes à travailler sur un projet. En plus de mes taches plus scientifiques, je dois m'occuper de la partie programmation arduino. Cette tâche est presque fini à part cette partie d'envoie des données en octet.
Moi je ne suis pas du tout informaticien et il y a des choses que je découvre grâce à vous et à travers ce projet, donc encore une fois merci pour vos interventions :slight_smile: .
Parmi nous il y a quelqu'un qui s'occupe de la partie traitement de données sur un autre logiciel. Cette personne voulait que je lui envoie des données brutes sous formes d'octet en 4 caractères ASCII mais je n'ai pas plus d'info, c'est pourquoi je semble quelqu'un qui ne sait pas ce qu'il est entrain de faire :slight_smile: . Les choses seront plus claires pour moi après notre prochaine réunion et à partir de ce moment je pourrai donner plus de détailles sur le format exact à envoyer...

Merci pour votre compréhension !

S'il y a plusieurs tensions à transmettre le simple envoi de quatre octets ne suffira pas.
Il va falloir élaborer une trame composée des différentes mesures.
Soit on envoie un paquet de mesures dans un ordre précis, donc le récepteur connaît l'ordre d'envoi.
Soit on envoie un paquet de mesures composé de couples identifiant/valeur, et dans ce cas le récepteur a simplement à connaître les identifiants.
L'intérêt de la deuxième solution est que l'on peut envoyer 1 mesure ou plusieurs, ou la totalité. Par exemple on peut éviter par ce moyen d'envoyer des mesures n'ayant pas changé depuis le dernier envoi.
Dans les deux cas il serait préférable d'envoyer un paquet avec deux indicateurs de début et de fin de paquet (un protocole).

Si les données sont binaires la question de la transparence va se poser. En effet l'octet considéré comme début ou fin de paquet peut très bien faire partie des données, puisque tout est binaire.

Si les données transitent en ASCII ce problème n'existe pas si l'on choisit un octet de début et fin de paquet non imprimable (retour chariot \r et fin de ligne \n par exemple).
D'autre part, tout cela sera certainement plus facile à mettre au point avec des données en ASCII, directement imprimables sur un terminal.

D'après ce que je comprends, comme l'écriture du logiciel récepteur est sous la responsabilité d'une autre personne il ne devrait pas être compliqué de s'entendre sur le format à adopter.

Bonjour victorelec

S'il y a plusieurs données analogiques, pourquoi ne pas utiliser une structure, qui permet d'envoyer, "en bloc" l'entier des mesures et de recevoir "d'un bloc" à l'autre bout,
Cette structure pourrait même être hétéroclite, c'est à dire contenir des float,, integer, boolean etc.


struct donneesMesureesDef
{float voltageA; float voltageB; float voltageC;};
donneesMesureesDef donneesAtransmettre;

void setup()
{
	Serial.begin(115200);
	
	donneesAtransmettre.voltageA = 12.25;
	donneesAtransmettre.voltageB = 7.00;
	donneesAtransmettre.voltageC = 9.33;

	Serial.write((byte *)&donneesAtransmettre, sizeof donneesAtransmettre); 
}

void loop()
{
}

La réception pourrait être

	Serial.readBytes((byte*)&donneesAtransmettre, sizeof donneesAtransmettre);

Je n'ai pas essayé en vrai, ni en port série,, mais j'utilise cette technique, couramment en i2C.

Cordialement
jpbbricole

Oui effectivement, c'est ce que j'ai constaté lorsque je visualisais les données sur CoolTerm. Pour un seul float ça marche, le résultat est bon mais quand je veux envoyer plusieurs en même temps cela ne fonctionne pas. Juste un float parmi les 6 est correctement envoyé. J'essaie de réfléchir à ça :slight_smile:


Il n'y a aucun problème pour envoyer 6 float. Le seul problème est de les différencier en réception.

Bonjour

Si tu les envoies dans une structure et les reçoit dans une même structure, comme indiqué ici, pas de problème.

Cordialement
jpbbricole

Je répondais simplement à victorelec qui disait que l'envoi d'un float fonctionnait, mais pas l'envoi de plusieurs.
Pas de problème avec l'envoi de structures. C'est souvent utilisé, on peut même, ajouter un crc dans la structure. Le seul petit problème qui peut se poser en deux systèmes différents est la taille et l'alignement des champs, mais ça se règle avec les options de compilation.

J'ai bien en compte de ta solution et je compte la tester dès que possible :slight_smile:

On y verrait certainement plus clair si victorelec voulait se donner la peine de préciser certaines choses :

  • le récepteur : quelle plateforme, quel langage ?
  • fréquence des transmissions

A noter : même en PYTHON, la réception d'une structure C serait envisageable :
https://docs.python.org/3/library/struct.html

On continue à tourner en rond ...

Ici on n'a pas besoin de préciser quelle donnée on va envoyer ?
En plus, il faut que je mette d'accord avec la personne qui reçoit les données si l'utilisation d'une structure la convient :slight_smile:

Bonjour kamill

Oupsss, j'avais "Quoté" le mauvais texte !

Cordialement
jpbbricole

Bonjour victorelec

C'est fait, vu que tes données, voltageA, voltageB, voltageC, sont dans la structure donneesAtransmettre, comme définie dans mon exemple.
Si tu lis ces données, au récepteur, dans une structure identique, tu n'as aucun souci quand à l'ordre
Edit: il suffit de copier ceci

struct donneesMesureesDef
{float voltageA; float voltageB; float voltageC;};
donneesMesureesDef donneesAtransmettre;

dans le programme du récepteur.

Cordialement
jpbbricole.

Quand on commence à envoyer plusieurs octets il vaut mieux prévoir un protocole sinon on ne peut pas synchroniser l’émetteur et le récepteur et si un octet vient à être raté ensuite toute la communication est décalée