JDE-ヘルプのヘルプ JDE-ヘルプのヘルプC言語等で記述したプログラムをターゲットCPUで動作する形のバイナリファイルに変換するプログラムです。
GCCなどのコンパイラは一般にコマンドライン形式のプログラムで、makeを使って呼び出します。
JDEはプロジェクトやウィンドウ画面の設定からプロジェクトを構築するmakefileを作りコンパイラを呼び出します。
GCCが出力する実行形式のファイルでelfフォーマットで拡張子として.outを使っています。
Linuxやcygwin上ではOSの機能でelfフォーマットのファイルを直接実行できますが、ボード上で実行するためにはメモリ配置を指定して転送に使うフォーマットに変換しなければなりません。
JDEでは主にSフォーマット形式で.motという拡張子のテキストファイルを使っています。
Windows用語のフォルダと同じ意味です、MicrosoftもDOSの時代にはフォルダのことをディレクトリと呼んでいました。
Linuxの世界では今でもディレクトリという名称が標準です。
プログラムを解析しデバッグするためのツールをデバッガと言います。
標準的なデバッガソフトとしてgdbがあります、JDEではgdbのGUI版であるinsightというデバッガに対応しています。
ボード上のプログラムをデバッグするためにはstubというgdb対応のデバッグモニタをボードに組み込むかJTAG対応のハードウェアツールを使ってPC上のinsightとボード上のプログラムが通信しなければなりません、ARMCPUではFlashROM上のプログラムをデバッグ可能なデバッグハードウェアが内蔵されておりJTAGを使ってデバッグすることが出来ます
JDEではオープンソースのJTAGツールであるopenocdとinsightを使ったデバッグをサポートしています。
H8/SH/AT91SAM等、最近のフラッシュ内蔵CPUは特別なハードウェアが無くてもシリアルポートやUSBからフラッシュへ書き込みができる機能を内蔵しています。
その機能を使ってメーカー出荷状態のCPUへプログラムを書き込むことをブート書き込みと言います。
ブート書き込みで書き込んだプログラムはCPUリセットで最初に実行されます（リセット起動）からプログラム先頭で必要なハードウェア初期化を全て行なわなければなりません。
それに対しブート書き込みでフラッシュROMへ書き込んだモニタプログラムを使って残りのフラッシュROMへプログラムを書き込むことをモニタ書き込みと呼びます。
ブート書き込み用のツールとしてルネサス製CPUではFDT、ATMELのAT91SAMシリーズではSAM-BAなどがメーカから提供されています。
ターゲットファイルを構築するためにはプログラムを記述した複数のソースファイル、リンカスクリプト、makefileが必要です。
プロジェクトはそれらのファイルと設定をまとめたものです、プロジェクトは.jprというプロジェクトファイル及びソースファイルの入っているディレクトリ単位で保存、コピーすることができます。
リンカオプションでプログラム内関数・データ配置アドレスの詳細リストをファイルに出力することが出来ます。
そのファイルをマップファイルと呼びます。
組込プログラミングではROM・RAMの容量とアドレスを確認してマップファイルに一度は目を通しておくことが大切です。
フラッシュROM先頭に書き込んだ小サイズのモニタを使ってプログラムを書き込むことをモニタ書き込みといいます。
モニタ書き込みの欠点は使用できるROM領域が狭くなることです。
長所は書き込み手順がシンプルになり、モニタ機能を使ってプログラムを簡単に書けることにあります。
コンパイラが作成した複数のバイナリファイルとライブラリをリンクしてアプリケーションを作成するプログラムです。
広い意味でコンパイラというときはコンパイラ＋リンカのセットを意味します。
リンカに作業を指示するファイルをリンカスクリプトと呼び、GCCのリンカはリンカスクリプトの記述で柔軟な処理が出来るのが特長です。
現在では、CPUという呼び名はPCマザーボードのようにメモリや他の周辺回路を外付けして使うチップを意味し、PICやH8のようにワンチップで使えるものはMPUと呼ぶことが多くなっています。
しかしその境界はあいまいで統一された定義はありません。
このヘルプでCPUという用語はワンチップMPUも含めてCPU的なもの全てを意味します。
GCCはGPLで提供されるコンパイラ群の総称でC言語を基本とする様々なプログラミング言語と、多くのCPUが対象となっています。
GPLに関しては賛否両論がありますがGCCは世界で多数のユーザーをかかえインターネット上で使い方について最も多くの情報が得られる組み込み用コンパイラです。
ソースとライブラリを独自に作成しGCCでコンパイルしたプログラムはGPLに縛られませんので単にGCCを使うならばGPLのことを気にする必要はありません。
しかしコンパイラを使うときは意識しなくてもライブラリからあらかじめ用意された関数を取り込んでしまいます、GPLのライブラリを使ったプログラムがGPLに従わなければならないかどうかはグレー領域の問題として扱われています。
組み込み用としてはGPLに縛られないフリーのライブラリであるNewlibがよく使われています。ライブラリとしてNewLibを使った場合は生成されたプログラムを公開するか否かは純粋に作った側の意図で決めることができます。
GPLはオープンソースのライセンスです、GPLの主旨は次の通りです。
※GPLのソースを取り込んだソフト全体にオープンソース化を強制することによってオープンソース化を推進する。
そのためソフト販売で利益を得ている陣営からはGPL汚染などという言葉も聞かれることがありますが研究やソフト全体の質を向上するためにはたいへん貢献しているライセンスです。
組込プログラムではプログラム構造は簡単でもハードウェアに関する知識がないとプログラム／デバッグが出来ません。
プログラムに全く問題がなさそうなのに動作しないなどの不可解な問題に直面したときはハードウェア構造など組込プログラム特有の知識とノウハウが必要になります。
簡単なプログラムでもハードウェアを操作することはPCのプログラムとは違った楽しみがあります。
最初に教科書を開いて退屈な座学から始める必要はありません、実際のプログラム／デバッグを通じて楽しみながら勉強することがエキスパートへの近道です。
次の項目は組込プログラム特有のノウハウに関する項目です、デバッグで壁にぶつかったら良い勉強の機会と思ってこれらの項目に関して調べてみましょう。
アセンブラでプログラムするのは出来るだけ避けた方が賢明です、ただしコンパイラがCのプログラムをどのような形でCPU操作命令に置き換えているのかを調べてみるのはエキスパートへの重要なステップです。
組込ではCPUの初期化もプログラマがコントロールしなければなりません、リセット信号の役割、リセットスタート時にCPUがどのアドレスから実行を開始するかなどについて確認して下さい。
PCでメモリを意識するのは「メモリ不足」というキーワードくらいですが、
RAM容量の少ないワンチップでは最初からデータ・プログラムがROMにどのように配置されるか、スタートアップルーチンで変数がどのように初期化されるかなどを確認しておかなければなりません。
使用するCPUボードのROM/RAM容量とコンパイラが出力するMAPファイルを最初に確認する習慣をつけましょう。
スタックオーバフローが原因でプログラムは正しいのに途中で暴走するなどのトラブルが発生することがあります。
原因不明のトラブルが起きたらスタックの役割、スタックポインタの初期化、スタックの使用量などを確認します。
組込プログラムでは割込みの活用が必須ですが割込はわかりにくいトラブルの発生原因にもなります。
割込みに関する基礎知識を身につけて、割込禁止・許可などの操作／メインルーチンとの連携がうまく出来るようになれば初心者レベルは卒業です。
プログラムを書き始める前にメモリマップと入出力ポートの対応、ビット操作などを確認します。