「ソフトウェアー・エンジニアリング」カテゴリーアーカイブ

ソフトウェアー関係の話題など・・

最近は、github にプッシュしてます~

整数計算でサインテーブルを生成する

これは、アセンブラ時代に、サインテーブルを生成する方法を色々試して、ある程度
成果のあった方法です。
※浮動小数点の sin で求めた値と微妙に違うところもありますが、実用性は十分あり
ます。

現在の C++11 以降では、constexpr でコンパイル時に計算して、定数としてソースコ
ードにテーブルを埋め込む事ができるので、必要性は薄いのですが、知っていれば、
応用範囲は広いでしょう。
ハードウェアーに実装して、周波数シンセサイザや音源の波形ベースに使う事も考え
られます。

x' = x・cos(s) - y・sin(s)
y' = x・sin(s) + y・cos(s)

s が十分小さい場合、以下のように近似できる。
cos(s) ≒ 1
sin(s) ≒ s

x' = x - y・s
y' = x'・s + y

テーブル生成に使っていますが、連続性がある場合は、リアルタイムに計算する事も
できます。(こちらの方が応用性があります)

非常に古いですが、1979年に発売された、ナムコのギャラクシアンで、編隊が、
実機の手前で、回転したり、サインカーブ的な軌跡で攻撃してくる場面がありますが、
この原理が使われていました。
※この当時、安易にテーブルにする人が多い中で、真のエンジニアでした。

また、単振動を使って、サインテーブルを計算する方法もあるかと思いますが、周期
を決定する定数を求めるのは、整数計算だけでは、簡単では無いと思えます。

テーブル生成では、テーブルのサイズは、2のN乗の方が、扱いやすいので、sの定
数を求める場合は、全円周(2・π)を、テーブル長で割る必要があります。

template <uint16_t shi, uint16_t len>
class sin_cos {

    static const uint32_t pai_ = 0xC90FDAA2;    ///< 円周率(3.141592654 * 2^30)
    static const uint32_t pai_shift_ = 30;      ///< 円周率、小数点位置

    uint16_t tbl_[(1 << shi) + 1];

    void build_()
    {
        int16_t gain = 16;  // 精度を確保する為の下駄
        int64_t x = len << gain;  // cos(0) の値
        int64_t y = 0;    // sin(0) の値
        for(uint16_t i = 0; i < ((1 << shi) + 1); ++i) {
            tbl_[i] = y >> gain;   // pai_ のビット位置補正
	    // 全周は、2・πなので+1
	    x -= (static_cast(pai_) * y) >> (pai_shift_ + shi + 1);
	    y += (static_cast(pai_) * x) >> (pai_shift_ + shi + 1);
        }
    }
    public:
        sin_cos() { build_(); }
};

整数演算で平方根

最近、整数演算だけで色々する話があったので、過去に作成したものを見直してみた。

・平方根
これは、ファミコン時代から使っていた方法をC++(C)で表現したもので。
※アルゴリズムは、コンピューターが出現する以前から知られていた数学的手法を元に
しているようで、初期のデジタルコンピューターが出現する、数十年前に既に知られて
いた方法のようである。

過去には、色々なマイコン用(6502、6809、68000、Z80)アセンブラ
で書いた記憶がある。
Cなどの高級言語では、キャーリーの扱いが無い為、シフトや、ビット操作を行う場合
無駄が多い。
アセンブラで書けば、より一層の高速化ができるけど、互換性を考えて、Cで実装して
ある。
ハードウェアーにも実装しやすく、割り算よりリソースを使わないと思われる。
※整数計算なので、「余り」がある。

ゲームにおいて平方根は、必ず必要な「道具」で、シューティングゲームの誘導ミサイ
ル、正規化、ほぼありとあらゆる場面で使うと思われる。

template <typename T>
struct sqrt_t {
    typedef T value_type;

    T   val;    ///< 答え
    T   mod;	///< 余り

    sqrt_t(T v = 0, T m = 0) : val(v), mod(m) { }
};

static sqrt_t<uint16_t> sqrt16(uint16_t in)
{
    uint32_t a = in;
    uint32_t b = 0x4000;
    for(int i = 0; i < 8; ++i) {
        if(a >= b) {
            a -= b;
            b = ((b + b) & 0xfffe0000) + 0x10000 + (b & 0xffff);
        } else {
            b = ((b + b) & 0xfffe0000) + (b & 0xffff);
        }
        a <<= 2;
    }
    sqrt_t<uint16_t> ans(b >> 16, a >> 16);
    return ans;
}

・32ビット版

