RXマイコンC++フレームワーク、RX220をサポート開始

RX220 マイコンをサポートする

半導体不足は未だ解消の気配は無く、RXマイコンを買うにしても、以前のような価格では流通していないし、バックオーダーで、買う事も出来ない。

RX220は、機能と価格で、CPはそんなに良くないが、秋月さんで売っているので、入手はしやすいだろうと思う。

  • DIPスイッチを逆に取り付けてしまったバージョンの基板なら比較的安価に購入できる。(1250円)
  • 以前RX72T(200MHz、RXv3コア)が10個で@600円くらいだった事を考えると、最大32MHzでRXv1コアはあまり触手が伸びない。
  • RX220はFPUも内蔵していない・・
  • 既に購入済で、積みボードになっている人もいるかもしれない。

とりあえず、RXマイコン全制覇を目論んでいるし、200番台をサポートするのは、それなりに価値がある。


秋月RX220ボードの改造

秋月さんのRX220ボードは、そのままでは多少使いづらい・・
このボードでは、内蔵フラッシュを書き換えるには、シリアル書き込みがほぼ標準的となる。
その場合、SCI1を使う事になるが、そのままだと、RSー232Cのレベル変換ICに接続されている。
今や、PCとの通信でRSー232Cを使う事は「稀」で、FT232やCP2102NなどのUSB/シリアル変換モジュールを使って、ロジックレベルで行うのが標準的となっている。
そうすると、RXマイコンのTxDは出力なので問題無いとしても、Rxdは入力となっていて、レベル変換ICの出力が接続されているので、モジュールのロジック端子を繋ぐ事ができない。
そこで、ボードのパターンをカットして、接続できるように改造した。
※何かの記事で読んだが、この「カットをする意味が判らない」と綴っている人がいた・・、これは、本当にビックリした、その程度の知識でマイコンをやってる人がいる現実に驚くばかり。
まぁ、でもマイコン掲示板で、自分で何も調べないで、いきなり質問する人や、初歩的と思えるような質問をする人、様々な人がいる現実を考えると、まぁそんなものかもしれない。


ソフトディレイの調整

RX220は最大32MHz(内蔵発振器動作)で動作する。

  • クロックジェネレーターにはPLL回路が無い為、外部にクリスタルを接続して利用する場合は、最大20MHzとなる。
  • クリスタルの発信器は、20MHzを超えると、ちょっと特殊な回路にしないと発振が安定しない(発振しない)ので、そうなっていると思う。
  • ただ、外部クロック入力でも最大20MHzなので、その他の物理的な要因が関係しているのかもしれない。
  • 内部発信器だと、正確性やジッタの問題があるとも思うが、意外と安定していると思う。
  • 内部発信器は最大50MHzで発振する事も出来るので、50MHzオーバークロックで動かしてみたが、普通に動作はするようだ。

最初、1マイクロ秒のソフト遅延を行う為、NOP命令のループ回数を調整していたが、思うように調整出来ない・・・
ある値を境に、遅くなったり、速くなったり、不思議な現象が発生した。

                for(uint32_t n = 0; n < device::clock_profile::DELAY_MS; ++n) {
                    asm("nop");
                }

・・・

少し考えたら、理由は判った、今まで、最低速度は、RX24Tの80MHzだったので、ループ回数はそれなりの値で問題無かった。
しかし、32MHzだと、ループ回数は少なく、ある値を境に、「asm("nop");」が、インライン展開されてしまう。

そこで、RX220の場合は、専用のAPIにした。

        static void delay_us() noexcept
        {
            // 定数(DELAY_MS)で指定すると、ループ数が少なくインライン展開され、予想した時間にならない為、直で’NOP’数で調整する。
            if(ICLK == 32'000'000) {  // 32MHz 用
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
            } else if(ICLK == 20'000'000) { // 20MHz 用
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
                asm("nop"); asm("nop"); asm("nop");
            } else {
                for(volatile uint8_t i = 0; i < (ICLK / 1'000'000) - 10; ++i) {
                    asm("nop");
                }
            }
        }

rx_prog でも、RX220をサポート

