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

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

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

WinAVR C++ の実力とは!?

この記事は、C++ Advent Calendar 2013 12月4日(水)の記事です。

前回は ボレロ村上 さんの記事でした。

最初に断っておきますが、C++ 関係の話題は、ほんの少しで、後は、少し毛色の違うマッタリとした話です。

WinAVR は、Atmel AVR Microcontrollers 用の gcc を使った C、C++ コンパイラーコレクションです。

今時、「gcc が使えるマイコン」なんて珍しくも無いと思うかも知れませんが、数百バイトの RAM と、数キロバイトの Flash(ROM) で構成された 8 ビットマイコンで実用に耐えるレベルで使う事が出来る C++(gcc) は、非常に珍しいと思いますし、フリーで制限無く使えます。
有志の方たちの努力で、非常に効率が良く、洗練された、品質の高いコードが出ます、又、数十種類にも及ぶ AVR ファミリーに特化した専用のヘッダーが用意されており、個々のデバイスに最適化した実装をシンプルに行う事が出来ます。

AVR マイクロコントローラーは、RAM や Flash(ROM) の容量や周辺機能の違いにより 100 円から数百円で、秋葉原などでも普通に買え、入手性も良く、又、プログラムを書き込むツールも安く売られています、必要な情報も公開されている為、自分で書き込み装置を製作する事もでき、これらのソリューションは、ホビーでハードウェアーを自作する人たちに好まれてきました。
IMG_0485s
2種類の自作 ISP (AVR にプログラムを書き込むツール)
日本でも色々な方が ISP を公開していますが、代表的なのは、「千秋ゼミ」 で、AVR への安価な書き込み機を紹介しています、このプロジェクトでは、100 円で買える最も安い AVR(ATtiny2313) を利用した ISP「HIDaspx」で、プログラミングループのマシンサイクルを厳密に調整して、USB1.1 の 1.5Mbps の接続をエミュレーションしています、そしてそれらを2キロバイトのメモリーに入れています、とてもクールなもので、素晴らしいソリューションです。
※「鶏と卵問題」がある為、HIDaspx が書き込まれた AVR が欲しい人は、連絡下さい、書き込み済みの物を送ります。(100 円+送料)

また、Arduino(アルドゥイーノ)と呼ばれる、統合開発環境があり、この環境では、C++ に似た(殆ど C++)Arduino 言語を用いて、プログラムを作成する事ができ、世界中の人が使っています、今回のシステムでは、Makefile で直接 avr-gcc を動かしますので、Arduino は使いません。

最近は、32 ビットの ARM マイコンが 110 円で入手出来る時代なので、その価値は多少薄れているようにも思いますが、電源電圧範囲が広く、低消費電力で、それなりに高速(最大 20MHz)、外部ペリフェラルも豊富で、関係資料が多く、とても使いやすいマイコンなので、ホビーで電子工作をする人のより良いアイテムとなっています。
※双璧を成す同じような構成のマイコンとして PIC がありますが、こちらは gcc は使えませんし、C++ も使えないようです、場合によっては有料の SDK を購入する必要があります。

今までは、AVR マイコンの開発では、主に C でプログラミングしてきましたが、C++ でどのくらい実用性があるのか、検証するつもりで、全て C++ による実装を行い、関連する問題を検証してみました。

最も大きな問題として AVR C++ の仕様では stdlibc++(STL が使えない) が無い点です、それでは C++ と言えないのではと言う人もいるかと思いますが、たとえば ATtiny2313 では 256 バイトの RAM と、2 キロバイトの Flash(ROM) しかありません、このようなリソースでは、STL ライブラリーを含める事は不可能です、多分、WinAVR の開発者は、リソースの制限から、STL を捨て、C++ によって得られる成果を最大限受け取れるように最適化したものと思われます。
もちろん、 boost もそのままでは使う事は出来ませんが、一部は、WinAVR 用に修正すれば、恩恵を受け取る事は可能だと思います。
良く、「車輪の再発明」と言うのがありますが、AVR に限っては、もし必要なら、小規模で独自な vector、string、map、のような何かは必要になると思います、都合が良い事に、参考に出来る資料や実装は沢山あるので、移植は難しい事では無いと思います。
ただ、メモリー消費と機能を天秤にかけた、中世期の実装、格闘となると思います。

今回 ATmega328P(RAM: 2K, ROM: 32K, Clock: 20MHz)のマイコン(250 円)を使い、16×16 のドットのマトリックス LED 表示を持った小型デバイスを作ってみました、表示だけではエンターティメント性に欠けるので、単音の矩形波で実現するパルスサウンドモジュレーター(チープですが)を組み込みました、そして、入力デバイスとして4つの押しボタンスイッチ、時計用のリアルタイムクロックも加えました。
IMG_0490s
※各モジュールを外して分解したところ
※この写真にはRTCなどが含まれていません。

ソースコード、回路図など GitHUB で公開していますので、ハンダ付けが出来るなら、回路製作をチャレンジしても良いと思います、なるべく汎用的な部品を使い低価格になるようにしています、今回 16×16 の LED モジュールは、秋葉原でたまたま見つけたジャンク LT-5013T (420 円)を使ったのですが、全体のコストは2000 円くらいでしょうか。
元々は、台所で使うキッチンタイマーをゴージャスに作るのが目的だったのですが、(ダイソーで買ったタイマーは味気がありませんし、最近誤動作するようになってきました)作ってみると、16x16 LED ドットマトリックスはチープなわりに意外と奥が深いのでミニゲームも作ってみました。

(1)ハードウェアーとソフトの分担
マイコンを使った「装置」を作る場合、ハードで分担する部分と、ソフトで分担する部分の比率や構成を考えなければなりません、ホビーで作る場合は、なるべくソフトの比重を多くして、簡単なハードで済ます方が何かと楽なものです、その中でとりあえず一番のトピックスは LED の表示方法です、この LED のマトリックスでは、16x16(256個)の LED がありますがマトリックス状に結線されている為、一度に16個を表示して、それを16回繰り返して全ての表示を行います(ダイナミックスキャンと言います)、フレームレートをゲーム機並みの 60 枚にしたかったので、LED のダイナミックスキャンは 960Hz で行っています、このくらい高速だと、人間の目にはちらつきは認識できません。
今回、LED のダイナミックスキャンでは、3 to 8 デコーダー(74HC138)を2個、8 ビットのラッチを2個、P チャネル FET 16個で行いましたが、後で気がついたのですが、 TLC5940 と言う IC があって、輝度調整も出来て、まさにこれが最適なようです。
※ダイナミックスキャンでは、LED が物理的に点灯している時間はこの場合1/16なので、目的の明るさにするには16倍の輝度(16倍の電流を流す)にする必要があります。

ゲームを作ると「音」が欲しいのですが、このマイコンには16ビットのタイマーが1チャネル内臓されており、タイマーの周期で信号をトグルさせる事で音を鳴らす事が出来ます(ビープ音と言っています)、これを利用して12平均音階率の周波数を数オクターブ出せれば、単音でも簡単な音楽を演奏する事もできます、多少誤差があるので、高音になる程オンチになります。
又、別の8ビットタイマーを使い、出力をパルス幅変調して、ローパスフィルターを通す事で、擬似的な電圧出力を出せます、これで、音の信号を変調すれば、音にエンベロープ(強弱)を追加する事が出来ます、また、12平均音階率の中心周波数に対して多少周波数を上下すれば、ビブラートのような効果を追加する事も出来ます、あまりやりすぎると、複雑になりすぎるので程ほどにしますが、チープなハードでも、ソフトを凝れば、相当色々な表現が出来る事は間違いありません、C++ でサウンドドライバー的な実装を行うと、非常に楽が出来、このような実装を書けるのはとてもありがたいです!

基本、キッチンタイマー(ゲーム)なので、入力装置も必要です、押しボタンスイッチを4個付けました、ところで、「チャタリング」と言うのは知っていますか?、物理的な構造で接点を ON/OFF して、電気信号をやりとりすると、ON した瞬間、OFF した瞬間は、数ミリ秒の期間(この時間は、スイッチの機械的な構造によって変化します)だけ、信号が暴れて ON/OFF を繰り返します、これを普通に読み出すと確率的に正しく読めないので、昔は、このノイズを取り除く方法として、フリップフロップ回路が考案され、実際に使われていました、現代では、ソフトウェアーによって、このノイズを取り除いています、実際には、画面の更新周期(フレームレート)が 60Hz なので、このタイミング(16.67ミリ秒)に合わせて、スイッチを読みにいくだけです、これで、チャタリングが取り除かれる理屈はサンプリング理論で説明できます、シンプルで賢い方法です、この方法で前提となっているのは、チャタリングが16ミリ秒より十分短いのが前提ですが、機械式接点のチャタリングは悪くても8ミリ秒程度です。

(2)C++ の準備
WinAVR の C++ では libstdc++ がありません、そこで、C++ 標準ライブラリーに含まれるいくつかのコードと、ワークアラウンドが必要です。
・お決まりの new、delete の実装

void * operator new(size_t size)
{
    return malloc(size);
}
 
void operator delete(void* ptr)
{
    free(ptr);
}

※AVR はメモリーが少ないので、もし必要なら、オブジェクトの生成や廃棄で、メモリーが断片化した場合の対策を行う必要があります。

・ガード関数などの宣言と実装

__extension__ typedef int __guard __attribute__((mode (__DI__)));
 
extern "C" int __cxa_guard_acquire(__guard *);
extern "C" void __cxa_guard_release (__guard *);
extern "C" void __cxa_guard_abort (__guard *);
 
