「電子工作な日々」カテゴリーアーカイブ

電子工作に関連するお話など・・

Github/RX にプルリクが来たので、それの対応など

最適化をしないコンパイル

現在(少し前)のフレームワークでは、最適化をしない「-O0」場合、大量にリンクで失敗する。

これは、「static」なオブジェクトの実態が無い為で、以前は最適化が標準となっているので、あまり問題にならなかった。
※static なオブジェクトと言っても、リソースを必要とするような実装は無く、最適化すると、実態を持たないものだった。

それでも、最適化しない場合、実態は必ず必要なので、リンクできずに実行バイナリーを作れず停止する。

たとえば、このような感じ・・・

    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  CMT 定義基底クラス
        @param[in]  base    ベース・アドレス
        @param[in]  per     ペリフェラル
        @param[in]  VEC     ベクター型
        @param[in]  ivec    割り込みベクター
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    template <uint32_t base, peripheral per, typename VEC, VEC ivec>
    struct cmt_t {

...

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  CMCR レジスタ
            @param[in]  ofs     レジスタ・オフセット
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
       template <uint32_t ofs>
        struct cmcr_t : public rw16_t<ofs> {
            typedef rw16_t<ofs> io_;
            using io_::operator =;
            using io_::operator ();
            using io_::operator |=;
            using io_::operator &=;

            bits_rw_t<io_, bitpos::B0, 2> CKS;
            bit_rw_t <io_, bitpos::B6>    CMIE;
        };
        static cmcr_t<base + 0x00> CMCR;

...

    };

    typedef cmt_t<0x00088002, peripheral::CMT0, ICU::VECTOR, ICU::VECTOR::CMI0> CMT0;

「CMCR」は、「cmcr_t」テンプレートクラスの「static」オブジェクトとなっている。

このオブジェクトは、「cmt_t」テンプレートクラスのメンバーで、実際には、「実態」となる物を定義する必要がある。

これが、テンプレートクラスでは無い場合、別にソースコードを作成して、その中で、staticなオブジェクトとして宣言しておく。

テンプレートクラスの場合、それはできないので、ヘッダーに特殊な書き方で定義する。

        typedef cmcr_t<base + 0x00> CMCR_;
        static CMCR_ CMCR;
    };

    template <uint32_t base, peripheral per, typename VEC, VEC ivec>
        typename cmt_t<base, per, VEC, ivec>::CMCR_ cmt_t<base, per, VEC, ivec>::CMCR;

上記のように、定義には、「CMCR」オブジェクトの型「cmtt<base, per, VEC, ivec>::CMCR」が必要なので、ペリフェラルの定義全部を大幅に書き換える必要がある。

何度か、修正しようと思った事もあったが、修正範囲が広く、自分には、それほど必要な機能でも無かったので、割愛してきた。

しかし、「-O0」にしないと、デバッガーで止めたりできないとの事で、この莫大な修正を行い、プルリクを送ってくれた方がいたので、このリクエストを受けて、マージする事にした。
※非常にありがたい修正で、修正したソースの分量もすさまじく、この修正を入れる事で、より良い物になるのは明白だ。

ただ、最近、RX72Nの為に色々と、改変している最中で、そのままマージしても、コンフリクトする事は明白なので、内容を精査しながら少しづつマージする事にした。

このプルリクを送ってくれた「Sinsjr2」さんには大変感謝しており、この場を借りて御礼申し上げます。

※自分以外でこのフレームワークを使っている人は、何人くらいいるのだろうか?
少なくとも一人はいる事が判ったw


普通のクラスをテンプレートクラスにするメリット

先ほどの説明で、static なオブジェクトの実態について、通常のクラスの場合は、別にソースを作成して記述する事を説明した。

しかしながら、そうすると、ヘッダーの他にソースコードが増えて、Makefile でソースを列挙する必要が出てくる。

これを回避する方法がある。

普通のクラスを無理やりテンプレートにする方法で、boost などでも使われている。

たとえば、以下のクラスをテンプレート化すると・・・

class flash_io
{

    flash_io() { }

};

template <class _> class flash_io_
{

    flash_io_() { }

};
typedef flash_io_<void> flash_io;

知ってはいたが、以前に実験した時、サイズが少しだけ大きくなるので、敬遠していた。
しかし、最近の RX マイコンは、サイズをあまり気にする程、ROM が小さくないので、存分に使うべきかもしれない・・


Makefile の機能追加

「make」は、「-e」オプションを使うと、外部から、内部で使っている環境変数をオーバーライド出来る。

  -e, --environment-overrides
                              環境変数が makefile 中の記述に優先する

たとえば、最適化は、

    OPTIMIZE = -O3

となっており、

