acontis EtherCAT Master Software EC-Masterが、 Raspberry Pi Compute Module 4 (CM4)で使用されるBROADCOM® System-on-Chip (SoC) BCM2711をサポートするようになったことを発表できることを誇りに思います。さらに、 BCM2711に含まれるオンボード イーサネット用に最適化された新しいイーサネット コントローラ ドライバ (acontis Real-time Driver) が開発されました。この新しいリアルタイム ドライバー ( BcmGenet ) は、ARM 32 ビットおよび ARM 64 ビット アーキテクチャで動作する Linux をサポートし、さらにオペレーティング システム (OS) のサポートが間もなく開始されます。

EC-Master スタックのスマートなアーキテクチャと社内のハードウェア ドライバーの知識により、イーサネット メディア アクセス コントローラー (MAC) のサポートを　　実装することはそれほど難しくありません。 Linux ドライバーから独立し、可能な限り最高のパフォーマンス、スループット、および最小のジッターを得るために、 acontis Real-time Driverとして実装することにしました。

この種類のドライバーは、イーサネット ハードウェアに排他的にアクセスできます。　 Linux Network Driverで非排他アクセスが可能です。したがって、2 つのアプローチの長所と短所を理解することが重要です。

図 1 アーキテクチャ

BROADCOM®イーサネット コントローラ用の新しいリアルタイム ドライバを自分で　テストすることに関心がある場合は、評価パッケージについてお問い合わせください。パッケージを使用すると、独自のシステムで行った測定を再現できます。そのための手順を以下に説明します。

評価は、 Raspberry Pi CM4または同様のシステムで実行できます。すぐに使える　CM4をお勧めします。モジュール上の他のシステム ( SoM ) では、Linux デバイス ツリーなどで、さらに調整が必要になる場合があります。

動作するリアルタイム ドライバーをセットアップするための最初の手順は、Linux デバイス ツリーをカスタマイズすることです。カスタマイズの目的は、イーサネット MAC との通信に標準のBROADCOM® Genet ドライバーの代わりに acontis atemsysカーネル モジュールを使用する必要があることをBCM2711プロセッサに通知することです。 atemsysモジュールを使用すると、  HYPERLINK "https://github.com/acontis/atemsys" BCM2711イーサネット MAC が Linux カーネル ドライバーから分離されます。その結果、EtherCAT 通信は、オペレーティング システムのイーサネット通信 (ARP や TCP/IP など) から分離されます。これは、他のイーサネット ポートでも可能です。

デバイス ツリーのカスタマイズ後、 atemsysモジュールをダウンロード、コンパイル、およびインストールできます。

EC-MasterがBcmGenet Real-time Driver を使用してCM4で動作しているかどうかを確認するには、EtherCAT デバイスをCM4イーサネット ポート ( BROADCOM® BCM54210ギガビット イーサネット トランシーバー) を起動し、評価パッケージ ( EcMasterDemo ) に含まれるコンパイル済みのバイナリ サンプル アプリケーションを次のコマンド ライン パラメーターで起動します。

./EcMasterDemo -bcmgenet 1 1

Snippet 1 ポーリング モードでの BcmGenet リアルタイム ドライバーを使用した EC-Master Demo 呼び出し

Broadcom Real-time ドライバーは 2 つの引数を取ります。最初の引数は使用するイーサネット コントローラー インスタンスを指定し、2 番目の引数は動作モード (ポーリングまたは割り込み) を指定します。この場合、最初のインスタンス (1) とポーリング モード (1) を指定します。コマンド ライン パラメータと関連する引数は、サンプル デモ プログラムを実行するときに -help 引数を使用して確認できます (以下を参照)。また、オンラインドキュメントでも確認できます。

-bcmgenet         Link layer = Broadcom BcmGenet
     Instance        Device instance (1=first), e.g. 1
     Mode            Interrupt (0) or Polling (1) mode

Snippet 2 EC-Master Demo のリアルタイム ドライバー パラメータ ヘルプ

acontis EC-Masterソフトウェアにはパフォーマンス測定機能が組み込まれており、これも含まれており、 EcMasterDemoサンプル アプリケーションで使用できます。パフォーマンス測定計算は、以下に示すように追加のコマンド ライン パラメータで呼び出すことができます。

./EcMasterDemo -bcmgenet 1 1 -v 3 -perf

Snippet 3 EC-Master Demo call with BcmGenet in polling mode and performance measurement enabled

実行する特定の測定に応じて、EtherCAT Network Information (ENI) ファイルを使用してアプリケーションを開始することも選択できます。

./EcMasterDemo -bcmgenet 1 1 -f eni.xml -v 3 -perf

ENI ファイルを使用したSnippet 4 EC-Master Demo 呼び出し、ポーリング モードの BcmGenet、およびパフォーマンス測定が有効化されている