static sqrt_t<uint32_t> sqrt32(uint32_t al)
{
    uint32_t ah, bh, bl;

    ah = bh = 0;
    bl = 0x40000000;
    for(int i = 0; i < 16; ++i) {
        if(al >= bl) {
            if(ah >= bh) {
                ah -= bh;
                al -= bl;
                bh += bh + 1;
            } else {
                bh += bh;
            }
        } else {
            if(ah >= (bh + 1)) {
                ah -= bh + 1;
                al -= bl;
                bh += bh + 1;
            } else {
                bh += bh;
            }
        }
        ah <<= 2;
        ah += al >> 30;
        al <<= 2;
    }

    sqrt_t ans(bh, ah);
    return ans;
}

intmath.hpp

マイクロチップ用開発環境を構築

マイクロチップ用のソースを修正する作業が生じた為、Windows で、環境構築をしてみた。

遠い昔に、マイクロチップが出始めた時に、自分でアセンブラを実装して開発した覚えが
あるが、最近は、AVRやルネサスがメインとなり、使わなくなった。

開発環境が有料な事や、プログラマーが高いのも敬遠する理由ではある。
・プログラマーを自分で作る事もできそうだが、種類が多いので大変そうだ・・・
・60日を過ぎると、無料版は、最適化が「-O1」のみとなる。
※一応ソースコードが入手できるので、パッチを当てて、制限を回避する事も出来るよう
だが・・・
・現状で、C++14 のコードをコンパイル出来ないのは、まともなコンパイラとは思えない。

PICの良い面は、デバイスの入手性、バリエーションの多さ、「コスパ」なのだと思うが
自分はメリットを感じない。

今回使うチップは、「PIC24EP256GU810」で、「MPLAB C30」をインストールした。
※コンパイラは魔改造された gcc のようだ。

例によって、IDEを使わず、コマンドラインで開発したいので、Windows、MSYS2 で動作
させてみた。
以前から少しづつアップデートしている独自の「Makefile」を PIC30 用に修正しておこなった。
※この「Makefile」は、非常に柔軟性が高い!
従属規則の生成も全く問題無く、正常に生成された。
そして、暫く格闘したが、コンパイルしてリンクできるようになった。

・MPLAB C30 にパスを通す。(PATH=$PATH:/c/'Program Files (x86)'/Microchip/'MPLAB C30'/bin)
・デバイスを指定する。(-mpu=24EP256GU810)
・適切なコンパイルオプションを選ぶ。(-mlarge-code -mlarge-data -mlarge-scalar -mconst-in-data)
・適切なリンクオプションを選ぶ。(-T p24EP256GU810.gld --heap=1024 --stack=1024)

これだけ行って、コンパイル、リンクが通った。

#=======================================================#
#                                                       #
#    PIC C30 Makfile                                    #
#                                                       #
#=======================================================#
TARGET  =   farm

DEVICE  =   24EP256GU810

BUILD   =   release

VPATH   =

ASOURCES =

CSOURCES =   ここにソースファイルを列挙する~

PSOURCES =   

USER_LIBS =

LDSCRIPT  =

USER_DEFS =

INC_SYS   =

INC_APP   =

OPTIMIZE  =   -O1 -mlarge-code -mlarge-data -mlarge-scalar -mconst-in-data

MCU_TARGET =   -mcpu=$(DEVICE)

CP_OPT   =   -Wall -Werror \
             -Wno-unused-variable \
             -Wno-unused-function \
             -fno-exceptions

#CC_OPT  =   -Wall -Werror \
#            -Wno-unused-variable \
#            -fno-exceptions
#CC_OPT  =   -x c
CC_OPT   =

SYSINCS  =   $(addprefix -I, $(INC_SYS))
APPINCS  =   $(addprefix -I, $(INC_APP))
AINCS    =   $(SYSINCS) $(APPINCS)
CINCS    =   $(SYSINCS) $(APPINCS)
PINCS    =   $(SYSINCS) $(APPINCS)
LIBINCS  =   $(addprefix -L, $(LIB_ROOT))
DEFS     =   $(addprefix -D, $(USER_DEFS))
LIBS     =   $(addprefix -l, $(USER_LIBS))

# You should not have to change anything below here.
AS       =   pic30-as
CC       =   pic30-gcc
CP       =
AR       =   pic30-ar
LD       =   pic30-ld
OBJCOPY  =
OBJDUMP  =   pic30-objdump
SIZE     =
HEX      =   pic30-bin2hex

# AFLAGS =   -Wa,-adhlns=$(<:.s=.lst),-gstabs
# AFLAGS =   -Wa,-adhlns=$(<:.s=.lst)
# ALL_ASFLAGS = -x assembler-with-cpp $(ASFLAGS) $(DEFS)
ALL_ASFLAGS  =   $(AFLAGS) $(MCU_TARGET) $(DEFS)

