ColdFire MCF52233 基板 (7)

インターフェース誌の Web サイトのダウンロード・ページに 8 月 5 日付けで CygwinGCC + GDB のパッケージが、8 月 6 日付けで出荷時の初期状態の ROM データが、それぞれアップロードされています。
これで、FM音源プログラム作成が始められます。
ところで、多くの方が Blog で、この ColdFire 基板の話題を取り上げています。
この基板に関して、私は疑問に感じているのに、それらの Blog では触れられていない点がいくつかあります。
もちろん、私は、推奨されているパルストランス付き RJ-45 ジャックを使っていないので、それが原因という可能性もあるのですが、本当に他の方の基板は問題がないのか気になります。
まず、簡単にまとめると、次のようになります。

  1. 全2重 (Full Duplex) で接続されない
  2. コンソール入力のエコーバックがちょっと変
  3. telnet 出力が、途切れ途切れで、遅い
  4. ダイレクト実行の途中でハングアップする

1. -- 全2重 (Full Duplex) で接続されない

「SystemRegistry」ファイル中の「Speed = 0」がおそらくリンク・スピード 100M / 10M の切り替えの設定だろうと思い、この値を書き換えてみると、確かに 100M / 10M が切り替わります。
同様に、「Dup = 1」が全2重 (Full Duplex) / 半2重 (Half Duplex) の切り替えではないかと思って書き換えてみましたが、0 でも 1 でも半2重のままで、全2重にはなりませんでした。
ハブとの相性の可能性もあるので、別のハブでも試してみましたが、やはり結果は同じでした。
別に半2重で接続されても実用上は問題ないのですが、すっきりしません。
原因としては、次のようなことが考えられると思います。

  • そもそも「Dup=」が Duplex 切り替えの変数ではない
  • 外付けパルストランス回路の問題
  • ハブとの相性問題
  • SilentC システムのバグ、あるいは初めから全2重に対応していない

また、「Auto=」が Auto Negotiation の切り替えではないかと考えて、「Auto=1」と設定すると、全くリンクせず、Ethernet 側からアクセスできなくなり、シリアル・コンソールから元にもどして回復しました。

2. -- コンソール入力のエコーバックがちょっと変

たとえば、コンソールから「dir」と打ったときのエコーバックを 16 進数で示すと、

64 0D 1B 5B 31 43 
69 0D 1B 5B 31 43 1B 5B 31 43
72 0D 1B 5B 32 43 1B 5B 31 43

となります。 見やすいように、改行してあります。
行の最初の文字は、それぞれ「d」、「i」、「r」の文字自体のエコーバックです。
「1B 5B 31 43」は VT100 (ANSI) のいわゆるエスケーブ・シーケンス (CSI シーケンス) で、文字で表すと、

<ESC> [1C

となり、カーソルを右に1文字分動かす機能になります。
表示するコンソールによっては、表示が乱れて、入力がしにくくなります。
たとえば、LinuxCygwin のターミナルウィンドウは VT100 互換で、正しく表示される場合もあるのですが、何かの拍子に設定が変わって、入力した文字が2個表示される状態になる場合があります。
セッションの出力をテキスト・ファイルにキャプチャする場合にも、エスケープ・シーケンスが大量に記録され、邪魔になります。
GCC + GDB で開発する場合、LinuxWindows 上の Cygwin を利用する場合が多いですから、telnet セッションのウィンドウで表示が変になるのは困ります。

3. -- telnet 出力が、途切れ途切れで、遅い

これは telnet クライアントに依存するのですが、Windows 2000 / XP / Vista 上のハイバーターミナル / Tera Term では、出力が連続的に出ず、数百 ms ごとに少量ずつ、途切れ途切れに出る状態になり、結果として出力のスピードが遅い状態になります。
これは Cygwin 上の telnet コマンドでも同様です。
一方、Linux 上の telnet コマンドでは、問題なく連続的に出力されます。
Linux 版と Cygwin 版とでは telnet コマンド自体に本質的な違いはないと思われるので、これは OS 側の問題 (ファイアーウォール設定など) かも知れません。
一方、シリアル接続では全く問題なく、トータルのスピードではシリアルの方が速く、現状では telnet 接続で使うよりシリアル接続で使うほうが快適です。
また、「tftp」によるファイル転送ではスピードの問題はなく、「flood ping」では、1 ms 周期で繰り返される ping に対しても、きちんと応答しています。

4. --ダイレクト実行の途中でハングアップする

出力が大量に出るだけで、別に何でもないプログラム

{int i;for(i=0;i<32767;i++){PrHexWord(i);PrStr("\r\n");}}

をダイレクト実行させると、シリアル・コンソールから実行させた場合には最後まで走るのに、telnet 経由で実行させた場合には、基板の ACTLED が点灯しっぱなしの状態で、途中でハングアップしてしまいます。
これは telnet セッションだけではなく、ping にも応答しなくなります。
また、毎回同じ位置で停止するというわけでもないようです。
同じプログラムをファイルとしてセーブし、実行させると最後まで走ることが多いです。 (ハングアップすることもある)
SilentC はインタプリタですから、for(;;) 文の繰り返しは、ループ終了判定部のソーステキストのアドレスを記憶しておいて、ソーステキスト自体を何回も読み直すことで実現していると思われます。
プログラムがファイル中にあればソーステキストはフラッシュ ROM 上から、ダイレクト実行なら ソーステキストは RAM 上のバッファから読み込んでいるはずです。
両者の違いはその程度だと思うのですが、なぜ両者の振るまいが違うのかについては、よく分かりません。