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

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

R8C I2C(RTC)のテスト

「R8C M120AN/M110AN」には、I2C専用ハードは無いので、ポートを制御する事で
同等の機能を実現するしかない。

個人的には、I2Cは嫌いだ、ポートの制御が面倒で複雑だし、速度もあまり速くなく、
デバイスによっては、特別なケアが必要な場合もある。
SPIはもっと簡単で高速だ、デバイスを沢山繋げるとポートを消費するけど、少なく
とも、DI、DOは共通化できるので、デバイスセレクトのみで、I2Cのように、
ポートの入出力がこまめに変化したりしない。
2本の制御線でやりとりするなら、より良い方法が他にあると思う、しかしながら、業
界標準的な位置づけになると、規格がはびこってしまい、どれもがI2C通信となる
困った状況だ・・・
ここまで、I2Cが流通してしまうと、規格が悪いとか言ってられなくなるのも事実で、
とりあえず、ソフト制御のI2Cクラスを実装する事とした。

とりあえず、手持ちのI2Cデバイスでテストしてみた、今回はDS1371を選んだ
DS1371は32ビットのバイナリーカウンターを内臓したRTCで、以前に、マキ
シム社にサンプルをもらって評価したデバイスの余りで、RTCの中でも構成としては
使いやすいデバイスである。(32ビットのカウンターが基本で、1.7V~5.5Vで動作)
※但し、購入するとなると、安くは無い事が判る、もっと複雑で扱いが面倒な、秒、分、
時、日、月、年などで構成されたタイプの方が安い。
degikey の場合で、377円
※1個100円くらいだと助かるのだが・・(R8Cより高いので違和感があるのか)
以前にもRXにこのデバイスを接続した時のブログで紹介したが、時間管理のデバイス
では、バイナリーカウンターがあればそれで十分で、他の構成は、使いにくいだけで、
最悪だと思う。
結局、まっとうな時間管理が必要な場合は、秒単位にシリアライズしなければならない。
※ハードを設計する人が、ソフトの都合をまるで判っていない例の一つだと思う。

さて、I2C専用ハードの場合と違って、プロトコルを細部まで理解する必要がある。
※ここで、大きなミスは、ネットにある情報が、自分の知りたい部分以外が多くて、
重要な部分を理解しないまま、「多分こうだろう」的な感じで、実装してしまい、
それが悪くて、中々通信が出来なかった事。
最終的には、DS1371の英文マニュアルの一部を読んでいて気がついた・・・
スレーブからのリード時のACKの振る舞いが判ってなかった・・・

IMG_0747

I2C関係の構成としては、以下のようになっている。

common/i2c_io.hpp  --->  I2C基本制御クラス
common/ds1371_io.hpp  --->  DS1371制御クラス
I2C_test/main.cpp  --->  SCL、SDA、ポート定義クラス

ポートの定義

// DS1371 I2C ポートの定義クラス
// P1_B7: SCL
// P4_B5: SDA
struct scl_sda {
    void init() const {  // オープン・ドレイン設定
        device::POD1.B7 = 1;
        device::POD4.B5 = 1;
    }
    void scl_dir(bool b) const { device::PD1.B7 = b; }  // SCL 方向 (0:in, 1:out)
    void scl_out(bool b) const { device::P1.B7 = b; }   // SCL 出力
    bool scl_inp() const { return device::P1.B7(); }    // SCL 入力
    void sda_dir(bool b) const { device::PD4.B5 = b; }  // SDA 方向 (0:in, 1:out)
    void sda_out(bool b) const { device::P4.B5 = b; }   // SDA 出力
    bool sda_inp() const { return device::P4.B5(); }    // SDA 入力
};

このクラス定義は、少し冗長だけど、I2CのSCL、SDAをどのポートに対応さ
せるかを実装する。
※詳細なテストはしていないが、オープンドレインポートじゃなくても動作すると思う。

