Serial.Write - comment éviter l'overflow du buffer ?

International Français
1

Bonjour,

Si j'ai bien compris, "Serial.Write" remplit un buffer qui envoi les caractères grâce à des interruptions, afin de ne pas "bloquer" le code... j'ai bon ?

Dans ce cas, comment connaitre le niveau de remplissage du buffer afin d'éviter l'overflow ?

2

Salut,

Connaitre le niveau comme ça je sais pas, j'imagine qu'il y a un registre qui doit pouvoir renvoyer ça.

Sinon il y a une technique simple : n'envoyer que des paquets de 64 byte (taille par défaut du buffer si ma mémoire est bonne) et attendre l'envoi complet par Serial.flush() avant d'en renvoyer un autre. Après c'est sûr flush() 'est bloquant ... Mais bon 64 bytes ça prend pas 10 ans à envoyer

EDIT : ici un bout de code interessant [solved] How do I detect when TRANSMIT (TX) buffer is full (or empty)? - Programming Questions - Arduino Forum

3

Avant d'ajouter un flush il faudrait que j'arrive à estimer les différentes "fréquences" qui composent mon code...

La MPU6050 tourne à 100Hz, donc je j'ai des données fraîches à lire 100 fois par seconde...
Et quand j'ai ces données, j'envoi 6 octets à 31250 bauds, ce qui prend environ 1,92ms ?

Donc il faut just que la durée d'envoi des données sur le port série soit cohérente avec la fréquence de d'arrivée des données du MPU...

4

Bon d'après les chiffres de mon post précédent, j'en déduis que je m'inquiète pour rien... vous confirmez ?

5

31250/( 6*8 ) => 651 hz pour tes émissions donc logiquement t'es dans les clous

6

Merci B@ttao,

Ma fréquence calculée était un peu plus faible car j'avais compté 10 bits par Byte (START/STOP).

Je pense que je vais mettre en place un "monitoring" avec la LED de l'Ardunio :

  • Je l'allume en début de LOOP quand je rentre dans un cycle de mise à jour des données
  • Je l'éteint en début de LOOP quand il n'y a pas de données à jour.

Au vu de fréquence "rapide" de LOOP je ne devrait pas la voir clignoter, c'est plutôt son intensité d'allumage qui doit me servir.

Si elle est parait allumée à fond tout le temps, je m'inquiète.
Ça te parait suffisant ?

7

En effet 10 bits c'est plus correct .. trop fait d'i2c ce week end ...

Sinon bof tu vas pas voir grand chose je pense

8

En fait je pense que l'overflow n'est pas possible.
La fonction write est bloquante en cas de saturation du buffer.
Ce qui pose un autre problème. En cas de saturation l'exécution du programme ne se déroule plus comme prévu.

code tiré de la lib HardwareSerial

size_t HardwareSerial::write(uint8_t c)
{
  int i = (_tx_buffer->head + 1) % SERIAL_BUFFER_SIZE;
	
  // If the output buffer is full, there's nothing for it other than to 
  // wait for the interrupt handler to empty it a bit
  // ???: return 0 here instead?
  while (i == _tx_buffer->tail)                        <==== ici on reste bloqué si le buffer est plein
    ;
	
  _tx_buffer->buffer[_tx_buffer->head] = c;
  _tx_buffer->head = i;
	
  sbi(*_ucsrb, _udrie);
  // clear the TXC bit -- "can be cleared by writing a one to its bit location"
  transmitting = true;
  sbi(*_ucsra, TXC0);
  
  return 1;
}
9

Bien vu !

10

Merci pour l'info fdufnews !
Moi ça me va comme fonctionnement : Serial.Write devient bloquant quand le buffer est plein.

Ya pas une idée simple à mettre en place pour se servir de la LED comme indicateur de "charge CPU" ?