W10./d/Git/RX/FIRST_sample/RX72N % make clean
W10./d/Git/RX/FIRST_sample/RX72N % export OPTIMIZE=-O0
W10./d/Git/RX/FIRST_sample/RX72N % make -e

とすれば、最適化無しで、コンパイルする事が出来る。

しかし、少し工夫して、「debug」と「release」と二つの状態を設ける事にした。
※「release」は元々固定となっている。

BUILD       =   release
#BUILD      =   debug

どちらかを有効にする事で、release(リリース版)と、debug(デバッグ版)を作成可能とした。
※事前に「clean」を行ってオブジェクトを全部廃棄する必要がある。
また、これは、変数をオーバーライド出来るので、「通常」を「release」としておく。

さらに、

ifeq ($(BUILD),debug)
    CC_OPT += -g -DDEBUG
    CP_OPT += -g -DDEBUG
    OPTIMIZE = -O0
endif

ifeq ($(BUILD),release)
    CC_OPT += -DNDEBUG
    CP_OPT += -DNDEBUG
    OPTIMIZE = -O3
endif

BUILD 変数により、オプションをいくつか追加している。

これで、かなり自由にオブジェクトの生成を制御できるようになった。


全体ビルドシェルコマンドの強化

プロジェクトは、最近はかなり大きくなっており、サンプルの数も増えて、メンテナンスに苦労が多い。

そこで、ディレクトリーを巡回して、「Makefile」を見つけたら、「make」を起動するスクリプトを shell で作成してある。

W10./d/Git/RX % sh all_project_build.sh help
Usage: all_project_build.sh options [clean]
    -debug      debug build, 'OPTIMIZE=-O0'

このスクリプトに「-debug」オプションを追加してある。


RX600 ディレクトリの「最適化無し」対応状況

2020-04-24 07:14:47 Friday

ファイル 対応 ファイル 対応 ファイル 対応 ファイル 対応
bus.hpp O cmt.hpp O dmac.hpp O icu.hpp O
cac.hpp O can.hpp O cmpc.hpp O cmtw.hpp O
crc.hpp O crca.hpp O doc.hpp O drw2d.hpp O
dsmif.hpp O dtc.hpp O edmac.hpp O elc.hpp O
eptpc.hpp O etherc.hpp O exdmac.hpp O flash.hpp O
glcdc.hpp O gpt.hpp O iwdt.hpp O lvda.hpp O
mmcif.hpp O mpc.hpp O mpu.hpp O mtu3.hpp O
pdc.hpp O pmgi.hpp O poe3.hpp O port.hpp O
ppg.hpp O qspi.hpp O r12da.hpp O riic.hpp O
rspi.hpp O rtc.hpp O s12adc.hpp O sci.hpp O
scif.hpp O sdhi.hpp O sdram.hpp - sdsi.hpp #
src.hpp O ssi.hpp O ssie.hpp O system.hpp O
tmr.hpp O tpu.hpp O usb.hpp O usba.hpp O
wdta.hpp O

※ Ox:中途(現状、必要な部分だけ)
※ X 今後アップデート予定
※ # 実装中

最適化無しでコンパイル、リンク出来るプロジェクト

FIRST_sample
SCI_sample
SDCARD_sample
AUDIO_sample
FLASH_sample
RAYTRACER_sample
SIDE_sample
NESEMU_sample
FreeRTOS

主要なプロジェクトは大体大丈夫と思う。


自動変換スクリプト

複雑な構造の場合は、一筋ではいかないものの、簡単なスクリプトで変換は「できる」・・

s/static \(.*\) \([0-9A-Z]*\);/typedef \1 \2_;static \2_ \2;/
s/;static/;\
                static /

これは、sed による変換スクリプトで、static 宣言された行で、オブジェクト名を分けて、typedef、static を部分コピーする。
次に、行を分けて、二行にする。
※ただ、全てに対して上手くいく訳ではないのだが・・・

次にテンプレートクラスの実態を生成する。

/static.*;/!d
s/static/template <uint32_t base, peripheral per> typename glcdc_t<base, per>::/
s/_ /_ glcdc_t<base, per>::/

※これは、glcdc.hpp クラス用だ、テンプレートの型が違う場合に、微妙に作り替えないとならない・・・

それにしても sed は便利で強力なツールだ・・

RX72N Envision Kit の D2 オーディオを使う

RX72N Envision Kit で搭載された D2 オーディオ

RX72N Envision Kit には、デジタルオーディオ再生のデバイスが搭載されている。

現ルネサス製(インターシル)の D2-41051 で、I2S などのデジタル入力を内蔵 DSP などで処理して、最終的に PWM 出力する。

最初、このデバイス用のドライバーを書く必要があると思い、マニュアルをダウンロードして、初期化を実装する準備をしていた。
しかし、RX72N Envision Kit ユーザーズマニュアルがアップロードされ、中を読むと、

