Nios II ソフトウェア開発ハンドブック Version 1...iv Altera Corporation Preliminary...

101 Innovation DriveSan Jose, CA 95134(408) 544-7000http://www.altera.com

Nios II ソフトウェア開発ハンドブック

NII5V2-1.2/JP

http://www.altera.com

myoshida

Text Box

この資料は、更新された最新の英語版が存在します。こちらの日本語版は参考用としてご利用下さい。設計の際は、必ず最新の英語版で内容をご確認下さい。

Copyright © 2004 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, the stylized Altera logo, specific device des-ignations, and all other words and logos that are identified as trademarks and/or service marks are, unless noted otherwise, the trademarks andservice marks of Altera Corporation in the U.S. and other countries. All other product or service names are the property of their respective holders. Al-tera products are protected under numerous U.S. and foreign patents and pending applications, maskwork rights, and copyrights. Altera warrantsperformance of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to makechanges to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the ap-plication or use of any information, product, or service described herein except as expressly agreed to in writing by AlteraCorporation. Altera customers are advised to obtain the latest version of device specifications before relying on any published in-formation and before placing orders for products or services.

Printed on recycled paper

ii Altera Corporation

Altera Corporation iiiPreliminary

目次

章の改定日 ...................................................................................................................... ix

このハンドブックについて ............................................................................................. xiアルテラへのお問い合わせ ......................................................................................................................................... xi表記規則 ......................................................................................................................................................................... xi

セクション I. Nios IIソフトウェア開発改定履歴 .................................................................................................................................................. セクション I–1

第 1章概要はじめに ....................................................................................................................................................................... 1–1使用開始にあたって ................................................................................................................................................... 1–1開発環境 ....................................................................................................................................................................... 1–2ツール ..................................................................................................................................................................... 1–2一貫した開発環境 ................................................................................................................................................. 1–3一貫したランタイム環境 ..................................................................................................................................... 1–4

サードパーティ・サポート ....................................................................................................................................... 1–4第 1世代のNiosプロセッサからの移行 ................................................................................................................. 1–4Nios II に関するその他の情報 .................................................................................................................................. 1–5

第 2章 Nios II IDEの紹介はじめに ....................................................................................................................................................................... 2–1Nios II IDEワークベンチ ........................................................................................................................................... 2–1パースペクティブ、エディタ、およびビュー ................................................................................................. 2–2

新規プロジェクトの作成 ........................................................................................................................................... 2–2プロジェクトのビルドと管理 ................................................................................................................................... 2–4プログラムの実行とデバッグ ................................................................................................................................... 2–6フラッシュのプログラミング ................................................................................................................................... 2–9オンライン・ヘルプ ................................................................................................................................................. 2–10

iv Altera CorporationPreliminary

目次 Nios II ソフトウェア開発ハンドブック

セクション II. HALシステム・ライブラリ改定履歴 ................................................................................................................................................. セクション II–1

第 3章 HALシステム・ライブラリの概要はじめに ....................................................................................................................................................................... 3–1使用開始にあたって ................................................................................................................................................... 3–1HALアーキテクチャ .................................................................................................................................................. 3–2サービス ................................................................................................................................................................. 3–2アプリケーションとドライバ ............................................................................................................................. 3–3汎用デバイス・モデル ......................................................................................................................................... 3–3C標準ライブラリ— Newlib ............................................................................................................................... 3–5

サポートされているペリフェラル ........................................................................................................................... 3–6

第 4章 HALを使用したプログラムの開発はじめに ....................................................................................................................................................................... 4–1Nios II IDEプロジェクト構造 ................................................................................................................................... 4–1system.hシステム記述ファイル ............................................................................................................................... 4–3データ幅と HAL型の定義 ......................................................................................................................................... 4–4UNIX形式のインタフェース .................................................................................................................................... 4–5ファイル・システム ................................................................................................................................................... 4–6キャラクタ・モード・デバイスの使用 ................................................................................................................... 4–7標準入力、標準出力および標準エラー ............................................................................................................. 4–8キャラクタ・モード・デバイスへの汎用アクセス ......................................................................................... 4–8C++ストリーム ..................................................................................................................................................... 4–9/dev/null ............................................................................................................................................................... 4–9

ファイル・サブシステムの使用 ............................................................................................................................... 4–9タイマ・デバイスの使用 ......................................................................................................................................... 4–10

HALシステム・クロック .................................................................................................................................. 4–10アラーム ............................................................................................................................................................... 4–11高精度時間測定 ................................................................................................................................................... 4–12

フラッシュ・デバイスの使用 ................................................................................................................................. 4–14シンプル・フラッシュ・アクセス ................................................................................................................... 4–15ブロックの消去または破壊 ............................................................................................................................... 4–17高精度フラッシュ・アクセス ........................................................................................................................... 4–18

DMAデバイスの使用 .............................................................................................................................................. 4–20DMA送信チャネル ............................................................................................................................................ 4–21DMA受信チャネル ............................................................................................................................................ 4–23メモリ間 DMA転送 ........................................................................................................................................... 4–24

コード・フットプリントの削減 ............................................................................................................................. 4–26コンパイラ最適化の有効化 ............................................................................................................................... 4–26スモール・フットプリント・デバイス・ドライバの使用 ........................................................................... 4–26ファイル・ディスクリプタ・プールの削減 ................................................................................................... 4–27/dev/nullの使用 ................................................................................................................................................ 4–27ANSI Cではなく UNIXファイル I/Oの使用 ............................................................................................... 4–28縮小版 Newlib Cライブラリの使用 ................................................................................................................. 4–28未使用デバイス・ドライバの除去 ................................................................................................................... 4–30非完全終了に対する _exit()の使用 .................................................................................................................. 4–30命令エミュレーションの無効化 ....................................................................................................................... 4–31

Altera Corporation vPreliminary

目次目次

ブート・シーケンスおよびエントリ・ポイント ................................................................................................. 4–31ホスト型アプリケーションと独立型アプリケーション ............................................................................... 4–31HALベース・プログラムのブート・シーケンス .......................................................................................... 4–32ブート・シーケンスのカスタマイズ ............................................................................................................... 4–33

メモリの使用 ............................................................................................................................................................. 4–34メモリ・セクション ........................................................................................................................................... 4–34メモリ・パーティションへのコードとデータの割り当て ........................................................................... 4–35ヒープおよびスタックの配置 ........................................................................................................................... 4–37ブート・モード ................................................................................................................................................... 4–37

HALシステム・ライブラリ・ファイルへのパス ................................................................................................ 4–38HALファイルの検出 .......................................................................................................................................... 4–38HAL関数の置き換え .......................................................................................................................................... 4–38

第 5章 HAL用デバイス・ドライバの開発はじめに ....................................................................................................................................................................... 5–1

HAL APIへの統合 ................................................................................................................................................ 5–1ペリフェラル固有の API ...................................................................................................................................... 5–2必要な知識 ............................................................................................................................................................. 5–2

デバイス・ドライバ作成の開発フロー ................................................................................................................... 5–2SOPC Builderの概念 .................................................................................................................................................. 5–3

system.hと SOPC Builderの関係 ...................................................................................................................... 5–3最適なハードウェア・コンフィギュレーションを目的とした SOPC Builderの使用 ............................... 5–3コンポーネント、デバイス、およびペリフェラル ......................................................................................... 5–3

ハードウェアへのアクセス ....................................................................................................................................... 5–3HALデバイス・クラス用ドライバの作成 .............................................................................................................. 5–5キャラクタ・モード・デバイス・ドライバ ..................................................................................................... 5–5ファイル・サブシステム・ドライバ ................................................................................................................. 5–8タイマ・デバイス・ドライバ ............................................................................................................................. 5–9フラッシュ・デバイス・ドライバ ................................................................................................................... 5–10DMAデバイス・ドライバ ................................................................................................................................ 5–11イーサネット・デバイス・ドライバ ............................................................................................................... 5–14

HALへのデバイス・ドライバの統合 .................................................................................................................... 5–17HALデバイスのディレクトリ構造 .................................................................................................................. 5–17HAL用デバイス・ドライバ・ファイル .......................................................................................................... 5–17要約 ....................................................................................................................................................................... 5–21

ドライバ・フットプリントの削減 ......................................................................................................................... 5–22ネーム空間の割り当て ............................................................................................................................................. 5–22デフォルト・デバイス・ドライバの置き換え ..................................................................................................... 5–23

セクション III. 高度なプログラミング手法改定履歴 ................................................................................................................................................セクション III–1

第 6章例外処理はじめに ....................................................................................................................................................................... 6–1Nios II例外の概要 ...................................................................................................................................................... 6–1HAL実装 ...................................................................................................................................................................... 6–2

_irq_entry ............................................................................................................................................................... 6–3alt_irq_handler() .................................................................................................................................................... 6–3software_exception ............................................................................................................................................... 6–4

vi Altera CorporationPreliminary


ISR ................................................................................................................................................................................. 6–6ISR用 HAL API ..................................................................................................................................................... 6–7alt_irq_register()を使用した ISRの登録 ........................................................................................................... 6–7ISRの記述 .............................................................................................................................................................. 6–8ISRのイネーブルおよびディセーブル ............................................................................................................ 6–10Cの例 .................................................................................................................................................................... 6–11

高速 ISR処理 ............................................................................................................................................................. 6–12ISRの性能データ ...................................................................................................................................................... 6–13ISR使用のデバッグ .................................................................................................................................................. 6–14ISRの記述に関する提案の要約 .............................................................................................................................. 6–15

第 7章キャッシュ・メモリはじめに ....................................................................................................................................................................... 7–1

Nios IIのキャッシュ実装 .................................................................................................................................... 7–1キャッシュ管理用 HAL API関数 ....................................................................................................................... 7–2その他の情報 ......................................................................................................................................................... 7–2

リセット後のキャッシュの初期化 ........................................................................................................................... 7–3HALシステム・ライブラリ・ユーザの場合 .................................................................................................... 7–4

デバイス・ドライバの記述 ....................................................................................................................................... 7–4HALシステム・ライブラリ・ユーザの場合 .................................................................................................... 7–5

プログラム・ローダまたは自己書き換えコードの記述 ....................................................................................... 7–6HALシステム・ライブラリ・ユーザの場合 .................................................................................................... 7–6

マルチ・マスタ /マルチ CPUシステムの管理 ..................................................................................................... 7–7ビット 31キャッシュ・バイパス ....................................................................................................................... 7–7HALシステム・ライブラリ・ユーザの場合 .................................................................................................... 7–8

第 8章 MicroC/OS-IIリアルタイム・オペレーティング・システムはじめに ....................................................................................................................................................................... 8–1概要 ............................................................................................................................................................................... 8–1その他の情報 ......................................................................................................................................................... 8–1ライセンス ............................................................................................................................................................. 8–2

その他の RTOSプロバイダ ....................................................................................................................................... 8–2アルテラによるMicroC/OS-IIの移植 .................................................................................................................... 8–2

MicroC/OS-IIアーキテクチャ ........................................................................................................................... 8–3MicroC/OS-IIのスレッド対応デバッグ ........................................................................................................... 8–3MicroC/OS-IIデバイス・ドライバ ................................................................................................................... 8–4スレッド・セーフ HALドライバ ....................................................................................................................... 8–4Newlib ANSI C標準ライブラリ ......................................................................................................................... 8–6

Nios II IDEでのMicroC/OS-IIプロジェクトの実装 ........................................................................................... 8–7MicroC/OS-IIの一般オプション ....................................................................................................................... 8–8イベント・フラグ設定 ......................................................................................................................................... 8–8相互排除の設定 ..................................................................................................................................................... 8–9セマフォの設定 ..................................................................................................................................................... 8–9メールボックスの設定 ....................................................................................................................................... 8–10キューの設定 ....................................................................................................................................................... 8–10メモリ管理の設定 ............................................................................................................................................... 8–11その他の設定 ....................................................................................................................................................... 8–11タスク管理の設定 ............................................................................................................................................... 8–12時間管理の設定 ................................................................................................................................................... 8–12

Altera Corporation viiPreliminary

目次目次

第 9章イーサネットと Lightweight IPはじめに ....................................................................................................................................................................... 9–1

Nios IIプロセッサ用 lwIP ................................................................................................................................... 9–1lwIPファイルとディレクトリ ............................................................................................................................ 9–2ライセンス ............................................................................................................................................................. 9–3

その他の TCP/IPスタック •プロバイダ ............................................................................................................... 9–3lwIPプロトコル •スタックの使用 .......................................................................................................................... 9–3

Nios IIのシステム要求 ........................................................................................................................................ 9–4lwIPタスク ............................................................................................................................................................ 9–4スタックの初期化 ................................................................................................................................................. 9–5ソケット・インタフェースの呼び出し ........................................................................................................... 9–10

Nios II IDEでの lwIPのコンフィギュレーション .............................................................................................. 9–10Lightweight TCP/IPスタックの一般的な設定 .............................................................................................. 9–11IPオプション ....................................................................................................................................................... 9–11ARPオプション .................................................................................................................................................. 9–12UDPオプション .................................................................................................................................................. 9–12TCPオプション ................................................................................................................................................... 9–12DHCPオプション ............................................................................................................................................... 9–12メモリ・オプション ........................................................................................................................................... 9–13

確認されている制限事項 ......................................................................................................................................... 9–13

セクション IV. 付録改定履歴 ............................................................................................................................................... セクション IV–1

第 10章 HAL APIリファレンスはじめに ..................................................................................................................................................................... 10–1標準型 ....................................................................................................................................................................... 10–70

第 11章アルテラの開発ツールはじめに ..................................................................................................................................................................... 11–1Nios II IDEツール ..................................................................................................................................................... 11–1アルテラのコマンドライン・ツール ..................................................................................................................... 11–2GNUコンパイラ・ツール・チェイン ................................................................................................................... 11–5ライブラリおよびエンベデッド・ソフトウェア・コンポーネント ................................................................. 11–5

第 12章リード・オンリ zipファイル・システムはじめに ..................................................................................................................................................................... 12–1プロジェクトでの zipファイル・システムの使用 .............................................................................................. 12–1

zipファイルの準備 ............................................................................................................................................. 12–2フラッシュへの zipファイルのプログラミング ............................................................................................ 12–2

索引

viii Altera CorporationPreliminary


Altera Corporation ixPreliminary

改定日付

本書「Nios II ソフトウェア開発ハンドブック」の各章の改訂日付は以下のとおりです。各章は、それぞれ個別に提供されており、資料番号は以下を参照して下さい。

第 1章概要改定日 : 2004年 5月パーツ番号 : NII52001-1.0

第 2章 Nios II IDEの紹介改定日 : 2004年 9月パーツ番号 : NII52002-1.1

第 3章 HALシステム・ライブラリの概要改定日 : 2004年 5月パーツ番号 : NII52003-1.0

第 4章 HALを使用したプログラムの開発改定日 : 2004年 12月パーツ番号 : NII52004-1.2

第 5章 HAL用デバイス・ドライバの開発改定日 : 2004年 12月パーツ番号 : NII52005-1.1

第 6章例外処理改定日 : 2004年 12月パーツ番号 : NII52006-1.2

第 7章キャッシュ・メモリ改定日 : 2004年 5月パーツ番号 : NII52007-1.0

第 8章 MicroC/OS-IIリアルタイム・オペレーティング・システム改定日 : 2004年 12月パーツ番号 : NII52008-1.1

第 9章イーサネットと Lightweight IP改定日 : 2004年 12月パーツ番号 : NII52009-1.2

第 10章 HAL APIリファレンス改定日 : 2004年 12月パーツ番号 : NII52010-1.2

x Altera CorporationPreliminary

改定日付 Nios II ソフトウェア開発ハンドブック

第 11章アルテラの開発ツール改定日 : 2004年 12月パーツ番号 : NII520011-1.1

第 12章リード・オンリ zipファイル・システム改定日 : 2004年 5月パーツ番号 : NII520012-1.0

Altera Corporation xi

このハンドブックについて

本ハンドブックでは、アルテラの Nios® II プロセッサ・ソフトウェアの総合的な情報を提供しています。

アルテラへのお問い合わせ

アルテラ製品に関する最新情報は、アルテラのWebサイト、www.altera.comをご覧ください。テクニカル・サポートについては、www.altera.com/mysupport にアクセスしてください。また、アルテラの販売代理店にもお問い合わせいただけます。

表記規則本ハンドブックでは、以下の表記規則を使用しています。

書体意味

太字かつ文頭が大文字コマンド名、ダイアログ・ボックス・タイトル、チェックボックス・オプション、およびダイアログ・ボックス・オプションは、太字かつ文頭が大文字で表記されています。例：Save Asダイアログ・ボックス。

太字外部タイミング・パラメータ、ディレクトリ名、プロジェクト名、ディスク・ドライブ名、ファイル名、ファイルの拡張子、およびソフトウェア・ユーティリティ名は、太字で表記されています。例：fMAX, \qdesignsディレクトリ、d:ドライブ、chiptrip.gdfファイル。

文頭が大文字キーボード・キーおよびメニュー名は、文頭が大文字で表記されています。例：Deleteキー、Optionsメニュー。

「小見出しタイトル」資料内の小見出しおよびオンライン・ヘルプ・トピックのタイトルは、鉤括弧で囲んでいます。例：「表記規則」。

Courierフォント信号およびポート名は、Courierフォントで表記されています。例：data1、tdi、input。アクティブ Low信号は、サフィックス nで表示されています（例：resetn）。

表示されている通りに入力する必要のあるものは、Courierフォントで表記されています（例：c:\qdesigns\tutorial\chiptrip.gdf）。また、Reportファイルのような実際のファイル、ファイルの構成要素（例：AHDLキーワードの SUBDESIGN）、ロジック・ファンクション名（例：TRI）も、Courierフォントで表記されています。

1.、2.、3.、およびa.、b.、c.など

手順など項目の順序が重要なものは、番号が付けられリスト形式で表記されています。

■ ● • 箇条書きの黒点などは、項目の順序が重要ではないものに付いています。

√ チェックマークは、1ステップしかない手順を表します。

http://www.altera.com

http://www.altera.com/mysupport

http://www.altera.com/mysupport

xii Altera Corporation

表記規則 Nios II ソフトウェア開発ハンドブック

指差しマークは、要注意箇所を表しています。

CAUTIONマークは、特別な配慮および理解が必要であり、手順またはプロセスを始める前、または続ける際に確認すべき情報を示しています。

注意マークは、手順またはプロセスを始める前、または続ける際に確認すべき情報を示しています。

矢印は、Enterキーを押すことを示しています。

足跡マークは、詳細情報の参照先を示しています。

書体意味

Altera Corporation セクション I–1

セクション I. Nios IIソフトウェア開発

このセクションでは、Nios® IIソフトウェア開発の概要を説明します。

このセクションは、以下の章で構成されています。

■ 第 1章　概要

■ 第 2章　Nios II IDEの紹介

改定履歴以下の表に、各章の改定履歴を示します。これらのバージョンは資料の改定を追跡しているのもので、Nios II 開発キットや Nios II プロセッサのバージョンには関係ありません。

章日付 /バージョン変更内容

1 2004年 5月v1.0

初版

2 2004年 9月v1.1

スクリーン・ショットの更新

2004年 5月v1.0

初版

myoshida

Text Box


セクション I–2 Altera Corporation

Nios IIソフトウェア開発 Nios II ソフトウェア開発ハンドブック

Altera Corporation 1–12004年 5月 Preliminary

1. 概要

はじめにこの章では、ソフトウェア開発者を対象として、Nios® II プロセッサの概要を説明します。Nios II ソフトウェア開発環境、使用可能なツール、およびソフトウェア開発のためのプロセスを紹介します。

使用開始にあたって

Nios II プロセッサ用ソフトウェアの作成は、他社のマイクロコントローラ・ファミリと似ています。アルテラから開発キットを購入すれば、設計が簡単に、かつ効率的に開始することができます。この開発キットには、資料、開発ボード、および Nios II プログラムを作成するのに必要なすべての開発ツールが含まれています。

Nios IIソフトウェア開発ハンドブックでは、読者にエンベデッド・プロセッサのコンセプトに関する基本的な知識があることを想定して作成されていますが、アルテラの特定のテクノロジやアルテラの開発ツールに関する知識は必要ありません。アルテラ・ハードウェア開発ツールに関する知識があれば、Nios II ソフトウェア開発環境の背景にある論理をより深く理解することができます。ただし、ソフトウェア開発者は、NiosII ソフトウェア開発ツールの背後にあるアルテラ・テクノロジの詳しい知識がなくても、アプリケーションの開発やデバッグを行うことができます。

ソフトウェア設計者が、新しい環境でプログラムの作成方法を習得するには、おそらく既存のコードを書き換えるのが、最も一般的で安心できる方法と考えられます。Nios II 開発キットには、ソフトウェア設計例が多数用意されており、設計者はこれらを自身のプログラムで検証、修正、および使用することができます。用意された例は、単純な「Hello World」プログラムから、実用的なリアルタイム・オペレーティング・システム（RTOS）の例、そしてWebサーバを稼動させる完全な TCP/IP（transmission control protocol/Internet protocol）スタックなど、広範囲に及びます。それぞれの例は、ドキュメント化されており、すぐにコンパイルできます。

NII52001-1.0

myoshida

Text Box


1–2 Altera CorporationNios II ソフトウェア開発ハンドブック 2004年 5月

開発環境

開発環境このセクションでは、Nios II ソフトウェア開発環境の概要を説明します。

ツール

アルテラが提供する Nios II ソフトウェア開発環境は、以下のツールで構成されています。

■ Nios II IDE■ GNU Tool Chain■ インストラクション・セット・シミュレータ（ISS）■ HALシステム・ライブラリ■ RTOSおよび TCP/IPスタック■ デザインの例

Nios II IDE

Nios II統合開発環境（IDE）は、Nios IIプロセッサ用のソフトウェア開発グラフィカル・ユーザ・インタフェース（GUI）です。プログラムの編集、構築、デバッグなど、すべてのソフトウェア開発作業を Nios IIIDE内で行うことができます。Nios II IDEから他のすべてのツールを起動できます。

Nios II IDEは、一般的な Eclipse IDEフレームワークおよび Eclipse C開発ツールキット（CDT）プラグインをベースにしています。Nios II IDEは、背後にある他のツールを操作して、コマンドライン・ツールの煩雑さから開発者を解放するとともに、統合された開発環境を実現する軽量なユーザ・インタフェースです。必要に応じて、ソフトウェア開発プロセスをスクリプト化し、GUIから独立して実行することが可能です。

GNU Tool Chain

Nios II のコンパイラ・ツール・チェインは、標準的な GNU GCC コンパイラ、アセンブラ、リンカ、およびmakefile機能をベースにしています。

GNUの詳細については、www.gnu.orgを参照してください。

インストラクション・セット・シミュレータ

Nios II インストラクション・セット・シミュレータ（ISS）を使うことで、ターゲットのハードウェア・プラットフォームが完成する前に、プログラムの開発を開始することができます。実際のハードウェア・ターゲット上で実行するのと同様に、Nios II IDEから ISSを使用して簡単にプログラムを実行できます。

Altera Corporation 1–32004年 5月 Nios II ソフトウェア開発ハンドブック

概要

HALシステム・ライブラリ

HAL（Hardware Abstraction Layer）システム・ライブラリは、ANSI C標準ライブラリに基づいた、ホストの C ランタイム環境を提供します。HAL によって一般的な I/O デバイスが提供されるため、printf() などの C標準ライブラリ・ルーチンを使用してハードウェアにアクセスするプログラムを作成できます。HALを使用すると、ペリフェラルを制御したり、ペリフェラルと通信するために、ハードウェア・レジスタに直接アクセスする必要は最小限に（または不必要に）なります。

RTOSおよび TCP/IPスタック

アルテラは、MicroC/OS-II RTOSのポートと Lightweight IP TCP/IPスタックを提供します。MicroC/OS-IIは、スレッド・セーフな HALシステム・ライブラリ上に構築されており、シンプルで定評のある RTOSスケジューラを実装しています。TCP/IPスタックは、MicroC/OS-II上に構築されており、標準 UNIX Sockets API を実装しています。その他にも、いくつかのオペレーティング・システムとスタックがサードパーティ・ベンダから提供されています。

デザインの例

Nios II プロセッサおよび開発環境のすべての重要な機能を実証できるように、ソフトウェア事例が提供されています。

一貫した開発環境

Nios II IDEは、すべての Nios II プロセッサ・システムに対して動作する、一貫した開発プラットフォームを提供します。PC、アルテラ FPGA、および JTAG（Joint Test Action Group）ダウンロード・ケーブル（アルテラの USB-Blaster™ ダウンロード・ケーブルなど）があれば、Nios IIプロセッサ・システムのプログラムを作成し、そのシステムと通信できます。Nios II プロセッサの JTAGデバッグ・モジュールでは、JTAGダウンロード・ケーブルを使用して、プロセッサと通信するための一貫した 1 つの方法を実現します。デバイスが Nios II プロセッサ・システムのみを実装しているか、または Nios II プロセッサが複雑なマルチプロセッサ・システムの中枢に埋め込まれているかに関係なく、Nios II IDEを使用したプロセッサへのアクセスは同じことです。したがって、エンベデッド・プロセッサ用に、手作業でインタフェース・メカニズムを作成して時間を浪費することはありません。


サードパーティ •サポート

一貫したランタイム環境

エンベデッド・システムにおいて基礎となるハードウェア機能にかかわらず、HALシステム・ライブラリは、一貫したホストの C/C++ランタイム環境を提供します。ボード・サポート・パッケージとして機能するカスタムHALシステム・ライブラリは、Nios II プロセッサ・システムごとに、自動的に生成されます。したがって、ドライバやボード・サポート・パッケージを手作業で作成して、時間を浪費することはありません。

HALランタイム環境は、コードのフットプリントを小さくするために、必要最小限にまで容易に簡略化できます。システムの初期化やハードウェア連携用のデバイス・ドライバを完全に制御したい場合は、独自のC環境も利用できます。

サードパーティ•サポート

何社かのサードパーティ・ベンダが Nios II プロセッサをサポートしており、デザイン・サービス、RTOS、あるいはその他のソフトウェア・ライブラリや開発ツールなどを提供しています。

Nios II プロセッサのサードパーティ・サポートについての最新情報は、Nios II プロセッサのホームページwww.altera.com/nios2をご覧ください。

第 1世代のNiosプロセッサからの移行

第 1世代のNiosプロセッサのユーザの皆様には心から感謝いたします。皆様にはソフトコア・エンベデッド・プロセッサの技術革新に直接関与していただきました。皆様の支持のおかげで Nios プロセッサは業界で最も人気のあるエンベデッド・プロセッサとなりました。アルテラは、第 2世代のコンフィギュレーションが可能なエンベデッド・プロセッサ・テクノロジを提供いたします。

第 1 世代の Nios プロセッサのユーザの方々には、今後のデザインではNios II プロセッサへ移行することをお勧めします。直接的な移行プロセスについては、AN 350: Upgrading Nios Processor Systems to the Nios IIProcessorで詳しく説明しています。


概要

Nios II に関するその他の情報

このハンドブックは、Nios II プロセッサの資料の一部です。Nios II に関するその他の情報については、次の参考文献を参照してください。

■ Nios IIプロセッサ・リファレンス・ハンドブックでは、インストラクション・セット・アーキテクチャ、ペリフェラル機能など、プロセッサのハードウェア・アーキテクチャおよび機能が定義されています。

■ Nios II 統合開発環境（IDE）では、グラフィカル・ユーザ・インタフェース（GUI）の機能を使用するためのチュートリアルと多くの参考情報が記載されています。Nios II IDEを起動すると、ヘルプ・システムを利用できます。

■ アルテラのオンライン・ソリューション・データベースである FindAnswersは、使いやすい検索エンジンによって、FAQに対する回答を提供するインターネット・リソースです。www.altera.com のサポート・センタにアクセスし、Find Answersをクリックしてください。

■ アルテラのアプリケーション・ノートとチュートリアルでは、特定のアプリケーションまたは目的に対する Nios II プロセッサの使用方法について、ステップごとに説明しています。多くの場合、これらの資料はアルテラの開発キットと同時にインストールされますが、www.altera.comから入手することもできます。


Nios II に関するその他の情報


2. Nios II IDEの紹介

はじめにこの章では、Nios II 統合開発環境（IDE）の主な機能について説明します。ここではNios II IDEのルック＆フィールについて簡単に説明するだけで、詳細はユーザ・ガイドで説明しています。Nios II IDEの使用を開始する最も簡単な方法は、ツールを起動し、オンライン・ヘルプ・システムからNios II ソフトウェア開発チュートリアルを実行することです。

ソフトウェアは改善および改良されるため、この章の図が、実際のソフトウェアの画面と厳密に一致しないことがあります。

IDE関連トピックの詳細については、Nios II IDEオンライン・ヘルプを参照してください。

Nios II IDEワークベンチ

「ワークベンチ」という用語は、Nios II IDE のデスクトップ開発環境を意味します。ワークベンチとは、プログラムを編集、コンパイルおよびデバッグする場所です。図 2-1はワークベンチの例を示します。

図 2-1. Nios II IDEワークベンチ

NII52002-1.1

myoshida

Text Box



新規プロジェクトの作成

パースペクティブ、エディタ、およびビュー

各ワークベンチ・ウィンドウには、1 つまたは複数のパースペクティブが含まれています。それぞれのパースペクティブでは、特定のタイプのタスクを実行することを目的とした機能セットが利用できます。例えば、図 2-1は C/C++開発パースペクティブを示します。

パースペクティブは、エディタと 1つ以上のビューで構成されています。エディタを使用して、プロジェクト・リソース（ファイル、フォルダ、またはプロジェクト）を編集することができます。ビューは、異なる表示形式や情報の検索方法を提供します。図 2-1は、エディタで開いた Cプログラムと、C/C++ Projectsビューを示します。C/C++ Projectsビューは、開いたプロジェクトの内容に関する情報を表示します。

同時に複数のエディタを開くことができますが、アクティブにできるのは 1つです。ワークベンチ・ウィンドウのメイン・メニュー・バーとツールバーには、アクティブとなっているエディタに適用可能な操作が用意されています。エディタのタブには、現在編集用に開いているリソースの名前が表示されます。アスタリスク（*）は、エディタで編集内容が保存されていないことを示します。また、各ビューには独自のメニューもあります。ビューのメニューを開くには、ビューのタイトル・バーの左端にあるアイコンをクリックします。さらに、独自のツールバーを持つビューもあります。ビューは、独立して表示させることも、タブ形式で他のビューに重ねて表示させることもできます。

新規プロジェクトの作成

Nios II IDEには、新規の C/C++アプリケーション・プロジェクトの作成をステップごとにガイドするNew Projectウィザードが用意されています。C/C++ アプリケーションの New Project ウィザードを起動するには、図 2-2のように、（ファイル・メニューから）Newを選択します。

図 2-2. C/C++アプリケーション New Projectウィザードの起動


Nios II IDEの紹介

C/C++ アプリケーション New Project ウィザードは、以下の入力を要求します。

1. 新規プロジェクトの名前

2. ターゲット・ハードウェア

3. 新規プロジェクトのテンプレート

プロジェクト・テンプレートは、あらかじめ用意されたリファレンス・デザインであり、ユーザ独自のプロジェクトの構築方法を示す例として機能します。空のプロジェクトで一から作業を開始するよりも、「HelloWorld」プロジェクトで作業を開始する方が簡単な場合がよくあります。

図 2-3は、C/C++アプリケーションNew Projectウィザードで、Dhrystoneと呼ばれるベンチマーク・デザインのテンプレートを選択した状態を示します。

図 2-3. C/C++アプリケーション New Projectウィザード


プロジェクトのビルドと管理

Finish をクリックすると、Nios II IDE は新規プロジェクトを作成します。また IDEは、システム・ライブラリ・プロジェクトの *_syslib（例えば、図 2-3 の場合は、dhrystone_0_syslib）も作成します。これらのプロジェクトは、ワークベンチのC/C++ Projectsビューに表示されます。

プロジェクトのビルドと管理

任意のリソース（ファイル、フォルダ、またはプロジェクト）を右クリックすると、コンテキスト・センシティブ・メニューが開き、そのリソースに対して実行できる操作が表示されます。必要な操作を見つけるには、右クリックが最も簡単な方法ですが、メニューとツールバーから操作することもできます。

プロジェクトをコンパイルするには、C/C++ Projectsビューでプロジェクトを右クリックし、Build Projectを選択します。図 2-4は、プロジェクト dhrystone_0のコンテキスト・センシティブ・メニューで、BuildProject オプションを選択する様子を示しています。ビルドする際には、Nios II IDEは、まずシステム・ライブラリ・プロジェクト（およびプロジェクトに関係するもの）をビルドし、次にメイン・プロジェクトをコンパイルします。ワーニングまたはエラーがあれば、Tasks ビューに表示されます。



図 2-4.コンテキスト・センシティブ（右クリック）メニューを使用したプロジェクトのビルド

C/C++ Projectsのプロジェクトを右クリックしても、プロジェクトの管理に重要な次のオプションにアクセスできます。

■ Properties－ターゲット・ハードウェアおよびその他のプロジェクトに関係するものを管理します。

■ System Library Properties－通信デバイスやメモリ分割など、ハードウェア固有の設定を管理します。

■ Build Project－makeと同じです。 ■ Rebuild Project－make allと同じです。■ Run As－ハードウェアまたは ISS上でプログラムを実行します。■ Debug As－ハードウェアまたはISS上でプログラムをデバッグします。


プログラムの実行とデバッグ


プロジェクトを右クリックすると、実行およびデバッグ動作が可能になります。Nios II IDEでは、ターゲット・ボードまたは Nios II インストラクション・セット・シミュレータ（ISS）のどちらでも、プロジェクトの実行およびデバッグが可能です。例えば、ターゲット・ボード上でプログラムを実行するには、図 2-5のように、Run As > Nios II Hardwareの順に選択します。stdout および stderr へのキャラクタ I/O は、Consoleビューに表示されます。

図 2-5.ターゲット・ハードウェア上でのプログラムの実行



デバッグ・セッションの起動は、実行セッションの起動と類似しています。例えば、ISS上でプログラムをデバッグするには、図 2-6のように、C/C++ Projects ビュー内のプロジェクトを右クリックし、Debug As >Nios II Instruction Set Simulatorの順に選択します。

図 2-6.インストラクション・セット・シミュレータの起動



図 2-7 は、dhrystone_0 project に対して実行中のデバッグ・セッションを示します。

図 2-7. ISS上での dhrystone_0のデバッグ

デバッガを起動すると、ワークベンチのパースペクティブはデバッグのパースペクティブに変化します。ワークベンチ・ウィンドウの左端にあるパースペクティブ・アイコンをクリックすれば、デバッグ・パースペクティブと C/C++ 開発パースペクティブを簡単に切り替えることができます。

デバッグ・セッションを開始すると、デバッガはプログラムをロードし、main()にブレークポイントを設定し、プログラムの実行を開始します。Step Into、Step Over、Resume、Terminate などのコントロールを使用して、コードをステップ実行します。ブレークポイントを設定するには、コード表示の左側の余白部分をダブル・クリックするか、右クリックから Add Breakpointを選択します。



Nios II IDE には、Variables、Expressions、Registers、Memory など、多数のデバッグ表示が用意されており、これらを使用すると、デバッグ中にプロセッサのステータスを確認できます。図 2-8は、Registersビューを示します。

図 2-8.デバッグ時における Registersビュー

フラッシュのプログラミング

多くの Nios II プロセッサ・システムが以下の項目のひとつ以上を保存するのに、外部フラッシュ・メモリを使用します。

■ プログラム・コード■ プログラム・データ■ FPGAコンフィギュレーション・データ■ ファイル・システム

Nios II IDEでは、Flash Programmerユーティリティを使用して、フラッシュ・メモリの内容を容易に管理およびプログラムすることができます。図 2-9は、Flash Programmerを示します。


オンライン・ヘルプ

図 2-9. Nios II IDE Flash Programmer


Nios II IDEヘルプ・システムでは、IDEに関するすべてのトピックを資料で参照できます。オンライン・ヘルプは、Help > Help Contentsの順に選択すると起動できます。また、F1キーを押せば、現在の画面についての説明をいつでも参照できます。さらにオンライン・ヘルプには、プロジェクトの作成、ビルド、およびデバッグのプロセスをステップごとに体験できるチュートリアルも用意されています。図 2-10は、オンライン・ヘルプ・システムでチュートリアルを表示した状態を示します。



図 2-10.オンライン・ヘルプ・システムのオンライン・チュートリアル

Altera Corporation セクション II–1

セクション II. HALシステム・ライブラリ

このセクションでは、HAL（Hardware Abstraction Layer）システム・ライブラリについて説明します。


■ 第 3章　HALシステム・ライブラリの概要

■ 第 4章　HALを使用したプログラムの開発

■ 第 5章　HAL用デバイス・ドライバの開発

改定履歴以下の表に、各章の改定履歴を示します。これらのバージョンは資料の改定を追跡しているのもので、Nios II 開発キットや Nios II プロセッサのバージョンには関係ありません。


3 2004年 5月v1.0

初版

4 2004年 12月v1.2

● ブート・モード情報を追加● コンパイラの最適化について修正● コード・フットプリント削減のセクションを更新

2004年 9月v1.1

DMA受信チャネルのコード例を修正

2004年 5月v1.0

初版

5 2004年 12月v1.1

lwIPのバージョンの参照を 0.6.3から 0.7.2に更新

2004年 5月v1.0

初版

myoshida

Text Box


セクション II–2 Altera Corporation

HALシステム・ライブラリ Nios II ソフトウェア開発ハンドブック


3. HALシステム・ライブラリの概要

はじめにこの章では、Nios® II プロセッサ用のHAL（Hardware Abstraction Layer）システム・ライブラリについて説明します。

HALシステム・ライブラリは、シンプルなデバイス・ドライバ・インタフェースを提供する軽量のランタイム環境です。プログラムはこのインタフェースを使用して基礎となるハードウェアと通信します。HALアプリケーション・プログラム・インタフェース（API）は、ANSI C標準ライブラリと統合されています。HAL API を使用すると、printf()、fopen()、fwrite()など、一般的な Cライブラリ関数によってデバイスおよびファイルにアクセスできます。

HALは Nios II プロセッサ・システムのボード・サポート・パッケージとして機能し、エンベデッド・システムのペリフェラルへの一貫したインタフェースを提供します。SOPC BuilderとNios II 統合開発環境（IDE）は緊密に統合されているため、HALシステム・ライブラリを自動的に生成できます。SOPC Builder がハードウェア・システムを生成すると、Nios II IDEは、そのハードウェア・コンフィギュレーションに合わせて、独自のHALシステム・ライブラリを生成できます。さらに、ハードウェア・コンフィギュレーションを変更すると、HALデバイス・ドライバのコンフィギュレーションに自動的に反映されます。このため、基本ハードウェアをわずかに変更したことによって発生するやっかいなバグがなくなります。

HALによってデバイス・ドライバが抽象化されるため、アプリケーションとデバイス・ドライバ・ソフトウェアが明確に区別されます。このようなドライバの抽象化によって、基本ハードウェアの変更に対応する再利用可能なアプリケーション・コードを容易に記述できます。さらに、既存のペリフェラル・ドライバに対応する新しいハードウェア・ペリフェラル用のドライバも簡単に記述できます。

使用開始にあたって

HAL の使用を開始する最も簡単な方法は、Nios II IDE に付属するオンライン・チュートリアルを実行することです。Nios II IDE で新規プロジェクトを作成するプロセスでは、HALシステム・ライブラリも同時に作成します。HALファイルを作成したりコピーしたりする必要はなく、また HALソース・コードを編集する必要もまったくありません。HALシステム・ライブラリは、Nios II IDEによって自動的に生成および管理されます。

NII52003-1.0

myoshida

Text Box



HALアーキテクチャ

HALシステム・ライブラリは、特定の SOPC Builderシステム上に構築する必要があります。SOPC Builderシステムとは、ペリフェラルおよびメモリと統合されたNios II プロセッサ・コア（SOPC Builderによって生成）を意味します。独自の SOPC Builder システムがない場合は、アルテラが提供するハードウェア・システムの例をベースにして、プロジェクトを作成できます。最初に、アルテラの Nios 開発ボードをターゲットとするプロジェクトを開発し、その後でプロジェクトのターゲットをカスタム・ボードに変更できます。ターゲットの SOPC Builder システムは、後から簡単に変更できます。

新規プロジェクトの開始に関する詳細は、Nios II IDEのオンライン・ヘルプを参照してください。


このセクションでは、HALアーキテクチャの基本的な要素について説明します。

サービス

HALシステム・ライブラリは、次のサービスを提供します。

■ newlib ANSI C標準ライブラリとの統合使い慣れた C標準ライブラリ関数が利用できるようになります。

■ デバイス・ドライバシステム内の各デバイスへのアクセスが可能になります。

■ HAL APIデバイス・アクセス、割り込み処理、アラーム機能など、HALサービスへの一貫した標準インタフェースを提供します。

■ システムの初期化main()を実行する前に、プロセッサおよびランタイム環境用の初期化タスクを実行します。

■ デバイスの初期化main()を実行する前に、システムの各デバイスをインスタンス化および初期化します。

図 3-1は、ハードウェア・レベルからユーザ・プログラムまでのHALベースのシステムのレイヤを示します。


HALシステム・ライブラリの概要

図 3-1. HALベースのシステムのレイヤ

アプリケーションとドライバ

プログラマは、アプリケーション開発者とデバイス・ドライバ開発者の2つの明確なグループに区分されます。アプリケーション開発者にはユーザの大部分が該当し、各種ルーチンの中でも特にシステムの main()ルーチンの記述を担当します。アプリケーションは、C標準ライブラリまたは HALシステム・ライブラリ APIを介してシステム・リソースと通信します。デバイス・ドライバ開発者の役割は、アプリケーション開発者がデバイス・リソースを利用できるようにすることです。デバイス・ドライバは、低レベルのハードウェア・アクセス・マクロにより、ハードウェアと直接通信します。

このため、主要な HAL の資料は、次の 2 つの章に大きく分割されています。

■ 第 4章　HALを使用したプログラムの開発では HALを活用し、基本ハードウェアを意識しないでプログラムを記述する方法について説明しています。

■ 第 5章　HAL用デバイス・ドライバの開発では、ハードウェアと直接通信する方法、および抽象化された HAL API を介してハードウェア・リソースを利用可能にする方法について説明しています。

ユーザ・プログラム

C標準ライブラリ

HAL API

デバイス・ドライバ

デバイス・ドライバ...デバイス・

ドライバ

Nios IIプロセッサ・システム・ハードウェア



汎用デバイス・モデル

HALは、タイマ、Ethernet MAC/PHYチップ、キャラクタ・データを伝送する I/Oペリフェラルなど、エンベデッド・システムで広く使用されるペリフェラルのクラスに対応する汎用デバイス・モデルを提供します。汎用デバイス・モデルは、HALシステム・ライブラリの中核となる機能です。汎用デバイス・モジュールを利用すれば、基本ハードウェアに関係なく、一貫した APIを使用してプログラムを記述することができます。

デバイス・モデル・クラス

HALは、次のデバイスのクラス用のモデルを提供します。

■ キャラクタ・モード・デバイスUART など、キャラクタをシリアルに送受信するハードウェア・ペリフェラルです。

■ タイマクロックをカウントし、周期的な割り込み要求を生成できるハードウェア・ペリフェラルです。

■ ファイル・サブシステム物理デバイス内に格納されたファイルにアクセスするためのメカニズムを提供します。内部実装に応じて、ファイル・サブシステム・ドライバは、基本デバイスに直接アクセスしたり、別のデバイス・ドライバを使用したりすることができます。例えば、フラッシュ・メモリ・デバイス用のHAL APIを使用して、フラッシュにアクセスするフラッシュ・ファイル・サブシステム・ドライバを記述できます。

■ イーサネット・デバイスアルテラが提供する軽量 IPプロトコル・スタックに対応したイーサネット接続へのアクセスを可能にします。

■ DMAデバイスデータ・ソースからディスティネーションへのバルク・データ転送を実行するペリフェラルです。イーサネット接続など、メモリやその他のデバイスをソースおよびディスティネーションにすることができます。

■ フラッシュ・メモリ・デバイス専用のプログラミング・プロトコルを使用してデータを格納する不揮発性メモリ・デバイスです。



アプリケーション開発者の利点

HALシステム・ライブラリは、デバイスの各クラスの初期化とアクセスに使用する関数のセットを定義します。この APIは、デバイス・ハードウェアの基本実装状態に関係なく、一貫性が維持されています。例えば、キャラクタ・モードのデバイスおよびファイル・サブシステムにアクセスする場合には、printf()や fopen()などの C標準ライブラリ関数が使用できます。アプリケーション開発者の場合、これらペリフェラルのクラスに対するハードウェアとの基本的な通信を確立するためだけに、低レベルのルーチンを記述する必要はありません。

デバイス・ドライバ開発者の利点

各デバイス・モデルは、デバイスの特定のクラスを操作するのに必要なドライバ関数のセットを定義します。新しいペリフェラル用のドライバを記述する場合は、このドライバ関数のセットを提供するだけで十分です。結果として、ドライバ開発作業は事前定義され、記録されます。さらに、既存の HAL 関数とアプリケーションを使用してデバイスにアクセスし、ソフトウェア開発の労力を軽減させることもできます。HALシステム・ライブラリは、ドライバ関数をコールしてハードウェアにアクセスします。アプリケーション・プログラマは、ドライバ・ルーチンを直接呼び出すのではなく、ANSI Cまたは HAL APIを呼び出してハードウェアにアクセスします。したがって、ドライバの使用法は HAL APIの一部として記録されます。

C標準ライブラリ— NewlibHALシステム・ライブラリでは、ANSI C標準ライブラリがランタイム環境に統合されています。HALは、C標準ライブラリのオープン・ソース実装である newlib を使用しています。newlib は、エンベデッド・システムで使用するための Cライブラリであり、HALおよび Nios II プロセッサに最適です。newlibのライセンスでは、ソース・コードのリリースや newlibベースのプロジェクトに対するロイヤリティは不要です。

ANSI C標準ライブラリに関する文献は豊富にあります。最もよく知られた参考文献は、Prentice Hallから出版された、B.W.カーニハン /D.M.リッチー著のプログラミング言語 Cでしょう。この文献は、20以上の言語に翻訳されています。また、Redhat社は、http://sources.redhat.com/newlibで newlibのオンライン資料を提供しています。


サポートされているペリフェラル


アルテラは、Nios II プロセッサ・システムで使用する多数のペリフェラルを提供しています。大部分のアルテラ製ペリフェラルでは、HAL APIを介してハードウェアへのアクセスを可能にする HAL デバイス・ドライバが利用できます。次のアルテラ製ペリフェラルは、HALを完全にサポートしています。

■ キャラクタ・モード・デバイス：● UARTコア● JTAG UARTコア● LCD 16207ディスプレイ・コントローラ

■ フラッシュ・メモリ・デバイス● 共通フラッシュ・インタフェース準拠のフラッシュ・チップ● アルテラの EPCSシリアル・コンフィギュレーション・デバイス・コントローラ

■ ファイル・サブシステム● リード・オンリ zipファイル・システム

■ タイマ・デバイス● タイマ・コア

■ DMAデバイス● DMAコントローラ・コア

■ イーサネット・デバイス● LAN91C111 Ethernet MAC/PHY Controller

LAN91C111コンポーネントには、MicroC/OS- II ランタイム環境が必要です。詳細については、9–1ページの「イーサネットと Lightweight IP」を参照してください。

その他にも、ここに記載していないペリフェラルが、サードパーティ・ベンダから提供されています。Nios II プロセッサで利用可能なその他のペリフェラルは、アルテラのWebサイトwww.altera.comをご覧ください。

（アルテラおよびサードパーティ・ベンダの両方が提供する）すべてのペリフェラルは、ハードウェアに対するペリフェラルの低レベル・インタフェースを定義したヘッダ・ファイルを提供する必要があります。このため、すべてのペリフェラルはある程度 HALをサポートしています。ただし、デバイス・ドライバを提供していないペリフェラルもあります。ドライバを入手できない場合は、ヘッダ・ファイルに提供された定義のみを使用して、ハードウェアにアクセスしてください。ハード・コード化されたアドレスやその他の「マジック・ナンバ」を使用してペリフェラルにアクセスすることは、絶対にしないでください。



特定のペリフェラルには、汎用 API では捕捉できない使用条件を持つハードウェア固有の機能が必ずあります。HAL システム・ライブラリは、UNIX 形式の ioctl() 関数を提供することによって、ハードウェア固有の要求に対応しています。ハードウェア機能はペリフェラルに依存するため、ioctl()オプションは、各ペリフェラルの説明書に記載されています。

一部のペリフェラルには、HAL汎用デバイス・モデルをベースにしていない専用のアクセス関数が用意されています。例えば、アルテラは、Nios II プロセッサ・システムで使用するための汎用パラレル I/O（PIO）コアを提供しています。この PIO ペリフェラルは、HAL が提供する汎用デバイス・モデルのどのクラスにも適合しないため、ヘッダ・ファイルと少数の専用アクセス関数のみが用意されています。

ペリフェラルのソフトウェア・サポートの詳細については、当該ペリフェラルの説明書を参照してください。アルテラ提供のペリフェラルの詳細については、Nios IIプロセッサ・リファレンス・ハンドブックを参照してください。


4. HALを使用したプログラムの開発

はじめにこの章では、アルテラのHAL（Hardware Abstraction Layer）システム・ライブラリをベースとして、プログラムを開発する方法について説明します。

HALベース・システムの APIは、Nios® II プロセッサを初めて使用するソフトウェア開発者の方でも、容易に利用できます。HALをベースとしたプログラムは、ANSI C 標準ライブラリ関数とランタイム環境を使用し、HAL APIの汎用デバイス・モデルを介してハードウェア・リソースにアクセスします。ANSI C標準ライブラリはHALシステム・ライブラリから独立していますが、HAL APIの大部分は、使い慣れた ANSI C標準ライブラリ関数で定義されています。ANSI C標準ライブラリとHALは緊密に統合されているため、HALシステム・ライブラリ関数を直接呼び出さない有効なプログラムを開発することができます。例えば、printf()、scanf()などの ANSI C標準ライブラリ I/O関数を使用して、キャラクタ・モードのデバイスとファイルを操作できます。

この章では、HAL システム・ライブラリ API を使用するための基本的な参考情報を記載します。いくつかのトピックは、他の章で詳細に扱われています。この章で扱っていない以下の重要なトピックについては、目次を参照してください。

■ デバイス・ドライバ、およびハードウェアと直接連携するコードの記述■ 例外処理および割り込みサービス・ルーチン■ キャッシュ・メモリを構成するためのプログラミング■ リアル・タイム・オペレーティング・システム（RTOS）■ イーサネット

本書では、ANSI C標準ライブラリについては説明していません。

Nios II IDEプロジェクト構造

HALシステム・ライブラリをベースとしたソフトウェア・プロジェクトの作成と管理は、Nios II 統合開発環境（IDE）に緊密に統合されています。このセクションでは、HAL を理解するための基礎として、Nios IIIDEプロジェクトについて説明します。

NII52004-1.2

myoshida

Text Box



Nios II IDEプロジェクト構造

図 4-1 は、HAL システム・ライブラリの組み込み方法に重点を置いたNios II プログラムのブロックを示します。各ブロックのラベルはブロックの作成元または作成者を示し、矢印は各ブロック間の依存関係を示します。

図 4-1. Nios II IDEプロジェクトの構造

HAL ベースのシステムは、図 4-1 に示すように、2 つの Nios II IDE プロジェクトを使用して構築されます。ユーザのプログラムは、1 つのプロジェクト（ユーザ・アプリケーション・プロジェクト）に含まれ、別のシステム・ライブラリ・プロジェクト（HALシステム・ライブラリ・プロジェクト）に依存します。アプリケーション・プロジェクトには、ユーザが開発するすべてのコードが含まれています。プログラムの実行可能イメージは、このプロジェクトをビルドしたものを土台として作成されます。HAL システム・ライブラリ・プロジェクトには、プロセッサ・ハードウェアとのインタフェースに関連するすべての情報が含まれています。システム・ライブラリ・プロジェクトは Nios II プロセッサ・システムに依存し、SOPC Builderで生成された .ptfファイルによって定義されています。

HALベースのソフトウェア・アプリケーション

別名：ユーザ・プログラムまたはユーザ・プロジェクト記述：.c、.h、.sファイル作成：ユーザ

別名：HALまたはシステム・ライブラリ・プロジェクト

記述：.ptfファイル

記述：Nios II IDE プロジェクト設定

別名：Nios IIプロセッサ・システムまたはハードウェア

作成：SOPC Builder

作成：Nios II IDE

ユーザ・アプリケーション・プロジェクト

HALシステム・ライブラリ・プロジェクト

SOPC Builderシステム


HALを使用したプログラムの開発

このプロジェクトの依存関係のため、SOPC Builderシステムが変更された（つまり、.ptfファイルが更新された）場合でも、Nios II IDEによって HAL システム・ライブラリが管理され、システム・ハードウェアを正確に反映するようにドライバ・コンフィギュレーションが更新されます。HAL システム・ライブラリによって、ユーザのプログラムは基本ハードウェアが変更されても影響を受けることはありません。そのため、ユーザは、自分のプログラムがターゲット・ハードウェアに適合するかどうかを気にすることなく、コードの開発とデバッグを実行できます。つまり、HALシステム・ライブラリをベースとするプログラムは、常にターゲット・ハードウェアと同期化されます。

system.hシステム記述ファイル

system.h ファイルは、HAL システム・ライブラリの基礎となります。system.h ファイルには、Nios II システム・ハードウェアのソフトウェア記述がすべて含まれています。このファイルは、ハードウェアおよびソフトウェアのデザイン・プロセス間における引き渡し点となります。system.hのすべての情報が、必ずしもプログラマに役立つとは限りませんし、Cソース・ファイルで明示的に指定する必要があるとも限りません。しかし、system.h には、「このシステムにはどのようなハードウェアが存在するか ?」という基本的な疑問に対する解答があります。

system.hファイルには、システム内の各ペリフェラルの記述と以下の詳細情報が入っています。

■ ペリフェラルのハードウェア・コンフィギュレーション■ ベース・アドレス■ IRQの優先順位（該当する場合）■ ペリフェラルの識別名

system.h ファイルは、絶対に編集しないでください。system.h ファイルは、HALシステム・ライブラリ・プロジェクト用にNios II IDEによって自動的に生成されます。system.hの内容は、ユーザが Nios II IDEで設定するハードウェア・コンフィギュレーションおよび HALシステム・ライブラリ・プロパティの両方に依存します。

詳細については、Nios II IDEオンライン・ヘルプを参照してください。


データ幅と HAL型の定義

system.hファイル内の以下のコードは、このファイルが定義するハードウェア・コンフィギュレーションの一部を示します。

例：system.hファイルの一部

/* * sys_clk_timer configuration * */

#define SYS_CLK_TIMER_NAME "/dev/sys_clk_timer"#define SYS_CLK_TIMER_TYPE "altera_avalon_timer"#define SYS_CLK_TIMER_BASE 0x00920800#define SYS_CLK_TIMER_IRQ 0#define SYS_CLK_TIMER_ALWAYS_RUN 0#define SYS_CLK_TIMER_FIXED_PERIOD 0

/* * jtag_uart configuration * */

#define JTAG_UART_NAME "/dev/jtag_uart"#define JTAG_UART_TYPE "altera_avalon_jtag_uart"#define JTAG_UART_BASE 0x00920820#define JTAG_UART_IRQ 1

データ幅とHAL型の定義

Nios II プロセッサなどのエンベデッド・プロセッサでは、多くの場合、データの正確な幅と精度を知ることが重要になります。ANSI C のデータ型では、データ幅が明示的に定義されていないため、HALは代わりに標準型定義のセットを使用します。ANSI C 型もサポートされていますが、これらのデータ幅はコンパイラの規約に依存します。

ヘッダ・ファイル alt_type.hでは、HAL型定義を定義しています。表 4–1にHAL型定義を示します。

表 4–1. HAL型定義

型意味

alt_8 符号付 8ビット整数

alt_u8 符号なし 8ビット整数







表 4–2 に、アルテラが提供する GNU Toolchain で使用するデータ幅を示します。

UNIX形式のインタフェース

HAL APIは、多数の UNIX形式の関数を提供します。UNIX形式の関数によって、新たに Nios II を使用するプログラマにも親しみやすい開発環境が提供され、既存のコードを移植して HAL 環境で実行させるための作業が容易になります。HAL は主にこれらの関数を使用して、ANSIC標準ライブラリ用のシステム・インタフェースを提供します。例えば、これらの関数は、stdio.h で定義された C ライブラリ関数が必要とするデバイス・アクセスを実行します。

以下に、利用可能な UNIX形式の関数の全リストを示します。

■ _exit()■ close()■ fstat()■ getpid()■ gettimeofday()■ ioctl()■ isatty()■ kill()■ lseek()■ open()■ read()■ sbrk()■ settimeofday()■ stat()■ usleep()■ wait()■ write()

最もよく使用される関数は、ファイル I/Oに関するものです。4–6ページの「ファイル・システム」を参照してください。

表 4–2. GNU Toolchainのデータ幅

型意味

char 8ビット

short 16ビット

long 32ビット

int 32ビット


ファイル・システム

これらの関数の使用法の詳細については、10–1 ページの「HAL APIリファレンス」を参照してください。

ファイル・システム

HALは、キャラクタ・モードのデバイスおよびデータ・ファイルを操作するのに使用可能なファイル・システムのコンセプトを提供します。newlib が提供する C 標準ライブラリのファイル I/O 関数（fopen()、fclose()、fread()など）、または HALシステム・ライブラリが提供する UNIX 形式のファイル I/O を使用して、ファイル・システム内のファイルにアクセスできます。

HALでは、ファイル操作に以下の UNIX形式の関数を利用できます。

■ close()■ fstat()■ ioctl()■ isatty()■ lseek()■ open()■ read()■ stat()■ write()

これらの関数の詳細については、10–1 ページの「HAL API リファレンス」を参照してください。

ファイル・システムは、自身をグローバル HAL ファイル・システム内のマウント・ポイントとして登録します。マウント・ポイントの下にあるファイルにアクセスを試みると、アクセスはそのファイル・サブシステムに対して実行されます。例えば、zip ファイル・サブシステムが/mount/zipfs() としてマウントされている場合、/mount/zipfs()/myfileを対象とした fopen()のコールは、関連付けられた zipfsファイル・サブシステムによって処理されます。

同様に、キャラクタ・モード・デバイスは、HALファイル・システム内のノードとして登録します。慣例的に、system.hファイルでは、デバイス・ノード名は、プリフィックス /dev/に続いて、SOPC Builderでハードウェア・コンポーネントに割り当てられた名前を付加して定義されます。例えば、SOPC Builderでの UARTペリフェラル uart1は、system.hでは /dev/uart1となります。

カレント・ディレクトリという概念はありません。すべてのファイルは、絶対パスを使用してアクセスする必要があります。



以下に、HALファイル・システム内のノードとして登録されたリード・オンリ zip ファイル・サブシステム rozipfs から、キャラクタを読み取るコードを示します。

例：ファイル・サブシステムからのキャラクタの読み取り

#include <stdio.h>#include <stddef.h>#include <stdlib.h>

#define BUF_SIZE (10)

int main(void){FILE* fp;char buffer[BUF_SIZE];

fp = fopen (“/mount/rozipfs/test”, “r”);if (fp == NULL){

printf (“Cannot open file.\n”); exit (1);}

fread (buffer, BUF_SIZE, 1, fp);

fclose (fp);

return 0;}


キャラクタ・モード・デバイスの使用

キャラクタ・モード・デバイスとは、UART（Universal AsynchronousReceiver/Transmitter）のように、キャラクタをシリアルに送受信するハードウェア・ペリフェラルです。キャラクタ・モード・デバイスは、HALファイル・システム内のノードとして登録されます。一般に、プログラムはファイル・ディスクリプタをデバイスの名前に関連付けた後に、file.hに定義された ANSI Cファイル操作を使用して、キャラクタをファイルから読み込んだり、ファイルに書き込んだりします。さらに、HALでは標準入力、標準出力、および標準エラーのコンセプトもサポートされているため、プログラムから stdio.h I/O 関数を呼び出すことができます。


キャラクタ・モード・デバイスの使用

標準入力、標準出力および標準エラー

シンプルなコンソール I/O を実装するには、標準入力（stdin）、標準出力（stdout）、および標準エラー（stderr）を使用するのが最も簡単な方法です。HALシステム・ライブラリは、背後で stdin、stdout、stderr を管理するため、ファイル・ディスクリプタを明示的に管理することなく、これらのチャネルを介してキャラクタを送信および受信することが可能になります。例えば、システム・ライブラリは、printf()の出力は標準出力に、perror()は標準エラーに送ります。

各チャネルは、Nios II IDEでシステム・ライブラリ・プロパティを設定することによって、特定のハードウェア・デバイスに関連付けます。


以下のコードは、定番の Hello Worldプログラムを示します。このプログラムでは、Nios II IDEでコンパイルしたときに stdoutに関連付けられる任意のデバイスへ、キャラクタを送信します。

例：Hello World

#include <stdio.h>int main (){ printf (“Hello world!”); return 0;}

UNIX形式のAPIを使用する場合は、unistd.hで定義されたファイル・ディスクリプタ STDIN_FILENO、STDOUT_FILENO、および STDERR_FILENOを使用すれば、stdin、stdout、stderrにそれぞれアクセスできます。

キャラクタ・モード・デバイスへの汎用アクセス

キャラクタ・モード・デバイス（stdin、stdout、または stderr を除く）へのアクセスは、ファイルを開いたり、ファイルに書き込んだりするのと同様に簡単です。以下に、uart1 という名前の UART にメッセージを書き込むコードを示します。

例：UARTへのキャラクタの書き込み

#include <stdio.h>#include <string.h>

int main (void){ char* msg = “hello world”; FILE* fp;



fp = fopen (“/dev/uart1”, “w”); if (fp) { fprintf(fp, “%s”,msg); fclose (fp); } return 0;}

C++ストリームHALベースのシステムでは、C++からのファイル操作に C++ストリーム APIが使用できます。

/dev/null

デバイス /dev/null は、すべてのシステムに含まれています。/dev/nullに書き込んでも処理されず、データは破棄されます。/dev/nullは、システム起動中に、安全な I/Oリダイレクションを実現するために使用されます。また、このデバイスは、不適切なデータを出さないようにするアプリケーションにも役立ちます。

このデバイスは、完全にソフトウェアのみで構成されています。システム内の物理的なハードウェア・デバイスとは無関係です。

ファイル・サブシステムの使用

ファイル・サブシステム用の HAL汎用デバイス・モデルを利用すれば、C標準ライブラリのファイル I/O関数を使用して、関連付けられるメディアに格納されたデータにアクセスできます。例えば、アルテラの zipリード・オンリ・ファイル・システムを利用すると、フラッシュ・メモリに格納されたファイル・システムにリード・オンリでアクセスできます。

ファイル・サブシステムの役割は、所定のマウント・ポイントにおけるすべてのファイル I/O アクセスを管理することです。例えば、ファイル・サブシステムがマウント・ポイント /mnt/rozipfsに登録されている場合、fopen(“/mnt/rozipfs/myfile”, “r”)など、このディレクトリにおけるすべてのファイル・アクセスは、そのファイル・サブシステムに対して実行されます。

キャラクタ・モード・デバイスと同様に、ファイル・サブシステム内のファイルは、fopen()や fread()など、file.hで定義された Cのファイル I/O関数を使用して操作できます。これらの関数の使用法の詳細については、10–1ページの「HAL APIリファレンス」を参照してください。


タイマ・デバイスの使用


タイマ・デバイスとは、クロックをカウントし、周期的な割り込み要求を生成できるハードウェア・ペリフェラルです。タイマ・デバイスを使用すると、HALシステム・クロック、アラーム、時刻、時間測定など、時間に関連する多数の機能を実現できます。タイマ機能を使用するには、Nios II プロセッサ・システムのハードウェアにタイマ・ペリフェラルが含まれていることが必要です。

HAL APIは、2種類のタイマ・デバイス・ドライバを提供します。1つは、アラーム機能を可能にするシステム・クロック・ドライバ、もう 1つは、高精度の時間測定を可能にするタイムスタンプ・ドライバです。特定のタイマ・ペリフェラルは、どちらか一方のみ動作できますが、両方同時には動作できません。

HALでは、標準 UNIX関数の gettimeofday()、settimeofday()、および times()が実装されています。

タイマ・デバイスにアクセスするための HAL 特有の API 関数は、sys/alt_alarm.hおよび sys/alt_timestamp.hで定義されています。


HALシステム・クロックHALシステム・クロック・ドライバは、周期的な「ハートビート」を供給して、各ビートごとにシステム・クロックを増加させます。システム・クロック機能を使用すると、指定した時間に関数を実行したり、タイミング情報を取得したりすることができます。特定のハードウェア・タイマ・ペリフェラルをシステム・クロック・デバイスとして関連付けるには、Nios II IDEでシステム・ライブラリのプロパティを設定します。


システム・クロックは、「チック」の単位で時間を測定します。ハードウェアとソフトウェアの両方を扱うエンベデッド・エンジニアは、HALシステム・クロックと、Nios II プロセッサ・ハードウェアの同期化に使用されるクロック信号を混同しないように注意してください。HALシステム・クロック・チックの周期は、ハードウェア・システム・クロックよりもはるかに長くなります。



システム・クロックの現在の値は、alt_nticks()関数を呼び出すと取得できます。この関数は、リセット以降の経過時間をシステム・クロック・チック単位で返します。システム・クロック・レート（チック /秒）は、関数 alt_ticks_per_second()を使用すれば取得できます。HALタイマ・ドライバは、システム・クロックのインスタンスを作成したときに、チック周波数を初期化します。

標準 UNIX関数 gettimeofday()を利用すれば、現在の時間を取得できます。まず、settimeofday() を呼び出して、時刻をキャリブレートすることが必要です。さらに、times() 関数を使用して、経過したチック数に関する情報を取得することもできます。これらの関数は、times.hで定義されています。

アラーム

HALアラーム機能を使用して、指定した時間に実行する関数が登録できます。アラームは、関数 alt_alarm_start() を呼び出すと、登録されます。

int alt_alarm_start (alt_alarm* alarm, alt_u32 nticks, alt_u32 (*callback) (void* context), void* context);

関数 callbackは、nticksが経過した後に呼び出されます。入力引数contextは、呼び出しが発生したときに、入力引数として callbackに渡されます。入力引数 alarm が示す構造体は、alt_alarm_start()への呼び出しによって初期化されます。この構造体を初期化する必要はありません。

このコールバック関数はアラームをリセットできます。登録したコールバック関数の戻り値は、次回の callback へのコールまでに経過するチック数です。戻り値がゼロであれば、アラームの停止が必要であることを意味します。alt_alarm_stop() を呼び出すと、アラームを手動でキャンセルできます。

アラーム・コールバック関数の記述には注意が必要です。これらの関数は、多くの場合、割り込み処理の中で実行され、機能に特定の制約が課されます（6–1ページの「例外処理」を参照してください）。



以下に、1 秒ごとに周期的なコールバックを行うように、アラームを登録する方法を示すコードの一部分を示します。

例：周期的なアラーム・コールバック関数の使用

#include <stddef.h>#include <stdio.h>#include “sys/alt_alarm.h”#include “alt_types.h”

/* * コールバック関数 */

alt_u32 my_alarm_callback (void* context){ /* この関数は、1秒ごとに呼び出されます。 */ return alt_ticks_per_second();}

...

/* alt_alarmは、アラームの期間存続することが必要です。 */static alt_alarm alarm;

...

if (alt_alarm_start (&alarm, alt_ticks_per_second(), my_alarm_callback, NULL) < 0) { printf (“No system clock available\n”); }

高精度時間測定

場合によっては、HALシステム・クロック・チックで得られるレベルを上回る精度で、時間間隔の測定が必要になることも考えられます。HALは、タイムスタンプ・ドライバを使用する高精度タイミング関数を提供しています。タイムスタンプ・ドライバは、単調に増加するカウンタを提供するため、このカウンタをサンプリングして、タイミング情報を取得できます。HALはシステム内に 1つのタイムスタンプ・ドライバのみサポートします。

タイムスタンプ・ドライバが存在すれば、関数alt_timestamp_start()および alt_timestamp() が利用可能になります。アルテラが提供するタイムスタンプ・ドライバは、Nios II IDEのシステム・ライブラリ・プロパティ・ページで、ユーザが選択したタイマを使用します。



関数 alt_timestamp_start()を呼び出すと、カウンタが動作を開始します。続いて alt_timestamp()を呼び出すと、タイムスタンプ・カウンタの現在の値が返されます。再び alt_timestamp_start()を呼び出せば、カウンタはゼロにリセットされます。カウンタが（232 – 1）に達したときのタイムスタンプ・ドライバの動作は定義されていません。

関数 alt_timestamp_freq()を呼び出すと、タイムスタンプ・カウンタが増加するレートを取得できます。一般にこのレートは、Nios II プロセッサ・システムが動作するハードウェア周波数（通常、毎秒数百万サイクル）です。タイムスタンプ・ドライバは、alt_timestamp.hヘッダ・ファイルで定義されます。

以下のコードは、タイムスタンプ機能を使用して、コード実行時間を測定する方法の一部分です。

例：コード実行時間を測定するためのタイムスタンプの使用

#include <stdio.h>#include “sys/alt_timestamp.h” #include “alt_types.h”

int main (void){ alt_u32 time1; alt_u32 time2; alt_u32 time3;

if (alt_timestamp_start() < 0) { printf (“No timestamp device available\n”); } else { time1 = alt_timestamp(); func1(); /* 最初にモニタする関数 */ time2 = alt_timestamp(); func1(); /* 2番目にモニタする関数 */ time3 = alt_timestamp();

printf (“time in func1 = %u ticks\n”, (unsigned int) (time2 – time1));

printf (“time in func2 = %u ticks\n”, (unsigned int) (time3 – time2));

printf (“Number of ticks per second = %u\n”, (unsigned int)alt_timestamp_freq());

} return 0;}


フラッシュ・デバイスの使用


HALは、不揮発性フラッシュ・メモリ・デバイス用の汎用デバイス・モデルを提供します。フラッシュ・メモリは、専用のプログラミング・プロトコルを使用して、データを格納します。HAL API は、データをフラッシュに書き込むための関数を提供します。例えば、これらの関数を使用して、フラッシュ・ベースのファイル・サブシステムを実装できます。

また、HAL APIは、フラッシュを読み取るための関数を提供します。ただし、一般にこの機能は不要です。大部分のフラッシュ・デバイスでは、プログラムは読み取りの際にフラッシュ・メモリ空間をシンプルなメモリとして扱うことができ、専用の HAL API 関数を呼び出す必要はありません。フラッシュ・デバイスに、アルテラ EPCSシリアル・コンフィギュレーション・デバイスなど、データ読み取り専用プロトコルが用意されている場合、データの読み取りと書き込みのどちらも、HAL APIを使用して実行する必要があります。

このセクションでは、フラッシュ・デバイス・モデル用の HAL API について説明します。以下の 2つの APIは、異なるレベルでフラッシュへのアクセスを可能にします。

■ シンプル・フラッシュ・アクセス－バッファをフラッシュに書き込み、フラッシュからその内容を読み取るためのシンプルな APIです。他のフラッシュ消去ブロックの以前の内容は保持されません。

■ 高精度フラッシュ・アクセス－個々のブロックへの書き込みまたはブロックの消去において、制御を必要とするプログラム用の高精度な関数です。一般に、この機能はファイル・サブシステムの管理に必要です。

フラッシュ・デバイスにアクセスするための API関数は、sys/alt_flash.hで定義されています。




シンプル・フラッシュ・アクセス

このインタフェースは、alt_flash_open_dev()、alt_write_flash()、alt_read_flash()、およびalt_flash_close_dev()で構成されています。4–16 ページの「例：シンプル・フラッシュ API 関数の使用」のコードは、これらすべての関数の使い方を、1 つのコード例で示しています。alt_flash_open_dev()を呼び出してフラッシュ・デバイスをオープンすると、フラッシュ・デバイスへのファイル・ハンドルが返されます。この関数は、system.h で定義されているとおり、唯一の引数としてフラッシュ・デバイスの名前を受け取ります。

ハンドルを取得すれば、alt_write_flash()関数を使用して、フラッシュ・デバイスにデータを書き込むことができます。プロトタイプは以下のとおりです。

int alt_write_flash(alt_flash_fd* fd, int offset, const void* src_addr, int length )

この関数を呼び出すと、ハンドル fd で識別されるフラッシュ・デバイスに、先頭から offset バイトの書き込みが実行されます。書き込むデータは、src_addrで指定されるアドレスから送られ、そのデータ量は lengthです。

また、フラッシュ・デバイスからのデータの読み取りには、alt_read_flash() 関数も利用できます。プロトタイプは以下のとおりです。

int alt_read_flash( alt_flash_fd* fd, int offset, void* dest_addr, int length )

この関数を呼び出すと、ハンドル fd を持つフラッシュ・デバイスの先頭から offset バイトが読み取られます。データは、dest_addr で示される位置に書き込まれ、データ量は length です。大部分のフラッシュ・デバイスでは、標準メモリとしてメモリ内容にアクセスできるため、alt_read_flash()を使用する必要はありません。

関数 alt_flash_close_dev() は、ファイル・ハンドルを受け取ってデバイスをクローズします。この関数のプロトタイプは以下のとおりです。

void alt_flash_close_dev(alt_flash_fd* fd )



以下のコードは、system.hで定義された /dev/ext_flashという名前のフラッシュ・デバイスに、シンプル・フラッシュAPI関数を使用してアクセスする方法を示します。

例：シンプル・フラッシュ API関数の使用

#include <stdio.h>#include <string.h>#include “sys/alt_flash.h”#define BUF_SIZE1024

int main (){alt_flash_fd* fd;int ret_code;

char source[BUF_SIZE]; char dest[BUF_SIZE]; /* ソース・バッファをすべて 0xAAに初期化 */ memset(source, 0xa, BUF_SIZE);

fd = alt_flash_open_dev(“/dev/ext_flash”); if (fd) { ret_code = alt_write_flash(fd, 0, source, BUF_SIZE); if (!ret_code) { ret_code = alt_read_flash(fd, 0, dest, BUF_SIZE); if (!ret_code) { /*

* 成功* この時点で、フラッシュはすべて 0xaとなり、* フラッシュの内容がすべて destに読み戻されているはずです。*/

} } alt_flash_close_dev(fd); } else { printf(“Can’t open flash device\n”); }return 0;

}



ブロックの消去または破壊

一般に、フラッシュ・メモリは複数のブロックに分割されます。ブロックにデータを書き込む前に alt_write_flash() で、ブロックの内容を消去しなければならないことがあります。この場合、ブロックの既存の内容は保存されません。ブロック境界をまたいで書き込みを行う場合も、この動作によって予期しないデータ破壊（消去）が発生することがあります。現在のフラッシュ・メモリの内容を保存する場合は、より高精度なフラッシュ関数を使用します。4–18ページの「高精度フラッシュ・アクセス」を参照してください。

表 4–3は、シンプルなフラッシュ・アクセス関数を使用した書き込みによって、予期しないデータ破壊がどのようにして発生するかを示します。表 4–3は、2つの 4Kバイト・ブロックで構成される 8Kバイトのフラッシュ・メモリの例を示します。最初に、すべて 0xAAからなる 5 Kバイトを、フラッシュ・メモリのアドレス 0x0000に書き込み、次にすべて0xBBからなる2 Kバイトをアドレス0x1400に書き込みます。最初の書き込みが成功すると（時刻 t(2)）、フラッシュ・メモリには 0xAAが 5 Kバイト格納され、それ以外は空（つまり、0xFF）になります。次に、2回目の書き込みが開始されますが、2 番目のブロックに書き込む前に、このブロックが消去されます。この時点（t(3)）で、フラッシュ・メモリには、0xAAが 4 Kバイト、0xFFが 4 Kバイト格納されています。2回目の書き込みが終了すると（t(4)）、アドレス 0x1000にある 2 Kバイトの0xFFが予期せず破壊されます。

表 4–3.フラッシュへの書き込みと予期しないデータ破壊発生の例

アドレスブロック

時刻 t(0) 時刻 t(1) 時刻 t(2) 時刻 t(3) 時刻 t(4)

1回目の書き込み前

1回目の書き込み 2回目の書き込み

ブロックの消去後

データ 1の書き込み後

ブロックの消去後

データ 2の書き込み後

0x0000 1 ?? FF AA AA AA

0x0400 1 ?? FF AA AA AA

0x0800 1 ?? FF AA AA AA

0x0C00 1 ?? FF AA AA AA

0x1000 2 ?? FF AA FF FF (1)

0x1400 2 ?? FF FF FF BB

0x1800 2 ?? FF FF FF BB

0x1C00 2 ?? FF FF FF FF

表 4–3の注：(1) 2回目の書き込みのための消去中に、予期せずクリアされて FFに変化した。



高精度フラッシュ・アクセス

その他にも、フラッシュへの書き込みを最高レベルの精度で完全に制御する 3つの関数

alt_get_flash_info()alt_erase_flash_block()alt_write_flash_block()

があります。

フラッシュ・メモリの性質上、あるブロック内の 1アドレスだけを消去することはできません。一度にブロック全体を消去（つまり、すべて 1に設定）する必要があります。フラッシュ・メモリへの書き込みでは、ビットが 1から 0に変化するだけで、どのビットでも 0から 1に変更するには、そのビットが含まれるブロック全体を消去する必要があります。したがって、ブロック内の特定の位置のみ変更し、周囲の内容が変化しないようにするには、ブロック全体の内容をバッファに読み出し、バッファ内で値を変更し、フラッシュ・ブロックを消去して、最後にブロック・サイズのバッファ全体をフラッシュ・メモリに書き戻すことが必要です。高精度フラッシュ・アクセス関数を利用すれば、このプロセスをフラッシュ・ブロック・レベルで実行できます。

alt_get_flash_info()は、消去領域の数、各領域内の消去ブロック数、および各消去ブロックのサイズを取得します。プロトタイプは以下のとおりです。

int alt_get_flash_info( alt_flash_fd* fd, flash_region** info, int* number_of_regions)

呼び出しが成功した場合、関数が返された時点で、number_of_regionsが示すアドレスには、フラッシュ・メモリ内の消去領域の数が格納されており、infoは 1番目の flash_regionで記述されるアドレスを示しています。

flash_region 構造体は sys/alt_flash_types.h で定義され、そのtypedefは以下のとおりです。

typedef struct flash_region{ int offset;/* フラッシュの開始位置からこの領域までのオフセット */ int region_size;/* この消去領域のサイズ */ int number_of_blocks;/* この領域のブロック数 */ int block_size;/* この消去領域内の各ブロックのサイズ */}flash_region;



alt_get_flash_info()を呼び出して情報を取得すると、フラッシュのブロックを個別に消去またはプログラムできます。

alt_erase_flash()は、フラッシュ・メモリ内の単一のブロックを消去します。プロトタイプは以下のとおりです。

int alt_erase_flash_block( alt_flash_fd* fd, int offset,

int length)

フラッシュ・メモリは、ハンドル fd で識別されます。ブロックは、フラッシュ・メモリの先頭からの offsetバイトとして認識され、ブロック・サイズは lengthに渡されます。

alt_write_flash_block()は、フラッシュ・メモリ内の 1ブロックに書き込みを実行します。プロトタイプは以下のとおりです。

int alt_write_flash_block( alt_flash_fd* fd, int block_offset, int data_offset, const void *data, int length)

この関数は、ハンドル fdで識別されるフラッシュ・メモリに書き込みを実行します。フラッシュの先頭から block_offsetバイトの位置にあるブロックに書き込みます。この関数は、dataで示された位置からlengthバイトのデータを、フラッシュ・デバイスの先頭から data_offset バイトの位置に書き込みます。

これらのプログラムおよび消去関数では、アドレス・チェックは実行されず、また書き込み操作の範囲が隣のブロックに及ぶかどうかも検証されません。プログラムまたは消去するブロックについて、適切な情報を渡すことが必要です。

以下のコードは、高精度フラッシュ・アクセス関数の使用法を示します。

例：高精度フラッシュ・アクセス API関数の使用

#include <string.h>#include "sys/alt_flash.h"#define BUF_SIZE 100

int main (void){ flash_region* regions; alt_flash_fd* fd; int number_of_regions; int ret_code; char write_data[BUF_SIZE];


DMAデバイスの使用

/* write_dataをすべて 0xaに設定 */ memset(write_data, 0xA, BUF_SIZE);

fd = alt_flash_open_dev(EXT_FLASH_NAME);

if (fd) { ret_code = alt_get_flash_info(fd,

&regions, &number_of_regions);

if (number_of_regions && (regions->offset == 0)) { /* 1番目のブロックを消去 */ ret_code = alt_erase_flash_block(fd,

regions->offset, regions->block_size); if (ret_code) {

/* * write_dataから BUF_SIZEバイト、つまり 100バイトを* フラッシュの 1番目のブロックに書き込みます*/

ret_code = alt_write_flash_block( fd, regions->offset,

regions->offset+0x100, write_data,

BUF_SIZE); } } }return 0;

}


HALは、DMA（Direct Memory Access）デバイスに対応するデバイス抽象化モデルを提供します。これらのモデルは、データ・ソースからディスティネーションへのバルク・データ転送を実行するペリフェラルです。イーサネット接続など、メモリやその他のデバイスをソースおよびディスティネーションにすることができます。

HAL DMAデバイス・モデルにおいて、DMA転送は、2つのカテゴリ、つまり送信と受信のいずれかに分類されます。したがって、HALは送信チャネルと受信チャネルを実装するために、2 つのデバイス・ドライバを提供しています。送信チャネルは、ソース・バッファにデータを受け取り、それをディスティネーション・デバイスに送信します。受信チャネルは、デバイスからデータを受信し、ディスティネーション・バッファに格納します。基本ハードウェアの実装状態に応じて、ソフトウェアでは、これら 2つのエンドポイントの一方のみにアクセスすることもできます。



図 4-2 に、DMA 転送の 3 つの基本形式を示します。メモリ間でデータをコピーする場合、受信 DMAチャネルと送信 DMAチャネルを同時に使用します。

図 4-2. DMA転送の 3つの基本形式

DMAデバイスにアクセスするための API関数は、sys/alt_dma.hで定義されています。


DMA デバイスは、物理メモリの内容を操作するため、データの読み取りおよび書き込みを行う際には、キャッシュの相互作用を考慮する必要があります。7–1ページの「キャッシュ・メモリ」を参照してください。

DMA送信チャネルDMA送信要求は、DMA送信デバイスのハンドルを使用して、キューに格納されます。ハンドルは関数 alt_dma_txchan_open()を使用して取得します。この関数は、system.hで定義されているように、1つの引数（使用するデバイスの名前）のみ受け取ります。

1.ペリフェラルからのデータの受信

DMARecieveChannel

ペリフェラルメモリ

2. ペリフェラルへのデータの送信

DMA受信

チャネル

ペリフェラル

DMA送信

チャネル

DMA受信

チャネル

DMA送信

チャネル

3.メモリ間でのデータの転送

メモリ

メモリメモリ



以下のコードは、DMA送信デバイス dma_0のハンドルを取得する方法を示します。

例：DMAデバイスのファイル・ハンドルの取得

#include <stddef.h>#include “sys/alt_dma.h”

int main (void){ alt_dma_txchan tx;

tx = alt_dma_txchan_open (“/dev/dma_0”); if (tx == NULL) { /* エラー */ } else { /* 成功 */ } return 0;}

このハンドルを使用すると、alt_dma_txchan_send() によって送信要求を送信できます。プロトタイプは以下のとおりです。

typedef void (alt_txchan_done)(void* handle);

int alt_dma_txchan_send (alt_dma_txchan dma, const void* from, alt_u32 length, alt_txchan_done* done, void* handle);

alt_dma_txchan_send()を呼び出すと、チャネルdmaに送信要求が送信され、lengthバイトのデータがアドレス fromから送信されます。この関数は、すべての DMA転送が完了する前に呼び出し元に復帰します。戻り値は、要求が正常にキューに格納されたかどうかを示します。負の戻り値は、要求が失敗したことを示します。転送が完了すると、通知を行うために引数 handleを渡して、ユーザ提供の関数 doneが呼び出されます。

DMA送信チャネルを操作するために、さらに 2つの関数alt_dma_txchan_space()、alt_dma_txchan_ioctl()が提供されています。alt_dma_txchan_space()関数は、デバイスのキューに格納できる追加送信要求数を返します。alt_dma_txchan_ioctl()関数は、送信デバイスのデバイス固有操作を実行します。



DMA受信チャネルDMA 受信チャネルは、DMA 送信チャネルと同様の方式で動作します。DMA受信チャネルのハンドルは、alt_dma_rxchan_open()関数を使用して取得できます。ハンドルを取得すると、alt_dma_rxchan_prepare()関数を使用して、受信要求を送信できます。alt_dma_rxchan_prepare()のプロトタイプは以下のとおりです。

typedef void (alt_rxchan_done)(void* handle, void* data);

int alt_dma_rxchan_prepare (alt_dma_rxchan dma, void* data, alt_u32 length, alt_rxchan_done* done, void* handle);

この関数を呼び出すと、受信要求がチャネル dma に送信され、最大でlegthバイトのデータがアドレスdataに置かれます。この関数は、DMA転送が完了する前に呼び出し元に復帰します。戻り値は、要求が正常にキューに格納されたかどうかを示します。負の戻り値は、要求が失敗したことを示します。転送が完了すると、通知を行うための引数 handle、およびデータを受け取るためのポインタを渡して、ユーザが提供した関数 doneが呼び出されます。

DMA受信チャネルを操作するために、さらに 2つの関数alt_dma_rxchan_depth()、alt_dma_rxchan_ioctl()が用意されています。

alt_dma_rxchan_depth()関数は、デバイスのキューに格納できる最大受信要求数を返します。alt_dma_rxchan_ioctl()関数は、受信デバイスのデバイス固有操作を実行します。

以下のコードは、DMA受信要求を送信し、転送が完了するまで main()で待機するアプリケーション例を示します。

例：受信チャネルでの DMA転送

#include <stdio.h>#include <stddef.h>#include <stdlib.h>#include “sys/alt_dma.h”#include “alt_types.h”

/* 転送の完了を示すために使用するフラグ */volatile int dma_complete = 0;

/* 転送が完了したときに呼び出される関数 */void dma_done (void* handle, void* data)



{ dma_complete = 1;}

int main (void){ alt_u8 buffer[1024]; alt_dma_rxchan rx;

/* デバイスのハンドルを取得 */ if ((rx = alt_dma_rxchan_open (“/dev/dma_0”)) == NULL) { printf (“Error:failed to open device\n”); exit (1); } else { /* 受信要求を送信 */ if (alt_dma_rxchan_prepare (rx, buffer, 1024, dma_done, NULL)

< 0) { printf (“Error:failed to post receive request\n”); exit (1); } /* 転送が完了するまで待機 */ while (!dma_complete); printf (“Transaction complete\n”); alt_dma_rxchan_close (rx); } return 0;}

メモリ間 DMA転送メモリ・バッファの間でデータをコピーするには、受信 DMAドライバと送信 DMAドライバの両方が必要です。以下のコードは、受信要求に続いて送信要求をキューに格納して、メモリ間 DMA転送を実現するプロセスを示します。

例：メモリ間でのデータのコピー

#include <stdio.h>#include <stdlib.h>

#include "sys/alt_dma.h"#include "system.h"

static volatile int rx_done = 0; /* * データ受信の完了を示す通知を取得する * コールバック関数 */



static void done (void* handle, void* data){ rx_done++;}

/* * */ int main (int argc, char* argv[], char* envp[]){ int rc;

alt_dma_txchan txchan; alt_dma_rxchan rxchan;

void* tx_data = (void*) 0x901000; /* 送信するデータを示すポインタ */ void* rx_buffer = (void*) 0x902000; /* rxバッファを示すポインタ */

/* 転送チャネルを作成 */ if ((txchan = alt_dma_txchan_open("/dev/dma_0")) == NULL) { printf ("Failed to open transmit channel\n"); exit (1); } /* 受信チャネルを作成 */ if ((rxchan = alt_dma_rxchan_open("/dev/dma_0")) == NULL) { printf ("Failed to open receive channel\n"); exit (1); } /* 送信要求を送信 */ if ((rc = alt_dma_txchan_send (txchan,

tx_data, 128, NULL, NULL)) < 0)

{ printf ("Failed to post transmit request, reason = %i\n", rc); exit (1); } /* 受信要求を送信 */ if ((rc = alt_dma_rxchan_prepare (rxchan,

rx_buffer, 128, done, NULL)) < 0)

{


コード・フットプリントの削減

printf ("Failed to post read request, reason = %i\n", rc); exit (1); }

/* 転送が完了するまで待機 */ while (!rx_done);

printf ("Transfer successful!\n");

return 0;}


コードを格納するメモリ・デバイスにはコストがかかるため、コード・サイズは常にシステム開発者の悩みです。コード・サイズのコントロールと削減は、このコストを管理する上で重要です。

HAL環境は、一般にユーザが要求する機能のみが全体的なコード・フットプリントに関与するように設計されています。ユーザの Nios II ハードウェア・システムに、プログラムで使用するだけのペリフェラルしかない場合、HALはそのハードウェアを制御するのに必要なドライバしか持つ必要はありません。

以下のセクションでは、コード・サイズを絶対最小サイズに削減する必要がある場合に検討すべきオプションについて説明します。

コンパイラ最適化の有効化

nios2-elf-gcc コンパイラに -O3 compiler 最適化レベルを使用します。すると、コードはサイズと速度の両方が最大限に最適化されてコンパイルされます。これは、システム・ライブラリとアプリケーション・プロジェクトの両方に対して行う必要があります。

スモール・フットプリント・デバイス・ドライバの使用

いくつかのデバイスでは、フル機能の「高速」型、および軽量の「スモール」型の 2つの改良型ドライバが用意されています。これら 2つの改良型によって、どの機能が利用できるかは、デバイスによって異なります。デフォルトで、HALシステム・ライブラリは常に高速型ドライバを使用します。Nios II IDEでHALシステム・ライブラリのUse Small FootprintDrivers オプションをオンにすると、スモール・フットプリント・ドライバを選択できます。HALシステム・ライブラリを構築するときには、プリプロセッサ・オプション –DALT_USE_SMALL_DRIVERSが利用できます。



表 4–4に、スモール・フットプリント・ドライバを提供するアルテラ製Nios II ペリフェラルを示します。また、その他のペリフェラルもスモール・フットプリント・オプションに影響されることがあります。スモール・フットプリント・ドライバの動作に関する詳細は、各ペリフェラルのデータシートを参照してください。

ファイル・ディスクリプタ・プールの削減

キャラクタ・モード・デバイスおよびファイルにアクセスするファイル・ディスクリプタは、利用可能なファイル・ディスクリプタのプールから割り当てられます。このプールのサイズは、コンパイル時の定数ALT_MAX_FDによって定義され、Nios II IDEのシステム・ライブラリ・プロパティとして管理できます。デフォルトは 32です。例えば、プログラムで 10のみ必要であれば、ALT_MAX_FDの値を小さくすることによって、メモリ・フットプリントを削減できます。

/dev/nullの使用ブート時において、標準入力、標準出力、および標準エラーは、すべてnull デバイス、つまり /dev/null に送られます。これによって、ドライバの初期化中に printf()を呼び出しても何も実行されず、動作に影響を与えません。すべてのドライバがインストールされると、これらのストリームは、HALで構成されたチャネルにリダイレクトされます。このリダイレクトを実行するコードのフットプリントは小さなものですが、stdin、stdout、および stderrに対して nullを選択すれば、リダイレクトを完全に回避できます。このように選択するには、標準出力または標準エラーに対して送信されたすべてのデータを破棄し、プログラムで stdin を介した入力を受信しないことが前提となります。stdin、stdout、および stderrチャネルは、Nios II IDEではシステム・ライブラリ・プロパティとして制御できます。

表 4–4. P. スモール・フットプリント・ドライバを提供するアルテラのペリフェラル

ペリフェラルスモール・フットプリント動作

UART IRQ駆動ではなく、ポーリングによって動作します。

JTAG UART IRQ駆動ではなく、ポーリングによって動作します。

共通フラッシュ・インタフェース・コントローラ

ドライバは、スモール・フットプリント・モードでは除外されます。

LCDモジュール・コントローラドライバは、スモール・フットプリント・モードでは除外されます。



ANSI Cではなく UNIXファイル I/Oの使用UNIX形式のファイル I/O関数を使用してデバイスやファイルにアクセスすると、アクセスごとにそれに付随するパフォーマンス・オーバヘッドが発生します。パフォーマンスを改善するために、ANSI C ファイルI/Oを使用することでバッファ使用のアクセスが可能になり、実行されるハードウェア I/O アクセスの総数が少なくなります。また、ANSI CAPI は柔軟性が高く、使いやすくなります。しかし、これらの利点は、コード・フットプリントを犠牲にして実現されています。UNIX 形式のI/O APIを直接使用することで、コード・フットプリントを削減することが可能です。4–5 ページの「UNIX 形式のインタフェース」を参照してください。

縮小版 Newlib Cライブラリの使用多くの場合、エンベデッド・システムには完全な ANSI C標準ライブラリは不要です。HAL は、一般にエンベデッド・システムでは不要なnewlibの機能を取り除くために、newlib ANSI C標準ライブラリの縮小版を提供します。縮小版の newlib 実装には、小さなコード・フットプリントが必要です。この newlib実装は、Nios II IDEではシステム・ライブラリ・プロパティとして制御できます。また、このオプションは、nios2-elf-gccの -msmallcコマンドライン・オプションでも制御できます。

縮小版の newlib Cライブラリがサポートする関数の詳細については、NiosII 開発キットと共にインストールされた newlib の資料を参照してください。（Windowsのスタート・メニューから）プログラム > Altera > Nios IIDevelopment Kit > Nios II Documentationの順にクリックします。



表 4–5に、縮小版 newlib Cライブラリ実装の制限事項を要約します。

表 4–5.縮小版 newlib Cライブラリの制限事項

制限事項影響する関数

printf()ルーチン・ファミリに対しては浮動小数点はサポートされません。右記の関数は実装されていますが、%fオプションと %gオプションはサポートされていません。

asprintf()fiprintf()fprintf()iprintf()printf()siprintf()snprintf()sprintf()vasprintf()vfiprintf()vfprintf()vprintf()vsnprintf()vsprintf()

scanf()ルーチン・ファミリはサポートされません。右記の関数は、サポートされていません。

fscanf()scanf()sscanf()vfscanf()vscanf()vsscanf()

シークはサポートされていません。右記の関数は、サポートされていません。 fseek()ftell()

FILE *のオープン /クローズはサポートされていません。既にオープンされたstdout、stderr、および stdinのみ利用できます。右記の関数は、サポートされていません。

fopen()fclose()fdopen()fcloseall()fileno()

FILE *ルーチン（つまり、すべての stdio.hルーチン）のバッファ機能はありません。

stdio.hで定義されたすべてのルーチン。

これらの関数は、サポートはされていますが、バッファ機能はありません。

setbuf()およびsetvbuf()はサポートされていません。

ロケールはサポートされていません。 setlocale()localeconv()

上記の関数がサポートされていないため、C++のサポートはありません。



未使用デバイス・ドライバの除去

ハードウェア・デバイスがシステムに存在する場合、Nios II IDEは、そのデバイスがドライバを必要するものと想定し、それに応じて HAL システム・ライブラリを構成します。適切なドライバを見つけることができれば、HALはこのドライバのインスタンスを作成します。ユーザ・プログラムで実際にデバイスにアクセスしない場合、デバイス・ドライバの初期化にリソースが不必要に消費されることになります。

デバイスがハードウェアに含まれているが、ユーザ・プログラムを使用しない場合は、デバイスを完全に削除するオプションを検討する必要があります。これによって、コード・フットプリントと FPGAリソースがともに削減されます。ただし、デバイスが存在してもソフトウェアがドライバを必要としない、回避不能なケースもあります。

最も一般的な例は、フラッシュ・メモリです。この場合、ユーザ・プログラムはフラッシュ・メモリへの書き込みアクセスが必要ないことが多いため、フラッシュ・ドライバも不要です。このような場合、オプション –DALT_NO_CFI_FLASH をプリプロセッサに指定すれば、HAL がフラッシュ・ドライバをシステム・ライブラリに組み込まないようにすることができます。

独立した環境を使用して、デバイス・ドライバの初期化プロセスをより詳細に制御できます。4–31ページの「ブート・シーケンスおよびエントリ・ポイント」を参照してください。

非完全終了に対する _exit()の使用HALは、システム・シャットダウン時に exit()関数を呼び出して、プログラムからの終了を実現します。exit()は Cライブラリの内部 I/Oバッファをすべて消去し、atexit()に登録された関数を呼び出します。特に、exit()は main()から戻るときに呼び出されます。

一般に、エンベデッド・システムは終了することがないため、このコードは冗長となります。クリーンな終了の実現に伴うオーバヘッドを回避するために、ユーザ・プログラムでは、exit()関数の代わりに _exit()関数が使用できます。この関数ではソース・コードの変更は必要ありません。終了動作は、Nios II IDEでのシステム・ライブラリ・プロパティとして、またはプリプロセッサ・オプション -Dexit=_exit を指定することによって制御できます。



命令エミュレーションの無効化

HALソフトウェア例外ハンドラは、プロセッサが乗算命令および除算命令をサポートしていない場合は、これらの命令をエミュレートできます。この機能は、システム・ライブラリ・プロジェクトの C プリプロセッサ・マクロ ALT_NO_INSTRUCTION_EMULATIONを定義すれば無効にできます。

使用中のコアがハードウェア乗算 / 除算をサポートしていれば、プロセッサがハードウェア乗算 /除算をサポートしていない場合でも、ほとんどのケースでこの機能を無効にすることができます。ハードウェア乗算 /除算命令をサポートしていないシステムに対して構築された、システム・ライブラリ・プロジェクトおよびアプリケーション・プロジェクトは、-mno-hw-mul オプションを指定してコンパイルおよびリンクされます。したがって、これらのプロジェクトの一部としてコンパイルされたコードに対しては、乗算命令のエミュレーションは不要です。除算命令エミュレーションは、–mhw-divオプションを指定してコードを明示的にコンパイルする場合のみ必要です。

ブート・シーケンスおよびエントリ・ポイント

これまでの説明では、プログラムのエントリ・ポイントを関数 main()と仮定していました。それに代わって利用できるエントリ・ポイントとして alt_main()があり、これを使用するとブート・シーケンスをより高度に制御できます。main()または alt_main()からのエントリの概念は、ホスト型アプリケーションと独立型アプリケーションの違いです。

ホスト型アプリケーションと独立型アプリケーション

ANSI C 規格では、ホスト型アプリケーションは、main() を呼び出して実行を開始するアプリケーションとして定義されています。main()の開始時に、ホスト型アプリケーションは、ランタイム環境およびすべてのシステム・サービスが初期化され、使用できる準備が整っていると仮定しています。HALシステム・ライブラリでも同様に仮定されます。事実、ホスト型環境では、システム内にどのデバイスが存在するか把握したり、各デバイスの初期化方法を考慮する必要がなく、HALがシステム全体を自動的に初期化するため、Nios II を初めて使用するプログラマにとって、ホスト型環境は HALの最大の利点の 1つです。


ブート・シーケンスおよびエントリ・ポイント

ANSI C 規格は、自動初期化を回避する代替エントリ・ポイントも用意しており、Nios II プログラマが使用されているハードウェアを手動で初期化することを想定しています。alt_main()関数は独立型環境を提供し、ユーザはシステムの初期化を完全に制御できます。独立型環境では、プログラマはプログラムで使用されるシステム機能を手動で初期化する必要があります。例えば、独立型環境では、alt_main()が最初にキャラクタ・モード・デバイス・ドライバをインスタンス化し、stdout をデバイスにリダイレクトしない限り、printf()を呼び出しても正しく機能しません。

独立型環境を使用すると、ユーザは HAL の利点を利用できず、システムの初期化をすべて手動で実行しなければならないため、Nios II プログラムの記述は複雑になります。独立型環境を検討する主な目的が、コード・フットプリントの削減の場合は、4–26ページの「コード・フットプリントの削減」で説明した推奨事項を考慮してください。HAL システム・ライブラリのフットプリントを削減するには、独立型モードを使用するよりも、Nios IIIDEで利用できるオプションを使用する方が簡単です。

Nios II 開発キットには、独立型プログラムとホスト型プログラムの例が用意されています。


HALベース・プログラムのブート・シーケンスHALは、以下のブート・シーケンスを実行するシステム初期化コードを提供します。

■ 命令キャッシュおよびデータ・キャッシュを消去する。■ スタック・ポインタをコンフィギュレーションする。■ グローバル・ポインタをコンフィギュレーションする。■ リンカが供給するシンボル __bss_startおよび __bss_endを使用して、BSS領域をゼロで初期化する。これらは、BSS領域の先頭および末尾を示すポインタです。

■ システム内にブート・ローダが存在しない場合に、.rwdata、.rodata、および/または例外セクションをRAMにコピーする（4–37ページの「ブート・モード」を参照）。

■ alt_main()を呼び出す。



alt_main()関数を用意していない場合は、デフォルト実装が以下のステップを実行します。

■ ALT_OS_INIT() を呼び出して、オペレーティング・システム固有の必要な初期化を実行する。OS スケジューラがないシステムの場合、このマクロは無効です。

■ HAL がオペレーティング・システムで使用されている場合、HAL ファイル・システムへのアクセスを制御する alt_fd_list_lock セマフォ（semaphore）を初期化する。

■ 割り込みコントローラを初期化し、割り込みを可能にする。■ alt_sys_init() 関数を呼び出して、システム内のすべてのデバイス・ドライバとソフトウェア・コンポーネントを初期化する。NiosII IDE は、各 HAL システム・ライブラリに対応するファイルalt_sys_init.cを自動的に作成および管理します。

■ 適切なデバイスを使用するために、C 標準 I/O チャネル（stdin、stdout、および stderr）をリダイレクトする。

■ _do_ctors()関数を使用して、C++コンストラクタを呼び出す。■ システム・シャットダウン時に呼び出される C++ デストラクタを登録する。

■ main ()を呼び出す。■ exit()を呼び出し、main()の戻りコードをexit()の入力引数として渡す。

このデフォルト実装は、Nios II 開発キットのインストール・ディレクトリ内のファイル alt_main.cに記述されています。

ブート・シーケンスのカスタマイズ

Nios II IDE プロジェクトで alt_main() を定義するだけで、スタートアップ・シーケンスの独自の実装を提供できます。これにより、ブート・シーケンスを完全に制御し、HALサービスを選択することができます。ユーザのアプリケーションで alt_main()エントリ・ポイントが必要な場合、デフォルト実装を開始ポイントとしてコピーし、必要に応じてカスタマイズできます。

この関数は呼び出し元に復帰しません。alt_main()のプロトタイプは以下のとおりです。

void alt_main (void)


メモリの使用

HAL構築環境の特徴の 1つは、すべてのソース・ファイルおよびインクルード・ファイルがサーチ・パスを使用して検索されることです。常にユーザのプロジェクトが最初にチェックされるため、デフォルトのデバイス・ドライバおよびシステム・コードをユーザ自身の実装に置き換えることができます。例えば、alt_sys_init.cの代わりにユーザ独自のファイルを供給する場合、そのファイルをユーザのシステム・プロジェクト・ディレクトリに置けばそれが可能です。ユーザが提供したファイルは、自動生成ファイルに優先して使用されます。

alt_sys_init()の詳細については、5–1ページの「HAL用デバイス・ドライバの開発」を参照してください。

メモリの使用このセクションでは、HALがメモリを使用する方法と、HALがコード、データ、スタックなどをメモリ内で配置する方法について説明します。

メモリ・セクション

デフォルトでは、HALベースシステムは、Nios II IDEで作成および管理される自動生成されたリンカ・スクリプトを使用してリンクされます。このリンカ・スクリプトは、利用可能なメモリ・セクション内で、コードおよびデータのマッピングを制御します。自動生成されたリンカ・スクリプトは、システム内の各物理メモリ・デバイスに対するセクションを作成します。例えば、system.h ファイルで定義された on_chip_memory という名前のメモリ・コンポーネントが存在する場合は、.on_chip_memoryという名前のメモリ・セクションが存在します。

メモリ・デバイスに Nios II プロセッサのリセット・アドレスや例外アドレスが含まれるのは、特殊な場合です。メモリ・デバイスにこれらのアドレスのいずれかが含まれる場合、そのアドレス以下のすべてのメモリは、そのメモリ・デバイスに関連付けられたセクションから除外されます。32バイトのリセット・セクションはリセット・アドレスを開始位置として構築され、リセット・ハンドラ専用として使用するために予約されます。

このメモリ方式で作成できる使用不可領域は、マルチプロセッサ・システムの他のプロセスが使用できます。



図 4-3 に、物理メモリをメモリ・セクションに分割する方法の一例を示します。あくまでも説明を目的として、この例では、リセット・アドレスおよび例外アドレスの配置によって使用不可となるメモリ領域を人為的に作成しています。デフォルトでは、アルテラのツールは、リセット・アドレスと例外アドレスをメモリにマップするため、アクセス不可のメモリは存在しません。デフォルトのメモリ・マップを使用するシステムでは、リセット・アドレスはデバイス・メモリまたはフラッシュ・メモリのオフセット 0x0 にあり、例外アドレスはシステム生成時に SOPCBuilderに指定されたメモリ内のオフセット 0x20にあります。

図 4-3. HALのメモリ・パーティション

メモリ・パーティションへのコードとデータの割り当て

このセクションでは、特定のメモリ・セクションでプログラム・コードとデータの配置を制御する方法について説明します。通常、Nios II 開発ツールは、合理的なデフォルトのパーティション作成方法を自動的に選択します。例えば、性能を向上させるための一般的な技法は、性能重視のコードとデータをアクセス・タイムが高速なデバイス RAM に配置します。また、デバッグ段階では RAM 内の位置からプロセッサをリセット（つまりブート）し、システムのリリース・バージョンではフラッシュ・メモリからブートすることも一般的です。このような場合は、どのコードがどのセクションに属するかを手動で指定する必要があります。

物理メモリ：on_chip_ram

0x0

セクション「.on_chip_ram」

物理メモリ：sdram

使用不可

セクション「.reset」

使用不可

セクション「.sdram」

0x0

リセット・アドレス

リセット・アドレス+0x10

例外アドレス


メモリの使用

シンプルな配置オプション

リセット・ハンドラ・コードは常に、.reset パーティションに配置されます。例外ハンドラ・コードは常に、例外アドレスを含むセクション内の最初のコードになります。デフォルトでは、その他のコードおよびデータは、以下の 3つの出力セクションに分割されます。

■ .text－その他のすべてのコード■ .rodata－読み取り専用データ■ .rwdata－読み取りおよび書き込みデータ（ゼロに初期化されたデータを含む）

.text、.rodata、および .rwdataの配置は、Nios II IDEでシステム・ライブラリ・プロパティとして制御できます。


高度な配置オプション

ユーザのプログラム・ソース・コード内で、特定のコードに対してターゲット・メモリ・セクションを指定できます。Cまたは C++でこの指定を行う場合は、section属性を使用できます。以下のコードは、.on_chip_memoryという名前のメモリ内の変数foo、および.sdramという名前のメモリ内の関数 bar()を配置する方法を示します。

例：特定のメモリ・セクションへの Cコードの手動による割り当て

/* セクション属性を使用する場合は、データの初期化が必要 */int foo __attribute__ ((section (".on_chip_memory"))) = 0;

void bar __attribute__ ((section (".sdram"))) (void){ foo++;}

アセンブリでは、この処理は .section 指示文を使用して実行します。例えば、次に示す行以降のすべてのコードは、on_chip_memoryという名前のメモリ・デバイスに配置されます。

.section .on_chip_memory

これらの機能の使用法の詳細については、GNU コンパイラおよびアセンブラの資料を参照してください。



ヒープおよびスタックの配置

ヒープとスタックは両方とも常に、.rwdataセクションと同じメモリ・パーティションに存在するように配置されます。スタックは、セクションの末尾から下方（下位アドレスへ）に拡張されます。ヒープは、.rwdata セクション内で最後に使用されたメモリから上方に拡張されます。

HALは、実行時にヒープおよびスタックに十分なスペースがあるかどうかはチェックしません。ユーザは自分のプログラムが、ヒープとスタックに利用できるメモリの制限内で動作することを保証する必要があります。

ブート・モード

リセット・ベクタを持つメモリ・デバイスがプロセッサのブート・デバイスになります。外部フラッシュまたはアルテラの EPCSシリアル・コンフィギュレーション・デバイス、あるいはオンチップ RAMをブート・デバイスにすることができます。ブート・デバイスの性質にかかわらず、すべての HAL ベースのシステムは、すべてのコードおよびデータ・セクションが最初の段階でブート・デバイス内に格納されるように構築されます。これらのセクションは、ブート時にシステム・ライブラリ・プロパティ・ページ上で指定された実行位置にコピーされます。

.textセクションがブート・デバイスに配置されていない場合、Nios IIIDE の Altera Flash Programmer は、_start を呼び出す前にすべてのコードおよびデータ・セクションをロードするブート・ローダを自動的にリセット・アドレスに配置します。EPCS デバイスからブートする場合、このローダの役割はハードウェアで提供されます。

ただし、.textセクションがブート・デバイス内に配置されている場合、システム内に個別のローダは存在しません。ローダを使用する代わりに、HAL 実行コマンド内の _reset エントリ・ポイントが直接呼び出されます。関数 _resetは、命令キャッシュを初期化した後に _startを呼び出します。そのため、フラッシュ・メモリから直接ブートおよび実行するアプリケーションの開発が可能です。

このモードで実行する場合、RAM へのロードが必要なセクションはすべて、HAL実行コマンドで行う必要があります。セクション .rwdata、.rodata、および例外セクションは、必要に応じて、alt_main()を呼び出す前に自動的にロードされます。この自動ロードは、関数alt_load()によって実行されます。


HALシステム・ライブラリ・ファイルへのパス


通常は、HALシステム・ライブラリ・ファイルは絶対に編集しないでください。ただし、参考のために、ヘッダ・ファイルなどを参照することは可能です。

HALファイルの検出Nios II システム独自の性質により、HAL システム・ライブラリ・ファイルは、いくつかの個別ディレクトリに存在します。Nios II システムごとに異なるペリフェラルが含まれることがあるため、各システムのHALシステム・ライブラリも異なります。HAL関連ファイルは、以下の場所のいずれかにあります。

■ ほとんどの HAL システム・ライブラリ・ファイルは、<Nios II インストール・パス >/componentsディレクトリに格納されています。

■ HALの汎用デバイス・モデルを定義するヘッダ・ファイルは、<Nios IIインストール・パス >/components/altera_hal/HAL/inc/sysに格納されています。#include ディレクティブの場合、これらのファイルは、<Nios IIインストール・パス >/components/altera_hal/HAL/inc/に対して参照されます。例えば、DMA ドライバを取り込むには、#include sys/alt_dma/hを使用します。

■ system.h ファイルは、特定の HAL システム・ライブラリ・プロジェクト用のNios II IDEプロジェクト・ディレクトリに格納されています。

■ Newlib ANSI C ライブラリ・ヘッダ・ファイルは、<Nios II インストール・パス >/binに格納されています。

HAL関数の置き換えユーザが関数を独自に実装するには、Nios II IDEアプリケーション・プロジェクトにファイルをインクルードします。実行ファイルを構築するときに、Nios II IDEはユーザの関数を最初に検出し、HALバージョンの関数の代わりに使用します。


5. HAL用デバイス・ドライバの開発

はじめにエンベデッド・システムは、一般に独自のデバイス・ドライバを必要とするアプリケーション固有のハードウェア機能を備えています。この章では、デバイス・ドライバを開発する方法と、それらのドライバをHAL（Hardware Abstraction Layer）システム・ライブラリに統合する方法について説明します。

ハードウェアとの直接的な連携は、デバイス・ドライバ・コードに限定する必要があります。一般に、ユーザ・プログラム・コードの大部分ではハードウェアへの低レベルなアクセスを行うことはありません。ハードウェアへのアクセスには、可能な限り、高レベルHAL API（ApplicationProgramming Interface）関数を使用してください。それによって、コードの一貫性が向上し、ハードウェア・コンフィギュレーションが異なるその他のNios® II システムへの移植性も向上します。

新しいドライバを作成する場合、ドライバは以下の 2つレベルのいずれかで、HALフレームワークに統合することができます。

■ HAL APIへの統合■ ペリフェラル固有の API

HAL APIへの統合HAL APIへの統合は、キャラクタ・モード・デバイスまたは DMAデバイスなど、HAL汎用デバイス・モデル・クラスのいずれかに属するペリフェラルに適した方法です。HAL APIへの統合では、この章で説明するデバイス・アクセス関数を記述すると、ソフトウェアから標準HAL APIを介してデバイスにアクセスできるようになります。例えば、ASCIIキャラクタを表示する新しい LCD 画面デバイスを使用する場合、キャラクタ・モード・デバイス・ドライバを記述します。このドライバを使用すると、プログラムから使い慣れた printf() 関数を呼び出して、LCD画面にキャラクタを出力できます。

NII52005-1.1

myoshida

Text Box



デバイス・ドライバ作成の開発フロー

ペリフェラル固有の APIペリフェラルが HAL 汎用デバイス・モデル・クラスのいずれにも属さない場合は、そのハードウェア実装専用のインタフェースを持つデバイス・ドライバを提供し、デバイスに対する APIを HAL APIから分離する必要があります。プログラムは、HAL APIではなくユーザが用意した関数を呼び出してハードウェアにアクセスします。

HAL APIへの統合では実装に労力を要しますが、デバイスを操作する上で、HALおよび C標準ライブラリ APIの利点が得られます。

HAL APIへの統合の詳細については、5–17ページの「HALへのデバイス・ドライバの統合」を参照してください。

この章の他のセクションは、HAL APIにドライバを統合する方法、およびペリフェラル固有のAPIを使用してドライバを作成する方法に関するものです。

C++はHALベースのプログラムでサポートされていますが、HALドライバは C++ では記述しません。ドライバ・コードは C またはアセンブラのみとし、移植性を考慮して Cを推奨します。

必要な知識

この章では、読者が HAL用の Cプログラミングに精通していることを前提としています。この章に入る前に、4–1ページの「HALを使用したプログラムの開発」の内容を確認してください。

デバイス・ドライバ作成の開発フロー

HAL用の新しいドライバを開発する手順は、デバイスの仕様によって大きく異なります。ただし、すべてのデバイス・クラスに以下の一般的な手順が適用されます。

1. レジスタについて記述するデバイス・ヘッダ・ファイルを作成します。このヘッダ・ファイルが、必要な唯一のインタフェースである場合もあります。

2. ドライバ機能を実装します。

3. main ()からテストします。

4. ドライバを HAL環境に統合する最終段階へ進みます。

5. デバイス・ドライバをHALフレームワークに統合します。


HAL用デバイス・ドライバの開発

SOPC Builderの概念

このセクションでは、ドライバ開発プロセスに関する理解を深めるために、アルテラの SOPC Builder ハードウェア・デザイン・ツールの概念について説明します。Nios II デバイス・ドライバを開発するのに、SOPCBuilderを使用する必要はありません。

system.hと SOPC Builderの関係system.h ヘッダ・ファイルは、Nios II システム・ハードウェアのすべてのソフトウェア記述を提供し、ドライバ開発の基本部分となるものです。ドライバは最下位レベルでハードウェアとやりとりを行うため、理解しやすいように system.h と Nios II プロセッサ・システム・ハードウェアを生成する SOPC Builder との関係を最初に説明しておきます。ハードウェア設計者は、SOPC Builderを使用して、Nios II プロセッサ・システムのアーキテクチャを指定し、必要なペリフェラルとメモリを統合します。したがって、各ペリフェラルの名前やコンフィギュレーションなど、system.h における定義は、SOPC Builder で選択したデザインを直接反映しています。

system.h ヘッダ・ファイルの詳細については、4–1 ページの「HAL を使用したプログラムの開発」を参照してください。

最適なハードウェア・コンフィギュレーションを目的とした SOPC Builderの使用system.h 内に最適でない定義を見つけた場合は、SOPC Builder で基本ハードウェアを変更することによって、system.h の内容を修正できます。デバイス・ドライバを記述して、不完全なハードウェアに対処する前に、SOPC Builderで簡単にハードウェアを改良できないか検討することが重要です。

コンポーネント、デバイス、およびペリフェラル

SOPC Builderで使用する「コンポーネント」という用語は、システムに含まれるハードウェア・モジュールを表します。Nios II ソフトウェア開発において、SOPC Builderコンポーネントとは、ペリフェラルやメモリなどのデバイスのことです。以降のセクションで、SOPC Builderに密接に関連する内容を説明する場合、「コンポーネント」は「デバイス」や「ペリフェラル」と置き換え可能な意味で使用します。

ハードウェアへのアクセス

ソフトウェアでは、デバイスへのメモリマップド・インタフェースを抽象化するマクロを介して、ハードウェアにアクセスします。このセクションでは、各デバイスのハードウェア・インタフェースを定義するマクロについて説明します。


ハードウェアへのアクセス

すべての SOPC Builder コンポーネントは、デバイス・ハードウェアとソフトウェアを定義するディレクトリを提供します。例えば、Nios II 開発キットに含まれる各コンポーネントには、<Nios II インストール・パス >/componentsディレクトリに配置された専用のディレクトリがあります。多くのコンポーネントは、ハードウェア・インタフェースを定義するヘッダ・ファイルを提供します。ヘッダ・ファイルは、< コンポーネント名 >_regs.hの名前で、特定のコンポーネント用の incサブディレクトリに格納されています。例えば、アルテラが提供する JTAG UARTコンポーネントの場合、そのハードウェア・インタフェースは、ファイル <Nios IIインストール・パス >/components/altera_avalon_jtag_uart/inc/altera_avalon_jtag_uart_regs.h内で定義されています。

_regs.hヘッダ・ファイルは、以下のアクセスを定義します。

■ 動作をサポートするデバイス内で、各レジスタに対する読み取りマクロや書き込みマクロを提供するレジスタ・アクセス・マクロ。これらのマクロは、IORD_<コンポーネントの名前 >_<レジスタの名前 >、および IOWR_<コンポーネントの名前 >_<レジスタの名前 >です（7–1ページの「キャッシュ・メモリ」を参照）。

■ レジスタ内の個々のビット・フィールドへのアクセスを可能にするビット・フィールド・マスクとオフセット。これらのマクロの名前は、以下のとおりです。

● フィールドのビット・マスクの場合、<コンポーネントの名前>_<レジスタの名前 >_<フィールドの名前 >_MSK

● フィールド先頭のビット・オフセットの場合、< コンポーネントの名前 >_<レジスタの名前 >_<フィールドの名前 >_OFST

● ステータス・レジスタの PE フィールドへのアクセスの場合、ALTERA_AVALON_UART_STATUS_PE_MSKおよびALTERA_AVALON_UART_STATUS_PE_OFST

デバイスのレジスタにアクセスするには、_regs.hファイルに定義されたマクロのみを使用してください。デバイスの読み取りまたは書き込みを行うときに、プロセッサがデータ・キャッシュを使用しないようにするために、レジスタ・アクセス関数を使用する必要があります。また、この処理では、ソフトウェアが基本ハードウェアの変更による影響を受けやすくなるため、ハード・コード化された定数は絶対に使用しないでください。

まったく新しいハードウェア・デバイス用のドライバを記述する場合、_regs.hヘッダ・ファイルを作成する必要があります。



キャッシュ管理およびデバイス・アクセスに関する影響の詳細は、7–1ページの「キャッシュ・メモリ」を参照してください。_regs.hファイルの詳細な例については、アルテラ提供の SOPC Builder コンポーネントのコンポーネント・ディレクトリを参照してください。

HALデバイス・クラス用ドライバの作成

HAL は、多数の汎用デバイス・モデル・クラスをサポートしています（3–1ページの「HALシステム・ライブラリの概要」を参照）。このセクションの説明に従ってデバイス・ドライバを作成して、既知のデバイス・クラスのいずれかに分類される特定のデバイスのインスタンスを HALに記述します。このセクションでは、HALがドライバ関数に均等にアクセスできるように、ドライバ関数のための統一されたインタフェースを定義します。

以下のセクションでは、以下のデバイスのクラスに対する APIを定義します。

■ キャラクタ・モード・デバイス■ ファイル・サブシステム■ DMAデバイス■ システム・クロックとして使用されるタイマ・デバイス■ タイムスタンプ・クロックとして使用されるタイマ・デバイス■ フラッシュ・メモリ・デバイス■ イーサネット・デバイス

以下のセクションでは、各デバイス・クラスに対してデバイス・ドライバを実装する方法と、それらのドライバを HAL ベース・システムで使用するための登録方法について説明します。

キャラクタ・モード・デバイス・ドライバ

このセクションでは、デバイス・インスタンスの作成方法とキャラクタ・デバイスの登録方法について説明します。

デバイス・インスタンスの作成

デバイスをキャラクタ・モード・デバイスとして使用できるようにするには、そのデバイスに alt_dev 構造体のインスタンスを提供する必要があります。alt_dev構造体は、以下のコードで定義されています。

typedef struct { alt_llist llist; /* 内部使用 */ const char* name; int (*open) (alt_fd* fd, const char* name, int flags, int mode); int (*close) (alt_fd* fd); int (*read) (alt_fd* fd, char* ptr, int len); int (*write) (alt_fd* fd, const char* ptr, int len);



int (*lseek) (alt_fd* fd, int ptr, int dir); int (*fstat) (alt_fd* fd, struct stat* buf); int (*ioctl) (alt_fd* fd, int req, void* arg);} alt_dev;

この構造体は、基本的には関数ポインタの集合です。これらの関数は、HALファイル・システムへのユーザ・アクセスに応答して呼び出されます。例えば、このデバイスに対応するファイル名を指定して関数 open()を呼び出すと、結果としてこの構造体に割り当てられた open()関数が呼び出されます。

open()、close()、read()、write()、lseek()、fstat()、および ioctl() の詳細については、10–1 ページの「HAL API リファレンス」を参照してください。

これらの関数はいずれも、グローバル・エラー・ステータスの errnoを直接変更することはありません。ステータスを変更する代わりに、errno.hで定義された該当するエラー・コードの負の値を返します。

例えば、ioctl() 関数は、要求を処理できない場合には、errno をENOTTYに直接設定するのではなく、戻り値として–ENOTTYを返します。errnoは、これらの関数を呼び出すHALシステム・ルーチンが適切に設定します。

これらの関数の関数プロトタイプは、int 型ではなく alt_fd* 型の入力ファイル・ディスクリプタ引数を取るという点が、アプリケーション・レベルのプロトタイプとは異なります。

新しい alt_fd 構造体は、open() を呼び出したときに作成されます。この構造体のインスタンスは、関連するファイル・ディスクリプタに対して実行されたすべての関数呼び出しに、入力引数として渡されます。

alt_fd構造体は、以下のコードで定義されています。

typedef struct { alt_dev* dev; void* priv; int fd_flags;} alt_fd;

ここで、

■ devは、使用中のデバイスのデバイス構造体へのポインタです。■ fd_flagsは、open()に渡される flagsの値です。■ privは、HALシステム・コードで使用されない不定値です。



■ privは、ドライバが内部使用に必要なファイル・ディスクリプタごとの情報を格納するために利用できます。

ドライバで、alt_dev構造体内のすべての関数を提供する必要はありません。関数ポインタが NULL に設定されている場合は、デフォルト動作が実行されます。表 5–1に、利用可能な関数それぞれのデフォルト動作を示します。

関数ポインタに加えて、alt_dev構造体にはさらに、llistと nameの2つのフィールドが含まれています。llistは内部で使用するためのもので、常に ALT_LLIST_ENTRY の値に設定する必要があります。nameは、HAL ファイル・システム内のデバイスの位置で、system.h で定義されたデバイスの名前です。

キャラクタ・デバイスの登録

alt_dev構造体のインスタンスを作成したら、これをHALに登録し、以下の関数を呼び出すことによって、システムでデバイスを利用できるようにする必要があります。

int alt_dev_reg (alt_dev* dev)

この関数は登録するデバイス構造体を唯一の入力引数として受け取ります。戻り値のゼロは正常に終了したことを示します。負の戻り値は、デバイスが登録できないことを示します。

表 5–1. alt_devで定義された関数のデフォルト動作

関数デフォルト動作

open デバイスが事前に TIOCEXCL ioctl() 要求によってロックされていない限り、このデバイスに対して open()を呼び出すと成功します。

close ファイル・ディスクリプタが有効な場合、このデバイスに対して close()を呼び出すと、必ず成功します。

read このデバイスに対して read()を呼び出すと、必ず失敗します。

write このデバイスに対して write()を呼び出すと、必ず失敗します。

lseek このデバイスに対して lseek()を呼び出すと、必ず失敗します。

fstat デバイスは、自身をキャラクタ・モード・デバイスとして識別します。

ioctl デバイスを参照しなければ処理できない ioctl()は失敗します。



デバイスがシステムに登録されると、HAL APIおよび ANSI C標準ライブラリを使用してデバイスにアクセスできます (4–1 ページの「HAL を使用したプログラムの開発」を参照 )。デバイスのノード名は、alt_dev構造体で指定されます。

ファイル・サブシステム・ドライバ

ファイル・サブシステム・デバイス・ドライバは、グローバル HALファイル・システム内の指定されたマウント・ポイントでのファイル・アクセスを処理します。

デバイス・インスタンスの作成

ファイル・システムの作成と登録は、キャラクタ・モード・デバイスの作成と登録とよく似ています。ファイル・システムを利用可能にするには、alt_dev構造体のインスタンスを作成します（5–5ページの「キャラクタ・モード・デバイス・ドライバ」を参照）。唯一の相違点は、デバイスの name フィールドがファイル・サブシステムのマウント・ポイントを表すことです。もちろん、キャラクタ・モード・デバイスの場合と同様に、read() や write() など、ファイル・サブシステムにアクセスするのに必要な関数も、ユーザが用意する必要があります。

fstat() を実装していない場合、デフォルトの動作によって、キャラクタ・モード・デバイスの値が返され、これはファイル・サブシステムに対して不正な動作となります。

ファイル・サブシステム・デバイスの登録

ファイル・サブシステムは、以下の関数を使用して登録できます。

int alt_fs_reg (alt_dev* dev)

この関数は登録するデバイス構造体を唯一の入力引数として受け取ります。負の戻り値は、ファイル・システムが登録できないことを示します。

ファイル・サブシステムが HAL ファイル・システムに登録されると、HAL APIおよび ANSI C標準ライブラリを使用して、このサブシステムにアクセスできます (4–1ページの「HALを使用したプログラムの開発」を参照 )。ファイル・サブシステムのマウント・ポイントは、alt_dev構造体で指定された nameです。



タイマ・デバイス・ドライバ

このセクションでは、システム・クロックとタイムスタンプ・ドライバについて説明します。

システム・クロック・ドライバ

システム・クロック・デバイス・モデルを使用するには、周期的な「チック」を生成するドライバが必要です（4–1ページの「HALを使用したプログラムの開発」を参照）。1つのシステムには 1つのシステム・クロック・ドライバしか存在できません。そのため、システム・クロック・ドライバは、周期的な割り込みを生成するタイマ・ペリフェラルに対する割り込みサービス・ルーチン（ISR）として実装します。このドライバは、以下の関数を周期的に呼び出す必要があります。

void alt_tick (void)

alt_tick()は割り込み処理中に呼び出されます。

システム・クロック・ドライバを登録するには、以下の関数を呼び出します。

int alt_sysclk_init (alt_u32 nticks)

入力引数 nticksは、1秒あたりのシステム・クロック・チック数です。この値はシステム・クロック・ドライバによって決まります。この関数の戻り値は、成功時にはゼロ、それ以外はゼロではない値です。

割り込みサービス・ルーチンの記述に関する詳細は、6–1 ページの「例外処理」を参照してください。

タイムスタンプ・ドライバ

タイムスタンプ・ドライバは、alt_timestamp_start()、alt_timestamp()、および alt_timestamp_freq()の 3つのタイムスタンプ関数の実装を提供します。システムには、1 つのタイムスタンプ・ドライバしか存在できません。

これらの関数の使用法に関する詳細は、4–1ページの「HALを使用したプログラムの開発」および 10–1ページの「HAL APIリファレンス」の章を参照してください。



フラッシュ・デバイス・ドライバ

このセクションでは、フラッシュ・ドライバの作成方法とフラッシュ・デバイスの登録方法について説明します。

フラッシュ・ドライバの作成

フラッシュ・デバイス・ドライバは、sys/alt_flash_dev.h で定義されたalt_flash_dev構造体のインスタンスを持つ必要があります。この構造体は以下のコードで表されます。

struct alt_flash_dev{ alt_llist llist; // 内部使用のみ const char* name; alt_flash_open open; alt_flash_close close; alt_flash_write write; alt_flash_read read; alt_flash_get_flash_info get_info; alt_flash_erase_block erase_block; alt_flash_write_block write_block; void* base_addr; int length; int number_of_regions; flash_region region_info[ALT_MAX_NUMBER_OF_FLASH_REGIONS]; };

最初のパラメータ llist は内部で使用するためのもので、常にALT_LLIST_ENTRY の値に設定する必要があります。name は、HALファイル・システム内のデバイスの位置で、system.hで定義されたデバイスの名前です。

open から write_block までの 8つのフィールドは、以下の関数へのユーザ API呼び出しの支援機能を実装する関数ポインタです。

■ alt_flash_open_dev()■ alt_flash_close_dev()■ alt_flash_write()■ alt_write_flash()■ alt_read_flash()■ alt_get_flash_info()■ alt_erase_flash_block()■ alt_write_flash_block()



ここで、

■ base_addrパラメータは、フラッシュ・メモリのベース・アドレスです。■ lengthは、フラッシュのバイト・サイズです。■ number_of_regionsは、フラッシュ内の消去領域の数です。■ region_infoには、フラッシュ・デバイス内のブロックの位置とサイズに関する情報が含まれています。

flash_region 構造体の形式に関する詳細は、4–14 ページの「フラッシュ・デバイスの使用」を参照してください。

共通フラッシュ・インタフェース（CFI）準拠のデバイスなど、フラッシュ・デバイスには、領域数とそれらのコンフィギュレーションを実行時に読み出せるものもあります。実行時に読み出せない場合、これらの2つのフィールドはコンパイル時に定義しなければなりません。

フラッシュ・デバイスの登録

alt_flash_dev構造体のインスタンスを作成したら、以下の関数を呼び出してデバイスを HAL システムで利用できるようにする必要があります。

int alt_flash_device_register( alt_flash_fd* fd)

この関数は、登録するデバイス構造体を唯一の入力引数として受け取ります。戻り値のゼロは正常に終了したことを示します。負の戻り値は、デバイスが登録できなかったことを示します。

DMAデバイス・ドライバHALは、DMA転送を受信チャネルと送信チャネルの 2つのエンドポイント・デバイスでの制御対象としてモデル化します。このセクションでは、DMA チャネルの各タイプに対するドライバについて個々に説明します。

HAL DMA デバイス・モデルの詳細な説明については、4–20 ページの「DMAデバイスの使用」を参照してください。

DMAデバイス・ドライバ・インタフェースは、sys/alt_dma_dev.hで定義されます。



DMA送信チャネル

DMA 送信チャネルは、以下の alt_dma_txchan 構造体のインスタンスを作成することによって構築されます。

typedef struct alt_dma_txchan_dev_s alt_dma_txchan_dev; struct alt_dma_txchan_dev_s { alt_llist llist; const char* name; int (*space) (alt_dma_txchan dma); int (*send) (alt_dma_txchan dma,

const void* from, alt_u32 len, alt_txchan_done* done, void* handle);

int (*ioctl) (alt_dma_txchan dma, int req, void* arg); };

表 5–2に、利用可能なフィールドとそれらの機能を示します。

space関数および send関数の両方を定義する必要があります。ioctlフィールドが null に設定されている場合、このデバイスに対してalt_dma_txchan_ioctl()を呼び出すと、–ENOTTYが返されます。

alt_dma_txchan 構造体のインスタンスを作成したら、以下の関数を呼び出して、デバイスを HAL システムに登録して利用可能にする必要があります。

int alt_dma_txchan_reg (alt_dma_txchan_dev* dev)

入力引数 devは、登録するデバイスです。戻り値は成功時にはゼロになり、デバイスが登録できない場合は負の値になります。

表 5–2. alt_dma_txchan構造体のフィールド

フィールド機能

llist このフィールドは内部で使用するためのもので、常に ALT_LLIST_ENTRYの値に設定する必要があります。

name alt_dma_txchan_open()の呼び出しでこのチャネルを示す名前。nameは、system.hで定義されるデバイスの名前です。

space デバイスのキューに格納できる追加送信要求数を返す関数へのポインタ。入力引数は、alt_dma_txchan_dev構造体へのポインタです。

send ユーザ API関数 alt_dma_txchan_send()を呼び出した結果として呼び出される関数へのポインタ。この関数は、DMA デバイスに送信要求を送信します。alt_txchan_send() に渡されるパラメータは、send()に直接渡されます。パラメータおよび戻り値の説明は、10–20ページの「alt_dma_txchan_send()」を参照してください。

ioctl この関数はデバイス固有のI/O制御を実行します。デバイスがサポートできる一般的なオプションのリストは、sys/alt_dma_dev.hを参照してください。



DMA受信チャネル

DMA 受信チャネルは、以下の alt_dma_rxchan 構造体のインスタンスを作成すれば構築されます。

typedef alt_dma_rxchan_dev_s alt_dma_rxchan;struct alt_dma_rxchan_dev_s { alt_llist list; const char* name; alt_u32 depth; int (*prepare) (alt_dma_rxchan dma, void* data, alt_u32 len, alt_rxchan_done* done, void* handle); int (*ioctl) (alt_dma_rxchan dma, int req, void* arg);};

表 5–3に、利用可能なフィールドとそれらの機能を示します。

prepare()関数を定義する必要があります。ioctl フィールドが null に設定されている場合、このデバイスに対して alt_dma_rxchan_ioctl()を呼び出すと、–ENOTTYが返されます。

表 5–3. alt_dma_rxchan構造体のフィールド

フィールド機能

llist この機能は内部で使用するためのもので、常に ALT_LLIST_ENTRYの値に設定する必要があります。

name alt_dma_rxchan_open()の呼び出しで、このチャネルを示す名前。nameは、system.hで定義されるデバイスの名前です。

depth どの時点でも未処理状態にすることができる受信要求の総数。

prepare ユーザ API関数 alt_dma_rxchan_prepare()を呼び出した結果として呼び出される関数へのポインタ。この関数は DMAデバイスに受信要求を送信します。alt_dma_rxchan_prepare()に渡されたパラメータは、prepare()に直接渡されます。パラメータおよび戻り値の説明は、10–14ページの「alt_dma_rxchan_prepare()」を参照してください。

ioctl この関数は、デバイス固有の I/O 制御を実行します。デバイスがサポートする一般的なオプションのリストは、sys/alt_dma_dev.hを参照してください。



alt_dma_rxchan 構造体のインスタンスを作成したら、以下の関数を呼び出してデバイスを HAL システムに登録して利用可能にする必要があります。

int alt_dma_rxchan_reg (alt_dma_rxchan_dev* dev)

入力引数 devは、登録するデバイスです。戻り値は成功時にはゼロになり、デバイスが登録できない場合は負の値になります。

イーサネット・デバイス・ドライバ

イーサネット・デバイス対応の HAL 汎用デバイス・モデルを利用すると、MicroC/OS-II オペレーティング・システム上で動作する軽量 IP（lwIP）TCP/IPスタックへのアクセスが可能になります。このセクションで定義するドライバ関数を供給することによって、新しいイーサネット・デバイスをサポートできます。

新しいイーサネット・デバイス用のデバイス・ドライバの作成を検討する前に、lwIPのアルテラ・ポートとその使用法の基本を理解しておく必要があります（9–1ページの「イーサネットと Lightweight IP」を参照）。

新しいイーサネット・デバイス・ドライバを作成する最も簡単な方法は、SMSC lan91c111デバイスに対するアルテラの実装から始めて、これをユーザのイーサネット・メディア・アクセス・コントローラ（MAC）に適合するよう修正することです。このセクションでは、ユーザがこの方法を利用するものと仮定しています。すなわち、lwIP スタック実装の詳細を学習するのではなく、動作確認済みの例を修正するだけでドライバを作成できます。したがって、このセクションでは、lwIP スタックのアルテラのポートを内部実装する上での最小限の内容について説明します。

lwIP実装の詳細については、www.sics.se/~adam/lwip/doc/lwip.pdfを参照してください。

lan91c111ドライバのソース・コードは、srcディレクトリおよび incディレクトリ内の<Nios IIインストール・パス>/components/altera_avalon_lan91c111/UCOSII/に、Nios II 開発キットとともに提供されています。イーサネット・デバイス・ドライバ・インタフェースは、<lwIPコンポーネント・パス >/UCOSII/inc/alt_lwip_dev.hで定義されています。



以下のセクションでは、新しいイーサネット・デバイス用のドライバを提供する方法について説明します。

alt_lwip_dev_listのインスタンスの提供

以下のコードは、各デバイス・ドライバで提供する必要があるalt_lwip_dev_list構造体のインスタンスを示します。

typedef struct { alt_llist llist; /* 内部使用 */ alt_lwip_dev dev;} alt_lwip_dev_list;

struct alt_lwip_dev{ /* netifポインタは構造体の最初の要素であることが必要 */ struct netif* netif; const char* name; err_t (*init_routine)(struct netif*); void (*rx_routine)();};

nameパラメータは、system.hで定義されるデバイスの名前です。

lwIPシステム・コードは netif構造体を内部で使用して、デバイス・ドライバへのインタフェースを定義します。netif 構造体は、<lwIP コンポーネントのパス >/UCOSII/src/downloads/lwip-0.7.2/src/include/lwipの netif.hで定義されています。特に、netif構造体には、以下の内容が含まれます。

■ インタフェースのMACアドレス用のフィールド■ インタフェースの IPアドレス用のフィールド■ MACデバイスを初期化する低レベル関数への関数ポインタ■ パケットを送信する低レベル関数へのポインタ■ パケットを受信する低レベル関数への関数ポインタ

init_routine()の提供

alt_lwip_dev 構造体の init_routine は、netif 構造体の設定とハードウェアの初期化を行う関数へのポインタです。この関数は、ターゲットのイーサネット・デバイス用に提供する必要があります。この関数のプロトタイプは以下のとおりです。

err_t init_routine(struct netif* netif)



init_routine()は、ルーチン get_mac_addr()およびget_ip_addr()を呼び出すことによって、MACアドレスおよび IPアドレスに対する netifフィールドに入力します。これらの関数は、9–1ページの「イーサネットと Lightweight IP」で定義されています。さらに、init_routine() では、必要な低レベル・レジスタ・アクセスを実行して、ハードウェアをコンフィギュレーションする必要があります。

output()と linkoutput()の提供

また、init_routine()関数では、output()および link_output()の2つの送信関数へのポインタに対するnetifフィールドにも入力する必要があります。

link_output()は、イーサネット・ハードウェア上でパケットを送信します。link_output()関数のプロトタイプは以下のとおりです。

link_output(struct netif *netif, struct pbuf *p)

link_output()は、イーサネット・インタフェース上で IPパケットを送信します。IPアドレスに関連付けられるMACアドレスに対して ARP要求が発行され、次に link_output()を呼び出してパケットを送信します。link_output()関数のプロトタイプは、以下のとおりです。

output(struct netif *netif, struct pbuf *p, struct ip_addr *ipaddr)

rx_routine()の提供

alt_lwip_dev 構造体の rx_routine は、TCP/IP スタックへの着信パケットを受信するために呼び出されるルーチンへの関数ポインタです。

新しいパケットが到着すると、割り込み要求（IRQ）が生成されます。関連付けられた割り込みサービス・ルーチン（ISR）がこの割り込みをクリアし、rx_mboxという名前のメッセージ・キューにメッセージを送信します。このメッセージ・ボックスは、ファイル <lwIPコンポーネントのパス >/UCOSII/src/alt_lwip_dev.cで定義されています。

rx_threadは、rx_mbox内で新しいメッセージを検出すると、rx_routine()を呼び出します。rx_routine()によって、ハードウェアからパケットが受信され、TCP/IPスタックに渡されます。



この関数のプロトタイプは以下のとおりです。

void rx_func()

HALへのデバイス・ドライバの統合

このセクションでは、HALの機能を活用して、システム初期化中にデバイス・ドライバを自動的にインスタンス化および登録する方法について説明します。いずれかのHAL汎用デバイス・モデルに対してデバイス・ドライバを作成した場合でも、ペリフェラル専用のデバイス・ドライバを作成した場合でも、このサービスを活用できます。HALが提供する自動化機能の主な利点は、HALディレクトリ構造の適切な場所にファイルを配置するプロセスです。

HALデバイスのディレクトリ構造各ペリフェラルは、特定の SOPC Builder コンポーネント・ディレクトリに提供されたファイルで定義されています（5–3ページの「ハードウェアへのアクセス」を参照）。このセクションでは、アルテラの JTAG UARTコンポーネントの例を使用して、ファイルの位置を示します。図 5-1に、JTAG UART コンポーネント・ディレクトリのディレクトリ構造を示します。このディレクトリは、<Nios IIインストール・パス >/componentsディレクトリ内に配置されています。

図 5-1. HALペリフェラルのディレクトリ構造

HAL用デバイス・ドライバ・ファイルこのセクションでは、必要なファイルを提供して、デバイス・ドライバをHALに統合する方法について説明します。

altera_avalon_jtag_uart

HALHAL

HAL

inc

src

inc



デバイスの HALヘッダ・ファイルと alt_sys_init.c

HALの中心となるのは、自動生成されたソース・ファイルのalt_sys_init.cです。alt_sys_init.c には、システム内のすべてのサポート対象デバイスのデバイス・ドライバを初期化するために、HAL が使用するソース・コードが含まれています。特に、このファイルでは alt_sys_init()関数が定義されています。この関数は、main()の前に呼び出されて、すべてのデバイスを初期化し、プログラムからそれらのデバイスを利用できるようにします。

以下のコードは、alt_sys_init.cファイルから一部分を抜粋したものです。

例：ドライバの初期化を実行する alt_sys_init.cファイルの一部分

#include "system.h"#include "sys/alt_sys_init.h"

/* * デバイス・ヘッダ */#include "altera_avalon_timer.h"#include "altera_avalon_uart.h"

/* * デバイス・ストレージの割り当て */ALTERA_AVALON_UART_INSTANCE( UART1, uart1 );ALTERA_AVALON_TIMER_INSTANCE( SYSCLK, sysclk );

/* * デバイスの初期化 */void alt_sys_init( void ){ ALTERA_AVALON_UART_INIT( UART1, uart1 ); ALTERA_AVALON_TIMER_INIT( SYSCLK, sysclk );}

新しいソフトウェア・プロジェクトを作成すると、Nios II 統合開発環境（IDE）は、SOPC Builder システムの固有のハードウェア内容に適合するように、alt_sys_init.cの内容を自動的に生成します。Nios II IDEは、ジェネレータ・ユーティリティ gtf-generate を呼び出して、alt_sys_init.cを作成します。

gtf-generate は、明示的に呼び出す必要はありません。HALの低レベル動作での gtf-generate について述べているため、ここでは参考として説明しています。



プロセッサから認識可能な各デバイスに対して、ジェネレータ・ユーティリティは、デバイスのHAL/incディレクトリ内で関連するヘッダ・ファイルを検索します。ヘッダ・ファイルの名前は、SOPC Builderコンポーネント名によって異なります。例えば、アルテラの JATG UARTコンポーネントの場合、ジェネレータはファイル altera_avalon_jtag_uart/HAL/inc/altera_avalon_jtag_uart.hを検出します。ジェネレータ・ユーティリティは、該当するヘッダ・ファイルを検出すると、alt_sys_init.cにコードを挿入して、以下の動作を実行します。

■ デバイスのヘッダ・ファイルをインクルードします。5–18ページの「例：ドライバの初期化を実行する alt_sys_init.cファイルの一部分」の /* デバイス・ヘッダ */を参照してください。

■ マクロ <デバイスの名前 >_INSTANCEを呼び出して、デバイスにストレージを割り当てます。5–18 ページの「例：ドライバの初期化を実行する alt_sys_init.cファイルの一部分」の /* デバイス・ストレージの割り当て */のセクションを参照してください。

■ alt_sys_init()関数内でマクロ<デバイスの名前>_INITを呼び出して、デバイスを初期化します。5–18ページの「例：ドライバの初期化を実行する alt_sys_init.cファイルの一部分」の /* デバイスの初期化 */のセクションを参照してください。

これらの *_INSTANCE マクロおよび *_INIT マクロは、関連付けられたデバイス・ヘッダ・ファイルで定義する必要があります。例えば、altera_avalon_jtag_uart.hでは、マクロALTERA_AVALON_JTAG_UART_INSTANCEとALTERA_AVALON_JGAT_UART_INITを定義する必要があります。*_INSTANCEマクロは、ドライバが必要とする静的メモリ割り当てをデバイスごとに実行します。*_INIT マクロは、デバイスのランタイム初期化を実行します。どちらのマクロも 2 つの入力引数を受け取ります。最初の引数は大文字で表したデバイス・インスタンスの名前、2 番目の引数は小文字で表したデバイス名です。これは、システム生成時に SOPCBuilderのコンポーネントに与えられた名前です。これらの入力パラメータを使用して、system.hファイルからデバイス固有のコンフィギュレーション情報を抽出できます。

詳細な例は、アルテラ提供のデバイス・ドライバを参照してください。

プロジェクトの再構築時間を短縮するには、ペリフェラル・ヘッダ・ファイルに system.h を直接指定しないようにします（alt_sys_init.cで既に指定されています）。



SOPC Builderコンポーネント用のデバイス・ドライバを公開するには、コンポーネントのディレクトリ内にファイルHAL/inc/<component_name>.hを提供します。このファイルは、上記のようにマクロ <COMPONENT_NAME>_INSTANCEおよび<COMPONENT_NAME>_INIT を定義するために必要です。このようにデバイスに対応したインフラストラクチャを準備すれば、HALシステム・ライブラリは、main() を呼び出す前に、デバイス・ドライバを自動的にインスタンス化して登録します。

デバイス・ドライバのソース・コード

一般に、デバイス・ドライバは、ヘッダでは完全に定義できません（5–18ページの「デバイスのHALヘッダ・ファイルと alt_sys_init.c」を参照）。ほとんどの場合、コンポーネントは、システム・ライブラリに組み込まれるその他のソース・コードも提供する必要があります。

必要なソース・コードは、HAL/srcディレクトリに配置しなければなりません。さらに、makefileの一部分の component.mkを取り込む必要があります。component.mkファイルは、システム・ライブラリに含まれるソース・ファイルをリストします。ファイル名をスペースで区切ると、複数のファイルをリストできます。以下のコードは、アルテラの JTAGUARTデバイスに対するmakefileの例を示します。

例：component.mk makefileの例

C_LIB_SRCS += altera_avalon_uart.c ASM_LIB_SRCS +=INCLUDE_PATH +=



Nios II IDEは、システム・ライブラリ・プロジェクトおよびアプリケーション・プロジェクトをコンパイルするときに、component.mkファイルをトップ・レベルのmakefileに自動的に取り込みます。component.mkは、利用できる make 変数を変更できますが、これは C_LIB_SRCS、ASM_LIB_SRCSおよび INCLUDE_PATHに限定されます。表 5–4にこれらの変数を示します。

component.mkによって、その他のmake規則とマクロを必要に応じて追加できますが、マクロ名は相互運用性を確保するために、ネーム空間規則に準拠する必要があります（5–22ページの「ネーム空間の割り当て」を参照）。

要約

要約すると、HALフレームワークにデバイス・ドライバを統合するには、以下の処理を実行することが必要です。

■ *_INSTANCE マクロおよび *_INIT マクロを定義するインクルード・ファイルを作成し、デバイスのHAL/incディレクトリに配置します。

■ デバイスを操作するソース・コード・ファイルを作成し、そのファイルをデバイスの HAL/srcディレクトリに配置します。

■ makefileの一部分、component.mkを記述し、HAL/srcディレクトリに配置します。

表 5–4. component.mkで定義されるmake変数

make変数意味

C_LIB_SRCS システム・ライブラリに組み込まれる Cソース・ファイルのリスト。

ASM_LIB_SRCS システム・ライブラリに組み込まれるアセンブラ・ソース・ファイルのリスト（これらはCプリプロセッサで前処理されます）。

INCLUDE_PATH インクルード検索パスに追加するディレクトリのリスト。ディレクトリ<component>/HAL/inc は自動的に追加されるため、コンポーネントで明示的に定義する必要はありません。


ドライバ・フットプリントの削減

ドライバ・フットプリントの削減

HAL では、ALT_USE_SMALL_DRIVERS という名前の C プリプロセッサ・マクロが定義されています。このマクロをドライバ・ソース・コード内で使用すると、最小のコード・フットプリントを必要とするシステムに対応した、代替動作が実現できます。Nios II IDEのオプションを利用すれば、機能が限定されたデバイス・ドライバを有効にすることができます。ALT_USE_SMALL_DRIVERS が定義されていない場合、ドライバ・ソース・コードはドライバのフル機能バージョンを実装します。マクロが定義されている場合、ソース・コードは機能を限定したドライバを提供します。例えば、あるドライバはデフォルトでは割り込み駆動式の動作を実装できますが、ALT_USE_SMALL_DRIVERS が定義されていれば、ポーリング式（より軽量と予想される）動作を実装できます。

デバイス・ドライバを作成する際に、ALT_USE_SMALL_DRIVERS の値を無視するように選択すれば、マクロの定義にかかわらず、同じバージョンのドライバが使用されます。

ネーム空間の割り当て

SOPC Builder システムでデバイスによって定義されるシンボルの名前が重複するのを回避するために、すべてのグローバル・シンボルに定義済みプリフィックスを付加する必要があります。グローバル・シンボルには、グローバル変数と関数名があります。デバイス・ドライバの場合、プリフィックスは SOPC Builder コンポーネントの名前の後に下線を付加したものです。このネーミングでは文字列が長くなるため、これに代わる短縮形式も利用できます。この短縮形式ではベンダ名が基本となり、例えばalt_は、アルテラが供給するコンポーネントに対するプリフィックスです。すべてのコンポーネントの相互運用性は、コンポーネントを供給するベンダがテストすることが求められます。

例えば、altera_avalon_jtag_uartコンポーネントの場合、以下の関数名は有効です。

■ altera_avalon_jtag_uart_init()■ alt_jtag_uart_init()

以下の名前は無効です。

■ avalon_jtag_uart_init()■ jtag_uart_init()

ソース・ファイルは検索パスを使用して検索されるため、これらのネーム空間制限事項はデバイス・ドライバのソース・ファイルとヘッダ・ファイルにも適用されます。



デフォルト・デバイス・ドライバの置き換え

すべての SOPC Builderコンポーネントは、HALデバイス・ドライバを提供することを選択できます（5–17 ページの「HAL へのデバイス・ドライバの統合」を参照）。ただし、コンポーネントに用意されたドライバがアプリケーションに適さない場合は、Nios II IDEのシステム・ライブラリ・プロジェクト・ディレクトリに別のドライバを供給して、デフォルトのドライバを置き換えることができます。

Nios II IDEは検索パスを使用して、すべてのインクルード・ファイルとソース・ファイルを検索します。この場合、システム・ライブラリ・プロジェクト・ディレクトリが常に最初に検索されます。例えば、コンポーネントがヘッダ・ファイル alt_my_component.h を提供し、システム・ライブラリ・プロジェクト・ディレクトリにもファイルalt_my_component.h が含まれている場合、コンパイル時にシステム・ライブラリ・プロジェクト・ディレクトリに提供されるバージョンが使用されます。これと同じメカニズムによって、Cソース・ファイルとアセンブラ・ソース・ファイルを置き換えることが可能です。


デフォルト・デバイス・ドライバの置き換え

Altera Corporation セクション III–1

セクション III. 高度なプログラミング手法

このセクションでは、高度なプログラミング手法について説明します。


■ 第 6章　例外処理

■ 第 7章　キャッシュ・メモリ

■ 第 8章　MicroC/OS-IIリアルタイム・オペレーティング・システム

■ 第 9章　イーサネットと Lightweight IP

改定履歴以下の表に、各章の改定履歴を示します。これらのバージョンは資料の改定を追跡しているのもので、Nios II開発キットや Nios IIプロセッサのバージョンには関係ありません。


6 2004年 12月 v1.2

HALへのボタン PIO ISRの登録例を修正

2004年 9月v1.1

● 例を変更● ISRの性能データを追加

2004年 5月v1.0

初版

7 2004年 5月v1.0

初版

8 2004年 12月v1.1

スレッド対応デバッグのパラグラフを追加

2004年 5月v1.0

初版

9 2004年 12月v1.2

lwIPのバージョンの参照を 0.6.3から 0.7.2に更新

2004年 9月v1.1

lwIP実装の変更について記載（タイマのタスクを削除）

2004年 5月v1.0

初版

myoshida

Text Box


セクション III–2 Altera Corporation

高度なプログラミング手法 Nios II ソフトウェア開発ハンドブック


6. 例外処理

はじめにこの章では、Nios® II プロセッサ・アーキテクチャで例外を処理するプログラムの記述方法について説明します。ユーザ定義の割り込みサービス・ルーチン（ISR）を HAL（Hardware Abstraction Layer）に登録することによって、ハードウェア割り込み要求を処理する方法を重点的に説明します。

この章では、以下のトピックを扱います。

■ Nios II例外の概要 ■ HAL実装■ ISR

● ISR用のHAL API（Application Programming Interface）● ISRの記述● ISRのイネーブルおよびディセーブル● Cの例

■ 高速 ISR処理■ ISR使用のデバッグ■ ISRの記述に関する提案の要約

Nios IIアーキテクチャでの例外および割り込み処理の低レベル仕様の詳細については、「Nios II プロセッサ・リファレンス・ハンドブック」のプログラミング・モデルの章を参照してください。

Nios II例外の概要

Nios II例外処理は、従来からの RISC形式、すなわちすべての例外タイプが 1つの例外ハンドラで処理される形式で実装されます。したがって、すべての例外（ハードウェアおよびソフトウェア）は、「例外アドレス」と呼ばれる 1つの位置に存在するコードによって処理されます。

Nios IIプロセッサでは、以下の例外タイプが利用できます。

■ ハードウェア割り込み例外。■ ソフトウェア例外。この例外は以下のカテゴリに分類されます。

● 未実装命令● ソフトウェア・トラップ● その他の例外

NII52006-1.2

myoshida

Text Box



HAL実装

例外が生成されると、プロセッサは以下のステップを自動的に実行します。

■ statusレジスタ（ctl0）の内容を estatusレジスタ（ctl1）にコピーして、例外発生前のプロセッサの状態を保存します。

■ status レジスタの PIE ビットをクリアして、以降のハードウェア割り込みをディセーブルします。

■ 例外発生後の命令のアドレスを ea レジスタ（r29）に格納して、例外ハンドラが戻るリターン・アドレスを提供します。

■ 例外アドレスへのベクタ・ジャンプ

HAL実装このセクションでは、HALシステム・ライブラリが使用する例外ハンドラ実装について説明します。これは参考のためであり、HAL ISRサービスを利用するのに、完全に理解する必要はありません。

HAL API（Application Programming Interface）を使用して ISRをインストールする方法の詳細については、6–6ページの「ISR」を参照してください。

HALシステム・ライブラリを持つ例外ハンドラは、例外アドレスに配置されます。このハンドラは、以下のアルゴリズムを実行して、ハードウェア割り込みとソフトウェア例外を区別します。

■ estatus レジスタの EPIEビットがイネーブルされているかどうか判断する。

● イネーブルされていない場合、例外はソフトウェア例外となります。

● イネーブルされている場合は、以下のステップに進みます。■ ipendingがゼロ以外かどうかを判断します。

● ipendingのいずれかのビットがゼロ以外の場合、例外はハードウェア割り込みであり、ハードウェア割り込みを処理します。

● すべてのビットがゼロの場合、例外はソフトウェア例外です。

このアルゴリズムは以下の 3つのルーチンを使用します。

■ _irq_entry()■ alt_irq_handler()■ software_exception()


例外処理

_irq_entry

Nios IIシステムにハードウェア割り込みが存在する場合、トップ・レベルのアセンブリ・ルーチン _irq_entry が例外アドレスに配置されます。このアセンブリ・ルーチンは、発生した例外のタイプを確認し、適切なルーチンを呼び出します。例外がソフトウェア例外の場合は、ルーチン software_exceptionを呼び出し、ハードウェア割り込みの場合は、ルーチン alt_irq_handlerを呼び出します。

ルーチンのアセンブリ・コードを確認するには、<Nios IIインストール・パス >/components/altera_nios2/HAL/inc/sys/alt_irq_entry.h ファイルを参照してください。あるいは、ハードウェア割り込みを使用するプロジェクトをビルドした後に、objdumpでリンクされたアセンブリ・ルーチンを調べることもできます。

以下のコードは、_irq_entryルーチンの擬似コード例です。

例：_irq_entryの擬似コード例

_irq_entry:if EPIE = 0

// ソフトウェア例外goto software_exception handler assembly.

else if ipending = 0// ソフトウェア例外goto software_exception handler assembly.

else// ハードウェア割り込みstore pre-exception processor state// alt_irq_handlerを呼び出して適切な ISRをディスパッチする。call the alt_irq_handler routinerestore the pre-exception processor state// 例外からの復帰issue the exception return instruction, eret. .

alt_irq_handler()

関数 alt_irq_handler() は、割り込みの原因（つまり、割り込みを発生させたデバイスに関連付けられた割り込み番号）を特定し、HALに登録されたその割り込みに対する関数を実行します。ループが記述された順序によって、最も高い割り込み要求（IRQ）の優先順位は IRQ0に、最も低い順位は IRQ31に与えられます。


HAL実装

以下のコードは、alt_irq_handler()の擬似コード例です。

例：alt_irq_handler()の擬似コード例

alt_irq_handler(void)// 0から 31までのすべての IRQに対するループ// ipendingが最初に「1」となったときに// ユーザ定義の関数を実行します。for i from 0 to 31:

// ipendingのどのビットが「1」であるかチェック。if ipending[i] == ‘1’:

// ユーザ定義の関数を実行します。// 注：alt_irq_arg[i]と iはそれぞれ、 // ユーザの関数プロトタイプにおける// void*型の contextおよび idに対応します。// alt_irq[]は、ISRへの関数ポインタの配列です。alt_irq[i]( alt_irq_arg[i], i )// 最初のアクティブな割り込みを検出すれば、// チェックを停止します。break;

ソース・コードは、<Nios IIインストール・パス >/components/altera_hal/HAL/src/alt_irq_register.cファイルにあります。

software_exception

software_exceptionルーチンは、ソフトウェア例外の原因を特定します。現在、software_exceptionルーチンは基本的に、どの未実装命令が例外を発生したかを特定し、適切な命令エミュレーション・ルーチンを呼び出します。

Nios IIシステムに、ハードウェア割り込みを使用するペリフェラルが含まれていない場合、software_exceptionルーチンは例外アドレスに直接配置されます。また、_irq_entry および alt_irq_handler はプロジェクトにリンクされません。

ソフトウェア例外の原因を特定するには、命令ワード内の OP フィールドと OPXフィールドを調べる必要があります。

OPフィールドおよびOPXフィールドの詳細については、「Nios IIプロセッサ・リファレンス・ハンドブック」の命令セットのリファレンスを参照してください。


例外処理

以下のコードは、software_exceptionアセンブリ・ルーチンの擬似コード例を示します。

例：software_exceptionの擬似コード例

software_excetion:if encoding = trap instruction // ソフトウェア・トラップ // 現在は未実装（nop命令のように動作）。 goto trap_handler else // 命令エミュレーション case op / opx muli:goto mul_immed // 即値乗算 mul:goto multiply // 乗算。 mulxss:goto mulxss // 符号付き－符号付き乗算 mulxsu:goto mulxsu // 符号付き－符号なし乗算 mulxuu:goto mulxuu // 符号なし－符号なし乗算 div:goto divide // 符号付き除算 divu:goto unsigned_division // 符号なし除算例外からの復帰

すべてのソース・アセンブリ・コードは、<Nios IIインストール・パス >/components/altera_nios2/HAL/src/alt_exceptions.S ファイルにあります。

上記の擬似コードは、alt_exceptions.S とは厳密には一致しません。厳密な実装の詳細については、アセンブリ・ソース・コードを参照してください。

未実装命令

software_exceptionは、未実装命令と考えられる各命令に対するエミュレーション・ルーチンを定義します。このようにして、特定の NiosII コアがハードウェアですべての命令を処理しない場合でも、すべてのNios II命令セットが常にサポートされます。一方で、Nios IIコアがハードウェアに特定の命令を実装する場合は、対応する例外は発生しません。エミュレーション・ルーチンは十分小さいため、エミュレーション・ルーチンを必要としない Nios II コアをターゲットとする場合でも、取り除くメリットはほとんどありません。

未実装命令の詳細については、「Nios II プロセッサ・リファレンス・ハンドブック」のプロセッサ・アーキテクチャの章を参照してください。


ISR

エミュレーション・ルーチンは例外の状況で実行されるため、例外ルーチンは絶対に未実装命令を発行できません。「未実装命令」は「無効な命令」を意味するものではありません。現行のNios IIコア実装では、OPフィールドおよび OPXフィールドに有効な命令エンコーディングが含まれていない場合、結果は未定義です。したがって、software_exceptionルーチンは、無効な命令を検出したり、それに応答することはできません。未定義の OP エンコーディングおよびOPXエンコーディングに対するプロセッサの動作は、Nios IIコアによって異なります。

詳細については、「Nios II プロセッサ・リファレンス・ハンドブック」のNios IIコア実装の詳細の章を参照してください。

ソフトウェア・トラップの例外処理

software_exceptionは、現行ではソフトウェア・トラップの例外に対して null処理を実行します。alt_exceptions.Sのコードでは、ソフトウェア・トラップに対するOPエンコーディングおよびOPXエンコーディングは検出しませんが、空の trap_handlerルーチンに分岐します。

その他の例外

将来の Nios II プロセッサ・コア実装では、新しい例外タイプが定義される予定です。それによって、例外の正確な原因を特定することなく、software_exceptionが実行できるようになります。HAL実装は現在定義されていない例外タイプには対応しません。

ISR 多くの場合、ペリフェラルとの通信は、割り込みを使用して達成されます。ペリフェラルが IRQをアサートすると、プロセッサの通常の実行フローに例外が発生します。このような割り込みが発生すると、適切な ISRによってこの割り込みを処理し、処理が完了したらプロセッサを割り込み発生前の状態に戻すことが必要です。このセクションでは、割り込み処理用に HAL システム・ライブラリが提供するフレームワークについて説明します。


例外処理

ISR用 HAL APIHALシステム・ライブラリは、ISRの作成とメンテナンスを容易にするために API を提供しています。また、MicroC/OS-II プログラムではすべてのHAL APIを利用できるため、このAPIもMicroC/OS-IIベースのプログラムで使用できます。HAL APIは割り込みを管理するための以下の関数を定義しています。

■ alt_irq_register()■ alt_irq_disable_all()■ alt_irq_enable_all()■ alt_irq_interruptible()■ alt_irq_non_interruptible()■ alt_irq_enabled()

ISR の実装に HAL API を使用するには、2 つのステップを実行します。まず、特定のデバイスに対する割り込みを処理する割り込みサービス・ルーチンを記述します。次に、プログラムで alt_irq_register()関数を使用して ISR を HAL に登録する必要があります。このプログラムでは、alt_irq_enable_all()関数と alt_irq_disable_all()関数を使用して、実行中に割り込みをイネーブルまたはディセーブルできます。

割り込みをディセーブルすると割り込みレイテンシが影響を受け、このためシステム・パフォーマンスも影響を受けます。

alt_irq_register()を使用した ISRの登録HALはこの関数ポインタをルックアップ・テーブルに登録します。特定の IRQが発生すると、HALはルックアップ・テーブル内で IRQを探し、登録済みの ISRをディスパッチします。

alt_irq_register()のプロトタイプは以下のとおりです。

int alt_irq_register (alt_u32 id, void* context, void (*isr)(void*, alt_u32));

プロトタイプには以下のパラメータがあります。


ISR

■ id は、system.h で定義されたデバイスのハードウェア割り込み番号です。割り込みの優先順位は IRQ番号と逆の関係にあります。したがって、IRQ 0は優先順位が最高の割り込み、IRQ 31は最低の割り込みを表します。

■ contextは、コンテキスト固有の情報を ISRに渡すために使用されるポインタです。このポインタは、どの種類の ISR 固有情報でも指すことができます。context の値は HAL からは読み取れません。この値は、ユーザ定義 ISRでの利用のみを目的として提供されます。

■ isrは IRQ番号 IDに応答して呼び出される関数です。この関数には、2つの入力引数として、contextポインタと idが提供されます。isrに nullポインタを登録すると、割り込みがディセーブルされます。

ISR が正常に登録されると、関連付けられた割り込み（id で定義）は、alt_irq_register()からの復帰時にイネーブルされます。

alt_irq_register()の詳細については、10–1ページの「HAL APIリファレンス」を参照してください。

ISRの記述記述する ISRは、alt_irq_register()が認識するプロトタイプに一致する必要があります。ユーザの ISR関数のプロトタイプは、以下のプロトタイプと一致しなければなりません。

void isr (void* context, alt_u32 id)

contextおよびidのパラメータ定義は、alt_irq_register()関数のパラメータ定義と同じです。

ISR の機能は、関連付けられた割り込み条件をクリアまたはマスク・アウトして、割り込みハンドラに戻ることです。

制限された環境

ISRは制限された環境で動作します。HAL API呼び出しの大部分は ISRからは利用できません。例えば、HALファイル・システムへのアクセスは許可されません。一般的な規則として、独自の ISR を記述する場合、割り込みの待機を妨害する可能性がある関数呼び出しは、絶対に使用しないでください。


例外処理

さらに、ISR の内部で ANSI C 標準ライブラリ関数を呼び出すときにも注意が必要です。C標準ライブラリ I/O APIを呼び出すと、システム内でデッドロックが発生する（つまり、システムが ISR 内部で永久にブロックされる）可能性があるため、これらの API関数を使用した呼び出しは避ける必要があります。特に、不用意に ISR内部から printf()を呼び出すことは避けてください。stdout が、適切に動作するために割り込みを使用するデバイス・ドライバにマップされている場合、printf()呼び出しは、割り込みがディセーブルされるため、システムは発生することのない割り込みを待ち続けデッドロックに陥る可能性があります。ISR内部から printf()を安全に使用できるのは、デバイス・ドライバが割り込みを使用しない場合に限られます。

ISRの性能

性能を向上させるために、ISR は通常、割り込みをディセーブルして実行されます。これによって、ISR はリエントリ操作が可能である必要がなくなるため、割り込み処理に関連するシステム・オーバヘッドが低減され、ISR の開発が容易になります。ただし、ISR が処理に時間を要する場合、システムの応答性に悪影響を与える可能性があります。特に、システムの他の ISRのリアルタイム動作（割り込みレイテンシ）に影響を与えます。このため、ISRは可能な限り効率的にすることが必要です。ISR は、割り込み条件をクリアして復帰するのに必要な最小限の作業を実行しなければなりません。

低速割り込みハンドラ

割り込みハンドラが実行に時間を要する場合、システムの性能と機能に悪影響を与えることがあります。割り込みハンドラを再編成して実行時間を短縮できない場合は、より優先順位の高い割り込みを低速割り込みハンドラに割り込ませることができます。これは、ネスト式割り込みハンドラとして知られています。

ネスト式割り込みハンドラを使用すると、優先順位が低い（割り込みを再イネーブルする割り込みハンドラよりも優先順位の低い）割り込みの割り込みレイテンシが増加するため、この方式を採用するときは検討が必要です。

ISR経由で最も遅いパスが約70命令未満のときにネスト式割り込みを許可すると、優先順位の高い割り込みの割り込みレイテンシが増加します。このような割り込みハンドラでは、割り込みを再イネーブルしないでください。


ISR

ネスト式割り込みが望ましい場合、alt_irq_interruptible()関数と alt_irq_non_interruptible() 関数を使用して、より優先順位の高い割り込みから割り込みを受ける可能性のある低速 ISR内に、コードをまとめる必要があります。これらの関数を使用すると、優先順位の高い ISRの割り込みレイテンシを改善することができます。これらの関数はペアで使用する必要があります。一方の関数しか使用しないと、システムがロックする可能性があります。

低速動作の抑制

一般に、ISR はハードウェアの状態の変化に対して、レイテンシの低い迅速な応答を行います。バルク・データ転送など、低レイテンシ機能を必要としない低速動作の実行は避けるべきです。低速動作は延期して、割り込み処理外で実行する必要があります。

MicroC/OS-IIスケジューラなどのリアルタイム・オペレーティング・システム（RTOS）をベースにしたシステムでは、タスクの延期は簡単です。この場合、低速処理を扱うスレッドが作成でき、ISR はイベント・フラグやメッセージ・キューなど、MicroC/OS IIの通信メカニズムを使用して、このスレッドと通信できます。

シングル・スレッドの HAL ベース・システムでも同じ方法が使用できますが、処理がやや煩雑になります。低速コードは、メイン・プログラムから定期的に呼び出す必要があります。このプログラムは ISRで管理されるグローバル変数をポーリングして、低速処理ルーチンを呼び出す必要があるかどうかを判断します。

ISRのイネーブルおよびディセーブルHAL は関数 alt_irq_disable_all()、alt_irq_enable_all()、alt_irq_enable()を提供しており、これによりプログラムはコードの特定のセクションに対する割り込みをディセーブルし、後で再イネーブルすることができます。alt_irq_disable_all()はすべての割り込みをディセーブルし、context の値を返します。割り込みを再イネーブルするには、alt_irq_enable_all()を呼び出して、contextパラメータに値を渡します。このようにして、割り込みは、alt_irq_disable_all()が呼び出される前の状態に戻されます。alt_irq_enabled()は、割り込みがイネーブルされている場合はゼロ以外の値を返すために、プログラムでこの関数を使用すれば割り込みの状態を確認できます。

最大割り込みレイテンシは、割り込みがディセーブルされている時間によって増加するため、割り込みのディセーブルは可能な限り短時間にする必要があります。


例外処理

Cの例以下の C コードの例は、ISR に対して HAL APIを使用する場合に必要なプロセスを理解するのに役立ちます。

以下の例は、4 ビット PIO ペリフェラルをプッシュボタンに接続したNios IIシステムをベースにしています。この場合、IRQはボタンが押されたときに生成されます。ISR コードは、PIO ペリフェラルのエッジ・キャプチャ・レジスタを読み取り、その値をグローバル変数に格納します。グローバル変数のアドレスは、contextポインタを介して ISRに渡されます。

以下のコードは、ボタン PIOからの割り込みを処理する ISRの例を示します。

例：ボタン PIO IRQを処理する ISR

#include "system.h"#include "altera_avalon_pio_regs.h"#include "alt_types.h"

static void handle_button_interrupts(void* context, alt_u32 id){/* contextポインタを整数ポインタにキャストします。 */volatile int* edge_capture_ptr = (volatile int*) context;/** ボタン PIOのエッジ・キャプチャ・レジスタを読み取ります。 * 値を保存します。*/*edge_capture_ptr =IORD_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_PIO_BASE);/* エッジ・キャプチャ・レジスタに書き込み、リセットします。 */IOWR_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_PIO_BASE, 0);/* ボタン PIOの割り込み機能をリセットします。*/IOWR_ALTERA_AVALON_PIO_IRQ_MASK(BUTTON_PIO_BASE, 0xf);

}

以下のコードは、ISRを HALに登録するメイン・プログラムのコード例を示します。

例：HALへのボタン PIO ISRの登録

#include "sys/alt_irq.h"#include "system.h"

.../* エッジ・キャプチャの値を保持するグローバル変数を宣言します。 */volatile int edge_capture;.../* 割り込みハンドラを登録します。 */alt_irq_register(BUTTON_PIO_IRQ,

(void*) &edge_capture, handle_button_interrupts);


高速 ISR処理

このコードに基づいて、以下の実行フローが可能になります。

1. ボタンが押され、IRQが生成されます。

2. HAL例外ハンドラが起動され、handle_button_interrupts() ISRをディスパッチします。

3. handle_button_interrupts()が割り込みを処理して戻ります。

4. edge_captureの値を更新して、通常のプログラム動作を継続します。

その他にも、プロジェクト・テンプレート例の count_binary など、ISRの実装方法を示すソフトウェアの例がNios II開発キットとともにインストールされています。

高速 ISR処理 ISRの性能を最大限に高めるには、以下のガイドラインに従ってください。

■ 例外コードを最速で実行するには、例外アドレスを高速メモリ・デバイスにマップします。例えば、低速 SDRAM よりも、待ち状態がゼロのオンチップ RAMの方が適しています。例外アドレスはシステム生成時に決定されるため、この設定はソフトウェアでは選択できません。ただし、例外アドレスは、容易に変更可能な Nios II CPUハードウェアのプロパティです。

■ また、ISR関数も高速メモリ・セクションにマップする必要があります（4–34ページの「メモリの使用」を参照）。

■ 通常、ISR内部での長時間に及ぶ計算の実行は避けてください。

HAL ISRサービスは、ISRを登録するための使いやすい汎用フレームワークを提供しており、ほとんどのアプリケーションで利用できます。アプリケーションの性能が特に必要な場合、例えば、異なる割り込み優先順位方式を実装するために、alt_irq_entryまたは alt_irq_handlerを置き換えて、システム性能を向上させることができます。ただし、これらのルーチンを置き換えるには、高度な専門知識と相当な労力が必要です。

システムが割り込みレイテンシに耐えるようにハードウェア・デザインを変更すれば、必要な労力も少なくてすみます。


例外処理

ISRの性能データ

このセクションでは、Nios II プロセッサでの ISR 処理に関連する性能データを示します。重要な以下の 3 つの測定基準によって、ISR の性能が決定されます。

■ 割り込みレイテンシ－割り込みが最初に生成されてから、プロセッサが例外アドレスの最初の命令を実行するまでの時間。

■ 割り込み応答時間－割り込みが最初に生成されてから、プロセッサが ISRの最初の命令を実行するまでの時間。

■ 割り込み回復時間－ ISR の最後の命令が通常の処理に復帰するまでに要する時間。

Nios IIプロセッサは高度にコンフィギュレーション可能なため、各測定基準に対する単一の標準値は存在しません。このセクションでは、以下の仮定に基づいて、各 Nios IIコアのデータ・ポイントを示します。

■ すべてのコードとデータがオンチップ・メモリに格納されていること。■ ISRコードが命令キャッシュ内に存在しないこと。■ テストに使用するソフトウェアは、アルテラが提供するHALシステム・ライブラリの例外ハンドラ・ルーチンをベースにしていること。

■ コードは、コンパイラ最適化レベル「-O3」または高度な最適化を使用してコンパイルされていること。

表 6–1 に、各 Nios II コアの割り込みレイテンシ、応答時間、および回復時間を示します。

実際に測定した結果は、以下の主な要因によって、大幅に異なることがあります。

■ 例外アドレスおよび ISRコードが存在するメモリ。表 6–1の数値は、オンチップ・メモリの使用に基づきます。低速オフチップ・メモリを使用すると、測定結果も低速になります。

■ コンパイラ最適化レベル。上記の結果は、レベル「-O3」に基づきます。レベル「-O2」を使用しても同様の結果が得られます。ただし、最適化を完全に排除すると、割り込み応答時間が大幅に増加します。

表 6–1.割り込み性能データ

コアレイテンシ応答時間回復時間

Nios II/f 8 129 78

Nios II/s 8 146 165

Nios II/e 15 362 260

表 6–1の注：(1) 数値は CPUクロック・サイクル単位で測定した時間を示します。


ISR使用のデバッグ

■ Nios IIコア。Nios II/fコア（高性能化指向設計）は、性能で Nios II/eコア（小型化指向設計）を上回ります。

■ 例外ハンドラ・ルーチン。HALシステム・ライブラリが提供する汎用 IRQ ハンドラは、C で記述されており、きわめて広範囲のアプリケーションに対応するように設計されています。IRQ ハンドラをアプリケーションの正確なニーズに合わせて設計すれば、応答時間を大幅に短縮することが可能です。

割り込みレイテンシは、割り込みが CPU のパイプラインのどの部分に挿入されているかによって異なる場合があります。ISR コードが命令キャッシュに常駐していれば、ISRの性能が改善されます。

デフォルトでは、HAL システム・ライブラリは、ISR をディスパッチするときに割り込みをディセーブルしますが、頻繁に割り込みを生成するシステムでは、これによって ISRの性能が著しく影響を受けることがあります。

ISR使用のデバッグ

ISR内にブレークポイントを設定することにより、Nios II IDEで ISRをデバッグできます。ブレークポイントに到達すると、デバッガはプロセッサを完全に停止させます。ただし、その間もシステムのハードウェアは動作し続けます。したがって、プロセッサが停止している間に、他のIRQが無視されるのは避けられません。デバッガを使用して ISRコード内をステップ移動できますが、一般にプロセッサを通常の実行に復帰させるまでの間に、その他の割り込み駆動デバイス・ドライバのステータスは無効になります。システムを既知の状態に戻すには、プロセッサをリセットする必要があります。

シングル・ステッピングの間、ipendingレジスタ（ctl4）は、すべてゼロにマスクされます。このマスク処理により、プロセッサは、コードのシングル・ステップ中にアサートされた IRQ を処理しなくなります。その結果、ipendingレジスタを読み込む例外ハンドラ・コードの部分（つまり、_irq_entryまたは alt_irq_handler()）をシングル・ステップしても、コードがペンディング中の IRQを検出することはありません。このブレークポイントが、ソフトウェア例外のデバッグに影響を与えることはありません。例外ハンドラがすでに ipending を使用して、例外を発生した IRQを特定しているため、ユーザは ISRコード内にブレークポイントを設定する（さらに、シングル・ステップで移動する）ことが可能です。


例外処理

ISRの記述に関する提案の要約

このセクションでは、HALフレームワーク用の ISRの記述に関する提案事項を要約します。

■ HAL APIが提供する alt_irq_register()関数を使用して、ISRを登録します。

■ ISR関数は、プロトタイプ void isr (void* context, alt_u32id)に適合するように記述します。

■ ISR内部で実行される処理量を最小にします。■ 低速処理タスクは、ISRから復帰するまで延期します。ISRはメッセージ引渡しメカニズムを使用して、低速処理タスクを実行するよう外部に通知できます。

■ ISRの内部では、printf()などのC標準ライブラリ I/O関数は使用しないこと。

■ alt_irq_interruptible()関数およびalt_irq_non_interruptible()関数を使用して、ISRコードの各部分で優先順位の高い ISR をイネーブル（およびディセーブル）できます。ISRが非常に短い場合、優先順位の高い割り込みを再イネーブルしても、オーバヘッドが発生するため効果的でないことがあります。

■ 最速の実行性能を実現するには、例外ハンドラと ISR コードを高速メモリ・デバイス内のメモリ・セクションに配置します。


ISRの記述に関する提案の要約


7. キャッシュ・メモリ

はじめに Nios® II プロセッサ・コアは、命令キャッシュとデータ・キャッシュを搭載することができます。この章では、Nios IIプロセッサ上でプログラムの正常な動作を保証するために検討する必要があるキャッシュ関連問題について説明します。幸いなことに、HAL システム・ライブラリをベースとする大部分のソフトウェアは、キャッシュに対する特別な対策がなくても正常に動作します。ただし、一部のソフトウェアではキャッシュを直接管理する必要があります。キャッシュを直接制御する必要があるコードに対して、Nios IIアーキテクチャでは以下の動作を実行する機能を提供しています。

■ 命令キャッシュおよびデータ・キャッシュのラインの初期化■ 命令キャッシュおよびデータ・キャッシュのラインの消去■ 命令のロード中およびストア中のデータ・キャッシュのバイパス

この章では、キャッシュの管理が必要な以下の一般的な事例について説明します。

■ リセット後のキャッシュの初期化■ デバイス・ドライバの記述■ プログラム・ローダまたは自己書き換えコードの記述■ マルチマスタ・システムまたはマルチプロセッサ・システムでのキャッシュの管理

Nios IIのキャッシュ実装Nios II コアの実装状態によって、Nios II プロセッサ・システムがデータ・キャッシュまたは命令キャッシュを搭載する場合としない場合があります。キャッシュ・メモリの有無に関わらず、ユーザはどの Nios IIプロセッサ上でも正常に機能する汎用性の高いプログラムを記述できます。一方または両方のキャッシュを搭載していない Niso IIコアの場合、キャッシュ管理操作を実行しても影響はなく、効果もありません。

現在のすべての Nios II コアで、ハードウェア・キャッシュ・コヒーレンシのメカニズムは搭載されていません。したがって、共有メモリにアクセスするマスタが複数存在する場合、ソフトウェアによって、すべてのマスタ間での整合性を明示的に維持することが必要です。

各Nios IIコア実装の機能に関する詳細は、「Nios II プロセッサ・リファレンス・ハンドブック」のNios IIコア実装の詳細の章を参照してください。

NII52007-1.0

myoshida

Text Box



はじめに

特定の Nios II プロセッサ・システムの詳細は、system.h ファイルに定義されています。以下のコードは、system.hファイルの一部を抜粋したものです。ここでは、キャッシュ・サイズや単一のキャッシュ・ラインのサイズなど、キャッシュのプロパティを定義しています。

例：キャッシュ構造を定義する system.hの一部

#define NIOS2_ICACHE_SIZE 4096#define NIOS2_DCACHE_SIZE 0#define NIOS2_ICACHE_LINE_SIZE 32#define NIOS2_DCACHE_LINE_SIZE 0

このシステムは、32バイト・ラインを持つ 4Kバイト命令キャッシュを搭載し、データ・キャッシュは搭載していません。

キャッシュ管理用 HAL API関数HAL APIは、キャッシュ・メモリを管理する以下の関数を提供しています。

■ alt_dcache_flush()■ alt_dcache_flush_all()■ alt_icache_flush()■ alt_icache_flush_all()■ alt_uncached_malloc()■ alt_uncached_free()■ alt_remap_uncached()■ alt_remap_cached()

API関数の詳細については、10–1ページの「HAL APIリファレンス」を参照してください。

その他の情報

この章では、Nios IIプログラマに関係するキャッシュ管理問題についてのみ扱います。キャッシュの基本的な動作については説明していません。「The Cache Memory Book（Jim Handy著）」は、一般的なキャッシュ管理について解説している優れた参考書籍です。


キャッシュ・メモリ

リセット後のキャッシュの初期化

リセットすれば、命令キャッシュおよびデータ・キャッシュの内容は読み込めなくなります。正しく動作させるには、キャッシュはソフトウェア・リセット・ハンドラの起動時に初期化する必要があります。

Nios IIキャッシュは、常にイネーブルされており、ソフトウェアでディセーブルすることはできません。適切な動作を実行するために、1 回のプロセッサ・リセットによって命令キャッシュは、リセット・ハンドラ・アドレスに対応する 1つの命令キャッシュ・ラインを無効化します。これによって、命令キャッシュはこのキャッシュ・ラインに対応する命令を強制的にメモリからフェッチします。リセット・ハンドラ・アドレスは、命令キャッシュ・ラインのサイズと一致する必要があります。

命令キャッシュの残りの部分の初期化は、リセット・ハンドラの最初の8 つの命令で行われます。Nios II の initi 命令は、1 つの命令キャッシュ・ラインを初期化するのに使用されます。将来の Nios II 実装で、flushi 命令を使用して命令キャッシュを初期化すると、悪影響を及ぼす可能性があるため、この命令は使用しないでください。

各命令キャッシュ・ライン・アドレスに対して initiを実行するループ内に、initi命令を配置します。以下のコードは、命令キャッシュを初期化するアセンブリ・コードの例を示します。

例：命令キャッシュを初期化するアセンブリ・コード

mov r4, r0movhi r5, %hi(NIOS2_ICACHE_SIZE)ori r5, r5, %lo(NIOS2_ICACHE_SIZE)

icache_init_loop:initi r4addi r4, r4, NIOS2_ICACHE_LINE_SIZEbltu r4, r5, icache_init_loop

命令キャッシュを初期化した後に、さらにデータ・キャッシュを初期化する必要があります。Nios IIの initid命令は、1つのデータ・キャッシュ・ラインを初期化する場合に使用します。この目的で、flushd 命令を使用しないでください。この命令はダーティ・ラインをメモリに書き戻すためです。リセット後は、キャッシュ・ライン・タグも含めて、データ・キャッシュは未定義になります。flushd を使用すると、不用意にランダム・データがランダム・アドレスに書き込まれることがあります。initd命令によって、ダーティ・データが書き戻されることはありません。

各データ・キャッシュ・ライン・アドレスに対して initd を実行するループ内に、initd命令を置きます。以下のコードは、データ・キャッシュを初期化するアセンブリ・コードの例を示します。


デバイス・ドライバの記述

例：データ・キャッシュを初期化するアセンブリ・コード

mov r4, r0movhi r5, %hi(NIOS2_DCACHE_SIZE)ori r5, r5, %lo(NIOS2_DCACHE_SIZE)

dcache_init_loop:initd 0(r4)addi r4, r4, NIOS2_DCACHE_LINE_SIZEbltu r4, r5, dcache_init_loop

一方または両方のキャッシュを実装していないNios IIコアに対しても、命令キャッシュおよびデータ・キャッシュの初期化コードは正しく実行できます。対応する種類のキャッシュが存在しない場合、initi命令とinitd命令は、単に nop命令として扱われます。

HALシステム・ライブラリ・ユーザの場合HALをベースとするプログラムでは、キャッシュ・メモリの初期化を管理する必要はありません。HAL Cランタイム・コード（crt0.S）には、alt_main()またはmain()が呼び出される前にキャッシュの初期化を実行するデフォルトのリセット・ハンドラが用意されています。

デバイス・ドライバの記述

通常、デバイス・ドライバは、そのデバイスに関連付けられたコントロール・レジスタにアクセスします。これらのレジスタは、Nios IIアドレス空間にマップされます。デバイス・レジスタにアクセスするときに、データ・キャッシュのためにアクセスが失われたり、延期されないようするために、データ・キャッシュをバイパスする必要があります。

デバイス・ドライバの場合、データ・キャッシュは ldio/stio命令ファミリを使用してバイパスしなければなりません。データ・キャッシュのないNios IIコアでは、これらの命令は対応する ld/st命令と同様に動作するため悪影響はありません。

Cプログラマの場合、ポインタを volatileとして宣言し、この volatileポインタを使用してアクセスしても、データ・キャッシュをバイパスできないことに注意してください。volatileキーワードは単に、コンパイラがポインタを使用したアクセスを最適化しないようにするためのものです。

この volatile動作は、第 1世代のNiosプロセッサの手法とは異なります。



HALシステム・ライブラリ・ユーザの場合HAL は C 言語マクロの IORD および IOWR を提供しており、これらはデータ・キャッシュをバイパスするための適切なアセンブリ命令に展開されます。IORDマクロは ldwio命令に展開され、IOWRマクロは stwio命令に展開されます。これらのマクロは、デバイス・レジスタにアクセスするために、HALデバイス・ドライバから使用する必要があります。

表 7–1に、利用可能なマクロを示します。これらのマクロはすべて実行すると、データ・キャッシュをバイパスします。一般に、ユーザのプログラムは、system.hで定義された値を BASEパラメータおよび REGNUMパラメータとして渡します。これらのマクロは、ファイル <Nios IIインストール・パス >/components/altera_nios2/HAL/inc/io.hで定義されています。

表 7–1.データ・キャッシュをバイパスする HAL I/Oマクロ

マクロ用途

IORD(BASE, REGNUM) ベース・アドレス BASE を持つデバイス内部のオフセットREGNUM のレジスタ値を読み込みます。レジスタはバスのアドレス幅だけオフセットされていると仮定されます。

IOWR(BASE, REGNUM, DATA) ベース・アドレス BASE を持つデバイス内部のオフセットREGNUMのレジスタに、DATAの値を書き込みます。レジスタはバスのアドレス幅だけオフセットされていると仮定されます。

IORD_32DIRECT(BASE, OFFSET) アドレス BASE+OFFSETの位置で 32ビットの読み込みアクセスを実行します。



IOWR_32DIRECT(BASE, OFFSET, DATA) 32ビットの書き込みアクセスを実行して、アドレスBASE+OFFSETの位置で DATAの値を書き込みます。




プログラム・ローダまたは自己書き換えコードの記述

プログラム・ローダまたは自己書き換えコードの記述

プログラム・ローダや自己書き換えコードなど、メモリに命令を書き込むソフトウェアでは、命令キャッシュおよび CPU パイプラインから古い命令を確実に消去することが必要です。この消去動作は、それぞれflushi命令および flushp命令によって実行されます。さらに、データ・キャッシュをバイパスしないストア命令を使用して新しい命令がメモリに書き込まれた場合は、flushd 命令を使用して、データ・キャッシュからメモリ内へ新しい命令を消去する必要があります。

以下のコードは、新しい命令をメモリに書き込むアセンブリ・コードを示します。

例：新しい命令をメモリに書き込むアセンブリ・コード

/* * 新しい命令が r4に存在し、* 命令アドレスが既に r5に存在すると想定します。*/stw r4, 0(r5)flushd 0(r5)flushi r5 flushp

stw命令は、r4内の新しい命令をr5で指定される命令アドレスに書き込みます。データ・キャッシュが存在する場合、命令はそのデータ・キャッシュに書き込まれ、関連付けられたラインはダーティとしてマークされます。flushd命令は、r5のアドレスに関連付けられたデータ・キャッシュ・ラインをメモリに書き込み、対応するデータ・キャッシュ・ラインを無効化します。flushi命令は、r5のアドレスに関連付けられた命令キャッシュ・ラインを無効化します。最後に、flushp 命令は、CPUパイプラインが、r5で指定されるアドレスの古い命令をプリフェッチしていないことを確認します。

上記のコード・シーケンスでは、stwio命令の代わりに、stwと flushdをペアで使用していることに注意してください。stwio命令を使用してもデータ・キャッシュは消去されないため、データ・キャッシュ内に古いデータが残る可能性があります。

このコード・シーケンスは、すべての Nios II 実装に対して有効です。Nios IIコアが特定の種類のキャッシュを搭載していない場合、対応する消去命令（flushdまたは flushi）は nopとして実行されます。

HALシステム・ライブラリ・ユーザの場合HAL APIは、このキャッシュ管理に対応する機能を提供していません。



マルチ・マスタ /マルチCPUシステムの管理

Nios IIアーキテクチャは、ハードウェア・キャッシュ・コヒーレンシを提供しません。代わりに、共有メモリを介して通信するときは、ソフトウェア・キャッシュ・コヒーレンシを提供する必要があります。すべてのマスタが最新の値を読み込み、新しいデータに古いデータを上書きしないようにするために、共有メモリにアクセスするすべてのプロセッサのデータ・キャッシュの内容は、ソフトウェアで管理しなければなりません。このような管理は、データ・キャッシュの消去およびバイパス機能を使用し、必要に応じて共有メモリとデータ・キャッシュ間でデータを移動することによって実行します。

flushd命令を使用すると、データ・キャッシュとメモリには 1つのラインに対して必ず同じ値が格納されます。ラインにダーティ・データが含まれる場合、そのデータはメモリに書き込まれます。次にそのラインはデータ・キャッシュ内で無効化されます。

最も重要なことは、常にデータ・キャッシュをバイパスすることです。プロセッサは、データ・キャッシュをバイパスするときに、アドレスがデータ・キャッシュ内に存在するかどうかチェックしません。ソフトウェアは、特定のアドレスがデータ・キャッシュ内に存在することを保証できない場合、データ・キャッシュをバイパスしてロードまたはストアを実行する前に、データ・キャッシュからアドレスを消去する必要があります。この処理によって、プロセッサはキャッシュ内の新しい（ダーティ）データをバイパスすることはなく、また誤ってメモリ内の古いデータにアクセスすることもなくなります。

ビット 31キャッシュ・バイパスldio/stio命令ファミリは、明示的にデータ・キャッシュをバイパスします。ビット 31はデータ・キャッシュをバイパスするもう 1つの手段です。ビット 31 キャッシュ・バイパスを使用すると、アドレスの最上位ビット（ビット 31）が 1に設定されている場合に、標準的な ld/st 命令ファミリを使用してデータ・キャッシュをバイパスできます。ビット31の値は CPU 内部でのみ使用されます。つまり、アクセスされる実際のアドレスでは、ビット 31は強制的にゼロになります。これにより、最大バイト・アドレス空間は 31ビットに制限されます。

関連するアドレスのキャッシュ機能がアドレス内に含まれているため、ビット 31を使用してデータ・キャッシュをバイパスするメカニズムはソフトウェアに好都合です。この使用法により、標準的な ld/st命令ファミリを使用するコードにアドレスを渡すことができ、同時にそのアドレスへのすべてのアクセスが常にデータ・キャッシュをバイパスすることを保証できます。


マルチ・マスタ /マルチ CPUシステムの管理

ビット 31キャッシュ・バイパスはNios II/fコアでのみ明示的に実現できます。その他の Nios II コアには使用しないでください。ビット 31キャッシュ・バイパスをサポートしていないその他のNios IIコアは、他の実装へコードを容易に移植するために、最大バイト・アドレス空間を31 ビットに制限しています。これらのコアは、実質的にビット 31 の値を無視するため、ビット 31 キャッシュ・バイパスを使用する Nios II/fコア用に記述されたコードは、その他の現行 Nios II 実装上でも正常に動作できます。一般に、この機能は Nios IIコア実装状態に依存します。将来のNios IIコアでは、ビット 31を他の目的に使用する可能性があります。

詳細については、「Nios II プロセッサ・リファレンス・ハンドブック」のNios IIコア実装の詳細の章を参照してください。

HALシステム・ライブラリ・ユーザの場合HALは、ldio命令ファミリに展開される C言語の IORD_*DIRECTマクロと、stio命令ファミリに展開される IOWR_*DIRECTマクロを提供します（表 7–1を参照）。これらのマクロはキャッシュ不能なメモリ領域にアクセスするためのものです。

HAL は、キャッシュされないメモリ領域の割り当てと操作を実行するalt_uncached_malloc()ルーチン、alt_uncached_free()ルーチン、alt_remap_uncached()ルーチン、およびalt_remap_cached()ルーチンを提供します。これらのルーチンは、データ・キャッシュ搭載または非搭載の Nios II コアで利用できます。つまり、データ・キャッシュを搭載したNios IIコア用に記述したコードは、データ・キャッシュ非搭載Nios IIコアと完全に互換性があります。

alt_uncached_malloc()ルーチンおよび alt_remap_uncached()ルーチンは、割り当てられたメモリ領域がデータ・キャッシュ内に存在しないこと、および以降の割り当て済みメモリ領域へのすべてのアクセスがデータ・キャッシュをバイパスすることを保証します。


8. MicroC/OS-IIリアルタイム・オペレーティング・システム

はじめにこの章では、Nios® IIプロセッサ用のMicroC/OS-IIリアルタイム・カーネルについて説明します。

概要 MicroC/OS-IIは、Micrium Inc.社製の定評のあるリアルタイム・カーネルで、解説書としては Jean J. Labrosse 著の「MicroC/OS-II - The RealTime Kernel（CMP Books）」があります。この書籍では MicroC/OS-IIは、移植性、ROM化の可能性、拡張性を備えた、プリエンプティブ、リアルタイム、マルチタスク対応のカーネルとして解説されています。MicroC/OS-II は、1992 年の発売以来、数百もの商業アプリケーションで使用され、Nios IIプロセッサを含めて 40種類以上のプロセッサ・アーキテクチャに移植されています。MicroC/OS-IIは次のサービスを提供します。

■ タスク（スレッド）■ イベント・フラグ■ メッセージ受け渡し■ メモリ管理■ セマフォ■ 時間管理

MicroC/OS-II カーネルは、Nios II プロセッサ用の HAL（HardwareAbstraction Layer）システム・ライブラリ上で動作します。HALの特性により、MicroC/OS-IIをベースにするプログラムは、他の Nios IIハードウェア・システムよりも移植性が高く、また基本ハードウェアが変更されても大きな影響を受けません。また、MicroC/OS-IIプログラムはすべての HAL サービスにアクセスし、使い慣れた HAL API（AdvancedProgramming Interface）関数を呼び出すことが可能です。

その他の情報

この章では、Nios IIプロセッサ用のMicroC/OS-IIの使い方の詳細についてのみ説明します。MicroC/OS-IIの機能と使用法に関する詳しい内容については、「MicroC/OS-II - The Real-Time Kernel」を参照してください。また、Micrium社のWebサイト www.micrium.comでも詳しい情報を入手できます。

NII52008-1.1

myoshida

Text Box



その他の RTOSプロバイダ

ライセンス

アルテラは、Nios II開発キットのMicroC/OS-IIを評価目的として配布しています。市販製品でMicroC/OS-IIの使用を計画されている場合は、[email protected]またはhttp://www.micrium.comからMicrium社に問い合わせて、ライセンスを取得する必要があります。

Micrium社は大学および学生向けに無償ライセンスを提供しています。詳細については、Micrium社にお問い合わせください。

その他のRTOSプロバイダ

アルテラは、使いやすいリアルタイム・オペレーティング・システム（RTOS）をすぐに体験いただくために、MicroC/OS-II を提供しています。MicroC/OS-II の他にも、多数の RTOS がサードパーティ・ベンダから市販されています。

Nios IIプロセッサをサポートする RTOSの全リストは、www.altera.com/nios2にあるNios IIのページにアクセスしてください。

アルテラによるMicroC/OS-IIの移植

アルテラはMicroC/OS-IIをNios IIプロセッサに移植しました。アルテラは Nios II開発キットで MicroC/OS-IIを配布し、MicroC/OS-IIカーネルのNios IIへの移植をサポートします。Nios II開発キットとともに、MicroC/OS-II プログラムがすぐに使える実用的なサンプルとしてインストールされます。実際、Nios 開発ボードは、MicroC/OS-II をベースにした Web サーバ・リファレンス・デザインおよび Lightweight IPTCP/IPスタックを使用して事前にプログラムされています。

アルテラ版 MicroC/OS-IIは、Nios II IDEから使いやすいように設計されています。Nios II IDEを使用すれば、すべての RTOSのモジュールに対するコンフィギュレーションを制御できます。カーネル機能をイネーブルまたはディセーブルするために、ソース・ファイルを直接修正する必要はありません。しかし、ユーザが確認できるように、アルテラは Nios II プロセッサ専用のソース・コードを提供しています。このコードはディレクトリ <Nios IIインストール・パス >/components/altera_nios/UCOSIIに格納されています。プロセッサに依存しないコードは、<Nios IIインストール・パス>/components/micrium_uc_osiiにあります。MicroC/OS-IIソフトウェア・コンポーネントは、SOPC Builderハードウェア・コンポーネントのドライバのように動作します。つまり、MicroC/OS-II が Nios II 統合開発環境（IDE）プロジェクトに含まれている場合、components/micrium_uc_osiiからのヘッダ・ファイルとソース・ファイルがプロジェクト・パスに含まれるため、MicroC/OS-IIカーネルはコンパイルされてプロジェクトにリンクされます。


MicroC/OS-IIリアルタイム・オペレーティング・システム

MicroC/OS-IIアーキテクチャアルテラ版Nios IIプロセッサ用MicroC/OS-IIは、基本的には HALのスーパセットです。つまり、MicroC/OS-II スケジューラおよび関連のMicroC/OS-II APIを統合して HAL環境を拡張したものです。すべてのHAL APIがMicroC/OS-IIプロジェクトから利用できます。

図 8-1 に、MicroC/OS-II をベースとしたプログラムのアーキテクチャ、およびHALとの関係を示します。

図 8-1. MicroC/OS-IIプログラムのアーキテクチャ

一部のHAL関数はマルチ・スレッド環境の影響を受けます。

マルチ・スレッド環境で特定の HAL 関数を呼び出した結果の詳細については、10–1ページの「HAL APIリファレンス」を参照してください。

MicroC/OS-IIのスレッド対応デバッグMicroC/OS-IIアプリケーションをデバッグするときに、デバッガでは、バックトレースやレジスタ値など、アプリケーション内のすべてのスレッドの現在の状態を表示できます。デバッガを使用して現在のスレッドを変更することはできません。したがって、スレッドの変更や他のスレッドのシングル・ステップ実行を目的として、デバッガを使用することはできません。

スレッド対応デバッグによって、ターゲット・アプリケーションの動作が変化することは一切ありません。

ユーザ・プログラム

C標準ライブラリ

HAL API



...デバイス・ドライバ

Nios IIプロセッサ・システム・ハードウェア

MicroC/OS-II API


アルテラによる MicroC/OS-IIの移植

MicroC/OS-IIデバイス・ドライバ各ペリフェラル（つまり、SOPC Builderコンポーネント）は、コンポーネントのHALディレクトリの incサブディレクトリおよび srcサブディレクトリにインクルード・ファイルおよびソース・ファイルを提供できます（5–1ページの「HAL用デバイス・ドライバの開発」を参照）。HALディレクトリの他にも、MicroC/OS-II 環境専用のコードを格納するUCOSII ディレクトリを提供するようにコンポーネントを選択できます。HAL ディレクトリと同様に、UCOSII ディレクトリには inc サブディレクトリと src サブディレクトリが含まれています。これらのディレクトリは、Nios II IDEでMicroC/OS-IIプロジェクトをビルドするときに、ソース検索パスとインクルード検索パスに自動的に追加されます。

UCOSIIディレクトリを使用すると、マルチ・スレッド環境でのみ使用されるコードを取得できます。これらの追加検索ディレクトリを除いて、MicroC/OS-IIデバイス・ドライバを提供するためのメカニズムは、5–1ページの「HAL用デバイス・ドライバの開発」で説明したプロセスと同じです。

HALシステム初期化プロセスでは、alt_sys_init()の前にMicroC/OS-II 関数 OSInit() を呼び出し、この関数によってシステム内の各デバイスのインスタンス化と初期化を行います。したがって、システムはプログラムが main()から OSStart()を呼び出すまでシングル・スレッド・モードで動作し続けますが、デバイス・ドライバからはすべてのMicroC/OS-II APIが利用できます。

スレッド・セーフ HALドライバ同じドライバを HAL 環境と MicroC/OS-II 環境との間で移植できるようにするために、アルテラはオペレーティング・システムの機能へアクセスを提供するOSに依存しないマクロのセットを定義しています。MicroC/OS-IIプロジェクト用にコンパイルすると、マクロはMicroC/OS-II API呼び出しに展開されます。シングル・スレッドHALプロジェクトに対してコンパイルされると、マクロは悪影響のない空の実装部に展開されます。これらのマクロは、アルテラが提供するデバイス・ドライバ・コードで使用され、同様の移植性を持つデバイス・ドライバを記述する必要がある場合にも使用できます。

表 8–1に、利用可能なマクロとそれらの機能を示します。

MicroC/OS-II 環境での機能の詳細については、「MicroC/OS-II – TheReal-Time Kernel」を参照してください。



ヘッダ・ファイルに対してリストされたパスは、<Nios IIインストール・パス >/components/micrium_uc_osii/OCOSII/inc ディレクトリを基準とする相対パスです。

表 8–1.スレッド・セーフ HALドライバ用の OSに依存しないマクロ (１ /２ )

マクロ定義するヘッダ

MicroC/OS-II実装シングル・スレッドHAL実装

ALT_FLAG_GRP(group) os/alt_flag.h groupという名前のフラグ・グループを指すポインタを作成します。

空のステートメント。

ALT_EXTERN_FLAG_GRP(group) os/alt_flag.h groupという名前のフラグ・グループを指すポインタへの外部参照を作成します。


ALT_STATIC_FLAG_GRP(group) os/alt_flag.h groupという名前のフラグ・グループを指す静的なポインタを作成します。


ALT_FLAG_CREATE(group, flags)

os/alt_flag.h OSFlagCreate()を呼び出して、flags（フラグ値）でフラグ・グループ・ポインタ group を初期化します。エラー・コードは、マクロの戻り値です。

0を返します（成功）。

ALT_FLAG_PEND(group, flags, wait_type, timeout)

os/alt_flag.h 最初の4つの入力引数をそれぞれ group、flags、wait_type、およびtimeoutに設定して、OSFlagPend()を呼び出します。エラー・コードは、マクロの戻り値です。


ALT_FLAG_POST(group, flags, opt)

os/alt_flag.h 最初の3つの入力引数をそれぞれ group、flags、および optに設定して、OSFlagPost()を呼び出します。エラー・コードは、マクロの戻り値です。


ALT_SEM(sem) os/alt_sem.h semという名前のOS_EVENT ポインタを作成します。


ALT_EXTERN_SEM(sem) os/alt_sem.h semという名前のOS_EVENT ポインタへの外部参照を作成します。



アルテラによる MicroC/OS-IIの移植

Newlib ANSI C標準ライブラリMicroC/OS-IIをベースとしたプログラムでは、ANSI C標準ライブラリ関数も呼び出せます。マルチ・スレッド環境では、C標準ライブラリ関数が確実にスレッド・セーフとなるように、何らかの配慮が必要です。NewlibCライブラリは、すべてのグローバル変数をポインタ_impure_ptrを介して参照される 1 つの構造体内に格納します。ただし、アルテラ版MicroC/OS-II は、タスクごとに構造体の新しいインスタンスを作成します。コンテキストの切り替え時に、_impure_ptrの値は、この構造体の現在のタスクのバージョンを指し示すように更新されます。このようにして、_impure_ptrが指し示す構造体の内容は、スレッド・ローカルとして扱われます。例えば、このメカニズムを利用すると、各タスクは独自のバージョンの errnoを持ちます。

このスレッド・ローカルなデータは、タスクのスタックの先頭に割り当てられます。したがって、スタックにメモリを割り当てるときは余分に領域が必要です。一般に、_reent構造体は、標準 Cライブラリでは約900バイトのデータを消費し、フットプリントを縮小した Cライブラリでも 90バイトのデータを消費します。

ALT_STATIC_SEM(sem) os/alt_sem.h semという名前の静的なOS_EVENT ポインタを作成します。


ALT_SEM_CREATE(sem, value) os/alt_sem.h value（引数）でOSSemCreate() を呼び出して、OS_EVENT ポインタsemを初期化します。戻り値は、成功時はゼロ、それ以外は負の値です。ｓｗｚ


ALT_SEM_PEND(sem, timeout) os/alt_sem.h 最初の2つの引数をそれぞれsemおよびtimeoutに設定して、OSSemPend()を呼び出します。エラー・コードは、マクロの戻り値です。


ALT_SEM_POST(sem) os/alt_sem.h 入力引数 sem を使用してOSSemPost() を呼び出します。


表 8–1.スレッド・セーフ HALドライバ用の OSに依存しないマクロ (２ /２ )

マクロ定義するヘッダ

MicroC/OS-II実装シングル・スレッドHAL実装



_reent構造体の内容に関する詳細は、（Windowsのスタート・メニューから）プログラム> Altera > Nios II Development Kit > Nios II Documentationの順にクリックして、Newlibの資料を参照してください。

さらに、MicroC/OS-IIの移植版では適切なタスク・ロックが利用できるため、ヒープ・アクセスつまり、malloc()コールと free()コールも確実にスレッド・セーフにすることができます。

Nios II IDEでのMicroC/OS-IIプロジェクトの実装

MicroC/OS-II をベースにしたプログラムを作成するには、まずシステム・ライブラリのプロパティを MicroC/OS-II プロジェクトに設定する必要があります。ここから、Nios II IDEは RTOSオプションを提供し、ユーザは MicroC/OS-II カーネルのコンフィギュレーションを制御することができます。

従来は、ファイルOS_CFG.h内で #defineディレクティブを使用して、MicroC/OS-IIをコンフィギュレーションする必要がありました。これに代わって、Nios II IDEでは GUIを使用して各オプションをコンフィギュレーションすることが可能です。したがって、MicroC/OS-IIの機能をコンフィギュレーションするために、ヘッダ・ファイルやソース・コードを編集する必要はありません。GUI 設定はシステム・ライブラリのsystem.hファイルに反映され、OS_CFG.hは単に system.hを指定するだけです。

次のセクションでは、Nios II IDEで利用可能なMicroC/OS-II設定を定義しています。各設定の意味は、すべて「MicroC/OS-II – The Real-TimerKernel」の 17章「MicroC/OS-II Configuration Manual」に記載されています。

Nios II IDEでMicroC/OS-IIプロジェクトを作成する方法に関するステップごとの説明は、「Using the MicroC/OS-II RTOS with the Nios IIProcessor Tutorial」を参照してください。



MicroC/OS-IIの一般オプション表 8–2に、一般オプションを示します。

イベント・フラグ設定

表 8–3に、イベント・フラグ設定を示します。

表 8–2.一般オプション

オプション機能説明

タスクの最大数 #define OS_MAX_TASKSにマップします。最低でも 2つが必要。

割り当て可能な最低優先順位 #define OS_LOWEST_PRIO にマップします。割り当て可能な最大値は 63です。

イベント・フラグのコード生成イネーブル

#define OS_FLAG_ENにマップします。これをディセーブルすると、イベント・フラグ設定もディセーブルされます（8–8ページの「イベント・フラグ設定」を参照）。

相互排除セマフォのコード生成イネーブル

#define OS_MUTEX_ENにマップします。これをディセーブルすると、相互排他セマフォ設定もディセーブルされます（8–9ページの「相互排除の設定」を参照）。

セマフォのコード生成イネーブル #define OS_SEM_ENにマップします。これをディセーブルすると、セマフォ設定もディセーブルされます（8–9 ページの「セマフォの設定」を参照）。

メールボックスのコード生成イネーブル

#define OS_MBOX_ENにマップします。これをディセーブルすると、メールボックス設定もディセーブルされます（8–10ページの「メールボックスの設定」を参照）。

キューのコード生成イネーブル #define OS_Q_ENにマップします。これをディセーブルウすると、キュー設定もディセーブルされます（8–10 ページの「キューの設定」を参照）。

メモリ管理のコード生成のイネーブル

#define OS_MEM_ENにマップします。これをディセーブルすると、メモリ管理設定もディセーブルされます（8–11 ページの「メモリ管理の設定」を参照）。

表 8–3.イベント・フラグ設定 (１ /２ )

設定機能説明

クリア・イベント・フラグを待機するコードのインクルード

#define OS_FLAG_WAIT_CLR_ENにマップします。

OSFlagAccept() のコードのインクルード

#define OS_FLAG_ACCEPT_ENにマップします。



相互排除の設定

表 8–4に、相互排除の設定を示します。

セマフォの設定

表 8–5に、セマフォの設定を示します。

OSFlagDel() のコードのインクルード

#define OS_FLAG_DEL_ENにマップします。

OSFlagQuery()のコードのインクルード

#define OS_FLAG_QUERY_ENにマップします。

イベント・フラグ・グループの最大数 #define OS_MAX_FLAGSにマップします。

イベント・フラグ・グループの名前のサイズ

#define OS_FLAG_NAME_SIZEにマップします。

表 8–3.イベント・フラグ設定 (２ /２ )

設定機能説明

表 8–4.相互排除の設定

設定機能説明

OSMutexAccept() のコードのインクルード

#define OS_MUTEX_ACCEPT_ENにマップします。

OSMutexDel() のコードのインクルード

#define OS_MUTEX_DEL_ENにマップします。

OSMutexQuery() のコードのインクルード

#define OS_MUTEX_QUERY_ENにマップします。

表 8–5.セマフォの設定

設定機能説明

OSSemAccept()のコードのインクルード

#define OS_SEM_ACCEPT_ENにマップします。

OSSemSet()のコードのインクルード

#define OS_SEM_SET_ENにマップします。

OSSemDel()のコードのインクルード

#define OS_SEM_DEL_ENにマップします。

OSSemQuery() のコードのインクルード

#define OS_SEM_QUERY_ENにマップします。



メールボックスの設定

表 8–6に、メールボックスの設定を示します。

キューの設定

表 8–7に、キューの設定を示します。

表 8–6.メールボックスの設定

設定機能説明

OSMboxAccept() のコードのインクルード

#define OS_MBOX_ACCEPT_ENにマップします。

OSMBoxDel() のコードのインクルード

#define OS_MBOX_DEL_ENにマップします。

OSMboxPost() のコードのインクルード

#define OS_MBOX_POST_ENにマップします。

OSMboxPostOpt() のコードのインクルード

#define OS_MBOX_POST_OPT_ENにマップします。

OSMBoxQuery()のコードのインクルード

#define OS_MBOX_QUERY_ENにマップします。

表 8–7.キューの設定

設定機能説明

OSQAccept() のコードのインクルード

#define OS_Q_ACCEPT_ENにマップします。

OSQDel()のコードのインクルード #define OS_Q_DEL_ENにマップします。

OSQFlush()のコードのインクルード

#define OS_Q_FLUSH_ENにマップします。

OSQPost() のコードのインクルード

#define OS_Q_POST_ENにマップします。

OSQPostFront() のコードのインクルード

#define OS_Q_POST_FRONT_ENにマップします。

OSQPostOpt() のコードのインクルード

#define OS_Q_POST_OPT_ENにマップします。

OSQQuery()のコードのインクルード

#define OS_Q_QUERY_ENにマップします。

キュー・コントロール・ブロックの最大数

#define OS_MAX_QSにマップします。



メモリ管理の設定

表 8–8に、メモリ管理の設定を示します。

その他の設定

表 8–9に、その他の設定を示します。

表 8–8.メモリ管理の設定

設定機能説明

OSMemQuery() のコードのインクルード

#define OS_MEM_QUERY_ENにマップします。

メモリ・パーティションの最大数 #define OS_MAX_MEM_PARTにマップします。

メモリ・パーティション名のサイズ #define OS_MEM_NAME_SIZEにマップします。

表 8–9.その他の設定

設定機能説明

引数チェックの有効化 #define OS_ARG_CHK_ENにマップします。

uCOS-IIフックの有効化 #define OS_CPU_HOOKS_ENにマップします。

デバッグ変数の有効化 #define OS_DEBUG_ENにマップします。

OSSchedLock()およびOSSchedUnlock() コードのインクルード

#define OS_SCHED_LOCK_ENにマップします。

uCOS-Viewに対するチック・ステップ機能の有効化

#define OS_TICK_STEP_ENにマップします。

静的タスクの有効化 #define OS_TASK_STAT_ENにマップします。

静的タスクからのタスク・スタックのチェック

#define OS_TASK_STAT_STK_CHK_ENにマップします。

静的タスク・スタック・サイズ #define OS_TASK_STAT_STK_SIZEにマップします。

アイドル・タスク・スタック・サイズ #define OS_TASK_IDLE_STK_SIZEにマップします。

イベント・コントロール・ブロックの最大数

#define OS_MAX_EVENTS 60にマップします。

セマフォ、相互排除、メールボックス、またはキュー名のサイズ

#define OS_EVENT_NAME_SIZEにマップします。



タスク管理の設定

表 8–10に、タスク管理の設定を示します。

時間管理の設定

表 8–11に、時間管理の設定を示します。

表 8–10.タスク管理の設定

設定機能説明

OSTaskChangePrio()のコードのインクルード

#define OS_TASK_CHANGE_PRIO_ENにマップします。

OSTaskCreate() のコードのインクルード

#define OS_TASK_CREATE_ENにマップします。

OSTaskCreateExt() のコードのインクルード

#define OS_TASK_CREATE_EXT_ENにマップします。

OSTaskDel() のコードのインクルード

#define OS_TASK_DEL_ENにマップします。

プロファイリングを目的とした変数の OS_TCBへのインクルード

#define OS_TASK_PROFILE_ENにマップします。

OSTaskQuery()のコードのインクルード

#define OS_TASK_QUERY_ENにマップします。

OSTaskSuspend()およびOSTaskResume() コードのインクルード

#define OS_TASK_SUSPEND_ENにマップします。

OSTaskSwHook() のコードのインクルード

#define OS_TASK_SW_HOOK_ENにマップします。

タスク名のサイズ #define OS_TASK_NAME_SIZEにマップします。

表 8–11.時間管理の設定

設定機能説明

OSTimeDlyHMSM() のコードのインクルード

#define OS_TIME_DLY_HMSM_ENにマップします。

OSTimeDlyResume() のコードのインクルード

#define OS_TIME_DLY_RESUME_ENにマップします。

OSTimeGet()およびOSTimeSet() コードのインクルード

#define OS_TIME_GET_SET_ENにマップします。

OSTimeTickHook() のコードのインクルード

#define OS_TIME_TICK_HOOK_ENにマップします。


9. イーサネットとLightweight IP

はじめに Lightweight IP(lwIP)は、TCP/IP(Transmission Control Protocol/InternetProtocol)スイーツを小コード量で実装します。lwIP TCP/IP実装の目的は、フル・スケール TCP/IP を提供するとともに、リソース使用量を低減することです。lwIPは、メモリ量の少ないエンベデッド・システムで使用するように設計されており、Nios® IIプロセッサ・システムに最適です。

lwIPには以下の機能があります。

■ 複数のネットワーク・インタフェースを経由したパケット転送を含む IP■ ネットワーク保守およびデバッグ用 ICMP(Internet Control Message

Protocol)■ UDP(User Datagram Protocol)■ 輻輳制御、RTT見積り、高速回復および高速再送機能を備えた TCP■ DHCP(Dynamic Host Configuration Protocol)■ イーサネット用 ARP(Address Resolution Protocol)■ API（Application Programming Interface）用標準ソケット

Nios IIプロセッサ用 lwIPアルテラは、ソース・コードを含む lwIPのNios II版を Nios II開発キットで提供しています。lwIP によって、Nios II プロセッサのイーサネット接続用スタックのオープン・ソースにすぐにアクセスできます。lwIPのアルテラ版にはソケット APIラッパが含まれており、参考文献が豊富な標準ソケット APIを提供します。

Nios II開発キットには、参考用として lwIPを使用したプログラムの実用例がいくつか用意されています。実際、Nios 開発ボードは、lwIP およびMicroC/OS-IIリアルタイム・オペレーティング・システム (RTOS)をベースにした Web サーバ・リファレンス・デザインによって事前にプログラムされ、完全なソース・コードが提供されます。

NII52009-1.2

myoshida

Text Box



はじめに

アルテラ版 lwIPは、MicroC/OS-II RTOSマルチ・スレッド環境を使用します。このため、lwIPを使用するには、MicroC/OS-II RTOSをベースにして C/C++プロジェクトを作成する必要があります。必然的に、Nios IIプロセッサ・システムにもイーサネット・インタフェースが必要です。現在、アルテラ提供の lwIPドライバは、SMSC lan91c111 MAC/PHYデバイスのみサポートしており、これはNios開発ボードで提供されるものと同じデバイスです。lwIPドライバは割り込み駆動式なので、イーサネット・コンポーネントに対する割り込みが接続されていることを確認する必要があります。

アルテラ版 lwIPは、HAL (Hardware Abstraction Layer)汎用イーサネット・デバイス・モデルをベースにしています。汎用デバイス・モデルの利点により、ターゲットとなるイーサネット・メディア・アクセス・コントローラ (MAC) をサポートする新しいドライバを記述して、ハードウェアにアクセスするための HALおよびソケット APIの一貫性を維持することができます。

イーサネット・デバイス・ドライバの記述については、5–1 ページの「HAL用デバイス・ドライバの開発」を参照してください。

この章では、Nios IIプロセッサ用 lwIPの詳細な使用方法についてのみ説明します。

標準ソケット・インタフェースには参考文献が豊富にあり、ソケットによるプログラミングに関する多くの解説書が出版されています。優れた参考文献としては、「Unix Network Programming（Richard Stevens著）」と「Internetworking with TCP/IP Volume 3（Douglas Comer著）」の 2冊が挙げられます。

lwIPファイルとディレクトリNios II IDE を使用して C/C++ プログラムで lwIP を使用するためにソース・コードを編集する必要はありません。しかし、アルテラは参考用にソース・コードを提供しています。デフォルトでは、これらのファイルは Nios II開発キットとともに <Nios IIインストール・パス >/components/altera_lwip/UCOSII ディレクトリにインストールされます。

スタックのディレクトリ形式では、より新しいバージョンの lwIP にスムーズにアップグレードできるように、オリジナルのオープン・ソース・コードを可能な限り UCOSII/src/downloads ディレクトリで管理します。UCOSII/src/downloads/lwip-0.7.2 ディレクトリにはオリジナルのlwIP v0.7.2ソース・コードが、UCOSII/src/downloads/lwip4ucosiiディレクトリにはMicroC/OS-II対応版のソース・コードがあります。


イーサネットと Lightweight IP

アルテラ版 lwIP ポートはプロトコル・スタックのバージョン 0.7.2 をベースにしており、HALシステム・ライブラリに統合するために、コードの周囲にラッパが配置されています。より新しいバージョンの lwIPも入手できますが、新しいバージョンは HALシステム・ライブラリ・ラッパでのテストが行われていません。

ライセンス

lwIP は、スウェーデン・コンピュータ科学研究所 (SICS) のコンピュータおよびネットワーク・アーキテクチャ(CNA)研究室で、Adam Dunkelsによって作成されたオープン・ソースの TCP/IPプロトコル・スタックであり、修正 BSD ライセンスの条件下で利用できます。lwIP プロジェクトは、http://savannah.nongnu.org/projects/lwip/で Savannahが管理しています。lwIPの背景情報とライセンスの詳細については、SavannahのWebサイトを参照してください。

以下の条件を満たす場合に限り、変更の有無にかかわらず、ソースおよびバイナリ形式での再配布と使用が許可されます。

■ ソース・コードを再配布する場合、<lwIPコンポーネントのパス >/UCOSII/src/downloads/lwIP-0.7.2/COPYING に示す著作権表示と免責事項を維持しなければなりません。

■ バイナリ形式で再配布する場合、<lwIPコンポーネントのパス >/UCOSII/src/downloads/lwIP-0.7.2/COPYING に示す著作権表示を複製して添付しなければなりません。

その他のTCP/IPスタック •プロバイダ

その他のサードパーティ・ベンダもNios IIプロセッサのイーサネット・サポートを提供しています。特に、サードパーティの RTOS ベンダは、多くの場合にそれぞれの RTOS フレームワーク用のイーサネット・モジュールを提供しています。

サードパーティ・プロバイダから入手可能な製品に関する最新情報については、www.altera.com/nios2のNios IIホームページをご覧ください。

lwIPプロトコル•スタックの使用

ここでは、Nios IIプログラムに lwIPプロトコル・スタックを含める方法について説明します。

lwIPプロトコル・スタックへの主要インタフェースは標準ソケット・インタフェースです。ソケット・インタフェースに加えて、以下の関数を呼び出してスタックとドライバを初期化します。

■ lwip_stack_init()■ lwip_devices_init()


lwIPプロトコル •スタックの使用

HAL システム・コードで呼び出される以下のシンプルな関数を使用して、MACアドレスと IPアドレスを設定する必要もあります。

■ init_done_func()■ get_mac_addr()■ get_ip_addr()

Nios IIのシステム要求lwIP を使用するには、Nios II システムが以下の要求を満たす必要があります。

■ システム・ハードウェアは、割り込みがイネーブルされたイーサネット・インタフェースを搭載していること。

■ システム・ライブラリはMicroC/OS-IIベースであること。

lwIPタスクアルテラ提供の lwIP プロトコルは、以下の 2 つの基本タスクを使用します。これらのタスクは、ユーザ・プログラムで作成したタスクに加えて連続的に実行されます。

1. メイン・タスクはプロトコル・スタックによって使用されます。メイン・タスクにはパケット受信タスクがあります。このタスクのメイン関数は、メッセージ・ボックスの待機をブロックします。新しいパケットが到着すると、割り込み要求 (IRQ) が生成され、割り込みサービス・ルーチン (ISR) がその IRQ をクリアして、メッセージをメッセージ・ボックスに送信します。

2. 次に、新しいメッセージが受信タスクを起動します。このような設計により、ISRをできるだけ迅速に実行して、システム・レイテンシへの影響を軽減できます。

これらのタスクは初期化プロセスが成功すると自動的に開始されます。システム内の他のタスクと重要度を比較してタスクの優先順位を設定してください。



スタックの初期化

スタックを初期化するには、関数 OSStartを呼び出す前にlwip_stack_init()を呼び出して、MicroC/OS-IIスケジューラを起動します。以下のコードは、main()の例を示します。

例 :main()での lwIPスタックのインスタンス化

#include <includes.h>#include <alt_lwip_dev.h>

int main (){... lwip_stack_init(TCPIP_THREAD_PRIO, init_done_func, 0);... OSStart();... return 0; }

lwip_stack_init()

lwip_stack_init()はプロトコル・スタックのセットアップを実行します。lwip_stack_init()のプロトタイプは以下のとおりです。

void lwip_stack_init(int thread_prio, void (* init_done_func)(void *), void *arg)

lwip_stack_init()は何も返さず、以下のパラメータを使用します。

■ thread_prio－メイン TCP/IPスレッドの優先順位。■ init_done_func －スタックが初期化されると呼び出される関数へのポインタ。

■ arg－ init_done_func()に渡す引数。argは通常ゼロに設定されます。

init_done_func()

スタックの初期化後に呼び出される関数init_done_func()を供給する必要があります。init_done_func()関数は lwip_devices_init()を呼び出さなければなりません。この関数はインストールされたすべてのイーサネット・デバイス・ドライバを初期化してから、受信タスクを作成します。

init_done_func()のプロトタイプは以下のとおりです。

void init_done_func(void* arg)



以下のコードは、init_done_func()関数の実装例であるtcpip_init_done()関数の例を示します。

例 :init_done_func()の実装

#include <stdio.h>#include <lwip/sys.h>#include <alt_lwip_dev.h>#include <includes.h>/** IPスタックがアクティブになると、この関数が呼び出されます。*/static void tcpip_init_done(void *arg){ int temp;

if (lwip_devices_init(ETHER_PRIO)){

/* 初期化が成功すると、ユーザ・タスクを開始します。*/temp = sys_thread_new(user_thread_func,

NULL, USER_THREAD_PRIO);

if (!temp)

{perror("Can't add the application threadsOSTaskDel(OS_PRIO_SELF);

}}

else{

/* * 以下の場合には、イーサネット・インタフェースを追加できません。

* 1. イーサネット・ハードウェアが存在しない場合 * 2. ハードウェアを初期化できない場合 * (ネットワークに接続されていない場合や * MACアドレスを取得できない場合など ) */ perror("Can't initialize any interface. Closing down.\n"); OSTaskDel(OS_PRIO_SELF); } return;}

ソケット・プロトコルを使用して IPスタックと通信する新しいタスクを作成するには、sys_thread_new()を使用する必要があります。

詳細については、9–10ページの「ソケット・インタフェースの呼び出し」を参照してください。



lwip_devices_init()

lwip_devices_init()は、system.hで定義されたインストール済のすべてのイーサネット・デバイスのリストを繰り返し実行し、各ドライバをスタックに登録します。lwip_devices_init() は成功するとゼロ以外の値を返します。成功すると TCP/IP スタックが使用可能になり、プログラム用のタスクを作成できます。

lwip_devices_init()のプロトタイプは以下のとおりです。

int lwip_devices_init(int rx_thread_prio)

この関数のパラメータは、受信スレッドの優先順位です。lwip_devices_init()は関数 get_mac_addr()とget_ip_address() を呼び出すので、これらの関数を用意する必要があります。

get_mac_addr() & get_ip_addr()

get_mac_addr()と get_ip_addr()は、デバイスの初期化処理中にlwIP システム・コードから呼び出されます。これらの関数は、lwIP システム・コードが特定デバイスのMACアドレスと IPアドレスを設定するのに必要です。これらの関数を自分で記述することにより、MAC アドレスと IPアドレスを、デバイス・ドライバにハードコード化された固定の場所ではなく、任意の場所に柔軟に格納できます。例えば、あるシステムでは MACアドレスをフラッシュ・メモリに格納し、他のシステムではオンチップ・エンベデッド・メモリに格納することができます。

どちらの関数も lwIP が内部で使用するデバイス構造体をパラメータとして取ります。ただし、構造体の詳細を把握している必要はありません。MACアドレスと IPアドレスを供給できれば十分です。

get_mac_addr()のプロトタイプは以下のとおりです。

err_t gat_mac_addr(alt_lwip_dev* lwip_dev);

関数内で、MAC アドレスを定義する alt_lwip_dev 構造体の以下のフィールドに入力する必要があります。

■ unsigned char lwip_dev->netif->hwaddr_len－MACアドレスの長さ。6に設定します。

■ unsigned char lwIP_dev->netif->hwaddr[0-5]－デバイスのMACアドレス。

コードで初期化するデバイスの名前も検証することができます。



get_mac_addr()のプロトタイプは、ヘッダ・ファイルUCOSII/inc/alt_lwip_dev.hにあります。netif構造体はUCOSII/src/downloads/lwip-0.7.2/src/include/lwip/netif.hファイルで定義されます。

以下のコードは、get_mac_addr()の実装例を示します。この例では、あくまでも説明の目的でMACアドレスがアドレス 0x7f0000に格納されます。

例 :get_mac_addr()の実装

#include <alt_lwip_dev.h>#include <lwip/netif.h>#include <io.h>err_t get_mac_addr(alt_lwip_dev* lwip_dev){ err_t ret_code = ERR_IF; /* * この名前は system.hで定義されたデバイス名です。 */ if (!strcmp(lwip_dev->name, "/dev/lan91c111")) {

/* MACアドレスの格納場所から 6バイトの MACアドレスを読み出します。*/lwip_dev->netif->hwaddr[0] = IORD_8DIRECT(0x7f0000, 4);lwip_dev->netif->hwaddr[1] = IORD_8DIRECT(0x7f0000, 5);lwip_dev->netif->hwaddr[2] = IORD_8DIRECT(0x7f0000, 6);lwip_dev->netif->hwaddr[3] = IORD_8DIRECT(0x7f0000, 7);lwip_dev->netif->hwaddr[4] = IORD_8DIRECT(0x7f0000, 8);lwip_dev->netif->hwaddr[5] = IORD_8DIRECT(0x7f0000, 9);ret_code = ERR_OK;

} return ret_code;}

関数 get_ip_addr() は、プロトコル・スタックの IP アドレスを割り当てます。プログラムによって DHCPを要求して IPアドレスを自動的に見つけるか、またはスタティック・アドレスを割り当てることができます。get_ip_addr()の関数プロトタイプは以下のとおりです。

int get_ip_addr(alt_lwip_dev* lwip_dev, struct ip_addr* ipaddr,

struct ip_addr* netmask, struct ip_addr* gw,

int* use_dhcp);

DHCPをイネーブルするには、以下の行を含めます。

*use_dhcp = 1;



スタティック IPアドレスを割り当てるには、以下の行を含めます。

IP4_ADDR(ipaddr, IPADDR0,IPADDR1,IPADDR2,IPADDR3);IP4_ADDR(gw, GWADDR0,GWADDR1,GWADDR2,GWADDR3);IP4_ADDR(netmask, MSKADDR0,MSKADDR1,MSKADDR2,MSKADDR3);*use_dhcp = 0;

IP_ADDR0-3は IPアドレスのバイト0-3です。GWADDR0-3はゲートウェイ・アドレスのバイトです。MSKADDR0-3はネットワーク・マスクのバイトです。

get_ip_addr()のプロトタイプはヘッダ・ファイルUCOSII/inc/alt_lwip_dev.hにあります。

以下のコードは、get_ip_addr() の実装例と、必要なインクルード・ファイルのリストを示します。

例 :get_ip_addr()の実装

#include <lwip/tcpip.h>#include <alt_lwip_dev.h>int get_ip_addr(alt_lwip_dev* lwip_dev,

struct ip_addr* ipaddr, struct ip_addr* netmask,

struct ip_addr* gw, int* use_dhcp){int ret_code = 0;/** この名前は system.hで定義されたデバイス名です。*/

if (!strcmp(lwip_dev->name, "/dev/lan91c111")) {#if LWIP_DHCP == 1 *use_dhcp = 1;#else

/* スタティック IPアドレスを割り当てます。*/ IP4_ADDR(&ipaddr, 10,1 ,1 ,3); /* デフォルトのデートウェイ・アドレスを割り当てます。*/ IP4_ADDR(&gw, 10,1 , 1,254); /* ネットマスクを割り当てます。*/

IP4_ADDR(&netmask, 255,255 ,255 ,0); *use_dhcp = 0;#endif /* LWIP_DHCP */

ret_code = 1; } return ret_code;}


Nios II IDEでの lwIPのコンフィギュレーション

ソケット・インタフェースの呼び出し

イーサネット・デバイスが初期化されたら、プログラムの残りはソケット APIを使用して IPスタックにアクセスする必要があります。

ソケット API を使用して IP スタックと通信する新しいタスクを作成するには、関数 sys_thread_new()を使用する必要があります。sys_thread_new()関数は、スレッドを作成する lwIP OSポーティング・レイヤの一部です。sys_thread_new()はMicroC/OS-II OSTaskCreate()関数を呼び出して、その他の lwIP固有の処理を実行します。

sys_thread_new()のプロトタイプは以下のとおりです。

sys_thread_t sys_thread_new(void (* thread)(void *arg), void *arg,int prio);

このプロトタイプはucosII/src/downloads/lwIP-0.7.2/src/include/lwIP/sys.hにあります。#include “lwIP/sys.h”として挿入できます。

OSポーティング・レイヤのその他の詳細は、lwIpコンポーネント・ディレクトリ、UCOSII/src/downloads/lwip4ucosii/ucos-ii/のsys_arch.cファイルを参照してください。


lwIPプロトコル・スタックには、ファイル lwipopts.hの #defineディレクティブを使用してコンフィギュレーションされる多くのコンフィギュレーション・オプションがあります。Nios II統合開発環境 (IDE)は、ソース・コードを編集せずに lwIP オプションをコンフィギュレーションできる (すなわち、lwipopts.hの #definesを変更できる )グラフィカル・ユーザ・インタフェース (GUI)を提供します。最も一般的なオプションは GUI を介して利用できます。ただし、GUI を介して変更できないオプションがいくつかあり、この場合は lwipopts.hファイルを手作業で編集する必要があります。

以下のセクションでは、Nios II IDEでコンフィギュレーション可能な機能について説明します。GUI で各機能のデフォルト値が提供されます。一般に、これらの値は適切な開始ポイントとして用意されており、システムの要求に応じて後から微調整することができます。



Lightweight TCP/IPスタックの一般的な設定ARP および IP プロトコルは常にイネーブルされます。表 9–1にプロトコル・オプションを示します。

表 9–2 に、TCP/IP スタックの全体的な動作に影響するグローバル・オプションを示します。

IPオプション複数のネットワーク・インタフェースが存在するときに IPパケット転送オプションがオンの場合、1つのインタフェースの IPスタックがそのインタフェース宛でないパケットを受信した場合、その他のインタフェースからパケットを転送します。

表 9–1.プロトコル・オプション


UDP UDP(user datagram protocol)をイネーブル /ディセーブルします。

TCP TCP(transmission control protocol)をイネーブル /ディセーブルします。

表 9–2.グローバル・オプション


DHCP を使用した IP アドレスの自動割り当て

DHCPをイネーブル /ディセーブルします。DHCPを使用するには UDPプロトコルがイネーブルであることが必要です。

統計の有効化このオプションがオンになっている場合、スタックは受信パケット、エラーなどのカウンタを維持します。これらのカウンタは、UCOSII/src/downloads/lwIP-0.7.2/src/coreファイルの構造体変数lwip_statsで定義されます。構造体の定義はUCOSII/src/downloads/lwIP-0.7.2/src/include/lwIP/stats.hにあります。

パケット・バッファ数パケットを受信するネットワーク・ドライバのバッファ数。

存続時間データグラムが破棄されるまでシステム内で保持される秒数。

最大パケット・サイズネットワーク・インタフェース上のパケットの最大サイズ。

デフォルト MACインタフェース

IP スタックに複数のネットワーク・インタフェースが存在する場合、このパラメータで既知のルートがない IPアドレスにパケットを送信する際、使用するインタフェースを指定します。9–13ページの「確認されている制限事項」を参照してください。



ARPオプションARP テーブルのサイズは、ARP キャッシュに格納可能なエントリ数です。

UDPオプションアプリケーションが使用する UDPソケットの最大数を入力できます。

TCPオプション表 9–3に TCPオプションを示します。

DHCPオプション割り当てられたアドレスが使用されていないことを ARP が確認するように指定できます。これにより、DHCP プロトコルが IP アドレスを割り当てると、APRパケットを送信して、割り当てたアドレスが他で使用されていないことを確認します。

表 9–3. TCPオプション


最大リスニング・ソケット数接続するクライアントをリスニングできる TCPソケットの最大数。

最大アクティブ・ソケット数プログラムが使用するTCPソケットの最大数 (リスニング中のソケットを除く )。

最大再送信数 TCP プロトコルが認識されていないパケットの再送信を試行する最大回数。

SYNフレームの最大再送信数 TCP プロトコルが認識されていない SYN パケットの再送信を試行する最大回数。

最大セグメント・サイズ TCPセグメントの最大サイズ。

最大送信バッファ・スペース TCPが転送用にバッファに格納するデータの最大容量。

最大ウィンドウ・サイズ TCPがバッファに格納する各受信ソケット用データの最大容量。



メモリ・オプション

表 9–4にメモリ・オプションを示します。

確認されている制限事項

アルテラの現行の lwIP スタックの実装に関して、以下の制限事項が確認されています。

■ lwIPはシャットダウン・ソケット・コールを正しく実装しません。シャットダウン・コールはクローズ・ソケット・コールに直接マップします。

■ コード内に複数のネットワーク・インタフェース機能が存在しますが、テストは行われていません。

表 9–4.メモリ・オプション


コピーなしで送信される最大バッファ数

スタックがコピーしないで再送を試行する最大バッファ数。UDPパケットおよび断片化された IP パケットの送信にのみこのオプションを使用します。このオプションは lwIP #define memp_num_pbufにマップします。

アプリケーション・スレッドとスタック・スレッド間で渡される最大パケット・バッファ数

アプリケーション・スレッドとプロトコル・スタック・スレッドの間 ( いずれかの方向 )で、一度に渡すことができる最大バッファ数。このオプションは lwIP #define memp_num_netbufにマップします。

アプリケーション・スレッドからスタック・スレッドまでの最大ペンディング API呼び出し数

アプリケーション・スレッドからプロトコル・スレッドに API呼び出しを送信するメッセージ・ボックスのサイズ。このオプションは lwIP #definememp_num_api_msgにマップします。

プロトコル・スタック・スレッドからアプリケーションに渡される最大メッセージ数

アプリケーション・スレッドからスタック・スレッドに渡される API呼び出しと、その他の方法で渡されるパケットとの組み合わせ。このオプションは lwIP #define memp_num_tcpip_msgにマップされます。

TCP/IPヒープ・サイズバッファを一時的な場所にコピーするためのメモリ・プールのサイズ。合計メモリ・サイズではありません。このオプションは lwIP #definemem_sizeにマップします。


確認されている制限事項

Altera Corporation セクション IV–1

セクション IV. 付録


■ 第 10章　HAL APIリファレンス

■ 第 11章　アルテラの開発ツール

■ 第 12章　リード・オンリ zipファイル・システム

改定履歴以下の表に、各章の改定履歴を示します。これらのバージョンは資料の改定を追跡しているのもので、Nios II開発キットや Nios IIプロセッサのバージョンには関係ありません。


10 2004年 12月v1.2

DMAの一般的な要求の名前を更新

2004年 9月v1.1

● open()を追加● alt_dma_txchan_open()に ERRNO情報を追加

● ALT_DMA_TX_STREAM_ONの定義を修正● ALT_DMA_RX_STREAM_ONの定義を修正● alt_dma_rxchan_ioctl()および

alt_dma_txchan_ioctl()に情報を追加

2004年 5月v1.0

初版

11 2004年 12月v1.1

Nios IIコマンドライン・ツールの情報を追加

2004年 5月v1.0

初版

12 2004年 5月v1.0

初版

myoshida

Text Box


セクション IV–2 Altera Corporation

付録 Nios II ソフトウェア開発ハンドブック


10. HAL APIリファレンス

はじめにこの章では、HAL（Hardware Abstraction Layer）API内のすべての関数をアルファベット順に記載します。それぞれの関数について Cプロトタイプを示し、簡単に説明します。また、マルチ・スレッド環境で実行するときにスレッド・セーフかどうか、割り込みサービス・ルーチン（ISR）から呼び出せるかどうかについても示します。

この章では、HALが提供する機能のみを記載します。HALシステム内部からはすべてのNewlib APIも利用できることに注意してください。例えば、Newlibは、ここで説明していない printf()やその他の標準 I/O関数を提供しています。

Newlib API の詳細については、Newlib の資料を参照してください。（Windows のスタート・メニューから）プログラム > Altera > Nios IIDevelopment Kit > Nios II Documentationの順にクリックしてください。

NII52010-1.2

myoshida

Text Box



_exit()

プロトタイプ void _exit (int exit_code)

一般的な呼び出し元 Newlib Cライブラリ

スレッド・セーフ ○

ISRからの利用 ×

インクルード <unistd.h>

説明 Newlibの exit()関数は、_exit()関数を呼び出して現在のプロセスを終了します。一般に、main()が完了したときに呼び出されます。HALシステム内にはプロセスは 1つしかないため、HAL実装は永久にブロックします。

割り込みはディセーブルされないため、ISR は動作し続けることに注意してください。

入力引数 exit_codeは無視されます。

戻り値 –

関連項目 Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。


HAL APIリファレンス

_rename()

プロトタイプ int _rename(char *existing, char* new)



ISRからの利用 ○

インクルード <stdio.h>

説明 _rename()関数は、Newlibの互換性を確保します。

戻り値常にリターン・コード –1で、errnoを ENOSYSに設定して失敗します。



alt_alarm_start()

プロトタイプ int alt_alarm_start (alt_alarm* alarm, alt_u32 nticks, alt_u32 (*callback) (void* context),void* context)

一般的な呼び出し元 C/C++プログラムデバイス・ドライバ



インクルード <sys/alt_alarm.h>

説明 alt_alarm_start() 関数はアラーム・コールバックをスケジュールします（4–11ページの「アラーム」を参照）。入力引数 ntickは、callback関数を呼び出すまで積算されるシステム・クロック・チック数です。入力引数 contextは、コールバックが発生したときに、入力引数として callbackに渡されます。

入力 alarm は、このアラームを表す構造体へのポインタです。このポインタは、ユーザが作成する必要があり、少なくともアラームよりも長い間有効である必要があります。ただし、alarmが指し示す構造体の内容をユーザが初期化する必要はありません。この処理は、alt_alarm_start() 呼び出しによって実行されます。

戻り値 alt_alarm_start() の戻り値は、成功した場合はゼロ、それ以外は負の値です。この関数はシステム・クロックが利用できない場合は失敗します。

関連項目 alt_alarm_stop()alt_nticks()alt_sysclk_init()alt_tick()alt_ticks_per_second() gettimeofday()settimeofday()times()usleep()



alt_alarm_stop()

プロトタイプ void alt_alarm_stop (alt_alarm* alarm)





説明 alt_alarm_stop()関数を呼び出すと、alt_alarm_start()呼び出しによって以前に登録されたアラームをキャンセルできます。入力引数は、以前のalt_alarm_start() 呼び出しに使用したアラーム構造体へのポインタです。

復帰時にアラームがまだアクティブの場合、アラームはキャンセルされます。

戻り値 –

関連項目 alt_alarm_start()alt_nticks()alt_sysclk_init()alt_tick()alt_ticks_per_second() gettimeofday()settimeofday()times()usleep()


alt_dcache_flush()

プロトタイプ void alt_dcache_flush (void* start, alt_u32 len)




インクルード <sys/alt_cache.h>

説明 alt_dcache_flush() 関数は、アドレス start から len バイトの長さのメモリ領域に対するデータ・キャッシュを消去（つまり、ダーティ・データをライト・バックして無効化）します。

データ・キャッシュのないプロセッサでは、効果はありません。

戻り値 –

関連項目 alt_dcache_flush_all()alt_icache_flush()alt_icache_flush_all()#alt_remap_cached()alt_remap_uncached()alt_uncached_free()alt_uncached_malloc()



alt_dcache_flush_all()

プロトタイプ void alt_dcache_flush_all (void)





説明 alt_dcache_flush_all()関数は、データ・キャッシュのすべての内容を消去（つまり、ダーティ・データをライト・バックして無効化）します。

データ・キャッシュのないプロセッサでは、効果はありません。

戻り値 –

関連項目 alt_dcache_flush()alt_icache_flush()alt_icache_flush_all()#alt_remap_cached()alt_remap_uncached()alt_uncached_free()alt_uncached_malloc()


alt_dev_reg()

プロトタイプ int alt_dev_reg(alt_dev* dev)

一般的な呼び出し元デバイス・ドライバ

スレッド・セーフ ×


インクルード <sys/alt_dev.h>

説明 alt_dev_reg()関数は、デバイスをシステムに登録します。登録が完了すると、標準 I/O 関数を使用してそのデバイスにアクセスできます（4–1 ページの「HALを使用したプログラムの開発」を参照）。

デバイスが、既存のデバイスまたはファイル・システムと競合する名前で登録された場合、システムの動作は不定となります。

alt_dev_reg()関数が呼び出された時点で、そのデバイスを使用しているスレッドが他に存在してはならないという意味で、alt_dev_reg() 関数はスレッド・セーフではありません。実際には、alt_dev_reg()は、シングル・スレッド・モードで動作している間にのみ呼び出す必要があります。この関数はalt_sys_init()で起動されたデバイス初期化関数によってのみ呼び出され、このデバイス初期化関数はシングル・スレッドの C起動コードによってのみ呼び出されることを想定しています。

戻り値ゼロの戻り値は正常に終了したことを示します。負の戻り値は失敗を示します。

関連項目 alt_fs_reg()



alt_dma_rxchan_close()

プロトタイプ int alt_dma_rxchan_close (alt_dma_rxchan rxchan)




インクルード <sys/alt_dma.h>

説明 alt_dma_rxchan_close() 関数は、アプリケーションが DMA 受信チャネル rxchanの使用を完了したことをシステムに通知します。現在の実装は常に成功します。

戻り値戻り値は、成功した場合はゼロ、それ以外は負の値です。

関連項目 alt_dma_rxchan_depth()alt_dma_rxchan_ioctl()alt_dma_rxchan_open()alt_dma_rxchan_prepare()alt_dma_rxchan_reg()alt_dma_txchan_close()alt_dma_txchan_ioctl()alt_dma_txchan_open()alt_dma_txchan_reg()alt_dma_txchan_send()alt_dma_txchan_space()


alt_dma_rxchan_depth()

プロトタイプ alt_u32 alt_dma_rxchan_depth(alt_dma_rxchan dma)





説明 alt_dma_rxchan_depth()関数は、指定されたDMA受信チャネルdmaに送信できる受信要求の最大数を返します。

この関数がスレッド・セーフかどうか、または ISRから呼び出せるかどうかは、基本デバイス・ドライバによって決まります。一般には、デバイスに依存しないことを前提とします。

戻り値送信できる受信要求の最大数を返します。

関連項目 alt_dma_rxchan_close()alt_dma_rxchan_ioctl()alt_dma_rxchan_open()alt_dma_rxchan_prepare()alt_dma_rxchan_reg()alt_dma_txchan_close()alt_dma_txchan_ioctl()alt_dma_txchan_open()alt_dma_txchan_reg()alt_dma_txchan_send()alt_dma_txchan_space()



alt_dma_rxchan_ioctl()

プロトタイプ int alt_dma_rxchan_ioctl (alt_dma_rxchan dma, int req, void* arg)


スレッド・セーフ説明を参照。

ISRからの利用説明を参照。


説明 alt_dma_rxchan_ioctl()関数は、DMA受信チャネル dma上でデバイス固有の I/O 操作を実行します。例えば、一部のドライバは転送操作の幅を制御するオプションをサポートしています。入力引数reqは要求される操作の列挙、argは要求に対する追加引数です。argの解釈は要求によって異なります。

表 10–1 に、<sys/alt_dma.h> で定義されている一般的な要求を示します。デバイスはこれら要求をサポートできます。

alt_dma_rxchan_iotcl()の呼び出しがスレッド・セーフかどうか、または ISR から呼び出せるかどうかは、デバイスによって決まります。一般には、デバイスに依存しないことを前提とします。

DMA 転送のペンディング中に alt_dma_rxchan_ioctl() 関数を呼び出さないでください。予期できない動作が発生することがあります。

戻り値負の戻り値は失敗を示します。それ以外の場合、戻り値の解釈は要求によって異なります。

関連項目 alt_dma_rxchan_close()alt_dma_rxchan_depth()alt_dma_rxchan_open()alt_dma_rxchan_prepare()alt_dma_rxchan_reg()alt_dma_txchan_close()alt_dma_txchan_ioctl()alt_dma_txchan_open()alt_dma_txchan_reg()alt_dma_txchan_send()alt_dma_txchan_space()


表 10–1.一般的な要求

要求意味

ALT_DMA_SET_MODE_8 8ビット単位でデータを送信します。argの値は無視されます。





ALT_DMA_GET_MODE 送信幅を返します。argの値は無視されます。

ALT_DMA_TX_ONLY_ON (1) ALT_DMA_TX_ONLY_ON要求によって、DMAチャネルは、トランスミッタのみがソフトウェアで制御されるモードで動作します。他端は 1つの位置から連続して書き込みます。書き込み先のアドレスはこの要求の引数です。

ALT_DMA_TX_ONLY_OFF (1) DMA の受信側と送信側の両方をソフトウェアで制御可能なデフォルト・モードに戻ります。

ALT_DMA_RX_ONLY_ON (1) ALT_DMA_RX_ONLY_ON要求によって、DMAチャネルは、レシーバのみがソフトウェアで制御されるモードで動作します。他端は 1つの位置から連続して読み込まれます。読み込むアドレスはこの要求の引数です。

ALT_DMA_RX_ONLY_OFF (1) DMA の受信側と送信側の両方をソフトウェアで制御可能なデフォルト・モードに戻ります。

表 10–1の注：(1) Nios II開発キットのバージョン 1.1では、これらのマクロ名は変更されています。古い名前（ALT_DMA_TX_STREAM_ON、ALT_DMA_TX_STREAM_OFF、ALT_DMA_RX_STREAM_ON、およびALT_DMA_RX_STREAM_OFF）は現在でも有効ですが、新しいデザインでは新しい名前を使用してください。



alt_dma_rxchan_open()

プロトタイプ alt_dma_rxchan alt_dma_rxchan_open (const char* name)





説明 alt_dma_rxchan_open()関数は、DMA受信チャネルのalt_dma_rxchanディスクリプタを取得します。入力引数 nameは、/dev/dma_0など、関連付けられた物理デバイスの名前です。

戻り値戻り値は、失敗した場合は null、そうでない場合は null 以外の値です。エラーが発生した場合、errnoは ENODEVに設定されます。

関連項目 alt_dma_rxchan_close()alt_dma_rxchan_depth()alt_dma_rxchan_ioctl()alt_dma_rxchan_prepare()alt_dma_rxchan_reg()alt_dma_txchan_close()alt_dma_txchan_ioctl()alt_dma_txchan_open()alt_dma_txchan_reg()alt_dma_txchan_send()alt_dma_txchan_space()


alt_dma_rxchan_prepare()

プロトタイプ int alt_dma_rxchan_prepare (alt_dma_rxchan dma, void* data,alt_u32 length,alt_rxchan_done* done, void* handle)





説明 alt_dma_rxchan_prepare() は、DMA 受信チャネルに受信要求を送信します。入力引数 dmaは使用するチャネル、dataはデータの受信先を示すポインタ、length は受信するデータのバイト単位の最大長、done はデータが受信されると呼び出しされるコールバック関数、handleは doneに渡される不定値です。


戻り値戻り値は、要求を送信できない場合は負の値、それ以外はゼロです。

関連項目 alt_dma_rxchan_close()alt_dma_rxchan_depth()alt_dma_rxchan_ioctl()alt_dma_rxchan_open()alt_dma_rxchan_reg()alt_dma_txchan_close()alt_dma_txchan_ioctl()alt_dma_txchan_open()alt_dma_txchan_reg()alt_dma_txchan_send()alt_dma_txchan_space()



alt_dma_rxchan_reg()

プロトタイプ int alt_dma_rxchan_reg (alt_dma_rxchan_dev* dev)




インクルード <sys/alt_dma_dev.h>

説明 alt_dma_rxchan_reg()関数は、DMA受信チャネルをシステムに登録します。登録が完了すると、4–23 ページの「DMA 受信チャネル」で説明した関数を使用してデバイスにアクセスできます。

チャネルが既存のチャネルと競合する名前で登録された場合、システムの動作は不定になります。

alt_dma_rxchan_reg() が呼び出された時点で他のスレッドがチャネル・リストを使用している場合、alt_dma_rxchan_reg()関数はスレッド・セーフではありません。実際には、alt_dma_rxchan_reg() は、シングル・スレッド・モードで動作している間にのみ呼び出します。alt_sys_init()によって起動されたデバイス初期化関数でのみ呼び出してください。デバイス初期化関数は、シングル・スレッド C起動コードでのみ呼び出してください。


関連項目 alt_dma_rxchan_close()alt_dma_rxchan_depth()alt_dma_rxchan_ioctl()alt_dma_rxchan_open()alt_dma_rxchan_prepare()alt_dma_txchan_close()alt_dma_txchan_ioctl()alt_dma_txchan_open()alt_dma_txchan_reg()alt_dma_txchan_send()alt_dma_txchan_space()


alt_dma_txchan_close()

プロトタイプ int alt_dma_txchan_close (alt_dma_txchan txchan)





説明 alt_dma_txchan_close() 関数は、アプリケーションが DMA 送信チャネル txchanの使用を完了したことをシステムに通知します。現在の実装は常に成功します。

戻り値戻り値は、成功した場合はゼロ、それ以外は負の値です。

関連項目 alt_dma_rxchan_close()alt_dma_rxchan_depth()alt_dma_rxchan_ioctl()alt_dma_rxchan_open()alt_dma_rxchan_prepare()alt_dma_rxchan_reg()alt_dma_txchan_ioctl()alt_dma_txchan_open()alt_dma_txchan_reg()alt_dma_txchan_send()alt_dma_txchan_space()



alt_dma_txchan_ioctl()

プロトタイプ int alt_dma_txchan_ioctl (alt_dma_txchan dma, int req, void* arg)





説明 alt_dma_txchan_ioctl()関数は、DMA送信チャネル dma上でデバイス固有の I/O 操作を実行します。例えば、一部のドライバは転送操作の幅を制御するオプションをサポートしています。入力引数reqは要求される操作の列挙、argは要求に対する追加引数です。argの解釈は、要求によって異なります。

デバイスがサポートできる一般的な要求については、表 10–1を参照してください。

alt_dma_txchan_iotcl()の呼び出しがスレッド・セーフかどうか、または ISR から呼び出せるかどうかは、デバイスによって決まります。一般には、デバイスに依存しないことを前提とします。

DMA 転送のペンディング中に alt_dma_rxchan_ioctl() 関数を呼び出さないでください。予期できない動作が発生することがあります。

戻り値負の値は失敗を示します。それ以外の場合、戻り値の解釈は要求によって異なります。

関連項目 alt_dma_rxchan_close()alt_dma_rxchan_depth()alt_dma_rxchan_ioctl()alt_dma_rxchan_open()alt_dma_rxchan_prepare()alt_dma_rxchan_reg()alt_dma_txchan_close()alt_dma_txchan_open()alt_dma_txchan_reg()alt_dma_txchan_send()alt_dma_txchan_space()


alt_dma_txchan_open()

プロトタイプ alt_dma_txchan alt_dma_txchan_open (const char* name)





説明 alt_dma_txchan_open()関数は、DMA送信チャネルのalt_dma_txchanディスクリプタを取得します。入力引数 name は、/dev/dma_0 など、関連付けられた物理デバイスの名前です。

戻り値戻り値は、失敗した場合は null、そうでない場合は null 以外の値です。エラーが発生した場合、errnoは ENODEVに設定されます。

関連項目 alt_dma_rxchan_close()alt_dma_rxchan_depth()alt_dma_rxchan_ioctl()alt_dma_rxchan_open()alt_dma_rxchan_prepare()alt_dma_rxchan_reg()alt_dma_txchan_close()alt_dma_txchan_ioctl()alt_dma_txchan_reg()alt_dma_txchan_send()alt_dma_txchan_space()



alt_dma_txchan_reg()

プロトタイプ int alt_dma_txchan_reg (alt_dma_txchan_dev* dev)




インクルード <sys/alt_dma_dev.h>

説明 alt_dma_txchan_reg()関数は、DMA送信チャネルをシステムに登録します。登録が完了すると、4–21 ページの「DMA 送信チャネル」で説明した関数を使用してデバイスにアクセスできます。

チャネルが既存のチャネルと競合する名前で登録された場合、システムの動作は不定になります。

alt_dma_txchan_reg() 関数が呼び出された時点で他のスレッドがチャネル・リストを使用している場合、alt_dma_txchan_reg()関数はスレッド・セーフではありません。alt_dma_txchan_reg()は、シングル・スレッド・モードで動作している間にのみ呼び出してください。alt_sys_init()で起動されたデバイス初期化関数によってのみ呼び出してください。このデバイス初期化関数はシングル・スレッドの C起動コードによってのみ呼び出してください。


関連項目 alt_dma_rxchan_close()alt_dma_rxchan_depth()alt_dma_rxchan_ioctl()alt_dma_rxchan_open()alt_dma_rxchan_prepare()alt_dma_rxchan_reg()alt_dma_txchan_close()alt_dma_txchan_ioctl()alt_dma_txchan_open()alt_dma_txchan_send()alt_dma_txchan_space()


alt_dma_txchan_send()

プロトタイプ int alt_dma_txchan_send (alt_dma_txchan dma, const void* from, alt_u32 length,alt_txchan_done* done, void* handle)





説明 alt_dma_txchan_send() 関数は、DMA 送信チャネルに送信要求を送信します。入力引数 dmaは使用するチャネル、fromは送信するデータの先頭を指し示すポインタ、length は送信するデータのバイト単位の長さ、done はデータが送信されると呼び出されるコールバック関数、handle は done に渡される不定値です。


戻り値戻り値は、要求を送信できない場合は負の値、それ以外はゼロです。

関連項目 alt_dma_rxchan_close()alt_dma_rxchan_depth()alt_dma_rxchan_ioctl()alt_dma_rxchan_open()alt_dma_rxchan_prepare()alt_dma_rxchan_reg()alt_dma_txchan_close()alt_dma_txchan_ioctl()alt_dma_txchan_open()alt_dma_txchan_reg()alt_dma_txchan_space()



alt_dma_txchan_space()

プロトタイプ int alt_dma_txchan_space (alt_dma_txchan dma)





説明 alt_dma_txchan_space()関数は、指定された DMA送信チャネル dmaに送信できる送信要求の最大数を返します。負の戻り値は最大数を決定できないことを示します。


戻り値送信できる転送要求の数を返します。

関連項目 alt_dma_rxchan_close()alt_dma_rxchan_depth()alt_dma_rxchan_ioctl()alt_dma_rxchan_open()alt_dma_rxchan_prepare()alt_dma_rxchan_reg()alt_dma_txchan_close()alt_dma_txchan_ioctl()alt_dma_txchan_open()alt_dma_txchan_reg()alt_dma_txchan_send()


alt_erase_flash_block()

プロトタイプ int alt_erase_flash_block(alt_flash_fd* fd, int offset, int length)




インクルード <sys/alt_flash.h>

説明 alt_erase_flash_block() 関数は、個々のフラッシュ消去ブロックを消去します。パラメータ fd はフラッシュ・デバイスを指定します。offset は消去するブロックのフラッシュ内でのオフセット、length は消去するブロックのサイズです。有効なブロックかどうか、または長さが正しいかどうかを確認するためのエラー・チェックは実行されません（4–18 ページの「高精度フラッシュ・アクセス」を参照）。

alt_erase_flash_block() は、シングル・スレッド・モードで動作しているときにのみ呼び出してください。

fdパラメータの値は、alt_flash_open_dev関数から返された値のみ有効です。その他の値が渡された場合、この関数の動作は不定です。


関連項目 alt_flash_close_dev()alt_flash_open_dev()alt_get_flash_info()alt_read_flash()alt_write_flash()alt_write_flash_block()



alt_flash_close_dev()

プロトタイプ void alt_flash_close_dev(alt_flash_fd* fd)





説明 alt_flash_close_dev() 関数は、フラッシュ・デバイスをクローズします。それ以降は、このフラッシュ・デバイスに対する alt_write_flash()、a l t _ r e a d _ f l a s h ( ) 、a l t _ g e t _ f l a s h _ i n f o ( ) 、alt_erase_flash_block()、および alt_write_flash_block() 呼び出しはすべて失敗します。

alt_flash_close_dev()関数は、シングル・スレッド・モードで動作しているときにのみ呼び出してください。


戻り値 –

関連項目 alt_erase_flash_block()alt_flash_open_dev()alt_get_flash_info()alt_read_flash()alt_write_flash()alt_write_flash_block()


alt_flash_open_dev()

プロトタイプ alt_flash_fd* alt_flash_open_dev(const char* name)





説明 alt_flash_open_dev()関数は、フラッシュ・デバイスをオープンします。オープンしたフラッシュ・デバイスに対しては、alt_write_flash() 関数を使用した書き込みや、alt_read_flash()関数を使用した読み込みが可能です。また個々のフラッシュ・ブロックは、alt_get_flash_info()、alt_erase_flash_block()、または alt_write_flash_block() 関数を使用して制御できます。

alt_flash_open_dev() 関数は、シングル・スレッド・モードで動作しているときにのみ呼び出してください。

戻り値戻り値のゼロは失敗を示します。それ以外の値は成功を示します。

関連項目 alt_erase_flash_block()alt_flash_close_dev()alt_get_flash_info()alt_read_flash()alt_write_flash()alt_write_flash_block()



alt_fs_reg()

プロトタイプ int alt_fs_reg (alt_dev* dev)




インクルード <sys/alt_dev.h>

説明 alt_fs_reg()関数は、ファイル・システムを HALに登録します。登録が完了すると、標準 I/O関数を使用してファイル・システムにアクセスできます（4–1ページの「HALを使用したプログラムの開発」を参照）。

ファイル・システムが、既存のデバイスまたはファイル・システムと競合する名前で登録された場合、システムの動作は不定になります。。

alt_fs_reg() 関数が呼び出された時点で他のスレッドがチャネル・リストを使用している場合、alt_fs_reg() 関数はスレッド・セーフではありません。実際には、alt_fs_reg() は、シングル・スレッド・モードで動作している間にのみ呼び出してください。この関数は alt_sys_init()で起動されたデバイス初期化関数によってのみ呼び出され、このデバイス初期化関数はシングル・スレッドの C起動コードによってのみ呼び出されることを想定しています。


関連項目 alt_dev_reg()


alt_get_flash_info()

プロトタイプ int alt_get_flash_info(alt_flash_fd* fd, flash_region** info, int* number_of_regions)





説明 alt_get_flash_info() 関数は、フラッシュ部分の消去領域の詳細情報を取得します。フラッシュ部分は識別子 fdによって指定され、flash_region構造体の開始位置へのポインタは info パラメータ内に返され、さらにフラッシュ領域の数は、number_of_regionsに返されます。

この関数は、シングル・スレッド・モードで動作しているときにのみ呼び出してください。



関連項目 alt_erase_flash_block()alt_flash_close_dev()alt_flash_open_dev()alt_read_flash()alt_write_flash()alt_write_flash_block()



alt_icache_flush()

プロトタイプ void alt_icache_flush (void* start, alt_u32 len)





説明 alt_icache_flush() 関数は、アドレス start から始まる長さ len バイトのメモリ領域の命令キャッシュを無効化します。

命令キャッシュのないプロセッサでは、効果はありません。

戻り値 –

関連項目 alt_dcache_flush()alt_dcache_flush_all()alt_icache_flush_all()#alt_remap_cached()alt_remap_uncached()alt_uncached_free()alt_uncached_malloc()


alt_icache_flush_all()

プロトタイプ void alt_icache_flush_all (void)





説明 alt_icache_flush_all()関数は、命令キャッシュのすべての内容を無効化します。

命令キャッシュのないプロセッサでは、効果はありません。

戻り値 –

関連項目 alt_dcache_flush()alt_dcache_flush_all()alt_icache_flush()#alt_remap_cached()alt_remap_uncached()alt_uncached_free()alt_uncached_malloc()



alt_irq_disable_all()

プロトタイプ alt_irq_context alt_irq_disable_all (void)




インクルード <sys/alt_irq.h>

説明 alt_irq_disable_all()関数はすべての割り込みをディセーブルします。

戻り値これに続く alt_irq_enable_all()呼び出しに、戻り値を入力引数として渡します。

関連項目 alt_irq_enable_all()alt_irq_enabled()alt_irq_register()


alt_irq_enable_all()

プロトタイプ void alt_irq_enable_all (alt_irq_context context)





説明 alt_irq_enable_all() 関数はすべての割り込みをイネーブルします。入力引数 context は、直前の alt_irq_disable_all() の呼び出しによって返された値です。割り込みは、関連する alt_irq_disable_all() の呼び出しが割り込みをディセーブルした場合にのみイネーブルされるため、ネストした alt_irq_disable_all()または alt_irq_enable_all()の呼び出しを正しく実行することができます。

戻り値 –

関連項目 alt_irq_disable_all()alt_irq_enabled()alt_irq_register()



alt_irq_enabled()

プロトタイプ int alt_irq_enabled (void)





説明 alt_irq_enabled()関数。

戻り値割り込みがディセーブルされた場合はゼロを返し、そうでない場合はゼロ以外の値を返します。

関連項目 alt_irq_disable_all()alt_irq_enable_all()alt_irq_register()


alt_irq_register()

プロトタイプ int alt_irq_register (alt_u32 id, void* context, void (*isr)(void*, alt_u32))





説明 alt_irq_register()関数は ISRを登録します。この関数が成功すると、要求された割り込みは関数の戻り時にイネーブルになります。入力引数 id はイネーブルする割り込み、isr は割り込みがアクティブなときに呼び出される関数、contextおよび idは isrの引数です。

alt_irq_register()が呼び出されると、登録された割り込み idのハンドラと置き換わります。

irq_handlerが nullに設定されている場合、割り込みはディセーブルされます。

戻り値 alt_irq_register()関数は、成功した場合はゼロを返し、そうでない場合はゼロ以外の値を返します。

関連項目 alt_irq_disable_all()alt_irq_enable_all()alt_irq_enabled()



alt_llist_insert()

プロトタイプ void alt_llist_insert(alt_llist* list, alt_llist* entry)




インクルード <sys/alt_llist.h>

説明 alt_llist_insert()関数は、二重のリンク・リスト・エントリ entryをリスト list に挿入します。これは、リエントリ操作できません。例えば、リストが他のスレッドから操作される、またはアプリケーション・コードと ISRの両方から操作される可能性がある場合、リストへのアクセスを保護する何らかのメカニズムが必要です。割り込みはロックすることができ、またMicroC/OS-IIでは mutexが使用できます。

戻り値 –

関連項目 alt_llist_remove()


alt_llist_remove()

プロトタイプ void alt_llist_remove(alt_llist* entry)




インクルード <sys/alt_llist.h>

説明 alt_llist_remove()関数は、二重のリンク・リスト・エントリ entryを、現在そのエントリがメンバであるリストから除去します。これは、リエントリ操作できません。例えば、リストが他のスレッドから操作される、あるいはアプリケーション・コードと ISRの両方から操作される可能性がある場合、リストへのアクセスを保護する何らかのメカニズムが必要です。割り込みはロックすることができ、また MicroC/OS-IIでは mutexが使用できます。

戻り値 –

関連項目 alt_llist_insert()



alt_nticks()

プロトタイプ alt_u32 alt_nticks (void)





説明 alt_niticks()関数。

戻り値リセット時点から経過したシステム・クロック・チック数を返します。システム・クロックが利用できない場合はゼロを返します。

関連項目 alt_alarm_start()alt_alarm_stop()alt_sysclk_init()alt_tick()alt_ticks_per_second() gettimeofday()settimeofday()times()usleep()


alt_read_flash()

プロトタイプ int alt_read_flash(alt_flash_fd* fd, int offset, void* dest_addr, int length)





説明 alt_read_flash() 関数はフラッシュからデータを読み出します。フラッシュ fd から length バイト（フラッシュの先頭から offset バイト）が読み込まれ、dest_addr位置に書き込まれます。



戻り値戻り値は、成功した場合はゼロ、そうでない場合はゼロ以外の値です。

関連項目 alt_erase_flash_block()alt_flash_close_dev()alt_flash_open_dev()alt_get_flash_info()alt_write_flash()alt_write_flash_block()



alt_remap_cached()

プロトタイプ void* alt_remap_cached (volatile void* ptr, alt_u32 len);





説明 alt_remap_cached()関数は、キャッシュ・アクセスのためのメモリ領域を再マップします。マップするメモリは、アドレス ptrから lenバイトです。

データ・キャッシュのないプロセッサは、非キャッシュ・メモリを返します。

戻り値この関数の戻り値は再マップされたメモリ領域です。

関連項目 alt_dcache_flush()alt_dcache_flush_all()alt_icache_flush()alt_icache_flush_all()#alt_remap_uncached()alt_uncached_free()alt_uncached_malloc()


alt_remap_uncached()

プロトタイプ volatile void* alt_remap_uncached (void* ptr, alt_u32 len);





説明 alt_remap_uncached() 関数は、非キャッシュ・アクセスのためのメモリ領域を再マップします。マップするメモリは、アドレス ptr から len バイトです。


戻り値この関数の戻り値は、再マップされたメモリ領域です。

関連項目 alt_dcache_flush()alt_dcache_flush_all()alt_icache_flush()alt_icache_flush_all()#alt_remap_cached()alt_uncached_free()alt_uncached_malloc()



alt_sysclk_init()

プロトタイプ int alt_sysclk_init (alt_u32 nticks)





説明 alt_sysclk_init()関数は、システム・クロック・ドライバを登録します。入力引数は、システム・クロック動作時の 1秒あたりのクロック数です。

この関数は、alt_sys_init()から、つまりシステムがシングル・スレッド・モードで動作している間にのみ呼び出されると想定されます。この関数を同時に呼び出すと、予測できない結果になることがあります。

戻り値この関数は、成功した場合はゼロを返し、それ以外は負の値を返します。システム・クロック・ドライバが既に登録されている場合、呼び出しは失敗します。

関連項目 alt_alarm_start()alt_alarm_stop()alt_nticks()alt_tick()alt_ticks_per_second() gettimeofday()settimeofday()times()usleep()


alt_tick()

プロトタイプ void alt_tick (void)





説明システム・クロック・ドライバしか alt_tick() 関数を呼び出してはなりません。ドライバは、alt_sysclk_init()の呼び出しで指定されたレートで、周期的にこの関数を呼び出す必要があります。この関数は、システム・クロック・チックが発生したことをシステムに通知します。この関数は、システム・クロック・ドライバに対する ISRの一部として動作します。

戻り値 –

関連項目 alt_alarm_start()alt_alarm_stop()alt_nticks()alt_sysclk_init()alt_ticks_per_second() gettimeofday()settimeofday()times()usleep()



alt_ticks_per_second()

プロトタイプ alt_u32 alt_ticks_per_second (void)





説明 alt_ticks_per_second() 関数は、1 秒ごとに経過するシステム・クロック・チック数を返します。システム・クロックが利用できない場合、戻り値はゼロです。

戻り値 1秒ごとに経過するシステム・クロック・チック数を返します。

関連項目 alt_alarm_start()alt_alarm_stop()alt_nticks()alt_sysclk_init()alt_tick()gettimeofday()settimeofday()times()usleep()


alt_timestamp()

プロトタイプ alt_u32 alt_timestamp (void)

一般的な呼び出し元 C/C++プログラム



インクルード <sys/alt_timestamp.h>

説明 alt_timestamp() 関数は、タイムスタンプ・カウンタの現在の値を返します（4–12ページの「高精度時間測定」を参照）。この関数は、タイムスタンプ・ドライバによって実行されます。したがって、この関数がスレッド・セーフかどうか、割り込みレベルで利用できるかどうかは、基本ドライバによって決まります。

alt_timestamp_start()関数は、必ず alt_timestamp()を呼び出す前に呼び出してください。そうしない場合、alt_timestamp()の動作は不定になります。

戻り値タイムスタンプ・カウンタの現在の値を返します。

関連項目 alt_timestamp_freq()alt_timestamp_start()



alt_timestamp_freq()

プロトタイプ alt_u32 alt_timestamp_freq (void)





説明 alt_timestamp_freq()関数は、タイムスタンプ・カウンタが増加するレートを返します（4–12 ページの「高精度時間測定」を参照）。この関数は、タイムスタンプ・ドライバによって実行されます。したがって、この関数がスレッド・セーフかどうか、割り込みレベルで利用できるかどうかは、基本ドライバによって決まります。

戻り値戻り値は 1秒あたりのカウンタ・チック数です。

関連項目 alt_timestamp()alt_timestamp_start()


alt_timestamp_start()

プロトタイプ int alt_timestamp_start (void)





説明 alt_timestamp_start()関数はシステム・タイムスタンプ・カウンタを開始します（4–12 ページの「高精度時間測定」を参照）。この関数は、タイムスタンプ・ドライバによって実行されます。したがって、この関数がスレッド・セーフかどうか、割り込みレベルで利用できるかどうかは、基本ドライバによって決まります。

この関数はカウンタをゼロにリセットして、カウンタの動作を開始します。


関連項目 alt_timestamp()alt_timestamp_freq()



alt_uncached_free()

プロトタイプ void alt_uncached_free (volatile void* ptr)





説明 alt_uncached_free()関数を実行すると、ptrが示すメモリが割り当て解除されます。すなわち、alt_uncached_malloc()呼び出しによってメモリ割り当てが可能になります。入力ポインタ ptrは、以前に alt_uncached_malloc()呼び出しによって割り当てられたメモリの領域を指します。そうでない場合、動作は不定です。

戻り値 –

関連項目 alt_dcache_flush()alt_dcache_flush_all()alt_icache_flush()alt_icache_flush_all()#alt_remap_cached()alt_remap_uncached()alt_uncached_malloc()


alt_uncached_malloc()

プロトタイプ volatile void* alt_uncached_malloc (size_t size)





説明 alt_uncached_malloc() 関数は、長さ size バイトの非キャッシュ・メモリ領域を割り当てます。これにより割り当てられたメモリの領域は、alt_uncached_free()関数を使用して解放できます。


戻り値この関数は、十分なメモリを割り当てできない場合は null を返し、それ以外は割り当てた空間へのポインタを返します。

関連項目 alt_dcache_flush()alt_dcache_flush_all()alt_icache_flush()alt_icache_flush_all()#alt_remap_cached()alt_remap_uncached()alt_uncached_free()



alt_write_flash()

プロトタイプ int alt_write_flash(alt_flash_fd* fd, int offset, const void* src_addr, int length)





説明 alt_write_flash() 関数はデータをフラッシュに書き込みます。書き込まれるデータは src_addr アドレスにあり、length バイト分のデータがフラッシュ fd（フラッシュの先頭から offsetバイト）に書き込まれます。

この関数はシングル・スレッド・モードで動作しているときにのみ呼び出してください。この関数は、この書き込みによってフラッシュ・セクタの非書き込み領域が影響を受ける場合でも、その領域の内容を保存しません（4–15ページの「シンプル・フラッシュ・アクセス」を参照）。



関連項目 alt_erase_flash_block()alt_flash_close_dev()alt_flash_open_dev()alt_get_flash_info()alt_read_flash()alt_write_flash_block()


alt_write_flash_block()

プロトタイプ int alt_write_flash_block(alt_flash_fd* fd, int block_offset,int data_offset,const void *data, int length)





説明 alt_write_flash_block() 関数は、フラッシュの 1 つの消去ブロックに書き込みます。フラッシュ・デバイスは fdで指定され、block_offsetはフラッシュ内におけるこのブロックの先頭位置のオフセット、data_offset はフラッシュ内でデータの書き込みを開始する位置のオフセット、data は書き込むデータ、length は書き込むデータ量です。どのパラメータにもチェックが行われないことに注意してください（4–18ページの「高精度フラッシュ・アクセス」を参照）。




関連項目 alt_erase_flash_block()alt_flash_close_dev()alt_flash_open_dev()alt_get_flash_info()alt_read_flash()alt_write_flash()



close()

プロトタイプ int close (int filedes)

一般的な呼び出し元 C/C++プログラムNewlib Cライブラリ




説明 close() 関数は、ファイル・ディスクリプタ filedes をクローズする標準UNIX形式の close()関数です。

操作対象のドライバが提供する close() の実装がスレッド・セーフである場合のみ、close()呼び出しはスレッド・セーフになります。

fd パラメータの有効な値は、STDOUT_FILENO、STDIN_FILENO、およびSTDERR_FILENO、または open()呼び出しから返された値です。定数STDOUT_FILENO、STDIN_FILENO、および STDERR_FILENOは、<unistd.h>で定義されています。

戻り値戻り値は、成功した場合はゼロ、それ以外は –1 です。エラーが発生した場合、errnoはエラーの原因を示す値に設定されます。



execve()

プロトタイプ int execve(const char *path, char *const argv[], char *const envp[])





説明 execve()関数は、Newlibとの互換性を確保するためだけに提供されています。

戻り値 execve()呼び出しは、常にリターン・コード –1で、errnoを ENOSYSに設定して失敗します。




fork()

プロトタイプ pid_t fork (void)





説明 fork()関数は、Newlibとの互換性を確保するためだけに提供されています。

戻り値 fork()呼び出しは、常にリターン・コード –1で、errnoを ENOSYSに設定して失敗します。



fstat()

プロトタイプ int fstat (int filedes, struct stat *st)




インクルード <sys/stat.h>

説明 fstat()関数は、オープン・ファイル・ディスクリプタの機能に関する情報を取得します。基本デバイス・ドライバは、入力 st 構造体にその機能に関する情報を入れます。利用可能なオプションについては、コンパイラとともに提供されるヘッダ・ファイル sys/stat.hを参照してください。

基本ドライバが fstat() 関数の独自の実装を提供しない場合、デフォルトではファイル・ディスクリプタはキャラクタ・デバイスとしてマークされます。

操作対象のドライバが提供する fstat() の実装がスレッド・セーフである場合のみ、fstat()呼び出しはスレッド・セーフになります。

fdパラメータに対する有効な値は、STDOUT_FILENO、STDIN_FILENO、および STDERR_FILENO、または open() 呼び出しから返された値です。定数STDOUT_FILENO、STDIN_FILENO、および STDERR_FILENOは、<unistd.h>で定義されています。

戻り値戻り値は、成功した場合はゼロ、それ以外は –1です。呼び出しが失敗した場合、errnoはエラーの原因を示す値に設定されます。

関連項目 close()ioctl()isatty()lseek()open()read()stat()write()Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。



getpid()

プロトタイプ pid_t getpid (void)





説明 getpid()関数は、Newlibとの互換性を確保するために用意されており、現在のプロセス idを取得します。

戻り値 HALシステムは複数のプロセスを含むことができないため、getpid()は常に同じ id番号を返します。



gettimeofday()

プロトタイプ int gettimeofday(struct timeval *ptimeval, struct timezone *ptimezone)




インクルード <sys/time.h>

説明 gettimeofday() 関数は、現在のウォール・クロック・タイムを示す時間構造体を取得します。この時刻は、システム・クロック・チックの経過数、および最新のsettimeofday()呼び出しによって設定された現在の時刻を使用して計算されます。

この関数が、settimeofday()呼び出しと同時に呼び出された場合、gettimeofday() が返す値の信頼性は低くなりますが、gettimeofday()は同時に呼び出しても問題ありません。


関連項目 alt_alarm_start()alt_alarm_stop()alt_nticks()alt_sysclk_init()alt_tick()alt_ticks_per_second() settimeofday()times()usleep()Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。



ioctl()

プロトタイプ int ioctl (int file, int req, void* arg)




インクルード <sys/ioctl.h>

説明 ioctl()関数を使用すれば、アプリケーション・コードから、デバイス・ドライバの I/O機能をドライバ固有の方法で操作できます。この関数は、UNIXの標準 ioctl() 関数に相当します。入力引数 file は操作するデバイスのオープン・ファイル・ディスクリプタ、req は操作要求を定義する列挙です。またargの解釈は、要求によって異なります。

一般に、この実装では、要求を適切なドライバ ioctl() 関数（ドライバのalt_dev構造体での登録に従って）に振り分けます。ただし、デバイスの場合（ファイル・サブシステムとは異なり）、TIOCEXCL要求と TIOCNXCL要求は、ドライバを参照しないで処理されます。これらの要求は、デバイスを排他的アクセスに対してロックおよびリリースします。

操作対象のドライバが提供する ioctl() の実装がスレッド・セーフである場合のみ、ioctl()呼び出しはスレッド・セーフになります。


戻り値戻り値の解釈は要求によって異なります。呼び出しが失敗した場合、errnoはエラーの原因を示す値に設定されます。

関連項目 close()fstat()isatty()lseek()open()read()stat()write()Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。


isatty()

プロトタイプ int isatty(int file)





説明 isatty()関数は、オープン・ファイル・ディスクリプタ fileに関連付けられたデバイスが、ターミナル・デバイスかどうかを判断します。この実装では、ドライバ fstat()関数を使用してその応答を判断します。

操作対象のドライバが提供する fstat() の実装がスレッド・セーフである場合のみ、isatty()呼び出しはスレッド・セーフになります。

戻り値戻り値は、デバイスがキャラクタ・デバイスの場合は 1、それ以外はゼロです。エラーが発生した場合、errnoはエラーの原因を示す値に設定されます。

関連項目 close()fstat()ioctl()lseek()open()read()stat()write()Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。



kill()

プロトタイプ int kill(int pid, int sig)




インクルード <signal.h>

説明 kill() 関数は、プロセスにシグナルを送信するために Newlib が使用します。入力引数 pidはシグナルを送信するプロセスの id、sigは送信するシグナルです。HALにはプロセスが 1つしか存在しないため、pidに対して有効な値は、getpid() で返される現在のプロセス id、またはブロードキャスト値のみです。つまり、pidはゼロ以下でなければなりません。

シグナル SIGABRT、SIGALRM、SIGFPE、SIGILL、SIGKILL、SIGPIPE、SIGQUIT、SIGSEGV、SIGTERM、SIGUSR1、SIGUSR2、SIGBUS、SIGPOLL、SIGPROF、SIGSYS、SIGTRAP、SIGVTALRM、SIGXCPU、または SIGXFSZが発生すると、システムは exit()を呼び出すことなく、すぐにシャットダウンします。

シグナル SIGCHLDおよび SIGURGは無視されます。

その他のシグナルはすべてエラーとして扱われます。




link()

プロトタイプ int link(const char *_path1, const char *_path2)





説明 link()関数は、Newlibとの互換性を確保するためだけに提供されています。

戻り値 link()呼び出しは、常にリターン・コード –1で、errnoを ENOSYSに設定して失敗します。




lseek()

プロトタイプ off_t lseek(int file, off_t ptr, int whence)





説明 lseek() 関数は、ファイル・ディスクリプタ file に関連付けられた読み出し / 書き込みポインタを移動します。この関数は、ファイル・ディスクリプタに関連付けられたドライバが提供する lseek() 関数に呼び出しを振り分けます。ドライバが lseek()の実装を提供しない場合は、エラーになります。

lseek()は、UNIXの標準 lseek()関数に相当します。

入力パラメータ whenceに対して、次の値が使用できます。

● whenceの値● インタプリテイション● SEEK_SET－オフセットが ptrバイトに設定されます。● SEEK_CUR－オフセットが ptrバイトだけ増加されます。● SEEK_END－オフセットがファイルの終端から ptrバイト加えた位置に設定されます。

操作対象のドライバが提供する lseek() の実装がスレッド・セーフである場合のみ、lseek()呼び出しはスレッド・セーフになります。

fd パラメータに対する有効な値は、STDOUT_FILENO、STDIN_FILENO、および STDERR_FILENO、または open() 呼び出しで返された値です。定数 STDOUT_FILENO、STDIN_FILENO、および STDERR_FILENOは、<unistd.h>で定義されています。

戻り値成功した場合、戻り値は負でないファイル・ポインタです。エラーが発生した場合、戻り値は –1 です。呼び出しが失敗した場合、errno はエラーの原因を示す値に設定されます。

関連項目 close()fstat()ioctl()isatty()open()read()stat()write()Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。


open()

プロトタイプ int open (const char* pathname, int flags, mode_t mode)





説明 open() 関数は、ファイルまたはデバイスをオープンし、ファイル・ディスクリプタ（読み出し、書き込みなどに使用する負でない小さな整数）を返します。

flagは、それぞれリード・オンリ、ライト・オンリ、リード /ライトでファイルのオープンを要求する O_RDONLY、O_WRONLY、O_RDWRのいずれかです。

ビット単位の ORフラグを O_NONBLOCKと組み合わせて、ファイルを非ブロック・モードでオープンすることもできます。返されたファイル・ディスクリプタに対する open()操作または後続の操作によって、呼び出し中のプロセスが待機することはありません。

必ずしもすべてのファイル・システム / デバイスが、このオプションを認識しないことに注意してください。

mode は、新規ファイルが作成された場合に使用許可を指定します。これは現在のファイル・システムでは使用されていませんが、互換性のために維持されています。

操作対象のドライバが提供する open()の実装がスレッド・セーフである場合のみ、open()呼び出しはスレッド・セーフになります。

戻り値戻り値は、成功した場合は新しいファイル・ディスクリプタ、それ以外は -1です。エラーが発生した場合、errnoはエラーの原因を示す値に設定されます。

関連項目 close()fstat()ioctl()isatty()lseek()read()stat()write()Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。



read()

プロトタイプ int read(int file, void *ptr, size_t len)





説明 read() 関数は、ファイルまたはデバイスからデータのブロックを読み出します。この関数は、入力のオープン・ファイル・ディスクリプタ file に関連付けられたデバイス・ドライバに要求を振り分けます。入力引数 ptrは読み込まれたデータを格納する位置、lenは読み込むデータのバイト長です。

操作対象のドライバが提供する read()の実装がスレッド・セーフである場合のみ、read()呼び出しはスレッド・セーフになります。


戻り値戻り引数は読み込まれたバイト数ですが、これは要求した長さより短い場合もあります。

戻り値の –1 はエラーを示します。エラーが発生した場合、errno はエラーの原因を示す値に設定されます。

関連項目 close()fstat()ioctl()isatty()lseek()open()stat()write()Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。


sbrk()

プロトタイプ caddr_t sbrk(int incr)





説明 sbrk()関数は、アプリケーションのデータ・セグメントを動的に拡張します。入力引数 incrは、割り当てるブロックのサイズです。sbrk()は直接呼び出さないでください。メモリを動的に割り当てる場合は、malloc()関数を使用します。

戻り値 –




settimeofday()

プロトタイプ int settimeofday (const struct timeval *t, const struct timezone *tz)




インクルード <sys/time.h>

説明 settimeofday()関数が gettimeofday()と同時に呼び出された場合、gettimeofday()が返す値の信頼性は低下します。

戻り値戻り値は、成功した場合はゼロ、それ以外は –1です。現在の実装は常に成功します。

関連項目 alt_alarm_start()alt_alarm_stop()alt_nticks()alt_sysclk_init()alt_tick()alt_ticks_per_second() gettimeofday()times()usleep()


stat()

プロトタイプ int stat(const char *file_name, struct stat *buf);




インクルード <sys/stat.h>

説明 stat() 関数は、fstat() 関数と同様に、ファイルに関するステータス情報を取得します。fstat()のように、オープン・ファイル・ディスクリプタを使用する代わりに、stat()はファイルの名前を入力引数として受け取ります。

操作対象のドライバが提供する stat()の実装がスレッド・セーフである場合のみ、stat()呼び出しはスレッド・セーフになります。

内部では、stat()関数は fstat()呼び出しとして実行されます（10–52ページの「fstat()」を参照）。

戻り値 –

関連項目 close()fstat()ioctl()isatty()lseek()open()read()write()Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。



times()

プロトタイプ clock_t times (struct tms *buf)




インクルード <sys/times.h>

説明 times() 関数は、Newlib との互換性を確保するために提供されています。リセット後のクロック・チック数を返します。さらに、入力引数 bufが示す構造体に時間計算に関する情報を格納します。tms 構造体の定義は以下のとおりです。

typedef struct {

clock_t tms_utime;clock_t tms_stime;clock_t tms_cutime;clock_t tms_cstime;

};この構造体には次の要素が含まれています。

● tms_utime:ユーザ命令の実行に要した CPU時間● tms_stime:プロセスに代わってシステムが実行に要した CPU時間● tms_cutime:子プロセスのすべての tms_utimeおよび tms_cutimeの合計

● tms_cstime:子プロセスの tms_stimesおよび tms_ctimesの合計

実際には、すべての経過時間はシステム時間として計算されます。ユーザ時間として考慮される時間はありません。また、子プロセスは HALから生成できないため、子プロセスに時間は割り当てられません。

戻り値システム・クロックが利用できない場合、戻り値はゼロです。

関連項目 alt_alarm_start()alt_alarm_stop()alt_nticks()alt_sysclk_init()alt_tick()alt_ticks_per_second() gettimeofday()settimeofday()usleep()Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。


unlink()

プロトタイプ int unlink(char *name)





説明 unlink()関数は、Newlibとの互換性を確保するためだけに提供されています。

戻り値 unlink()呼び出しは、常にリターン・コード –1で、errnoを ENOSYSに設定して失敗します。




usleep()

プロトタイプ int usleep (int us)





説明 usleep()関数は、usマイクロ秒単位で実行を遅延します。

戻り値 usleep()関数は、成功した場合はゼロ、それ以外は –1を返します。エラーが発生した場合、errnoはエラーの原因を示す値に設定されます。現在の実装は常に成功します。

関連項目 alt_alarm_start()alt_alarm_stop()alt_nticks()alt_sysclk_init()alt_tick()alt_ticks_per_second() gettimeofday()settimeofday()times()


wait()

プロトタイプ int wait(int *status)




インクルード <sys/wait.h>

説明 Newlibは、wait()関数を使用して、すべての子プロセスが終了するのを待ちます。HAL は子プロセスの生成をサポートしていないため、この関数はすぐに復帰します。

戻り値復帰すると、status の内容はゼロに設定され、子プロセスが存在しないことを示します。

戻り値は常に –1になり、errnoは ECHILDに設定され、待機する子プロセスが存在しないことを示します。




write()

プロトタイプ int write(int file, const void *ptr, size_t len)





説明 write() 関数は、ファイルまたはデバイスにデータのブロックを書き込みます。この関数は、要求を入力のファイル・ディスクリプタ file に関連付けられたデバイス・ドライバに振り分けます。入力引数 ptrは書き込むデータ、lenはデータのバイト長です。

操作対象のドライバが提供する write() の実装がスレッド・セーフである場合のみ、write()呼び出しはスレッド・セーフになります。


戻り値戻り引数は書き込まれたバイト数ですが、これは要求した長さより短い場合もあります。

戻り値の –1 はエラーを示します。エラーが発生した場合、errno はエラーの原因を示す値に設定されます。

関連項目 close()fstat()ioctl()isatty()lseek()open()read()stat()Newlib の資料。（Windows のスタート・メニューから）プログラム > Altera >Nios II Development Kit > Nios II Documentationの順にクリックしてください。


標準型移植性を高めるために、HALは ANSI C組み込み型の代わりに標準型定義のセットを使用しています。表 10–2に、ヘッダ alt_types.hで定義されるこれらの型を示します。

表 10–2.標準型

型説明








11. アルテラの開発ツール

はじめにこの章では、アルテラが Nios® IIプロセッサ用に提供するすべての開発ツールを紹介します。これらのツールは、次のカテゴリに分類されます。

■ Nios II統合開発環境（IDE）および関連ツール■ アルテラのコマンドライン・ツール■ GNUコンパイラ・ツール・チェイン■ ライブラリおよびエンベデッド・ソフトウェア・コンポーネント

この章では、これらのツールの詳細な使用方法については説明せず、最適な資料を紹介します。

Nios II IDEツール

表 11–1は、Nios II IDEユーザ・インタフェースで提供されるツールを説明しています。

表 11–1. Nios II IDEおよび関連ツール (１ /２ )

ツール機能説明

Nios II IDE Nios II IDEは Nios IIプロセッサ用ソフトウェア開発ユーザ・インタフェースです。プログラムの編集、構築、デバッグなど、すべてのソフトウェア開発作業を IDE内で行うことができます。詳細については、Nios II IDEオンライン・ヘルプ・システムを参照してください。

Flash Programmer Nios II IDEには、ターゲット・ボード上のフラッシュ・メモリ・チップのプログラミングを可能にする Flash Programmerユーティリティが用意されています。Flash Programmerは、アルテラの開発ボードやユーザ独自のカスタム・ボードを含むあらゆるボード上のフラッシュのプログラミングをサポートします。Flash Programmer は、フラッシュに以下のコードやデータを簡単にプログラミングできます。

● 実行可能コードおよびデータ● フラッシュから RAMにコードをコピーし、RAMから実行するためのブートストラップ・コード

● HALファイル・サブシステム● FPGAハードウェア・コンフィギュレーション・データ詳細については、「Nios II Flash Programmer User Guide」を参照してください。

NII520011-1.1

myoshida

Text Box



アルテラのコマンドライン・ツール


ここでは、アルテラが提供するコマンドライン・ツールについて説明します。これらのツールを Nios II Software Development Kit (SDK) Shellコマンド・プロンプトから実行して、例えばコンパイル作業を自動化するためのスクリプトを書くことができます。アルテラのコマンドライン・ツールは、<Nios II インストール・パス >/bin/ ディレクトリに格納されています。

各ツールは、コマンドラインからアクセスできるヘルプ・ページ形式の独自の資料を提供します。ヘルプを表示するには、Nios II SDK Shellを開いて、以下のコマンドを入力します。

<ツール名 > --help

表 11–2に、Nios II IDEグラフィカル・ユーザ・インタフェース（GUI）を起動せずにNios II IDEプロジェクトの作成とビルドを行うコマンドライン・ユーティリティを示します。これらのユーティリティによって、コマンドライン・スクリプトを使用してNios II IDEの処理を自動化できます。例えば、これらのユーティリティを利用すると、スクリプトでソース・コントロールからNios II IDEプロジェクトを点検し、プロジェクトをNios II IDEのワークスペースにインポートして、プロジェクトをビルドすることができます。

これらのユーティリティのそれぞれが GUIを表示せずに、バックグラウンドでNios II IDEを起動します。一度にアクティブにできる Nios II IDEのインスタンスは 1つに限られるため、IDEが動作している間はこれらのユーティリティを使用できません。

インストラクション・セット・シミュレータ

アルテラは Nios IIプロセッサ用インストラクション・セット・シミュレータ（ISS）を提供します。ISSは Nios II IDE内で使用でき、ISSでのプログラムの実行およびデバッグ・プロセスは、ターゲット・ハードウェア上での実行およびデバッグ・プロセスと同じです。詳細については、Nios II IDEオンライン・ヘルプ・システムを参照してください。

Quartus IIプログラマ

Quartus IIプログラマは、Quartus IIソフトウェアの一部ですが Nios II IDEから直接起動できます。Quartus II プログラマを使用して、新しい FPGA コンフィギュレーション・ファイルをボードにダウンロードすることができます。詳細については、Nios II IDEオンライン・ヘルプ・システムを参照するか、または Quartus IIプログラマが開いているときに [F1]キーを押してください。

表 11–1. Nios II IDEおよび関連ツール (２ /２ )



アルテラの開発ツール

表 11–3 に、Nios II プログラム開発用にアルテラが提供するその他のコマンドライン・ツールを示します。

表 11–2. Nios II IDEコマンドライン・ツール


nios2-create-system-library 新しいシステム・ライブラリ・プロジェクトを作成します。

nios2-create-application-project 新しいC/C++アプリケーション・プロジェクトを作成します。

nios2-build-project Nios II IDE managed-make機能を使用して、プロジェクトをビルドします。makefileを作成または更新してプロジェクトをビルドし、任意にmakeを実行します。nios2-build-projectは、現在のNios II IDEのワークスペースに存在するプロジェクト上でのみ動作します。

nios2-import-project 以前に作成した Nios II IDE プロジェクトを現在のワークスペースにインポートします。

nios2-delete-project Nios II IDEのワークスペースからプロジェクトを削除し、任意にファイル・システムからファイルを削除します。

表 11–3.アルテラのコマンドライン・ツール


nios2-download デバッグまたは実行のために、ターゲット・プロセッサにコードをダウンロードします。

nios2-flash-programmer ターゲット・ボード上のフラッシュ・メモリにデータをプログラムします。

nios2-gdb-server ターゲットの Nios II プロセッサを使用し、TCP 経由で GNU デバッガ（GDB）リモート・シリアル・プロトコル・パケットを JTAG（Joint TestAction Group）トランザクションに変換します。

nios2-terminal Nios IIシステムの JTAG UART（Universal Asynchronous Receiver/Transmitter）で端末 I/Oを実行します。

validate_zip 指定された zipファイルが、アルテラのリード・オンリ zipファイル・システムと互換性があるかどうかを検証します。



あるユーティリティから別のユーティリティにデータを渡すときに、ファイル・フォーマットの変換が必要になる場合があります。表 11–4に、ファイル・フォーマットを変換するためのアルテラが提供するユーティリティを示します。

表 11–5に、第 1 世代の Niosプロセッサ SDK およびツール・フローとの下位互換性をサポートする、アルテラのツールを示します。

詳細については、「 AN 350: Upgrading Nios Processor Systems to theNios II Processor」を参照してください。

表 11–4.ファイル変換ユーティリティ

ユーティリティ機能説明

bin2flash バイナリ・ファイルをフラッシュ・メモリにプログラムするために、.flashファイルに変換します。

elf2dat .elf 実行可能ファイル・フォーマットを、Verilog HDL ハードウェア・シミュレータに適した .datファイル・フォーマットに変換します。

elf2flash .elf実行可能ファイルをフラッシュ・メモリにプログラムするために、.flash ファイルに変換します。

elf2hex .elf実行可能ファイルを Intel .hexファイル・フォーマットに変換します。

elf2mem 特定の Nios IIシステム内のメモリ・デバイス用のメモリ内容を生成します。

elf2mif .elf実行可能ファイルを Quartus IIメモリ初期化ファイル (.mif)フォーマットに変換します。

flash2dat .flash ファイルを、Verilog HDL ハードウェア・シミュレータに適した .dat ファイル・フォーマットに変換します。

mk-nios2-signaltap-mnemonic-table

.elfファイルと SOPC Builderのシステム・ファイル (.ptf)を取り込み、Nios II命令のニーモニック・テーブルとアルテラの SignalTap® II ロジック・アナライザ用のシンボルを含む .stpファイルを作成します。

sof2flash FPGAのコンフィギュレーション・ファイル（.sof）を、フラッシュ・メモリにプログラムするための .flashファイルに変換します。

表 11–5.下位互換性サポート・ツール (１ /２ )


nios2-build レガシー SDK ライブラリに基づき、ソフトウェア・プロジェクトをコンパイルおよびリンクします。

nios2-run プログラムを Nios IIプロセッサにダウンロードし、プログラムに対して端末 I/Oを実行します。


アルテラの開発ツール

GNUコンパイラ・ツール・チェイン

アルテラはNios IIプロセッサ用標準 GNUコンパイラ・ツール・チェインを提供し、サポートしています。GNUツールに関する HTMLの資料一式は、Nios IIインストール・ディレクトリにあります。GNUツールは、<Nios IIインストール・パス >/bin/nios2-gnutoolsディレクトリに格納されています。

Nios IIプロセッサ用 GNUツールの名前は、一般にnios2-elf-<ツール名 >になります。以下にいくつかの例を示します。

■ nios2-elf-gcc■ make■ nios2-elf-as■ nios2-elf-ld■ nios2-elf-objdump■ nios2-elf-size

完全なリストについては、GNU HTMLの資料を参照してください。

ライブラリおよびエンベデッド・ソフトウェア・コンポーネント

表 11–6 に、Nios II 開発キット・ライブラリとソフトウェア・コンポーネントを示します。

nios2-debug プログラムを Nios IIプロセッサにダウンロードし、Insightデバッガを起動します。

nios2-console FS2コマンドライン・インタフェース（CLI）を開いて、Nios IIプロセッサに接続し、コードをダウンロードします（オプション）。

表 11–5.下位互換性サポート・ツール (２ /２ )


表 11–6.開発キット・ライブラリおよびソフトウェア・コンポーネント (１ /２ )

名称概要

HAL（Hardware Abstraction Layer）システム・ライブラリ

3–1ページの「HALシステム・ライブラリの概要」を参照してください。

MicroC/OS-II RTOS 8–1ページの「MicroC/OS-IIリアルタイム・オペレーティング・システム」を参照してください。

Lightweight IP TCP/IPスタック 9–1ページの「イーサネットと Lightweight IP」を参照してください。


ライブラリおよびエンベデッド・ソフトウェア・コンポーネント

Newlib ANSI C標準ライブラリ 3–1 ページの「HAL システム・ライブラリの概要」を参照してください。Newlib に関する HTML の資料一式は、Nios II インストール・ディレクトリにあります。

リード・オンリ zip ファイル・システム

12–1ページの「リード・オンリ zipファイル・システム」を参照してください。

デザイン例 Nios II開発キットでは、Nios IIプロセッサと開発環境の優れた特長を実証できるように、ソフトウェア事例が用意されています。

表 11–6.開発キット・ライブラリおよびソフトウェア・コンポーネント (２ /２ )

名称概要


12. リード・オンリ zipファイル・システム

はじめにアルテラは、HAL ( Hardware Abstraction Layer)システム・ライブラリで使用するリード・オンリ（読み取り専用）zip ファイル・システムを提供します。リード・オンリ zip ファイル・システムは、フラッシュ・メモリに格納されたシンプルなファイル・システムへのアクセスを提供します。このドライバは、ファイル・サブシステム用の HAL 汎用デバイス・ドライバ・フレームワークを利用しています。したがって、fopen()やfread()などのANSI C標準ライブラリI/O関数を使用して、zipファイル・サブシステムにアクセスすることができます。

アルテラのリード・オンリ zipファイル・システムは、Nios II統合開発環境（IDE）で使用するソフトウェア・コンポーネントとして提供されます。HALドライバ用のソース・ファイルおよびヘッダ・ファイルはすべて、<Nios IIインストール・パス >/components/altera_ro_zipfs/HAL/ディレクトリに置かれます。

プロジェクトでのzipファイル・システムの使用

リード・オンリ zipファイル・システムは、Nios II IDEユーザ・インタフェースでサポートされています。ファイル・システム使用に際して、ソース・コードの編集をする必要はありません。zip ファイル・システムを使用するには、Nios II IDEグラフィカル・ユーザ・インタフェース（GUI）を使用して、zip ファイル・システムをシステム・ライブラリ・プロジェクトのソフトウェア・コンポーネントとして指定します。

以下の 4つのパラメータを指定して、ファイル・システムをコンフィギュレーションする必要があります。

■ ファイリング・システムをプログラムするフラッシュ・デバイスの名前■ このフラッシュのオフセット■ HAL ファイル・システム内のこのファイル・サブシステムのマウント・ポイントの名前。例えば、マウント・ポイントの名前が /mnt/zipfsの場合、HALベースのプログラム内から呼び出された以下のコードが zipファイル内で hello ファイルを開きます。 fopen(“/mnt/zipfs/hello”, “r”)

■ 使用する zipファイルの名前。Nios II IDEシステム・ライブラリ・プロジェクトに zipファイルをインポートした後、その zipファイル名を指定することができます。

NII520012-1.0

myoshida

Text Box



プロジェクトでの zipファイル・システムの使用

インポートの詳細については、Nios II IDEオンライン・ヘルプを参照してください。

これらの設定を行った後、次にプロジェクトをビルドするときに、Nios II IDEはファイル・サブシステムをプロジェクトに取り込んでリンクします。ビルド後、system.h ファイルへ、このソフトウェア・コンポーネントの存在がシステムに反映されます。

zipファイルの準備zip ファイルは非圧縮ファイルでなければなりません。アルテラのリード・オンリ zip ファイル・システムは、複数のファイルをバンドルする目的にのみ zip フォーマットを使用しており、zip ユーティリティで有名なファイル解凍機能は提供していません。

非圧縮の zip ファイルの作成は、WinZip GUI を使用すれば簡単です。あるいは、コマンドラインから winzipまたは pkzipを使用するときに、-e0オプションを使用して圧縮を無効にします。

フラッシュへの zipファイルのプログラミングプログラムで zip ファイル・サブシステム内のファイルにアクセスするには、まず zip データをフラッシュにプログラムする必要があります。Nios II IDEは、プロジェクト・ビルドの過程で、zipファイル・システム用のデータを含む .flashファイルを作成します。このファイルは、プロジェクトの Releaseディレクトリにあります。

これで、Nios II IDE Flash Programmerを使用して、zipファイル・システムのデータをボード上のフラッシュ・メモリにプログラムすることができます。

フラッシュへのプログラミングの詳細については、「Nios II FlashProgrammer User Guide」を参照してください。

Altera Corporation 索引 –1Preliminary

索引

_exit() 4–30, 10–2_irq_entry 6–3_rename() 10–3

Aalt_alarm_start() 10–4alt_alarm_stop() 10–5alt_dcache_flush() 10–6alt_dcache_flush_all() 10–7alt_dev_reg() 10–8alt_dma_rxchan_close() 10–9alt_dma_rxchan_depth() 10–10alt_dma_rxchan_ioctl() 10–11alt_dma_rxchan_open() 10–13alt_dma_rxchan_prepare() 10–14alt_dma_rxchan_reg() 10–15alt_dma_txchan_close() 10–16alt_dma_txchan_ioctl() 10–17alt_dma_txchan_open() 10–18alt_dma_txchan_reg() 10–19alt_dma_txchan_send() 10–20alt_dma_txchan_space() 10–21alt_erase_flash_block() 10–22alt_flash_close_dev() 10–23alt_flash_open_dev() 10–24alt_fs_reg() 10–25alt_get_flash_info() 10–26alt_icache_flush() 10–27alt_icache_flush_all() 10–28alt_irq_disable_all() 10–29alt_irq_enable_all() 10–30alt_irq_enabled() 10–31alt_irq_handler() 6–3alt_irq_register() 6–7, 10–32alt_irq_register()を使用した ISRの登録 6–7alt_llist_insert() 10–33alt_llist_remove() 10–34alt_lwip_dev_list 5–15alt_nticks() 10–35alt_read_flash() 10–36

alt_remap_cached() 10–37alt_remap_uncached 10–38alt_sysclk_init() 10–39alt_tick() 10–40alt_ticks_per_second() 10–41alt_timestamp() 10–42alt_timestamp_freq() 10–43alt_timestamp_start() 10–44alt_uncached_free() 10–45alt_uncached_malloc() 10–46alt_write_flash() 10–47alt_write_flash_block() 10–48

Cclose() 10–49Cの例 6–11

Ddev/null 4–27DMA受信チャネル 4–23, 5–13DMA送信チャネル 4–21, 5–12DMAデバイス

DMA受信チャネル 4–23DMA送信チャネル 4–21HALを使用したプログラムの開発 4–20メモリ間 DMA転送 4–24

DMAデバイス・ドライバ 5–11DMAデバイスの使用

HALを使用したプログラムの開発 4–20

Eexecve() 10–50

Ffork() 10–51fstat() 10–52

索引 –2 Altera CorporationPreliminary


Gget_ip_addr() 9–7get_mac_addr() 9–7getpid() 10–53gettimeofday() 10–54GNU tool chainツール 1–2

GNUコンパイラ・ツール・チェインアルテラ提供の開発ツール 11–5

HHAL API統合 5–1HAL APIへの統合 5–1HAL APIリファレンス

_exit() 10–2_rename() 10–3alt_alarm_start() 10–4alt_alarm_stop() 10–5alt_dcache_flush() 10–6alt_dcache_flush_all() 10–7alt_dev_reg() 10–8alt_dma_rxchan_close() 10–9alt_dma_rxchan_depth() 10–10alt_dma_rxchan_ioctl() 10–11alt_dma_rxchan_open() 10–13alt_dma_rxchan_prepare() 10–14alt_dma_rxchan_reg() 10–15alt_dma_txchan_close() 10–16alt_dma_txchan_ioctl() 10–17alt_dma_txchan_open() 10–18alt_dma_txchan_reg() 10–19alt_dma_txchan_send() 10–20alt_dma_txchan_space() 10–21alt_erase_flash_block() 10–22alt_flash_close_dev() 10–23alt_flash_open_dev() 10–24alt_fs_reg() 10–25alt_get_flash_info() 10–26alt_icache_flush() 10–27alt_icache_flush_all() 10–28alt_irq_disable_all() 10–29alt_irq_enable_all() 10–30alt_irq_enabled() 10–31alt_irq_register() 10–32alt_llist_insert() 10–33alt_llist_remove() 10–34

alt_nticks() 10–35alt_read_flash() 10–36alt_remap_cached() 10–37alt_remap_uncached() 10–38alt_sysclk_init 10–39alt_tick() 10–40alt_ticks_per_second() 10–41alt_timestamp() 10–42alt_timestamp_freq() 10–43alt_timestamp_start() 10–44alt_uncached_free() 10–45alt_uncached_malloc() 10–46alt_write_flash() 10–47alt_write_flash_block() 10–48close() 10–49execve() 10–50fork() 10–51fstat() 10–52getpid() 10–53gettimeofday() 10–54ioctl() 10–55isatty() 10–56kill() 10–57link() 10–58lseek() 10–59open() 10–60read() 10–61sbrk() 10–62settimeofday() 10–63stat() 10–64times() 10–65unlink() 10–66usleep() 10–67wait() 10–68write() 10–69はじめに 10–1標準型 10–70

HALsystem.hを使用したプログラムの開発 4–3

HALアーキテクチャHALシステム・ライブラリの概要 3–2newlib 3–5サービス 3–2

HAL関数 - 置き換え 4–38HAL関数の置き換え 4–38HAL型の定義

HALを使用したプログラムの開発 4–4


HALシステム・クロック 4–10HALシステム・ライブラリ・ユーザマルチ・マスタ /マルチ CPUシステムでの

キャッシュの管理 7–8HALシステム・ライブラリツール 1–3

HALシステム・ライブラリの概要HALアーキテクチャ 3–2サポートされているペリフェラル 3–6はじめに 3–1

HALシステム・ライブラリ・ファイルHALを使用したプログラムの開発 4–38


HAL関数の置き換え 4–38HALファイルの格納場所 4–38HALを使用したプログラムの開発 4–38

HALシステム・ライブラリ・ユーザデバイス・ドライバの記述 7–5プログラム・ローダの記述 7–6リセット後のキャッシュの初期化 7–4

HAL実装_irq_entry 6–3alt_irq_handler() 6–3software_exception 6–4例外処理 6–2

HALデバイス・クラス・ドライバDMAデバイス・ドライバ 5–11イーサネット・デバイス・ドライバ 5–14キャラクタ・モード・デバイス・

ドライバ 5–5タイマ・デバイス・ドライバ 5–9ファイル・サブシステム・ドライバ 5–8フラッシュ・デバイス・ドライバ 5–10

HALデバイス・クラス用ドライバの作成HAL用デバイス・ドライバの開発 5–5

HALデバイス・ディレクトリ構造 5–17HALデバイス・ドライバ・ファイル 5–17HAL標準型 10–70HALファイルの格納場所 4–38HALへのデバイス・ドライバの統合

HAL用デバイス・ドライバの開発 5–17HAL用デバイス・ドライバ・

ファイル 5–17要約 5–21

HALベース・プログラムのブート・シーケンス 4–32

HAL用デバイス・ドライバの開発HALデバイス・クラス用ドライバの

作成 5–5HALへのデバイス・ドライバの統合 5–17SOPC Builderの概念 5–3デバイス・ドライバ作成の開発フロー 5–2デフォルト・デバイス・ドライバの

置き換え 5–23ドライバ・フットプリントの削減 5–22ネーム空間の割り当て 5–22ハードウェアへのアクセス 5–3はじめに 5–1

HAL用デバイス・ドライバ・ファイル 5–17HALを使用したプログラムの開発

DMAデバイス 4–20DMAデバイスの使用 4–20HAL型の定義 4–4HALシステム・ライブラリ・

ファイル 4–38HALシステム・ライブラリ・ファイルへの

パス 4–38Nios Ⅱ IDEプロジェクト構造 4–1UNIX形式のインタフェース 4–5エントリ・ポイント 4–31キャラクタ・モード・デバイス 4–7キャラクタ・モード・デバイスの使用 4–7コード・フットプリント 4–26コード・フットプリントの削減 4–26システム記述ファイル 4–3タイマ・デバイス 4–10タイマ・デバイスの使用 4–10データ幅 4–4はじめに 4–1ファイル・サブシステム 4–9ファイル・サブシステムの使用 4–9ファイル・システム 4–6フラッシュ・デバイス 4–14フラッシュ・デバイスの使用 4–14ブート・シーケンス 4–31メモリの使用 4–34

Iinit_done_func() 9–5init_routine() 5–15ioctl() 10–55isatty() 10–56



ISRCの例 6–11ISRのイネーブル 6–10ISRの記述 6–8ISRのディセーブル 6–10ISRの登録 6–7ISR用HAL API 6–7例外処理 6–6

ISR記述に関する提案例外処理 6–15

ISRのイネーブル 6–10ISRの記述 6–8ISRの性能データ例外処理 6–13

ISRのディセーブル 6–10ISR用HAL API 6–7ISRを使用したデバッグ例外処理 6–14

Kkill() 10–57

LLightweight IP

ARPオプション 9–12DHCPオプション 9–12IPオプション 9–11Lightweight TCP/IPスタックの一般的な

設定 9–11Nios IIポート 9–1TCPオプション 9–12UDPオプション 9–12ファイル 9–2メモリ・オプション 9–13

Lightweight IPのNios IIポート 9–1link() 10–58linkoutput() 5–16lseek() 10–59lwip_devices_init() 9–7lwip_stack_init() 9–5LWIPプロトコル・スタックの使用イーサネットと Lightweight IP 9–3

MMicroC/OS-II リアルタイム・

オペレーティング・システムアルテラによるMicroC/OS-IIの移植 8–2Newlib ANSI C標準ライブラリ 8–6Nios II IDEでのプロジェクトの実装 8–7アーキテクチャ 8–3一般オプション 8–8イベント・フラグ 8–8キューの設定 8–10時間管理の設定 8–12スレッド対応デバッグ 8–3セマフォの設定 8–9相互排除の設定 8–9その他の RTOSプロバイダ 8–2その他の情報 8–1その他の設定 8–11タスク管理の設定 8–12デバイス・ドライバ 8–4はじめに 8–1メールボックスの設定 8–10メモリ管理の設定 8–11ライセンス 8–2


概要 8–1

NNewlib ANSI C標準ライブラリ

MicroC/OS-II リアルタイム・オペレーティング・システム 8–6

Newlib Cライブラリ 4–28Nios II IDEツール 1–2

Nios II IDEツアーアルテラ提供の開発ツール 11–1

Nios II IDEでの LWIPのコンフィギュレーション

イーサネットと Lightweight IP 9–10Nios II IDEでのMicroC/OS-IIプロジェクトの

実装 8–7Nios II IDEワークベンチ

Nios Ⅱ IDEの紹介 2–1エディタ 2–2パースペクティブ 2–2ビュー 2–2


Nios IIのキャッシュ実装 7–1Nios II例外の概要例外処理 6–1

Nios Ⅱ IDEの紹介Nios II IDEワークベンチ 2–1オンライン・ヘルプ 2–10新規プロジェクトの作成 2–2はじめに 2–1フラッシュのプログラミング 2–9プログラムの実行とデバッグ 2–6プロジェクトの構築と管理 2–4

Nios Ⅱ IDEプロジェクト構造HALを使用したプログラムの開発 4–1

Oopen() 10–60output() 5–16

Rread() 10–61RTOSおよび TCP/IPスタックツール 1–3

rx_routine() 5–16

Ssbrk() 10–62settimeofday() 10–63software_exception 6–4SOPC Builderと system.hの関係 5–3SOPC Builderの概念

HAL用デバイス・ドライバの開発 5–3最適ハードウェア・

コンフィギュレーション 5–3SOPCの概念コンポーネント、ドライバおよび

ペリフェラル 5–3stat() 10–64stderr 4–8stdin 4–8stdout 4–8system.h

HALを使用したプログラムの開発 4–3system.hと SOPC Builderの関係 5–3

Ttimes() 10–65

UUNIX形式のインタフェース

HALを使用したプログラムの開発 4–5unlink() 10–66usleep() 10–67

Wwait() 10–68write() 10–69

Zzipファイルの準備リード・オンリ zipファイリング・

システム 12–2zipファイルのプログラミングリード・オンリ zipファイリング・

システム 12–2

あアーキテクチャ


アラーム 4–11アルテラ提供の開発ツール

GNUコンパイラ・ツール・チェイン 11–5Nios II IDEツアー 11–1アルテラのコマンドライン・ツール 11–2エンベデッド・ソフトウェア・

コンポーネント 11–5はじめに 11–1ライブラリ 11–5

アルテラによるMicroC/OS-IIの移植MicroC/OS-II リアルタイム・

オペレーティング・システム 8–2アルテラのコマンドライン・ツールアルテラ提供の開発ツール 11–2



いイーサネット・デバイス・ドライバ 5–14

alt_lwip_dev_list 5–15init_routine() 5–15linkoutput() 5–16output() 5–16rx_routine() 5–16

イーサネットと Lightweight IPLWIPのNios IIポート 9–1LWIPファイル 9–2LWIPプロトコル・スタックの使用 9–3Nios II IDEでの LWIPの

コンフィギュレーション 9–10確認されている制限事項 9–13システム要件 9–4スタックの初期化 9–5その他の TCP/IPスタック・

プロバイダ 9–3はじめに 9–1ライセンス 9–3

一般オプションMicroC/OS-II リアルタイム・

オペレーティング・システム 8–8イベント・フラグ


インストラクション・セット・シミュレータツール 1–2

えエントリ・ポイントブート・シーケンスのカスタマイズ 4–33HALを使用したプログラムの開発 4–31独立型アプリケーション 4–31ホスト型アプリケーション 4–31

エンベデッド・ソフトウェア・コンポーネントアルテラ提供の開発ツール 11–5

おオンライン・ヘルプ

Nios Ⅱ IDEの紹介 2–10

か開発環境概要 1–2

確認されている制限事項イーサネットと Lightweight IP 9–13

概要MicroC/OS-IIリアルタイム・

オペレーティング・システム 8–1Nios Ⅱに関するその他の情報 1–5開発環境 1–2サードパーティ・サポート 1–4第 1世代のNiosプロセッサ・ユーザ 1–4入門 1–1はじめに 1–1

きキャッシュ管理用 HAL API関数 7–2キャッシュ実装 7–1キャッシュの管理 7–2キャッシュ・メモリ

Nios IIのキャッシュ実装 7–1キャッシュ管理用 HAL API関数 7–2デバイス・ドライバの記述 7–4はじめに 7–1プログラム・ローダまたは

自己書き換えコードの記述 7–6マルチ・マスタ /マルチ CPUシステムでの

キャッシュの管理 7–7リセット後のキャッシュの初期化 7–3

キャラクタ・モード・デバイスC++ストリーム 4–9dev/null 4–9HALを使用したプログラムの開発 4–7アクセス 4–8標準入力、標準出力、標準エラー 4–8

キャラクタ・モード・デバイス・ドライバ 5–5

作成 5–5登録 5–7

キャラクタ・モード・デバイスの使用HALを使用したプログラムの開発 4–7

キューの設定MicroC/OS-II リアルタイム・

オペレーティング・システム 8–10


こ高精度時間測定 4–12高精度フラッシュ・アクセス 4–18高速 ISR処理例外処理 6–12

コード・フットプリント_exit() 4–30dev/null 4–27HALを使用したプログラムの開発 4–26Newlib Cライブラリ 4–28スモール・フットプリント・デバイス・

ドライバ 4–26ファイル記述子プール 4–27未使用デバイス・ドライバ 4–30

コード・フットプリントの削減HALを使用したプログラムの開発 4–26

さサードパーティ・サポート概要 1–4

最適ハードウェア・コンフィギュレーション 5–3

サポートされているペリフェラルHALシステム・ライブラリの概要 3–6

しシステム記述ファイル

HALを使用したプログラムの開発 4–3システム・クロック・ドライバ 5–9システム要件

Lightweight IP 9–4使用開始にあたって

HALシステム・ライブラリの概要 3–1新規プロジェクトの作成

Nios Ⅱ IDEの紹介 2–2シンプル・フラッシュ・アクセス 4–15時間管理の設定


自己書き換えコードの記述HALシステム・ライブラリ・ユーザ 7–6

すスタックの初期化

Lightweight IP 9–5スタックの配置 4–37スモール・フットプリント・デバイス・

ドライバ 4–26スレッド対応デバッグ


せセマフォの設定


そ相互排除の設定


その他の RTOSプロバイダMicroC/OS-II リアルタイム・

オペレーティング・システム 8–2その他の情報


Nios Ⅱ 1–5その他の設定


その他の TCP/IPスタック・プロバイダイーサネットと Lightweight IP 9–3

たタイマ・デバイス

HALシステム・クロック 4–10HALを使用したプログラムの開発 4–10アラーム 4–11高精度時間測定 4–12

タイマ・デバイス・ドライバ 5–9システム・クロック・ドライバ 5–9タイムスタンプ・ドライバ 5–9

タイマ・デバイスの使用HALを使用したプログラムの開発 4–10

タイムスタンプ・ドライバ 5–9



タスク管理の設定MicroC/OS-II リアルタイム・

オペレーティング・システム 8–12第 1世代のNiosプロセッサ・ユーザ概要 1–4

つツール 1–2

GNU tool chain 1–2HALシステム・ライブラリ 1–3Nios II IDE 1–2RTOSおよび TCP/IPスタック 1–3インストラクション・セット・

シミュレータ 1–2

てデータ幅

HALを使用したプログラムの開発 4–4デバイス・ドライバ


デバイス・ドライバ作成の開発フローHAL用デバイス・ドライバの開発 5–2

デバイス・ドライバの記述HALシステム・ライブラリ・ユーザ 7–5キャッシュ・メモリ 7–4

デフォルト・デバイス・ドライバの置き換えHAL用デバイス・ドライバの開発 5–23

と独立型アプリケーション 4–31ドライバ・フットプリントの削減

HAL用デバイス・ドライバの開発 5–22

に入門概要 1–1

ねネーム空間の割り当て

HAL用デバイス・ドライバの開発 5–22

はハードウェアへのアクセス

HAL用デバイス・ドライバの開発 5–3はじめに

HAL APIリファレンス 10–1HALシステム・ライブラリの概要 3–1HAL用デバイス・ドライバの開発 5–1HALを使用したプログラムの開発 4–1MicroC/OS-II リアルタイム・

オペレーティング・システム 8–1Nios Ⅱ IDEの紹介 2–1アルテラ提供の開発ツール 11–1イーサネットと Lightweight IP 9–1概要 1–1キャッシュ・メモリ 7–1リード・オンリ zipファイリング・

システム 12–1例外処理 6–1

破壊 4–17

ひヒープの配置 4–37必要な知識

HAL用デバイス・ドライバの開発 5–2標準エラー 4–8標準出力 4–8標準入力 4–8

ふファイル記述子プール 4–27ファイル・サブシステム

HALを使用したプログラムの開発 4–9ファイル・サブシステム・ドライバ 5–8作成 5–8登録 5–8

ファイル・サブシステムの使用HALを使用したプログラムの開発 4–9

ファイル・システムHALを使用したプログラムの開発 4–6

フラッシュ・デバイスHALを使用したプログラムの開発 4–14高精度フラッシュ・アクセス 4–18シンプル・フラッシュ・アクセス 4–15破壊 4–17ブロックの消去 4–17


フラッシュ・デバイス・ドライバ 5–10作成 5–10登録 5–11

フラッシュ・デバイスの使用HALを使用したプログラムの開発 4–14

フラッシュのプログラミングNios Ⅱ IDEの紹介 2–9

ブート・シーケンス 4–32HALを使用したプログラムの開発 4–31独立型アプリケーション 4–31ブート・シーケンスのカスタマイズ 4–33ホスト型アプリケーション 4–31

ブート・シーケンスのカスタマイズ 4–33ブート・モード 4–37ブロックの消去 4–17プログラムの実行とデバッグ

Nios Ⅱ IDEの紹介 2–6プログラム・ローダの記述

HALシステム・ライブラリ・ユーザ 7–6プログラム・ローダまたは

自己書き換えコードの記述キャッシュ・メモリ 7–6

プロジェクトでの zipファイル・システムの使用

リード・オンリ zipファイリング・システム 12–1

プロジェクトの構築と管理Nios Ⅱ IDEの紹介 2–4

へペリフェラル固有の API 5–2

ほホスト型アプリケーション 4–31

まマルチ・マスタ /マルチ CPUシステムでの

キャッシュの管理HALシステム・ライブラリ・ユーザ 7–8キャッシュ・メモリ 7–7

み未使用デバイス・ドライバ 4–30

めメールボックスの設定


メモリ間 DMA転送 4–24メモリ管理の設定


メモリ・セクション 4–34メモリの使用

HALを使用したプログラムの開発 4–34スタックの配置 4–37ヒープの配置 4–37ブート・モード 4–37メモリ・セクション 4–34メモリ・パーティションへのコードと

データの割り当て 4–35メモリ・パーティションへのコードと

データの割り当て 4–35

らライセンス

Lightweight IP 9–3MicroC/OS-II リアルタイム・

オペレーティング・システム 8–2ライブラリアルテラ提供の開発ツール 11–5

りリード・オンリ zipファイリング・システム

zipファイルのプログラミング 12–2プロジェクトでの zipファイル・システムの

使用 12–1zipファイルの準備 12–2はじめに 12–1

リセット後のキャッシュの初期化HALシステム・ライブラリ・ユーザ 7–4キャッシュ・メモリ 7–3



れ例外処理

HAL実装 6–2ISR 6–6ISR記述に関する提案 6–15

ISRの性能データ 6–13ISRを使用したデバッグ 6–14Nios II例外の概要 6–1高速 ISR処理 6–12はじめに 6–1

Nios II ソフトウェア開発ハンドブック Version 1...iv Altera Corporation Preliminary...

Documents

Transcript of Nios II ソフトウェア開発ハンドブック Version 1...iv Altera Corporation Preliminary...