2009年4月11日
秋月電子のシーモスネットワークボード(H8/3052F)を入手したので、hamayanさんのNavajoを載せてみた。
Navajo(ナバホ)とは、アメリカのユタ州、アリゾナ州、ニューメキシコ州の3州にまたがる自治区のアメリカ先住民族のNavajoよりとったものらしい。 Apache(アパッチ)に対抗したのだろうか。
ちなみに、日経新聞の4月16日の裏面の記事によれば、日本語の「こっち」はナバホ語の「コッチェ」、「あっち」は「アッチェ」にあたり、発音も似ているらしい。
|
|
まずは、hamayanさんのNavajoのページの、2003/7/5追記のところにあるように、RTL8019ASの100pinと4pinをジャンパーした。
|
|
例によって、HEWを起動し、hos-v4のライブラリを構築。
次に、H8/3052Fの新規プロジェクトを作成し、hamayanさんの「H8/3052F 秋月電子通商 有限会社シーモス用 プロトコルスタック 1.04版」をダウンロードし、すべてのソースファイルをプロジェクトに追加してコンパイル、リンクしてみると、udpclock.cのなかの「CYC_ID_MBX_CLOCK」がみつからないというエラーが出る。
LINKV5.SUBのなかには、「UDPCLOCK」は見あたらないようなので、udpclock.cはプロジェクトからはずしてみたら、エラーが出なくなった。
ビルドフェーズとして、PreConfigure、Configureの前に、NavajoConfigを登録し、navacfg.exeを実行するようにした。
|
FDTで、H8/3052FのフラッシュROMにプログラムを書込み、電源を入れると、シリアルポート(SCI1)より、クレジット
HOS-V4 for HITACHI H8/300H
Presented by Project HOS
が出力されたが、LCDの表示が乱れている。
CPU内蔵のフラッシュROMでの実行では速度が速すぎるのか、はたまた、LCDモジュールがよろしくないのか。
lcdkey.cの先頭のところに、「表示がおかしい時は、ループ数を増やす等、ここでタイミングの調整を行って下さい。」とあったので、
#define LOOP_COUNT_40 (((__CPU_CLOCK__ / 1000000UL) * 10) / 10)
のように変更して、waitを増やしてみたが効果は無いようだ。
void LcdWrite4( char c )
{
lcd->E = 1;
lcd->E = 1; /* 追加 */
lcd->DATA = c; /*データ書込み*/
lcd->E = 0;
}
のように、データの書込みの前にEパルスに余裕をもたせてみたら、それなりに表示するようになった。
それでも、まれに電源投入直後になにも表示しないときがある。
LCDの初期化処理のあたりのwaitが充分ではないのだろうか。
|
2009年4月12日
毎回H8/3052FのフラッシュROMにプログラムを書込んでいたのでは、そのうち書込制限回数を超えてしまいそうで心配になったので、プログラムをSRAMにダウンロードして動かしてみることにした。
(ただし、Navajoのコード部分とRAMの部分を合わせると、1MbitのSRAMにはおさまらないので、4MbitのSRAMにする必要がある。)
「H8/3052F 秋月電子通商 ネットワークボード用(SRAM有効)デバッグモニタ第3版」をダウンロードして、フラッシュROMに書き込んだ。
リンクのセクションの設定を下図のように変更してリンクし、Htermで読み込んで実行させてみたが、なんだか動かない。 |
|
ユーザインターフェースをSCI1に接続して実行させていたのを、HtermもSCI1に接続したのでは動かないのはあたりまえだ。
回路図を見ると、SCI1のほかに、SCI0が使えるようなので、HtermでのデバッグをSCI1で行い、ユーザインターフェースのほうをSCI0に変更してみることにした。
SCI0は右の写真のようにコネクタをつなげるだけで済む。
|
|
SCI0は、tcp2seri.cだけで使用されているようなので、comm.hの #define SCI_1
1 を #define SCI_1 0 に変更し、system.cfgやact_tsk(TID_SCI_SND0);なども変更し、それなりに動くようになった。
ところが、DHCPに失敗するようになってしまった。
H8/3052FのフラッシュROMにプログラムを書込んで動かしていたときは、問題なくDHCPに成功していたのに、どうしたことだろう。
DISCOVERパケットを送信しても、OFFERパケットを受信しないようだ。
デバッグしてみようとして、RequesetDHCP();でブレークして、そのまま実行するとOFFERパケットを受信した。
ということは、RequesetDHCP();の前に、dly_tsk( 1000 );を入れてみればどうなるか試してみたら、ブレークをかけなくてもDHCPに成功するようになった。
なにかタイミングの問題があるのだろうか。
|
|
|