最初、とりあえずルネサスフラッシュプログラマーで書き込みを行ったが、非常に不安定で、書き込みに失敗、そもそも接続も出来ないなどのトラブルが多発した。
この原因は追究していないが、USBシリアルデバイスがCP2102Nなのが問題なのかと思った。

  • CP2102Nは、FTDIより高速で、同じボーレートでも、転送にかかる遅延が非常に少ない為と思った。
  • RX200系は、RXマイコン初期の物なので、あまり枯れていないのかもと思った。
  • ルネサスフラッシュプログラマーの無料版は、ノークレームなので、改修を要求する事さえ出来ない。

そこで、まず、rx_prog にRX220のプロトコルを追加する事にした。
ブートモードの説明を斜め読みした感じでは、RX63Tとほぼ同じ感じで、そのまま行けると感じた。

「rx_prog.conf」に、RX220 デバイスのプロファイルを追加して、「rx220_protocol.hpp」を追加、説明と照らし合わせた。

R5F52206 {
    group = "RX220"
    clock = 3200
    divide_sys = 1
    divide_ext = 1
    rom = 256K
    ram = 16K
    data = 8K
    comment = "; RX220 Flash:256K DataFlash:8K RAM:16K"
    rom-area  = FFFC0000,FFFFFFFF
    data-area = 00100000,00101FFF
    ram-area  = 00000000,00003FFF
}

「rx63t_protocol.hpp」ほぼ同じでOKだったが、ファイルは別けておいた。

まず、コネクションを試してみた。

 % rx_prog -d RX220 --verbose
# Platform: 'Cygwin(MSYS2)'
# Configuration file path: '/usr/local/bin/rx_prog.conf'
# Group: 'RX220'
# Serial port path: 'COM7'
# Serial port speed: 230400
# Erase Page Wait: 2000 [uS]
# Write Page Wait: 5000 [uS]
# Serial port alias: COM7 ---> /dev/ttyS6
# Serial port path: '/dev/ttyS6'
# Device: R5F52206 (first find)
#   Master clock: 32.00 MHz
#   ICLK multiplier: 1 (32.00 MHz)
#   PCLK multiplier: 1 (32.00 MHz)
Connection OK. (RX62x)
#01/01: Device: RX200 Series (LittleEndian)
#01/01: Device ID: 0x33306A37
#01/01: Clock Mode: 0x00
#01/02: Multiplier: 1
#02/02: Multiplier: 1
#01/02: Frequency Min: 32 MHz, Max: 32 MHz
#02/02: Frequency Min: 32 MHz, Max: 32 MHz
#01/01: Change baud rate: 115200
#01/01: Boot Area: FF7FC000, FF7FFFFF
#01/01: Area: FFFC0000, FFFFFFFF
#01/26: Area: FFFFF000, FFFFFFFF
#02/26: Area: FFFFE000, FFFFEFFF
#03/26: Area: FFFFD000, FFFFDFFF
#04/26: Area: FFFFC000, FFFFCFFF
#05/26: Area: FFFFB000, FFFFBFFF
#06/26: Area: FFFFA000, FFFFAFFF
#07/26: Area: FFFF9000, FFFF9FFF
#08/26: Area: FFFF8000, FFFF8FFF
#09/26: Area: FFFF4000, FFFF7FFF
#10/26: Area: FFFF0000, FFFF3FFF
#11/26: Area: FFFEC000, FFFEFFFF
#12/26: Area: FFFE8000, FFFEBFFF
#13/26: Area: FFFE4000, FFFE7FFF
#14/26: Area: FFFE0000, FFFE3FFF
#15/26: Area: FFFDC000, FFFDFFFF
#16/26: Area: FFFD8000, FFFDBFFF
#17/26: Area: FFFD4000, FFFD7FFF
#18/26: Area: FFFD0000, FFFD3FFF
#19/26: Area: FFFCC000, FFFCFFFF
#20/26: Area: FFFC8000, FFFCBFFF
#21/26: Area: FFFC4000, FFFC7FFF
#22/26: Area: FFFC0000, FFFC3FFF
#23/26: Area: 00101800, 00101FFF
#24/26: Area: 00101000, 001017FF
#25/26: Area: 00100800, 00100FFF
#26/26: Area: 00100000, 001007FF
#01/01: Program size: 256 Bytes
#01/01: ID Protect: false

問題無い。

次に、書き込み、ベリファイも試して、問題無かった。
rx_prog は、多少書き込み速度が遅いものの、安定して書き込めるし、OS-X、Linux でも同じように動作する実績がある。
※RX220 は、OS-X、Linux では試していないけど・・

