RX110, RX111, RX113 などをサポート

RX マイコン C++ フレームワークでは、なるべく多くの品種をサポートするべく作業を行っている。

これらの RX マイコンは、現行品で、比較的低価格のマイコンとなっている。
FPU が無いとか、5V で動かせない（1.8～3.6V）とか、色々と制限があるものの、特定の分野なら十分な能力があると思う。
動作周波数は 32MHz だが、8/16 ビット系に比べて、扱い易く、高性能だと思える。

• FPU はアプリケーションによっては、無い事が不利益にならない場合がある
• 32 ビット CPU なので、バンクを気にする必要が無く、プログラムの実装は、非常にやりやすいと思う
• それでいて、十分低消費電力であり、コストパフォーマンスも良い
• 必要十分なペリフェラル（MTU, RTC, SCI, I2C,　RSPI）を内蔵しており、通常の用途では十分と思える
• USB、LCD、静電タッチ機能を使える物など、そこそこバリエーションがある
• 基本的に RX マイコンのリソースを再利用出来る

サポートと言っても、以前のリソースを集めたり、定義を少し書くだけなので、そんなに大げさなものでは無い。
ただ、デバイスを入手して、実験していないので、ちゃんと動作するかは判らない、近々にデバイスを入手して、簡単なテストは行いたい。

• ROM 容量が 64K 以上ある RX140 が安価に入手出来れば良いのだが、チップワンストップには在庫が確認出来ない
• ROM 容量が大きい RX140、海外の販売サイトには在庫があるようだが、単価が高いので、RX231とかの方が良いかもしれない
• 上記 RX100 系は、動作電圧範囲が狭いので、A/D を使う場合に、ダイナミックレンジが狭く、色々と制限が多いのは、マイナスポイント
• 当然、電源電圧が低いと、ノイズ耐性にも影響があるものと思う

チップワンストップ：

RX110: 64LQFP, RXv1, 32MHz, Code: 32K, RAM: 10K, DataFlash: 0K, R5F51101ADFM
１個：２５６円
１０個：＠１９０円
RX110 Github

RX111: 64LQFP, RXv1, 32MHz, USB2.0, Code: 128K, RAM: 16K, DataFlash: 8K, R5F51115ADFM
１個：３６８円
１０個：＠２３４円
RX111 Github

RX113: 64LQFP, RXv1, 32MHz, USB2.0, Code: 512K, RAM: 64K, DataFlash: 8K, R5F51138ADFM
１個：６３０円
１０個：＠４８３円
RX113 Github

データフラッシュの操作

今まで、RX64M 系、RX24T 系のデータフラッシュの操作は、実装して、試していたが、それとは異なる系統の場合、実装されていなかった。
構成が異なり、シーケンスも微妙に異なるグループがある。
これは、デバイスにより、内蔵フラッシュメモリの構造や特性が異なるのが要因と思う。
このデータフラッシュ操作は、RX220/RX621/RX62N/RX631/RX63N など、古いタイプの RX マイコンなのもある。
しかし、RX26T が、このグループに近い操作系となっており、ついでにサポートして実験した。

• 消去は基本、バンク単位で行う
• １バイト単位で書き込め、消去後の値が 0xFF の場合、多分従来型の EEPROM に近いものと思う
  -　消去後の値が未定の場合は、新しいタイプ（E2?）のフラッシュメモリとなっている

FLASH_sample: 各プロジェクト、データフラュシュ操作クラス、アプリケーションの動作確認

RX220/RX26T/RX62[1N]/RX63[1N] などサポート

これらグループは、ほぼ同じ操作系なのだが、微妙に異なる部分もあり、やりたくは無かったが、「#if defined(xxx)」でより分けている。
多少工夫すると、無くせなくも無いが、コードの見通しがもっと悪くなると思ったのもあって、とりあえず、制御文で別けている。