パフォーマンス測定が有効になっている場合、サンプル アプリケーションは、アプリケーションの循環部分内で呼び出されるジョブ関数の実行時間と、循環タスク自体によって消費される合計計算時間を測定します。サンプル アプリケーションでは、付属の API ecatPerfMeasStart ( )およびecatPerfMeasEnd ()を使用して、高精度の測定時間を計算します。

結果の測定値は、数秒ごとに記録され、コンソールとログ ファイルに次の形式で出力されます。

PerfMsmt 'Cycle Time                     ' (min/avg/max) [usec]:  989.4/1000.0/1011.4
PerfMsmt 'Task Duration (JOB_Total + App)' (min/avg/max) [usec]:   28.5/  29.6/  45.6
PerfMsmt 'JOB_Total                      ' (min/avg/max) [usec]:   24.6/  25.8/  44.8
PerfMsmt 'JOB_ProcessAllRxFrames Duration' (min/avg/max) [usec]:   10.0/  10.6/  20.1
PerfMsmt 'JOB_SendAllCycFrames Duration  ' (min/avg/max) [usec]:    8.2/   8.8/  13.5
PerfMsmt 'JOB_MasterTimer Duration       ' (min/avg/max) [usec]:    4.6/   5.3/  10.0
PerfMsmt 'JOB_SendAcycFrames Duration    ' (min/avg/max) [usec]:    0.9/   1.0/   6.7
PerfMsmt 'myAppWorkPd                    ' (min/avg/max) [usec]:    0.8/   0.9/   1.3

リスト 1 EC-Master のパフォーマンス測定結果 (BcmGenet OSOpti)

ユーザーは、 EC-Masterによって実行された重要なタスクの期間、さらにはカスタム アプリケーションの期間を見ることができます。これらの測定から得られるさらに重要な情報は、全体のサイクル時間と比較した各タスクの比率です。たとえば、受信したすべてのフレームの処理 ( JOB_ProcessAllRxFrames ) を例にとると、これは使用されるサイクル時間の 1.06% (10.6 マイクロ秒) を表し、循環フレームの送信には最大 0.88% かかります (平均 1ms サイクルの 8,8 マイクロ秒)。

以下のセクションで説明するように、これらの値をさまざまなシナリオで収集し、比較のために表にまとめました。しかし、最初に、私たちが行ったいくつかの追加の測定と、そのために使用したセットアップを示したいと思います.

上記のEC-Masterの内部時間測定を、ネットワーク上のフレームのさらに信頼性の高い外部時間測定に関連付けたいと考えました。これは、EC-Master ソフトウェア内の測定が不正確であることを意味するものではありませんが、ネットワーク上のデバイスに関連する時間ではなく、プロセッサのタイミングを測定します。これがワイヤ上のタイミングです。当初はオシロスコープで測定しようと考えていましたが、標準プローブを使用した方が測定しやすく、再現も容易であることがわかりました。したがって、 　　Beckhoff®を使用しました。 ET2000を使用して、マスターとネットワーク上のデバイス間のフレーム タイミングを測定します。

図 2 測定セットアップ

ET2000は、ハードウェアでイーサネット フレームにタイム スタンプを付け、フレームをタイムスタンプと共に測定 PC に転送します。測定用 PC では、単純にWiresharkを実行して、循環フレームのみをフィルタリングし、ハードウェア タイムスタンプ デルタを取得しました (ヒント: Wiresharkの「ディセクタを有効にする」 )。

図 3 Wireshark の構成

これらの数値はすべてMicrosoft® Excelで収集され、次の表と図が作成されました。

EC-Masterは、 CM4にインストールされた Ubuntu 20.04 ARM-64bit で実行されています。したがって、 EcMasterDemoバイナリはこのシステム用にコンパイルされ、　　1ms サイクルで接続された 7 つの EtherCAT スレーブ デバイスを制御します。

ネットワークの起動がキャプチャされ、統計に寄与するようにするには、 EcMasterDemoの前にWiresharkを起動する必要があります。私たちの測定では、 EcMasterDemoは 1 分間実行されました ( -t <time> コマンド ライン パラメーター)。

BcmGenetリアルタイム ドライバーと既存のBcmSockRaw汎用ソケット ドライバーとの比較を優先し、OS の最適化の有無にかかわらず、 4 つの異なるシナリオに集中しました。

ヒント： BcmSockRawは、この記事では、BCM2711 用の標準 Linux ネットワーク ドライバーを使用する raw ソケット (SockRaw) ドライバーとして定義されています。

図 4 4 つの測定シナリオ

CPUについて

EC-Masterパフォーマンス測定 APIを使用して CPU で測定された、上記の 4 つのシナリオからの測定値を示しています。

