徒然日記 電子工作編でタグ「H8OS」が付けられているもの

回路図-1 LCD-1-4.PNG いつまでもタコメータばかりやっているわけにもいかないので、一日一時間の枠を取っ払って仕上げにかかる。

 リセットスイッチ、FLASH 書き込みモード切替スイッチ、電圧測定用の分圧回路を組み込む。イグニッションパルスの入力回路は、ブレッドボードを使ってカットアンドトライをしたが、手持ちに丁度いいコンデンサがなかったので保留。

 電圧計測の AD変換はあっさり動いたので組み込むことに。簡単なオープニング画面を表示させて、いよいよ完全 ROM 化。

 Makefile に rom.mot を作るルールを追加、rom から起動するプログラム用のスタートアップルーチンとリンカスクリプトを持ってきて、コンパイル。
 リンカスクリプトの変更(1,2)を忘れていて多少手こずったが、CPU へのヘキサの書き込みは一発で動く。

 先に ROM 化したプログラムとあわせてヘキサが2本(H8OS も入れると3本)、メモリマップも奇々怪々。機会があれば一本化したほうがいいかも。

 あとは、注文した LCD をケースに入れて、ステラから信号を引っ張り出して...。

----
 エージングしていたんだが、表示がおかしい。正常な信号が入っているのに under と判断しているようだ。

 やっぱり、簡単にはいかないか。

 
 昨日作った ROM化した TimerA アクセスルーチンを使うためのプログラムを作る。

 「関数のポインタの配列へのポインタ」をアクセスするのに悩んだが、なんとか一発で動く。

 ROM にある関数のアクセスはこんな感じ。

enum {dummy,InitTimerA,GetTimerA_Counter};
#define func_tbl_ptr (int (**)(int))(*(volatile unsigned long *)0x5800)
int (**func_tbl)(int);
func_tbl = func_tbl_ptr;
func_tbl[InitTimerA](0);

 このあと、二つの *.mot ファイルを CPU の FLASH に書き込むのに手間取るが(結局二本の *.mot をエディターで結合した)、ROM 化した関数のアクセス・動作は問題なく成功。

 明日は TIimerW アクセスルーチンの ROM 化だ。



 プログラム全体のサイズが H8OS/3664 の RAM 領域で開発できる範囲を大きく超えることが明らかになったので、今まで作ったルーチンを少しずつ ROM 化していくことにした。
 最初はサイズが小さく機能も少ない TimerA 割り込み関連の処理から。H8OS 本体のリンカスクリプトを見ながら専用のリンカスクリプトを作る。関数ベクタテーブルの ROM 化に手間取ったがとりあえずそれらしい *.mot ファイルが完成。

 しかし、こういうのは最近の組み込みの範疇に入るのだろうか?いや、入るのだろうが、おそらく「プリミティブ」なごく一部な領域になるのだろう。

 今日はここで time up。明日は呼び出す側のプログラム作成、ROM への書き込み、そして debug だ。

----
 関数へのポインタの配列を定数化にするのに、少し悩む。

const int (*func_tbl[])(int) = {main,...};
 だと、const int を返す関数のポインタへの配列になってしまう。

int (* const func_tbl[])(int) = {main,...};
 正解はこちら。やっぱりポインタは難関だ。
----
 gcc は(同じファイルにない)外部関数のアドレスを引っ張ってこれる。以前使っていた 8/16bit の C コンパイラではこれが出来なくて苦労した記憶がある。
----
 今日、ヘキサファイルを眺めていて気付いたが、H8 の gcc はポインタが 4byte もある。コードがでかくなるわけだ。

 昨日少し調べたが、H8 CPU は 16bit レジスタが 16本もある。なるほど、C で割り込みハンドラを書くとスタックを馬鹿食いたくさん使うわけだ。


 昨日に引き続いて、タイマW のソースにタイマA を組み込むとうまく動かない不具合の調査。色々やっていくうちに、スタックがコードを食い荒らしているのではなかろうかと考え H8OS のメモリダンプやらメモリクリアを使って見て行くと、確かにスタックがコードまでは行かなくても bbs 領域まで侵食した跡が見える。

 割り込みハンドラの終わり方を間違ってスタックを食い続けているか、いや、ハンドラの管理は H8OS だし。CPU の data sheet を見ても特殊な「お約束」があるようにも見えないし...。

 あれこれやった結果、割り込みを使うとその分スタック使用量が増えて、H8OS のユーザーRAM 領域にまで入り込むらしいことがわかった。これなら使わないソースを組み込んだだけで動作がおかしくなるのも納得がいく。

 今日はここまでで 20分のオーバー。つまらないことで一日半も使ったと思うと悔しいが、2時間と思えば、そうでもない。

