SPIバスの概要と組み込みLinux用のスレーブSPIデバイスのドライバーの開発（パート1、概要）

この記事では、SPIバス（さまざまなデバイスを接続するために使用される組み込み技術で広く使用されているインターフェイス）の簡単な概要を示し、Linux用SPIデバイスのプロトコルレベルのドライバーを作成するプロセスを説明します。 このドキュメントは完全なガイドではなく、正しい方向を示すことを目的としています。 この記事は1つのトピックのサイズに含まれていなかったため、2つの部分に分割する必要がありました。

0.導入する代わりに

この記事は何ですか？

この記事は、さまざまなソースからの情報をまとめたものであり、ドキュメントの一部を無料で翻訳したものです。また、私自身のコメント、追加、発生した問題の説明も掲載しています。



この記事の対象者

まず第一に、私は初心者向けです。 組み込みLinuxフォーラムでは、「このボードでSPIを操作する方法は？」という質問を見つけることができます。 私が答えようとするのは彼にとってです。 例として、テストSPIデバイスで動作するように記述されたコードを提供します。



記事の構造

多くの情報があったため、この記事はいくつかのセクションに分かれています。

1. SPIとは何ですか？
2. Linux SPIサブシステムの概要
3. spidevを使用したユーザー空間プロトコルSPIドライバーの開発
4. カーネルレベルのプロトコルSPIドライバーの開発
5. ドキュメント

最初の2つの段落は記事の最初の部分に含まれ、残りは2番目の部分に含まれます。



最初のサブセクションではSPIバスの動作について説明します。記事のこの部分は特にLinuxに結び付けられていないため、Linuxに興味がない人でも読むことができますが、このインターフェースに関する情報を取得するだけでかまいません。



2番目のサブセクションでは、LinuxでSPIを使用する基礎となる構造とメカニズムについて説明します; 3番目と4番目のパートで説明する内容を理解するために読む必要があります。



翻訳や追加に興味がない場合は、すぐに5番目のセクションに進んでください。ここでは、この問題に関する必要な情報をすべて入手できる場所に関する情報を見つけることができます。



構造または関数の名前にリンクが表示されている場合、新しいタブで開くことができるため、Linuxカーネルの公式ドキュメントでこの構造/関数の説明に直接アクセスできます。



間違い

私は魔術師ではありません、ただ勉強しています。 エラーや不正確な点を見つけた場合は、お知らせください。

1. SPIとは何ですか？

SPIという略語は、「シリアルペリフェラルインターフェース」またはロシア語版では「シリアルペリフェラルインターフェース」を意味します。 名前はそれ自体を物語っています。このインターフェイスは、さまざまな周辺機器を操作するために使用されます。 たとえば、さまざまなDAC / ADC、ポテンショメータ、センサー、入出力ポートエクスパンダ（GPIO）、さまざまなメモリ、さらにはオーディオコーデックやイーサネットコントローラなどのより複雑な周辺機器を使用できます。



技術的な観点から見ると、SPIは同期4線式バスです。 これは、2つの同期シフトレジスタの接続であり、SPIデバイスの中心的な要素です。 接続はマスター/スレーブ構成を使用します。 マスターのみが同期パルスを生成できます。 回路には常に1つのマスターしかありません（複数のマスターを使用できるオプションがある同じI2Cバスとは異なり）、スレーブの数は異なる場合があります。 一般的な場合、マスターの出力はスレーブの入力に接続され、逆の場合、スレーブの出力はマスターの入力に接続されます。 SCK出力に同期パルスを適用すると、データはマスターによってMOSI出力からプッシュされ、MISO入力でスレーブによってキャプチャされます。 したがって、シフトレジスタの幅に対応する数の同期パルスを送信すると、レジスタ内のデータが場所を交換します。 SPIは常に全二重モードで動作します。 ただし、パラメータを書き込むときにデバイスから受信したデータが必要かどうかは別の問題です。 デバイスにデータを書き込むときにデバイスから受信したデータがガベージであることがよくあります。その場合、それらは単に無視されますが、希望に関係なく受信します。



SPIコントローラーは通常、MCUまたはeMPUの周辺装置によって実装されます。 ほとんどのチップでは、マスターモードとスレーブモードの両方で動作します。 しかし現時点では、Linuxはマスターモードのみをサポートしています。



SPIデバイスを有効にする方法はいくつかあります。