デバイスの制御
「ds1371_io.hpp」はテンプレートクラスで上のポート定義を渡す。
内部的には、ポート定義は、i2c_io クラスにそのまま渡している。
デバイスの制御では
・初期化 ---> DS1371 の制御レジスターを設定する。
・リード ---> 32ビットカウンターの読み出し(time_t で受け渡しをする)
※RTC特有の部分として、確率的に読み出すタイミングでカウントアップが行われた際、
全てのカウンタ値が確定する前に不正な値を読み出してしまう場合があり、複数回読み出
して比較する事でこれを回避している。
・ライト ---> 32ビットカウンターへ書き込み(time_t で受け渡しをする)
※他のデバイスを制御するなら、このソースを参考にすれば、少しの手間で、色々なI2C
デバイスに対応できると思う。

I2C制御
基本的に、初期化と、読み出し、書き込みなどの関数しか無い。
また、7ビットのデバイスアドレスしか対応していないが、10ビットのアドレスを使って
いるデバイスは少ないようなので問題無いだろう。
一応、100KBPS、400KBPS を切り替えられるようにしてあるが、ソフトウェアーループによる
クロック生成なので、あまり正確ではなく、実際より10%以上遅いと思われる。

I2Cの仕様として、スレーブデバイスが、内部動作の影響で、応答出来ない場合に、SCL
を強制的に「0」にする事で、動作を遅延させる事が出来る。
初期設定では、その「待ち時間」の最大を「200」マイクロ秒としているが、

//-----------------------------------------------------------------//
/*!
    @brief  スレーブデバイスの「待ち」時間の最大値を設定
    @param[in]	busy	待ち時間(単位マイクロ秒)
*/
//-----------------------------------------------------------------//
void set_busy(uint16_t busy) { busy_ = busy; } 

関数で、大きな待ち時間を設定できるようにしてある。
この待ち時間を越えてSCLが引き伸ばされると、各関数はストールして、falseを返す。

------
libc の時間関数はかなり巨大な為、必要最小限な実装をした関数群を用意した。
・うるう年の補正、曜日の計算など含まれている。
・time_t から tm 構造体、双方向(シリアライズ、デシリアライズ)で変換可能
・タイムゾーンは+9時間(東京)にしてあり、ハードコーディングしてある。
・time_t はグリニッチ標準時間で管理している。

common/time.h
common/time.c

GitHub R8C

R8Cライターモジュール作成

R8Cの書き込みプログラム完成を受けて、とりあえず、まともなライターを製作してみた。
今回はライターモジュール側の製作です。

売られている比較的安価なR8C用ライターは、USBシリアルモジュールが乗っている。
しかし、シリアルモジュールは単独で動作させる事も多いので、別にしたいと思う。
これは、前回のブログの通りです。

一応、ライターモジュールを KiCAD で回路を引いてみた。
6Pのスイッチを設けて、「WRITER」モードと、「RUN」モードを切り替えている。
TXD 信号の扱いが、WRITE/RUN で代わるので、その切り替えも兼ねている。
「RUN」モード時、シリアルの入出力だけが、具体的に繋がる機能だけなので、LEDや、A/D
用のボリューム、スイッチなど取り付けるつもりだが、今回は、ケースの加工が面倒なので
今後の課題とする。
今回、TEXTOOL のICソケットを使って、ライターらしく仕上げてみた。

R8C_Writer
※KiCAD の関係ファイルは、GitHub にプッシュしてある。

IMG_0742

RXD、TXD は、どちら側から見ているのかで、逆の意味となる、今回は、シリアルモジュール側から見た、
端子名をそのまま使っているので、方向に十分注意してほしい。

FTDI:RXD <--- R8C:TXD
FTDI:TXD ---> R8C:RXD

又、TXD 端子は、ライターモードでは、P1_6 に接続している、これは、R8Cの書き込みモードではそ
のようになっているもので、何故そうなのかは不明。

IMG_0744

-----
FTDI 社の FT231X だけど、Windows7 ではデバイスドライバーのインストールが必要だったが、OS-X で
は、そのまま認識して、直ぐに使えた、ちょっとビックリ・・

FTDI 社のデバイスは、中国製のコピーデバイスが安価で出回っており、それを掴むと、純正ドライバー
では、コピーチップと認識して、弾くらしいので注意が必要。

R8Cフラッシュプログラムとりあえずベータ完成