表 1 EC-Master 内部タイミング測定

ご覧のとおり、min、avg、および max セクションの左側の 2 列には、もう少し緑色があります。これは、これら 2 つのシナリオで Real-time Driver を使用しているため　です。 BcmGenetリアルタイムドライバーは、ほぼすべてのサイクル タイムとジョブ　期間のインジケーターでより良い結果を提供します。 Real-time Driver を使用すると受信したすべてのフレームの処理に少し時間がかかるように見える例外が 1 つあります。これは興味深い結果であり、これをさらに調査します。すべてのサイクリック フレームの送信は、 BcmGenetドライバーを使用すると 4 倍以上高速になります。要約すると、 BcmGenetリアルタイム ドライバーは、 BcmSockRaw汎用ソケット ドライバーと比較して、タスクの合計時間を半分に短縮します。

さらに、 BcmGenetリアルタイム ドライバーは、 BcmSockRaw汎用ソケット ドライバーよりもジッターが少なくなります。それぞれの最良のケースでは、ジッターはBcmGenetリアルタイム ドライバーで約 ± 1.1%、 BcmSockRaw汎用ソケット ドライバーで約 ±3.2% でした。

BcmGenetリアルタイム ドライバーを使用したEC-Masterではフレーム ロスが報告されていませんが、 BcmSockRaw汎用ソケット ドライバーでは顕著なフレーム ロスが報告されています。

オン・ザ・ワイヤー

ワイヤ上の物理的なタイミングを見ると、同様の図が得られます。実際、メイン メモリで実行されているソフトウェアから物理的なワイヤまでの時間は非常に短いことが確認されています。 EC-Masterの内部時間計測の最小値、平均値、最大値を確認し、ワイヤー上のタイミングに対応させることができます。 EC-Master ソフトウェアのタイミング値は信頼に値します。

Wireshark記録の最初の 30.000 周期フレームが評価のために取得されます。 　　　1 ミリ秒のサイクル時間または 1kHz の周波数では、最初の 30.000 周期フレームが各テスト測定の最初の 30 秒に対応します。これらの最初の 30 秒のヒストグラムは、各テスト シナリオで 200 マイクロ秒幅のビンと比較されます。最も外側の 2 つのビンは 975 ミリ秒と 1025 ミリ秒の境界を表すため、これらのビンはこれらの境界を超えるすべての測定値を収集します。

図 5 ヒストグラムの比較

以前の CPU タイミングと同様に、 BcmGenetリアルタイム ドライバーは最高 (最低) のジッター動作を示します。適用された OS 最適化の有無にかかわらず、中央に狭いピークが見られ、極端な領域にはほとんどフレームがありませんでした。 OS の最適化により、値はさらに向上します。

BcmSockRaw 汎用ソケット ドライバーは、OS の最適化が適用されている場合、メイン サイクル周波数の ±2,5Hz、±16,2Hz、および ±18,7Hz 付近で確定的なジッターを示します。これらの周波数は、繰り返しテストで観察されました。このシナリオでは、サイクル タイム付近の中央の高いピークが完全に欠落しています。カーネル スレッドの同期がこの動作につながると考えられます。 OS の最適化を行わないと、サイクル タイム付近に明確なピークがあり、メイン周波数の ±2.5Hz 付近にいくつかの小さなピークがありますが、外側の領域にはありません。

前述の測定に加えて、同じプラットフォーム上の Intel ギガビット イーサネット アダプタ ファミリ用のよく知られた実績のあるリアルタイム ドライバなどを使用して、さらにいくつかの測定も行いました。すでに言えることは、 BcmGenetリアルタイム ドライバーは間違いなく同じレベルにあるということです。

与えられた結果から、新しいBcmGenetリアルタイムドライバーは、さまざまなシステム構成でBcmSockRaw汎用ソケット ドライバーよりも決定論的であると言えます。 OS の構成によっては、他のパラレル イーサネット ポートでの通信によって引き起こされる EtherCAT フレームの損失は、リアルタイム ドライバーの設計によって完全に排除されます。

これらすべての測定を行うと、正しい OS と OS 構成がないと、良い結果が得られないこともわかりました。アプリケーションの送信要求が低ジッターで時間どおりに実行されない場合、ドライバーはこれを修正できません。構成が間違っていると、ロードされたシステムとアンロードされたシステムのレベルが異なります。より多くの測定結果や、システムを微調整してパフォーマンスを向上させる方法に興味がある場合は、お気軽にお問い合わせください。

このテストと分析が、どのシナリオで何を使用するかを決定するのに役立つことを願っています。また、必要に応じて、実際に必要なネットワーク構成を備えた独自の　　ハードウェア、アーキテクチャ、および Linux ディストリビューションで再現するために、与えられた説明と例で十分です。