最新のＲＸデバイスの入手

いつもお世話になっているチップワンストップでは、現状、RX66T、RX72T、RX72M のデバイス登録は無い。

百個単位なら、営業に相談すれば入手出来そうだが、人気で、色々な企業が使うデバイス以外は入手が難しいし、数十個でも個人では無理。

ＲＸ６６ＴはＲＳコンポーネンツで１個単位で入手出来た。

そもそも、新規デバイスが１個単位で入手出来るのは、どこかの企業が、そのデバイスを使う機器を開発する為オーダーしたものと思う。
それの余剰品が、個人に回ってくると考えると納得できる。

ＲＸ７２Ｍは、とりあえず最新なので、入手して動かしてみたいが、現在でも入手は難しい状態のようで、生産はしているものの、入手は難しい状況となっている。
先日、マウサーのページにＲＸ７２Ｔの扱いがある事に気が付き注文した（１５００円くらいなので割高）。
ＲＸ７２Ｍもリストには無いが部品の登録はあったので注文したが、現在バックオーダーで８月入荷とある。
※一応２個注文したが・・（＠２５００と高い）

ＲＸ７２Ｔフラッシュ書き込みプログラム

最近のＲＸは、デバイスが異なっても、フラッシュの書き込みプロトコルを変更する事が少なくなっており
新しいデバイスに対応するのは簡単になっている。

ＲＸ７２Ｔのフラッシュ関係プロトコルを斜め読みした感じでは、ＲＸ６６Ｔと同じで書き込み出来るようだ。

とりあえず、「rxprog」に、ＲＸ７２Ｔプロトコルを追加して、デバイスのコンフィグを追加しておいた。
※現状ではデバイスを入手していないので、書き込めるかは不明

/Git/RX/rxprog % ./rx_prog --device-list
R5F563T6 (RAM: 8K, Program-Flash: 64K, Data-Flash: 8K)
R5F524T8 (RAM: 16K, Program-Flash: 128K, Data-Flash: 8K)
R5F524TA (RAM: 16K, Program-Flash: 256K, Data-Flash: 8K)
R5F564MF (RAM: 512K, Program-Flash: 2048K, Data-Flash: 64K)
R5F5671F (RAM: 512K, Program-Flash: 2048K, Data-Flash: 64K)
R5F564MG (RAM: 512K, Program-Flash: 2560K, Data-Flash: 64K)
R5F571MG (RAM: 512K, Program-Flash: 2560K, Data-Flash: 64K)
R5F564MJ (RAM: 512K, Program-Flash: 3072K, Data-Flash: 64K)
R5F571MJ (RAM: 512K, Program-Flash: 3072K, Data-Flash: 64K)
R5F564ML (RAM: 512K, Program-Flash: 4096K, Data-Flash: 64K)
R5F571ML (RAM: 512K, Program-Flash: 4096K, Data-Flash: 64K)
R5F565NE (RAM: 640K, Program-Flash: 2048K, Data-Flash: 32K)
R5F566TA (RAM: 64K, Program-Flash: 256K, Data-Flash: 32K)
R5F566TE (RAM: 64K, Program-Flash: 512K, Data-Flash: 32K)
R5F566TF (RAM: 128K, Program-Flash: 512K, Data-Flash: 32K)
R5F566TK (RAM: 128K, Program-Flash: 1024K, Data-Flash: 32K)
R5F572MD (RAM: 1024K, Program-Flash: 2048K, Data-Flash: 32K)
R5F572MN (RAM: 1024K, Program-Flash: 4096K, Data-Flash: 32K)
R5F572TF (RAM: 128K, Program-Flash: 512K, Data-Flash: 32K)
R5F572TK (RAM: 128K, Program-Flash: 1024K, Data-Flash: 32K)

ＲＸ７２Ｔ関係デバイスクラス

ＲＸ７２ＴはＲＸ６６Ｔの高速版みたいな扱いなので、デバイスクラスを作るのは、ＲＸ６６Ｔのリソースを使えるので工数が少ない。
そこで、ＲＸ７２Ｔ関係の整備を始めた。