# Override is only needed by avr-lib build system.

CFLAGS  =   $(CC_OPT) $(OPTIMIZE) $(MCU_TARGET) $(DEFS)
PFLAGS  =   -std=c++14 $(CP_OPT) $(OPTIMIZE) $(MCU_TARGET) $(DEFS)

# override LDFLAGS = $(MCU_TARGET) -nostartfiles -Wl,-Map,$(TARGET).map -T $(LDSCRIPT)
# override LDFLAGS = $(MCU_TARGET) -T$(DEVICE).gld,--defsym=__MPLAB_BUILD=1,--defsym=__MPLAB_DEBUG=1,--heap=1024,--stack=1024,-Map="VTS-10a.map"
override LDFLAGS = $(MCU_TARGET) -T p$(DEVICE).gld --heap=1024 --stack=1024

OBJCOPY_OPT  =   --srec-forceS3 --srec-len 32

OBJECTS =   $(addprefix $(BUILD)/,$(patsubst %.s,%.o,$(ASOURCES))) \
            $(addprefix $(BUILD)/,$(patsubst %.c,%.o,$(CSOURCES))) \
            $(addprefix $(BUILD)/,$(patsubst %.cpp,%.o,$(PSOURCES)))

DOBJECTS =  $(addprefix $(BUILD)/,$(patsubst %.c,%.o,$(CSOURCES))) \
            $(addprefix $(BUILD)/,$(patsubst %.cpp,%.o,$(PSOURCES)))

DEPENDS =   $(patsubst %.o,%.d, $(DOBJECTS))

.PHONY: all clean
.SUFFIXES :
.SUFFIXES : .rc .hpp .s .h .c .cpp .d .o

all: $(BUILD) $(TARGET).elf

$(TARGET).elf: $(OBJECTS) Makefile
    $(CC) $(LDFLAGS) $(LIBINCS) -o $@ $(OBJECTS) $(LIBS)
    $(HEX) $@ $(TARGET).hex

$(BUILD)/%.o: %.s
    mkdir -p $(dir $@); \
    $(AS) -c $(AOPT) $(AFLAGS) $(AINCS) -o $@ $<

$(BUILD)/%.o : %.c
    mkdir -p $(dir $@); \
    $(CC) -c $(COPT) $(CFLAGS) $(CINCS) $(CCWARN) -o $@ $<

$(BUILD)/%.o : %.cpp
    mkdir -p $(dir $@); \
    $(CP) -c $(POPT) $(PFLAGS) $(PINCS) $(CPWARN) -o $@ $<

$(BUILD)/%.d: %.c
    mkdir -p $(dir $@); \
    $(CC) -MM -DDEPEND_ESCAPE $(COPT) $(CFLAGS) $(APPINCS) $< \
        | sed 's/$(notdir $*)\.o:/$(subst /,\/,$(patsubst %.d,%.o,$@) $@):/' > $@ ; \
        [ -s $@ ] || rm -f $@

$(BUILD)/%.d: %.cpp
    mkdir -p $(dir $@); \
    $(CP) -MM -DDEPEND_ESCAPE $(POPT) $(PFLAGS) $(APPINCS) $< \
        | sed 's/$(notdir $*)\.o:/$(subst /,\/,$(patsubst %.d,%.o,$@) $@):/' > $@ ; \
        [ -s $@ ] || rm -f $@

clean:
    rm -rf $(BUILD) $(TARGET).elf $(TARGET).mot $(TARGET).lst $(TARGET).map

clean_depend:
    rm -f $(DEPENDS)

後は、書き込んでテストとなるが、ライターは自作する時間も惜しいので、仕方なく
「PICkit3」を買う(5700円)事にする。(自分のお金じゃ無いけど・・)
IMG_0898s
※自分は、デバッグ機能(トレース、実行など)が必要になった事が少ないので、
フラッシュ書き込みさえ出来れば、満足なのだけど・・・

やはり、コンパイラが有償(無償版は60日過ぎると、最適化できなくなる)なのは、最
悪だと思う、自分的には、仕事以外では絶対に使わないデバイスだと思う。

追記:
Windows10 のノートにもPICの開発環境をインストールしたが、コンパイラを走らせる
と「ライセンスがどうの」と言ってきてエラーになる・・・
調べると、「mplabc30-v3_31-windows-installer.exe」のバージョンに起因する、
license-lm 関係のバグのようだ、そこで、「v3_30」を取ってきてインストールした。

-----
やっぱり、ルネサス系、R8C、RL78、RXマイコンが最高だと、再認識する。
※コストでは、PICに武がある事は認めるのだけど・・・

RXマイコン用スタートアップのバグ

