マイコンの開発

マイコンのシステム開発はどのように行うのですか。

一般には、次のような開発の流れになります。
(1) システム設計
(2) 部品調達
(3) 試作ハードウエア開発
(4) プログラム開発
(5) IEやシミュレータ、評価ボード等での動作検証とディバグ
(6) ROM書き込み
(7) 実チップでの動作検証
(8) 量産ボード開発
(9) マスクROM発注
(10) マスク品での動作検証

(1)では、システム要件に適したマイコンを選定し、各内部機能の動作モードを定義したり、 外部接続やアドレスの割り当て、処理フローの作成などを行います。

(3)と(4)は、ハードウエアとソフトウエアの分担で、同時進行することがあります。
(3)では、(1)の設計内容に従って、 ボードのハードウエア設計と部品(マイコン以外)の実装をします。 試作なので、ソケット実装でのラッピング配線やはんだ付けによる配線をすることがあります。

(4)では、パソコンでプログラム作成(プログラミング)をします。開発言語はC言語や、 CPUのアーキテクチャに依存するアセンブリ言語です。
プログラムが完成すると、アセンブリ言語の場合にはアセンブラで、 またC言語の場合にはCコンパイラで、それぞれ機械語(マシン語)に変換します。
Cコンパイラによっては、C言語をアセンブリ言語に落としてから、アセンブラで機械語 に変換する場合もあります。
これらが分割した機械語プログラムなら、その後リンカで結合します。



(5) ターゲット・システム内のマイコンの代わりに、 IE(インサーキット・エミュレータ)とパソコンを接続して、 IE上に展開したプログラムを実行します。

問題があれば、シミュレータやディバッガによって、回路やプログラムのディバグを行います。
なお、想定しているマイコンのパッケージと、IEのアダプタの形状が異なる場合には、変換ソケットが必要です。



(6) PROM(内蔵または外部)ではPROMプログラマで、 またフラッシュ・メモリではフラッシュ・プログラマで、 パソコンを通じて生成した機械語をROMコードに変換して書き込みます。



(7) プログラムを書き込んだROMとマイコンをターゲット・ボードに実装して、 プログラム動作による確認を行います。

(8) プリント基板を作成します。

(9) 大量生産する場合は、マスク品を作成します。
マスク品では、プログラムの提示だけでなく、マスク・オプションによる機能指定ができます。
発注方法は ROMコードの発注方法 をご参照ください。

(10)では、(9)で完成したマイコンと必要なデバイスを(8)の基板に実装して、 最終的な動作確認を行います。

(2004/06)

マイコン・システムの開発で、PROM品とフラッシュ品ではどのように違いますか。

プログラム開発に違いがあります。
まず、プログラムの書き込みに使用するライタが、PROMプログラマかフラッシュ・プログラマかの違いです。書き込み方法が異なるので、互いに代用することはできません。

次に、PROM品はプログラマ上でしか書き込めませんが、フラッシュ品はターゲット・システムにプログラマを接続してオンボード書き込みもできます。このためフラッシュ品では、セット出荷後のプログラム変更が比較的容易です。
さらにAll Flashマイコンでは、フラッシュ・メモリを書き換えながらプログラムのディバグを行うオンチップ・ディバグ機能を内蔵しています。

なお、オプション・バイトがあるフラッシュ品では、ユーザ・オプションとしてこれを設定する必要があります。
フラッシュ品の書き込みについては、フラッシュ書き込みをご参照ください。

(2008/03)

マイコンの命令は、どういう構成になっているのですか。

マイコンの動作をレジスタ・レベルで直接定義する命令(インストラクション)記述は、アセンブリ言語です。アセンブリ言語は、基本動作を定義するニモニックと、アクセス対象の内部レジスタやアドレス(メモリ、I/O)を指定するオペランドで構成されます。
C言語では、マイコンの命令を直接意識せず、演算や転送、判断などの概念を記述します。C言語とマイコンの命令セットとの関連付けは、Cコンパイラが行います。このため、Cコンパイラによって、コードの生成効率が異なります。
また、Cコンパイラやアセンブラが生成する機械語は、マイコンが直接実行できる形式の命令コードとなります。