今回入手できるＲＸ７２ＴはＵＳＢ内蔵タイプなので、１９２ＭＨｚで動かす事になる。
ただ、ＵＳＢを使わない場合２００ＭＨｚで動かしたいだろうから、外部オシレーターのクロックは８ＭＨｚにした。
８ＭＨｚなら、ＰＬＬの倍率調整で、１９２ＭＨｚも２００ＭＨｚも調整可能だと思う。

他はＲＸ６６Ｔとほとんど同じ構成で、ファイルをコピーして何も変更していない。

icu.hpp
icu_mgr.hpp
port_map.hpp
peripheral.hpp
power_mgr.hpp
R5F572TK.ld
R5F572TF.ld
README.md

LED 点滅プログラムのコンパイル

デバイスクラスを整備したら、とりあえずＬＥＤ点滅。

コンパイルとリンクを出来るようにした。
※ソフトディレイループのパラメータは、デバイスを入手してから調整する。

また、標準で使うＬＥＤポートをＰ０１とした。
※Ｐ００はＵＳＢブート時の切り替えポートとなっている。

終わりに

※Github にはそのうちマージする。

早く、デバイス来ないかな～
※テスト基板をどうするか・・・

先ほど知ったのだが、C++ の constexpr などを利用した強力なライブラリーをリリースしていた「ボレロ村上」氏が他界したようだ。
ボレロ村上逝去
以前に、Ｃ＋＋勉強会で合った事があり、他人事とは思えない、まだ３２歳だったようだ、残念だ・・・

最近、ようやくＵＳＢ関係を始めた。

フレームワークは、ルネサス純正の物を試用して実験している。
ＵＳＢのフレームワークでは、イベント関係で割り込みを使っている。

ＲＸ６５Ｎでは、選択型割り込みを使っている。

自分のフレームワークと、ルネサス社のフレームワークを合わせるのは、工夫が必要で、そのままではリンクが難しい。

少し調べると、割り込み関係は、「basic/src/hw/r_usb_rx_mcu.c」で設定されており、これを改修すれば良さそうだ。

それで、色々かち合う部分に手を入れ、ＵＳＢマスストレージ関係をコンパイル、リンクする事が出来るようになった。
早速動作検証するのだが、動かない・・・
どうやら、割り込みがかからないようだった・・・

よくよく調べると、選択型割り込みクラスにバグがあり、それが原因だった。
※以前に実装していたが、選択型割り込みを扱うデバイスが無かったので、動作検証されていなかった・・

ＲＸマイコンでは割り込み要因は２５６個まで設定できるが、非常に沢山あるペリフェラルで発生する割り込みをアサインするのは無理があり、物理的に足りない。

そこで、ＲＸマイコンには、割り込みをシェアしたり（グループ割り込み）、使いたい割り込みをアサインしてプログラマブルに使う（選択型割り込み）などの仕組みが用意されている。

ただ、同じようなペリフェラルでも、デバイスによって異なるグループだったり、要因が異なったり、複雑で、ドライバーを作る場合に個々に対応しなければならない。

自分の C++ フレームワークでは、この問題を隠蔽して、簡単に扱えるように、色々な仕組みを実装してある。
※この仕組みこそが C++ を使う最大のメリットの一つと思う。
※特殊なツールを使ってコード生成する必要が無い。

例えば、CMT（コンペアマッチタイマー）を使いたい場合、「cmt_io」クラスを使う。

#include "common/cmt_io.hpp"

typedef device::cmt_io<device::CMT0> CMT;
CMT     cmt_;


    {
        uint8_t intr = 3;  // 割り込みレベル
        uint32_t freq = 1000;  // 1000Hz の周期 
        cmt_.start(freq, intr);
    }


    while(1) {

        cmt_.sync();  // 同期

    }

上記の例では、リソースとして「CMT0」を使い、1000Hz の周期を持ったタイマーを割り込みレベル「３」で起動している。

CMTには、チャネルが４つあり、CMT0～CMT3まで使える。

RX65N の場合 CMT0、CMT1 は通常の割り込みだが、CMT2、CMT3 は選択型割り込みを使う必要があるが、それらは隠蔽されていて、特別な設定を行う必要が無い。