今まで、RXマイコンで、挙動が怪しい事があって、その原因が判らなかったが、
やっと判明した・・・

症状としては、
・スタックに配置した変数が書き換わる場合
・割り込みが多重に起動するような場合に多く発生
・多重じゃなくても割り込み関連が絡む場合など

どうもスタックが壊れている感じではあるけど、プログラムを追っても、問題無
さそう・・・

RXマイコンでは、スタックは、割り込み用スタック(ISP)と、ユーザース
タック(USP)に分かれていて、起動時、「start.s」のアセンブラプログラム
で設定されている。
ISPをメモリーの後半に置き、その手前にUSPを設定している。
当初、ISPの容量は32バイトくらいしか無かったので、256バイトにした
が、症状に変化は無い・・・

    .text
    .global  _start
    .type    _start,@function
_start:

# スタックの設定(SP:__stack、USP:__stack - 128)
    mov.l       #__stack, r0
    mvtc        r0, isp
    sub         #128,r0
    mvtc        r0, usp

ソフトウェアーマニュアルを読み直していたら、何と「R0」レジスタと「SP」
は扱いが同一となっていた!

汎用レジスタ R0 には、汎用レジスタとしての機能に加えて、スタックポインタ
(SP)としての機能が割り当てられています。

あ!、「R0」は使ったら駄目なんだ・・・・・・・・・

そこで、単純に、レジスタ名を変更

    .text
    .global  _start
    .type    _start,@function
_start:

# スタックの設定(SP:__stack、USP:__stack - 128)
    mov.l       #__stack, r5
    mvtc        r5, isp
    sub         #128,r5
    mvtc        r5, usp

この修正後、今までのおかしな挙動が直った。

今まで、結構大きなプログラムを動かしていたけど、よく動いてたなぁ・・・

経験的に、レジスターセットの後ろ(R15とか)にSPを置いてあるのが普通と
思っていたから、何も考えずに、R0を使ったのが間違いだった・・・
※ソフトウェアーマニュアルを良く読まなかったのが悪いのだけど・・・

-----
RXマイコンでは、スーパーバイザーモードとユーザーモードのRUNレベルがあり、
通常はユーザーモードで動作させる。

ユーザーモードで特権命令を実行すると、「特権違反例外」が発生する。

ユーザーモードに移行するには、「rte」命令などを実行した場合に、退避してあった
ステータスレジスターを復帰するが、その際、ユーザーモードフラグが有効になって
いれば、ユーザーモードに移行する為、以下のような、少しキワドイプログラムで移
行する。

# PMレジスタを設定し、ユーザモードに移行する、ユーザースタックに切り替わる
    mvfc    psw,r1
    or      #0x00100000, r1
    push.l  r1

# UレジスタをセットするためにRTE命令を実行する
    mvfc    pc,r1
    add	    #10,r1
    push.l  r1
    rte
    nop

※PCにオフセットを加える事で、RTE命令の下に復帰する。

RX64MにSDRAMを接続する

ようやく、SDRAMのテストを開始、結線は多いが、高速な大容量外部
メモリを得られる。
デバイスだけでも512Kバイトのメモリーを持っているので、通常は十
分ではあるけど、このようなデバイスじゃないと、SDRAMを制御する
為のハードウェアーを内臓していない、又、169ピンのデバイスじゃな
いと、32ビットの外部バスをサポートしていない。
※最大のパフォーマンスを得たいので32ビットバスで動かしてみたい。

普通は、基板を起こすべきなのだろうけど、実験ではそうもいかない。
と、言っても最近では、海外のメーカーに発注すれば、基板を新規に作成
するコストは尋常じゃ無く安いので、いきなり基板を起こしてみるのも悪
くないかもしれない。

クロックが高いので、手配線では動作が難しいかもしれないが、バスに接
続するSDRAMは、CPUの動作速度の半分でしかないので、(およそ
60MHz)このくらいなら、手配線でも何とか動作すると思う。
「反射」が起こって動作が不安定になった場合は、ダンピング抵抗を調整
してインピーダンスの整合を行えば、何とかなるのでは無いかと考えてい
る。
※変換基板では、電源ラインが相対的に弱くなるのが多少気になる。

デバイスは300円(128メガビット)なのに、変換基板(Aitendo 産)
が250円するけど、他に、収まりが良く、スペースが少ない変換基板が
無かった。
img_0867s
※基板を起こす時には256メガビット品を使うと思うが、組み込み用途
のSDRAMを単体で入手(秋葉原などで)できるのは限られている。