rx_prog -d RX220 --progress  --write --verify sci_sample.mot
Write:  #################################################
Verify: #################################################

これで、RX220を正式サポートした事になると思う。

Makefile は、以下の部分のみ異なるだけで良く、RX220 に移る事は簡単だ。

DEVICE      =   R5F52206

RX_DEF      =   SIG_RX220

まとめ

現状、サンプルプログラムは、「FIRST_sample」、「SCI_sample」のみだが、今後拡充してゆく予定。
※基本、各プロジェクトで、Makefileを用意すればOKだが、まだ、RSPIや、RIIC(I2C)ペリフェラルの追加などをしていない。

RX220 は浮動小数点を扱うとエミュレーションになってしまうが、「utils::format」の表示関係は、内部はほぼ整数を使っているし、速度以外はそれなりに使えると思う。
もう少し安価に入手できれば・・・
それでも、32ビットなので、RL78などの8ビット系に比べて大きなアドバンテージがあるのは言うまでも無い。

Start SCI (UART) sample for 'AE-RX220' 32[MHz]
SCI PCLK: 32000000 [Hz]
SCI Baud rate (set): 115200 [BPS]
  Baud rate (real): 117647 (2.08 [%])
  SEMR_BRME: false
  SEMR_BGDM: false
CMT Timer (set):  100 [Hz]
  Timer (real): 100 [Hz] (0.00 [%])
#

現在、RX631/RX63N もサポート中で、秋月ユーザーでも、C++ フレームワークを使ってみる機会がそれなりに増えると思う。

C++ に対する嫌悪感

主にC言語しか使わない人は、C++ に対する嫌悪感が半端ない事が多い。
また、C++ は判らないし、難しそうだから近寄らない人も多い。

しかしながら、マイコン初心者(プログラムの経験が全く無い人)に教える場合、C++ から始めても、そんなに敬遠したりしない事が判っている。
※もちろん、最初はあまり多くを示さないで、簡単な事、理解しやすい事、シンプルな事から始める。
むしろ、半端にプログラム出来る人より、飲み込みが速く、応用が利く人が多いように思う、これは、教え方次第のように思う。
年齢は関係無い、若い人は頭が柔らかく、吸収する力が大きいように感じる。

C++だと、コンパイラが教えてくれる事が多く、小さなミスは、ほぼ起きなくなるし、柔軟で応用範囲が広いライブラリなど、利便性が高い。

今回 RX220 をサポートしたが、アプリケーションレベルでは変更が全くなく、同じように動作する。

今後、勉強会や、講習会、YouTubeビデオなど、学べる機会や媒体を増やしていく予定でいる。

RXマイコン、C++、sci_io クラスの機能追加(RS-485)

RS-485

RS-485 は、非同期シリアルに RS-485 用ドライバを付け、若干のソフトを追加するだけで、利用出来る。
ドライバーは、差動信号を使い、ノイズに強く、長い通信路でも、信号の品質を維持する事が出来る。
ネットワークのトポロジーとして、CAN のような構成にできて、複数の機器を相互に接続出来る。
詳しくは、RS-485 の解説を参照してもらいたい。

但し、半二重通信なので、送信を行うには、送信ゲートを適切にコントロールする必要がある。
また、プロトコルを実装して、クライアントと通信するので、全体の構成を考える必要がある。
受信だけなら、流れてくるパケットをデコードするだけなので簡単だが、送信するには、受信データを監視して、タイミングを守る必要がある。
プロトコルは規定されていないが、PLC、インバーターなどで良く使われるものがあるようだ。

今回は、三相モーターのインバーターと通信するのがとりあえずのゴール。


sci_io クラスに機能を追加

sci_io クラスは、SCI を使った非同期シリアル通信を扱うクラスとなっている。

今回、RS-485 の送信ゲート制御を追加した。

一つのクラスに、あまり多くの機能を盛り込むのは、設計上別の問題もあるが、色々検討した結果、少しの機能追加で行える事が判ったので、機能追加とした。

RS-485 のゲート制御は、テンプレートパラメータで決定する為、通常の SCI 通信では、余分なコードが残らないように配慮してある。


機能を切り替える仕組み