#if defined(SIG_RX24T) || defined(SIG_RX66T) || defined(SIG_RX72T)
    typedef cmt_t<0x00088002, peripheral::CMT0, ICU::VECTOR, ICU::VECTOR::CMI0> CMT0;
    typedef cmt_t<0x00088008, peripheral::CMT1, ICU::VECTOR, ICU::VECTOR::CMI1> CMT1;
    typedef cmt_t<0x00088012, peripheral::CMT2, ICU::VECTOR, ICU::VECTOR::CMI2> CMT2;
    typedef cmt_t<0x00088018, peripheral::CMT3, ICU::VECTOR, ICU::VECTOR::CMI3> CMT3;
#elif defined(SIG_RX64M) || defined(SIG_RX71M) || defined(SIG_RX65N) || defined(SIG_RX72M)
    typedef cmt_t<0x00088002, peripheral::CMT0, ICU::VECTOR, ICU::VECTOR::CMI0> CMT0;
    typedef cmt_t<0x00088008, peripheral::CMT1, ICU::VECTOR, ICU::VECTOR::CMI1> CMT1;
    typedef cmt_t<0x00088012, peripheral::CMT2, ICU::VECTOR_SELB, ICU::VECTOR_SELB::CMI2> CMT2;
    typedef cmt_t<0x00088018, peripheral::CMT3, ICU::VECTOR_SELB, ICU::VECTOR_SELB::CMI3> CMT3;
#endif

CMT0～CMT3の定義は、上記のようになっており、割り込み要因をデバイス毎に定義してある。

auto vec = CMT::get_ivec();
if(level_ > 0) {
    if(task != nullptr) {
        icu_mgr::set_interrupt(vec, task, level_);
    } else {
        icu_mgr::set_interrupt(vec, i_task_, level_);
    }
    CMT::CMCR = CMT::CMCR.CKS.b(cks) | CMT::CMCR.CMIE.b();
} else {
    icu_mgr::set_interrupt(vec, nullptr, 0);
    CMT::CMCR = CMT::CMCR.CKS.b(cks);
}

上記は「cmt_io」の割り込み関係を設定する部分で、「auto」を使って、割り込み型「ICU::VECTOR」、「ICU::VECTOR_SELB」を自動で再定義している。

「set_interrupt」APIは、割り込み型の違いを定義してあり、それぞれ、割り込みの管理方法が異なる。

static ICU::VECTOR set_interrupt(ICU::VECTOR vec, utils::TASK task, uint8_t lvl) noexcept {
    set_task(vec, task);
    set_level(vec, lvl);
    return vec;
}

static ICU::VECTOR set_interrupt(ICU::VECTOR_SELB vec, utils::TASK task, uint8_t lvl) noexcept
{
    for(uint16_t i = 144; i <= 207; ++i) {
        if(lvl > 0) {
            if(ICU::SLIXR[i] == 0) {
                ICU::IER.enable(i, 0);
                set_task(static_cast<ICU::VECTOR>(i), task);
                ICU::IPR[i] = lvl;
                ICU::SLIXR[i] = static_cast<uint8_t>(vec);
                ICU::IR[i] = 0;
                ICU::IER.enable(i, 1);
                return static_cast<ICU::VECTOR>(i);
            }
        } else if(ICU::SLIXR[i] == static_cast<uint8_t>(vec)) {
            ICU::IER.enable(i, 0);
            set_task(static_cast<ICU::VECTOR>(i), nullptr);
            ICU::SLIXR[i] = 0;
            ICU::IR[i] = 0;
            return static_cast<ICU::VECTOR>(i);
        }
    }
    return ICU::VECTOR::NONE;
}

※選択型割り込みでは、SLIXR レジスタに、割り込み要因番号を設定する事で行われ、割り込み番号１４４～２０７まで定義できる。
※選択型割り込みのバグは、「ICU::SLIXR」レジスタアドレスがタイポしていたものだった・・・