最近は、0.5mmピッチのハンダ付けが多かったので、0.8mmピッ
チは、凄く楽だったーー
変換基板には、何故か余分な部分があるので、カットして、裏面にある謎
の端子パッドも、いつものようにポリイミドテープで絶縁、ベース基板と
直接コンタクトさせる。
img_0870s
※ピン番号のシルクが一部間違っている・・(28、29ではなく、27、
28ね・・)
※ポリイミドテープの存在を知らない時は、「紙」を貼っていた。www

まず、電源ラインを配線してから、十分なパスコンを接続、それから配線
を行った、データバスは、液晶を接続するのにも使うので、別途、コネク
ターに出す。
・電源の配線
img_0871s

参考回路(ルネサスのRX64Mボードの例)
rx64m_sdram

厄介なのは、SDRAMの場合、初期化処理を行わないと、使う事ができな
い点で、それなりのパラメーターがある、とりあえず、ベストな設定より、
必ず動作しそうな無難な設定を考えてみた。
後は、SDRAMのマニュアルと、RX64Mのマニュアルを見ながら、行
い、とりあえず、書いたデータを読み出せた~
※もっと苦労すると思っていたので、意外な感じはあるが、メモリー空間は
32メガバイトもあるので、詳細なテストを行わないと、分からない。

バス・インターフェースの初期化

    // SDRAM 初期化 128M/32bits bus
    device::MPC::PFAOE0 = 0xff;  // A8 to A15
    device::MPC::PFBCR0 = device::MPC::PFBCR0.ADRLE.b(1) |
                          device::MPC::PFBCR0.DHE.b(1) |
                          device::MPC::PFBCR0.DH32E.b(1);
    device::MPC::PFBCR1 = device::MPC::PFBCR1.MDSDE.b(1) |
                          device::MPC::PFBCR1.DQM1E.b(1) |
                          device::MPC::PFBCR1.SDCLKE.b(1);
    device::SYSTEM::SYSCR0 = device::SYSTEM::SYSCR0.KEY.b(0x5A) |
                             device::SYSTEM::SYSCR0.ROME.b(1) |
                             device::SYSTEM::SYSCR0.EXBE.b(1);
    while(device::SYSTEM::SYSCR0.EXBE() == 0) asm("nop");

SDRAM の初期化

    device::BUS::SDIR = device::BUS::SDIR.ARFI.b(0) |
                        device::BUS::SDIR.ARFC.b(1) |
                        device::BUS::SDIR.PRC.b(0);
    device::BUS::SDICR = device::BUS::SDICR.INIRQ.b(1);  // 初期化シーケンス開始
    while(device::BUS::SDSR() != 0) asm("nop");
    // 動作許可、32ビットアクセス
    device::BUS::SDCCR = device::BUS::SDCCR.BSIZE.b(1);
    // Burst read and burst write, CAS latency: 3, Burst type: Sequential, Burst length: 1
    device::BUS::SDMOD = 0b00000000110000;
    // CAS latency: 3, Write recovery: 1, ROW prechage: 4, RAS latency: 3, RAS active: 4
    device::BUS::SDTR = device::BUS::SDTR.CL.b(3) |
                        device::BUS::SDTR.RP.b(3) |
                        device::BUS::SDTR.RCD.b(2) |
                        device::BUS::SDTR.RAS.b(3);
    // 128M/16 カラム9ビット、ロウ12ビット
    device::BUS::SDADR = device::BUS::SDADR.MXC.b(1);
    // Refresh cycle
    device::BUS::SDRFCR = device::BUS::SDRFCR.RFC.b(2048) |
                          device::BUS::SDRFCR.REFW.b(7);
    device::BUS::SDRFEN = device::BUS::SDRFEN.RFEN.b(1);
    // SDRAM 動作開始
    device::BUS::SDCCR.EXENB = 1;

img_0872s

SDRAM サンプル

RX24TでLCD表示と、各種LCD

部品の整理をしていたところ、色々なLCDが出てきた。
img_0858s
※安売りでバーゲンしてる時に買ったもの。

RX24Tには、まだ液晶を接続していなかったので、RX24Tで実験してみた。

赤い基板と横長の基板は、ST7565で、小さいのは、UC1701、白い枠は、
カラーTFT液晶。
横長は、モノ128×32、他はモノ128×64、カラーは128×160となって
いる。

どのLCDも、SPIで通信するものだけど、ピンアサインが、どれも微妙に異な
る・・・
また、基本的には、電源は3.3Vだけど、バックライト用電源が異なるモジュー
ルがある。(Aitendo さん何で同じにしないかなぁ・・・)

以前に買ったLCDで、LCDの不良(仕様違い)で、使わなくなっていたやつを
交換してきた、メールで問い合わせたら、返金すると言っていたが、同等品があった
ので、交換にした。
img_0862s
このLCDは大型でバックライトもあり、なかなか良い。

同じコントローラーでもLCDによりコントラストの設定が異なるのが、多少厄介。

