要求/応答スキームは非効率になる傾向があり、シリアル ポートですぐに表示されます。スループットに関心がある場合は、kermit ファイル送信プロトコルなどのウィンドウ化されたプロトコルを調べてください。
Andy Ross が指摘したように、実際のレイテンシはハードウェア FIFO 処理にあるため、プロトコルに固執してレイテンシを短縮したい場合は、select、poll、read のすべてでほぼ同じレイテンシが得られます。
運が良ければ、パッチを適用せずにドライバーの動作を微調整できますが、それでもドライバー コードを確認する必要があります。ただし、ARM で 10 kHz の割り込みレートを処理することは、システム全体のパフォーマンスにとって確実に良くありません...
もう 1 つのオプションは、毎回 FIFO しきい値に達するようにパケットをパディングすることです。また、FIFO しきい値の問題であるかどうかも確認します。
10 ミリ秒 @ 115200 は 100 バイトを送信するのに十分です (8N1 を想定)。 フラグが設定されていません。試す
setserial /dev/<tty_name> low_latency
これは、データを tty 層に移動するときにカーネルによって使用される low_latency フラグを設定します:
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);
}
18 この呼び出しは、観察された 10 ミリ秒の遅延の原因である可能性があります。
Linux のシリアル ポートは unix スタイルの端末構造に「ラップ」されているため、1 ティック ラグ、つまり 10 ミリ秒が発生します。 20 なら試してみてください 役に立ちますが、保証はありません。
PC では、ハードコアになり、標準のシリアル ポートと直接通信できます。32 を発行します。 シリアル ポート hw から Linux ドライバーのバインドを解除し、49 経由でポートを制御します。 ポートレジスターへ。試してみましたが、うまくいきました。
欠点は、データが到着したときに割り込みが発生せず、レジスタをポーリングする必要があることです。
アーム デバイス側でも同じことができるはずですが、エキゾチックなシリアル ポート ハードウェアではもっと難しいかもしれません。
このトピックについてさらに何人かのエンジニアと話し合った結果、この問題はユーザー空間では解決できないという結論に達しました。ブリッジを渡ってカーネル ランドに入る必要があるため、プロトコルと通信して 1 ミリ秒未満のレイテンシを実現するカーネル モジュールを実装する予定です。
--- 編集 ---
私は完全に間違っていたことがわかりました。必要なのは、カーネルのティック レートを上げることだけでした。デフォルトの 100 ティックには 10 ミリ秒の遅延が追加されました。 1000Hz とシリアル プロセスの負のナイス値により、到達したい時間動作が得られます。
これが 59 です ポートのファイル記述子に低レイテンシーを設定するには:
ioctl(fd, TIOCGSERIAL, &serial);
serial.flags |= ASYNC_LOW_LATENCY;
ioctl(fd, TIOCSSERIAL, &serial);