Armadilloフォーラム

> Armadillo610上に以下の環境を配置しています。
> ・ABOS 3.19.1-at.4
> ・コンテナ内OS Debian GNU/Linux 11 (bullseye)
>
> コンテナ内のアプリより、ioctlにて連続的にSPI通信を実施しています。
> 通信自体は成功しているのですが、ABOS内の他のプロセスが原因でSPIドライバの処理時間が揺れます。
>
> 1ms以上ioctlの処理を停止（または中断）する可能性のある周期的なプロセスをご教示いただけないでしょうか。

niceを最低にして実行してみたら、改善しますか？
(nice -n -20 myappのように起動します。niceの最低値は-20ですが
この値はシステム全体にとってCPUを使わずにniceであるかどうか、
なので最低の-20にすると優先して使うということです)

もし改善するなら、それはプロセススケジューラーそのものによる遅れで、
Linuxを使う限り逃れることはできません。
ioctlを含むシステムコールは、そのシステムコールを呼んでいる
プロセスコンテキストで動くため、当然ですがCPUがそのプロセス
(=そのioctlを呼んでるアプリ)の実行に切り替わる必要があります。

一方、LinuxはRTOSではないので、プロセスのスケジュール周期を
保証できないため、単一のコアしかないA610では尚更他のプロセスが
動くタイミングの変動があれば、時間は一定しません。
(例えば、ボード全体で同じような処理しかしていなくても、あるときに
Etherパケットの到達が有って割り込みが起きたり、ファイルシステムの
バッファが容量や時間要因でフラッシュされたりすると、あるプロセスに
回ってくるタイミングがズレます)

なので、支配的な単独の要因があるわけではないです。
(というより、マルチタスクOSであるということが原因です。)

解決方法としては100%ジッタ無しを保証したい場合は、
デバイスドライバを書いてkernelモードでタイマ割り込みを掛けて
割り込み禁止状態で(A610はシングルコアなのでkernelとしての
すべての機能を止めて)データを読む実装にするという方法がありますが、
これは当然ですが他のkernel内部の”時間を守らないといけないハードウェア
I/F等の時間制約”を破壊する可能性があります。
とくにシングルコアのCPUを搭載したA610の上では、慎重なテストと
よく理解した実装が必要になりますし、処理時間によっては
OSとしての機能が破綻するため実装できない場合もあります。

２つ目に、100%ジッタ無しでもいいのである程度周期を優先したい場合は
前述の通りniceを下げ、それでも不足の場合にプロセススケジューラを
変更してみると良いのですが、

まずもって、ms単位の周期のリアルタイム性を求める場合はRTOSではない
Linuxでの直接処理はせず、マイコン等を前段に入れる場合や、単純な
信号の割り込みでトリガしてドライバで刈り取れるような設計にすること
が多いと思います。