RX26T は、ほぼ同じとは言え、構成も異なるので、ソースを別けた方が良いかもしれないが、同じようなコードをコピペする事になる、コピー元を変更したら、コピー先に反映させなければならないしで、どうしたものか・・・
※まぁ、機能違いは、継承させて、分離する方が良いかもしれないが、それも複雑になるし、一長一短ではある・・・

• RX62[1N]、RX63[1N]は、ファームの転送が必要
• RX26T は、FACI コマンド発行アドレスが異なる
• RX26T は、データフラッシュ操作アドレス用に、専用のレジスタがあり、適切な値を設定する必要がある
• それぞれ、書き込みサイズ、バンクサイズ等が異なる場合があり、FLASH レジスタークラスで定義を行って、flash_io クラスからは参照するようにしている

まとめ

Start Data Flash sample for 'RX62N FRK-RX62N' 96 [MHz]
Flash drive clock: 48 [MHz]
Data Flash total size: 0x00008000
Data Flash block size: 2048 bytes
Data Flash word size: 8 byte
# check 2
Erase check: bank 2: 0x1000 to 0x17FF OK
# write 1000 123456789abcdef0 fa926534bcdea021
# r 1000 100f
0x1000: 123456789ABCDEF0 FA926534BCDEA021
# check 2
Erase check: bank 2: 0x1000 to 0x17FF NG
# erase 2
Erase OK: bank 2, 0x1000 to 0x17FF
# check 2
Erase check: bank 2: 0x1000 to 0x17FF OK
# r 1000 100f
0x1000: 1274567892BCDEF0 FA926514BCDEA021
#

• RX220 は、RX62[1N]/RX63[1N] この系列なのだが、動作確認で失敗し、原因を調査・・・
• RX220 は ROM ブロック領域の説明も実際と異なっている
• データフラッシュのバンクサイズも１２８バイト、２０４８バイトと説明が２つあり、どちらが正解なのか判らない
• 多分 2048 バイトだと思う
• RX220 は保守外の品種なので、どうかと思うが、一応、ルネサスに質問しておこうと思う
• RX220 のフラッシュ操作が動かない理由は、判ったー
• FCU クロック通知を、データ領域では無く、コード領域に行う必要がある・・・
• 「フラッシュ P/E モードエントリレジスタ（FENTRYR）」のアドレスがタイポしていた・・・
• レジスタアドレスは、構成が同等の RX マイコンでも、微妙に異なっている場合がある・・・
• それを修正して動作するようになった！（確認したつもりだったが・・・）
• 消去後のデータが不定だと、消去されているか不明なので、ワード単位の消去チェックや消去操作が必要となる
• これは、今後ワード単位の API を追加する（RX64M 系も同じように追加が必要）

※ 120km を mi に変換 (74.56 mi)

関数電卓を考える

関数電卓は、丁度良いボリュームで、難易度も適当な事から、昔から興味の尽きないアプリケーションとなっている。

マイコンで作る電卓なら、大容量メモリや周辺機能を活かして、通常流通している物には無い機能を盛り込める。
前回、倍精度浮動小数点よりも高精度に計算が行える、gmp、mpfr ライブラリを使って、計算の核を実装している。

RX マイコン EnvisionKit の機能を活かして実現が出来るのもガジェットとして都合が良い。

最終的には、簡単に持ち運びが出来る形態で、実用的なハンドヘルド関数電卓を作りたいと考えている。

構成的には、タッチキーでは無く、物理ボタンが欲しい処ではあるけど、複雑な操作は GUI じゃないと作りずらい場合もある。
物理ボタンなら、フルキーボードが欲しい処ではあるけど、気軽に使えるような、小型のフルキーも少ない・・
市販されているボタンを組み合わせてキーアレイを構築するにしても、コストの割に良い物を作る事が難しい・・

それでも、手頃な RX マイコン、液晶、物理キーを組み合わせた、スクラッチの関数電卓も作ってみたい。