内部レジスタ間アクセスを1バイトの命令コードで記述するマイコンであっても、転送先(dst)や転送元(src)に、メモリやI/Oのアドレスの値を記述する場合は、命令コードが2バイト以上になります。命令コードの1バイト目をオペコード(オペレーション・コード)と呼び、マイコンがオペコードを読み取ることをオペコード・フェッチといいます。マイコンは、フェッチしたオペコードを解析して、何バイト命令かを認識し、残りの命令コードがあるかどうか(さらに読み取ってから実行するかどうか)を判断します。

ROM化とは何?また、なぜROM化が必要なのか。

マイコンのアプリケーションプログラムは最終的に内蔵のROM(マスクROMやフラッシュ等)に書き込み、応用システムに組み込んで使用します。
このため、Cコンパイラでプログラムを作るだけでは不十分です。
単に、プログラムや固定データを内蔵ROMへ配置するだけではなく、初期値のある変数への対応等が必要になります。
例えば、初期値のある変数は、アプリケーションプログラムの動作時にはRAMに配置されていて、参照や書き換えができる必要があります。
しかし、マイコンでは電源が投入された時にはRAMの内容が不定となります。
そのため、アプリケーションプログラムがスタートする前に、変数の初期値を設定しておく必要があります。
この為の処理がROM化と呼ばれ、前もってROMの中に初期値データを格納しておき、起動時にそのデータを対応するRAMにコピーを行うものです。



78Kシリーズの場合には、標準でROM化を行うようになっていて、気にする必要はありませんが、V850ではオプションで指定する必要があります。
さらに、ROMからRAMへのコピーはアプリケーションプログラムの中で実行(_rcopy関数を使用)する必要があります。

フラッシュ品を使ってディバグ(評価)を行う場合にもROM化は必要か。

はい、ROM化はフラッシュ品を用いた評価の場合にも必要です。

エミュレータを用いたディバグではROM化をしないで、ROM発注のときにだけROM化すればよいのか。

いいえ、エミュレータを用いたディバグ段階からROM化しておいてください。
ROM化してないと、ディバグでリセットからやり直した場合に初期値のある変数の初期値がおかしくなっている可能性があります。
(エミュレータでは、初期値のある変数も、直接RAMにオブジェクトをダウンロードするので、初期値が入ります。しかし、ディバグ中に変数が書き換えられるとその状態が残ってしまいます。再度、プログラムをリセットからやり直した場合には書き換えた値が新しい初期値となるので、プログラムの動作が変わってくることが考えられます。ROM化してあると、リセットからやり直すことで、初期値のある変数に初期値がコピーされるので、正しい初期値で使えます。)

ROMコード発注時にINTEL HEXフォーマットを使うが、INTEL HEXフォーマットとはどのようなものか。

INTEL HEXフォーマットはオブジェクト(機械語)をやり取りするためのフォーマットのひとつで、1バイトをASCIIコードで2桁の16進数(HEX)に変換して表現したものです。
1行(レコード)で最大255バイト分のデータを表現でき、これを必要な回数繰り返します。
具体的なフォーマット例を以下に示します。

":"がレコ-ドの開始を示します
次の16進数2桁(10)がレコードのデータ数を示します
次の16進数4桁(0000)がデータのアドレスを示します
次の16進数2桁(00)がレコ-ドタイプで、データレコードであることを示します
(00はデータレコ-ド、01はエンドレコ-ド、02はセグメントレコ-ド等)
ここがデータそのもので、データは"00","01","02",・・・,"0E","0F"です
最後がチェクサムでデータ数からチェックサムまでを加算すると下位8ビットは00になるようになっていて、エラー・チェックに使用します。

以上の情報に改行がついて1行が1つのレコ-ドとなります。
2行目がエンドレコ-ドで、データ数が00、レコードタイプが01になります。



これだけではアドレスは16ビット(64Kバイト)しか表せません。
それ以上を指定できるようにセグメントレコード(レコードタイプ02)を使用します。
下記の例は上の例の前にセグメントレコードを追加したものです。
セグメントレコードで指定したセグメントの値を16倍した値が以降のレコードのアドレスに加算されます。
ここではの1000Hがセグメントとして指定されているので、以降のデータは10000H〜1000FHに格納されることを示しています。

ROM発注にはINTEL HEXフォーマットであればどのようなものでもよいのか。

いいえ、マスクROM処理ではチェックのためにさらに制限を設けています。
例えば、INTEL HEXフォーマットではレコードのアドレスの順番に制限はありませんが、マスクROM処理ではアドレスは連続して大きくなる必要があります。
その他にも厳密なチェックを行っていますので、ROM発注には、必要なオプションを指定してオブジェクトコンバータを通した結果をご使用ください。