アルファ値を含んだ画像を扱う必要があるので、libpng をインポートした。
PNG では、インデックスカラーの場合でも、カラーパレットにアルファ値を含める事が出来る。
ただ、zlib が必要なのと、記憶割り当てを使う事から、BMP やJPEG を使っていたが、インデックスカラーでアルファ付画像を扱う必要性があり、やはりインポートをする事になってしまった・・
書き込みを使う事は「稀」と考えて、デコーダーのみではあるが・・・
Windows のフレームワーク「glfw_app」では以前からサポートしてあるので、そのコードを再利用したので簡単ではあったけど、意外とライブラリビルド時の「configure」の使い方で google 先生の助けを借りたｗ

libpng をビルドするには、zlib が必要なので、事前に zlib をビルドしておいた。
※zlib のビルドは普通に出来ると思う。

libpng のビルドでは、ツール関係（コマンドライン実行ファイル）のビルドで失敗するものの（RX マイコンでは、動かす環境のハードルが高い）、ライブラリの構築には成功しているので、それで「ヨシ」とした。
※github には「libpng.a」とヘッダーなど必要な物を上げてあるので、それを利用するぶんには、自分でビルドをする必要は無い。

 ./configure --includedir="/d/Git/RX/zlib" --host=rx-elf --disable-shared

Makefile 編集

make
cp .libs/libpng16.a /d/Git/RX/libpng/libpng.a
cp png.h /d/Git/RX/libpng/.
cp pnglibconf.h /d/Git/RX/libpng/.
cp pngconf.h /d/Git/RX/libpng/.

上記のように、「ホスト」を指定し、zlib のパスを追加してある。
しかしこれだけでは不十分で、make すると、zlib.h が無いとか言ってエラーになる・・・
正しいやり方が判らなかったので、手っ取り早く、configure で生成された Makefile を直接編集した。
・DEFAULT_INCLUDES = -I. -I/d/Git/RX/zlib
※zlib のパスを追加
・CFLAGS = -mcpu=rx600 -O2 -I/d/Git/RX/zlib
※最適化「-O2」を追加
・シェアードライブラリは必要無いので、省いてある。
・ビルドすると、「.libs」ディレクトリにライブラリが出来ている。
・必要なヘッダーをコピーする。

png ファイルのロードは、以前に実装したので、それをほぼそのまま使っている。（glfw3_app/common/img_io/png_io.hpp）

※組み込みでは、png ファイルを出力する事は「稀」と思うので、ロードのみサポートしている。

PNG 画像のアルファ値は、元の画素と合成されて描画する。
※アルファ値が「０」の場合、そのピクセルは描画されない。

#include "graphics/img_in.hpp"

namespace {

     typedef img::scaling<RENDER> PLOT;
     PLOT        plot_(render_);
     typedef img::img_in<PLOT> IMG_IN;
     IMG_IN      imgs_(plot_);
}


     imgs_.load(filename);・

・img_in クラスは、BMP、JPEG、PNG を自動で判別してロードするクラス。
・scaling クラスはワークメモリを最小限にして、スケールしながら描画するもので、それなりにエイリアシングも除去してくれる。

# cd res
# image ff.png
libpng warning: iCCP: known incorrect sRGB profile
# dir
      6727 Jul  9 2016 08:21  ff.png
      3407 Jul  9 2016 08:21  forte.png
     23148 Jul  9 2016 08:21  NoImage.png
      6371 Jul  9 2016 08:21  pause.png
      3419 Jul  9 2016 08:21  piano.png
      6856 Jul  9 2016 08:21  play.png
    373882 Jul  9 2016 08:21  Player.icns
    117306 Jul  9 2016 08:21  player.ico
     17632 Jul  9 2016 08:21  PlayerICON.png
      6361 Jul  9 2016 08:21  plus.png
      6748 Jul  9 2016 08:21  rew.png
      6607 Jul  9 2016 08:21  right.png
      3934 Jul  9 2016 08:21  seek_handle.png
      6364 Jul  9 2016 08:21  seg12.ttf
      4680 May  6 2019 23:08  select.bmp
      6780 Jul  9 2016 08:21  select.png
      4028 Jul  9 2016 08:21  slider_handle.png
      6343 Jul  9 2016 08:21  stop.png
      6605 Jul  9 2016 08:21  up.png