まだ、機能的に欠けている部分もあるし、あまりにヒドイ実装の部分もあり、
手直しをしたいのだがーとりあえず、書き込み、読み出し、消去など、一通り
の機能は揃っているので、この辺で、ライタープログラムは、止めて、
R8C本体のプログラムなどを充実したい感じです〜
※ヒドイ実装とは、設定ファイルのパースとか、機能が分離出来ていない
モトローラーファイルフォーマットの入出力など。

※その為、バージョンは「0.72b」としている。

Renesas R8C Series Programmer Version 0.72b
Copyright (C) 2015, Hiramatsu Kunihito (hira@rvf-rc45.net)
usage:
r8c_prog[options] [mot file] ...

Options :
-d, --device=DEVICE		Specify device name
-e, --erase			Perform a device erase to a minimum
    --erase-all, --erase-chip	Perform rom and data flash erase
    --erase-rom			Perform rom flash erase
    --erase-data		Perform data flash erase
-i, --id=xx:xx:xx:xx:xx:xx:xx	Specify protect ID
-P, --port=PORT			Specify serial port
-a, --area=ORG,END		Specify read area
-r, --read			Perform data read
-s, --speed=SPEED		Specify serial speed
-v, --verify			Perform data verify
    --device-list		Display device list
-V, --verbose			Verbose output
-w, --write			Perform data write
    --progress			display Progress output
-h, --help			Display this

MacBook Pro でシリアル接続して、R8Cの書き込みや、消去、を色々試したけど、
とりあえず、何の問題も無い、十分に使えると思う。
自分としては、俺俺フレームワークでGUI版も作りたいけど、それはまた、後で
考えるとして・・

ソースコード一式は、GitHubにプッシュ済み、一応 MSYS2 でコンパイルと簡単な動作は
確認済みなので、Windows でも使えると思う、MSYS2 の clang では、シリアル制御関係の
ヘッダーが無い為、コンパイル出来ない、Makefile 内で、MSYS2 環境では gcc を使うよ
うにしてある。

ifeq ($(OS),Windows_NT)

R8C関係 GitHub

さて、R8Cは、メモリーが64K使える事が判ると、SDカードの操作も楽に出来そうだし、
色々と夢が膨らむ〜

R8C本体に行く前に、先週、買ってきたもので、ちゃんとしたライターを作っておこうと思う。
以前の書き込みハードはあまりにショボイ・・
色々考えた末、USBシリアル部分と、R8Cのライター部分を分離した構造にした。
USBシリアルは、色々な場合に使う事が多いので、分離しておけば、便利に利用できるだろう。

まず、USBシリアル変換、モジュールが比較的安く売られているので、それを使っても良いが、
小さいケースに収めて、綺麗に作りたかったので、部品をバラで買ってきた、デバイスは
FTDI の FT231XS、単品だと安くて210円だった。
SSOP20 ピンのハンダ付けが、少しだけ厳しい・・
それと、マイクロUSBコネクター、調べると、ミニUSBコネクターより、マイクロUSB
コネクターの方が、抜き差しの耐用が高いらしい。
また、スマホがマイクロUSBコネクターを採用している事が多く、ケーブルも調達がしやすい。
RTS、CTS、DTR、DSR など制御線を出しておきたいので10ピンのコネクターを出す。
それと、5V、3.3Vを切り替え出来るようにしておく。
3.3Vは、ICにレギュレーターが内蔵されているけど、取り出せる電流が少ないので、別途
三端子レギュレーターを載せる。

ケースは、「タカチ」の「TW4-2-6」を使った。

以前から、採用している構造で、非常に具合が良いのだが、L型の10ピンコネクターを横に出す
構造にして、反対側は、マイクロUSBコネクターの先端で受けるようにする事で、基板を抑える
事が出来、シンプルに収まる。

IMG_0733
IMG_0734
IMG_0735

一応KiCADで回路を引いた、この関係ファイルもGitHubにプッシュしてある。
SerialModule

IMG_0740
IMG_0741
IMG_0739

さて、これでシリアルモジュールが出来たー、次は本命のR8Cライターなんだけど、これは次回にでも~

R8C に新たなフラッシュ領域見つかる〜

