Serial et unsigned long

International Français
1

Bonsoir,

j'ai besoin de communiquer entre un arduino nano et un programme sur ordi (écrit en lazarus/pascal) par le port USB.

Je souhaite récupérer, côté PC, un unsigned long (c'est un t = millis() déclenché par un capteur)

Si j'utilise :

void loop() {
    if (envoi) {
        Serial.println(t-tzero);
        serial_t = false;
    }
}

j'arrive à mes fins.

Sauf que je trouve ça un peu goret comme manière de faire. Si j'ai bien compris, println envoie du texte, texte que je peux certes récupérer par le programme lazarus et retransformer en entier.

Par ma méthode, si je transmet la valeur 4 215 151 664 c'est 10 octets plus la fin de ligne qui est envoyé alors que pour un unsigned long, 4 suffiraient ! Et je suppose que du traitement inutile peut-être économisé...

Y a-t-il une méthode plus radine en ressources et plus propre ?

2

bonsoir,
plutôt que Serial.print[ln] tu devrais utiliser les fonctions hardware de l'UART intégré au µC dont tu disposes : la seule contrainte est d'envoyer ta donnée octet par octet.

3

Envois tes données en binaires

4

Donc faire dans un premier temps un découpage en 4 octets ? Bon, je vais me plonger dans la manipulation de bits :roll_eyes:

5

Ça ressemble à ça ? :

  val = t-tzero;
  byte octets[4];
  octets[0] = val & 255;
  octets[1] = (val >> 8)  & 255;
  octets[2] = (val >> 16) & 255;
  octets[3] = (val >> 24) & 255;
6

salut @ProfesseurMephisto

non, finalement, comme suggéré par @terwal, il semblerait qu'Arduino ait prévu la possibilité d'envoyer, grâce à la fonction Serial.write, une valeur sous forme binaire.

les décalages d'octets et l'utilisation des fonctions hardware du µC n'existent finalement plus que pour que je m'amuse tout seul dans mon coin... mais au moins je vais plus vite qu'Arduino avec mes manipulations de registres !
bye

7

Tu veux dire que Serial.write(t-tzero); devrait passer directement ?

8

oui, ça peut être une façon de faire.
ensuite il faut configurer l'UART et le nourrir.

mais comme écrit plus haut, Serial.write est peut-être une solution plus accessible, si tu ne maîtrises pas encore les fonctions (et donc la doc) de l'ATMega328.

EDIT :
ARRGH ! nos réponses se croisent !

9

je n'ai jamais utilisé l'IDE Arduino, je ne connais donc pas Serial.write, mais à la lecture du "mode d'emploi" j'en déduis que c'est la solution simple dont tu as besoin.
personnellement, je code sur AtmelStudio et effectue des écritures directes dans les registres ;
je pense que Serial.write fait la même chose que moi : découpage en octets et écriture dans les registres UDRn du µC.

10

Oui, tu fais un Serial.write avec ton entier, il va t'écrire les octets correspondant sur ton port série.
Par contre il faudra que tu lise le port série en binaire aussi du coté du PC.

11

Bonjour,

Ceci ne va envoyer qu'un octet.
Il faudrait faire
unsigned long duree=t-tzero;
Serial.write((uint8_t *)&duree, sizeof duree);

Pour la réception il faut lire 4 octets, par exemple avec Serial.readBytes()

Le problème de transmettre en binaire est que l'émetteur et le récepteur peuvent se désynchroniser avec le risque de ne plus pouvoir se resynchroniser si la fréquence de transmission est trop rapide.

12

parce qu'utiliser Serial.print (qui envoie du texte formaté) résout le problème de la vitesse de transmission ?

13

Parce que une transmission ascii permet d'utiliser un terminateur (par exemple \n) qui permet de resynchroniser la transmission. Encore mieux avec un caractère de début et un caractère de fin.

14

Ba tu ne te synchronise qu'a moitié, ce qui est perdue est perdue.

Si la fréquence est trop rapide, tu as aussi le risque d'avoir ton tampon plein et de ne pas recevoir le \n ?
Alors certes, Dans un système de question/réponse tu peux espérer pouvoir reprendre le fil si la question suivante est suffisamment courte pour ne pas remplir le tampon, tampon qui aura était vidé entre temps.

15

Peut-être mais tôt ou tard tu auras un autre \n et tu pourras te resynchroniser.
Alors que si la liaison est purement binaire tu ne sauras pas identifier un début de "trame" sauf à mettre en place un protocole relativement élaboré

16

Ba oui et non, tu aura un \n uniquement si celui-ci est inclus dans un message plus court que ton tampon.

En l'occurrence, c'est plutôt un fin de trame qui te fait sortir de l'attente de donnée.
En binaire cet fin de trame est la taille que tu attends, donc soit fini en dure, soit envoyé en début de la première trame.

Mais je suis bien d'accord que ça parait plus simple en ASCII.

17

bonjour,

@terwal : la taille du tampon ne dépend que de toi et de ta programmation.

@fdufnews , @kamill : je n'envisage même pas un transfert sans protocole, mais si vous préférez accuser des pertes de temps en conversions multiples c'est votre problème.
communiquer avec des valeurs brutes est pour moi plus efficace que des conversions valeur <==> texte.

18

Qu'est ce que tu racontes là?
Je n'ai pris partie ni pour l'un ni pour l'autre, mais j'ai simplement répondu au topic de @ProfesseurMephisto.

Non ça dépend aussi de la mémoire disponible surtout sur un microcontrôleur.

19

@kamill

la question de départ était : comment envoyer/recevoir une valeur brute (et non formatée) ?

j'ai répondu, @Terwal a répondu.
point, barre.

20

Comment ça?
Je suis du même avis que @kamill

Tu confond deux choses, autant je suis d'accord avec toi sur un transfert sans protocole n'a pas de sens.
Par contre si tu envois à 115k et reçois à 9k, le temps gagné à ne pas convertir ne changera pas vraiment grand chose?
Par contre comment calcule tu l'efficacité, cela est vraiment important uniquement si c'est vitale?
Après c'est une histoire de préférence, je serais plutôt comme toi à utiliser la vrai valeur, plutôt qu'une conversion qui est toujours source potentiel d'ennuis.