Total 19 files
# image NoImage.png
libpng warning: iCCP: known incorrect sRGB profile
# image ff.png
libpng warning: iCCP: known incorrect sRGB profile
# image PlayerICON.png
libpng warning: iCCP: known incorrect sRGB profile
#

実験は、RX65N Envision Kit で行った。

相変わらず、SDHCなどの高容量タイプで、ACMD41が失敗する問題に悩んで１週間くらい？

ロジックアナライザを繋いで制御ピンの状態を確認するとか、ありとあらゆる方策を試していたが・・・

全く成果無し状態でいた。

電源の状態が悪いのかとかも確認したが、電源のリップルはそれ程多くは無く、許容範囲だった。
RTK5 RX65N Envision Kit では、SD カード電源制御と、電源電圧の確認用に専用のICを使っているが、それは実装されていない為、とりあえず、P チャネルの MOSFET を取り付けて、電源制御を加えてみたりもしたが、全く効果は無い。
※秋月電子で入手出来る「DMG3415U」を使った。

LA2016 には、色々な解析モードが用意されており、それを使う事で、CMDピンで、ホストとスレーブ間でやりとりするデータ列を具体的に確認する事が出来る。
凄く便利で、素晴らしい機能だーー
※今まで、こんなに便利な機能なのに、あまり積極的に使っていなかった、他にも色々と解析が出来るので、これからは重宝すると思う。

これで、確認した限りでは、問題無さそうで、2GのSDカードと8GのSDカードの違いは無さそうだった。
※ただ、SDHCカードでは、BUSYのまま・・・

SD カード関係の正規資料なども、色々読んで、何か間違いが無いかを確認していた。

そんな時、アルテラ社のFPGA向けライブラリでSDIOの説明を見つけ、ACMD41関係の部分を読んでいたら、
> SD_SEND_OP_COND（ACMD41）コマンドを送信します。
> ビット [23:0] = サポートされている電圧範囲

ん？

サポートされている電圧範囲？

現状では、0x000000 を送っている・・・

SPI だと、0x000000 を送っていて、SDHCカードを使えている。

それで、ルネサスの r_sdhi ソースを確認してみると、2.7V から 3.6V の場合、0xFF8000 を設定する事が判った・・・

で、修正してみると、今度は成功する・・・
今までの苦労は何だったのか・・・

まぁ、良くある話ではあるのだが、思い込みで、正規の資料を読んでも、重要な事をスルーしてしまう・・・

まぁ動いたから「ヨシ」とする・・

SDモードでの初期化の手順をまとめると・・・

・SDモードによる初期化手順
（１）CMD0、0x00000000
※複数打った方が良いかもしれない（SDカードは応答を返さない）
（２）CMD8、0x000001AA
※0x100 は電圧範囲（2.7V ～ 3.6V）
※0x0AA は、マッチパターン
（３）CMD8 のステータスで、0x1AA が返れば、SDV2 カード
それ以外の場合、エラー
※CMD8のレスポンスが無い場合、そのカードはCMD8をサポートしておらず、別の初期化シーケンスに切り替える。
これは多分、容量が少ない昔のカードの場合など（自分のドライバーでは、現状、サポートしていない）
（４）ACMD41、0x40FF8000
レスポンスのB31が「１」になるまで投げ続ける。
※１回投げて、1ms 待つ、1000回繰り返しても「１」に成らなければエラーとする。
※レスポンスで、B30が「１」なら、そのカードは、ブロックアクセスを行う。
これは、32 ビットだと 0 ～ 4G までしかアクセス出来ないので、それに対応する方法、このビットが有効なら、read/write はブロックアクセスとなる。
（５）CMD2、0 で CID を取得
（６）CMD3、0 で RCA を取得（B31～B16）
（７）CMD7、RCA でカード選択
（８）CMD16,512 でセクターサイズ設定
（９）ACMD6、0x00000002 で、バス幅を４ビットにする。
※１ビットの場合、0x00000000
（１０）SDHI のバス幅を切り替えて、クロック速度をブーストする。

まだ、エラー検査とかがズブズブで、割り込みやDMAに対応していないが、とりあえず、動くようになった・・・
速度はかなり高速で、以下のような感じ～
※GitHub のマスターにマージ済み