100円で買えるマイコンとして、売られているR8Cですが、データシート上は、

RAM256バイト
フラッシュ2Kバイトです

ところが、実際は・・

RAM1366バイト
フラッシュ32Kバイト

まで使えると判り、小躍りしていました~

OS-Xでも、R8Cの開発環境を整える目的で、フラッシュ書き込みプログラムを開発していましたが、
その過程で、R8Cのフラッシュ領域には、まだ拡張された領域があるのでは無いかと思い、良く調べてみました。

すると・・・

0x10000~0x17FFFに、さらに32Kバイトの領域があり、実際に使える事が判明しました。

つまり、フラッシュ2キロバイトとは、見せ掛けの容量で、実際には64キロバイトの領域があります。
※市場では、容量が多く(最大16KB)値段が高いデバイスが存在しますが、基本的に中身は全て同一
なのでしょう・・

考えるに、「ATtiny2313」など100円マイコンと同じレンジのマイコンがラインナップに無いので、
それに相当するデバイスを揃える為に既存のデバイスを再利用したのだと思います、その時、本当の
RAM、ROM容量では、他のラインナップと競合してしまうので、苦肉の索として、100円に釣り
合うと思われる小さい容量で売り出したのでしょう・・

現在のところ、最強の100円マイコンだと思います(笑)

さて、領域がある事が判ったのですが、R8Cのポインターは16ビットなので、基本的には64KB以上の
領域にアクセスするには、工夫が必要です、R8Cは20ビットのアドレス空間までアクセス出来る仕組みが
あるので、アセンブラなら、下駄を履かせてアクセスする方法がありますが、 gcc ではどうでしょうか?
調べてみると、64KB以上のアドレスの関数をコールする為の仕組みがあり、それを使う事で、拡張領域を
使う事が割と簡単に出来るようです。

まず、リンカースクリプトに拡張領域を追加します。

MEMORY {
    RAM (w)  : ORIGIN = 0x00300, LENGTH = 0x00400
    ROM (r)  : ORIGIN = 0x08000, LENGTH = 0x07FD8
    EXT (r)  : ORIGIN = 0x10000, LENGTH = 0x08000
    VVEC (r) : ORIGIN = 0x0FED8, LENGTH = 256
    FVEC (r) : ORIGIN = 0x0FFD8, LENGTH = 40
}

次に、セクション領域を宣言しておきます。

  .exttext   :
  {
    *(.exttext .stub .exttext.* .gnu.linkonce.t.*)
    KEEP (*(.exttext.*personality*))
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
    *(.interp .hash .dynsym .dynstr .gnu.version*)
  } > EXT =0

これで、ソースコードで拡張領域のセクション指定すれば、通常領域から押し出す事ができます。
※ADC_testで main 関数を押し出してみました。

__attribute__ ((section (".exttext")))
int main(int argc, char *argv[])

コンパイル、リンクも普通に通り、出来上がったバイナリーをデバイスに書き込んでみましたが、普通に動きます。

Motolola Sx format load map:
  0x008000 to 0x009225 (4646 bytes)
  0x00FF00 to 0x012DB6 (11959 bytes)
  Total (16605 bytes)

R8C フラッシュプログラム

OS-X 用に R8C 用 gcc もビルド出来た事だし、フラュシュライターを実装する事にした。
これが出来れば、MacBook などで R8C の開発が全て完結する〜

R8C/M120AN、R8C/M110AN の場合、mode 端子を Low にしてリセットをかけると、ブートモードになり
シリアル通信で、コマンドとデータを送る事で、内部フラッシュメモリーをプログラミング出来る。

尚、ライターは簡単に自作出来るが、出来合いもあり、これがお勧めかも・・
R8C/M12A ライタ&LEDキット【MR8C-TRM】

通信プロトコルは、以下のリンクから資料を取得した。
R8C/1x、2xシリーズ 標準シリアル入出力モードプロトコル仕様書
R8C/Mxシリーズ、LAxAグループ 標準シリアル入出力モードプロトコル仕様書