img_0863s
※周囲が暗いけど、小さめの赤い基板のLCD、液晶の応答速度が若干速い気がする。

img_0859s
※さらに小型のLCD(バックライト付)で、コントローラーがUC1701

他にもあるが、どれも表示は問題無くできる。

    // SPI 定義(RSPI0)
    typedef device::rspi_io<device::RSPI0> SPI;
    SPI spi_;

    typedef device::PORT<device::PORT6, device::bitpos::B1> LCD_SEL;    ///< LCD 選択信号
    typedef device::PORT<device::PORT6, device::bitpos::B2> LCD_A0;     ///< LCD レジスター選択

#ifdef LCD_ST7565
    // ST7565 drive
    chip::ST7565<SPI, LCD_SEL, LCD_A0> lcd_(spi_);
#endif
#ifdef LCD_UC1701
    // UC1701 drive
    chip::UC1701<SPI, LCD_SEL, LCD_A0> lcd_(spi_);
#endif

「LCD_SEL」はLCDの選択信号
「LCD_A0」は、LCDの制御レジスター切り替え

LCDの切り替えは、インスタンスを代える事で行う。
「spi_」は、SPIを制御するクラスで、コンストラクター時、参照で受け取るよう
にしてある為、SPI の制御をシェア可能になっている。

LCDのコントラストは、LCDのスタート時に(初期化)設定する。

    lcd_.start(0x00);

※大きいタイプは0x10程度、他は、0x00くらいだった。(LCDにより調整
が必要なようだ)

RX24T、LCDサンプル

R8C関係、テンプレートライブラリのアップデート

R8C、RL78、RXマイコンと、実装を重ねた結果、色々と新しい試み(
判りやすさ、正確性、共有性、性能)が導入されて、昔に実装した、R8C関
係のテンプレートライブラリの完成度が相対的に低下している状況となってい
る。

ここらで、最新の実装方法を、R8Cにも反映するべく、アップデートを大々
的に行った。
この改修は、I2Cや、SPIデバイスの制御クラスを全てのプラットホーム
で共有する為の準備でもある。
また、デバイスのフラッシュ書き込み関係プログラムも改修を行った。

I2C、SPIインターフェースの完成度が低いので、その辺りも、RL78
やRXと同等な実装に切り替えた。

かなり大掛かりな手術となったが、一応完成した、これで、各プラットホーム
で、外部デバイスを共有する事が出来ると思う。

-----

以前にアマゾンで、LEDドライバー、マキシム社のMAX7219を買った。
MAX7219 7セグLED×8

部品単体で買っても1000円する(これは、高すぎるが・・)ので、とても
CPが高い。
一般的に、多数のLEDを接続するには、ポートや、電流容量の問題で、ドラ
イバーを入れなくてはならないので、それが簡単に接続できる。
ただし、電源は5Vなので、3.3Vのデバイスに接続するには、別途電源が
必要と思う。
そこで、電源電圧が自由に選べるR8C/M120ANで、5Vで駆動により、
接続実験を行った。

img_0857s

輝度をプログラム出来るとか、電流制限抵抗が少ない、デージーチェインできる
、ダイナミックスキャンが行われているなど、かなりユニークなデバイスで、取
り扱いが簡潔で良い。(少量でも安ければ良いのだけど・・・)

MAX7219サンプル

MAX7219制御クラス

BMP180/BMP280圧力センサー

最近、BMP280が、安く購入出来る事を知り、早速購入、実験してみた。
アマゾンで230円だった。
※湿度も計測できる、BME280は、まだ高価なようだ・・(@540)

BMP280は、BMP180の後継で、色々な部分が改善されているようだ、ただ、
温度や気圧を得る為のシーケンスは、BMP180とは異なる為、新規に実装する必要
がある。
今後は、BMP180はBMP280に置き換わるものと思われる。
※現状では、BMP280の方が安く入手できる。

BMP180とBMP280の主な違い:

Parameter:               BMP180                 BMP280
Footprint:               3.6 × 3.8 mm           2.0 × 2.5 mm
Minimum VDD:             1.80 V                 1.71 V
Minimum VDDIO:           1.62 V                 1.20 V
Current consumption:     12 μA                  2.7 μA
(@3Pa RMS noise)
RMS Noise:               3 Pa                   1.3 Pa
Pressure resolution:     1 Pa                   0.16Pa
Temperature resolution:  0.1°C                  0.01°C
Interfaces:              I²C                    I²C & SPI (3 and 4 wire, mode ‘00’ and ‘11’)
Measurement modes:       Only P or T, forced    P&T, forced or periodic
Measurement rate:        up to 120 Hz           up to 157 Hz
Filter options:          None                   Five bandwidths

