Software Platform の導入

Introduction to the Software Platform
  Organization of the Software Platform
  Using the Software Platform Builder
  Glossary
 
Software Platform は、ハードウェアデザインでペリフェラルへアクセスするために容易にソフトウェアを記述するためのソフトウェアの構成です。また、それはソフトウェアプロトコルを容易に実行でき、マルチスレッディングのようなアプリケーションで使用できる機能を提供します。本質的にそれは、ソフトウェアモジュールの集まりでソースコードとして渡されます。ペリフェラルをコントロール、またはアクセスするために必要な様々なローレベルのルーチンを処理するために、これらのモジュールをエンベデッドプロジェクトへ追加できます。また、各モジュールは特定の機能性（例えば、ボーレートを変更する機能 set_baudrate()）を提供し、アプリケーションへのインターフェースとなります。
Software Platform Builder は、エンベデッドプロジェクトを設定したり、モジュールを追加するために使用するグラフィカルユーザインターフェースです。Software Platform を作成するためにSoftware Platform Builder を使用します。エンベデッドプロジェクトへ特定のドキュメントを追加する時（拡張子 .SwPlatform の_Software Platform file_）、Software Platform Builder は利用できます。このドキュメントは、プロジェクトの Software Platform を表し、必要な機能性を選択、設定するためのグラフィカルインターフェースを提供します。必要なものは、アプリケーションでアクセスしたいハードウェアデザインのペリフェラルに依存します。　
Software Platform Builder は、FPGA デザインを読み、FPGA デザインのペリフェラルのためにローレベルのモジュールを インポート できます。開始点としてこのインポートを使用し、抽象的なレベルの機能を Software Platform ファイルへ追加できます。　

Software Platform Builder の使用方法が記載されたチートリアルについては、チュートリアル - Software Platform Builder 入門　を参照してください。　

Software Platform が必要な理由　　

ペリフェラルへアクセス、またはコントロールするソフトウェアを書き込むには、ペリフェラルの知識（必要なレジスタ、使用するデバイス特定のコマンド、使用する通信プロトコル、処理する割り込み）が必要です。　

簡単なデザイン環境

簡単な FPGA デザインについて、ソフトウェア自体を記述することは複雑ではありません。例えば、LED の列をコントロールするには、アドレスへ 8 ビットバイナリを記述する必要があります。そのアドレスは、FPGA のペリフェラルの場所になり NanoBoard 上の LED を接続します。それは、プロセッサ I/O 空間（例えば、0xFF000000）の最初のアドレスになります。もし、そのアドレスへ C ソースで記述する場合、LED はそれに応じて動作します。　 　
デバイス特定のコマンド、割り込み処理、特定のレジスタ、通信プロトコル、特定のデータ処理は必要ありません。それは、手動でこのデザインのソフトウェアを記述するのが容易です。この簡単な例では、LED のベースアドレスは FPGA デザインで定義され、ハードウェアデザインを変更する場合、無効になるかもしれないため C コードは完全なポータブルではありません。　　

より複雑なデザインの状況　

しかし、より複雑なペリフェラルをコントロールしたい時、手に負えなくなります。PS/2 キーボードを含むデザインを想像してください。エンドユーザは例えば、"Shift + A" を押すかもしれません。そして、アプリケーションの目的は後で使用するために変数の大文字の 'A' を保存することです。これは、簡単に見えますが表面下で扱う必要があります。　

• 最も低いレベルで、PS/2 ポートのベースアドレスや、ポートのクロックラインやデータラインをアクセスするアドレスを定義して、PS/2 ポートへ接続する必要があります。 　
• 次のレベルでは、アプリケーションが PS/2 ペリフェラル上でキーボードから割り込みを受け取る準備ができている必要があります。正しく割り込みを処理する必要があり、PS/2 ポートのデータラインから次に来るデータを読み出します。キーボードは、11ビット フレームのシリアルデータを送ります。複数のフレームはスキャンコードを作成します。それは、キーボード（例えば、キーを押す、またはキーを開放）で可能なイベントを表します。
• より高いレベルで、データを収集しスキャンコードを保存する必要があります。スキャンコードは 1 から 8 バイトまで可能です（例えば、0xC1 は 'A' キーを押すことに相当し、0xF0 0xC1 は 'A' キーを離すことに相当します）。　
• 最高レベルで、正しいキーへスキャンコードをマップして認識する必要があります。また、キーの組み合わせを見つける必要があります。この例では、コード（大文字 'A' として認識すべき）を作成する 'A' キーを受け取る前に、Shift キーを押す（コードを作成する）スキャンコードを受け取ったことを思い出す必要があります。認識された入力は正しく処理する必要があります。　

この説明は完全ではありませんが（送信データから抽出、キーボードの初期化等）、これは PS/2 キーボードのようにペリフェラルデバイスを扱うソフトウェアを記述する必要がある時、複雑さを表します。　
この段階で Software Platform を導入します。Software Platform のモジュールはよりローレベルのルーチンを扱います。そして、アプリケーションがコントロールする必要がある各ペリフェラルの Application Programming Interface を容易に使用できます。　