最初のハードルは、OS−Xって、どうやって「シリアル通信」すんの?
だった、でも、ちょっと調べたら、どうやらPOSIX準拠のシリアル通信APIをサポートしており、要はLinuxと同じ
コードで、大丈夫のようだったー、これは、MinGWでもサポートしているようなので、簡単にマルチプラットホーム
に出来るおまけ付きだ!
※ただ、デバイスファイル名は、OS依存なのだと思う。

とりあえず、FTDIのシリアルUSBブリッジを接続したら、/dev/tty*にそれらしいデバイスが認識される。

crw-rw-rw-  1 root  wheel   18,   6  5  7 21:18 /dev/tty.usbserial-A600e0xq

これを使って、簡単な通信を行いテストすると、普通に動作する〜
「rs232c_io.hpp」に必要な機能を盛り込んだ〜

それではと、色々ガリガリプログラムを作成して、とりあえず、出来上がった〜
まだ機能追加中で、中途半端な状態ではあるけれども、一応動作しているようだ。
GitHubで公開している。

仕様的には、千秋ゼミで公開されているr8cprogを元にしている。
※このプログラムをダウンロードするには、登録が必要。

ただ、C++ でスクラッチから組んだものなので、動作は、オリジナルとは違うので注意。
俺俺フレームワークとして、「file_io、string_utils、sjis2_utf16」など同梱している。

r8c_prog -d R5F2M120 -s 57600 -e -w -v uart_test.mot

現在は、デバイス名は無視されています。
ポートは、何も指定しないと、上記のデバイスパスが使われるようにしてあります。
また、コンパイルには boost が必要です。

Windows 環境では、テストされていません。
Msys2環境でコンパイル、実行を試しました。
※select の挙動が、OS−Xと違っていて、少し悩みましたが、とりあえず、問題無く動作するようになりました。

R8Cコンパレーターのテスト

R8Cの機能を一通り実装、テストしている。

今回は、コンパレータークラス。

テストプログラムでは、ICOMP3、IVREF3 を電圧比較をして、その結果、LEDの点滅速度が変わると言うもの。
※実験では、REF側に、VCCを1/2に分圧し、COMP側にボリュームを接続、確認した。

R8Cには2チャネルのコンパレーターがある、機能的には、単純な物だが、割り込みを使った時に、実行する
処理をどのような構成にするか、考えてみた。
以前にタイマークラスを実装した時に、タイマー割り込みから、何らかの処理を実行できるように、

void (*task_)(void);

実行ポインターを用意した、ところが、こんな事をすると、コンパイラは、「task_」で何が実行されるか不明
な為、メイン側で利用しているライブラリーのワークを全てスタックに積むようコードを生成する。
※タスク内で、メイン側と同じライブラリーを使った場合に備える為で、強引な方法だが、動作は正しい。
しかし、これでは、スタックが直ぐに限界を超え深くなるのは容易に想像出来る、その為、「実行ポインター」
でのタスク管理は不採用とした。

そこで、コンパイル時に静的な関数が実行できるような仕組みを追加した。
関数オブジェクトを使い。

class task {
    public:
    void operator() () {

    .....

    }
};

()オペレーター内に、実行したい手続きを実装して、それをテンプレートの引数とする。
関数オブジェクト内の手続きが何も無い場合、コンパイラは、その部分一切を削除する。

template <class TASK1, class TASK2>
class comp_io {

    static TASK1 task1_;
    static TASK2 task2_;

    public:
        static INTERRUPT_FUNC void itask1() {
            task1_();
            WCB1INTR.WCB1F = 0;
    }

    .....

};

これなら、コンパイラが、テンプレートクラスを展開する時に、割り込み内手続きを考慮するので、ライブラリー
で使われる変数の退避も最小限となる。

COMP_test ソースコード

-----
そして、R8CのI/O定義は、ほぼ全てを網羅した。

R8C PWM出力(タイマーC)

R8C関係のリソースもかなり色々揃って来ました。

組み込みマイコンでは、外せないPWM機能の実装です。

一般的に、組み込みマイコンのハードウェアータイマーの機能は、多機能で、複雑です。
R8C/M120の、タイマーCでも、PWMは二通りのモードがあり、その他に、インプットキャプチャなど
色々な機能があります。

