XMOS startKIT：XMOSおよびRaspberryPiロボットXMP-1の構築
はじめに
Farnell（またはNewark）のXMOS startKITは、Raspberry Piでうまく機能する非常に低コスト（VATを含めて£12）のプロセッサプラットフォームです。はんだ付けをほとんど必要とせずに、一緒にロボット工学アプリケーションを構築することが可能です。
XMOS startKITは、Cでプログラムできる複数の「XMOSコア」を備えたXMOSチップを搭載したクレジットカードサイズに近いボードです。XMOSテクノロジーにより、低ジッターで高速に並列実行できます。これらはまさに、ロボット工学アプリケーションに理想的な特性です。
XMOSstartKITボードとRaspberryPi（RPI）で実行するコードとともに、ボードを使用してシンプルでコンパクトなモバイルプラットフォームを構築します（これからはロボットではなくXMP、XMOSモバイルプラットフォームと呼びます）。すべての前に「X」を付けるというXMOSの精神でオンになります。
XMP-1は、いくつかのセンサーとより多くのプログラミングを備えているまではロボットではありませんが、将来的にはロボット実験用に拡張される可能性があります。 XMP-1は、低コストの既製の標準ハードウェアを使用し、ドライバー、ワイヤーカッター、ペンチ以外のエキゾチックなツールは使用していません。
この投稿では、シリアルペリフェラルインターフェイス（SPI）インターフェイスを使用したRPIとXMOSボード間の通信と、XMP-1を構築してWebブラウザから制御する方法について説明します。
ここのビデオは、XMP-1がルートを教えられていることを示しています。それを使用する最初の試み！それはより良いユーザーインターフェースから利益を得るでしょう。 XMP-1は非常に速く動くことができますが、私はここで低速でそれを楽にしました。右側はブラウザコントロールで、下部はコンソール出力で、何が起こっているかを確認するためのキープアライブメッセージとステータスメッセージを生成するだけです。
以下の次のビデオは、XMP-1がルートを再生しようとし、途中で苦痛と痛みを引き起こしているところを示しています。私の低コストの連続回転サーボ（車輪を駆動するために使用されている）はあまり良くなく、XMP-1にはまだセンサーがありません。
もう少し詳しく
この投稿は、実際にはいくつかのXMOSstartKIT実験のパート2です。パート1には、XMOSの概要、用語、アーキテクチャ、およびサンプルプログラムのクイックスタートガイドが含まれています。このテクノロジーに興味がある場合は、最初にパート1に従うと役立つ場合があります。これにより、このパート2の方が理にかなっています。このパート2は、RaspberryPiとXMOSstartKITボード間の高速通信のための単純なフレームワークを構築することを目的としています。フレームワークは、多くのプロジェクトで使用できる十分な汎用性を備えている必要があります（ロボット工学は私の意図ではありませんでした）。 XMP-1は、Raspberry PiからXMOSボードへの通信をテストしたいという点で、実際には単なる副産物です。役に立つ場合に備えて、ここに記録されています。 （XMOS startKITというタイトルのパート3もあります：XMOSとRaspberry Pi Oscilloscope XAE 1000は、この投稿で説明されているSPI機能を再利用し、XMOSチップに存在するアナログ-デジタルコンバーター（ADC）の使用方法を紹介します。 、およびWebブラウザでリアルタイムグラフィックスを実行する方法）。
XMP-1の構築と使用のみに関心がある場合は、投稿の下部にあるコードを取得し、コンパイルして、XMOSstartKITボードとRaspberryPiのFlash（パート1で説明）に保存します。 XMP-1ハードウェアアセンブリについて説明しているセクションに従ってください。他のすべてのコンテンツはスキップしてください。 Raspberry PiとWebブラウザーを使用してハードウェアを制御することに関心がある場合は、ここにあるコードの一部を再利用できます。ただし、RaspberryPiとXMOSstartKITの組み合わせを最大限に活用するには、startKITを初めて使用する場合に、ここに記載されている残りの情報が役立つ場合があります。
ソリューションの概要–ハードウェアとソフトウェア
これが完成したXMP-1の充電中の写真です。屋外での使用には、携帯電話でブラウザを実行する802.11ホットスポットタイプのデバイス（MiFi）を使用しました。
下の図は、XMP-1の背面から見たビットとピースのおおよそのレイアウトを示しています。 XMP-1は簡単な実験でした。
Raspberry Pi（RPI）は、すべてのネットワークアクティビティを処理するために使用されます。小さなWebサーバーを実行し、ほとんどのコードはNode.jsプラットフォームでJavaScriptで記述されています。 RPIは、シリアルインターフェース（SPI）を介してモーター制御速度（実際にはXMP-1には連続回転サーボが使用されていました）をXMOSstartKITボードに伝達します。 XMOS startKITは、パルス幅変調（PWM）信号をモーターに供給する役割を果たします。
RPIは、802.11 WiFiUSBアダプターを使用してネットワークに接続されています。
完全な配線図をここに示します。ハードウェアと構造については後で説明します。
次の図は、RPIおよびstartKITに実装されるソフトウェアを示しています。見た目はよく見えますが、そうではなく、以下でさらに説明する小さな部分に分割することができます。前述のように、ソースコード全体がこの投稿の下部にあるため、必要に応じて変更せずに使用できます。
簡単に言うと、緑色のブロックはWebインタラクションを処理し、ユーザー入力に基づいてモーターの速度と方向を決定します。緑のブロックは、ユーザーインターフェイスを組み込んだWebページ（index.html）をユーザーに提供します。 xmos_servoプログラムは、Cで記述された小さなソフトウェアであり、目的の速度/方向を、startKITに送信されるデータのシリアルペリフェラルインターフェイスバイトに変換します。 startKITソフトウェアは、別々のXMOSコアで同時に実行される3つの部分に分かれています。 spi_processは、SPI信号を配列に格納されるデータに変換します。 data_handlerコードは、配列を検査して何をするかを決定します（今日の結論は、サーボを操作することだけです）。 servo_handlerプロセスは、サーボにパルスストリームを出力するため、サーボは目的の速度で回転できます。これらのブロックはすべて、以下でさらに詳しく説明されています。
シリアルペリフェラルインターフェース（SPI）
SPIは、SS、SCLK、MISO、およびMOSIと呼ばれる4つのワイヤと、通信に関与する2つのデバイスのマスターとスレーブの割り当てに依存しています。 RPIおよびXMOSボードの場合、RPIはマスターデバイスであり、クロック信号の生成を担当します。 RPIは、MOSIワイヤでデータを送信し、MISOワイヤでデータを受信します。これは、SPIインターフェースが同時に双方向の方法でデータを転送できることを意味します。実際には、一方向のデータが必要な場合は、対象の方向に応じて、MOSI信号またはMISO信号のいずれかを無視できます。
ここにあるオシロスコープのスクリーンショット（個々の信号とTektronix MSO2024Bオシロスコープからの自動SPIデコード）は、RaspberryPiを使用したSPI通信の例を示しています。 SPIはいくつかの方法で構成できます。この例では、3バイトのデータがマスター（RPI）からスレーブ（XMOSボード）に転送され、それらが0x02、0x00、および0x10であり、データがないか、0x00、0x00、0x00がから転送されたことがわかります。同時にマスターにスレーブします。
SSワイヤはチップセレクト信号（アクティブロー）です。 RPIには、SSに使用できる26方向コネクタに2つのピンがあります。これらは、CE0およびCE1とマークされた、下の図の青色の円で示されています。これは、RPIが必要に応じて2つのSPIスレーブデバイスと通信できることを意味します。この場合、CEピンの1つだけが使用されました–私はCE1を選びました。
ホビーサーボモーターの制御
ホビーサーボモーターは、入力信号に基づいて動きを生成します。それらは通常1回転未満で回転します。通常、ホビーサーボは約180度の範囲で回転します。出力シャフトを（たとえば）リンケージに接続して、入力信号に基づいてホイールを完全に左または完全に右（またはその間の任意のもの）に回転させることができます。
下の図は、典型的なホビーサーボ（このサイトから取得）の内部を示しています。左側（青色）は従来のDCモーターです。それはかなり減速されており、最後のシャフトは、たとえばホイールステアリングメカニズムに接続できる青いアームに接続されている右側にあります。最終シャフトの下にはポテンショメータがあり、最終シャフトの正確な位置に関するフィードバックを提供します。したがって、ホビーサーボは閉ループシステムであり、アームが誤って目的の位置からノックアウトされた場合に自己修正できます。
ホビーサーボには通常3つの接続があります。 0V、5Vおよび信号。信号線はサーボへのデジタル入力であり、PWM信号が必要です。パルス幅のサイズによって、シャフトが移動する角度が決まります。 PWM信号は20ミリ秒ごとに繰り返す必要があり、パルス幅が1.5ミリ秒の場合、シャフトは中央の位置に移動します。幅が1ミリ秒の場合、サーボは一方向に完全に移動し、幅が2ミリ秒の場合、サーボは他の方向に完全に移動します（さらに下には、サーボ制御のオシロスコープのトレースがいくつかあります）。
「連続回転」サーボとして知られている修正されたサーボのタイプがあります。これは、ポテンショメータがエンドストップとともに取り外された修正サーボであり、回路はサーボがまだ中央位置にあると考えるように説得されます。 1.5msec以外のパルス幅でPWMを送信すると、メカニズムはパルス幅に応じた速度で時計回りまたは反時計回りに回転します。 XMP-1は、各ホイールに1つずつ、合計2つの連続回転ホビーサーボを使用します。ホビーサーボの本来の目的とは異なる目的で使用されているため（XMP-2はDCブラシ付きモーターを使用）、制御されたモーションを取得する最適な方法ではありませんが、デジタルで制御できるという利点があります。論理信号であり、外部Hブリッジ回路を必要としません。
ホビーサーボワイヤーは、メーカーによって色分けが異なります。通常、中心線は赤で、+ 5Vになります。黒または茶色のワイヤーは0Vです。白または黄色の線はPWM信号入力です。
開発の開始–ボードの接続
ソフトウェアを開発するために、RPIとstartKITは、リボンケーブルとIDCコネクタアセンブリを使用して接続されました。これらは、バイスを使用して組み立てることも、既製のものを購入することもできます。自己組織化バージョンの場合、ケーブルの中央にあるデバッグコネクタとして使用するIDCコネクタを追加購入する価値があります。これにより、マルチメータまたはスコープで信号をプローブする際の作業が楽になります。
XMOS startKITでのSPI（spi_process）の実装
XMOS開発環境（xTIMEcomposer）の使用についてはパート1で説明しました。以下のスクリーンショットはWindowsバージョンのxTIMEcomposerを示していますが、Linuxバージョンは同じように見えます（Macバージョンも似ている可能性があります）。
この時点で、xSOFTipラボのSPIスレーブ機能ライブラリを右クリックして、ライブラリをワークスペースにインポートできます。私はxTIMEcomposerの専門家ではないため、ここでは間違って使用している可能性がありますが、ライブラリのソースコードとヘッダーファイルは、プロジェクトエクスプローラーの別のフォルダーに表示されます（下の青い丸で囲まれています）：
ファイルはspi-testフォルダーにある必要がありました（上の緑色の円で囲まれたように表示されるように）。これを実現するには、spi_slave.hファイルとspi_slave.xcファイルをmodule_spi_slave / srcフォルダーからspi-testに手動でコピーしました。 Windowsエクスプローラを使用した/ srcフォルダ。
このソフトウェアは、ポートの概念を使用して、出力を制御したり、入力を読み取ったりします。これらの論理ポートとチップ上のピンへの物理マッピングの間にはマッピングがあります。マッピングは特定の組み合わせで変更できます（XS1ポートの概要PDFドキュメントの図3を参照）。
XMOSデバイスの入力/出力ポートは、1、4、8、16、または32ビット幅にすることができます。パーツを使用して設計する場合、特定の機能を1ビットポートに割り当てたり、他の機能をマルチビットポートに割り当てたりすることができます。そのため、図3は、使用するポートとピンを決定するのに非常に役立ちます。
SPIスレーブコードがspi-test / srcフィルダーに含まれるようになったため、このコードはわずかに変更されました。ライブラリコードは、SPIインターフェースに使用されているポートがすべて1ビットポートであると想定していますが、Raspberry Pi SPI SSピン（CE1）はXMOSボードの32ビットポートに接続されています。 startKITハードウェアマニュアルのPDFドキュメントの図8を以下に示します。緑の中央には、XMOSボードとRaspberryPiを接続する2×13ウェイヘッダーがあります。左側と右側の青色は、チップ上の物理ピン名（X0D0 、、 X0D11など）です。ピンで強調表示されている値は、論理ポート番号です。 P1A、P1Dなどはシングルビットポートです。 P32A1は、32ビットポートの最初の2桁です
SPIライブラリにかなりの変更が加えられ、コード全体が投稿に添付されているため、ここではコードの一部のみを説明します。この投稿の最後に添付されている完全なコードをコピーして貼り付ける必要はありません。使用できます。
XMOSデバイスのSPIインターフェイスは、次のように初期化されます。以下でさらに説明します。
+ソースビュープレーンを展開- void spi_slave_init（spi_slave_interface＆spi_if）
- {
- int clk_start;
- set_clock_on（spi_if.blk）;
- configure_clock_src（spi_if.blk、spi_if.sclk）;
- configure_in_port（spi_if.mosi、spi_if.blk）;
- configure_out_port（spi_if.miso、spi_if.blk、0）;
- start_clock（spi_if.blk）;
- return;
- }
パート1の投稿で述べたように、I / Oは正確な時間にXMOSデバイスにクロックインおよびクロックアウトできます。上記のコードでは、set_clock_on関数（XMOS xs1.hヘッダーファイルで定義）を使用して、XMOSチップに組み込まれているクロッキングメカニズムの1つをオンにします。次の図（XS1ポートの概要ドキュメントから）は、このメカニズムを黄色で示しています。 configure_clock_src関数は、外部クロックを選択するために使用されます（図では青色で示されています）。 RaspberryPiのSCLKピンに接続されます。 configure_in_port関数とconfigure_out_port関数は、ポートをクロッキングメカニズムに接続するために使用されます。 MOSI信号とMISO信号（下に緑色で表示）の両方が、クロッキングメカニズムに接続されるように構成されています。
XMOSデバイスでのシリアルデータの処理方法は非常に優れています。ここでのコードについては、以下でさらに説明します。まず、構造体を使用して、SPIインターフェースとして使用する必要のあるポートに関する詳細を含めます。
+ソースビュープレーンを展開- typedef struct spi_slave_interface
- {
- in port ss;
- バッファリングされたポート：8mosi;
- バッファリングされたポート：8味噌;
- in port sclk;
- } spi_slave_interface;
上記の興味深い行は、ポート変数mosiとmisoを参照している行です。それらはタイプport：8として宣言されています。変数に1ビットのポートアドレスが割り当てられている場合、XMOSデバイスはビットの1線式ストリームを8ビット値に自動的に逆シリアル化します。
これにより、残りのSPIコードが非常に簡単になります。 RaspberryPiからのSPIデータ入力を管理するコードは次のとおりです。
+ソースビュープレーンを展開- void spi_slave_in_buffer（spi_slave_interface＆spi_if、unsigned char buffer []、int num_bytes）
- {
- unsigned int data;
- unsigned int vlen =0;
- clearbuf（spi_if.miso）;
- clearbuf（spi_if.mosi）;
- for（int i =0; i
- {
- spi_if.mosi：>データ;
- data =data <<24;
- buffer [i] =bitrev（data）;
- if（i ==2）
- {
- vlen =（（（unsigned int）buffer [1]）<<8）| （unsigned int）buffer [2];
- if（vlen ==0）
- 休憩;
- }
- if（i> =vlen + 2）
- {
- 休憩;
- }
- }
- }
上記のコードでは、forループがあり、ループ内に行spi_if.mosi：> data;があることがわかります。 MOSIライン上の8ビットの情報をデータと呼ばれる変数に読み込むために使用されます。
次の2行は、バイト内のビットを反転するために使用され、データはバッファ配列に格納されます。
次の数行には説明が必要です。それらは、目的のプロトコルに関連しています。これは、XMP-1だけでなく、多くのことに使用できる汎用コードを作成することを目的としていました。 RaspberryPiがXMOSstartKITボードにデータを送信する場合、XMOSボードは予想されるデータのバイト数を知る必要があります。これはハードコーディングできますが、柔軟性がありません。
非常に単純な「タグ（またはタイプ）、長さ、値」（TLV）プロトコルを使用することが決定されました。 Raspberry Piが送信する必要のある最初のバイトは、0〜255の範囲のタグまたは識別子です（つまり、1バイト）。値が何を表すかを決定するのはユーザーの責任です。たとえば、値1は「モーター速度の設定」を意味し、値2は「ヘッドライトの明るさの強度の設定」を意味します。次の2バイトは16ビット値であり、続く値（つまりデータ）バイト数を示します。これを4kバイト（4096バイト）に制限することにしました。これは多くのユースケースに対応するはずですが、実際の値はコードのBUFLEN定義を調整することで変更できます。
したがって、SPIインターフェイスで送信される最小バイト数は3（タグ、長さ0x0000）で、最大バイト数はタグで長さ0x1000（16進数で4096）の4099、データバイト数は4096です。
プロトコルがわずかに改良されたため、タグ番号が奇数の場合、Raspberry Piは、現在のTLVストリームの完了後に開始する次のSPI通信で応答を期待し、タグ番号が偶数の場合は、RaspberryPiが応答を期待しないことを意味します。戻る。
これは非常に基本的なプロトコルですが、多くの通常の要件を満たす必要があります。次の表でも説明されています。青い数字は、受信側の4099バイトバッファへのSPIバイトインデックスです。
前のコードスニペットに戻ると、次の数行で、SPIデータの受信中にbuffer [1]とbuffer [2]の内容をオンザフライでチェックしていることがわかります。内容は、上の図に示されている長さであると予想されます（青いバッファインデックスを参照）。コードが余りの長さを決定するとすぐに、その数のデータバイトを正確に受け入れ、ルーチンが終了します。
これは、MOSIラインのXMOSボードへのSPI入力を対象としています。 MISOライン上のXMOSデバイスからのSPI出力も同様に動作し、MOSIライン上で同時に長さをオンザフライでチェックするため、要求されたバイト数が転送されるとすぐに関数が終了します。
プロセス間通信
SPIが理解され、最大4096バイト長までのいずれかの方向で可変長データを交換するためのプロトコルが実装されたので、プログラムの本体にいくつかの考慮が払われました。 XMOSコアがSPIタスクの処理専用になることは明らかでしたが、残りのコードは1つ以上の追加のXMOスコアに存在する必要がある場合があります。
パート1では、タスクがさまざまなXMOSコアで並行して実行される方法と、値をチャネルにプッシュすることによってタスクが相互に通信する方法について説明しました。コア間で通信する別の方法があり、チャネルではなく「インターフェイスを介したトランザクション」の概念を使用します。あるXMOSコアから別のコアに異なるタイプの複数の変数を送信できるため、より柔軟性があります。トランザクションタイプは、C関数プロトタイプのように定義されます。例を見ると、これはすべてはるかに明確になります。
たとえば、アプリケーションにディスプレイを制御するタスクがある場合、送信タスクはディスプレイをオンまたはオフにしたい場合や、ピクセルをプロットしたい場合があります。 2つのXMOSコア間の通信のインターフェース定義は次のようになります。
+ソースビュープレーンを展開- {
- void backlight（int state、int color）; //トランザクションタイプ1
- void plot（int x、int y、int color）; //トランザクションタイプ2
- };
インターフェイス通信は単方向であるため、ディスプレイがタッチスクリーンの状態などの情報を送信する場合は、別のインターフェイスを別の方向で使用する必要があります。このことから、インターフェースにはクライアント側とサーバー側があることが明らかです。この図は、2つのXMOSコア（紫色）、2つのインターフェース（灰色）、および最初のインターフェース（program_displayと呼ばれる）により、program_displayインターフェース全体で2つの異なるタイプのトランザクション（青色）を実行できることを示しています。
インターフェイスとトランザクションタイプを使用することの優れている点は、C関数のプロトタイプと同様に、戻り値を取得したり、変数への参照を渡したりできることです。これにより、通信は常にインターフェイスのクライアント側で開始されますが、データ転送が行われます。双方向で発生する可能性があります。図に示されていないもう1つの非常に興味深い機能は、サーバー側がクライアント側に「通知」を送信できる機能です。これは、おそらくいくつかのデータを取得するために、通常の方法でトランザクションを発行するようにクライアントに通知することができます。この機能はXMP-1コードで使用されます。そのため、インターフェースをコーディングし、データと通知を送信する方法の詳細については、以下でさらに説明します。
SPIコンテンツを処理するためのIPCアーキテクチャの設計
SPIインターフェースの処理についてはすでに説明しました。ここで、SPIメッセージのコンテンツは、後続の処理に役立つ方法でタスクに提示される必要があります。インターフェイスとトランザクションに関する知識を身に付ければ、XMOSコアを分離する機能の割り当てと、RPIからXMOSに有用なメッセージコンテンツを送信できる汎用フレームワークに到達するためのプロセス間通信の設計を開始することができました。ボードとその逆、そして処理されます。
ここの図は、開発されたものを示しています（上から下への時系列があることを除いて、以前と同様の図）。
Raspberry PiがXMOSボードにメッセージを送信することを希望する場合、RPIはメッセージを前述のTLV形式に構築します。次に、情報はMOSI信号線（上の図の上部に緑色で表示）でクロックアウトされます。同時に、XMOSデバイスは何かを送り返す必要がありますが、送り返す情報がまだないため、ピンクで示されているように、MISO行にガベージまたはすべてゼロの値が含まれている可能性があります。 spi_process関数は、メッセージをバッファー（unsigned charの配列）に収集してから、別のdata_handlerXMOSコアへのトランザクションを開始します。 data_handlerは、メッセージの内容を処理し、オプションでspi_process XMOSコアに情報を送り返す役割を果たします。これにより、後続のSPI交換で、ガベージ値の代わりに有用なデータをRaspberryPiに送り返すことができます。
バッファのコピーを作成することにより、spi_processとdata_handlerの間でデータを送信できます。ただし、代わりに、バッファメモリへのポインタを渡すことは可能です。これを行う1つの方法は、ポインタとバッファメモリの場所の制御をspi_processからdata_handlerに「移動」することです。 data_handlerがメッセージ検査を完了すると、トランザクションで使用できる戻り変数を使用して、制御をspi_processに戻すことができます。これが、上の図に、移動可能なポインターとして定義されたパラメーターと、移動可能なポインターとして定義された戻り値を持つarray_dataというトランザクションがある理由です。このように、一度に1つのXMOSコアのみがバッファメモリにアクセスできます。
使用されるインターフェースは次のとおりです。
+ソースビュープレーンを展開- {
- void code（unsigned char c）;
- };
- {
- unsigned char * moveable array_data（unsigned char * moveable bufp）;
- };
spi_handlerコードは、バッファーにスペースを割り当ててから、次のコードに示されているbuf =c.array_data（move（buf））行を使用して、バッファーの制御をdata_handlerコードに渡します。
+ソースビュープレーンを展開- spi_process（interface to_rpi server s、interface from_rpi client c）
- {
- unsigned char storage [4099];
- unsigned char * moveable buf =storage;
- …
- buf =c.array_data（move（buf））;
- …
- {
- case s.code（unsigned char c）：
- if（c ==SEND）
- {
- spi_slave_out_buffer（spi_sif、buf、4099）;
- }
- 休憩;
- }
- }
data_handlerコードはバッファーの制御を取得し、後続のSPIトランザクションでRPIに応答を送信する必要がある場合は、バッファーに応答が入力されます。最後に、バッファの制御がspi_handlerプロセスに戻されます。
+ソースビュープレーンを展開- data_handler（interface to_rpi client c、interface from_rpi server s）
- {
- 選択
- {
- case s.array_data（unsigned char * moveable vp）-> unsigned char * moveable vq：
- // vqにはSPIからのデータが含まれています。ここでは、好きなことを何でもできます。
- //応答はここでも作成されます：
- vq [0] =0x22; //タグ
- vq [1] =0x00; //長さ
- vq [2] =0x00; //長さ
- vq =move（vp）; //ポインタコントロールをspi_processに戻します
- tosend =1;
- 休憩;
- }
- if（送信）
- {
- c.code（SEND）; //コードをspi_processに送信して、RPIに送信するデータがあることを認識できるようにします
- }
- }
奇数のタグ値がRPIによって送信された場合、これは、RPIが後続のSPI交換でXMOSstartKITボードからの応答メッセージを予期したことを示していると前述しました。これは、spi_processとdata_handlerの両方によって実装され、受信した最初のバイトが奇数の場合にリターンメッセージが期待されることに注意してください。 data_handlerは、バッファメモリにリターンメッセージの作成を完了すると、バッファポインタをspi_process XMOSコアに戻し、「送信準備完了」などのメッセージを含む可能性のあるコードトランザクションも送信します。これで、spi_processXMOSコアは後続のSPI交換の準備が整いました。 data_processがRaspberryPiにメッセージを送り返したくない場合（たとえば、タグが評価された場合）、コードトランザクションは送信されません（または「送信準備ができていません」などの別のコードが送信される可能性があります） 。
前の図では、後続のSPI交換がMISOワイヤ上のRaspberryPiにデータを送り返したことがわかります。
要約すると、spi_processとdata_processは、RPIとXMOSボード間で双方向にデータを交換するためのかなり汎用的な機能を提供します。
startKITにPWM（servo_handler）を実装する
汎用アーキテクチャをテストするために、多くのデバイスを制御するためにそれを使用することが決定されました。デバイスは、電気的なインターフェースの労力がほとんど必要なく（Hブリッジやトランジスタドライバーは不要）、サーボ入力ワイヤーをXMOS出力ピンに直接接続できるため、最終的には趣味のサーボになりました。私はサーボをあまり持っていなかったので、コードは8つのサーボ制御を実装していますが、XMP-1には2つしか使用されていませんでした。
コードを変更して、DCモーター制御も提供することができます（適切な外部Hブリッジ回路を使用）。
8つのサーボを処理するために単一のXMOSコアを使用することが決定されました。次の図は、ソリューションで使用される3つのXMOSプロセスの合計を示しています。新しく追加されたのは、右側に示されているservo_handlerタスクです。このタスクには、現在のサーボ値を格納する配列があります。タスクが起動するとすぐに、値が中央の値に初期化され（または連続回転サーボの場合は停止）、マイクロ秒ごとにタスクがウェイクアップして、サーボPWM信号の調整が必要かどうかを確認します。その場合、サーボポート出力が切り替えられます。 20ミリ秒後、プロセスが繰り返されます。
詳細：XMOS startKITXMOSおよびRaspberryPiロボットXMP-1の構築
製造プロセス