int __cxa_guard_acquire(__guard *g) {return !*(char *)(g);};
void __cxa_guard_release (__guard *g) {*(char *)g = 1;};
void __cxa_guard_abort (__guard *) {};

・純粋仮想関数の宣言と実装

extern "C" void __cxa_pure_virtual(void);
 
void __cxa_pure_virtual(void) {};

これだけあれば、C++ として必要十分の事は出来るようになります。

(3)割り込み
組み込みで一般的なアプリケーションと違う部分は、割り込み処理でしょうか、OS を伴わないマイクロコントローラーのソフトウェアーでは、割り込みを直接扱います、また、割り込み関数と、メイン関数の共有リソース管理や同期処理などを正しく動かす為、コンパイラの最適化を制御しなければなりません。

//-----------------------------------------------------------------//
/*!
    @brief  ATMEGA168P タイマー2 割り込みタスク(タイマー0比較一致)
*/
//-----------------------------------------------------------------//
ISR(TIMER2_COMPA_vect)
{
    ledout_.reflesh();
}

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  LED 出力クラス
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
class ledout {

    static const uint16_t fb_width_  = 16;
    static const uint16_t fb_height_ = 16;

    uint8_t     fb_[fb_width_ * fb_height_ / 8];
    uint8_t     count_;
    volatile uint16_t   frame_;

......

//-----------------------------------------------------------------//
/*!
    @brief  ダイナミック・スキャンのリフレッシュ
*/
//-----------------------------------------------------------------//
void reflesh() {

.....

    ++count_;
    if(count_ >= 16) {
        count_ = 0;
        ++frame_;
    }
}

//-----------------------------------------------------------------//
/*!
    @brief  フレームの同期
*/
//-----------------------------------------------------------------//
void sync() const {
    volatile uint16_t cnt;
    cnt = frame_;
    while(frame_ == cnt) ;
}

↑の「ledout」クラスでは、frame_は、割り込み関数と、メイン関数で共有されます、sync 関数では、割り込み時に frame_ のカウントアップが行われる為、それを検出していますが、最適化を制御する為、「volatile」を使います。
※ ISR マクロは、WinAVR が定義しているデバイス毎の割り込み関数用マクロです。

(4)同期式プログラムとモーションオブジェクト
ゲームでは、ファミコン時代から、画面の更新(60Hz)に同期してプログラムを動かす方式が主流です、一般的なアプリが、メッセージを送受信して、それに応答するように設計されるのに比べて小規模なシステムでは、合理的な事が多く、細かい制御が楽な為です。
ゲームアプリケーションでは、絶対的な時間軸に沿ってプログラムを動かします、たとえば「移動」を考えた場合、停止している場合は、移動ルーチンをスキップしているのでは無く、速度を「0」にしているに過ぎません、移動ルーチンは、動いていても動かなくても常に通っています、全体的に、このような方法論により組み立てます。
しかしながら問題もあって、処理負荷が大きくなり過ぎると、画面の更新( 60Hz だと 16 ミリ秒)に間に合わなくなり、次の画面更新に持ち越してしまう為、見た目の速度が半分、又はそれ以下になってしまいます、昔のシューティングゲームなどで敵や弾が多く表示された時に遅くなる現象(ナムコでは「ぞうさん」と呼んでいましたww)です。
ゲームの開発者は、そうならないように、処理負荷を調整して、分散させるなど工夫をしていました。

ファミコンでは家庭用ゲーム機としては、多分初めてハードウェアーによる画像の管理機能が採用されました、これを一般的には「スプライト」と呼びます。
あらかじめ設定した二次元の絵をハードウェアーによる管理で自由に移動させる事が出来るものです、「モーションオブジェクト」と言うのは「アタリ社」が呼んでいたものです。
※初期のパソコンでは、グラフィックスのビットマップをソフトウェアー処理して、スプライトのような処理をしていました、その為、リアルタイムに同時に動かせるオブジェクトの数と大きさに著しい制限がありました。
※インベーダーが流行った時代、アーケードの違法コピーが沢山行われていました、これは、当時のアーケードゲームは、誰でも入手できる部品を使っていた為ですが、現在大手のメーカーもコピーを行っていたのは、痛い事です・・・
ところで、インベーダーの基板は、白黒のビットマップグラフィックスしか無く、モーションオブジェクトのハードウェアーは搭載されていませんでしたが、どこかのコピー屋が、ナムコのギャラクシアンをコピーしていました、当然、モーションオブジェクト回路は無いので、その部分はソフトウェアーエミュレーションなのですが、ギャラクシアンの編隊が出ると、「ぞうさん」状態になっていましたwww
※そんだけ、エンジニアリングがあれば、オリジナルゲームが作れると思いますが・・・

今回のハードウェアーでも、アプリケーションは同期式で制御しており、ドットマトリックスは、16×16のモノクログラフィックスとして処理を行っています、ダブルバッファによるフレームバッファ方式を採用して、スプライト的な機能をソフトウェアーで実現しています。
フレームの最初でフレームバッファをドットマトリックスのスキャンバッファにコピー後、フレームバッファを消去して、表示の再構成を毎フレーム行っています。

   while(1) {
        graphics::monograph& mng = task_.at_monograph();
        ledout_.copy(mng.fb());    ///< フレームバッファを LED 表示バッファへコピー
        mng.clear(0);              ///< フレームバッファの消去

        task_.service();           ///< 表示の再構成を行う為のタスクサービス

        uint8_t sw = sync_system_timer_();   ///< フレームと同期後、スイッチの状態をサンプリング
        task_.at_switch().set_level(sw);     ///< スイッチの状態を更新して、押した瞬間、離した瞬間を作成
    }

(5)サウンド
今回採用した方法は、単音でチープですが、基本的な構造は網羅してあります。
まず、音階ですが、一般的な音楽理論では、12平均率を使います、1オクターブを均等に12分割するので平均率と呼ばれます。
1オクターブで周波数は2倍となるので、12乗したら2になる定数 (1.059463) を求め、乗算の定数として使います、12回掛けると2倍になります。

