最近、仕事が忙しく、更新が無かった・・・
ＲＸマイコンでタイマー割り込みに使うのに適したペリフェラルはＣＭＴだろ
う、単機能、シンプルで扱いやすく、理解しやすい。
しかし、ＣＭＴのカウンターは１６ビットだが、プリスケーラーの仕様により
最大で、ＰＣＬＫＢの１／８の周期になってしまう為、間隔の短いタイマー割
り込みを組みたい場合に、誤差が大きくなる場合がある。
※メインクロックとの相性もあるが・・
そこで、他の選択肢としてＴＰＵを使ったタイマーを実装する事にした。
※ＴＰＵは、ＰＣＬＫＢの１／１を選択可能なので、より正確なタイミングを
生成でき、ポートの出力も制御できる。
ＴＰＵユニットは、ＲＸ２４Ｔには無いが、ＲＸ６４Ｍには、１ユニット、６
チャネルある。
※ＲＸ６３１、ＲＸ６３Ｎなどにもあるようだ。
ただ、面倒なのが、割り込み設定で、ＲＸ６４Ｍではモジュールが大量に増え
た為、ＴＰＵの割り込みは固定ベクターではなく、選択的なベクターになって
いる。
ＴＰＵの操作をテンプレートで実装する場合に、割り込みベクターの管理を自
動で行いたいので、工夫してみた。
※ＲＸ６３１のＴＰＵは、固定ベクターなので、その辺りも上手く吸収できる
ようにしなければならない。
また、ＴＰＵの機能は、タイマー割り込みの他、色々な機能があるので、それ
も簡単に扱えるような工夫が必要となるが、全ての機能を盛り込むと、設定が
複雑になるので、ある程度は妥協も必要で、その辺りのバランスが難しい。
※現在は、拡張中・・
ＴＰＵを考える前に、省電力機能の管理を少し拡張した。
「省電力機能」は、内部ペリフェラルの電源を「On/Off」して、使わない電力
を削減できるもので、起動時、最低限必要なものしか有効になっていない。
※ドライバー実装時、この省電力を「無効」にするのを忘れて、ペリフェラル
が動作せずに、時間を浪費した事があるのでは無いだろうか？
※注意事項には書いてあるのと、「お約束」ではあるのだが・・
ペリフェラルのテンプレートでは、個別ＩＤを設定しておいて、それを定義に
忍ばせておく事で、他の連携クラスが、固有の動作を切り替えて実現でき、ま
た、連携クラスの実装分担を、ペリフェラルの定義から分離できる。
この簡単な仕組みにより、ペリフェラルの実装時、ペリフェラルやチャネルに
より異なる実装を隠蔽できる。
自分は、「手」を動かす事が好きなので、あーでもない、こーでもないを繰り
返して今の実装になっている。
ペリフェラルの定義：
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
@brief ペリフェラル種別
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
enum class peripheral : uint16_t {
TPU0, ///< 16 ビットタイマパルスユニット０
TPU1, ///< 16 ビットタイマパルスユニット１
TPU2, ///< 16 ビットタイマパルスユニット２
TPU3, ///< 16 ビットタイマパルスユニット３
TPU4, ///< 16 ビットタイマパルスユニット４
TPU5, ///< 16 ビットタイマパルスユニット５
...
};
ＴＰＵの定義：
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
@brief 16 ビットタイマパルスユニット（TPUa）
@param[in] base ベースアドレス
@param[in] per ペリフェラル型
@param[in] intra 割り込み要因Ａ
@param[in] intrb 割り込み要因Ｂ
@param[in] intrc 割り込み要因Ｃ
@param[in] intrd 割り込み要因Ｄ
@param[in] intru 割り込み要因Ｕ
@param[in] intrv 割り込み要因Ｖ
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t base, peripheral per,
uint8_t intra, uint8_t intrb, uint8_t intrc, uint8_t intrd, uint8_t intru, uint8_t intrv>
struct tpux_t {
...
//-----------------------------------------------------------------//
/*!
@brief ペリフェラル型を返す
@return ペリフェラル型
*/
//-----------------------------------------------------------------//
static peripheral get_peripheral() { return per; }
};
ＴＰＵチャンネル毎の定義：
typedef tpux_t<0x00088110, peripheral::TPU0, 15, 16, 17, 18, 0, 19> TPU0; typedef tpux_t<0x00088120, peripheral::TPU1, 20, 21, 0, 0, 22, 23> TPU1; typedef tpux_t<0x00088130, peripheral::TPU2, 24, 25, 0, 0, 26, 27> TPU2; typedef tpux_t<0x00088140, peripheral::TPU3, 28, 29, 30, 31, 0, 32> TPU3; typedef tpux_t<0x00088150, peripheral::TPU4, 33, 34, 0, 0, 35, 36> TPU4; typedef tpux_t<0x00088160, peripheral::TPU5, 37, 38, 0, 0, 39, 40> TPU5;
※「割り込み要因」は、選択型割り込みを設定する際に必要なＩＤで、チャネル
毎に機能が微妙に異なるが、シンプルな定義になっている。（０は、割り込み要
因が存在しない場合）
省電力管理で、必要な要素として、チャンネルの起動と廃棄時、まだ、使ってい
るチャネルがある場合に、省電力機能を無効にしないようにする事で、リファレ
ンスカウンタのような仕組みが必要な点だ。
実装は、簡単なのだが、スタティック変数の定義問題がある。
現在、ほぼ全ての実装は、ヘッダーのみで行っているので、それを壊したくは無
いが、単純にスタティック変数を記述すると、その実態として、ソースコードに
も書く必要があり、そうすると、そのソースコードのオブジェクトをリンクしな
ければならなくなる。
そこで、簡単なテンプレート関数を書いて、その中で定義できるようにした。
テンプレートにすると、「実態」をヘッダーに書けるので、ソースとヘッダーに
分ける必要が無くなる。
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
@brief スタティック・ホルダー・テンプレート・クラス
@param[in] ST 構造体
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <class ST>
class static_holder {
public:
static ST st;
};
template <class ST> ST static_holder<ST>::st;
実際の定義では以下のようになっている。
struct pad_t {
uint8_t tpu_;
pad_t() : tpu_(0) { }
};
typedef utils::static_holder<pad_t> STH;
この構造体の具体的な操作は、「RX64M/power_cfg.hpp」で行っている。
これら関連したコードはGitHubにプッシュ済み。
今回はここまで。