5.15.5 DAE-4 設定について
本ボードは既に I2S 経由で入力された PCM 音源を出力できる様に設定されています。

と書かれており、直ぐに使える事が判った。
※IPL 用 EEPROM が載っており、リセット時、初期化を行うようだ。

SSIE のドライバーを実装

RX72N には、I2S 通信用に SSIE インターフェースが載っている。
又、オーディオクロックとして、24.576MHz の発信器が載っている。
※この周波数は、48KHz のサンプリングに適した周波数となっている。
※ 24.576 MHz / (32 + 32) / 8 ---> 48KHz

また、内蔵クロックジェネレータが、PLL 方式で、周波数をプログラム出来るので、44.1KHz 用も出ると思ったが、48KHz のみのようだ。
なので、44.1KHz などの CD 音源の再生では、アップサンプリングして変換する必要がある。
厳密に行うのは、色々と面倒そうなので、簡易な方法で凌いでいる、そのうちより厳密な方法を行いたい。
※RX 内臓 DSP 命令を使う時が来たかもしれないw

最初「PCM」とあったので、16 ビットで出力していたが、アナログ出力は変化が無かった、色々調べて、24 ビットにしたら、出力される事が判った。
※現在の実装では 32 ビットにしている。(MSB ファーストなので、問題無いハズ)

最初、テストで「ノコギリ波」を出力していたが、出力波形が、思ったように出ない・・・

良く考えたら D2 デバイス内部で、FIR フィルタなどを通っているので、スパイク上の波形変化では、高い周波数成分が乗り、そのようになるだろう事が判った。
サイン波で実験したら、思ったようなアナログ出力が得られた。

オーディオ出力

RX72N Envision Kit には、PWM からアナログに変換するフィルタ回路がオペアンプで実装されている。
マニュアルには、

5.15.1 接続できるスピーカについて 接続できるスピーカについて
音声出力ジャックにはアンプ付きのスピーカを接続出来ます。アンプがない場合は 8Ωのスピーカも接続でき
ますが、イヤホン等インピーダンスの高い物は接続できません。

と書かれているが、意味が良く判らない、オペアンプは、かなり電流を流せるもののようだが、8オームをドライブできて、16や32オームをドライブ出来ないとは???
また、オペアンプには出力に100オームの制限抵抗があるので、なおさらだ・・・
実験的に、10オームくらいの抵抗を繋いでみたが、思った通り振幅が非常に小さくなる。
※少し怖いので、イヤホンは繋いでいない。

RCA 入力のアンプを接続して、普通に音が鳴っている。

※「D2-41051」には、複数の PWM チャネルがあるので、ランドに出しておいて欲しかった・・・

RX65N のコードを移植

RX65N Envision Kit で D/A 出力していた部分を、SSIE にするコードを追加して、音を聴いてみた。
厳密なヒアリングを行っていないが、普通に聞こえる。(12ビットD/Aより良いか、悪いか、何とも言えない)

コード中では、

#define USE_DAC

と

#define USE_SSIE

で切り替えるようにしている。

DAC 用には、

    volatile uint32_t   wpos_;

    /// DMAC 終了割り込み
    class dmac_term_task {
    public:
        void operator() () {
            device::DMAC0::DMCNT.DTE = 1;  // DMA を再スタート
            wpos_ = 0;
        }
    };

    typedef device::dmac_mgr<device::DMAC0, dmac_term_task> DMAC_MGR;
    DMAC_MGR    dmac_mgr_;

    uint32_t get_wave_pos_() { return (dmac_mgr_.get_count() & 0x3ff) ^ 0x3ff; }

    typedef device::R12DA DAC;
    typedef device::dac_out<DAC> DAC_OUT;
    DAC_OUT     dac_out_;

    typedef utils::sound_out<1024, 512> SOUND_OUT;
    SOUND_OUT   sound_out_;

    class tpu_task {
    public:
        void operator() () {
            uint32_t tmp = wpos_;
            ++wpos_;
            if((tmp ^ wpos_) & 64) {
                sound_out_.service(64);
            }
        }
    };

    typedef device::tpu_io<device::TPU0, tpu_task> TPU0;
    TPU0        tpu0_;

    void start_audio_()
    {
        {  // 内臓12ビット D/A の設定
            bool amp_ena = true;
            dac_out_.start(DAC_OUT::output::CH0_CH1, amp_ena);
            dac_out_.out0(0x8000);
            dac_out_.out1(0x8000);
        }

        {  // サウンドストリーム DMAC マネージャー開始
            uint8_t intr_level = 4;
            bool cpu_intr = true;
            auto ret = dmac_mgr_.start(tpu0_.get_intr_vec(), DMAC_MGR::trans_type::SP_DN_32,
                reinterpret_cast<uint32_t>(sound_out_.get_wave()), DAC::DADR0.address(),
                sound_out_.size(), intr_level, cpu_intr);
            if(!ret) {
                utils::format("DMAC Not start...\n");
            }
        }

        // 波形メモリーの無音状態初期化
        sound_out_.mute();
    }