    2 ^ (1/12) = 1.059463
    C    :  65.41 Hz
    C#/Db:  69.30 Hz
    D    :  73.42 Hz
    D#/Eb:  77.78 Hz
    E    :  82.41 Hz
    F    :  87.31 Hz
    F#/Gb:  92.50 Hz
    G    :  98.00 Hz
    G#/Ab: 103.83 Hz
    A    : 110.00 Hz
    A#/Bb: 116.54 Hz
    B    : 123.47 Hz

※ピアノの調律などでは、この周波数を微妙にずらしたりするようです、和音の響きとか、色々な流儀があるようです。
「ドレミファソラシ」は「ミ、ファ」が連なっていて、他が一つおきなのに、何だか妙な感じです・・・
オクターブと音階により、分周比を決定し、タイマーのレジスターに書く事で、希望の周波数が出力されます、出力はデジタルなので矩形波です。

これだけだと、非常に限られた表現しかできません、たとえば、ある楽譜で「ド、ド、レ」となった場合、「ド、ド」は、一つの長い「ド」として聞こえてしまいます。
そこで、強弱を加える事で、切れ目を作ります、エンベロープ波形などと呼ばれています。
しかし、AVR はデジタル出力しかありません、そこで、パルス幅変調(PWM)と言う方法を使います、PWM では、一定の周波数を短形波出力して、1と0の比率を変える事で、平均すれば、強弱を変化させている事に等しくなります、PWM の周波数は、人間の可聴範囲外にある(今回は 78KHz を設定)ので、PWM で変調する事により、全体として、音の強弱として聞こえます、最終出力には、RC フィルターを入れて、高い音の成分をなだらかにして、多少聞きやすくしています。

サウンドクラスでは、音階と音長の管理、他表現のコマンド管理などを行い、音楽を演奏する環境を整えています。
又、音楽を鳴らしながら、効果音を擬似的に鳴らせるように、音楽を演奏するトラックは2つ用意して、別々に管理して、優先順位を決めて、片方のトラックの音を鳴らしています、常時1音しか出ないので、音楽が鳴っている時に効果音が鳴ると、音楽が完全に途切れるのですが、仕方ありません・・
※あるいは、ソフトウェアーを工夫して、短い時間で時分割処理にするとかすれば、擬似的に同時二音も出来そうな気がしますが、複雑になり過ぎるので、妥協しました。

・キッチンタイマー用楽曲
   // ストラップ(doriko)、イントロ部分
    static const uint8_t bgm_01_[] PROGMEM = {
        device::psound::sound_key::TEMPO,   210,

        device::psound::sound_key::D + 12 * 5, 32,
        device::psound::sound_key::D + 12 * 5, 32,
        device::psound::sound_key::E + 12 * 5, 32,
        device::psound::sound_key::Q,          16,
        device::psound::sound_key::D + 12 * 5,  8,
        device::psound::sound_key::E + 12 * 5,  8,
        device::psound::sound_key::Fs+ 12 * 5, 16,
        device::psound::sound_key::G + 12 * 5, 16,
        device::psound::sound_key::Fs+ 12 * 5, 16,
        device::psound::sound_key::E + 12 * 5,  8,
        device::psound::sound_key::D + 12 * 5, 24,
        device::psound::sound_key::Q,          32,

        device::psound::sound_key::A + 12 * 5, 32,
        device::psound::sound_key::A + 12 * 5, 16,
        device::psound::sound_key::D + 12 * 5, 16,
        device::psound::sound_key::E + 12 * 5, 32,
        device::psound::sound_key::Q,          16,
        device::psound::sound_key::D + 12 * 5, 16,
        device::psound::sound_key::A + 12 * 4, 16,
        device::psound::sound_key::Cs+ 12 * 5, 16,
        device::psound::sound_key::D + 12 * 5,  8,
        device::psound::sound_key::E + 12 * 5, 32,
        device::psound::sound_key::Q,          32,

        device::psound::sound_key::D + 12 * 5, 32,
        device::psound::sound_key::D + 12 * 5, 32,
        device::psound::sound_key::E + 12 * 5, 32,
        device::psound::sound_key::Q,          16,
        device::psound::sound_key::D + 12 * 5,  8,
        device::psound::sound_key::E + 12 * 5,  8,
        device::psound::sound_key::Fs+ 12 * 5, 16,
        device::psound::sound_key::G + 12 * 5, 16,
        device::psound::sound_key::Fs+ 12 * 5, 16,
        device::psound::sound_key::E + 12 * 5,  8,
        device::psound::sound_key::D + 12 * 5, 24,
        device::psound::sound_key::Q,          32,

        device::psound::sound_key::D + 12 * 5, 32,
        device::psound::sound_key::D + 12 * 5, 32,
        device::psound::sound_key::E + 12 * 5, 32,
        device::psound::sound_key::Q,          16,
        device::psound::sound_key::D + 12 * 5,  8,
        device::psound::sound_key::E + 12 * 5,  8,
        device::psound::sound_key::Fs+ 12 * 5, 16,
        device::psound::sound_key::G + 12 * 5, 16,
        device::psound::sound_key::Fs+ 12 * 5, 16,
        device::psound::sound_key::E + 12 * 5,  8,
        device::psound::sound_key::D + 12 * 5, 24,
        device::psound::sound_key::Q,          32,

        device::psound::sound_key::A + 12 * 5, 32,
        device::psound::sound_key::A + 12 * 5, 16,
        device::psound::sound_key::D + 12 * 5, 16,
        device::psound::sound_key::E + 12 * 5, 32,
        device::psound::sound_key::Q,          16,
        device::psound::sound_key::D + 12 * 5, 16,
        device::psound::sound_key::Cs+ 12 * 5, 16,
        device::psound::sound_key::D + 12 * 5, 16,
        device::psound::sound_key::E + 12 * 5,  8,
        device::psound::sound_key::D + 12 * 5, 24,
        device::psound::sound_key::Q,          16,

        device::psound::sound_key::Q,          255,
        device::psound::sound_key::END
    };
・効果音
    /// 移動効果音
    static const uint8_t snd_move_[] PROGMEM = {
        device::psound::sound_key::A + 12 * 4, 1,
        device::psound::sound_key::C + 12 * 4, 1,
        device::psound::sound_key::E + 12 * 4, 1,
        device::psound::sound_key::END
    };

IMG_0514ss
スピーカー、パワーアンプ、ボリューム

(6)RTC(リアルタイムクロック)
作っているうちに欲が出てきて、RTCを載せる事にしました、時間が判ると便利なものです。
RTCは電源が切れている間も時間を刻む必要があるので、専用ICを使いました、今回は、DS1371を使います、この IC は、1秒間隔でカウントアップする、32ビットカウンターを内臓しています、電源が切れても、リチウムボタン電池によりバックアップを行っているので、時間カウントは休み無く進み続けます。
単純な秒のカウントなので、ソフトウェアーで、年月日曜日などを生成します、この部分は通常 libc の「time.h」関係に含まれるのですが、AVR では、それも無い為、独自に実装しています、この部分は、昔に作った C のソースを使っています。

コラム:「不思議な RTC の常識」
RTC は、かなり昔からある IC で、色々なメーカーが何百種類と色々な物を出しています、ただ、その構成や機能には疑問が残ります。
一般に非常に多く流通している構成は、DS1302 のようなもので、カウンターは、秒、分、時間、曜日、日、月、年のように分かれており、一見便利そうですがー、ソフトを作る立場では、大きなお世話で、余計な事をしている典型で、非常に扱いにくいものです、このような構成では、これらレジスターを集めて、一旦シリアライズして、また元に戻さないと、何もできません、まっとうな時計管理では、うるう年や、うるう年、曜日を求める事が必須なのですから。
今回使った DS1371 は扱い易くてシンプルな32ビットカウンターなのですが、購入するとなると、こちらの方が値段が高く、入手性も悪いのが現実です、今回は以前にサンプルで入手した物が手元にあったので使いました。
これは、初期の8ビットマイコン時代の悪しき慣習が見直されないまま、現在に至っている事だと思いますが、何とも、歯がゆいものです・・・
※時間を設定する時、曜日を入力させた。
※ちなみに、DS1371 は 150 円、DS1302 は 50 円です。

IMG_0513ss
DS1371

IMG_0516ss
バックアップ電池

(7)アプリケーションの実際
今回は、とりあえず、以下の機能を入れてあり、全体で19キロバイト程の容量となりました。
・キッチンタイマー
・3分、4分、5分、用タイマー(カップ麺用)
・ゲーム
・時計

(8)電源
AVR は5Vで動作させているので、リチウムポリマー電池(3.7V)から5Vを生成して、動かしています。
リチウムポリマー電池の充電はUSBから行えるようにしてあります。
※この部分は、昔にジャンクで買った、USBバッテリーをそのまま分解して使いましたwww
IMG_0512ss
※この部分は、大きさに難がありまだ載せていません・・・

(9)まとめ
今回、色々な部分をC++で実装してみて、STLが使えないながら、効率よく判りやすく実装する事が出来ました、そして、小規模環境でも、十分実用的にプログラミングが行える事が判りました、メモリーが少ない事があらかじめ判っていれば、そのような対応をすれば問題無く、少ないメモリーは工夫をする為の味付けと感じました。
ただ、以上の前提は、今まで、C++を習得してきた下地がある事で応用が利いているものと思います。
現状で、これだけ環境が整っているのに、C++で実装している AVR のホビースト(日本国内の感覚)が少ない現実を考えると、やはり、C++の習得には、一定のハードルがある物と思われますし、最低限実用になるまで習得するにはそれなりの時間と忍耐も必要なのだと実感します、自分も未だ習得は半ばですが、この楽しい言語の習得は続けていきたいと考えています。

今回の成果を github に上げてありますので、興味ある人は参照して下さい。

※ドットマトリックス用のビットマップデータ変換は、「ビットマップ変換ツール」を参照。

操作の動画

そして次回は hotwatermorning さんの記事です。

よろしくお願いします!

C 言語よりお得な C++ その5

C 言語プログラマーが、C++ に移行して、最初に味わう挫折感は、テンプレートでは無いでしょうか(継承とか、まぁ色々あると思いますが・・)?
大抵、複雑なテンプレートに出会うと、理解不能で、これがどんなふうに機能するのか、理解出来ない事が多く、それが、C++ 不審に陥るキッカケになるかもしれません。
逆説的に、プログラマーにハードルを与える機構を持った優れた言語と言う事も出来るかもしれません。

テンプレートは変態的 define とあんまし変らないと思う人もいるかもしれません、ですが、単なるマクロとは大きく違い、C++ 言語としての仕様をちゃんと網羅しており、より複雑で精妙な事を実現できますし、エラー検査が厳密に行われます。

最初は、簡単な物から、より複雑で、高機能な物へと順番に進んでいけば、良いと思えます。
※ゆっくり歩こうが速くあるこうが、諦めなければ最終目的地に到着します。

さて、テンプレートの題材(ネタ)を考えていたのですが、最近小規模な RX マイコンのプログラムを書いていて良いネタがありましたので紹介します。
※小規模な RX マイコンでは、リソースの関係で、STL がほぼ使えません。

シリアルコミュニケーションのドライバーで使う FIFO を簡単なテンプレートで改修します。
※シリアルコミュニケーションでは、FIFO を使って割り込みルーチンとメイン側でデータの受け渡しを行います。

最初は、以下のような物でした・・

#include <cstdint>
#include <cstdlib>

namespace utils {

    class fifo {

        volatile uint32_t       get_;
        volatile uint32_t       put_;

        char*       buff_;
        uint32_t    size_;

    public:
        fifo() : get_(0), put_(0), buff_(0), size_(0) { }

        ~fifo() { free(buff_); }

        void initialize(uint32_t size) {
            buff_ = static_cast<char*>(malloc(size));
            size_ = size;
            clear();
        }

        void clear() { get_ = put_ = 0; }

        void put(uint8_t v) {
            buff_[put_] = v;
            ++put_;
            if(put_ >= size_) {
                put_ = 0;
            }
        }

        uint8_t get() {
            uint8_t data = buff_[get_];
            ++get_;
            if(get_ >= size_) {
                get_ = 0;
            }
            return data;
        }

        uint32_t length() const {
            if(put_ >= get_) return (put_ - get_);
            else return (size_ + put_ - get_);
        }

        uint32_t pos_get() const { return get_; }

        uint32_t pos_put() const { return put_; }

        uint32_t size() const { return size_; }
    };
}

※記憶割り当てでは、通常 new delete を使うのですが、RX の gcc で、new、delete を呼び出す事で ROM サイズがほんのり大きくなる為、malloc、free にしてあります。

上のクラスは設計が不十分です、動的にバッファのサイズを変えようと思っても、割り当てを廃棄する関数が無い為、実際には変えられません (メモリーリークします)、それに、「initialize」を呼ばずに使うとクラッシュしてしまいます、まぁこの辺は、メンバー関数を追加するとか、ポインターのチェックを行うなどすれば回避できるのですが、だんだん複雑になっていきます。
そもそも、動的に変えられる仕様は必要でしょうか?
通常、シリアルコミュニケーションを使う前に1度確保したら、プログラムが終了するまで、サイズを変える事は稀です。
そこで、これをテンプレート化します。

#include <cstdint>

namespace utils {

