SATAのIPコアでHDDのDevice IDの取得に成功

SATAのIPコアの開発をはじめて、もう６日になります。
ようやくHDDのDevice IDが読めるようになりました。

こうやってEXPARTAN-6TのSATAコネクタとHDDとをつないで実験しています。

リンク層が送受信ともにできたので、適当なパケット（フレーム）を送ってみました。
まずは、ハードディスクとのリンクアップした後に、デバイスから最初に送ってくるフレーム「34005001 01000000・・・」というものです。これは、デバイスの初期化が完了して、TFR（ATAのレジスタ）やステータスをホストに送ってきているものです。これを、そっくりそのままデバイスに送ることにしました。すると・・

このフレームのCRCは正しいはずなのですが、R_ERRが返ってきてしまって、正しく受け入れられていないことがわかります。それもそのはず、先頭の「34」というのは、デバイス→ホスト方向の転送のタイプを示すためです。
おそらく相手側のリンク層はよくても、トランスポート層ではじかれてエラーとなったのでしょう。

次に、ホスト→デバイス方向の正しいフレームを送ってやります。すると、

おおっ、ちゃんとR_OKが帰ってきました。受け入れられるのって何だか嬉しい！

フレームのエラーチェックは、リンク層だけではなくトランスポート層でも判断しているのですね。しかし、どちらの層でエラーとなっても返るのはR_ERRですから、SATAというのはシンプルなプロトコルです。

フレームがちゃんと相手に伝わっていることがわかったので、つないだハードディスクに対してIDENTIFY DEVICEコマンドを発行してみました。すると、見事にDevice IDが取得できました。

送信したフレームの中身は、2780EC00 00000000 00000000 00000000 00000000というものです。
27はホスト→デバイス方向の転送を示し、80はコマンドを与えることを示し、ECはIDENTIFY DEVICEのコマンドです。
帰ってきたフレームは２つありました。最初に「PIO setup Device to Host」というフレームが来て、次に「Data Device to Host」というのが来ました。PIO setup Device to Hostは「これからデータを送るよ、長さは○○バイトだよ」と知らせてくるものです。

setup のフレームの中身は、5F605800 00000000 00000000 00000050 00020000でした。これは512バイトの後続データがあることを意味します。

Data Device to Hostフレームの中身は、46000000 5A0CFF3F 37C81000 00000000 3F000000 00000000 20202020 20202020 20202020 56393453 31563953 00000000 04004343 48312020 20205453 31333035 33303134 53412020 20202020 20202020 20202020 20202020 20202020 20202020 00001080 0000002F
・・・（略）
というものでした。

手作業で解読すると、
・論理シリンダ数=16383
・論理ヘッド数=16
・論理セクタ数=63
・シリアル番号 9V34V139
・ファームウェアのバージョン="CC1H "
・型番 ST31500341AS
となっていました。
（ちなみに、実験に使っているHDDはSeagate社のBarracuda 7200.11。特定のファームウェアに致命的な不具合があって突然壊れるといういわくつきのもの。まぁ、怖くて使えないジャンクHDDですわな。）

正しくよめているようです。
ここまで動いたので、ひとまず安心です。

SATAリンク層のCRC受信回路の作成

昨夜は寝てしまったので、今日は朝からSATA IPコアの開発です。

リンク層の受信部分ができました。
デスクランブル回路とCRC計算回路がややこしいのですが、うまく動きました。

SOFが来たら、スクランブルの値(rx_scramble)をx"C2D2768D"に初期化し、以後、PureDataを受信するたびに
rx_scramble <= rx_scramble_gen(rx_scramble);
と進めていって、その値とPHY層からあがってきた受信データをXORしてやれば出スクランブルできます。
dscr_rxdata <= phy_rd_data xor rx_scramble;
なお、rx_scramble_genというのはVHDLで作ったFunctionで、中身はXORの塊です。

CRCも同様で、SOFが来たらCRCのレジスタをx"52325032"に初期化して、
以後、PureDataを受信するたびに
rx_crc_val <= crc32_gen(rx_crc_val xor dscr_rxdata);
と進めていけばCRCの計算ができるわけです。
crc32_genもVHDLで作ったFunctionで、中身はXORの塊です。

