Communication de port série: interrogation du port série vs utilisation de l'événement DataReceived du port série

Question

Je suis en train de réviser le code que j'ai écrit pour communiquer avec le port série en C # sur CF2.0. Je n'utilise pas l'événement DataReceived car il n'est pas fiable. MSDN indique que:

  

L'événement DataReceived n'est pas   gauranteed être élevé pour chaque octet   reçu. Utilisez la propriété BytesToRead   pour déterminer combien de données est laissée à   être lu dans le tampon.

J'interroge le port avec read () et un délégué traite les données lors de la lecture. J'ai aussi lu quelque part que "les sondages sont mauvais" (aucune explication fournie).

Des idées pour lesquelles les sondages pourraient être mauvais? En plus des précautions d'usage en matière de threading - j'ai un thread séparé (thread d'arrière-plan) qui interroge le port, le thread est quitté après la lecture des données, tout est testé et fonctionne bien.

Answer 1

Comme je l'ai lu, vous pourriez obtenir un événement pour plusieurs octets plutôt qu'un événement par octet. Je m'attendais quand même à obtenir un événement lorsque les données sont prêtes et à ne pas l'avoir "ignorer". quelques octets entièrement.

J'ai toujours utilisé cet événement et je n'ai eu aucun problème avec.

Answer 2

Selon la sagesse classique, "les sondages sont mauvais". car il finit souvent par être un processus lié au processeur. Si vous utilisez plutôt des E / S bloquantes, la CPU est disponible pour d'autres processus jusqu'à ce que l'événement se produise.

Cela dit, il est généralement possible de configurer les choses de sorte qu'un sondage attend un délai (bref) avant de revenir lorsque aucun caractère n'est disponible. Si vous choisissez un délai approprié, votre boucle d'interrogation simple utilise beaucoup moins de temps processeur et d'autres processus s'exécutent également.

Je n'ai pas du tout utilisé les ports série de C #, mais je vais risquer de deviner ce que la documentation voulait dire

  

Il n'est pas garanti que l'événement DataReceived soit déclenché pour chaque octet reçu. Utilisation   la propriété BytesToRead pour déterminer la quantité de données à lire dans la mémoire tampon.

est que vous ne pouvez pas vous attendre à recevoir un événement par personnage. Dans certaines circonstances, il peut arriver que l'événement comporte plus d'un personnage. Récupérez simplement tous les caractères disponibles dans votre gestionnaire d'événements et tout ira bien.

Modifier: Un appel bloquant sur un fil du lecteur peut être la meilleure réponse dans l'ensemble. Ce n'est pas une interrogation en tant que telle car le fil de discussion est bloqué jusqu'à l'arrivée des caractères. Vous devrez peut-être ajuster la taille de la mémoire tampon et certains paramètres du port série si vous devez traiter les données au fur et à mesure de leur arrivée plutôt que par morceaux de taille fixe.

Answer 3

Je suis presque sûr que le code du pilote de port série sous-jacent est déclenché par interruption, même lors de l'utilisation de l'appel bloquant en lecture.