    template <uint32_t size_ = 256>
    class fifo {

        volatile uint32_t       get_;
        volatile uint32_t       put_;

        char       buff_[size_];

    public:
        fifo() : get_(0), put_(0) { }

        void clear() { get_ = put_ = 0; }

        void put(uint8_t v) {
            buff_[put_] = v;
            ++put_;
            if(put_ >= size_) {
                put_ = 0;
            }
        }

        uint8_t get() {
            uint8_t data = buff_[get_];
            ++get_;
            if(get_ >= size_) {
                get_ = 0;
            }
            return data;
        }

        uint32_t length() const {
            if(put_ >= get_) return (put_ - get_);
            else return (size_ + put_ - get_);
        }

        uint32_t pos_get() const { return get_; }

        uint32_t pos_put() const { return put_; }

        uint32_t size() const { return size_; }
    };
}

どうでしょうか?、随分シンプルになりました。

インスタンスは、コンパイル時に決定する為、メモリー確保に関連するトラブルからも避けられ、サイズを与えれる(コンパイル時のインスタンス化)ので十分な実用性もあります。

何も指定しないと、256 バイトでサイズが作られますが、以下のようにすれば、サイズを指定できます。

    utils::fifo<512>    fifo_;

このテンプレートは「サイズ」をキーにしている為、サイズが異なれば、違う物とみなされる事になります。
このクラスのポインターを取得したければ、以下のようにサイズが合っていなければなりません。

    utils::fifo<512>*   fifo_ptr_;

    fifo_ptr_ = &fifo_;

LCD用ビットマップデータ変換

LCD などを使った機器では、文字や、グラフィックスなど比較的小さい物を扱う事が出来れば便利です。
AVR マイコンなどに LCD を繋いだ場合は、小さな絵をデータ化して、プログラム領域に置いておき、描画したいものです。

そんな時、手頃な変換ツールがあれば便利なので、OpenGL(GLFW3)の一環として作ってみました。
※OpenGL はプレビューの描画にしか使っていないので、通常動作では、コマンドラインで行い、GUI は簡単なプレビューを助ける程度しかありません。

また、「漢字」を表示させたい用途もあります、自分のライブラリーは、FreeType2 を持っているので、TrueType フォントの描画も出来ますが、ライセンスの問題や、LCD のような低解像度で単色では、フリーで流通している BDF 形式を扱えたら便利です、そこで、BDF フォントファイルを読み込んで、変換する機能も入れてみました。
SJIS の漢字コードをおおよそいれると、12ピクセルのフォントでも156キロバイト必要です、通常は外部にEEPROM(2メガビット必要)を接続して、そこにデータを置く必要がありますが、SD-CARD のインターフェースがあれば、そこから必要なフォントをキャッシュすれば、かなり実用的な速度で描画する事も可能です。

※ビットマップの絵や自分フォントなどをデザインする場合には、自分は「edge」と言うフリーソフトを使っています、小回りが利いて、ドット絵をデザインするには便利なソフトです。

--

この変換ツールは、画像ファイルとして以下のフォーマットをサポートしています。
bmp,png,jpeg,jpeg2000,tga
※gif はあえてサポートしていません。

ファイル出力は、バイナリーか、C ソース用のテキスト出力を選択出来ます。
他に細かいオプションがあります。

出力は、ビットストリームで、行われます、展開する場合は、単純にLSBから1ビットづつアクセスして、順番に描画すればよく、サイズと速度で合理的と思えます。
出力はバイト単位で行われる為、余ったビットは0で埋められます。
※ AVR の描画サンプルが github にあります。

ソースコード、実行ファイルをgithubで公開しています。
※DLL は player/build からコピーして下さい。

コマンドを実行すると、以下のように簡単なヘルプが表示されます。

BitMap Converter
Copyright (C) 2013, Hiramatsu Kunihito
Version 0.50
usage:
    bmc.exe [options] in-file [out-file]
    -preview,-pre     preview image (OpenGL)
    -header size      output header
    -text             text base output
    -c-style symbol   C style table output
    -offset x,y       offset location
    -clip       x,y        clipping area
    -bdf              BDF file input
    -append           append file
    -inverse          inverse mono color
    -dither           ditherring
    -verbose          verbose

※英語表記がかなりいい加減です・・・

・「-preview」は、変換後に画像をプレビューします。
・「-no-header」は、通常画像のサイズ、又は切り出した場合、そのサイズを、横、縦2バイト出力しますが、それを抑止します、サイズが同じ物を連続して出力する場合などに使います。
※サイズが256バイトを超えると問題が起こります、ソースコードもありますから必要なら機能追加して下さい。

・「-header size」は、ヘッダー情報としてサイズを出力します、「size」は、ビット幅です。
・「-text」は、ソースコードに取り込めるようにした16進形式の羅列です。
・「-c-style symbol」は、uint8_t の配列として、シンボル名を含めて出力します。
・「offset x,y」はソース画像を切り出す場合のオフセットです。
・「clip x,y」は、ソース画像を切り出すサイズを指定します。
※これら、「x,y」のパラメーターは、一般的な数値計算を受け付けます。(Ex: 16*5,24*3)
・「-bdf」は、BDF 形式のファイルを入力する場合です。
※BDF 形式でのプレビューは限定的ですが、これは仕様です。
・「-append」は、出力ファイルに追加で出力する場合に指定します。
・「-inverse」はピクセルを反転します。
・「-dither」はディザリング処理を行います。
・「-verbose」は、内部情報を出力します。

※PNGファイルの変換とプレビュー

bmc -pre images/matrix_font.png out

bmc00

※BDFフォント(warabi12 フォント)の変換とプレビュー

/bmc -pre -bdf bdf/warabi12-0.19a/warabi12-1.bdf kfont12.bin

bmc_02

BDF の漢字ビットマップの出力では、SJIS並びとなっています、合理的に並べられ、SJISコードから漢字のビットマップをアドレスするのが容易な為ですが、文字コードはUTF8 を使う必要もあり、結局相互に変換を行う必要性は免れません・・・

また、SJIS をリニアアドレスに変換する場合は、以下のコードを参考にして下さい。

    // sjis コードをリニア表に変換するサンプル。
    // 上位バイト: 0x81 to 0x9f, 0xe0 to 0xef
    // 下位バイト: 0x40 to 0x7e, 0x80 to 0xfc
    static uint16_t sjis_to_liner_(uint16_t sjis)
    {
        uint16_t code;
        uint8_t up = sjis >> 8;
        uint8_t lo = sjis & 0xff;
        if(0x81 <= up && up <= 0x9f) {
            code = up - 0x81;
        } else if(0xe0 <= up && up <= 0xef) {
            code = (0x9f + 1 - 0x81) + up - 0xe0;
        } else {
            return 0xffff;
        }
        int loa = (0x7e + 1 - 0x40) + (0xfc + 1 - 0x80);
        if(0x40 <= lo && lo <= 0x7e) {
            code *= loa;
            code += lo - 0x40;
        } else if(0x80 <= lo && lo <= 0xfc) {
            code *= loa;
            code += 0x7e + 1 - 0x40;
            code += lo - 0x80;
        } else {
            return 0xffff;
        }
        return code;
    }

※ディザリング処理の場合(2013年11月21日機能追加)
DitherTest

※BDF フォントの読み込み時、プレビューを修正(2013年11月24日)
bmc_03

C 言語よりお得な C++ その4

(8)文字列の扱い(コンテナによるオブジェクトの受け渡し)
AVR の C++ には STL が無いので、std::string を使う事はできませんが、文字列を確保する簡単なコンテナを実装して、それを使う事は出来ると思います、またネットを探せば、std::string に似せた実装のいくつかを見つけられると思います。
※動的に確保が必要な文字列が必要無いのであれば、以下の項目はスルーして下さい、しかしながら、常に固定化された文字列だけ扱えば良い場合と言うのも稀と思います。
※std::string が使える環境で、あえて、同じような文字列のコンテナを使う意味は全くありません(ゲームの開発者などに多いようですが、std::string より優秀なクラスを設計して実装し、動作確認をするには、極めて莫大な時間と労力を消費すると思います)、std::string は極めて正しく実装されており、std::string より優れた実装を行う事は殆ど不可能に近いと思います、これは、STL を理解していない「一知半解」と言うべき愚かな行為です。
※メモリーの断片化を避けて、独自の記憶割り当てを行いたい為に、独自の string クラスを作る人がいますが、そんな事をしなくても、アロケーターを実装して、それを渡せば良いのです、std::string が仕様的に不適格で、別の実装を考えなければならない場合は通常殆どありません。
C 言語から C++ を始めて間もない頃は、文字列をやりとりする場合などに、std::string と char* をチャンポンで使った実装をする事が多いと思います、ですがー、コンテナを使った方法論に移行すべきタイミングです。
コンテナを使って返す事で、余分にコピーが発生するので、速度が落ちると考えるかもしれませんが、最適化以前に、より良い設計を心がけるべきで、最適化はその後です。
※通常、コンテナの受け渡しは参照によって行われるので、コピーが発生するのは、最小限となります。
※ AVR の gcc では std::string が使えないので、勉強と、STL 理解の目的で、string クラスを実装してみるのは有益だと思います、仕様は、std::string を元にすれば良いし、テンプレートの作り方などを習得できます、同じ物を作るのはハードルが高いので、自分に必要な機能だけ実装それば良いと思います。
実際には、AVR では、メモリー領域が物理的に分かれている為、ROM 上(コード領域)の場合と、RAM 上の場合で、別々の処理を行う必要があるので、簡単では無いのですが・・

class aaa {
  // 内部で扱うコンテナや変数は「private」にし、外部に公開する場合は、必ずアクセサーを使ってアクセスするように設計します。
  std::string  text_;
public:

  // const 参照で受けて・・
  void put(const std::string& text) {
    text_ = text;
  }

  // const 参照を返す・・
  const std::string& get() const { return text_; }

  // ポインターを返す仕様なら、条件が「偽」なら、0(NULL ポインター)を返せば、シンプルと思うかもしれませんが、ソースがコンテナであるのに、そのポインターを返すのでは二度手間になる場合があります、やはり、統一的にコンテナとして扱えた方が利便性が高いので、「偽」の場合に、空のコンテナを返すようにすれば、コンテナとして統一的に扱えます。
  const std::string& test(char ch) const {
    if(!text_.empty() && text_[0] == ch) {
      return text_;
    } else {
      static std::string empty;
      return empty;
    }
  }

  // 固定の文字列を返すのなら「const char*」で返すのは問題無いでしょう。
  const char* name() const { return "aaa"; }
};


int main() {
  aaa a;

  a.put("abcdefg");  ///< std::string は、「=」オペレーターで「char*」型も受け取れるように実装されている。

  std::string b("qwert");
  a.put(b);          ///< もちろん、std::string を受け取る事も出来る。

  {
    const std::string& t = a.get();
    if(!t.empty()) {
    
    }
  }

  {
    const std::string& t = a.test('a');
    if(t.empty()) {

    } else {

    }
  }
}

 
 
(9)avr-g++ の制限と回避
avr-g++ は、stdc++ ライブラリーが無い為、通常標準で備わっている事が出来ませんので、それら使う場合は個別に実装する必要があるようです。
・new、delete

void * operator new(size_t size)
{
    return malloc(size);
}

void operator delete(void * ptr)
{
    free(ptr);
}

 
・また場合によっては、スレッドセーフの機構を呼び出すコードが追加されますので、以下のコードも追加します。

__extension__ typedef int __guard __attribute__((mode (__DI__)));

extern "C" int __cxa_guard_acquire(__guard *);
extern "C" void __cxa_guard_release (__guard *);
extern "C" void __cxa_guard_abort (__guard *);

int __cxa_guard_acquire(__guard *g) {return !*(char *)(g);};
void __cxa_guard_release (__guard *g) {*(char *)g = 1;};
void __cxa_guard_abort (__guard *) {};

 
・最後に、仮想関数用のコードを追加します。

extern "C" void __cxa_pure_virtual(void);

void __cxa_pure_virtual(void) {};

 
これで、ほぼ遜色無く、C++ のコードをコンパイル出来るハズです。

C 言語よりお得な C++ その3

(5)define
C では、例外無く、普通に define を使ってきました、しかしながら、多くのプログラミングガイドなどで、害悪が指摘されるように、C++ では define を使わなくても良い方法が提供されています。
人によっては、少しだけ注意すれば便利なので、それ程とやかく言わなくても的な事を言う人もいますが、define より安全で、優れた機能が提供されているのに、何故、危険で制限のある古い方法を使うのか理解に苦しみます。
※厳密には define を使わないと、どうしても解決出来ない事が全く無い訳では無いのですが、それは、「稀」な事と思います、普通は、使わなくても何とかなる事の方が多いハズです。
※「郷に入れば郷に従え」

C では、define をアセンブラのマクロ命令のように、人間による最適化を施した拡張命令のように捉えられていると思われますが、「最適化」はいくつかの例外を除いて、人間がやるよりコンパイラに任せた方が安全で確実であると思います。
※精妙な最適化は、それが必要になったら行うべき事項であり、開発途中の中途半端な段階で行うのは問題が多く実りが少ないと言えます。

C++ では、最大の最適化でも、「関数の呼び出し」を尊重してコンパイルします、その関数が少ないステップで構成されている場合でも、指示の無い事は行いません。
もし、設計者が、ステップ数や、実行時間の比率などを考えて、関数を展開した方が有益と判断されるなら、「inline」を宣言する事で、その関数は展開され、呼び出しのコストが取り除かれます、ただ、注意しなければならない事があります、どんな場合でも「展開」する事が有益だとは限らない事です、たとえばキャッシュが小さいマイコンの場合は、展開する事で、キャッシュのヒット率が悪くなり、逆に速度が落ちるかもしれません、結局、計測してみないと本当の事は判らないと言う事です。
※もちろん、キャッシュが無いような小規模なマイコンでは、当てはまりません。
※「計測」は非常にスキルの必要なエンジニアリングです、浅はかな計測では大抵真実は明らかになりません。

組み込みで、良く使われる define の利用法として、ハードウェアーの制御や定数の定義などがあります。

たとえば、ボーレートの初期値として・・・

#define BAUD_RATE 9600

これは、単純に

static const int BAUD_RATE = 9600;
又は、
enum rate {
  BAUD = 9600,
};

のように、名前空間などを利用した構造的な定義が出来ます。
最適化されれば、余分なメモリーを消費する事も無く、参照されずに直接アセンブラ命令に埋め込まれます。
※この場合の定数は、「int」型となりますので、int 型が都合悪ければキャストする必要があります。

良くありがちな I/O デバイスの操作で・・

void write_data(u8 data) {
  ACTIVE_PORT;    // ポートを有効
  OUT_DATA(data); // データ出力
  WRITE;          // ライト
  CS_LOW;         // CS 有効
  SETUP_DELAY;    // データのセットアップタイム
  CS_HIGH;        // CS 無効
  INACTIVE_PORT;  // ポートを無効
}

↑のように、あるデバイスにデータを出力する手続きを実装したものです。
※本来、大文字で書かれた命令は、普通に関数(inline 関数など)を定義しても良いのですが、内部で行っている事が、少なく、関数を定義するのが「冗長」又は、マクロ展開で処理コストを節約とかの判断なのでしょう、典型的な C のプログラマーは、これを define で定義する事が多いように思います。
※また、define では、パラメーターを埋め込んで、適当に整形して展開出来る為、かなり複雑な事も可能ですが、C++ では殆どの場合、テンプレート関数でそれを置き換える事が出来ると思います。

#define ACTIVE_PORT { ... }
これは、単純に・・
inline void ACTIVE_PORT() { ... }

#define OUT_DATA(d) { ... }
引数がある場合は、その引数の「型」を定義できるので、正確で安全です。
inline void OUT_DATA(uint8_t d) { ... } 

 
次の例では、一次元配列に対して、二次元配列的にアクセスするマクロです、型に依存しない様にテンプレートで表現しています、define を使わなくても可能な例です。
※配列サイズを超えたら、例外を投げるとか、色々拡張する事もできるでしょう。
※参照を使っているので、関数に直接値を代入するような書き方が可能です。

/// 読み出し専用
template <typename T>
const T& get_dim_(const T* p, uint32_t row, uint32_t col) {
    return p[(col << 2) + row];
}

/// 書き込み専用
template <typename T>
T& put_dim_(T* p, uint32_t row, uint32_t col) {
    return p[(col << 2) + row];
}
-----
    float mat[16];
    
    put_dim_(mat, 1, 3) = 10.0f;

    float a = get_dim_(mat, 1, 3);

 
 
(6)キャスト
C では、「キャスト」について、アセンブラ的に、単純に警告を取り除く為の手段として利用しているのが殆どのように思います。
C のキャストはたとえば、こんな感じの物です。

  char ch;
  ...
  unsigned char data = (unsigned char)ch;

C++ では、いくつかのキャストが用意されており、場合によって使い分けます。
  unsigned char data = static_cast<unsigned char>(ch);

良く、C++ のプログラムで、C のキャストを使う人がいますが、C のキャストは、変換が可能か不可能かに関係なくエラー検査無しに変換します。
※驚く事に、「C++ のキャストは冗長だから、C のキャストを使う」と言っている人がいましたが、反面教師にすべきです。
C++ では、static_cast を良く使いますが、もし変換が出来ない場合はエラーとなります。
C++ のプログラムでは、C のキャストを使わないようにして下さい。
また、const を取り除くようなキャストも行ってはなりません、そのような操作は、基本的に間違っています、通常、設計を正しくする事で避ける事が出来ます。
※ C++ の他のキャストについては、リファレンスを参照して下さい。
 
 
(7)警告
コンパイラが出力するレポートは非常に重要です、エラー検査は最大レベル(厳しいエラー検査)を設定し、一つでも警告が出たら、実行する前に、警告を取り除くようにソースコード修正する「クセ」をつける必要があると思います。
良くありがちな事として、「警告は最後にまとめて取り除く」という方針を実践している人がいますが、間違いです、「警告」が出るのには理由があり、コンパイラがソースコードの構造的欠陥を指摘しているのですから、警告が出ないような、抜本的な改修や、綺麗な設計が必要です、これらの優先順位は最後に回すべきものではなく、「今」行うべき事項であると認識して下さい。
※とりあえず「警告」を無視する事の無いように・・・
※「警告」が沢山出るプログラムは、そもそも設計が良くない場合も考えられます。

C 言語よりお得な C++ その2

(4)クラス
「クラス」は、C++では、大きなトピックです、ここでは、クラスに関連するいくつかの事を紹介します。

・初期化リスト
「クラス」では、「コンストラクター」と呼ばれる特別のメソッドがあります。

class bitmap
{
public:
// コンストラクター
 bitmap() { }
};

これは、ご承知の通りです。
普通、コンストラクター内では、変数の初期化を行います。

class bitmap
{
  int counter_;
public:
// コンストラクター
 bitmap() { counter_ = 0; }
};

「= 0」と値を代入しています。
これは、間違いでは無いのですが、「=」(イコール)で代入するのでは無く、コンストラクターでは、「初期化リスト」を使います。
違いは、初期化リストでは、各オブジェクトのコンストラクターを呼んでいるのに対して、代入では、=オペレーターを呼んでいる事になります、最適化された場合は、殆ど同じになりますが、コンストラクター内では、初期化リストで初期化するようにして下さい。
※詳細な理由については、記しませんので、ご自分で調べて下さい。

class bitmap
{
  int counter_;
public:
  bitmap() : counter_(0) { }
}

・メンバー変数に「_」アンダースコアーを付ける
クラス内のメンバー変数は、引数の変数名などと被らないようにします。
典型的には、「m_counter」などとする事もありますが、これは、ハンガリアンスタイルと言えます、なので、シンプルに後ろに付けるのが好ましいと思えます。
※高橋晶さんから指摘してもらいましたので修正します。
先頭アンダースコアの次に大文字が来る場合は規約違反となります。

※インクルードガードにアンダースコアー
多くの人(C のプログラマーに多い)が、インクルードガードで使うキーワードに、未だにアンダースコアーを使っている人がいます。

func.h の場合
#ifndef __FUNC_H__
#define __FUNC_H__

...

#endif

しかしこれは、規約違反である事を念のため確認しておきます。
※私は、「#pragma once」をお勧めしますが・・

func.h の場合
#ifndef FUNC_H
#define FUNC_H

...

#endif

・引数の void
受け取るパラメーターが無い場合、C では void を使いました。

void init(void)
{
}

C++ では、何も書く必要は無くなりましたので、引数が無ければ何も書きません。

void init()
{
}

※しかし、書いてもエラーにはなりません、問題なのは、書く必要が無いのにあえて書く人と、その心理でしょうか・・・

・引数に標準的な値を代入できる
受け取るパラメーターがあったとして、標準的な値を代入しておく事が出来ます。

void set(int value = 1);

...