そして、rx_crc_val xor dscr_rxdataとしてあるのがポイントで、CRCの計算結果と、受信してデスクランブルした結果が一致すれば、EOFを受信したときに関数crc32_genに入れるデータが0になるので、rx_crc_valも0になります。このためチェックも楽です。

EXPARTAN-6TにSATAデバイス（ハードディスク）をつないで実機で確認してみたところ、ちゃんと受け取ったデータのCRCが一致していることが確かめられました。フレームのEOFを受け取ったら、R_OKというプリミティブを返します。

次に、わざとCRCでエラーを起こすような実験をしてみました。フレームを受信したらR_ERRを返します。すると、デバイス（ハードディスク）は何度もリトライしてくるようになりました。

期待通りの動作になりました。

SATAリンク層の受信部分の作成

SATAのリンク層を作成しています。

受信したデータの中から各種プリミティブを抽出する回路を作るわけですが、厄介なのはCONTプリミティブというやつです。CONTを受信したら前のプリミティブを受信したことにしなければなりません。また、ALIGNプリミティブは無視してリンク層では関与しないようにします。

このようにして、プリミティブとPureDataをデコードする回路を作りました。

そして、受信したプリミティブに応じてリンク層ステートマシンを動かし、相手からのデータを待ち受けるようにします。相手がX_RDYを送ってきたらR_RDYを、SOFが来たらR_IPを、EOFでR_OKを送ります。

このようにして適切な応答を返すと、１フレームがうまく受け取れます。

フレームの中のデータはスクランブルがかけられているので、それをデコードする回路を作ります。
スクランブルの初期値は8D76D2C2で、データを受け取るたびに68B3261F、6C4308A5、54D35234、0295558A、1BBE1ABB・・と変化していきます。この生成式はXORの塊です。

受信したデータに、このスクランブルの系列をXORしてやると、本来のデータが復元できます。

最初に受信した6DWordのパケットは、スクランブル解除すると、34005001 01000000 00000000 01000000 00000000 952405DCでした。最後の952405DCというのはCRCです。
34というのがパケットのタイプを示すもので、Register Device to Hostというコマンドを示します。50というのはステータスのようで、正常のときにこの値になるみたいです。

次はCRCをチェックする回路と、フレームを送信する回路を作ろうと思います。

SATAのパケット解析

SATA IPコアの物理層が動き出したので、今度はリンク層を作っています。

ハードディスクがX_RDYというプリミティブを送ってきたら、R_RDYというプリミティブを送り返します。
すると、SOFから始まる何らかのフレーム(FIS)が送られてくるのが確認できました。

これが最初に受信したパケットです。

解析してみたところ、SOF データの中身 EOF WTERM WTERM CONT ・・・　となっていました。
データの中身は、「B9 76 82 C3 69 B3 26 1F 6C 43 08 A5 55 D3 52 34 , 02 95 55 8A , 8E 9A 1F 67 」です。最後の4バイトはCRCなのはいいのですが、データにスクランブルがかけられているため、中身はさっぱりわかりません。

これを解読するには、デスクランブル回路を作らなければならなそうです。

SATAのコアを開発しています

4月ごろにちょっと始めたSATAのIPコアですが、本格的に開発することになりました。
納期は9月中旬だと思っていたのに、8月末になってしまいました。
というわけで突貫工事で開発中です。

今日は物理層がリンクアップするまでができました。

EXPARTAN-6Tには、ホスト用とデバイス用の2つのSATAコネクタがあります。
なので、IPコアもデバイスモード（ハードディスクをエミュレートするモード）とホストモード（マザーボードをエミュレートするモード）の両方を一緒に開発します。

IPコアをデバイスモードにし、パソコンのSATAコネクタにEXPARTAN-6Tのデバイス用のSATAコネクタをつなぎ、波形をキャプチャしてみました。

最初にデバイス初期化時の波形を見てみます。

まず、デバイス(EXPARTAN-6T)からCOMINITというリセット信号を送信し、ホストPCからのCOMWAKEを待ちます。その後、COMWAKEを送信します。

そうしたらAlignプリミティブやSyncプリミティブを送信して、リンクアップ完了です。