あなたが上の写真で見るそれらの最も単純なもの（無料のGFDLライセンスの下の写真についてはWikipediaに感謝します）。 この場合、スレーブ選択信号（〜CS）を除き、すべてのスレーブがマスターに並列に接続されます。 各スレーブには個別のスレーブ選択信号が必要です（図ではSSxとして指定されています）。 スレーブ選択信号の場合、この目的のために特別に設計されたSPIコントローラー出力と、マイクロコントローラーの汎用入出力（GPIO）ポートの両方を使用できます。



データ伝送には2つの導体が使用されます。1つはクロックパルスを供給し、もう1つは各スレーブのスレーブを選択するための信号です。

使用される信号の説明：

• MOSI-マスター出力、スレーブ入力（マスター出力、スレーブ入力）。 この信号は、マスターからスレーブへのシリアルデータ送信を目的としています。 SDO、DOなどとも呼ばれます。
• MISO-マスター入力、スレーブ出力（マスター入力、スレーブ出力）。 この信号は、スレーブからマスターへのシリアルデータ送信を目的としています。 SDI、DIなどと呼ばれる場合があります。
• SCK-シリアルクロック。 データ転送中の同期に使用されます。 SCLK、CLKなどとも呼ばれます。
• 〜CS-チップ選択（チップ選択）。 この信号により、スレーブがアクティブになります。 通常、これは逆です。つまり、低レベルはアクティブと見なされます。 時々それは〜SS（Slave Select、ロシア語の「奴隷の選択」）と呼ばれます。

独立した接続の特殊なケースは、単一のスレーブを持つオプションです。 この場合、デバイスが常にアクティブ状態になるように〜CS信号をグランドにプルすることができます。 ただし、スレーブは初期化またはその他のサービス目的でCS信号を使用できるため、これを行うことは非常に推奨されません。



スレーブの独立した接続の主な不便は、スレーブごとに個別の信号〜CSが必要なことです。 外国文学で「デイジーチェーン」（「ガーランド」と翻訳できる）と呼ばれるカスケード接続スキームには、このような欠点がありません。









上の図からわかるように、ここではすべてのスレーブに共通のスレーブ選択信号が使用されています。 各スレーブの出力は、次のスレーブの入力に接続されます。 最後のスレーブの出力はマスターの入力に接続されているため、閉回路を形成します。 この接続では、直列接続されたデバイスが1つの大きなシフトレジスタを形成すると仮定できます。 したがって、必要なパッケージを収集した後、接続の物理的な順序に対応する順序で各デバイスのデータを組み合わせて、すべてのデバイスにデータを「一度に」書き込むことができます。 ただし、微妙な点が1つあります。 まず、すべての超小型回路がこのタイプの接続をサポートする必要があります。 第二に、Linuxカーネルはこのタイプの接続をサポートしていないため、引き続き使用する場合は、既存のドライバーを変更するか、独自のドライバーを作成する必要があります。



SPIデバイスには4つの動作モードがあります。 原則として、初心者の間で最も混乱を引き起こすのは彼らです。 これらの4つのモードは、2ビットの組み合わせです。

• CPOL（クロック極性）-同期信号の初期レベル（極性）を決定します。
  
  CPOL = 0は、同期信号が低レベルで開始するため、立ち上がりエッジが立ち上がり、立ち下がりエッジが立ち下がることを示します。
  
  CPOL = 1、同期信号は高レベルで開始するため、立ち上がりエッジは立ち下がり、立ち上がりエッジは立ち上がります。
• CPHA（クロックフェーズ）-同期のフェーズで、クロック信号のどのエッジでデータをサンプリングするかを決定します。
  
  CPHA = 0は、立ち上がりエッジでサンプリングする必要があることを示します。
  
  CPHA = 1は、データを立ち下がりエッジでサンプリングする必要があることを示します。

これらの2ビットはモード番号を形成します。 CPOLは最上位ビットであり、CPHAは最下位ビットです。 デバイスのドキュメントにモード番号が明示的に示されていない場合もありますが、タイミング図からいつでも簡単に判断できます。 データのサンプリングとインストールは常にクロック信号の反対側のエッジで行われることを理解することも重要です。 たとえば、デバイスをモード0（最も一般的なオプション）で動作させます。この場合、スレーブデバイスはクロック信号の立ち上がりエッジに沿ってMOSI入力からデータビットを読み取り、マスターは立ち上がりエッジに沿ってMISO入力でスレーブからデータを読み取ります。 より明確にするために、4つの動作モードすべてのオシログラムを示します。