  set();     //「1」が引数として使われる。
  set(100);  //「100」が引数として使われる。

これらを利用して、色々と便利な事が行えます、応用してみて下さい。
私がお勧めしたい応用として、ブーリアンを使った、フラグの設定を紹介します。
よく、状態として、「許可」と「不許可」を設定したい場合があります。
そんな時・・・

void enable();
void disable();


のようにしますか?
ですが、これだと、何かの状態を評価してから、状態を設定する場合、関数を呼び分けなければなりません。

if(flag) enable();
else disable();

そこで・・

void enable(bool f = true)
{
}

とすればー

  enable();  // 許可したい場合

...

  enable(false);  // 不許可したい場合

...

  enable(flag);  // flag が「true」か「false」で、「許可」、「不許可」を設定できる。

※よく、二つの状態を受け渡しするのに、「int」とかを使う人がいますが、それは間違いです「bool」を使って下さい。
※又、3つなら「int」が便利(1, 0, -1)と言う人がいますが、それも間違いで、3つの状態があるなら、enum などで、3つの状態を定義して、それを使います。

・enum の便利な使い方

C++ では、define を使わなくなりますし、あえて使う理由もありません、そこで定数を定義するのに便利な enum を C++ で便利に使う為の方法を紹介します。

enum は意味のある値を定義する上で便利な機能ですが、不都合な事が起こります。

たとえば、以下のような、enum の定義では、enum 内に同じ名前のキーワードを定義できません。

enum holizontal {
  LEFT,
  H_CENTER,   // これは少し冗長
  RIGHT
};

enum vertical {
  TOP,
  V_CENTER,   // これは少し冗長
  BOTTOM
};

しかし、C++では、こう書けば・・

struct holizontal {
  enum type {
    LEFT,
    CENTER,
    RIGHT
  };
};

struct vertical {
  enum type {
    TOP,
    CENTER,
    BOTTOM
  };
};

型名をクラス名にして、その中で enum を定義する事で、別々に定義出来ます。
※名前空間で分離する事も出来ますが、私は、クラスで括る方が好みです。
※私は、このような場合に enum の型として type と言うキーワードを使うのが好みです。

int main()
{
  holizontal::type h = holizontal::CENTER;
  vertical::type v = vertical::CENTER;

...

}

※structとclassの違いについて
C++ では、struct と class の違いは、殆どありません、private か、public の違いくらいです。
※ main 関数の戻り値
↑のサンプルでは、main 関数の戻り値(return 0;)が記述されていません、C++ では、main 関数の戻り値が無い場合、0が戻る事が保障されています、これは言語規約に定められています、言いたいのは、C++ では、C 以上に言語規約を良く理解して正確に従う必要がある点です。

・new、delete をなるべく使わない
クラスを定義して、それを使う場合、以前に良く見たサンプルは、以下のような物です。

  func* f = new func;

  f->xxx();

  delete f;

しかし、このように書けば、new、delete を省略出来ます。

  {
    func f;

    f.xxx();

  }

↑のように書けば、delete を忘れて、メモリーリークする事を防げますし、func クラスが生成されるタイミングもスコープで制御できます。
雑多な事はコンパイラに任せ、コンパイラに出来ない事に集中します、最適化にも貢献出来ます。

C 言語よりお得な C++ その1

C++を常用的に使うようになってから随分時間もたち、C++も少しだけ上達してきました。
最近では殆どのプログラムをC++で行うようになり、組み込みのような小規模なシステムでも、開発環境が提供される限りC++を使っています。

話は変わって、AVRマイコンの開発環境で「WinAVR」と言うのがあります、gcc が使えるフリーのツールキットなのですが、8ビットマイコンであるにも関わらず、C、C++でプログラミングできるフリーの開発ツールです、但し、C++のプログラミングでは、STLは使えないのですが、まぁ、数百バイトのRAMや、数キロバイトのROMでは、リソースの関係で困難と思えます、まして、データ領域とプログラム領域が分離しているアーキテクチャーでは、物理的に同じような実装をする事は難しいのかもしれません。
ただ、string、vector、map のようなコンテナは仕様に制限を設定すれば、実装する事は可能でしょう。

AVRで使える g++ は非常に良く出来ていて、最近では、AVRのプログラミングでもC++でプログラムするようになりました、何か特別な理由が無い限り、Cでプログラムを書く理由は無いと思えます。

しかしながら、典型的なCのプログラマーは、多くの勘違いをしている事が多いと思います、これはC++を本格的に学ぶ前の自分もそうでした。

(1)C++はリソースを多く消費し、プログラムサイズが大きくなる。
(2)C++は余分な処理が多く、余分なマシンサイクルを消費するので、遅い。
(3)Cのプログラミングスキルは、C++にそのまま生かせる。

まず(1)ですが、幾つかのプログラムをつくり、最適化されたアセンブラコードを観てみましたが、適正に書かれたC++コードは、Cのコードと遜色は無く、余分な命令は殆ど追加されていませんでした。
※これは処理系によっては、違う結果となる場合もありますが、WinAVR g++ ではそんな事は無く、洗練されたアセンブリコードが出るようです。

次に(2)ですが、(1)で示したように、余分な命令は殆ど無いので、余分なマシンサイクルも消費しません、場合によっては、より最適化されたコードが出る可能性も含まれている為、C言語より高速なコードが出る可能性もあります。
但し、「適正に書かれた」と言う前提が付きます、適正に書くには「学ぶ」必要がある為、C++に不慣れなプログラマーが、少しのC++のスキルを使って検証したら、別の結論に行き着く可能性があります。

そして(3)です、確かに、何かの処理をどのように細分化して、実際に動くコードを作成する能力(基本的なプログラミングのスキル)は、生かされるのですが、C++には、Cに無い様々な用法があります、それを知らないと、適切なコーディングは出来ないと思うのです、しかしながら典型的なCのプログラマーは、C++をある程度理解しているし、実際に動くコードを実装出来るので、使うつもりなら、いつでもC++でプログラミング出来る(C++は大体理解している)と思っています、しかし、C++はCに似ていますが、全く違う言語である事を認識すべきでは無いでしょうか、C++で適正なプログラミングをする為には、多くの時間を使って学ぶ必要があると思います、もしC++を理解していれば、Cより便利で安全なC++が使える環境でC++でプログラミングしない理由は無いハズなのです、C++を使わないのはそれ相応の理由が存在するのでしょう。
※幾つかの場面で、C++でプログラムしない理由は存在しますが、本当にそうなのかは検証しなければ判らないし、ケースバイケースです、Cを選択するのが最適な場合はあるででしょうが・・

これから、不定期に何回かに分けて、C++でプログラムするのに便利なテクニックや豆知識を紹介していこうと思います。
主に、昔に感じた事や重要と思われるトピックを中心に書いていこうと思います。
この文書は、正確でなかったり、実際と違う場合などがあると思います、気が付いたり指摘されれば修正していこうと思います。

良く、初心者が読むのに適したC++の参考書は?と聞かれますので、とりあえず、この本をあげておきます。
C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス

・名前空間

Cには無い便利な機能として「名前空間」があります、名前空間を活用する事で、プログラムを判りやすく、構造的にする事が出来ます。
※悪名高い Embedded C++ には名前空間がありませんが、C++を理解出来なかった人たち(日本人です)によって策定された仕様です、恥ずかしい事です。

・参照

「参照」は、C++でも最も利益のある機能の一つだと考えます、参照はポインターに似ている為、Cのプログラマーは軽視しがちですが、コンパイラーにとっては、最適化を進める上で、非常に強力な武器です、関数に渡すのがポインターでは無く、参照であれば、より進んだ最適化を行う可能性が生まれます。
また、参照では、ポインターのような、NULLチェックを行う必要は無く、構造的に参照が適用出来ない場合は、コンパイラが教えてくれます。
ポインターより少しだけ制限のある参照は、より洗練された構造をプログラムに提供し、それと同時に安全性も提供します。
参照では、const をより明確に使え、明確な意図をもって伝播させる事が出来ます、これを最初は「ウザイ」と思う人もいますが、そうでは無い事は直に理解出来ると思います。
一つの典型的な方法論として、まず参照で解決出来るか考えて、なるべく参照を使うように全体を設計し、どうしても参照に出来ない場合だけ、ポインターを使うようにします。

ポイント:
NULL について:
「NULL」はC言語のマクロであり、C++でも使えますが使うべきでは無いと考えていますし、使う理由もありません。
C++では「0」を使えば良いのです、NULLを使う理由として、数値に代入する0と、ポインターに代入する0を明確に分けたいとの理由を挙げる人もいますが、それが、わざわざ、C言語のマクロを使う理由としてメリットがあるとは考えられません、また、NULLマクロを使うには stdlib.h(cstdlib)をインクルードする必要があります。

・基本的な事

(1)標準ライブラリーのインクルード
C言語のヘッダーをインクルードする際に
C++では、C言語で使える関数も当然使えます、その際ヘッダーをインクルードしますが、C++用に専用ヘッダーが用意されています。

たとえば、「stdio.h」なら「cstdio」、「stdlib.h」なら「cstdlib」、「string.h」なら「cstring」です。
※規則は察しがつくと思います。
C++の標準的ヘッダーは、「.h」などの拡張子が無いので、それに習っているのと、C++から使う際の「おまじない」がしてあります。
※AVR の g++ では、C++ 専用のヘッダーが用意されていない為、普通のCヘッダーをインクルードします。

(2)型について
C++では、「型」を厳密に評価します。

Cの場合、たとえばポインターは典型的に以下のように書きます。

void func(char *ptr)
{
  char *tmp = NULL;

...


}

しかしC++では・・

void func(char* ptr)
{
  char* tmp = 0;

...


}

ポインターを示す「*」が、変数名に付いていたのが、型に付くようになっています。
Cでは、「ptr」の「ポインター」、「tmp」の「ポインター」だったのが、
C++では、「ptr」や「tmp」は「char」の「ポインター型」と言う考えによるものです。
しかし、多くの人が、自分流の定型記述セオリーを持っており、少しでも異なると、「気持ち悪い」と感じる為、それだけでも、テンションが下がる要因になる場合も少なくありません。
これは、慣れの問題で、もちろんコンパイラーは、「char *ptr」でも「char* ptr」でもエラー無くコンパイル出来ますが、しばらくは、自己流の狭い考えを捨てて、流れに身を任す事が寛容と考えます。

ただ、ここで問題が起こります。