78K0/KB2をターゲットにして、NIMICUBE2でシステム開発を行おうとしています。最終的なプログラムのサイズは16Kバイト以下にすることでF0501を考えています。ユーザーズ・マニュアルにはデバッグ対象の製品に合わせてIMSレジスタの設定を行うように書かれています。開発段階では16Kバイトを超えることが考えられますが、IMSレジスタの設定はどうすればいいでしょうか。

開発段階で16Kバイトを超える可能性があるなら、その段階ではIMSレジスタは開発対象製品の値(04)ではなく、より大きなROM容量の製品の値(例えば、オンチップ・デバッグに使用するF0503Dの値(C8H))に設定してください。開発が進んで、プログラムが16Kバイトに収まるようになった段階で、開発対象製品の値に変更してください。

(2007/12)

F0501をターゲットにした開発で、開発段階はF0503D用の値をIMSレジスタに設定してオンチップ・デバッグを行いますが、IMSをそのままにしておいてはだめですか。プログラムがF0501の内蔵ROMの中に収まることは確認しています。だめな場合にはその理由を教えてください。

2つの点で問題が考えられるために、IMSレジスタは開発対象製品の値に変更してください。
ひとつは、内蔵RAMへのアクセスの問題です。RAMへのアクセスはRAMのアドレスを直接指定する(変数の名前をつけて、その名前でアクセスするなどダイレクト・アドレッシングやショート・ダイレクト・アドレッシング。MAP情報でアドレスは明確になる)以外にもレジスタ間接(レジスタの内容がRAMのアドレスを示すために最終的なアドレスは命令が実行されるまでわからない)などでアクセスされることもあります。そのときに開発対象製品にはないアドレスがアクセスされる可能性がありますが実行するまで分かりません。ところが、オンチップ・デバッグで使用するF0503DにはそのアドレスにもRAMがあるので、デバッグでは分かりません。
もう一つは、ROMの内容をデータとして参照している場合です。このときに開発対象製品では存在しないアドレスを参照していると、アクセス結果が異なることになります。
IMSレジスタを開発対象製品の値に設定すると、本来は存在しないアドレスのROMを参照するとウォッチドッグ・タイマの機能で検出できます。(ただし、内部高速RAM領域に対しての異常アドレス・アクセスは検出できません。)

(2007/12)

小ピン・マイコン(78K0S)でも内蔵するメモリ容量が異なるのに、IMSレジスタのようなレジスタがありません。なぜ、問題ないのでしょうか。

小ピン・マイコンではオンチップ・デバッグ専用のデバイスを用いることなく、対象の製品を使ってデバッグが行えます。従って、IMSレジスタのような機能を用いなくてもメモリ構成は対象の製品と同じになるからです。

(2007/12)

CC78K0を用いてC言語でのプログラム開発を考えていますが、ポートの制御をどのように記述すればよいかが分かりません。また、ユーザーズ・マニュアルのレジスタの説明でビット番号が□で囲まれたものと、そうでないものの制御はどう違ってくるのですか。

CC78K0やCC78K0Sではデバイスのユーザーズ・マニュアルに記載されたレジスタの名称をC言語のプログラム中で使うことができます。そのためにはプログラムの頭の部分で、「#pragma sfr」と宣言してください。そうすると、内蔵周辺レジスタを変数のように使用することができるようになり、以下の例のように記述することでポート等の制御を行うことができます。

�@	port_data = P2;		/* ポート2の状態を変数port_dataに読み込む */
�A	PM1 = 0b00000000;		/* ポート1の8ビット全てを出力に設定 */
�B	P1 = 0x55;		/* ポート1に0x55を出力する */
�C	P1.0 = 0;		/* ポート1のビット0を"0"にする */
�D	P1.7 ^= 1;		/* ポート1のビット7を反転する */
�E	while(P2.0 == 0);		/* ポート2のビット0が"1"になるのを待つ */
�F	while(TMIFH1 == 0);		/* タイマH1のインターバル割り込みを待つ */
	TMIFH1 = 0;		/* タイマH1の割り込み要求をクリア */

�@の例ではポート2(の端子の状態)を読み込んで、その値を変数"port_data"に代入します。このような記述を行うことでポート(端子)の状態を取り込むことができます。

�Aの例はポート1を出力ポートに設定するために、ポート・モード・レジスタ1の各ビットを0(=出力)に設定しています。