-----
 これ以上は RAM 上での開発は無理。ここから先は毎回フラッシュに焼いていかなくてはならない。CPU の書き込み制限 100回以内に完成させられるか?

----
 それにしても、H8 のメモリ利用率は、8086/Z80 に比べて異様に悪い気がする。気のせいなのか、いまどきの CPU はこんなものなのか?
 今日は H8-3664 のタイマの動作確認。フリーランで走らせて、オーバーフロー割り込みでカウンタをインクリメントさせてみた。あっさり成功。30分も時間が余った。

 こういう状況は考えていなかったので、次にやることが思いつかない (^^;。余った時間で H8OS ドキュメントの 3664 版との正誤表をちょっと作ってみた。

P4:下調べ

| | トラックバック(0)
 タイマ W を使った周期測定のために、タイマ W を使うための下調べ。

 H8OS 3.51 のソースに timer.c というファイルがあって、それを見ると関数 sleep はタイマVを使っていることになっている。ということはタイマV をいじって行けば sleep の動きに変化があるはず、とやっていくが思ったとおりの変化が得られない。タイマVのカウンタを直接読み出してもカウントしているようには見えない。一体なぜ...。

 よくよくソースを追って行くと 3664 版の H8OS は timer.c をリンクしていない orz。内部で H8_3664 の define も使っているのに...。
 H8OS のソースを sleep で grep すると、misc.c にも sleep 関数の定義があり、そちらではただの for の loop。

 少し調べた限りではタイマW もまったく使っていない模様。これはこれでありがたいが、ドキュメントを見ると、H8OS が 16bit カウンタを使っているとも書いてある。
 H8OS 3.51 のドキュメントはあまり当てにしないほうが良いか。フリーの、何年も前のソフトに文句も言えんし。

----
 今日はここで時間切れ。
 
 昨日作ったソースを見直してから動かしてみると...、動かない (; ;)。見直しをかけると、CGRAM に送るデータをコマンド(RS=0)として送っていた。そこを直すと無事動いた。フォントもこちらでイメージしたとおり。

 と、ここで不具合発見。自前のプログラムから直で LCD をアクセスするとうまく表示されない。一度 H8OS を使って LCD 表示をしてからだとうまくいく。初期化ルーチンに問題があるのか...。

 それはそれとして、今日の残り時間はコードを短くする検討に入る。
 ネットをあちこち回って調べると、皆さん色々とやっておられる。ソースは「 PIC24Fの紹介と実験」から拝借。データとフォントパターンの関係については、「 LCDのCGRAMに書き込んでみた・・・」のを参考にさせていただいた。

 コンパイルすると、「4byte ほど bss に fit できない」とリンカーがエラーを出してくる。H8OS+3664 だと開発に使える RAM は 1.25KB しかないのだが、もう一杯になってしまったか。ちょっとやりくりしてとりあえずメモリに収める。今日はここで時間切れ。
 マップファイルをちょっと見ると構造体を使った I/O のアクセスはかなりコード効率が悪いみたいだ。いろいろやる価値はありそうだ。
002.JPG 昨日で配線は終わったので、今日は LCD 表示のテストプログラムを作るところから。といっても、H8/OSのサンプルプログラムをチョコチョコといじくるだけ。のはずだったが、ポートの設定を自前でしなくてはならないので、オリジナルの H8/3067 のデータシートをダウンロードしたり、H8/3664 の設定レジスタを調べたりと時間がかかる。LCD をつないだポート(P56)は 3664N では出力に設定しないでくださいとあって焦ったが、I2C コントローラーとかぶっているだけみたいなので、ままよとプログラムを動かしてみる。

 プログラムを CPU に転送するのがうまくいかず、10回近くかかったが、正常に転送されたあとは一発で動いた。

 今日はここで時間切れ。
-----

 忘れていたが、H8/OS のページにある RAM 転送プログラムは速い PC ではうまく動かない。
 さて、どうしたものかとソースを見ると -w オプションで wait を入れられるじゃありませんか。
 これで次からは大丈夫だ。

----
 ソースはこんな感じ

#include    "../h8os/syscall.h"
#include    "../h8os/reg3664.h"
int main()            /*  C1-19 C1-18 C2-03 C1:17 C1:16 C1:15 C1:14    */
{                /*  RS:55 RW:54  E:56 D7:53 D6:52 D5:51 D5:50    */
    unsigned char    lcdport[] = {0x20, 0x10, 0x40, 0x08, 0x04, 0x02, 0x01};
   
    PMR5 = 0x00;
    PCR5 = 0x7F;

    lcd_setup(2, 16, &PDR5, lcdport);
    lcd_clear();
    write_mode(LCD);
        /*    1234567890123456    */
    write_string("CPU is H8/3664\n");
    write_string("H8OS is ready!");
}

とりあえず H8OS 上で動く、シリアルポートから文字列を返すだけのプログラムを組んで動作確認をする。

#include    "../h8os/syscall.h"

int main()
{
//    sio_speed(57600,16000000);
    write_mode(SIO);
    write_string("CPU is HD64F3664\n");
    write_string("H8/OS is ready!!\n");
}
 まずは、3664 の RAM にプログラムの転送ではまる。H8OS のコマンドインタープリターにコマンドがあるもんだと思ったらない。FDT から書き込むのかと思ったら違う (FLASH development toolkit だから当たり前か (^^;)、ドキュメントを良く見ると、RAM 転送ツールを使うと書いてあって、HP を良く見るとそういう名前のツールがある。それを使って、RAM に転送は成功。

 RAM 上のプログラムをコマンドインタープリターから実行すると動かない。.mot ファイルを良く見ると、なぜか ROM のある 0100 からデータがある。マップファイルを良く見ると BSS 領域の初期値。なぜ?
 よくよく調べると、リンカのスクリプトファイルで 'rodata' となっているラベルが 'rodata.str1.1'となっている。'str1.1'ってなに?
 とりあえずスクリプトファイルの rodata の後ろに rodata.str1.1 を追加してコンパイルすると。ROM 領域のデータは消えた。str1.1 か。 1.2 とかも出てくるんだろうか?

.text :    {
    *(.text)
    *(.strings)
    *(.rodata)
    *(.rodata.str1.1)   <---- 追加
        _etext = . ;
    }  > ram

 再度実行するが、まだ動かない。

 念のためにと、シリアルポートのボーレート設定をコメントアウトして再挑戦。やっと動く。

H8/OS >exec f9c0CPU is HD64F3664
H8/OS is ready!!

 executed.
 なんで sio_speed がうまくいかないのかわからないが、今日はここで時間切れ。というか 30分ほどオーバー。

----
 今日見つけたページ
 
GNU リンカ LD の使い方
 予定を変更して、
  1. 旧メインマシン(現iTunesサーバー)に VNC サーバーをインストール
  2. 旧メインマシンから現メインマシンへファイル共有できるようにする
  3. H8OS の API を使って、単にシリアルポートからメッセージを出力するだけのプログラムを動作させる
 を目標に作業開始。

 1 はほどなく終わったが、2 がうまくいかない 現 ->旧のファイル共有は出来たのだが...。あきらめて 3 に取り掛かり、.mot ファイルが出来上がったところでタイムアップ。

----
 明日は今日作った .mot ファイルの動作確認から

P4:H8OS 稼動

| | トラックバック(0)
 さて、今日はいよいよ H8OSをインストール。

 最初に半田付けの接続チェックをして....全部 OK....、メインマシンのシリアルポートにつなごうとすると...、シリアルポートがない!!! VGAのポートをシリアルと勘違いしていた orz。それではと、iTunes サーバーに使っている元メインマシンにつなごうとすると...、オス対オス?そうかメインマシンの VGA コネクターがメスなのでパソコン側のシリアルポートがメスだと勘違いした。RS-232C のストレートケーブル(メスーメス)を探してきて、パソコンに接続。ルネサスのページから FDT をダウンロードして CPU との接続を試みるが...、失敗。あれこれ調べると...、ストレートケーブルを本体に接続していない orz。
 ケーブルを接続すると FDT と CPU のコネクションはあっさり成功。H8OS のダウンロードも問題なく成功。
 手探りで H8OS コマンドインタープリターの通信速度 57600bps を見つけて、H8OS の動作確認完了。

 ポカミスがいくつかあったが、割とすんなり終了。ちょっと物足りなかったりしないでもない (^^;
-----
 明日からは LCD 周りを配線して、H8 OS の API  経由で LCD にアクセスして接続確認。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

track feed Subscribe in a reader
Powered by Movable Type 4.01