早速、BMP280用にテンプレートクラスを実装して、動作実験を行った。
ここで、BMP180とインターフェースを合わせる為、BMP180の実装も見直した。
BMP180では、温度は0.1度単位で出力されるが、BMP280では、0.01度
までの分解能がある。
なるべく、小規模なマイコンなどで使う事を考えて、浮動小数点を使わないようにしたの
で、以前のインターフェースでは、10倍した整数で、温度を取得するようにしていたが
これを100倍とした。
圧力(ヘクトパスカル)は、元々100倍された値だったのでそのまま使った。
BMP280では、さらに小数点以下8ビットも有効のようだったが、センサの分解能か
ら考えて、必要ないと思ったので、捨てている。
圧力から、高度を求めるAPIは、std::pow を使うので、R8C版では、容量の関係で、
コンパイルは出来るものの、容量オーバーで、リンクに失敗する。
RL78でも問題無く機能するものの、バイナリーは64キロを超える。
※RXでは13キロ程度に収まる。

-----

補正などのソースコードはネットにあるソースを参考にしたけど、どうも、初期設定の
デバイスの動作モード設定に誤りがあるようで、データシートを読んで(観て)設定データ
としたが、それが正しいのか微妙ではある、データを1秒間隔で出力させると、それらしい
データを出力している。
※立川の高度は100mくらいのハズなので、かなり違うが、天気によりそれなりに変
化すると思うので、スルーしている。
※一応、圧力の補正ルーチンは確認しているが、特に間違いは無いと思える。

Bosh のデータシートには「filter」に関する説明が不十分なように思う・・・
※とりあえず、「Filter:16」の設定として、0b100としている。

BMP280 初期化コードの一部

    // Ex: Ultra high resolution
    // setting control
    // osrs_t(X2): 010, osrs_p(X16): 101, mode(Normal): 11
    uint8_t mode = 0b010'000'00 | 0b000'101'00 | 0b000'000'11;
    write8_(REG::CONTROL, mode);

    // setting config
    // t_sb(0.5ms): 000, filter(16): 100, xxx(0): 0, spi3w_en(0): 0
    uint8_t conf = 0b000'000'0'0 | 0b000'100'0'0 | 0b000'000'0'0 | 0b000'000'0'0;
    write8_(REG::CONFIG, conf);

img_0856s

Temperature: 19.51 C
Pressure: 1005.85 hPa
Altitude:   61.79 m
Temperature: 19.51 C
Pressure: 1005.86 hPa
Altitude:   61.71 m
Temperature: 19.51 C
Pressure: 1005.87 hPa
Altitude:   61.63 m
Temperature: 19.51 C
Pressure: 1005.87 hPa
Altitude:   61.63 m

BMP180/BMP280 サンプル

RX24TでA/D変換テスト

RX24Tは、モーター制御がターゲットだからか、A/D変換関係が、もの
凄く充実した(細かい)造りになっている。
変換時間は1マイクロ秒で、12ビットの精度があり、5チャンネルが2ユニ
ット、12チャネルが1ユニット、計22チャンネルと豪華で、付随する機能
も豊富で複雑だ。

流石、インバーター制御用なので、サンプルホールド回路が複数あったり、
ゲインを制御する機構があったり、モーター制御に必要な機構を網羅している
ようではある。
変換結果を受け取るレジスターも、個別になっているので、変換したいチャネ
ルを選んで、変換を開始するだけで、マネージメントも簡単で、処理負荷も少
なくてすむ。

とりあえず、単に変換するだけの機能を実装してテストしてみた。
他の変換モードは、必要になったら、適宜追加していくようにしたい。
ただ、テンプレートの定義は、複雑だったので、それなりに苦労した。
なるべく、3つのモジュールを同じように扱う事が出来るように工夫した。

チャネルの扱いをどのように扱うか、色々悩んだが、結局、各モジュールの定
義内に、「enum class」を使って、チャネル定義を行った。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  S12AD1 定義
    @param[in]	base	ベース・アドレス
    @param[in]	t		ペリフェラル型
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t base, peripheral t>
struct s12ad1_t : public s12ad_t {

    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  アナログ入力型
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    enum class analog : uint8_t {
        AIN100,
        AIN101,
        AIN102,
        AIN103,
        AIN116 = 0x10,
    };
.
.
.
};
typedef s12ad1_t<0x00089200, peripheral::S12AD1> S12AD1;