  char* tmp, ptr;

このように書くと、「tmp」は「ポインター型」ですが、「ptr」は「char型」です、これは、C言語との互換を考慮して、このような不都合な事が起こります。
なので、一つの方法として、コンマで区切って、複数の変数を宣言しない事で避ける事ができます。

(3)スコープを利用した宣言

以前、Cの典型的関数では、関数内で使う変数を、頭の方で、集中的に宣言していました。

void func(void)
{
  int i, j, k;
  char c;

...


}

しかし、C++では、変数を使いたい時に、初めて変数を宣言できます。

void func()
{
  int i;
  int j;

...

  char c;
  int k;

...


}

また、スコープを使って、分離する事で、同じ変数名を何度でも宣言できます。

void func()
{
  int j;
  {
    int i;

...

  }

  {
    int i;
    int j;

...

  }
}

これは、コードがより観やすくなるだけでは無く、関数内であってもモジュール化でき、最適化に貢献できます。
ただ、↑の例で、スコープで囲まれた変数「j」を、大域の「j」と混同してしまう場合があり、注意する必要があります。※警告により回避出来ます
その都度宣言する事で、不必要なコードが生成されると思っている人がいますが、最適化されたコードは、そのような事はありません。(コンパイラーの常識、プログラマーの非常識)

OpenGL(with GLFW3)オーディオプレイヤー(ベータ)

OpenGL GLFW3 を使ったオーディオプレイヤーを作ってみました。

まだ、最低限の機能しかありません。

これは、OpenGL で GUI のフレームワークを実現する為のテスト的アプリケーションです。

GUI のフレームワークを作るにしても、何か、アプリケーションを作ってみない事には、必要な要件や仕様などが判らない為です。
GLFW3 を使っているので、Linux や、OS-X でも動作可能と思いますが、現状では Windows 依存のコードが含まれている為、コンパイル出来ません・・

player

・mp3, wav 形式のファイルを再生するアプリケーションです。
・mp3 タグ情報の表示などを行います。
・描画は OpenGL で行っています。
・フォントの描画では、FreeType2 を使っています。
・cygwin の i686-w64-mingw32 クロスコンパイラを使っています。
・左下隅のボタンを押すと、ファイル選択ダイアログが開きます、音楽ファイルを選択して下さい。
・まだベータ版で予期しない動作で落ちる場合もあります(表面的なテストしかされていません)。
・ソースコードは、少し整理してから公開する予定ですが、「今欲しい」方はリクエストを」下さい、方法を考えます。

オーディオプレイヤー

※9月8日15時23分
・大きなメモリーリークを発見したので修正、アーカイブのリンクを修正

※9月9日22時47分
・aac (mp4a) のデコードを追加、タグ情報の表示
・FAAD2 ライブラリーの libmp4ff には、カバー情報(アルバムのアートワーク)を正しく扱えないバグがあり、修正しました。
・その他、微妙に修正

※9月10日22時
GitHub にソースコード一式を公開しました。

AKI-RX62で「C++」を使わない理由が無い!

RXマイコン用、C++デバイス制御クラスを実装していて、色々と少しづつアップデートしている。

今日の標語:

  「C++」を使わない理由が無い!

RX621に内臓されているハードウェアーリソースは豊富なので、まだ、全ては実装出来ていないけど、とりあえず、必要そうな定義は実装してみた。
※十分なテストとかしていないので、バグがあるかもしれないけど・・・
※一番ありがちなのは、アドレス定義ミス。

各ソースコードと機能の対応:
※ルネサスの「RX62Nグループ、RX621グループユーザーズマニュアル ハードウェア編」を元にしている。

rx62x_system.hpp    システム制御関係の定義(リセット、電圧検出回路、クロック発生、消費電力削減)

rx62x_icu.hpp       ICU(割り込みコントローラー)の定義

rx62x_port.hpp      I/Oポートの定義

rx62x_dmaca.hpp     DMACA(DMAコントローラー)の定義
rx62x_exdmac.hpp    EXDMAC(EXDMAコントローラー)の定義
rx62x_dtc.hpp       DTC(データトランスファーコントローラー)の定義
rx62x_crc.hpp       CRC の定義

rx62x_mtu.hpp       マルチファンクションタイマユニットの定義

rx62x_i2c.hpp       I2C(RIIC) バスインターフェースの定義
rx62x_i2c_io.hpp    I2C の制御
rx62x_i2c_io.cpp

rx62x_rspi.hpp      RSPI の定義
rx62x_rspi_io.hpp   RSPI の制御
rx62x_rspi_io.cpp

rx62x_cmt.hpp       CMT(コンペアマッチタイマー)の定義
rx62x_cmt_io.hpp    CMT の制御
rx62x_cmt_io.cpp

rx62x_sci.hpp       SCI(シリアルインターフェース)の定義
rx62x_sci_io.hpp    SCI の制御
rx62x_sci_io.cpp

rx62x_rtc.hpp       RTC の定義
rx62x_rtc_io.hpp    RTC の制御

rx62x_s12ad.hpp     S12AD(12ビットA/Dコンバーター)の定義
rx62x_ad.hpp        AD(10ビットA/Dコンバーター)の定義
rx62x_da.hpp        DA(10ビットD/Aコンバーター)の定義

全ソースコード

☆テンプレート化してあるので、複数チャネルがあるデバイスは全て同じように扱える。
☆デバイスのテンプレートは、多少工夫してあるので、判りやすく、間違えば大抵エラーとなる。

DMACA、4チャネル
EXDMACA、2チャンネル
I2C、2チャンネル
RSPI、2チャンネル
CMT、4チャネル
SCI、6チャネル、※何故か4チャンネルは無く(0、1、2、3、5、6)
※SCIは、シリアル入力(RxD)に対応するポートを入力に指定する必要がある。

ルネサスがサンプルなどで提供しているデバイスの定義ファイルを捨てて、とりあえず、現状、定義してあるデバイスヘッダーでコンパイル出来るように変更した。
この修正で、必要な部分は、全て C++ で実装されているので、それを使う事が出来る。

fatfs は、RXマイコン依存の部分を新しいデバイステンプレートを使って、C++でコンパイル出来るように修正した。
※基本的に、えるむさんのコードはそのままになっている。
※サンプルにあったRXマイコン用のコードは、C++デバイス定義用「mmc_rspi.hpp、mmc_rspi.cpp」に修正されている。

プログラムの動作について:
・RxD0、TxD0 にターミナルを接続すると、簡単なシェルが起動する。(115200、8ビット、1ストップビット)
・RTC は外部の I2C に DS1371 を接続する。(ds1371_io.cpp でどのポートを使っているか判る)
※RX621 内臓の RTC は、バッテリーバックアップ出来ないので仕方なく接続・・・
※RX621 内臓の RTC を使う事も出来る、コードは一応用意した。(rx62x_rtc_io.hpp)
※「sd_monitor.cpp」で、どちらを使うか選択出来る。
・VS1063a の接続する場合、ソースコードを確認の事。
・「syscalls.c」で、POSIX のファイル操作(SDメモリーに対して行う)を実装してあり、fopen 系、printf など普通に使う事が出来る。
・「init.c」で静的に宣言しているクラスなどのコンストラクターが呼ばれる。
・「stdc++」ライブラリーをリンクしているので、STL も使える。
・コマンドは、以下

% ls         SD カードのディレクトリーを表示
% cd xxx     カレントディレクトリーを移動
% date       日付、時間を表示、設定も可能
% play xxx   オーディオファイルを再生(現在はポーリングとなっている)
% volume     ボリュームの呼び出しと設定

このフレームワーク?では、C++ で普通にプログラム可能なのだが、iostream は使わない事、メモリを非常に食うので、フラッシュに入らないと思う。
※ C++ だけど、とりあえず、printf を使って欲しい。
※当然ながら、iostream と関連性が強く、インクルードしてあるソースも避ける事。
STL は普通に使えるし、boost も全てでは無いけど使える~(iostream に関連する制限がある点に注意)

リンクに、変な警告が出ているけど、とりあえず無視するしかないが、問題は無さそう~
※このエラーが何故出るのか不明・・・、出ないようにする方法が不明なので、そのままになってる。

------
I2C や RSPI のデータ転送を DMA ベースにしたいとか、色々やる事があるけど、その前にお約束の LCD を繋ぎたい~

※バグを発見したり、質問があれば書きこんで~

C++ でI/Oデバイスの操作を考える

組み込みでもC++と言う事で、最近では、RXマイコンでC++0Xを使ってソフト開発をしていますが・・

ルネサスなどのサンプルでは、I/Oデバイスの操作は、C言語で使えるビットフィールドを多用しています。
サンプルに付属のハードウェアーデバイスを定義してあるヘッダー「iodefine_renesas.h」がその典型例です、しかしながら、規約では、16ビットや32ビットの定義は処理系依存であったと思います。
又、エンディアンが変わった場合も少なくと gcc では問題あります。
それなのに、このやり方が使われているのは大きな問題だと感じています。

ルネサスが試用版としてダウンロード出来るコンパイラでは問題無いようですが、gcc では問題となります。
※やった事は無いのですが、ルネサスのCコンパイラで boost が正しくコンパイルできるか不明ですし、C++11を使いたいし、IDEは嫌いだしで、積極的に使いたいとは思えません。
※時間が出来たら、RX用のLLVMをポートしたいです。
特に gcc では、最適化が施された場合に、32ビットでしかアクセス出来ないI/O空間に、バイトでアクセスするようなコードが出てくる場合もあります。
※これはRX用 gcc の問題なのかもしれません。

又、C++の強みを生かしたコーディングをしたいのもあります、今回RXマイコン用のコードを作る過程で、C++でI/Oデバイスを操作するライブラリーを実験、考えてみました。
自分のC++スキル以内の事しか出来ませんが、とりあえず、我慢できる程度の物が出来たので紹介します。

まず、どんな感じで書きたいか考えます。
RXマイコンに備わっているI/Oポートを例に考えてみます。