�Bの例は全てのビットを出力に設定してあるポート1に対して16進数で55というデータを出力しています。これで、ビット0,2,4,6はハイ・レベルになり、ビット1,3,5,7はロウ・レベルになります。

�Cの例はポート1のビット0の値だけを"0"にして出力をロウ・レベルにします。

�Dの例はポート1のビット7の出力だけを反転させます。

�Eの例はポート2のビット0がロウ・レベルの間はwhileでループするので、ポート2のビット0への入力がハイ・レベルになるのを待つことになります。

�Fの例はタイマH1を用いたインターバル・タイマの時間経過を割り込みではなくポーリングにより待つ処理です。前もって指定されたインターバルが経過するとタイマH1は割り込み要求フラグをセットします。ここでは、割り込み要求フラグが"0"の間はwhileでループするので、インターバルの経過までを持つことになります。割り込み要求が発生してループを抜けると、割り込み要求をクリアします(この2つのステートメントをセットで使用します)。

この例の�Eと�Fのwhile文のループ条件を比べてください。
�Eでは、"P2.0"とポート番号 + "." + ビット番号で特定のビットを指定しています。ところが
�Fでは、"TMIFH1"とビットの名称を直接記述しています。これがデバイスのユーザーズ・マニュアルでレジスタの説明中のビット番号が□で囲まれたものと、そうでないものの使い方の違いです。"TMIFH1"はIF0Hレジスタのビット3なので、"IF0H.3"と記述してもいいのですが、"TMIFH1"と書いた方が何を示しているかがはるかに分かりやすいはずです。ところが、"P2.0"のようにビットそのものには殆んど意味がないので、□はついていません。例えば、"P2.0"がモータの電源オン/オフの確認に使っているような場合には以下のように目的に応じて名前を定義して使ったほうが"P2.0"を"P20"とするよりははるかに分かりやすいはずです。

(2007/12)

C言語でプログラムする場合に他に注意点はありますか。

CC78K0やCC78K0Sではオプション・バイトには対応していないので、オプション・バイトについてはアセンブラで記述してください。
オプション・バイトの記述については、FAQのオプション・バイトの設定(78K0S/Kx1+,78K0/Kx2に共通)もご参照ください。

(2007/12)

CC78K0で割り込みを使うにはどうすればいいですか。具体的な例を示してください。

上記のタイマH1の割り込みを使う場合について示します。ただし、ここではタイマH1の設定そのものは省略して割り込みに関係した部分だけを説明します。
割り込みを使用するにはプログラムの頭の部分でそのための宣言を行う必要があります。通常は以下のような宣言となります。この2行目と3行目は割り込みを使う場合には必須となる割り込みの受け付けの許可や禁止を行う命令を使用可能にするための宣言です。この4行目が割り込みの宣言です。#pragma interruptの部分が割り込み関係の宣言であることを示しています。次のINTTMH1の部分はタイマH1の割り込みに関する宣言であることを示し、fn_intTimerIntervalの部分はINTTMH1の割り込みが発生したときに、実際に起動する割り込み処理関数の名前を示しています。


その上で、割り込み処理関数の本体部分は以下のように記述します。


これで、割り込み処理そのものの記述はおしまいです。あとは、メイン関数の中でタイマH1を起動した後に以下のように記述することで割り込み受け付けの準備は完了です。

(2007/12)

V850の場合には多重割り込みを行うために「__multi_interrupt」修飾子がありますが、CC78K0にはありません。多重割り込みは使えないのですか。

いいえ、多重割り込みは使えます。
78K0や78K0Sでは割り込みを受け付けると、プログラム・カウンタやPSWの値はスタックにセーブします。ところが、V850では割り込みを受け付けると、プログラム・カウンタやPSWの値は特定のレジスタにセーブされます。そのため、多重に割り込みを受け付けさせるにはこの特定のレジスタにセーブされた内容をスタッック領域に保存しなおす必要があります。
この処理をおこなうことを指定したのが「__multi_interrupt」です。CC78K0ではこのような処理が必要ないので、この修飾子はありません。多重割り込みを行ないたい場合には多重割り込みを許す割り込み処理の中で割り込みマスクを制御して、割り込みを許可する(ei();を記述する)だけです。多重割り込みについてはFAQの「割り込みの優先度制御の注意点[78K0S、78K0、78K0R]」も参照してください。

(2007/12)