ソフトウェアー関係の話題など・・
以前にＡＴＭｅｇａを使ってデータロガーを作成したが、需要が無かったのと、
大きくて、使いかってが悪いなどで使わなくなっていた。
最近、需要が、少しではあるがありそうなので、最新のＲＸ２４Ｔで作り直す
事にした。
ソースは、ＡＴＭｅｇａの物をなるべく利用するが、元はＣで書かれているの
と、ＡＶＲ用に特化している部分もあるので、Ｃ＋＋で作り直す。
今度は利便性を第一に考えて、小型に作る。
とりあえず、タカチのケース（ＣＳ１１５Ｎ）に入るようにして、基板を起こす
予定でいる。
※最近は、基板を小ロット作成するのにかかるコストは凄く少なくなっている。
スペックや仕様は以下の通り：
・１００Ｈｚサンプリング
・ラップタイム入力
・Ｇ．Ｐ．Ｓ．入力
・加速度、ジャイロセンサー（ＭＰＵ６０５０）
・速度（パルス）入力、２チャンネル
・回転（パルス）入力、１チャネル（エンジン回転用）
・アナログ４チャンネル
・ＳＤカード対応
・１２８×６４、液晶表示
・７２０ｍＡリチウムポリマー電池と充電、３．３ＶＤＣ／ＤＣ
・ＵＳＢ充電
ＲＸ２４Ｔの内臓データフラッシュの読み書きが出来たので、関係クラスと
サンプルを追加した。
ＲＸ２４Ｔでは、内臓データフラッシュは８Ｋバイトあり、１Ｋバイト毎の
ブロックに分かれている。
※消去は、１Ｋバイト単位で行う。
以前、ＲＬ７８では、内臓データフラッシュへのアクセスは、情報が公開さ
れておらず、使う事が出来なかった。
※操作ラブラリーだけが公開されており（gcc 版は無い）ソースコードや、
関係レジスターの説明等は未公開となっている為、実装をあきらめた。
※「公開できない」理由について、色々考えたりもしたが、それが、トリガー
となって、ＲＬ７８からは疎遠になってしまった。
ＲＸマイコンでは、アクセスが多少面倒ではあるものの、内蔵データフラッ
シュを使う事が出来る。（常識でもある）
また、ＲＯＭフラッシュ領域も、書き込みなどが行えるものの、操作が面倒
なのと、当面必要では無いので、実装していない。
データフラッシュは、消去が１バイト単位で出来ない（１Ｋバイト毎）ので、
汎用的なメモリーとして扱うようにするには、巧妙なマネージメントを必要
とする、これは、フラッシュの書き換え可能回数制限や、ブロック・イレー
スに、時間が多少必要など、フラッシュメモリーの特性が起因している。
データフラッシュの扱いは、ＲＸマイコンで共通なら、問題は無いが、デバ
イスによって異なるようだ・・
今回、ＲＸ２４Ｔ専用となったので、
RX24T/flash.hpp RX24T/flash_io.hpp
専用のクラスを用意した。
ただ、データフラッシュに対する操作は同じ仕様とする。
//-----------------------------------------------------------------//
/*!
@brief 開始
*/
//-----------------------------------------------------------------//
void start() const;
//-----------------------------------------------------------------//
/*!
@brief 読み出し
@param[in] org 開始アドレス
@return データ
*/
//-----------------------------------------------------------------//
uint8_t read(uint16_t org) const;
//-----------------------------------------------------------------//
/*!
@brief 読み出し
@param[in] org 開始アドレス
@param[in] len バイト数
@param[out] dst 先
*/
//-----------------------------------------------------------------//
void read(uint16_t org, uint16_t len, void* dst) const;
//-----------------------------------------------------------------//
/*!
@brief 消去チェック
@param[in] bank バンク
@return エラーがあれば「false」
*/
//-----------------------------------------------------------------//
bool erase_check(data_area bank) const;
//-----------------------------------------------------------------//
/*!
@brief 消去
@param[in] bank バンク
@return エラーがあれば「false」
*/
//-----------------------------------------------------------------//
bool erase(data_area bank) const;
//-----------------------------------------------------------------//
/*!
@brief 書き込み
@param[in] src ソース
@param[in] org 開始オフセット
@param[in] len バイト数
@return エラーがあれば「false」
*/
//-----------------------------------------------------------------//
bool write(const void* src, uint16_t org, uint16_t len) const;
//-----------------------------------------------------------------//
/*!
@brief 書き込み
@param[in] org 開始オフセット
@param[in] data 書き込みデータ
@return エラーがあれば「false」
*/
//-----------------------------------------------------------------//
bool write(uint16_t org, uint8_t data) const;
正月休みは風邪引いて本物の寝正月で、趣味の工作など、全く出来なかった。
去年の１１月終わりに請けた仕事も、ようやく何とかなりそうで、やっとＲＸマイコン
を再開した。
ＲＸ６４Ｍ、１７６ピンは、内臓ＲＴＣを持っており、バックアップ用別電源端子が用
意されている。
※ VBATT（15）
※バッテリーバックアップできないようなＲＴＣは、ほとんど利用価値が無い為、外部
にさらにＲＴＣを繋ぐ必要がある。
ＲＸ６４Ｍ、ＲＴＣのもう一つのメリットは、バイナリーカウンターモードがある点で、
これは、やっとまともな仕様になったとも言える。
時間管理を普通にやる場合、シリアライズがどうしても必要だが、一般的なＲＴＣのレ
ジスター構成は、二度手間になるだけで何のメリットも無いものになっている。
※レジスターは、秒、時間、日、月、年、曜日などに分かれており、扱いが容易では無
い、これは、３０年前以前の処理能力が無かった時代の腐った仕様が現役になっている。
時間の設定や、時間管理を考えた場合、「うるう年」や「曜日」の管理を行うのが普通
なので、基点からの経過時間（秒）で管理するのが確実だ、従って、ＲＴＣは、単純な
秒単位のカウンターが一番適している。
ハードウェアーデバイスに着目すると、単なるバイナリーカウンターのＲＴＣも流通し
てはいるが、腐った仕様のＲＴＣよりコストが高い事に驚く。
※ＤＳ１３７１などがバイナリー仕様のＲＴＣ
バイナリーカウンタＲＴＣ：
DS1371（単価３４１円）
年、月、日、時間ＲＴＣ：
MCP79410（単価１２２円）
DS3231モジュール（単価１１０円）
※何でこんな値段でやれるのか、不思議でならない・・・
リチウムイオン電池には直列に逆流防止ダイオードを入れる。
ただ注意しなければならないのは、順方向電圧降下が少ないタイプ（ショットキー）は
逆方向電流が多い物が多い、今回は、ＲＢ７５１Ｓ－４０を使った。
ＲＸ６４Ｍ内臓のＲＴＣは、バイナリーカウンターなので、非常に簡単に実装する事が
できた。
ＲＴＣの読み出しでは、注意する必要がある。
複数の非同期カウンターをどのように読むべきか？
何も考えずに読み出すと、カウントアップ時の非同期性の為、間違った値を読んでしま
う事がある。
全てのカウンターレジスター更新には、多少の時間的ズレがある為、確率的に全てのカ
ウント更新が終了していない中途半端な状態を読み出してしまう為で、以前に観た実装
では、ＲＴＣから１Ｈｚ出力を出して、それを割り込みを使って、そのタイミングで読
み出すとかしていた、しかもこの方法でも、正しい値を読み出せる保障は無く、多分、
「たまたま」うまく読み出せているだけで、ＲＴＣが違う場合には、うまくいかない場
合もあるかもしれない。
非同期で動作する複数のカウンターがある場合、以下のように、二度読み出して、両方
同じなら、「値を信用」し、違えば、二度同じ値になるように読み出すループを作れば
良い。
腐った仕様のＲＴＣでは、利用するレジスター全てを比較する。
bool get_time(time_t& tp) const {
auto a = get_();
for(int i = 0; i < 5; ++i) {
auto b = get_();
if(a == b) {
tp = static_cast(a);
return true;
}
a = b;
}
return false;
}
そして、
以前に、Ｒ８Ｃ、ＲＬ７８のＲＴＣ用に実装した、マネージメントを組み込んだ。
時間関数は、libc に含まれているが、巨大なので、必要最低限の実装を行った独自の
「common/time.ｃ」を使っている。
※「うるう秒」の補正は行っていない。
# RX64M RTC sample # help date date yyyy/mm/dd hh:mm[:ss] # date Sat Jan 14 23:13:56 2017
コマンドラインから、時間設定と、表示を行う事ができる。
時間管理は、「time_t」（基点からの経過秒数）で行っており、内部はグリニッジ標準
時間を使い、タイムゾーン（東京＋９時間）はハードコートしてある。
ＲＸ６４Ｍのバックアップ機能も問題無く動作しているようだ～
これは、アセンブラ時代に、サインテーブルを生成する方法を色々試して、ある程度
成果のあった方法です。
※浮動小数点の 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
テーブル生成に使っていますが、連続性がある場合は、リアルタイムに計算する事も
できます。（こちらの方が応用性があります）
非常に古いですが、１９７９年に発売された、ナムコのギャラクシアンで、編隊が、
実機の手前で、回転したり、サインカーブ的な軌跡で攻撃してくる場面がありますが、
この原理が使われていました。
※この当時、安易にテーブルにする人が多い中で、真のエンジニアでした。
また、単振動を使って、サインテーブルを計算する方法もあるかと思いますが、周期
を決定する定数を求めるのは、整数計算だけでは、簡単では無いと思えます。
テーブル生成では、テーブルのサイズは、２のＮ乗の方が、扱いやすいので、ｓの定
数を求める場合は、全円周（２・π）を、テーブル長で割る必要があります。
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_ のビット位置補正
// 全周は、２・πなので＋１
x -= (static_cast(pai_) * y) >> (pai_shift_ + shi + 1);
y += (static_cast(pai_) * x) >> (pai_shift_ + shi + 1);
}
}
public:
sin_cos() { build_(); }
};
最近、整数演算だけで色々する話があったので、過去に作成したものを見直してみた。
・平方根
これは、ファミコン時代から使っていた方法をＣ＋＋（Ｃ）で表現したもので。
※アルゴリズムは、コンピューターが出現する以前から知られていた数学的手法を元に
しているようで、初期のデジタルコンピューターが出現する、数十年前に既に知られて
いた方法のようである。
過去には、色々なマイコン用（６５０２、６８０９、６８０００、Ｚ８０）アセンブラ
で書いた記憶がある。
Ｃなどの高級言語では、キャーリーの扱いが無い為、シフトや、ビット操作を行う場合
無駄が多い。
アセンブラで書けば、より一層の高速化ができるけど、互換性を考えて、Ｃで実装して
ある。
ハードウェアーにも実装しやすく、割り算よりリソースを使わないと思われる。
※整数計算なので、「余り」がある。
ゲームにおいて平方根は、必ず必要な「道具」で、シューティングゲームの誘導ミサイ
ル、正規化、ほぼありとあらゆる場面で使うと思われる。
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;
}
・３２ビット版
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;
}
マイクロチップ用のソースを修正する作業が生じた為、Windows で、環境構築をしてみた。
遠い昔に、マイクロチップが出始めた時に、自分でアセンブラを実装して開発した覚えが
あるが、最近は、ＡＶＲやルネサスがメインとなり、使わなくなった。
開発環境が有料な事や、プログラマーが高いのも敬遠する理由ではある。
・プログラマーを自分で作る事もできそうだが、種類が多いので大変そうだ・・・
・６０日を過ぎると、無料版は、最適化が「-O1」のみとなる。
※一応ソースコードが入手できるので、パッチを当てて、制限を回避する事も出来るよう
だが・・・
・現状で、C++14 のコードをコンパイル出来ないのは、まともなコンパイラとは思えない。
PICの良い面は、デバイスの入手性、バリエーションの多さ、「コスパ」なのだと思うが
自分はメリットを感じない。
今回使うチップは、「PIC24EP256GU810」で、「MPLAB C30」をインストールした。
※コンパイラは魔改造された gcc のようだ。
例によって、ＩＤＥを使わず、コマンドラインで開発したいので、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」を買う（５７００円）事にする。（自分のお金じゃ無いけど・・）
※自分は、デバッグ機能（トレース、実行など）が必要になった事が少ないので、
フラッシュ書き込みさえ出来れば、満足なのだけど・・・
やはり、コンパイラが有償（無償版は６０日過ぎると、最適化できなくなる）なのは、最
悪だと思う、自分的には、仕事以外では絶対に使わないデバイスだと思う。
追記：
Windows10 のノートにもＰＩＣの開発環境をインストールしたが、コンパイラを走らせる
と「ライセンスがどうの」と言ってきてエラーになる・・・
調べると、「mplabc30-v3_31-windows-installer.exe」のバージョンに起因する、
license-lm 関係のバグのようだ、そこで、「v3_30」を取ってきてインストールした。
-----
やっぱり、ルネサス系、Ｒ８Ｃ、ＲＬ７８、ＲＸマイコンが最高だと、再認識する。
※コストでは、ＰＩＣに武がある事は認めるのだけど・・・
今まで、ＲＸマイコンで、挙動が怪しい事があって、その原因が判らなかったが、
やっと判明した・・・
症状としては、
・スタックに配置した変数が書き換わる場合
・割り込みが多重に起動するような場合に多く発生
・多重じゃなくても割り込み関連が絡む場合など
どうもスタックが壊れている感じではあるけど、プログラムを追っても、問題無
さそう・・・
ＲＸマイコンでは、スタックは、割り込み用スタック（ＩＳＰ）と、ユーザース
タック（ＵＳＰ）に分かれていて、起動時、「start.s」のアセンブラプログラム
で設定されている。
ＩＳＰをメモリーの後半に置き、その手前にＵＳＰを設定している。
当初、ＩＳＰの容量は３２バイトくらいしか無かったので、２５６バイトにした
が、症状に変化は無い・・・
.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）としての機能が割り当てられています。
あ！、「Ｒ０」は使ったら駄目なんだ・・・・・・・・・
そこで、単純に、レジスタ名を変更
.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
この修正後、今までのおかしな挙動が直った。
今まで、結構大きなプログラムを動かしていたけど、よく動いてたなぁ・・・
経験的に、レジスターセットの後ろ（Ｒ１５とか）にＳＰを置いてあるのが普通と
思っていたから、何も考えずに、Ｒ０を使ったのが間違いだった・・・
※ソフトウェアーマニュアルを良く読まなかったのが悪いのだけど・・・
-----
ＲＸマイコンでは、スーパーバイザーモードとユーザーモードのＲＵＮレベルがあり、
通常はユーザーモードで動作させる。
ユーザーモードで特権命令を実行すると、「特権違反例外」が発生する。
ユーザーモードに移行するには、「rte」命令などを実行した場合に、退避してあった
ステータスレジスターを復帰するが、その際、ユーザーモードフラグが有効になって
いれば、ユーザーモードに移行する為、以下のような、少しキワドイプログラムで移
行する。
# PMレジスタを設定し、ユーザモードに移行する、ユーザースタックに切り替わる
mvfc psw,r1
or #0x00100000, r1
push.l r1
# UレジスタをセットするためにRTE命令を実行する
mvfc pc,r1
add #10,r1
push.l r1
rte
nop
※ＰＣにオフセットを加える事で、ＲＴＥ命令の下に復帰する。
ようやく、ＳＤＲＡＭのテストを開始、結線は多いが、高速な大容量外部
メモリを得られる。
デバイスだけでも５１２Ｋバイトのメモリーを持っているので、通常は十
分ではあるけど、このようなデバイスじゃないと、ＳＤＲＡＭを制御する
為のハードウェアーを内臓していない、又、１６９ピンのデバイスじゃな
いと、３２ビットの外部バスをサポートしていない。
※最大のパフォーマンスを得たいので３２ビットバスで動かしてみたい。
普通は、基板を起こすべきなのだろうけど、実験ではそうもいかない。
と、言っても最近では、海外のメーカーに発注すれば、基板を新規に作成
するコストは尋常じゃ無く安いので、いきなり基板を起こしてみるのも悪
くないかもしれない。
クロックが高いので、手配線では動作が難しいかもしれないが、バスに接
続するＳＤＲＡＭは、ＣＰＵの動作速度の半分でしかないので、（およそ
６０ＭＨｚ）このくらいなら、手配線でも何とか動作すると思う。
「反射」が起こって動作が不安定になった場合は、ダンピング抵抗を調整
してインピーダンスの整合を行えば、何とかなるのでは無いかと考えてい
る。
※変換基板では、電源ラインが相対的に弱くなるのが多少気になる。
デバイスは３００円（１２８メガビット）なのに、変換基板（Aitendo 産）
が２５０円するけど、他に、収まりが良く、スペースが少ない変換基板が
無かった。
※基板を起こす時には２５６メガビット品を使うと思うが、組み込み用途
のＳＤＲＡＭを単体で入手（秋葉原などで）できるのは限られている。
最近は、０．５ｍｍピッチのハンダ付けが多かったので、０．８ｍｍピッ
チは、凄く楽だったーー
変換基板には、何故か余分な部分があるので、カットして、裏面にある謎
の端子パッドも、いつものようにポリイミドテープで絶縁、ベース基板と
直接コンタクトさせる。
※ピン番号のシルクが一部間違っている・・（２８、２９ではなく、２７、
２８ね・・）
※ポリイミドテープの存在を知らない時は、「紙」を貼っていた。ｗｗｗ
まず、電源ラインを配線してから、十分なパスコンを接続、それから配線
を行った、データバスは、液晶を接続するのにも使うので、別途、コネク
ターに出す。
・電源の配線
参考回路（ルネサスのＲＸ６４Ｍボードの例）
厄介なのは、ＳＤＲＡＭの場合、初期化処理を行わないと、使う事ができな
い点で、それなりのパラメーターがある、とりあえず、ベストな設定より、
必ず動作しそうな無難な設定を考えてみた。
後は、ＳＤＲＡＭのマニュアルと、ＲＸ６４Ｍのマニュアルを見ながら、行
い、とりあえず、書いたデータを読み出せた～
※もっと苦労すると思っていたので、意外な感じはあるが、メモリー空間は
３２メガバイトもあるので、詳細なテストを行わないと、分からない。
バス・インターフェースの初期化
// 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");
// 動作許可、３２ビットアクセス
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 カラム９ビット、ロウ１２ビット
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;
部品の整理をしていたところ、色々なＬＣＤが出てきた。
※安売りでバーゲンしてる時に買ったもの。
ＲＸ２４Ｔには、まだ液晶を接続していなかったので、ＲＸ２４Ｔで実験してみた。
赤い基板と横長の基板は、ＳＴ７５６５で、小さいのは、ＵＣ１７０１、白い枠は、
カラーＴＦＴ液晶。
横長は、モノ１２８×３２、他はモノ１２８×６４、カラーは１２８×１６０となって
いる。
どのＬＣＤも、ＳＰＩで通信するものだけど、ピンアサインが、どれも微妙に異な
る・・・
また、基本的には、電源は３．３Ｖだけど、バックライト用電源が異なるモジュー
ルがある。（Aitendo さん何で同じにしないかなぁ・・・）
以前に買ったＬＣＤで、ＬＣＤの不良（仕様違い）で、使わなくなっていたやつを
交換してきた、メールで問い合わせたら、返金すると言っていたが、同等品があった
ので、交換にした。
このＬＣＤは大型でバックライトもあり、なかなか良い。
同じコントローラーでもＬＣＤによりコントラストの設定が異なるのが、多少厄介。
※周囲が暗いけど、小さめの赤い基板のＬＣＤ、液晶の応答速度が若干速い気がする。
※さらに小型のＬＣＤ（バックライト付）で、コントローラーがＵＣ１７０１
他にもあるが、どれも表示は問題無くできる。
// 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_A0」は、ＬＣＤの制御レジスター切り替え
ＬＣＤの切り替えは、インスタンスを代える事で行う。
「spi_」は、ＳＰＩを制御するクラスで、コンストラクター時、参照で受け取るよう
にしてある為、SPI の制御をシェア可能になっている。
ＬＣＤのコントラストは、ＬＣＤのスタート時に（初期化）設定する。
lcd_.start(0x00);
※大きいタイプは０ｘ１０程度、他は、０ｘ００くらいだった。（ＬＣＤにより調整
が必要なようだ）
Ｒ８Ｃ、ＲＬ７８、ＲＸマイコンと、実装を重ねた結果、色々と新しい試み（
判りやすさ、正確性、共有性、性能）が導入されて、昔に実装した、Ｒ８Ｃ関
係のテンプレートライブラリの完成度が相対的に低下している状況となってい
る。
ここらで、最新の実装方法を、Ｒ８Ｃにも反映するべく、アップデートを大々
的に行った。
この改修は、Ｉ２Ｃや、ＳＰＩデバイスの制御クラスを全てのプラットホーム
で共有する為の準備でもある。
また、デバイスのフラッシュ書き込み関係プログラムも改修を行った。
Ｉ２Ｃ、ＳＰＩインターフェースの完成度が低いので、その辺りも、ＲＬ７８
やＲＸと同等な実装に切り替えた。
かなり大掛かりな手術となったが、一応完成した、これで、各プラットホーム
で、外部デバイスを共有する事が出来ると思う。
-----
以前にアマゾンで、ＬＥＤドライバー、マキシム社のＭＡＸ７２１９を買った。
ＭＡＸ７２１９ ７セグＬＥＤ×８
部品単体で買っても１０００円する（これは、高すぎるが・・）ので、とても
ＣＰが高い。
一般的に、多数のＬＥＤを接続するには、ポートや、電流容量の問題で、ドラ
イバーを入れなくてはならないので、それが簡単に接続できる。
ただし、電源は５Ｖなので、３．３Ｖのデバイスに接続するには、別途電源が
必要と思う。
そこで、電源電圧が自由に選べるＲ８Ｃ／Ｍ１２０ＡＮで、５Ｖで駆動により、
接続実験を行った。
輝度をプログラム出来るとか、電流制限抵抗が少ない、デージーチェインできる
、ダイナミックスキャンが行われているなど、かなりユニークなデバイスで、取
り扱いが簡潔で良い。（少量でも安ければ良いのだけど・・・）