QIDIAN MLC 32GB (SDHC) Class10
# write test.bin
disk_ioctl: 00
Open:  0 [ms]
Write: 440393 Bytes/Sec
Write: 430 KBytes/Sec
Close: 5 [ms]
# read test.bin
SD Read test...
Open:  0 [ms]
Read: 1048576 Bytes/Sec
Read: 1024 KBytes/Sec
Close: 0 [ms]

Lexar 633x 8GB (SDHC) Class10
# write test.bin
disk_ioctl: 00
Open:  170 [ms]
Write: 215048 Bytes/Sec
Write: 210 KBytes/Sec
Close: 12 [ms]
# read test.bin
SD Read test...
Open:  2 [ms]
Read: 1302578 Bytes/Sec
Read: 1272 KBytes/Sec
Close: 0 [ms]

SanDisk Industrial 8GB (SDHC) Class10
# write test.bin
disk_ioctl: 00
Open:  3 [ms]
Write: 338359 Bytes/Sec
Write: 330 KBytes/Sec
Close: 98 [ms]
# read test.bin
SD Read test...
Open:  1 [ms]
Read: 1747626 Bytes/Sec
Read: 1706 KBytes/Sec
Close: 0 [ms]

SanDisk Industrial 16GB (SDHC) Class10
# write test.bin
disk_ioctl: 00
Open:  6 [ms]
Write: 397941 Bytes/Sec
Write: 388 KBytes/Sec
Close: 5 [ms]
# read test.bin
SD Read test...
Open:  2 [ms]
Read: 1227840 Bytes/Sec
Read: 1199 KBytes/Sec
Close: 0 [ms]

TOSHIBA 40MB/s Taiwan 32GB (SDHC) Class10
# write test.bin
disk_ioctl: 00
Open:  1 [ms]
Write: 204920 Bytes/Sec
Write: 200 KBytes/Sec
Close: 46 [ms]
# read test.bin
SD Read test...
Open:  1 [ms]
Read: 1091130 Bytes/Sec
Read: 1065 KBytes/Sec
Close: 0 [ms]

SanDisk Industrial 16GB (SDHC) Class10 for Soft-SPI
# write test3.bin
Open:  0 [ms]
Write: 181634 Bytes/Sec
Write: 177 KBytes/Sec
Close: 17 [ms]
# read test3.bin
SD Read test...
Open:  2 [ms]
Read: 232758 Bytes/Sec
Read: 227 KBytes/Sec
Close: 0 [ms]

以下のようにして、SDHIインターフェースを使う場合とSPI（ソフトSPI）を使う場合を切り替えできる。

    // カード電源制御は使わない場合、「device::NULL_PORT」を指定する。
//  typedef device::NULL_PORT SDC_POWER;
    typedef device::PORT<device::PORT6, device::bitpos::B4> SDC_POWER;

#ifdef SDHI_IF
    // RX65N Envision Kit の SDHI ポートは、候補３になっている
    typedef fatfs::sdhi_io<device::SDHI, SDC_POWER, device::port_map::option::THIRD> SDHI;
    SDHI    sdh_;
#else
    // Soft SDC 用　SPI 定義（SPI）
    typedef device::PORT<device::PORT2, device::bitpos::B2> MISO;  // DAT0
    typedef device::PORT<device::PORT2, device::bitpos::B0> MOSI;  // CMD
    typedef device::PORT<device::PORT2, device::bitpos::B1> SPCK;  // CLK

    typedef device::spi_io2<MISO, MOSI, SPCK> SPI;  ///< Soft SPI 定義

    SPI     spi_;

    typedef device::PORT<device::PORT1, device::bitpos::B7> SDC_SELECT;  // DAT3 カード選択信号
    typedef device::PORT<device::PORT2, device::bitpos::B5> SDC_DETECT;  // CD   カード検出

    typedef fatfs::mmc_io<SPI, SDC_SELECT, SDC_POWER, SDC_DETECT> MMC;   // ハードウェアー定義

    MMC     sdh_(spi_, 35000000);
#endif

RX65N Envision Kit の、SD カードインターフェースは、SDHI インターフェースを想定した設計になっている。