SSIE 用には

    SSIE_IO     ssie_io_;
    SSIE_IO::SOUND_OUT& sound_out_ = ssie_io_.at_sound_out();

    void start_audio_()
    {
        {  // SSIE 設定 RX72N Envision kit では、I2S, 48KHz, 32/24 ビットフォーマット
            uint8_t intr = 5;
            uint8_t adiv = 24'576'000 / 48'000 / (32 + 32);
            auto ret = ssie_io_.start(adiv,
                utils::ssie_t::FORM::I2S,
                utils::ssie_t::D_NUM::_32, utils::ssie_t::S_NUM::_32, intr);
///             utils::ssie_core::D_NUM::_24, utils::ssie_core::S_NUM::_32, intr);
            if(ret) {
                ssie_io_.enable_mute(false);
                ssie_io_.enable_send();  // 送信開始
                uint32_t bclk = 24'576'000 / static_cast<uint32_t>(adiv);
                utils::format("SSIE Start: BCLK: %u Hz\n") % bclk;
            } else {
                utils::format("SSIE No start...\n");
            }
        }
    }

となっている。

発音は、sound_out オブジェクト(クラス)に対して行うので、シンプルとなる。
ssie_io クラス内で、sound_out クラスを持っていて、操作は、それを経由している、なので、外部に、sound_out オブジェクトの参照を出してある。
このような場合 C++ は本当に便利だ。

NESEMU_sample(ファミコン・エミュレータ)

NES エミュレータ(動画)

RX65N、RX72N で共有のソースとした。

NESEMU_sample

各ディレクトリに移動して「make」すればビルド出来る。
※まだ、RX72N Envision Kit の入手性が悪いが、ビルドしたバイナリーを置いてある。

操作には、ファミコン互換パッドが必要だ。
※近々に USB ジョイパッドに対応する予定でいる。

他に、SIDE_sample も動作を確認した(スペースインベーダーエミュレータ)

github のソースをクローンしている場合

RX72N の追加で、ソースコードは、非常に短いスパンで更新されている。
なので、ソースコードを利用している人は、アーカイブをダウンロードせず、git の操作で更新をした方が有益だと思う。

RX72N Envision Kit での開発(その1)

Arduino を使わないという選択

世の中、ほぼ Arduino 一択という状況になってしまったと言っても過言では無いです。
自分が考えるに、良い面と、そうではない面があると思います。

「良い面」は、非常に簡単に言うと、「敷居を極限まで下げた」と言えるのかもしれません。
アプリケーションを作るのに必要な知識だけでマイコンを動かせます。


Arduino は易しいですが、マイコンを独自で動かす事も実はそんなに難しくありません。

実際、「独自」にマイコンを動かして、「main」関数まで来るには、色々と、行わなければならない事や知識が必要です。
Arduino では、これらの知識は「不要」と分類されており、アプリケーションを作るユーザーが考える必要はありません。
※これは、マイコンが違っても、Arduino 環境下では、同じように使う事が出来ます。

Arduino は一応 C++ ですが、元が、AVR と言う 8/16 ビットマイコンからスタートした為、最新の C++ コンパイラを利用できません。
世の中にある、スケッチは、この制限により、C++ とは言えない物が多く、互換性を考えて、今でも、古いスタイルでプログラミングをしています。

自分も昔は、C 言語が主流で、C++ はオマケ程度でしたが、PC でアプリケーションを作るプロジェクトで仕事をした時、C++ を勉強しなおしました。
そこから、数十年、今では、C++ 以外でプログラムを作る事が苦痛になっています。
※ C++ は非常に難しい部分があるので、独学では限界があります、良い師と、時間が必要ですが、最近は、「勉強会」も頻繁に行われており、「学ぶ」には、かなりハードルが下がりました。
また、最高のコンパイラもフリーで利用出来ます。


組み込みマイコンでも、C++ を積極的に使いたいので、国産で、高性能なマイコンを探しました。
ARMが嫌いな訳では無く、単純に、日本人なのに、「わざわざ外国のマイコンを使うのはおかしいだろう」という思いがありました。
昔から、日立は好きで、H8やSHを良く使っていました、しばらくしてルネサスに統合されました。
最近は、RXマイコンを推しているようです、RXマイコンは多分三菱由来のマイコンと思いますが、非常に優れた、マイコンである事が直ぐに判りました。
開発環境も、gcc をサポートしており、十分実用になる事が判りました。