    device::PORT2::DDR.B3 = 1; // PORT23 output (/xCS)
    device::PORT2::DDR.B2 = 1; // PORT22 output (/xDCS/BSYNC)
    device::PORT4::DDR.B7 = 0; // PORT47 input (DREQ)
    device::PORT4::ICR.B7 = 1;
    device::PORT2::DR.B3 = 1; // xCS=H
    device::PORT2::DR.B2 = 1; // xDCS=H

とりあえず、こんな感じでしょうか?
※名前空間は「device」としています。

template <uint32_t base>
struct portx_t {
    typedef io8<base + 0x00> ddr_io;
    struct ddr_t : public ddr_io {
        using ddr_io::operator =;
        using ddr_io::operator ();
        using ddr_io::operator |=;
        using ddr_io::operator &=;

        bits_t<ddr_io, 0, 1>  B0;
        bits_t<ddr_io, 1, 1>  B1;
        bits_t<ddr_io, 2, 1>  B2;
        bits_t<ddr_io, 3, 1>  B3;
        bits_t<ddr_io, 4, 1>  B4;
        bits_t<ddr_io, 5, 1>  B5;
        bits_t<ddr_io, 6, 1>  B6;
        bits_t<ddr_io, 7, 1>  B7;
    };
    static ddr_t DDR;
};
typedef portx_t<0x0008c000> PORT0;
typedef portx_t<0x0008c001> PORT1;

オペレーターの定義として、「=」、「()」、「&=」、「|=」を定義してあります。

「=」オペレーターの戻り値をvoidとして値を返さないようにしてあります。
PORT0::DDR = 0xf0;
と代入は出来ますが・・・
uint8_t data = PORT0::DDR;
とは出来ません、代わりに、
uint8_t data = PORT0::DDR();
とする事で値を取得できます。
これには、幾つかの側面があって、I/Oに対する「読み出し」と「書き込み」は同じアドレスであっても全く別の操作だからです。
又、最適化によって起こる問題を回避できると考えています。
※又、「=」オペレーターを無効にする事により、リードオンリーのデバイスを扱えます。(書き込もうとするとコンパイルエラーになります)

さて、バイト操作が出来たので、ビット操作を考えてみます。
※ bits_t の定義がそれに辺り、アクセス開始ビットと、アクセスするビット幅を定義してあります。

template <class T, uint8_t pos, uint8_t len>
struct bits_t {
    static typename T::value_type get() {
        return (T::read() >> pos) & ((1 << len) - 1);
    }
    static void set(typename T::value_type v) {
        typename T::value_type m = ((1 << static_cast(len)) - 1) << pos;
        T::write((T::read() & ~m) | (v << pos));
    }

    void operator = (typename T::value_type v) { set(v); }
    typename T::value_type operator () () { return get(); }
};

テンプレートに渡すT型のクラスは、8ビット、16ビット、32ビットのアクセス幅により決定します。

    typedef io8<base + 0x00> ddr_io;
    bits_t<ddr_io, 0, 1> B0;

※上の例では、io8 クラスを使っています。

io8 はこんな感じです。

template <uint32_t adr>
struct io8 {
    typedef uint8_t value_type;
    static void write(uint8_t data) { wr8_(adr, data); }
    static uint8_t read() { return rd8_(adr); }void operator = (value_type data) const { write(data); }

    value_type operator () () const { return read(); }
    void operator |= (value_type data) const { write(read() | data); }
    void operator &= (value_type data) const { write(read() & data); }
};

実際にハードウェアー上のアドレスにアクセスするのは、以下です。

static inline void wr8_(uint32_t adr, uint8_t data) {
    *reinterpret_cast<volatile uint8_t*>(adr) = data;
}
static inline uint8_t rd8_(uint32_t adr) {
    return *reinterpret_cast<volatile uint8_t*>(adr);
}

まだ冗長な部分がありますが、とりあえずやりたい事は出来ています。

※完全なソースコードは、AKI-RX62 でMP3再生(VS1063a)を参照して下さい。

※参考文献:
C++テンプレートテクニック

追記、修正: 2013,7,21
operator は継承出来ないので、冗長となっていた部分、using 文で、シンプルに書ける事が判った為修正。
※using ってこんな感じで使えるのか・・
※RX のソースアーカイブは、別の作業(RSPIの割り込み化)をしているので、それが終わってから更新します。

追記、修正: 2013,7,25
コンパイルした場合にどのようなアセンブリコードが出てくるか検証しました。

int main(int argc, char** argv)
{
    // ICLK=96MHz, BCLK=48MHz, PCLK=48MHz SDCLK出力,BCLK出力
    device::SYSTEM::SCKCR = 0x00010100;
    device::SYSTEM::MSTPCRA.MSTPA15 = 0;  // B15 (CMT)のストップ状態解除
    device::SYSTEM::MSTPCRB.MSTPB31 = 0;  // B31 (SCI0)のストップ状態解除
    device::PORT3::DDR.B0 = 1;            // PORT3:B0 output
    device::PORT2::ICR.B1 = 1;            // PORT2:B1 input (RXD0)
}

-O2 で最適化した場合のアセンブリコードです。

fff80a64 <_main>:
fff80a64: fb ee 20 00 08         mov.l    #0x80020, r14
fff80a69: f8 ee 00 01 01         mov.l    #0x10100, [r14]
fff80a6e: fb 4e 10 00 08         mov.l    #0x80010, r4
fff80a73: ec 4e                  mov.l    [r4], r14
fff80a75: fb 3e 14 00 08         mov.l    #0x80014, r3
fff80a7a: 77 2e ff 7f ff         and      #0xffff7fff, r14
fff80a7f: e3 4e                  mov.l    r14, [r4]
fff80a81: ec 3e                  mov.l    [r3], r14
fff80a83: fb 4e 03 c0 08         mov.l    #0x8c003, r4
fff80a88: 74 2e ff ff ff 7f      and      #0x7fffffff, r14
fff80a8e: e3 3e                  mov.l    r14, [r3]
fff80a90: cc 43                  mov.b    [r4], r3
fff80a92: fb ee 62 c0 08         mov.l    #0x8c062, r14
fff80a97: 65 13                  or       #1, r3
fff80a99: c3 43                  mov.b    r3, [r4]
fff80a9b: cc e4                  mov.b    [r14], r4
fff80a9d: 66 01                  mov.l    #0, r1
fff80a9f: 65 24                  or       #2, r4
fff80aa1: c3 e4                  mov.b    r4, [r14]
fff80aa3: 02                     rts

及第点でしょうか・・