定義は以下のようなもので、通常の SCI 定義を拡張したものとなっている。
ハードフロー制御(RTS)と共用となっているので、enum class の FLOW_CTRL 型に、RS485 を含めてあり、テンプレートパラメータで指示する。

    typedef utils::fixed_fifo<char, 1024> RS485_RXB;  // RS-485/RX (受信) バッファの定義
    typedef utils::fixed_fifo<char, 512>  RS485_TXB;  // RS-485/TX (送信) バッファの定義

    typedef device::PORT<device::PORT3, device::bitpos::B3> RS485_DE;   // for MAX3485 DE
    typedef device::sci_io<RS485_CH, RS485_RXB, RS485_TXB, device::port_map::ORDER::SECOND, device::sci_io_base::FLOW_CTRL::RS485, RS485_DE> RS485;
    RS485   rs485_;
  • RS-485 ドライバーの DE(送信ゲート)を制御する為、ポート定義を同時に行う。
  • RS-485 ドライバーの受信ゲートは、常に有効にしてある。
  • RS-485 ドライバは、ループバックしているので、送信した文字列をそのまま受信する。
  • 送信した文字列と受信した文字列が等しければ、衝突は発生せず、正しく送信出来た事を保障する事が出来る。
  • RS-485 ドライバーは、MAX3485 を使っている。(3.3V 動作品)

DE ポートの制御

  • RS-485 の送信ゲート制御は、送信データ列が出ている間だけ、送信ゲートを有効にする必要がある。
  • RX マイコンの SCI では、シリアル送信中のデータ列が出ている期間を知る手法はいくつかあるのだが、送信データがバッファリングされている為、単純な方法では、うまくいかない。
  • 送信割り込みは、送信が可能になったタイミングで発生する。
  • ストップビットを含めたシリアルデータが全て送られたタイミングで「送信終了割り込み」が発生する。
  • 色々検討して実験した結果、送信開始前に、ゲートを有効にして、送信 FIFO が「空」になったら、送信終了割り込みを発生させ、そのタイミングでゲートを閉じるようにした。


9600bps


送信終了割り込み(TEI)のハンドリング

送信終了割り込み(TEI)は多少厄介で、一工夫が必要となっている。
それは、マイコンによって、通常割り込みの場合と、グループ割り込みの場合がある為で、それを正しく管理する必要がある。

  • RX621/RX62N/RX63T/RX24T では通常割り込み。
  • RX64M/RX71M/RX65N/RX72N/RX66T/RX72T ではグループ割り込み。
        static inline void tei_task_()
        {
            if(send_.length() == 0) {
                RTS::P = 0;
            }
            SCI::SCR.TEIE = 0;
        }

        static INTERRUPT_FUNC void tei_itask_()
        {
            tei_task_();
        }

        void set_intr_(uint8_t level) noexcept
        {
            if(level > 0) {
                icu_mgr::set_interrupt(SCI::RXI, rxi_task_, level);
                icu_mgr::set_interrupt(SCI::TXI, txi_task_, level);
                if(FLCT == FLOW_CTRL::RS485) {
                    auto gv = icu_mgr::get_group_vector(SCI::TEI);
                    if(gv == ICU::VECTOR::NONE) {
                        icu_mgr::set_interrupt(SCI::TEI, tei_itask_, level);
                    } else {
                        icu_mgr::set_interrupt(SCI::TEI, tei_task_, level);
                    }
                }
            } else {
                icu_mgr::set_interrupt(SCI::RXI, nullptr, level);
                icu_mgr::set_interrupt(SCI::TXI, nullptr, level);
                if(FLCT == FLOW_CTRL::RS485) {
                    icu_mgr::set_interrupt(SCI::TEI, nullptr, level);
                }
            }
        }

現在、RX マイコン C++ フレームワークでは、グループ割り込みは、標準のディスパッチルーチンから呼ばれるので、割り込みタスクの属性を適切に設定する必要がある。

SCI::TEI(送信終了割り込み)がグループベクターの場合は、通常のタスクを登録し、グループベクターでは無い場合には、「INTERRUPT_FUNC」属性を付与した関数を登録する。
「INTERRUPT_FUNC」属性では、「RTE」オペコードで終了する。(通常関数は「RTS」オペコード)

RX24T の場合、「TEI」は通常ベクターで、グループでは無いので、「VECTOR::NONE」が返る。

        static ICU::VECTOR get_group_vector(ICU::VECTOR vec) noexcept {
            return ICU::VECTOR::NONE;
        }