そこから C++ を積極的に利用した組み込みマイコン用フレームワークを整備して、現在に至っています。
※このフレームワークは、いくつかのプロジェクトで利用しています、その関係もあり、ライセンスを MIT にしています。

開発環境の整備

ルネサス社の E2 Studio は、無料版に制限(128Kバイトまでしかバイナリーを作れない)があり、CC-RX コンパイラでは、C++11、C++14, C++17 などの C++ ソースをコンパイルする事が出来ない為、独自にビルドした gcc-6.4.0 を使います。
※ルネサス社は、独自に、gcc-4.8 ベースの開発環境も用意していますが、4.8 系では、C++14, C++17 をコンパイルする事が出来ない。

C++11, C++14, C++17 はそれぞれ、2011 年、2014 年、2017 年に C++ 標準化委員会が策定した仕様を網羅したバージョンです。
年度が更新する(3年毎)度に、より良い機能が使えるようになっており、わざわざ古い仕様の C++ を使う理由は無いと思います。
※ C++17 は 2017 年の仕様です、今は 2020 年なので、ある程度「枯れて」いると言えると思います。

RX72N Envision kit の内蔵 E2-Lite を使って、マイコン内蔵フラッシュプログラムを書き換えするには、Windows 環境が必須となります。

コマンドラインによる開発環境を著しく敬遠する人がいますが、「慣れ」の問題であり、GUI 環境を覚えるよりハードルは低いと思われます。

MSYS2 を利用しています。

gcc のビルドに関しては、hirakuni45 github RX、又は gcc、g++を使ったルネサスRXマイコン開発を参照の事。

Renesas Flash Programmer v3 をインストールしてください。

ソースコードの編集には、VSCode が便利です、馴染みのテキストエディターが無いのなら(あっても)インストールお勧め。
※設定や、使い方は、ぐぐって~

ソースコードの取得

関係フレームワークなど一式を、github からクローンします。
※「D:/Git/RX」にクローンしています。

W10.~ % cd /d/Git
W10./d/Git % git clone git://github.com/hirakuni45/RX.git

他に「boost」が必要です。

W10./d/Git % pacman -S mingw-w64-x86_64-boost

FIRST_sample

FIRST_sample ディレクトリ、RX72N に移動します。

W10./d/Git ~ % cd RX/FIRST_sample
W10./d/Git/RX/FIRST_sample % cd RX72N

ソースコードをビルドします。

W10./d/Git/RX/FIRST_sample/RX72N % make

W10./d/Git/RX/FIRST_sample/RX72N % ls
led_sample.elf  led_sample.lst  led_sample.map  led_sample.mot  Makefile  release

ビルドされた「led_sample.mot」ファイルを、Renesas Flash Programmer で、RX72N Envision kit に書き込みます。

RX72N Envision kit USR LED が 0.25 秒間隔で点滅する。

Flash Programmer v3 の設定

  • PC と RX72N Envision kit の「ECN1」をマイクロUSBで接続します。
  • 電流不足になる場合、外部にACアダプタを接続する必要があります。
  • SW1 の 2 番をOFFにします。
  • 新規プロジェクトを作成し、RX72x を選択します。

  • E2 emulator Lite を選択
  • FINE を選択
  • 1,500,000 bps を選択

  • 供給しない を選択

  • リセット端子をHi-Z を選択

  • 接続出来たら、先ほどビルドしたファイルを選択して、書き込みます。

ソースコードを眺める

ソースコードは、複数のRXマイコン用に実装されており、「SIG_RX72N」が機種依存部分となっています。

#include "common/renesas.hpp"

namespace {

/// ベースクリスタルの定義
/// LED 接続ポートの定義
#if defined(SIG_RX71M)
    typedef device::system_io<12'000'000> SYSTEM_IO;
    typedef device::PORT<device::PORT0, device::bitpos::B7> LED;
#elif defined(SIG_RX72M)
    typedef device::system_io<12'000'000> SYSTEM_IO;
    typedef device::PORT<device::PORT0, device::bitpos::B7> LED;
#elif defined(SIG_RX72N)
    typedef device::system_io<16'000'000> SYSTEM_IO;
    typedef device::PORT<device::PORT4, device::bitpos::B0> LED;
#elif defined(SIG_RX64M)
    typedef device::system_io<12'000'000> SYSTEM_IO;
    typedef device::PORT<device::PORT0, device::bitpos::B7> LED;
#elif defined(SIG_RX65N)
    typedef device::system_io<12'000'000> SYSTEM_IO;
    typedef device::PORT<device::PORT7, device::bitpos::B0> LED;
#elif defined(SIG_RX63T)
    typedef device::system_io<12'000'000> SYSTEM_IO;
    typedef device::PORT<device::PORTB, device::bitpos::B7> LED;
#elif defined(SIG_RX24T)
    typedef device::system_io<10'000'000, 80'000'000> SYSTEM_IO;
    typedef device::PORT<device::PORT0, device::bitpos::B0> LED;
#elif defined(SIG_RX66T)
    typedef device::system_io<10'000'000, 160'000'000> SYSTEM_IO;
    typedef device::PORT<device::PORT0, device::bitpos::B0> LED;
#elif defined(SIG_RX72T)
    typedef device::system_io<8'000'000, 192'000'000> SYSTEM_IO;
    typedef device::PORT<device::PORT0, device::bitpos::B1> LED;
#endif
}