Software Platform とは何ですか?　

Software Platform は、アプリケーションで使用できる便利な API と共に機能性を提供するモジュールと同様に、ローレベルのソフトウェアルーチンを扱う多くのソフトウェアモジュールを提供します。　
最もローレベルのモジュールは、特定のペリフェラルデバイスのコンフィギュレーションデータやドライバを提供します。よりハイレベルのモジュールはより抽象的で独立したハードウェアです。例えば、より高く抽象的レベルで、アプリケーションのファイルシステムへアクセスするモジュールを使用するために選択できます。よりローレベルで、アクセスしたい特定のストレージデバイス（ハードドライブ、SD カード、ram ドライブ）を決めるためにモジュールを選択できます。このように、よりローレベルのモジュールはより特定のペリフェラルです。ハイレベルのモジュールはハードウェアが少なく複数のペリフェラルデバイスと組み合わせて使用できます。　　

エンベデッドプロジェクトで Software Platform を使用　

 
Altium Designer でエンベデッドプロジェクトがある時、拡張子 .SwPlatform の特定のドキュメントをプロジェクトへ追加できます。このドキュメントは通常のソースドキュメントではなく、ソフトウェアモジュールをグラフィカルに表現したものです。
この Software Platform "ドキュメント" は、ソフトウェアモジュール選択するために使用するグラフィカルユーザインターフェース Software Platform Builder を提供します。これらのモジュールで device stacks（よりハイレベルのモジュールはよりローレベルのモジュールへ配置されます）を形成できます。スタックにモジュールを多く、または少なく配置することで、アプリケーションで使用したい抽象的なレベルを選択できます。 　
例えば、PS/2 キーボードは各抽象的なレベルごとに 4 つのモジュールを選択できます。図はスタックの例を示します。各色分けされたブロックはソフトウェアモジュールを表します。一般的に（特に指定しない限り）、最もハイレベルのモジュールはアプリケーションへインターフェースを提供します。
このサンプルの PS/2 キーボードのスタックでは、トップレベルモジュールは、キーボードへアクセスするための標準の C インターフェースを提供する Keyboard I/O Context です。これは、よりローレベルの関数の turn call に関して、アプリケーションでコールできるのは標準の C 関数のためです。そのモジュールは、これらのローレベルの C I/O 関数を実行できます。この例で、以下のローレベルの関数は特定の実行方法があります:

次の項目ではモジュールを構成する方法と、スタックを組み立てる方法について紹介します。　

技術的な背景

以前に記述した通り、Software Platform からのモジュールは設定できるソフトウェアパッケージです（Software Platform ドキュメントへソースコードを追加する時、エンベデッドプロジェクトの一部になるソースコードとして渡されます）。エンベデッドプロジェクトをコンパイルする時、選択したモジュールはソフトウェアライブラリへコンパイルされます。アプリケーションからライブラリの関数をコールした後、このライブラリはエンベデッドプロジェクトと共にリンクされます。　
そのライブラリは、毎回、再コンパイルします。Software Platform がエンベデッド設定で変更がある度にそのライブラリは、毎回、再コンパイルします。

生成されたソフトウェアプラットフォーム ライブラリ　

Software Platform が設定（指定した設定に基づいた）を保存する度に、ライブラリを構築するための情報を含む makefile を生成します。この makefile は全体的なコンパイルオプション（インターフェースが見えるか、または見えないかどうかのような中でもマクロ定義やソースの特定のコンパイルオプション）を含みます。　　
一般的に、コンパイルするファイルは 2 つ（permanent と generated ファイル）に分割できます。 permanent ソースは Software Platform のリポジトリを決め、それらのコードはエンベデッドプロジェクト間で共有されます。generated ファイルは各新しい設定の Software Platform によって出力され、プロジェクト固有になります。これらの生成されたファイルは、エンベデッドデータ、タイプ、マクロを含む C ソースファイルです。エンベデッドプロジェクトを構築する時、permanent と generated ファイルはプロジェクトと一緒にリンクするライブラリを形成するためにコンパイルされます。 　

モジュールの Instantiation

プロジェクトの一部にするために選択するモジュールは instances になると言うことを理解することが重要です。モジュールはグローバルに設定できます。しかし、一度、instantiate した場合（global configuration 設定と一緒に）、同じモジュールの複数の instance は個別に設定できます。言い換えると、モジュールを特定の設定と共に構築する時、どのモジュールをエンベデッドプロジェクトの一部にするか指定します。この結合された情報は Software Platform ライブラリ（選択したモジュールの instance を含みます）を構築するために使用します。この方法で生成したライブラリは常に特定のプロジェクト用になります。　

結論

Software Platform では、ソフトウェアをより容易に開発するために作成済みのソフトウェアモジュールを利用できます。それには、知る必要があるハードウェアの情報や通信プロトコルが含まれています。また、モジュールの設定（特定の Software Platform ドキュメントを修正して）を素早く変更できるため、Software Platform は移動可能で、ハードウェアの独立したアプリケーションとして書き込めます。これは、アプリケーションを再書き込みしないでハードウェアデザインを変更できます。