今回は、3チャネルの出力が可能な、PWMモードの実装を行いました。
※今後必要になったら、PWMモード2や、インプットキャプチャーなど、他の設定も組み込む予定です。

PWMの場合、デューティ可変範囲を切りのよい2のn乗にしたい場合と、あくまでも周波数(周期)で設定
したい場合がありますので、引数の違う2つの設定を用意してあります。

今回、必要無かったので、割り込みを使っていません。

このタイマーCのPWM出力は、設定値とカウンターの一致を利用しているので、設定値を書き換えるタイミングに注意
する必要がありますが、現状の実装では考慮されていません。

    // PWMモード設定
    {
        PML1.P12SEL = pml1_t::P12TYPE::TRCIOB;
        PML1.P13SEL = pml1_t::P13TYPE::TRCIOC;
        PML1.P10SEL = pml1_t::P10TYPE::TRCIOD;
        bool pfl = 0;  // 0->1
        timer_c_.start_pwm(10000, pfl);
        uint16_t n = timer_c_.get_pwm_limit();
        timer_c_.set_pwm_b(n >> 2);  // 25%
        timer_c_.set_pwm_c(n - (n >> 2));  // 75%
    }

↑の例では、PWM周波数を10KHzとしています。
B出力には25%、C出力には75%のデューティで出力します。

    if(adc_.get_state()) {
        uint32_t v = adc_.get_value(1);
        v *= timer_c_.get_pwm_limit();
        timer_c_.set_pwm_d(v >> 10);
	adc_.start();
    }

又、C出力にはLEDが接続してあるので、AN1入力にボリュームを繋げて、0~100%まで
デューティを変化させられますのでLEDの明るさが変化します。

-----
I/Oポートの定義を見直し、ポートのマッピングに「固有の型」を導入しています。
その為、設定が判りやすく、誤設定も減ると思います。

        PML1.P12SEL = pml1_t::P12TYPE::TRCIOB;
        PML1.P13SEL = pml1_t::P13TYPE::TRCIOC;
        PML1.P10SEL = pml1_t::P10TYPE::TRCIOD;

※この型には「enum class」を使っている為、C++11対応コンパイラでコンパイルする必要があります。
現在 gcc-4.7.4 なので、「-std=c++0x」オプションを使っています。

PWM_test

GitHubにソースをプッシュしました。

R8Cデータフラッシュの操作

さて、今回はデータフラッシュメモリーを扱います。

R8Cには、プログラムフラッシュとは別に、データの記録用の小規模なフラッシュメモリーが別にあります。

3000番地から始まり、容量2048バイトです。
※1024バイト毎にバンク0、バンク1と分かれています。
フラッシュメモリーは、「1」のビットを「0」にする事は出来ますが、「0」のビットを「1」にする場合は、バンク毎に
イレースコマンドを発行して、全て「1」の状態に戻します。

この辺りのマネージメントが、多少難しいのですが、電源を切っても、記録を残す事が出来るので、非常に有益なメモリーと言えます。

テストプログラムでは、バイト単位での読み出し、書き込み、イレースなどが対話形式で行えるようにしてあります。
※シリアルポートにターミナルを接続します。

Start R8C FLASH monitor
# ?
erase bank[01]
r xxxx
write xxxx yy
# r 3
FF
# write 3 56
# r 3
56

操作説明:
? ---> 簡単な説明
r xxx ---> xxx のデータをリード
write xxx yy ---> xxx へ yy を書き込み
erase bank0 ---> バンク0を消去(0x3000 to 0x33ff)
erase bank1 ---> バンク1を消去(0x3400 to 0x37ff)

※xxx アドレスは、0 から 7ff までの領域です
※値は全て16進数で行います

本来は、プログラム領域の操作関数も含めたいところですが、それは、また次の機会(必要になったら)とします。