int main(int argc, char** argv);

int main(int argc, char** argv)
{
    SYSTEM_IO::setup_system_clock();

    LED::OUTPUT();  // LED ポートを出力に設定

    while(1) {
        utils::delay::milli_second(250);
        LED::P = 0;
        utils::delay::milli_second(250);
        LED::P = 1;
    }
}

RX マイコンは、内部にクロックジェネレータがあり、起動した場合には、内部の発信器で、最低限の状態で起動します。
そこで、RX72N の動作を最高性能に切り替える為、フレームワークの助けを借ります。

    SYSTEM_IO::setup_system_clock();

この API を呼ぶ事で、RX72N は最大の 240MHz で動作します。

「SYSTEM_IO」は、以下のように定義されており、外部 16MHz のクリスタルを接続している設定です。

    typedef device::system_io<16'000'000> SYSTEM_IO;

240MHz の指定は、Makefile でされており、ソースをコンパイルする時に、定数を指定しています。
※「F_ICLK」の値

USER_DEFS   =   SIG_RX72N \
                F_ICLK=240000000 \
                F_PCLKA=120000000 F_PCLKB=60000000 F_PCLKC=60000000 F_PCLKD=60000000 \
                F_FCLK=60000000 F_BCLK=120000000

※これらの定数を使って、内部で、クロックジェネレータの設定を自動で行います。
※詳しくは、system_io.hppを参照の事。

LED の定義では、PORT テンプレートクラスにより、1ビットのポートとしています。
※この場合、PORT4 の B0 で、ボード上のユーザーLEDに接続されています。

    typedef device::PORT<device::PORT4, device::bitpos::B0> LED;

LED ポートを出力に指定します。

    LED::OUTPUT();  // LED ポートを出力に設定

LED ポートに「0」、「1」を送る。

        LED::P = 0;
...
        LED::P = 1;

0.25 秒の間隔を作るのはソフトウェアータイマーによるものです。(あまり正確ではありません)
※250ミリ秒

    utils::delay::milli_second(250);

このように、非常に簡単にオリジナルプログラムを走らせる事が出来ます。


次回、SCI を利用したプログラムを解説する予定です。

RX72N Envision Kit が到着

RX72N Envision Kit

RX65N Envision Kit は、かなり良く出来ていたけど、不満な部分もあった。

RX72N Envision Kit は、その「不満」の大部分が解消されて、かなり完成度が高い仕上がりとなっている。
※現状では、設計データや、インストールプログラムについての情報などがアップロードされていないのが残念ではあるが、時間が解決するものと思う。
※チップ・ワン・ストップで、4620円だった。
ソースコードは github に公開された。
※プロジェクトは、ルネサスの統合環境、CC-RX

内容を考えると、かなりコストパフォーマンスが高い製品となっている。

開発環境の問題等もあるが、M5Stack に比べて人気が低いのは残念と思う。
何か自作アプリを作るのなら、より良い物が創れると思う。
※独自にコンパイルした、gcc-6.4.0 ベースの環境で、問題なく開発が可能。

  • WiFi/Bluetooth モジュール(ESP32)
  • マイクロ SD ソケット
  • Ethernet (10/100)機能、RJ45 コネクタを含む
  • DSP 内臓のオーディオインターフェース、クロックジェネレータ
  • USB Serial インターフェース(PC とのシリアル通信機能)
  • 480x272 の静電容量タッチ付き液晶
  • 多目的に使える 32M の EEPROM
  • ステレオマイク
  • USB ホスト機能(クライアント機能も可能と思える)
  • E2 Lite 相当のエミュレーター機能(Fine)

※ オーディオインターフェース、D2-41051(インターシル/ルネサス)
※クロックジェネレータ 5X35023(IDT/ルネサス)

RX マイコンのフラッグシップモデル RX72N(R5F572NNHDFB) の特徴
※ 4MB プログラムフラッシュ、暗号機能アリ、144ピンLFQFP

  • コアは最大 240MHz 動作
  • 高機能な液晶コントローラと、グラフィックスの描画をブーストする DRW2D エンジン
  • 512K + 512K バイトの内蔵 RAM と、4MB の内蔵フラッシュメモリ
  • 豊富なチャネルを持ち、高速で高精度な A/D 変換ユニット(最大 2MBPS/12bits)
  • 倍精度浮動小数点命令を実行可能な RXv3 コア
  • 三角関数演算ユニット
  • 72 ビットのアキュムレータを持つ積和演算器、DSP 命令
  • I2S インターフェース内蔵(デジタルオーディオ入出力)

