Si je le met à 10 millis, je risque de ne pas avoir le temps de lire toute une donnés si dans l'avenir elles devenait plus grande ? C'est pour cela que tu ne trouve pas génial cette solution ?
En fait c'est plus pour la raison qu'évoque trimarco232, si l'OS émetteur décide de faire une pause >10 ms au milieu du message ce que lira l'arduino sera incomplet. A l'inverse, si tu augmentes la cadence coté émetteur (C#) qu'est ce qui te garanti que l'OS ne décidera pas de fusionner 2 messages en 1, te faisant perdre du coup un couple de valeur du coté arduino. Enfin, dernier problème du setTimeout (pour ce soir ;-)), c'est qu'il n'est pas optimal (ici il te fait perdre 10 ms à la fin de chaque message). Bref, cette histoire de timeout est bancale de tous les cotés.
Comme trimarco232 je soigne mes protocoles mais d'une autre façon (classique sous *nix) :
Je n'émets et ne reçois que des lignes (chaînes terminées par le caractère '\n').
- Du coté émetteur un printf('\n') ou println() ou équivalent.
- Du coté récepteur un fgets() ou Serial.readStringUntil()('\n') ou équivalent.
Et c'est seulement après que je décode la ligne coté récepteur (avec sscanf pour chaînes C, toInt, toFlot, ... pour les String C++).
Sinon, je sais que sous un OS digne de ce nom, quand une application se termine, elle ferme ses fichiers toute seule comme une grande 