Blocage Linux et lecture non bloquante en série

Le code que vous mentionnez est de l'OMI mal codé et commenté. Ce code n'est pas conforme à POSIX pratiques pour la portabilité, comme décrit dans Réglage Des Modes De Terminal Server Correctement et Série Guide de Programmation POSIX Systèmes d'Exploitation. Que le code ne mentionne pas qu'il utilise non-canonique (aka raw) mode, et réutilise le "blocage" et "non bloquant" terminologie pour décrire les VMIN et VTIME attributs.

À la définition traditionnelle d'un "blocage" versus "non bloquant" lire est basée sur "le lors de" l'appel read revenez à votre programme (et de reprendre l'exécution à l'instruction suivante) et si il y aura des données stockées dans votre programme de lecture de la mémoire tampon. Un blocage de la lecture est le mode par défaut, à moins que non bloquant est demandé par l'ouverture du port série avec le O_NONBLOCK ou O_NDELAY option.

Mode canonique

Pour un blocage canonique lire appel d'un port série, une ligne (aka record) du texte est toujours renvoyée dans la mémoire tampon (à moins qu'une erreur s'est produite). La lecture appel de bloc (c'est à dire, suspendre l'exécution de votre programme) aussi longtemps qu'il le prend pour une ligne de caractère de fin pour être reçue et traitée.

Un non bloquantes canonique lire l'appel d'un port série reviendra toujours "immédiatement". La lecture peut ou peut ne pas renvoyer des données.

Si (depuis la dernière lecture d'appel) d'au moins une ligne de texte a été reçu et enregistré dans la mémoire tampon du système, alors le plus ancien sera supprimé de la mémoire tampon du système et copié dans la mémoire tampon. Le code de retour indique la longueur des données.

Si (depuis la dernière lecture d'appel) une ligne de caractère de fin n'a pas été reçues et traitées, il n'existe pas (complète) de la ligne de texte disponible. Le read() renverra une erreur EAGAIN (c'est à dire un -1 code de retour et errno ensemble de EAGAIN). Votre programme peut ensuite effectuer certains calculs, ou de demande d'e/S à partir d'un autre appareil, ou de retard de sommeil. Après l'arbitraire d'un retard ou par notification par poll() ou select(), votre programme peut réessayer la read().

Non-canonique,

Lorsque le port série est configuré pour les non-canonique mode, la termios c_cc les éléments du tableau VMIN et VTIME doit être utilisé pour le contrôle de "blocage", mais cela nécessite que le port soit ouvert par défaut dans le mode de blocage, c'est à dire ne pas spécifier le O_NONBLOCK option ouvrir. Sinon O_NONBLOCK aura préséance sur le VMIN et VTIME spécification, et read() sera mis errno à EAGAIN, et de revenir -1 au lieu de 0 lorsqu'il n'y a pas de données disponibles. (C'est le comportement observé au cours des dernières Linux 3.x noyaux; les plus âgés 2.6.x noyaux peuvent se comporter différemment.)

La structure de la page de manuel décrit (c_cc index de tableau) VMIN comme le "nombre minimal de caractères non canoniques de lire"et (c_cc index de tableau) VTIME comme le "délai d'attente en dixièmes de s. non canoniques de lire".

VMIN doit être ajustée par votre programme pour accueillir le message typique ou datagramme longueur qui est attendu et/ou la taille minimale de données à récupérer & processus par read().

VTIME doit être ajustée par votre programme de s'adapter au sporadicité ou taux d'arrivée de la série de données qui est attendu et/ou la durée maximale d'attente de données ou un système de référence géodésique.

La VMIN et VTIME valeurs interagissent pour déterminer le critère d'lors de la lecture doit retourner; leur une signification précise, qui dépendent d'entre eux sont non nuls. Il y a quatre cas possibles.

Cette page web explique que:

• VMIN = 0 et VTIME = 0

  C'est complètement non-blocage de la lecture de l'appel est convaincue immédiatement et directement depuis le siège du conducteur d'entrée de la file d'attente. Si les données sont disponibles, il est transféré à l'appelant en mémoire tampon jusqu'à nbytes et retourné. Sinon zéro est immédiatement retourné pour indiquer "pas de données". On notera que c'est "bureaux" du port série, et c'est presque toujours une mauvaise idée. Si fait à plusieurs reprises, il peut consommer d'énormes quantités de temps processeur et est très inefficace. N'utilisez pas ce mode, sauf si vous avez vraiment, vraiment savoir ce que vous faites.

• VMIN = 0 et VTIME > 0

  C'est un pur cadencée à lire. Si les données sont disponibles dans la file d'attente d'entrée, il est transféré à l'appelant en mémoire tampon jusqu'à un maximum de nbytes, et immédiatement renvoyé à l'appelant. Sinon, le pilote se bloque jusqu'à ce que les données arrivent, ou lorsque VTIME dixièmes à expiration depuis le début de l'appel. Si le délai expire sans données, zéro est renvoyée. Un seul octet est suffisant pour satisfaire à cette lecture appel, mais si plus d'informations sont disponibles dans l'entrée de la file d'attente, il est retourné à l'appelant. Notez que ceci est un ensemble de minuterie, pas un intercharacter.

• VMIN > 0 et VTIME > 0

  Un read() est satisfaite lorsque la valeur VMIN personnages ont été transférés à l'appelant de la mémoire tampon, ou lorsque VTIME dixièmes expirent entre les personnages. Depuis ce minuteur est pas commencé jusqu'à ce que le premier caractère arrive, cet appel peut bloquer indéfiniment si le numéro de série en ligne est inactive. C'est la plus commune mode de fonctionnement, et nous considérons VTIME être un intercharacter délai d'attente, pas un ensemble. Cet appel ne devrait jamais retourner zéro octets lus.

(Dans mon expérience, la VMIN>0 and VTIME>0 mode ne fonctionne pas comme annoncé. La minuterie semble être un intervalle très court, beaucoup moins que d'un 1/10e de seconde. Je n'ai pas vu à l'oeuvre sur les BRAS avec la 2.6, et Linux 3.13 sur x86. Rapides à une vitesse de transmission en bauds (115200), avec VMIN=1 et VTIME=1, read() retourne parfois plus de 10 octets. Mais le plus souvent c'est juste une lecture partielle de quelques octets, indépendamment de la VTIME valeur. Peut-être que cette brisure est préféré/désiré? Un minimum de 0.1 sec message séparation est tout simplement trop long (et pas pratique) au moderne, rapide baudrates.)

• VMIN > 0 et VTIME = 0
  

  C'est un comptés lire qui n'est satisfaite que lorsque au moins VMIN personnages ont été transférés à l'appelant tampon - il n'y a pas de synchronisation des éléments concernés. Cette lecture peut être satisfait de la part du conducteur d'entrée de la file d'attente (où l'appel peut renvoyer immédiatement), et en attendant que de nouvelles données arrivent: à cet égard, l'appel peut bloquer indéfiniment. Nous croyons que c'est un comportement indéfini si nbytes est inférieure à la valeur VMIN.

Que le code que vous mentionnez configure "non bloquant" mode VMIN=0 et VTIME=5. Cela ne provoque pas la lecture() pour retourner immédiatement comme un non bloquantes canonique lire: avec ce code un read() doit toujours attendre au moins une demi-seconde avant de revenir. La définition conventionnelle d'un "non bloquant", c'est que votre programme appelant n'est pas interrompu pendant le syscall et reprend le contrôle (presque) immédiatement.
Pour obtenir un (inconditionnel et immédiat-retour (pour un non-canonique de lire), définissez la valeur VMIN=0 et VTIME=0.