この図は、MOSI（青線）およびSCK（黄線）信号を示しています。 すべての場合において、番号0x64が送信されます。 明るい縦線は、データサンプリングの瞬間を示しています。 モード2について考えてみます。思い出してくださいが、CPOL = 1およびCPHA = 0です。 したがって、同期信号は最初は高レベルであり、サンプリングは立ち上がりエッジ（この場合は立ち下がり）で行われます。 私のオシロスコープには2つのチャンネルしかないため、〜CSおよびMISO信号は表示されません。 しかし、この場合、それらはあまりおもしろくありません。たとえば、〜CS信号は、データ転送全体を通して単純に「障害」です。

2. LinuxのSPIサブシステムの概要

Linux SPIドライバーは2つの部分に分かれています。 1つはSPIコントローラーのドライバーで、特定のコントローラーのハードウェアと直接連携します。 このようなドライバーは、コントローラーの構成方法、サスペンドモードへの切り替え（サスペンド）および終了（再開）、メッセージの送信キュー（spi_message、すぐ下のキューについて）からの次の送信（spi_transfer）の選択、および直接送信時に行うアクションを決定しますポートに対して、CSを介して特定のデバイスをアクティブ化/非アクティブ化する方法も決定されます（cs_activate / cs_deactivate関数）。 この記事では、このタイプのドライバーについては説明しません。 原則として、それらはLinuxポートが存在するMCU / eMPUに既に実装されており、外部から目的のスレーブデバイスをアクティブにできるように、チップセレクトデコードなどの特定の機能が必要な場合にのみそれらに登る必要がありますロジック。 これは、たとえばGPIOがない場合に役立つことがあります。



2番目の部分は、SPIバスに接続されているさまざまなスレーブで動作するために使用されるプロトコルドライバーです。 これらのドライバーは、「プロトコル」と呼ばれます。これは、機器と直接連携せずに、スレーブとの間でのみさまざまなデータを送受信するためです。 関心のあるスレーブのサポートをシステムに追加できるため、このタイプのドライバーが最も関心があります。これについて検討します。



ほとんどのプロトコルドライバーはカーネルモジュールです。 たとえば、デバイスがSPIを介して接続されたオーディオコーデックである場合、ドライバーはALSAが提供する機能も使用し、プログラム（たとえば、madplay）は、ハードウェアの構成方法について少しも考えずに、シンボルデバイス/ dev /オーディオを介してそれを操作できますどのバスが接続されているか。



カーネルは、キャラクターデバイスの形式のインターフェイスを備えた、spidevと呼ばれる汎用プロトコルドライバーも提供します。 これにより、標準のread（）およびwrite（）システムコールを使用してスレーブSPIデバイスに半二重呼び出しを行い、動作モードを設定し、ioctl（）呼び出しを介して全二重データ交換を実行できます。



したがって、SPIデバイスのプロトコルドライバーは2つのタイプに分類できます。

• ユーザー空間で動作し、通常のプログラムをあらゆる言語で表現し、対応するキャラクターデバイスspidevを読み書きすることによりSPIデバイスで動作するユーザー空間ドライバー。
• カーネルスペースで動作し、/ devディレクトリのデバイスファイルを介して、またはsysfsのデバイスディレクトリの属性を使用して、ユーザースペースのインターフェイスを提供するドライバー。

LinuxはSPIデバイスへのすべての呼び出しを呼び出します。 SPIプロトコルドライバーは、複数セグメントSPIトランザクションであるspi_message構造体によって表されるメッセージを明示的または暗黙的に処理します。

struct spi_message { struct list_head transfers; struct spi_device *spi; unsigned is_dma_mapped:1; void (*complete)(void *context); void *context; unsigned actual_length; int status; struct list_head queue; void *state; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

転送-トランザクション（転送）で送信されたセグメントのリンクリスト。

spi-このメッセージが置かれているキュー内のspiデバイスへのポインター。

is_dma_maped-このフラグがtrueの場合、各送信バッファーにdmaおよびcpu仮想アドレスの両方が提供されます。

complete-トランザクションの終了を通知するために呼び出されるコールバック。

context-コールバックする引数complete（）;

actual_length-すべての成功した転送で送信されたバイトの総数。

status-成功した場合は0、エラーの場合はerrnoの負の値。



spi_message構造は 、データ転送のアトミックシーケンスを実行するために使用されます。各データ転送は、 spi_transfer構造で表されます。 前のメッセージが完全に送信されるまで、 SPIバスを使用して別のspi_messageメッセージを送信できないという意味で、送信シーケンスは「アトミック」です。 一部のシステムでは、このようなシーケンスの多くは、単一のプログラムされたDMA送信として実行できます。 すべてのシステムで、これらのメッセージはキューに入れられ、他のデバイスとのトランザクションの後に完了することができます。 単一のスレーブへのすべての呼び出しは、常にFIFOの順序で実行されます。



struct spi_transfer構造体は、リンクされたメッセージリスト内の単一の送信を記述し、読み取り/書き込みバッファのペアを定義します。