ユニット0、1は、チャネル5本で、5番目は、16番から開始する為、定数を16
としている、この値を使ってレジスターアクセスのオフセットとしている。
※ただ、こうすると、ループを回して、設定するような事が出来なくなるのが、痛い
が、アナログチャネルは、通常全て同一に使う事は少ないので、「良し」とする。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  S12AD2 定義
    @param[in]	base	ベース・アドレス
    @param[in]	t		ペリフェラル型
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t base, peripheral t>
struct s12ad2_t : public s12ad_t {

    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  アナログ入力型
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    enum class analog : uint8_t {
        AIN200,
        AIN201,
        AIN202,
        AIN203,
        AIN204,
        AIN205,
        AIN206,
        AIN207,
        AIN208,
        AIN209,
        AIN210,
        AIN211,
    };
.
.
.
};
typedef s12ad2_t<0x00089400, peripheral::S12AD2> S12AD2;

変換時間は1マイクロ秒と短い時間ではあるけど、80MHzのCPUの場合
では、変換開始から変換終了を待つのでは、十分な実装とは言えないので、割
り込み処理は実装してあり、変換終了時に、何かタスクを実行できるような仕
様としてあるが、どこまで実用的かは多少疑問が残る。
結局、リアルタイムカーネルのようなマルチタスクシステムにしないと真価を
発揮出来ないかもしれない。

RX24TのA/Dユニットの構成は、他のRXマイコンと比較して、汎用的
では無いため、変換操作を行う具体的なクラス「adc_io」は個別に定義した。
RX64Mや、RX63Tでは、別に定義する必要がある。

A/D 変換サンプル

RX24TでSDカードの読み書き

RX24TにもSDカードを接続してみた。

ほとんどは、RL78のリソースを使ったものの、FatFS を ff12b と最新の
実装を使った。
また、なるべく、固有のハードウェアー設定を追い出して、ハードの依存を
少なくする仕組みを整えた。

RX24Tには、専用のSPIチャネル(RSPI0)が1つだけあるので、
SDカードに割り当てた。
SDカードを扱うと、このチャネルはほぼ占有されてしまうと思うので、他
とのシェアをあまり考えなくてもも良いと思うが、一応、それも可能に出来る
ようにはしてある。

img_0855s

新規に作成したUSBシリアルコンバーターから、電源を取っているのだけど、
SDカードをマウントすると、USBシリアルデバイスが不安定になる現象が
起こった、これは、SDカードマウント時に大きな電流が流れ、電圧効果が大
きいのだろう、そこで、解消の為、USBシリアルモジュール側に47uFの
コンデンサを追加した、(22uFくらいで十分だと思うが、手持ちが無かっ
た)これで、安定的に動作するようになった。
念のため、RX24T側にも10uFのコンデンサを足した。

簡単なベンチマークを行った。
※サンプルのSDカードは、Transcend の8GB
※RX24Tでは、SPIの最大クロックは20MHzとなっている。

RX24T:
SD Speed test start...
SD Write test...
Write frame: 460
Write: 136770 Bytes/Sec
Write: 133 KBytes/Sec
SD Read test...
Read frame: 133
Read: 473041 Bytes/Sec
Read: 461 KBytes/Sec

RL78/G13:
SD Write test...
Write frame: 541
Write: 116293 Bytes/Sec
Write: 113 KBytes/Sec
SD Speed test start...
SD Read test...
Read frame: 180
Read: 349525 Bytes/Sec
Read: 341 KBytes/Sec

※書き込み速度は、あまり変化は無いが、読み込み速度はかなり改善している。
※RL78では、SPIのクロックは16MHzだったので、その分と、CPU
の処理能力の違いと思える。

-----

ポートを1ビット単位で定義できるようなクラスを実装した、これはRL78
でも同じようなクラスを実装したけど、より汎用的な仕様にした。

定義の仕方は、RL78とほぼ同じだが、ポートの指定は、テンプレートクラス名とした。

    typedef device::PORT<device::PORT6, device::bitpos::B5> sdc_select;    ///< カード選択信号
    typedef device::PORT<device::PORT6, device::bitpos::B4> sdc_power;    ///< カード電源制御
    typedef device::PORT<device::PORT6, device::bitpos::B3> sdc_detect;    ///< カード検出

RXマイコンでは、ポートの出力と、入力は、異なったレジスターを利用する
為、テンプレートクラスは、この対応が非常にやりやすい。
以下は、ポートクラスの一部:

struct port_t {
    static bit_rw_t<rw8_t<PORTx::base_address_ + 0x20>, bpos> PO;  // ポート出力用
    static bit_ro_t<ro8_t<PORTx::base_address_ + 0x40>, bpos> PI;  // ポート入力用

        void operator = (bool val) { PO = val; }
        bool operator () () { return PI(); }
    };
    static port_t P;

operator をオーバーロードする事で、「P」に対して、「=」で、値を設定、
「()」で読み出す事が出来る。

RX24T SD カードアクセスサンプル