細かい事だけど、非常に便利なテストポイント

ルネサス(インターシル)D2-41051

Renesas/D2-41051 Intelligent Digital Amplifier PWM Controller and Audio Processor

新規にオーディオ用として投入されたこのデバイスは、このボードにピッタシの選択なのかもしれない。

かなり多くの品種を展開する「インターシル」は「ルネサス」の傘下になり、今回のプロジェクトにピッタリなICを持っていた。

このプロセッサは、非常にユニークで、I2Sからのデジタル信号をフルデジタルで出力してスピーカーを直接駆動する事が出来る。
※最終はPWM出力なので効率が良く、構造上、一般的なオーディオ用D/A、フィルター、プリアンプが必要無い。
※ボリューム調整もフルデジタルで行える。
※単価を調べると、1個購入時でも500円程度なので、他の用途にも使いたいと思える。(マウサー調べ)

ただ、I2Cで通信して、レジスターの意味を理解して、適切なパラメータをセットする手順は複雑そうだー
※サンプルがあるかもしれないけど、まだあまり調べていない・・
※TI にも同じようなデバイスがあるが、TI よりこちらの方が機能的に優れておりコストも安い。

Wifi/Bluetooth

今回はイーサーネットが「Ready」状態なのだが、無線も最初から用意されている。

ESP32 が乗っている、速度はあまり期待出来ないが、WiFi や Bluetooth が使えると、アプリの自由度が格段に上がる。
※ソフトの構成が複雑になるので、アプリに組み込んで利用するには、相応のスキルは必要だが、FreeRTOS 下で 240MHz 動作となると、まぁ何とでもなると思える。

USB Serial

ルネサス社の仮想シリアルが載っており、PC と接続して、ターミナルソフトなどでデバッグ情報などやりとりが行える。
もちろん特定のアプリで、PC と通信する事も出来る、シリアル通信はシンプルで簡単なので、小回りが利いて便利だ。
※ルネサス社のシリアルドライバをインストールする必要があるが、FlashProgrammer V3 をインストールする時に入るようだ。

それとは別に E2 Emulator Lite の USB 接続も出来る、こちらは、ルネサス純正の統合環境なら、より洗練されたデバッグ環境を使えると思われる。

アプリ

電源を入れ、初期インストールアプリで一通り遊んでから、早速、自前のプログラムを動かしてみた。

~~まだ、回路図などが公開されていないので(ソースを調べて、どのポートがアサインされているのか調べれば良いのだが・・)、とりあえず
LED 点滅だけやってみた。~~

※ユーザー LED はパターンを見ると「P40」に接続しているようだ。

また、メインクロックは 16MHz となっている。
※これは、RX72x で新たに追加された PLL 回路を使い、Ethernet PHY 向け 25MHz を生成するのに適した周波数となる。
※ 16MHz を 1/2 にして PLL で 25 倍すると 200MHz が得られる、これを 1/8 すると 25MHz が得られる。
※自前のフレームワークでは、テンプレートで、メインクロック周波数を指定すれば、内部のクロック設定は自動で行われる。


#elif defined(SIG_RX72N)
    typedef device::system_io<16'000'000> SYSTEM_IO;
    typedef device::PORT<device::PORT4, device::bitpos::B0> LED;
#elif defined(SIG_RX64M)

恒例のレイトレースによるベンチマーク

※とりあえず、RXマイコン最速をマーク!(RX71Mも240MHzだけど、ポートバスでの描画の評価しかしていない)
※倍精度浮動小数点演算命令をサポートしていない状態(本格的にコンパイラをテコ入れする必要がある)

とりあえず、今日はここまで。

4月7日追記

SDHIの動作検証も行い、問題無くSDカードがアクセスできる事を確認している。

現在動作可能なサンプル

  • First_sample/RX72N
  • SCI_sample/RX72N
  • RAYTRACER_sample/RX72N
  • SDCARD_sample/RX72N

Renesas RX72N Envision Kitのページに、各種ドキュメントがアップされました。
それにより判明した事:

  • デジタルオーディオは、初期設定で、48KHz の I2S を受け付けるように IPL ROM が載っている。
  • 3.5mm のオーディオジャックは、インピーダンスの関係か、イヤホンのようなインピーダンスが高い物は「不可」となっているようだ。
  • 「8オームのスピーカーは接続出来る」とある。

※少し残念なのは、44.1KHz 等に対応しておらず、44.1KHz の音源は 48KHz に変換して出さないといけない点・・・