色々考えても、一長一短で最適解があるのか無いのか・・、とりあえず、ソフトで出来る事を地道に積み上げて、完成度を高めるのが良さそうだと感じている。

GUI が無くても、シリアル接続で、対話式に計算を行えるようにしてあり、殆どのＲＸマイコンで動作する。
※容量が 256K 品では不足するのが、多少問題で、最低でも 512K 品が必要・・

単位の換算機能

２進、１６進の変換機能などを実装して、及第点にはなった感があるのだけど、自分としては前から欲しいと思った機能もある。
Qiita の記事：ＲＸマイコンで動作する関数電卓
※上記記事は、２進、１０進、１６進の機能を追加したバージョンの記事で、内部の構成などを解説している。

新たに追加した機能は「単位の変換」機能だ。

単位変換は、長さ、速度、重量など相互に変換したい場合があり、電卓の専用機能として実装すれば、利便性が格段に上がると思われる。

電卓では、単純に小数点の位置をオフセットして、10 の乗数で表す機能（ENG）があり、単位の変換は、これに近い機能。
そうすれば、元の値を保持したまま、自由に単位を変更出来るので、非常に便利。
※元の値を保持したまま変換出来る点が利便性が高い。

追加で、貨幣の変換も追加した、貨幣の場合、レートが日々変化するので、変換レートを更新する必要がある。
なので、貨幣レートのみ、変換レートを再設定出来るようにしてある。
※GUI版は、貨幣レートを入力するダイアログ関係を実装中で、現在、コマンド入力では再設定出来る。

GUI spinboxt

スピンボックスｔは、登録された単語集を、左右の小さいボタンにより変更して、目的の機能を選択する。
※通常のスピンボックスは、数値を変化させて、定量的な値を得るもので、それとは少し異なるものだ。

• ボタンを三等分して、左、右、中心で機能を別けているので、ある程度の幅が必要となる
• 左右の小さい三角は、選択肢の有無を表している
• メニューの方が良いかもしれないが、画面タッチでは、シンプルな操作性の方が使い易いと思う

レートの再設定

貨幣レート変換の場合、時間と共にレートが変わるので、レートを変更出来るようにする必要がある。
コマンドラインのインターフェースでは、その機能を入れてあるが、GUI は、現在実装中となっている。

RX231 のフラッシュ書き込みの不具合

RX231 を、rx_prog でフラッシュ書き込みを行った処、途中でストールして書き込めなくなった・・・
色々調べたが原因が良く判らない・・
とりあえず、「--write-page-wait=10000 --erase-page-wait=5000」書き込み時の遅延を大きくしたら、ストールしなくなったので、RX231 だけ遅延を再設定するように、common/makefile を修正した。

sci_io、rsci_io、scif_io クラスのエラーハンドリング

以前の実装では、オーバーランエラー、フレーミングエラー、パリティエラーが発生した場合、受信を受け付けなくなる不具合があった。

長い間、放置され修正を忘れていたものだった・・・
それを思い出し、ちゃんと実装した。

• エラー割り込みを有効にして、エラーフラグを消去する
• エラーの回数を記録する

まだ、緻密なテストを行っていないが、多分問題無いと思う。
エラーが発生した場合、受信データを捨てる事になるが、エラーをクリアして、正常に受信を行えば自動で復帰する。

ＲＸマイコン GUI ダイアログ

ダイアログボックスは、優先度の高い GUI で、フォーカスを占有する。
現状、gui/widget_director は、これらの管理を全くしておらず、新規に実装する必要がある・・

しかし、ここにきて、行き当たりばったりで実装してきた事がかなり痛いー、ちゃんと良く考えないと管理が難しく複雑になる。
少し時間を取って、ゆっくり考えたい。
glfw3_app では、実装済みなのだが、昔実装した時には、かなり面倒だったと記憶している。
本来、こんなに高機能にするつもりが無かった、シンプルな構造で十分と思っていたのだが、関数電卓の GUI を実装する過程で、やっぱり、シンプルな機能だけでは、不可能な事案が出てきてしまった。