-----
R8Cへのプログラム書き込みには、ルネサスのFDTを使っていましたが、コマンドラインから気軽にプログラム出来れば便利です。
又、FDTは Windows 環境にしか対応しておらず、Linuxや、OS-X での開発には不向きでしたが、先日、AVR関係でお世話になっている
YCITのsenshuさん
の掲示板で、コマンドラインで使える、R8C 用プログラムコマンドが公開されました。
元々は、ゆきさん開発の r8cprog を元にしていて、M120AN 32K Flash に対応した
ものですが、使いやすいように、その他の小規模な改造も行っており、安定性も増しています。
私は、コマンドラインから使えるのが便利ですが、GUI 版も用意されており、シンプルで良く精査されたシンプルな設計により、予備知識が無く
ても直ぐに使えるようになっています。
Linux にも対応している事から、OS-X にも対応可能と思います、こちらは、時間が出来たら挑戦してみるつもりです。

R8C割り込みの注意点

ADCを動作検証するサンプルで、UARTとタイマーの割り込みを使うようになった。
他、色々複雑化しているのだが・・

非常に気になる事案が発生するようになった、数時間程度稼動させていると、ハングアップするのだ・・

スタックかと思い調べたが問題無い・・

全く原因が掴めないので、しばらく放置していたが、たまたま確認の為、R8Cのマニュアルを観ていたら
気になる事項が・・

5.7.3 割り込み制御レジスタの変更
(1) 割り込み制御レジスタは、そのレジスタに対応する割り込み要求が発生しない箇所で変更してく
ださい。割り込み要求が発生する可能性がある場合は、割り込みを禁止した後、割り込み制御レジ
スタを変更してください。
(2) 割り込みを禁止して割り込み制御レジスタを変更する場合、使用する命令に注意してください。
IRビット以外のビットの変更
命令の実行中に、そのレジスタに対応する割り込み要求が発生した場合、IR ビットが“1”(割り込み
要求あり)にならず、割り込みが無視されることがあります。このことが問題になる場合は、次の命令
を使用してレジスタを変更してください。
対象となる命令…A N D 、O R、BCLR、BSET
IRビットの変更
IR ビットを“0”(割り込み要求なし)にする場合、使用する命令によってはIR ビットが“0”にならな
いことがあります。IR ビットはM O V 命令を使用して“0”にしてください。

は!?、うーーーん、そうか・・・
これは、要するに、リードモディファイライト命令など、リードからライトへの遅延が短い場合に、
フラグのリセットに失敗するのだろう、しかし、わかり難いのは、常に失敗する訳では無く、何か
の条件が重なると失敗するようだ。
もしかしたらコレかもしれない、そこで、割り込みフラグのリセットを全般的に書き換えた。

※タイマーの割り込みフラグのクリア部分

以前は、
    TRBIR.TRBIF = 0;

だったのを・・

    volatile uint8_t r = TRBIR();
    TRBIR = TRBIR.TRBIF.b(false) | (r & TRBIR.TRBIE.b());

とした。
※同じように、UARTの制御クラスにも修正を加えた。

ここで、TRBIR レジスターを1度読み出しているのだが、「volatile」を指定しないと、最適化されて、
AND 命令とかでI/Oを直接書き換えるようなコードが出てしまう。

この検証には時間がかかる・・・
24時間走らせたが、今度は順調なので、多分解消されたと思う。
割り込みフラグを「消す」場合には注意が必要だ・・

ただ、コンパイルされたアセンブリコードには多少無駄な部分がある、しかしこれはコントロールが難しい
ので、我慢するか、アセンブラで書き直すしかない。
折角、可読性を重視して C++ を活用しているので、まぁ我慢しておく事にする。

元のソース
    uint8_t r = TRBIR();
    TRBIR = TRBIR.TRBIF.b(false) | (r & TRBIR.TRBIE.b());

    8266:	97 80 e7 00 	and.b:s #-128,0xe7
「volatile」修飾子を使った場合
    volatile uint8_t r = TRBIR();
    TRBIR = TRBIR.TRBIF.b(false) | (r & TRBIR.TRBIE.b());

    826b:	75 c4 e7 00 	mov.w:g #231,a0
    826f:	72 60       	mov.b:g [a0],r0l
    8271:	02 ff       	mov.b:s r0l,-1[fb]
    8273:	0a ff       	mov.b:s -1[fb],r0l
    8275:	94 80       	and.b:s #-128,r0l
    8277:	72 06       	mov.b:g r0l,[a0]

R8C A/D変換