RX72N Envision Kit がリリース


ついに、ルネサス社がやってくれた

RX72N Envision Kit

RX72N となっていて、まだ現状では RX72N の情報は無いが、ボード写真のデバイスには RX72N と読めるので、新たに追加されたデバイスのように思う。

Renesas RX72N

これでやっと、「STM32H7」を載せたボードに対抗出来る製品が出た事になる。
とゆーか、RX72N Envision Kit の方が、かなり強力なように思う。

値段も5000円以下!

※Chip One Stop で4620円
RX72N Envision kit (Chip One Stop)


  • 240MHz で動くRXv3 コア(倍精度浮動小数点をサポート)
  • 1024K の内部メモリ(512K+512K)

豊富で強力な外部インターフェース

まだ詳細な情報が少ないが、ボード写真を見ると、かなり強力なボードのようだ。

  • Ethernet (10/100)
  • Wifi/BLE モジュール(ESP32?)
  • SD Card interface
  • USB Host
  • Audio (DSP, D/A, Clock generator インターシル製)
  • LCD (GLCDC/DRW2D)
  • LCD Touch controller
  • On Board Emulator
  • USB Serial on board

RX72M 関係のリソースも既にかなり準備しているので、直ぐにソフト開発も進められると思う。
※RX72N 関係のリソースを準備中

JDS6600 60MHz 版を購入

周波数ジェネレータを購入

中華製の周波数ジェネレータ「JDS6600」(60MHz版)を購入した。

値段が微妙に異なるが、一番高い周期を発生出来るバージョンにした。

ただ、実際に波形を見ると、その実力は無いものと思える。

内部アンプや、フィルターの問題か、周波数が高くなると振幅が減衰するので、実用性はせいぜい2MHz程度しか無い。
それでも8600円程なので、まぁ、値段相応なのかもしれない。

付属品

今の騒動もあるものの、注文してから10日くらいで到着。

早速開封したのだが、ACアダプターの電源ソケットが・・・

ソケットの変換を持っていなかったが、センター+の5Vなら何でも使えるようだ。
※自宅にあった5V2Aのアダプターを使って普通に動作した。

他に、ワニ口付きのBNCケーブル2本、USBケーブル、ソフトのメディア、説明書などが入っている。

GUIは、英語と中国語が選択できる。

機能豊富

機能は豊富で、周波数、振幅、オフセット、フェーズなどを変更できる。

また、CH1、CH2と独立に設定が可能だ。(内部基準発信機が同一のようだ)

実用性

「実際の実用性」を聞かれると、少し疑問ではあるが、何も無いよりは随分マシと思う。


同じ日に「RX72T」も届いた。
こちらも、速いとこ実験したいとこだ・・・

RX72T 関係リソースの整備

最新のRXデバイスの入手

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

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

RX66TはRSコンポーネンツで1個単位で入手出来た。

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

RX72Mは、とりあえず最新なので、入手して動かしてみたいが、現在でも入手は難しい状態のようで、生産はしているものの、入手は難しい状況となっている。
先日、マウサーのページにRX72Tの扱いがある事に気が付き注文した(1500円くらいなので割高)。
RX72Mもリストには無いが部品の登録はあったので注文したが、現在バックオーダーで8月入荷とある。
※一応2個注文したが・・(@2500と高い)

RX72Tフラッシュ書き込みプログラム

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

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

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

/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)

RX72T関係デバイスクラス

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

今回入手できるRX72TはUSB内蔵タイプなので、192MHzで動かす事になる。
ただ、USBを使わない場合200MHzで動かしたいだろうから、外部オシレーターのクロックは8MHzにした。
8MHzなら、PLLの倍率調整で、192MHzも200MHzも調整可能だと思う。

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

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

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

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

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

また、標準で使うLEDポートをP01とした。
※P00はUSBブート時の切り替えポートとなっている。

終わりに

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

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


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

RXマイコン、選択型割り込みを使う

最近、ようやくUSB関係を始めた。

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

RX65Nでは、選択型割り込みを使っている。

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

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

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

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

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

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

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

自分の 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 の周期を持ったタイマーを割り込みレベル「3」で起動している。

CMTには、チャネルが4つあり、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 レジスタに、割り込み要因番号を設定する事で行われ、割り込み番号144~207まで定義できる。
※選択型割り込みのバグは、「ICU::SLIXR」レジスタアドレスがタイポしていたものだった・・・

RXマイコン用、libpng の構築

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

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 画像のアルファ値は、元の画素と合成されて描画する。
※アルファ値が「0」の場合、そのピクセルは描画されない。

#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 で行った。

RXマイコンSDHIインターフェースその2(完了)

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

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

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

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

LA2016 の SDIO 解析画面

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