最近ブログ書いて無かったので・・

ＲＸ１４０ボードは出来て、組み立て途中、クリスタルのフットプリントを間違えていた・・
新たに、ＵＳＢシリアルとして安価なCH340、を採用した、それは動いている事は確認した。
@70円は、確かに安いが、どうだろうか・・・

クリスタルの表面実装品は取り付けが困難な事が判ったー、ハンダペーストは出来れば使いたく無い・・

1603サイズのLEDが見つからないので、動作検査はまだ出来ていないが、まぁ問題無いと思う。

今回、JLPCBを使った。

準備が出来たら、領府を行う予定、多分１０００円位。

RX マイコンC++フレームワークの構成など、細かく見直した

まず、サポートしているＲＸマイコンの種別を増やした、ただ、実際にデバイスに書き込んで動作検査をしていない品種もある。
ChipOne ストップでの入手性、値段などから品種の追加等を行っている。
現行デバイスでは無いものでも、まだ流通している品種はそのまま残しているが、古いデバイスを新たに追加するかは未定。

• RX13T
• RX140
• RX220
• RX231
• RX23T
• RX24T
• RX24U
• RX26T
• RX62x
• RX63x
• RX63T
• RX64M
• RX65x
• RX660
• RX66T
• RX66N
• RX671
• RX71M
• RX72T
• RX72N
• RX72M

又、各ディレクトリに「README.md」を置いて、特徴、リンカーファイルの構成、専用ファイル、基本ピンアサイン、フラッシュプログラマ関係の情報などを記述してコミットした。
これを観れば、デバイスを選択する際の要点などが判ると思う。

最近、秋月で、RX231 の販売を開始したようだが、値段が高く、フラッシュ容量も少ない品種で、中途半端な感じだ・・
※フラッシュ容量128Kは、USBが使えても、少ないと思う、それで580円、まぁCANが使える品種のようだが・・
それでも、一応、リンカーファイルは追加しておいた。
ChipOne ストップで、もっとフラッシュ容量が大きく、ピン数が多い品種を買った方が良いと思える。

CAN は自動車やバイクで使えるので、そのような用途に使えるかもしれない。
C++フレームワークでは、現在「RSCAN」は未サポートなので、早急に何とかしたい～

format_class を少しだけ更新

GitHub の format_class 関係、少しだけ修正した。

「make run」で、セルフテストを行うと、文字出力で、「ゼロサプレス」を使った場合にリファレンスと異なった動作をしていた。
それを修正した。
この評価は、clangコンパイラで行っており、「標準」的な動作なのだと思われる。

クロックのブーストを改修

俺俺C++フレームワークでは、クロックのブーストを独自に行っている。

RX64M、RX71M、RX65x、RX671、RX66N、RX72N、RX72M、RX66T、RX72T は、ほぼ共通のレジスタ構成で、共有化していた。
ただ、共有出来ない部分もあり、「#if、#endif」を使って、デバイス毎に、別けていた。

最近、新たな方法を導入して、これを、もっとスマートな方法で分ける方法を実装した。

無効なアクセスを行う定義

RX66T/RX72T には、サブクロック発信器が無いので、それに関係するレジスタは存在しない。

以前は、以下のようにしていた。

#if defined(SIG_RX66T) || defined(SIG_RX72T)
#else
            // サブクロック発信器制御
            device::SYSTEM::SOSCWTCR = 0b0'1010;
            device::SYSTEM::SOSCCR = device::SYSTEM::SOSCCR.SOSTP.b(!clock_profile::TURN_SBC);
#endif

この、「#if　～ #endif」で分ける実装は、一か所くらいなら、まだ良いが多くなると、読み辛くなるしスマートとは言えない、どうしたものかと考えていた。