RX72T の場合、「TEI」は「VECTOR_AL0」なので、「VECTOR::GROUPAL0」が返る。

        static ICU::VECTOR get_group_vector(ICU::VECTOR_AL0 vec) noexcept {
            return ICU::VECTOR::GROUPAL0;
        }

「icu_mgr::get_group_vector(SCI::TEI);」で、「SCI::TEI」がグループベクターなのか、そうでないのか判定出来る。
C++ では「型」の違いで、コンパイラが自動で関数を呼び分ける事ができ、処理を切り替える事が可能なので、柔軟性が大きい。
この判定は、定数が返るだけなので、最適化がされると、分岐や判定が綺麗に消えて、無駄なコードが残らない為、余分なメモリとマシンサイクルを節約する。
このような精妙な仕組みがスマートに実装出来るのは C++ の特徴となっている。
このような仕組みはC言語では難しい。


グループベクターのハンドリング

自分のフレームワークでは、割り込みなどは登録制にしてあり、グループベクターも登録制となっている。

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  GROUPAL0・ベクター型
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        enum class VECTOR_AL0 : uint8_t {
            TEI11 = 12,     ///< SCI11 / TEI11
            ERI11,          ///< SCI11 / ERI11

            SPII0 = 16,     ///< RSPI0 / SPII0
            SPEI0,          ///< RSPI0 / SPEI0
            NUM_ = 4
        };

SCI11 の送信終了割り込み「TEI11」は「グループベクター AL0」のグループで、上記番号は、レジスターのビット位置となっている。
グループ割り込みが発生した場合に該当する処理を呼び分けるディスパッチルーチンはなるべく高速に実行したいので、割り込みタスク登録時に必要なデータを登録してある。

        typedef icu_utils::dispatch<ICU::VECTOR_AL0> GROUPAL0_dispatch_t;
        static GROUPAL0_dispatch_t GROUPAL0_dispatch_;

        template<typename GRPV>
        class dispatch {
...
            void set_task(GRPV grpv, GTASK task) noexcept
            {
                uint32_t bits = 1 << static_cast<uint32_t>(grpv);
                for(uint32_t i = 0; i < NUM; ++i) {
                    if(bits_[i] == bits) {
                        bits_[i] = 0;
                        task_[i] = nullptr;
                        break;
                    }
                }
                for(uint32_t i = 0; i < NUM; ++i) {
                    if(bits_[i] == 0) {
                        bits_[i] = bits;
                        task_[i] = task;
                        break;
                    }
                }
            }

            void run(uint32_t togo) const noexcept
            {
                for(uint32_t i = 0; i < NUM; ++i) {
                    if(bits_[i] == 0) break;
                    if((bits_[i] & togo) != 0 && task_[i] != nullptr) {
                        (*task_[i])();
                    }
                }
            }
        };

        static INTERRUPT_FUNC void group_al0_handler_() noexcept
        {
            GROUPAL0_dispatch_.run(ICU::GRPAL0());
        }

        static void install_group_task(ICU::VECTOR_AL0 grpv, icu_utils::GTASK task) noexcept
        {
            ICU::GENAL0.set(grpv, false);
            set_task(get_group_vector(grpv), group_al0_handler_);
            GROUPAL0_dispatch_.set_task(grpv, task);
            if(task != nullptr) {
                ICU::GENAL0.set(grpv);
            }
        }
  • dispatch::run(togo) は割り込み要因 GRPAL0 レジスタを引数に呼ばれる。
  • 登録されたデータに従い、タスクを呼び出す。
  • この辺り、部分的な実装を抜き出しているので雰囲気だけなので、実際は、github のコードを観て下さい。

RX72T 関係
icu_utils 関係


まとめ

  • 現在サポートしているRXマイコンは10種程度に及ぶので、良く考えて実装しないと、修正が大掛かりになる場合もある。
  • 同じような機能を提供するクラスや関数をなるべく共有できるようにしないと、全ての品種で恩恵が薄くなる。

C++ だと、テンプレートや、C++11、C++14、C++17 で備わった機能など色々使って、かなりシンプルに実装が出来る、速度も速い!
テンプレートの場合、コンパイルがエラー無く通ると、大体ちゃんと動く場合が多い。
そして、ほとんどが、ヘッダーのみに全て実装出来る、なんて便利なんだろうといつも思う、利用する人が増えれば良いのにと思う。