Les schémas de requête/réponse ont tendance à être inefficaces et apparaissent rapidement sur le port série. Si vous êtes intéressé par le débit, regardez le protocole fenêtré, comme le protocole d'envoi de fichiers kermit.
Maintenant, si vous voulez vous en tenir à votre protocole et réduire la latence, sélectionner, interroger, lire vous donnera à peu près la même latence, car comme Andy Ross l'a indiqué, la vraie latence réside dans la gestion matérielle FIFO.
Si vous avez de la chance, vous pouvez modifier le comportement du pilote sans patcher, mais vous devez toujours consulter le code du pilote. Cependant, le fait que l'ARM gère un taux d'interruption de 10 kHz ne sera certainement pas bon pour les performances globales du système...
Une autre option consiste à remplir votre paquet afin d'atteindre le seuil FIFO à chaque fois. Il confirmera également s'il s'agit ou non d'un problème de seuil FIFO.
10 msec @ 115200 est suffisant pour transmettre 100 octets (en supposant 8N1), donc ce que vous voyez est probablement dû au low_latency l'indicateur n'est pas défini. Essayez
setserial /dev/<tty_name> low_latency
Il définira l'indicateur low_latency, qui est utilisé par le noyau lors du déplacement des données vers le haut dans la couche tty :
void tty_flip_buffer_push(struct tty_struct *tty)
{
unsigned long flags;
spin_lock_irqsave(&tty->buf.lock, flags);
if (tty->buf.tail != NULL)
tty->buf.tail->commit = tty->buf.tail->used;
spin_unlock_irqrestore(&tty->buf.lock, flags);
if (tty->low_latency)
flush_to_ldisc(&tty->buf.work);
else
schedule_work(&tty->buf.work);
}
Le schedule_work appel pourrait être responsable de la latence de 10 ms que vous observez.
Les ports série sous Linux sont "enveloppés" dans des constructions de terminaux de style Unix, ce qui vous frappe avec un décalage de 1 tick, c'est-à-dire 10 ms. Essayez si stty -F /dev/ttySx raw low_latency aide, mais aucune garantie.
Sur un PC, vous pouvez aller de l'avant et parler directement aux ports série standard, émettez setserial /dev/ttySx uart none pour dissocier le pilote Linux du port série hw et contrôler le port via inb/outb aux registres des ports. J'ai essayé ça, ça marche très bien.
L'inconvénient est que vous ne recevez pas d'interruptions lorsque les données arrivent et que vous devez interroger le registre. souvent.
Vous devriez pouvoir faire la même chose du côté de l'appareil bras, peut-être beaucoup plus difficile sur le port série exotique hw.
Après avoir parlé à d'autres ingénieurs sur le sujet, je suis arrivé à la conclusion que ce problème ne peut pas être résolu dans l'espace utilisateur. Puisque nous devons traverser le pont vers le noyau, nous prévoyons d'implémenter un module noyau qui parle de notre protocole et nous donne des latences <1ms.
--- modifier ---
Il s'avère que j'avais complètement tort. Tout ce qui était nécessaire était d'augmenter le taux de tic du noyau. Les 100 ticks par défaut ont ajouté le délai de 10 ms. 1 000 Hz et une valeur agréable négative pour le processus série me donnent le comportement temporel que je voulais atteindre.
Voici ce que setserial fait pour définir une faible latence sur un descripteur de fichier d'un port :
ioctl(fd, TIOCGSERIAL, &serial);
serial.flags |= ASYNC_LOW_LATENCY;
ioctl(fd, TIOCSSERIAL, &serial);