そこで、根本に返り、レジスタクラスの定義をダミーにする事で、「#if ～ #endif」を除く事が出来る。
その代わり、見た目には、普通にレジスタをアクセスしているようにしか見えないのが問題ではある。
レジスタの定義を確認して、初めて、このアクセスがダミーで無効である事に気が付く。
一応、コメントには、そのように書いてあるが・・・

        template <uint32_t base>
        struct sosccr_null_t : public rw8_null_t<base> {
            typedef rw8_null_t<base> io_;
            using io_::operator =;
            using io_::operator ();
            using io_::operator |=;
            using io_::operator &=;

            bit_rw_t<io_, bitpos::B0> SOSTP;
        };

• rw8_null_t は、中身は空で、アクセスが発生しても何もしない
• これは、最適化により、完全に無くなる

この手法をとりあえず、system.hpp に導入し、関係レジスタの定義を見直した

#if defined(SIG_RX64M)
    typedef system_64m_t SYSTEM;
#elif defined(SIG_RX65N) || defined(SIG_RX651)
    typedef system_65x_t SYSTEM;
#elif defined(SIG_RX66N)
    typedef system_66n_t SYSTEM;
#elif defined(SIG_RX671)
    typedef system_671_t SYSTEM;
#elif defined(SIG_RX71M)
    typedef system_71m_t SYSTEM;
#elif defined(SIG_RX72N) || defined(SIG_RX72M)
    typedef system_72n_72m_t SYSTEM;
#elif defined(SIG_RX66T) || defined(SIG_RX72T)
    typedef system_66t_72t_t SYSTEM;
#endif

• 各クラスは、共通では無い部分のみ定義を行い、共通部分(system_base_t)は、継承している

    struct system_66t_72t_t : public system_base_t {

        static constexpr bool NCRGx_reg    = false;
        static constexpr bool NCRCx_reg    = false;

        // オプション設定メモリ
        static inline spcc_t<0x0012'0040> SPCC;
        static inline ofs0_t<0x0012'0068> OFS0;
        static inline ofs1_t<0x0012'006C> OFS1;
        static inline mde_t <0x0012'0064> MDE;

        static inline memwait8_t<0x0008'101C> MEMWAIT;

        static inline romwt_null_t<0x0000'0000> ROMWT;

        static inline sosccr_null_t<0x0000'0000> SOSCCR;

        static inline soscwtcr_null_t<0x0000'0000> SOSCWTCR;
    };

• 一応、コメントを入れてあるが、コメントはコードとは異なるので、多少問題があるとは思う・・

            // サブクロック発信器制御
            // サブクロックが RX66T/RX72T では、ダミーアクセスとなる。
            device::SYSTEM::SOSCWTCR = 0b0'1010;
            device::SYSTEM::SOSCCR = device::SYSTEM::SOSCCR.SOSTP.b(!clock_profile::TURN_SBC);

実装ミスがあり、RX66T/RX72T が起動しなかった・・・

• 電卓プログラムを確認している時、RX66T が起動しなかった。
• RX66T は RAM が少ないので、それが問題と思って、色々修正したが、動作しない。
• あれ？と思い、LED 点滅を実験したら、やっぱり起動しない。
• 調べると、上記のダミーアクセスコードに実装ミスがあり、それが原因だった。
• 大きな変更をしたら、ちゃんと確認しないと駄目だと痛感した。

RX24T のクロック設定にも問題が・・・

• 以前に、ソフトディレイループを、アセンブラコードにしたので、RX24T の微調整を行った。
• クロックを落とすとソフトディレイの誤差が大きくなる。
• 調べると、「SCKCR」の予約ビットの設定があり、それが抜けていたので修正した。
• それで、クロックを落とした場合でも、ソフトディレイがある程度正確になった。
• 最大速度（80MHz）で動かす場合には、問題無かった。