R8CのA/D変換も出来ました。

ただ、別の部分で、工夫が必要な事が判りました。

工夫と言うのは、バイナリーサイズが肥大化しているのです・・
問題になってるのは「format」クラスです。
このクラスは、「printf」に代わるものとして実装した物ですが、16キロバイトにもなります。
フラッシュメモリーは32キロまで使えるとは言え、流石に半分も消費するのでは問題です。
RXマイコンで実装した物をほとんどそのまま使っているのですがー、RXマイコンではそこそこのサイズでしたが、R8Cでは巨大になるのです・・

動作は、設計の通りですが、小さくする工夫をする必要があります。

しばしば、小さな組み込みでは、libc の printf が巨大になるので、縮小版を作る人が多いですが、自分もその口です。
そもそも、printf は、引数がスタックベースなので、フォーマットと、引数が食い違う場合に簡単にクラッシュするか、
意図しない微妙な動きになる場合があります。
コンパイラーが整合性をチェックしますが、完全ではありません。
C++では、そんな危険を冒さなくても、安全な方法が色々あります。
「format.hpp」は、オペレーターの機能を使って、boost::format のような実装を行った物です、boost::format 版は、std::cout が必要な為、バイナリーが肥大化して使えませんので、縮小版です。

  int i = 123;
  printf("%d\n", i);

が、

  uint32_t i = 123;
  format("%d\n") % i;

のように書けます。
※R8Cでは「int」が16ビットなので、in32_t、uint32_t を使います。
※「%」オペレーターをオーバーロードしています。

調べると、現在の実装では、文字の出力や、定型サイズなどをテンプレートの引数として受け取るのですが、これが肥大化の要因のようです。
そこで、テンプレートをやめ、通常のクラスとして定義しなおし、エラーレポートもオフにしてみました、その結果、半分以下になりました。
これなら、許容範囲と思いますと言いたいのですが、もう少し何とかしないと駄目な感じです・・
R8C の gcc はメンテされていないのと、基本16ビットのCPUなので、コンパイラのコード生成に問題があるのかもしれません・・
※R8Cでは、フラッシュは64キロ以内なので、64キロを超えてジャンプする機構は必要無いのですが、コンパイル
されたマシンコードには、そのキックコードが含まれています、コンパイラのスイッチで排除出来ると思いますが、少し調べた限りでは判りませんでした・・

さて、本題はA/D変換です、R8Cに内臓されているA/Dコンバーターは10ビットの分解能で、2チャネル、アナログ入力は6チャネルあります。
変換速度は高速で、最大で2.3uSです。
アナログ用電源はピン数の制限から、デジタル電源と共通ですが、ルネサス系のCPUは電源ノイズも少なく、A/D変換の精度もAVR系より優れている感覚があります。
※AVR系ではサンプルホールドが無い為、変換結果に誤差が乗り易く、正確な変換を行うのが難しいと思えます。

format クラスには、A/D変換などの表示に適した、固定小数点表示「%y」を実装してあります。
A/D変換結果は大抵、電圧や電流などですが、表示する場合、小数点付きで10進表記で表示した方が判りやすい
ですが、通常だと実数と少数部を分けて、別々に計算をする必要があり、多少面倒です。

固定少数点表記機能を使うと、例えば、1023を5Vとすると、実数1桁、小数2桁、小数点以下8ビットの精度としてー

  uint16_t v = adc_.get_value();
  format("%1.2:8y") % static_cast(((v + 1) * 10) >> 3);

とすれば、v が1023の場合に「5.00」と表示できます。

A/D変換のサンプルコード

浮動小数点の計算は、リソースを食うし、FPUが無いとスピードも出ませんので、固定小数点の計算を簡単に行えると便利だと思います。
※何故10倍して8で割っているのか、良く考えれば判ります。

現在の「format.hpp」は「float、double」の実装がまだで、中途です、IEEE754 の表示を浮動少数点を使わずに整数計算だけで実装したいのですが、苦労しています、道まだ半ばです・・・

型指定子にどんなものが使えるか、「format.hpp」を観れば直ぐに解ると思います。
※8進数は、通常あまり使わないので、オプションとしています。