しかし、RX マイコンの SDHI インターフェースでは、ハードウェアーマニュアルの情報だけでは、不明な事が多く、ソフトウェアを実装出来ない状態だった。
※SDHI のハードウェアー操作は、SD カードの制御シーケンスと密接に関連している為、これは仕方無いかもしれない・・
※何回かトライしたが初期化の段階で、思ったように動かないので、断念していた・・
※とりあえず、実績のある ChaN 氏のソフトウェアー SPI で動かしていた。

最近、ルネサスは、SD カードの操作が含まれるマネージャー関連（SD カードの初期化などが含まれる r_sdc_sdmem_rx）を公開するようになったので、具体的にどのように SDHI にアクセスするのか不明な部分が明らかになってきた。
※以前、RX64M、RX71M は、SDHI インターフェースがオプションとなっており、自分の持っているデバイスは、「SDHI なし」なので、試せないでいた・・

また、SD カードを SPI でアクセスする方法は、かなり情報があるのだが、４ビット（SD モード）でアクセスする方法は、情報が少なく、どのような初期化をするのか、イマイチ判らなかった・・・
最近ネットで、kingston SD カードの詳細な 解説を見つけ、この情報をたよりにする事で、SD モードでの推移方法がかなり詳しく判った。

それらの情報を元に、初期化プロセスを実装してみたが、正常に動作しない・・・
(1) 1GB、2GB の HC ではない SD カードだと、初期化に成功する事を発見したが、8GB、16GB、32GB（SDHC）のカードでは、初期化に失敗する。
※ACMD41コマンドで失敗しているが原因が判らない。
ACMD41 コマンドは、ステートに、BUSYがREADYに変わるまで呼び続ける仕様だが、SDHC カードの場合、いつまでたっても READY にならない・・・

とりあえず、手持ちの中で、動作する２枚のカードをテストした。
2GB のカードより、1GB のカードの方が性能が高い為、1GB のカードのみ評価した。
・１ビットバスと４ビットバスの速度比較
・クロック速度による違い

KINGMAX 1GB MicroSD CARD:
Clock: 15MHz
1 bit bus:
Open:  0 [ms]
Read: 825650 Bytes/Sec
Read: 806 KBytes/Sec
Close: 0 [ms]

4 bits bus:
Open:  0 [ms]
Read: 1233618 Bytes/Sec
Read: 1204 KBytes/Sec
Close: 0 [ms]

Clock: 30MHz:
Open:  0 [ms]
Read: 1347784 Bytes/Sec
Read: 1316 KBytes/Sec
Close: 0 [ms]

上記のように、大体１．５倍くらいの違いがある。
駆動クロックを倍にすると、10% 弱速くなるようだが、最終的に扱う場合には、ノイズ耐性、インピーダンスのマッチング（ダンピング抵抗、プルアップ、プルダウン抵抗）など色々考える事が多く、微妙だろうと思う。

流石、４ビットモードは、昔の 1GB の SD カードでも 1.3M バイト毎秒以上の速度が出るので、十分利便性が高い。（早急にSDHCカードが動かない原因を突き止めないと・・・）

最近の高速、高容量の SD カードは、高速動作時に、消費電力を下げる為、より低い電圧（1.8V など）で動作するような仕組みがあるようだ。

しかしながら、インターフェースの I/O 電圧が、低い電圧に対応していないとならない為、たとえ、電源電圧を制御する事が出来ても、対応出来ない。
RX マイコンの SDHI は、1.8V などの I/O 電圧に対応していないので、レベルシフターを間に入れるなどの対応をしないと、電圧を下げて使う事が出来ない。

又、バスのサンプリングポイントを調整するコマンドもあるようだ。

今回はここまで、SDHC における、ACMD41 が失敗する原因を色々探って、色々な実験をしたが、成果は無かった・・・
ハードウェアーで足りない部分があるのかとも思ったが、それも違うようだ・・・
ルネサスのソースコードも読んで、同じようなシーケンスを組んでいる筈だが、動かない・・・

ChaN さんの SPI 仕様では、ACMD41 は正常終了して、SDHC は動くのだが、それと何が違うのか、判らないでいる・・・