 struct spi_transfer { const void *tx_buf; void *rx_buf; unsigned len; dma_addr_t tx_dma; dma_addr_t rx_dma; unsigned cs_change:1; u8 bits_per_word; u16 delay_usecs; u32 speed_hz; struct list_head transfer_list; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

tx_buf-送信するカーネルメモリ空間のデータバッファへのポインタ、またはNULL。

rx_buf-データを読み込むカーネルメモリ空間のデータバッファへのポインタ、またはNULL。

lenは、rxおよびtxバッファーのサイズ（バイト単位）です。

tx_dma-spi_message.is_dma_mappedが設定されている場合に使用されるDMAアドレスtx_buf。

rx_dma-DMAアドレスrx_buf。spi_message.is_dma_mappedが設定されている場合に使用されます。

speed_hz-デバイスのデフォルト値以外の伝送速度を設定します。 この値が0の場合、spi_device構造体のmax_speed_hzフィールドで指定されたデフォルトの速度が使用されます。

bits_per_word-デフォルトとは異なるワードあたりのビット数を設定します。 この値が0の場合、spi_device構造体のbits_per_wordフィールドで指定されたデフォルト値が使用されます。

delay_usecs-伝送の最後のビットが送信されてからチップセレクトの状態を変更するまで、またはキュー内の次の伝送の伝送を開始するまでのマイクロ秒単位のタイムアウト。 このパラメーターには細心の注意を払ってください。遅延が実装されているコントローラードライバーの部分を確認する必要があります。 たとえば、at91シリーズチップの場合、割り込みハンドラに実装されるため、その使用には結果が伴います。



spi_transfer構造を初期化するとき、非常に重要なポイントがあります。それらは、kmalloc、kzallocなどを介してDMAで使用可能なメモリ領域に割り当てる必要があります。 マスタードライバーがdmaを使用している場合、静的に宣言された配列を使用すると、転送しようとしたときにドライバーがクラッシュします。



SPIを介してデータを送信する場合、記録されたビット数は常に読み取られたビット数と等しくなります。 プロトコルドライバーは、常にtx_bufバッファーまたはrx_bufバッファーへのポインターを提供する必要があります。 場合によっては、送信データのDMAアドレスを提供する場合があります。



各転送のデータ転送レートとワードあたりのビット数を個別に無効にする機能は、特定のドライバーの実装とコントローラーのハードウェア機能に依存します。 たとえば、at91シリーズチップのSPIコントローラーの場合、フィールドspeed_hzおよびbits_per_wordを再定義する可能性は提供されないため、常に0に設定する必要があります。そうしないと、データを転送しようとしたときにエラーが発生します。



tx_bufへのポインターがNULLに設定されている場合、SPIコントローラーはrx_bufバッファーがいっぱいになるとゼロをポップアウトします。 rx_bufがNULLに設定されている場合、読み取られたデータは無視されます。 プッシュ（およびキャプチャ）されるバイト数は常にlenです。 単語の一部のみをプ​​ッシュしようとすると、エラーが発生します。 （たとえば、3バイトと16ビットまたは20ビットのワード長をプッシュしようとする場合、最初のケースではワードごとに2バイトが使用され、2番目では4バイトが使用されます）。



送信するデータは、常に特定のハードウェアプラットフォームに固有の順序で保存されます。 データの送信/読み取り時に、バイト順序はSPI固有（SPI_LSB_FIRSTパラメーターが設定されていない限り、通常ビッグエンディアン）からこのCPUのハードウェア固有の順序に自動的に変換されます。 たとえば、bits_per_wordパラメーターが16の場合、バッファーは2Nバイトを占有し、このCPUに固有のバイト順で格納された、それぞれ16ビットの長さのNワードを含みます。



ワードサイズが2のべき乗でない場合、メモリ内のワードの表現には追加のビットが含まれます。 プロトコルドライバー用にメモリに保存されている単語は常に右揃えであるため、余分なビットは常に高位ビットになります。

わかりやすくするために、もう一度オシログラムを示します。



この場合、txバッファーには値0xf98eが含まれ、設定値bits_per_wordはワードあたり12ビットに対応します。 デバイスはSPI_MODE_0で実行されています。 図では、青い線がMOSIコントローラーの出力に対応し、黄色の線がSCKに対応しています。 ここでは、送信中に0x098eのみが送信され、上位4ビットは追加と見なされるため、破棄されたことが明確にわかります。 非常に単純な場合、1つの12ビットワードがメモリの2バイトを占有し、メモリのワードサイズと実際のサイズの差は2 * 8-12 = 4ビットであり、送信中に破棄されます。



すべてのSPI転送は、対応するチップセレクトのアクティブ化から始まります。 通常、スレーブはメッセージの最後の送信までアクティブのままです。 ドライバーは、 spi_transfer構造体のcs_changeフラグを使用してcsの状態を変更できます。

• 送信がメッセージの最後ではない場合、cs_changeフラグを使用して、メッセージの途中でチップセレクトを一時的に非アクティブにします。 スレーブコマンドを完了するには、このようなcsスイッチが必要になる場合があります。 これにより、1つのspi_messageを使用して、1つのスレーブの送信グループをすぐに実行できます。
• 送信がメッセージの最後の場合、スレーブは次のメッセージの送信が開始されるまで選択されたままになります。 別のデバイスへのメッセージ送信の開始により、現在のcsが非アクティブ化されます。 一部のデバイスが機能するには、トランザクションはspi_messageメッセージキューで構成されている必要があります。後続のメッセージの内容は、以前のメッセージの結果に依存します。 この場合、トランザクションはcsを非アクティブ状態にすることで完全に完了します。

spi_message （およびそのspi_transferの）を下位レベルに渡すコードは、これらの構造のメモリを管理します。 明示的に定義されていない構造体のフィールドはすべて、ゼロに初期化する必要があります。 メッセージ（およびその中の個々の送信）を送信した後、このメッセージを完了するためのコールバックが機能するまで、後続のメッセージを無視する必要があります。



SPIは、自動デバイス検出メカニズムをサポートしていません。 さらに、ほとんどの場合、SPIデバイスはホットプラグ/アンプラグを提供しないため、通常はボードに直接はんだ付けするだけです。 この点で、これらのデバイスはボード固有と見なされます。 このようなデバイスのパラメーターは、ボードファイルに示されています：arch /.../ mach-* / board-*。C.

たとえば、SK-AT91SAM9260デバッグボードのtlv320aic23bオーディオコーデックのパラメーター設定は次のようになります。

