4 | 12月 | 2013 | RVF/RC45 blog

この記事は、C++ Advent Calendar 2013 １２月４日（水）の記事です。

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

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

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

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

AVR マイクロコントローラーは、RAM や Flash(ROM) の容量や周辺機能の違いにより 100 円から数百円で、秋葉原などでも普通に買え、入手性も良く、又、プログラムを書き込むツールも安く売られています、必要な情報も公開されている為、自分で書き込み装置を製作する事もでき、これらのソリューションは、ホビーでハードウェアーを自作する人たちに好まれてきました。

２種類の自作 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 表示を持った小型デバイスを作ってみました、表示だけではエンターティメント性に欠けるので、単音の矩形波で実現するパルスサウンドモジュレーター（チープですが）を組み込みました、そして、入力デバイスとして４つの押しボタンスイッチ、時計用のリアルタイムクロックも加えました。

※各モジュールを外して分解したところ
※この写真にはRTCなどが含まれていません。

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

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

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

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

（２）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++ として必要十分の事は出来るようになります。

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

//-----------------------------------------------------------------//
/*!
    @brief  ATMEGA168P タイマー２ 割り込みタスク（タイマー０比較一致）
*/
//-----------------------------------------------------------------//
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 が定義しているデバイス毎の割り込み関数用マクロです。

（４）同期式プログラムとモーションオブジェクト
ゲームでは、ファミコン時代から、画面の更新（60Hz）に同期してプログラムを動かす方式が主流です、一般的なアプリが、メッセージを送受信して、それに応答するように設計されるのに比べて小規模なシステムでは、合理的な事が多く、細かい制御が楽な為です。
ゲームアプリケーションでは、絶対的な時間軸に沿ってプログラムを動かします、たとえば「移動」を考えた場合、停止している場合は、移動ルーチンをスキップしているのでは無く、速度を「０」にしているに過ぎません、移動ルーチンは、動いていても動かなくても常に通っています、全体的に、このような方法論により組み立てます。
しかしながら問題もあって、処理負荷が大きくなり過ぎると、画面の更新（ 60Hz だと 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);     ///< スイッチの状態を更新して、押した瞬間、離した瞬間を作成
    }

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

    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 では、一定の周波数を短形波出力して、１と０の比率を変える事で、平均すれば、強弱を変化させている事に等しくなります、PWM の周波数は、人間の可聴範囲外にある（今回は 78KHz を設定）ので、PWM で変調する事により、全体として、音の強弱として聞こえます、最終出力には、RC フィルターを入れて、高い音の成分をなだらかにして、多少聞きやすくしています。

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

・キッチンタイマー用楽曲
   // ストラップ（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
    };

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

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

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

ＤＳ１３７１

バックアップ電池

（７）アプリケーションの実際
今回は、とりあえず、以下の機能を入れてあり、全体で１９キロバイト程の容量となりました。
・キッチンタイマー
・３分、４分、５分、用タイマー（カップ麺用）
・ゲーム
・時計

（８）電源
AVR は５Ｖで動作させているので、リチウムポリマー電池（３．７Ｖ）から５Ｖを生成して、動かしています。
リチウムポリマー電池の充電はＵＳＢから行えるようにしてあります。
※この部分は、昔にジャンクで買った、ＵＳＢバッテリーをそのまま分解して使いましたｗｗｗ

※この部分は、大きさに難がありまだ載せていません・・・

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

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

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

操作の動画

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

よろしくお願いします！

RVF/RC45 blog

日別アーカイブ: 2013年12月4日

WinAVR C++ の実力とは！？

Just another WordPress site

2013年12月
月	火	水	木	金	土	日
« 11月				1月 »
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31