SATAでは32bit単位で送受信します。最初の1バイトがK符号ならばプリミティブといって制御用の符号になり、全部がD符号ならば純粋なデータとなります。
プリミティブには、
・ALIGN(K28.5 D10.2 D10.2 D27.3) クロック再同期や弾性バッファの調整に使われる
・SYNC(K28.3 D21.4 D21.5 D21.5) アイドル状態
・CONT(K28.3 D10.5 D25.4 D25.4) 直前のプリミティブを繰り返すときに使う
・X_RDY(K28.3 D21.5 D23.1 D23.1) フレーム送信の開始要求
・SOF(K28.3 D21.5 D23.2 D23.2) フレームの開始
など、全部で18種類ほどあります。
物理層で使うのはALIGNだけです。

次に、IPコアをホストモードにしたときの波形です。

EXPARTAN-6Tに、適当なハードディスクをつないで準備完了です。
デバイスからのCOMINIT(リセット要求）を受信したら、COMWAKEを送信します。デバイスから返事のCOMWAKEを受信したら、ALIGNプリミティブを待ちます。

リンクアップするときには、デバイス(ここではHDD)から、ALIGNプリミティブとSYNCプリミティブが送られてきます。その後、CONTプリミティブが送られてきます。

SATAでは同じ信号が連続して送られてEMI放射が増加することを嫌います。そのためデータにはスクランブルがかけられることになっていますが、プリミティブにはスクランブルがかけられないので、同じプリミティブを連続して送る場合にはCONTプリミティブとJunkデータを使って代替してもよいことになっています。

つまり、SYNC SYNC SYNC SYNC SYNC ・・・の代わりに、SYNC CONT Junk Junk Junk ・・・としてもよいということです。Junkデータにはスクランブルがかかるので、同じ符号が連続して送られることがなくなります。
ややこしいうえに、ユーザには特にメリットがない仕様です。

だからCONTが来たら直前のプリミティブの連続と解釈しなければなりません。

リンクアップしてしばらくすると、X_RDYというプリミティブとCONTが送られてきました。

X_RDYは、「何か送りたいデータがあるんだけど」という意味です。これもCONTプリミティブを使っています。
これに対してホストがR_RDYで応答すれば、次のデータを送ってきてくれるようになるのでしょう。

SATAではハードディスクのほうからX_RDYを送ることで、最初の通信が始まるということがわかりました。ホストのほうからは特に何も送信しないようです。

RX62NでTCP/IPのプロトコルスタックを作ろう

RX62NでTCP/IPのプロトコルスタックを作ろうと思います。
対象ボードは、究極のRX62Nボードと、RX-MEGA。

ルネサスのサイトには「Webサーバ」のサンプルコードがあるのですが、これはuIPというのを使っていて超スパゲッティーなのです。

これをビルドするには、WebサーバとかTELNETサーバとか、アプリケーションをあらかじめ決めておいて、それに対応したヘッダファイルをincludeすることで選択するようで、アプリケーションに応じた「構造体の型」がtypedefされていて・・まあなんだかわけのわからない構造なのです。さらには擬似マルチスレッドを複雑なマクロで実現しようとしていたり、マクロの塊で何がどうなっているのかさっぱり。

任意のポートを開いて、受信したデータに応じて処理する、という普通の感性じゃないのです。uIPを拡張して何かを作るというのは極めて困難だと思いました。

そういうわけで、車輪の再発明になることを覚悟で、RX62N用のシンプルなTCP/IPプロトコルスタックを開発することにしました。

今日はARPができました。

ARPっていうのは、TCP/IPが通信する前に、IPアドレスに対応したMACアドレスを調べるところで使うプロトコルです。ARPリクエスト(○.○.○.○番のIPアドレスは誰ですか？)と、ARPリプライ(○.○.○.○番のIPアドレスは私です)があります。

自分のIPアドレスは192.168.1.123、MACアドレスは02-00-00-00-00-01に設定しています。このMACアドレスはローカルMACアドレスというもので、ネットワークの管理者が決められる範囲のものです。

RX62NがARPのリクエストを受け取ったら自動的に応答するようにしました。その結果、ホストPCのARPテーブルに追加されることも確認しました。

また、RX62N上のコンソールから、特定のIPアドレスを調べるARPパケットを発行できるようにしました。取得したARPのテーブルは4つまでメモリ上に格納するようにしました。

自分で作ったパケットが、他の機器に受け入れられるって、やってみるととても面白いです。
TCP/IPに、どっぷりはまりそう。

次はDHCPに挑戦してみたいと思います。

RX62NとArduinoUNOとMARY(LPC1114)の速度対決

3つのメジャーな組み込み向けCPUで、フラクタルの描画速度を比較してみました。

①　左上にあるのがMARYボード。NXPのLPC1114(ARM Cortex-M0)が乗っています。
②　左下にあるのがArduino UNO。ATMELのATMEGA328P@16MHzです。
③　右にあるのがインタフェースのRX62N付録基板と拡張ベースボードRX-MEGA。
　　　ルネサスRX62N@96MHzが乗っています。

速度の対決の一部始終は、次のムービーをご覧ください。

MARYとArduinoUNOはほぼ同じ速度でした。MARYとArduinoが30秒ほどしてフラクタルの一部を苦戦しながら描いているときに、おもむろにRX62Nの電源を入れました。あっという間にフラクタルを描けてしまっています。

このウサギは油断しません。次々とフラクタルを描いてカメを追い抜いていきます。

MARYとArduinoUNOは、最初の1枚の絵を描くのに204秒かかります。しかし、RX62Nはわずか2秒しかかかりません。RX62Nの演算速度はArduinoやMARYのそれと比較すると約100倍です。
この差はクロック速度の差だけではありません。内蔵の浮動小数点演算器やアーキテクチャの素晴らしさによるものでしょう。

RX62Nは圧倒的な速さです。気の短い江戸っ子にもお勧めです。
フィジカルコンピューティングに速度が必要だったら、迷わずにRX62Nでしょう。

IF誌付録RX62N用豪華拡張基板「RX-MEGA」の詳細はこちらへどうぞ。
http://www.tokudenkairo.co.jp/rxmega/

RX-MEGAのリソースCD-ROMをバージョンアップ！

お待たせしました。

特電のRXのノウハウがぎっしり詰まったCD-ROMをリリースしました。
これを、RX-MEGAをお買い上げいただいた、大切な大切なお客様にお贈りします！

今回、『MITOUJTAG RX特別版』は大きくバージョンアップしました。
RX-MEGAボードや、究極のRX62Nボードを認識すると、自動的にファームウェアがアップデートされ、約３倍に高速化されます。もちろん、JTAG ICEはMITOUJTAGに統合され、安定動作と使いやすさが向上しました。

バウンダリスキャンでは毎秒160回程度、端子の状態をサンプリングできます。
世の中にRX62Nのボードは数多くありますが、私の知る限りでは、JTAGバウンダリスキャンでRX62Nの端子の状態がサンプリングできるのはこれだけです。

具体的には、何がバージョンアップしたかというと、
① JTAG ICEが統合されたMITOUJTAG BASIC特別版を同梱しました！
② ボード上に乗っているUSB-JTAG ICEの速度が約３倍に高速化しました！
③ Linux版、MAC版、Cygwin版のGCCを同梱しました！
④ RXduinoと特電HAL、およびデバイスライブラリの完全なるソースとサンプルコードを含めました！などなど、盛りだくさんです。

このCD-ROMのMITOUJTAGは、RX-MEGAボードでも、究極のRX62Nボードでも使えます。
オンボードのUSB-JTAGを使うと、とてもケーブルがすっきりします。

だから、電車の中でも違和感なく開発やデバッグができると思います。

JTAG　ICEのダウンロード速度は約1.8kB/secです。軽めのプログラムならストレスなくダウンロードできます。
FDTを使わなくてもROMに書き込めます。書き込みと実行で、ジャンパを切り替える必要もありません。

また、RX62Nのいろいろなパッケージが選択できるようになりました。

本日以降にRX-MEGAをご注文いただいた方には、この新しいCD-ROMをお送りします。
また、これまでにお買い上げいただいた皆様には、別途CD-ROMを郵送させていただきます。今週末には皆様のお手元に届くと思われます。
それではRX62Nで楽しい週末をお過ごしください！！

RX62Nでマンデルブロー集合を描いてみた

MARYのOLED基板に、マンデルブロー集合を描くデモを行ってみました。

RX62Nには浮動小数点演算器が内蔵されているので、たまにはそれを駆使してあげることにしました。次の動画をご覧下さい。

Webコンパイラにコードを貼り付けて、コンパイルして、メモリマップや逆アセンブラリストを確認し、MITOUJTAGのJTAG ICE機能を使ってRAMにダウンロードして実行しています。その一部始終を上のようなムービーにしました。
ピッピッピと音がしているのは、画面を１回更新したときに音を鳴らすようにしているためです。そうすれば、RX62Nの演算の実力がわかるだろうと思うわけです。

なお、コンパイルオプションは-O2をつけて最適化しています。

コアな部分のプログラムを示します。

// 複素数の乗算 C = A * B

void complex_mult(float ar,float ai,float br,float bi,float *cr,float *ci) {

  *cr = ar * br - ai * bi;

  *ci = ar * bi + ai * br;

}

　

// 複素数の絶対値の二乗を得る

float complex_abs2(float r,float i) {

  float ar,ai;

  complex_mult(r,i,r,-i,&ar,&ai);

  return ar;

}

　

// 繰り返しの処理

void loop() {

  OLED_move_position(MARY2,0,0); // MARYの書き込みモードセット

  for(int y = 0;y < 128;y++) {

    for(int x = 0;x < 128;x++) {

      float cr = (x - 64) / 64. / mag + offsetx;

      float ci = (y - 64) / 64. / mag + offsety;

      float zr = 0, zi = 0;

      int t; // 何回繰り返せば発散するか

      for(t=0;t<64;t++) {

        if(complex_abs2(zr,zi) > 2) break;

        complex_mult(zr,zi,zr,zi,&zr,&zi);

        zr += cr; zi += ci;

      }

      OLED_Send_Pixel(MARY2,generateColor(t,16)); // 1ピクセル描画

    }

  }

  mag = mag * 1.03; // 視点の移動

  offsety += 0.001;

  offsetx += 0.0016;

}

これでRX62Nのプログラム開発や、ダウンロードがとても楽にできるようになりました。

RX62NのWebコンパイラがパワーアップ

RX62NのWebコンパイラがパワーアップしました。

こちらにあります。
http://www.tokudenkairo.co.jp/rxmega/webcomp/
ご利用は無料です。

まずは次の画面をご覧下さい。ぱっとみて分かるように、デザインが格段に綺麗になりました。

特に、このサンプルコードと書かれた部分に注目してください。

サンプルコードにはCで書かれたものや、C++とRXduinoで書かれたものなどいろいろあります。イーサネット・パケット・キャプチャのようなものまであります。

このリンクをクリックすると、ソースコードのところにいろいろなサンプルコードがロードされます。次の図は、GPIOをArduino風に操作するサンプルコードを読み込んだところです。

サンプルをロードしたら、「コンパイル実行」と書かれたボタンを押すだけです。

でも、ちょっとその前に、ビルド時のオプションが選べるようになりました。

この項目の意味するものは何かというと、
・ターゲットボード・・・ビルド対象のボードを選びます。生のデバイス単体の場合、RX-MEGA基板、究極のRX62Nボード、Interface誌付録基板から選べます。（実際には何を選択しても同じものが生成されます。）
・使用するライブラリ・・・どのライブラリを使用するかを選びます。Arduino風スケッチ風に書くならば「RXDuino」を、C言語でガリガリ書くならば「特電HAL」、ライブラリを全部自分で作りたいならば「なし」を選びます。RXduinoを選ぶよりも特電HALを選んだほうが、若干、ファイルのサイズが小さくなります。
・メモリマップの配置・・・RAM実行用を選択すると0x0000000番地から、ROM化用を選択すると0xFFF80000番地から配置されます。
です。

コンパイルボタンを押すと、コンパイルされて、その結果が表示されます。

もし、コンパイルやリンク時にエラーやWarningが出た場合は、画面にその旨が表示されます。

コンパイルに成功したら、「ELFダウンロード」というボタンを押すと、生成されたELFファイルがダウンロードされます。ROM化の場合はMOTファイル（Sレコード）もダウンロードできます。

このファイルをダウンロードして、JTAGデバッガなどでROMに書き込めば、すぐに動かせます。

また、「MAP表示」というボタンを押すとメモリマップが表示され、「逆アセンブラ」というボタンを押すと、出来あがったELFファイルを逆アセンブルして表示してくれます。

パケットキャプチャのプログラムを生成して、動かしてみました。

こんな感じで、RX62Nのプログラムがすぐに、無料で、あっという間に作れるようになりました。
WindowsパソコンにGCCのRX用コンパイラをインストールするのは結構な手間がかかるので、すぐにRX62Nを試してみたい方は、ぜひともご活用ください。

http://www.tokudenkairo.co.jp/rxmega/webcomp/

RX62NのプログラムをWebでコンパイルできるようにしました！

RX62NのプログラムをWebでコンパイルできるようにしました！
Interface誌の付録基板用のプログラムを生成することができます。
これは、完全無料でオールフリーです。
どなたでもご利用いただけます。
RX-MEGAや究極のRX62Nボードをお買い上げいただいていない方でも、ご利用いただけます。

具体的にいうと、RX-ELF-GCCをサーバ上において、PHPやJavaScriptを駆使して、サーバ上でコンパイルして、出来上がったELFファイルをユーザに返すようにしました。

まず、下記のURLにアクセスしてください。
http://www.tokudenkairo.co.jp/rxmega/webcomp/index.php

次のような画面が開きます。
setup()とloop()というArduino風の関数が見えます。

ここに、貴方が作ったスケッチを書いください。

コンパイルボタンを押すと・・

このとおりコンパイルされて、結果のELFファイルと、MAPファイルがダウンロードできるようになります。

RX-MEGAや究極のRX62Nボードをお買い上げいただいていない方でも、ご利用いただけますので、是非ともお気軽にお試しください。

細かい修正は、後日、行います。

RX-MEGAでSD/MMCカードがアクセスできるようになった

Interface誌付録RX62N用の豪華拡張基板『RX-MEGA』で、ようやく、SD/MMCカードが自由自在にアクセスできるようになりました。

ChanさんのFatFSを使わせていただいているのですが、Interface誌に掲載されているものはHEWでコンパイルされていました。それをGCCに移植しようとして、つまらないことで、いろいろ苦労しました・・

修正すべき箇所は、mmc_rspi.cの中にあります。

まず、GCCではiodefine.hで定義されている　･･･.BIT.･･･　の記述が使えません。（構造体のビットフィールドの順序をHEWでは反転できるけど、GCCではできないから）
したがって、モジュールスタンバイレジスタをつかさどるマクロも使えません。
まぁ、これらは、手作業でやればいいのですが、

PORTC.ICR.BYTE |= 0x80;

IOPORT.PFGSPI.BYTE = 0x0E;

SYSTEM.MSTPCRB.LONG &= ~(1 << 17); 

次に、悩ましいのが、これです。

#ifdef __LIT

#define LDDW(x) revl(x)

#else

#define LDDW(x) x

#endif

HEWはリトルエンディアンでコンパイルすると自動的に__LITというマクロが定義され、LDDW(x)がrevl(x)になります。GCCでは__LITが定義されていないので、違う結果となります。

それなら、#define LDDW(x) revl(x) だけ有効にすればいいかというと、そうではなくて、revl(x)というのはHEWで定義された、DWORDサイズの変数のエンディアンを入れ替えるという特殊なマクロ関数なのです。おそらく、RXのREVLというアセンブラ命令に置き換えられるのだと思います。
しかし、GCCではREVL命令を直接書けないので、

unsigned long LDDW(unsigned long x)

{

	return  ((x        & 0xff) << 24) |

	       (((x >> 8)  & 0xff) << 16) |

	       (((x >> 16) & 0xff) << 8 ) |

	       (((x >> 24) & 0xff) << 0 );

}

などと、軟弱な関数で置き換えます。
あと、RSPIの内蔵レジスタを触るところでBITが使われているところをこまめにANDやORに直していきます。

最後に、FatFSには、 void disk_timerproc (void) という関数があります。これを1msごとに呼び出してやらねばなりません。これを忘れていたために、動作が安定しないということにずーっと悩まされてきました。
また、カードが挿入されたかどうかをI/Oピン(INSというマクロ経由で)で知るようになっていますが、カードの挿入スイッチをI/Oポートにつないでいなければ、これを適当に置き換える必要があります。

そんなこんなで、ようやく動くようになりました！

SDカードを挿せば、対話型のコマンドでディレクトリが見れます。

ファイルの日付の表示は、西暦ではなく元号（といっても昭和と平成のみ対応）にしました。

ディレクトリだけではなく、ファイルの中身も見えます。

この対話型インタフェースの上から、テキストファイルを作ったり、削除することもできます。

RX-MEGAでは、デフォルトではI/Oポートに挿入キーがつながっていないので、SDカードを交換したらinsコマンド打ちます。すると、新しいディスクに交換されたと認識されます。

いろんなカードで速度を測定してみると、750～950kB/secの範囲でした。

バスの速度が24MHzなので、その3分の1程度しか出ていない計算になります。送受信の部分をアセンブラで書けば、おそらく2倍は速くなると思います。

このサンプルプログラムは、13日の未明までにアップロードします。
RXマイコンをコンソールで叩いて、SDカードの中を読み書きできるのって、結構楽しいですよ。

RX62Nのバウンダリスキャンとオープンショートテスト

明日、MITOUJTAG Proのデモを行うためちょっと遠くまで出かけるのですが、その予行練習で今、MITOUJTAGの基板検査機能の確認をしていました。

XILINXの評価ボード上のSDRAMの内容を読み書きしたり、そんなことをいろいろやっていました。

そのJTAGバウンダリスキャンテストの中のひとつに、「オープンショートテスト」というのがあるのですが、要するに、バウンダリスキャンで端子をH/Lに振ってみて、その線の挙動を見るテストです。オープンなのか、プルアップ/プルダウンされているのか、電源にショートしているのかがわかります。

今日の昼まで「何か手ごろなマイコンの評価ボードはないかな・・」と会社の棚を探していたのですが、よくよく考えてみたら、自分のところで開発していたのを忘れていました。

思い出したように、究極のRX62NボードにMITOUJTAG Proをつなぎ、オープンショートテストのスクリプトを走らせて見たら・・・

(クリックで拡大します)

見事に動くではないですか！
クックックッとテストが走っていって、SDRAMのCKEはプルダウンとか、SDカードのCSはプルアップとか、RMIIのMDCはプルアップとか、見事に言い当ててくれます。

回路図を見ながら正しい状態をファイルに記述しておけば、各ピンの状態があらかじめ定義しておいたファイルのとおりになっているかを調べて、総合的なOK/NGを判断してくれます。

定義ファイルというのはこんな感じです。

昨年までは、他社製ボードを持って歩いてデモしていたのですが、もう、そんな必要はなくなりました。RX62Nはバウンダリスキャンに対応していたのです。
開発した目的を思い出しました。

SDRAMの挙動とかもみえて、ばっちし。

RXduinoに加速度センサとジャイロをつなぐ

国産RX62Nマイコンでフィジカルコンピューティングを実現する、
RXduino(アールエックスデュイーノ)のサンプルコード集を作っています。

昨日は、秋月で買ってきたジャイロと加速度センサの実験をしました。

コードはとても簡単で、

// RX62NのGCCサンプルプログラム 

// 圧電振動ジャイロサンプル 

// (C)Copyright 2011 特殊電子回路 

#include <rxduino.h>

#include <stdlib.h>

　

void setup() 

{ 

    Serial.begin(38400); 

　

    pinMode(PIN_SW,INPUT); 

    pinMode(PIN_LED3,OUTPUT); 

} 

　 

void loop() 

{ 

    int val1,val2; 

    int analogPin1 = 1; //アナログ入力の１番ピン 

    int analogPin2 = 2; //アナログ入力の２番ピン 

　  

    Serial.println("RXDuino 圧電振動ジャイロテスト"); 

    Serial.println("G1_data, G2_data"); 

    while(1){ 

        val1 = analogRead(analogPin1); 

        Serial.print(val1,OCT); 

        Serial.print(" , "); 

        val2 = analogRead(analogPin2); 

        Serial.println(val2,OCT); 

        delay(20); 

    } 

} 

たったの、これだけです。
これだけで、Interface誌の付録基板からアナログ値をとりこんで、シリアルコンソールに出力できるのです。1900ページある、ハードウェアマニュアルを読む必要はありません。RX62Nの内蔵レジスタをちょくせつ触る必要はありません。

パソコンに取り込めば、こんな感じでグラフになります。

そのほかにもいろいろなコードのサンプルを作っています。
詳しくは、こちらのページに掲載しています。
http://www.tokudenkairo.co.jp/rxmega/doc/index.html

このRXduinoのライブラリは、RX-MEGA基板（紫色の拡張ボード）なしでも動きますから、最終的に組み込む形態、つまりCPU単体でも動きます。
やっぱり、これからの時代のフィジカル・コンピューティングは、国産マイコンでいきましょう！

◆　追記
現在のRX-MEGAの在庫は8台です。お早めに！
◆◆　追記２
明日（土曜日）の夜には、MITOUJTAG特別版用の高速化パッチをリリースする予定です。書き込みが約3倍速くなります。

RX62N用特電HALをリリースしました

RX62N用特電HALをリリースしました。

特電HALというのは何かというと、RX62Nの内蔵ペリフェラルを簡単に使えるようにするためのライブラリです。

RX62Nには、GPIOやイーサ、SCI、SPI、I2C、RTC、EXDMAC、USBなど様々なペリフェラルが内蔵されていますが、特電HALはそれらを使いやすくします。

ルネサスのペリフェラルジェネレータを使うと、すべてのペリフェラルが渾然一体となったわけのわからない巨大なコードが生成されますが、特電HALはとてもシンプルです。

いままでこういったライブラリを何度か作っては壊し、作っては壊しして、ようやく仕様が纏まってきました。その上、先日Arduino互換のRXduinoを作ろうとして一緒に開発したためごちゃごちゃしていましたが、今回のリリースではしっかりと分けました。

このHALは、C++ではなくC言語で書かれているので余計なコードが追加されることはありません。また、このHALの上にRXduinoライブラリをのせて、duinoアプリをC++でお手軽に開発することもできますし、C言語でぎちぎちのネイティブアプリを開発することもできます。（新しいRXduino環境は近日中にリリースします。お楽しみに。）

現在のところ、このHALではGPIO、Ether、RTC、SCI、SPI、DAC、ADC、Timerが動きます。使うときにはGNUリンカで-ltkdnhal とオプションをつけるだけでOKです。実際に使われるモジュールだけがリンクされるようになっているので、出来上がるオブジェクトのサイズはかなりコンパクトです。

こんなライブラリですが、ドキュメントはDoxygenで作成しました。だから綺麗です。
使い方はこちらをご覧下さい。

HALはこちらからダウンロードできます。イーサとRTCとGPIOとADCのサンプルプログラム付です。さらに、今ならソースもついてきます。
イーサのサンプルアプリは先日のパケットダンプのプログラムです。ちょっと楽しめます。割り込み駆動のLink Up/Down検出も対応しました。

そのほか、RX-ELF-GCCのMAC OSX版と、Linux版（Ubuntu 32bitと64bit版）もリリースしました。

ダウンロード可能なものの一式は下記のページに用意しました。
http://www.tokudenkairo.co.jp/rxmega/download.html

皆様のRX62N開発環境がよりよいものになりますように。

◆追記

すごいことを発見したのです。
Interface誌付録のRX62Nの型番はR5F562N7BDFBです。N7というデバイスはRAMが64kB（Interface誌本文にもそう書かれている）であるはずなのですが、どうやら0x10000番地以降もRAMがあって96kB使えるようなのです。

MITOUJTAGのICEを使ってみてみると、ほら、10000番地以降もあるでしょ？
いままでスタックをx018000番地に設定したり64kB以上あるRAMアプリを書き込んできたけれども、全く問題なく動いていました。

たまたま私がそういうデバイスを手に入れてしまったのか、はたまたN7とN8は実際には同じなのか。謎は深まるばかりです。

◆さらに追記

RX-MEGAボードの在庫は着実に減ってきています。あと10日は持たないかもしれませんのでお早めにお願いします。
ご購入はこちらのオンラインショップからお願いします。