 static struct spi_board_info ek_spi_devices[] = { { /* tlv320aic23b CODEC */ .modalias = "tlv320aic23b", .chip_select = 0, .max_speed_hz = 10 * 1000 * 1000, .bus_num = 1, .mode = SPI_MODE_1, .platform_data = &tlv320aic23b_data, }, … }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

modaliasは、デバイスの保守を担当するカーネルドライバーの名前です（この例では、「tlv320aic23b」）。

chip_select-対応するチップセレクトの番号。

max_speed_hz-Hz単位の最大周波数。

mode-定数SPI_MODE_0 ... SPI_MODE_3で定義されたSPIモード。ビット単位の「or」操作でもSPI_CS_HIGHフラグを追加できます（チップセレクトのアクティブをハイレベルに設定）、SPI_NO_CS（原則としてCSアクティベーションなしのデータ転送）。 可能なフラグの完全なリストは、 spi_device構造体の説明にあります。

bus_num-バス番号（通常、MCU / eMPUのデータシートにあるコントローラーのSPI番号に対応）。

spi_board_info構造には、上記の例で初期化されていない次のフィールドも含まれています。

const void * platform_data-このフィールドは、特定のドライバーに固有のデータへのポインターを格納するためのものです。

void * controller_data-一部のコントローラーでは、DMAなどのデバイス構成に関する情報が必要です。

int irq-デバイスの接続に依存します。



spi_board_info構造体のすべてのフィールドは、 spi_device構造体の対応するフィールドを設定します。

他のSPIデバイスのパラメーターを設定する必要がある場合、同様の要素が配列に追加されます。

これらの構造には、ドライバーが常に判断できるわけではない情報が格納されます。 ドライバのプローブ（）機能によって決定できる情報（たとえば、1ワードあたりのビット数）は、この構造には含まれません。



スレーブSPIデバイスをホットプラグする可能性がまだあることに注意してください。 この場合、 spi_busnum_to_master（）関数を使用して、SPIバス番号でspi_master構造体へのポインターを取得し、バス上のデバイスを反復処理します。 しかし、このトピックはこの記事の範囲外です。



第二部を読む