CuBeatSystems

小規模組み込みシステムでも使えるBMPライブラリ(Tiny BMP I/O)

2012-02-22T07:36:00.001+09:00

はじめに

昨年の今頃に着手したBlacktank LPC1769からは複数の派生プロジェクトが生まれています。

Natural Tiny Shell (NT-Shell)もその一つですが、今回は小規模組み込みシステムでも使えるBMPライブラリ(Tiny BMP I/O)について触れます。

これは何？

Tiny BMP I/Oは、BMP Data StreamからBMPイメージを読み込んでPixel Storageにピクセル値を格納したり、Pixel Storageからピクセル値を読み込んで、BMP Data StreamにBMPイメージを書き込んだりすることのできるライブラリです。

一般に書かれたライブラリでは、「BMPデータがどこに格納されているのか＝ファイルに格納されている」、「ピクセルデータがどこに格納されているのか＝メモリ」という暗黙の前提が使われている事が多いのですが、Tiny BMP I/Oはそれらをシステム依存として捉えて設計してあります。

システムに依存する部分をきちんと切り出す事で「１つのライブラリでSDからも、フラッシュからもSRAMからだって読める！」、「カメラから読んだ画像を簡単にBMPファイルにできる！」など、色々な用途で使用する事が可能になります。

例えば、「SDカードにあるファイルを読み込んで液晶に表示したい」とか「カメラから取り出した映像をファイルに書き込みたい」などはすぐに考える事のできる応用例の１つです。

また、それだけではつまらないのでbmpimg_tというキャンバスに対して描画可能なプチユティリティも装備しました。描きたいパターンをさっと実現してファイル化する事が可能です。

int bmpimg_draw_box(bmpimg_t *p, const int x1, const int y1, const int x2, const int y2, bmpcol_t *color);
int bmpimg_fill_box(bmpimg_t *p, const int x1, const int y1, const int x2, const int y2, bmpcol_t *color);
int bmpimg_draw_string(bmpimg_t *p, const int x, const int y, const int size, const char *text, bmpcol_t *color);
int bmpimg_draw_line(bmpimg_t *p, const int x1, const int y1, const int x2, const int y2, bmpcol_t *color);
int bmpimg_draw_pixel(bmpimg_t *p, const int x, const int y, bmpcol_t *color);

機能

24ビットBMPファイルの入出力に対応。
特定プラットフォームに非依存。
便利な描画用ユティリティ付属。
その他。

簡単に使えます

Tiny BMP I/Oはシステムに依存する以下の機能を実装するだけで簡単に使えます。

データのリード、ライト関数
ピクセルのリード、ライト関数

データのリード、ライト関数は、BMPのイメージが直列化されて格納されている領域を、ストリームとして入出力するための機能を提供するものです。

ピクセルのリードライト関数は、画像を実際に表示したりするための入出力機能を提供するものです。

ポイント

この手のライブラリは世の中に溢れています。

「また車輪の再開発か」と言われそうですが、必ずしもそうではありません。

ここではTiny BMP I/Oで考慮されている点を挙げてみます。

データがどこに格納されているのか？に依存しない。
画像ピクセルがどこに、どのように格納されているのか？に依存しない。

データがどこに格納されているのか？に依存しない。

小規模組み込みシステムでは、データが必ずファイルシステム上に存在するとは限りません。

一般に流通しているライブラリの多くは「データはファイルシステム上のファイルとして存在する事」を前提に設計実装されています。これらのライブラリを使用する場合、小規模組み込みシステムにファイルシステムとlibcをポートする事になります。

Tiny BMP I/Oは、データがどこに格納されいるのか？についての前提を持ちません。

それがファイルシステム上であろうが、フラッシュメモリ上であろうが、SRAM上であろうが、何の問題もありません。どこに格納されていても

画像ピクセルがどこに、どのように格納されているのか？に依存しない。

ここで言う「画像ピクセル」とは、データを読み込んで解釈した映像の１つ１つのピクセルを指します。

「画像ピクセルがどこに格納されているのか？」ですが、普通に考えるとメモリ上に格納するわけですが、ちょっとした画像ファイルでも結構な容量になってしまいます。例えば、1920x1080ピクセルでR, G, Bの各レイヤーが8ビットだったとすると、1920x1080x1x3=6,220,800[Bytes] (約6[MB])になってしまいます。潤沢なメモリが対象システムに存在するかどうかはシステム次第です。

読み込んだデータをそのままディスプレイに表示させたいだけの場合もあります。

この場合、わざわざ読み込んだデータをメモリ上に展開する必要はありません。

そのまま表示してしまえば良いのです。

巷に出回っているBMPライブラリの多くは、画像ピクセルデータをメモリに展開する事を前提で書かれているため、小規模組み込みシステムでそのまま使用することは難しい事があります。

Tiny BMP I/Oはシステムに対するインターフェースを規定して設計してあります。

このインターフェースさえ守れば、画像ピクセルがどこにどのように格納されていても問題ありません。

サンプルプログラムとその画像

サンプルプログラムでは、インターフェースの動作を的確に示すために、汎用プラットフォームで動作するコードを示しています。このコードを見れば、Tiny BMP I/Oが規定している入出力インターフェースを簡単に理解することができます。

プログラムはここからダウンロードできます。

実際にTiny BMP I/Oを使って出力したサンプル画像を示します。

サンプルプログラムでは、汎用プラットフォーム向けの実装を提供していますが、Tiny BMP I/Oのインターフェースに従った実装をプラットーフォーム向けに提供しているだけです。

プラットフォームに依存した部分を書き換えれば色々なプラットフォームで使うことができます。

/**
 * @file sample.c
 * @author Shinichiro Nakamura
 * @brief 小規模組み込みシステム向けBMP I/Oのサンプル実装。
 */

/*
 * ===============================================================
 *  Tiny BMP I/O Module
 *  Version 0.0.1
 * ===============================================================
 * Copyright (c) 2010-2011 Shinichiro Nakamura
 *
 * Permission is hereby granted, free of charge, to any person
 * obtaining a copy of this software and associated documentation
 * files (the "Software"), to deal in the Software without
 * restriction, including without limitation the rights to use,
 * copy, modify, merge, publish, distribute, sublicense, and/or
 * sell copies of the Software, and to permit persons to whom the
 * Software is furnished to do so, subject to the following
 * conditions:
 *
 * The above copyright notice and this permission notice shall be
 * included in all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
 * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
 * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 * OTHER DEALINGS IN THE SOFTWARE.
 * ===============================================================
 */

#include 
#include 
#include "pattern.h"

int main(int argc, char **argv);

/**
 * @brief 独自に規定したキャンバス構造。
 * @details
 * このサンプルでは、汎用プラットフォーム向けなのでメモリ上に画像を格納する。
 */
typedef struct {
    int w;              /**< 横方向サイズ。 */
    int h;              /**< 縦方向サイズ。 */
    bmpcol_t *buffer;   /**< バッファへのポインタ。 */
} canvas_t;

/**
 * @brief ストリームからデータを読み込む。
 * @details
 * インターフェースでは、何からどのように読み込むかについて一切感知していない。
 * この関数では、何からどのように読み込むかについて解決する。
 *
 * @param buf バッファへのポインタ。
 * @param size 読み込みバイトサイズ。
 * @param extobj ユーザが指定した拡張オブジェクト。
 */
int func_fread(void *buf, const unsigned int size, void *extobj)
{
    FILE *fp = (FILE *)extobj;
    return fread(buf, size, 1, fp);
}

/**
 * @brief ストリームへデータを書き込む。
 * @details
 * インターフェースでは、何にどのように書き込むかについて一切感知していない。
 * この関数では、何にどのように書き込むかについて解決する。
 *
 * @param buf バッファへのポインタ。
 * @param size 書き込みバイトサイズ。
 * @param extobj ユーザが指定した拡張オブジェクト。
 */
int func_fwrite(const void *buf, const unsigned int size, void *extobj)
{
    FILE *fp = (FILE *)extobj;
    return fwrite(buf, size, 1, fp);
}

/**
 * @brief ピクセル値を書き込む。
 * @details
 * インターフェースでは、何にどのように書き込むかについて一切感知していない。
 * この関数では、何にどのように書き込むかについて解決する。
 *
 * @param x X座標。
 * @param y Y座標。
 * @param r 赤。
 * @param g 緑。
 * @param b 青。
 * @param extobj ユーザが指定した拡張オブジェクト。
 */
void func_pixel_write(const int x, const int y, const uint8_t r, const uint8_t g, const uint8_t b, void *extobj)
{
    canvas_t *canvas = (canvas_t *)extobj;
    bmpcol_t *buffer = canvas->buffer + (canvas->w * y) + x;
    buffer->r = r;
    buffer->g = g;
    buffer->b = b;
}

/**
 * @brief ピクセル値を読み込む。
 * @details
 * インターフェースでは、何からどのように読み込むかについて一切感知していない。
 * この関数では、何からどのように読み込むかについて解決する。
 *
 * @param x X座標。
 * @param y Y座標。
 * @param r 赤。
 * @param g 緑。
 * @param b 青。
 * @param extobj ユーザが指定した拡張オブジェクト。
 */
void func_pixel_read(const int x, const int y, uint8_t *r, uint8_t *g, uint8_t *b, void *extobj)
{
    canvas_t *canvas = (canvas_t *)extobj;
    bmpcol_t *buffer = canvas->buffer + (canvas->w * y) + x;
    *r = buffer->r;
    *g = buffer->g;
    *b = buffer->b;
}

int main(int argc, char **argv)
{
    const int imgw = 1280;
    const int imgh = 720;
    canvas_t canvas;
    bmpimg_t bmpimg;
    FILE *fp;

    /*
     * 画像ピクセルを格納する領域を確保する。
     */
    canvas.w = imgw;
    canvas.h = imgh;
    canvas.buffer = (bmpcol_t *)malloc(sizeof(bmpcol_t) * imgw * imgh);

    /*
     * 開始処理。
     *
     * ピクセル入出力関数を渡して初期化する。
     * ユーザが指定可能な拡張オブジェクトに、独自に規定したキャンバスを渡しておく。
     */
    bmpimg_open(&bmpimg, imgw, imgh, func_pixel_write, &canvas, func_pixel_read, &canvas);

    /*
     * サンプルの実装では、ファイルから読み込む。
     */
    fp = fopen("input.bmp", "rb");
    if (fp != NULL) {
        bmpimg_bmp_read(&bmpimg, func_fread, fp);
        fclose(fp);
    }

    {
        /*
         * パターン１を書き込む。
         */
        pattern_sample1(&bmpimg);

        /*
         * サンプルの実装では、ファイルに書き込む。
         */
        fp = fopen("sample1.bmp", "wb");
        if (fp != NULL) {
            bmpimg_bmp_write(&bmpimg, func_fwrite, fp);
            fclose(fp);
        }
    }

    {
        /*
         * パターン２を書き込む。
         */
        pattern_sample2(&bmpimg);

        /*
         * サンプルの実装では、ファイルに書き込む。
         */
        fp = fopen("sample2.bmp", "wb");
        if (fp != NULL) {
            bmpimg_bmp_write(&bmpimg, func_fwrite, fp);
            fclose(fp);
        }
    }

    /*
     * 終了処理。
     */
    bmpimg_close(&bmpimg);

    /*
     * 画像ピクセルを格納する領域を破棄する。
     */
    free(canvas.buffer);

    return 0;
}

Blackfin ADSP-BF592搭載基板ACB-BF592の下ごしらえ

2012-01-29T14:38:00.001+09:00

先日入手したBlackfin ADSP-BF592搭載基板ACB-BF592の下ごしらえです。

この基板は動かすためのコンポーネントが全て入ったいわゆる「全部入り」なので、ピンヘッダをくっつけておけば準備完了です。

ということでピンヘッダを準備します。
デバッガを接続する箇所にはキーに合わせてピンを１ピン抜いておきます。

実装するとこんな具合。

秋月電子通商さんのAE-FT2232と並べてみましょう。

このサイズでDSPが楽しめるなんて幸せです。

こんな感じで準備ができました。

DSP空挺団さんのページでは、ブレッドボードを使って使用する様子が書かれています。

http://bfin.sakura.ne.jp/?p=125

うーん。

私も早くやってみたい！

これは新機軸！金子システム株式会社さんのDSP基板が登場（予定）！

2012-01-22T21:22:00.002+09:00

このブログを読んでいらっしゃる方の中にも「DSP触ってみたいなぁ」という方が結構いるのではないでしょうか？そんな私も例に漏れず以前から「Blackfinを触ってみたい触ってみたい」と念仏のように唱えていました。

色んなきっかけによって徐々に環境を整えつつあるのですが、先日「私好みのキュッと引き締まったDSP基板」を入手する事ができましたので御紹介します。

私がすっかり気に入ってしまったDSP基板の写真はこちら。

この基板は金子システム株式会社さんの設計によるもの。
基板フェチの私は美しく引かれたパターンとティアドロップにうっとりです。
プロの仕事はやはり違います。

コンパクトな基板の上にBlackfinとクロックとSPIフラッシュとJTAG用ヘッダとブートモード選択用DIPスイッチと1.2V降圧レギュレータが搭載されています。要するにこの基板に+3.3Vを供給するだけで、直ぐにでもDSPを楽しむ事ができるのです。

搭載されているDSPはAnalog Devices社のADSP-BF592 Blackfinです。

なるほど～って、全然まだ意味がわかっていません。
なんだこのブロック・ダイアグラムにある「BLACKfin」ってのは！と突っ込みたくなります。
これがDSPの心臓部分か。

そんな感じでヨチヨチ状態ですが、NXPセミコンダクターズのLPCシリーズと合わせて、今年はこちらも楽しみたい！それにはまずデバッガの入手かな？

ちなみに、このDSP基板は今後販売予定があるそうです。
興味のある方は金子システム株式会社さんまで問い合わせてみて下さい。

「CuBeatSystemsのウェブを見た」と言うと・・・おそらく特典は無いと思います。

プチ報告「小規模組み込みシステムプラットフォーム研究部会」

2012-01-22T20:47:00.000+09:00

遅ればせながら、先週行なった「小規模組み込みシステムプラットフォーム研究部会」～近代文学施設でモクモクと組み込みシステムプラットフォームを研究しよう～のプチ報告です。

場所は神奈川県横浜市の港の見える丘公園の中にある神奈川近代文学館でした。

プチ参加賞は夏目漱石が自筆で作った原稿用紙の復刻版・・・を１枚。
これは施設で販売されていたので面白くて購入しました。

朝９時３０分から１８時００分までの開催。
途中、公園内の散策を楽しむ余裕もありました。

和室の風景はこちら。
温泉旅館に宿泊しているかの雰囲気が個人的に好みです。

相変わらずの絵で皆様をお出迎えしました。

夜は当然ながら親睦を深める会です。
と言っても、コアなメンバーが集うので結局のところ熱く組み込み談義が繰り広げられました。
楽しかった！

前回の「LPCXpresso横浜お楽しみ部会」では、参加者の開発の様子も御紹介しました。
本当は今回も御紹介しようと思ったのですが、今後は参加された方が見れるお互いの様子という形にしようと思います。
その方が、公開したくない人も参加しやすいかな？と思いました。

継続的に開催する方向で検討中ですので、皆様も機会があえば是非！

Red Probe+を購入しました

2012-01-09T20:27:00.000+09:00

先日勢い余ってSoliton WaveさんでRed Probe+と10ピン-20ピン JTAGアダプタを発注しました。

本日やっとこさの開梱です。

本体には20ピンのJTAGケーブルが接続されています。
付属品やUSBケーブルとウェブへのリンクを示すシートです。

こちらは一緒に購入した10ピン-20ピン JTAGアダプタです。

SWDをインターフェースとして使用する時に使います。

実は、Red Probe+内部にもSWD用ピンヘッダがあります。
上記のアダプタの10ピンケーブルを、内部SWD用ピンヘッダに直接接続して使用する事も可能。
その場合、20ピンJTAGケーブルは取り外しておいた方が良いでしょう。

それらの情報はcode_red社のウェブから見る事ができます。
http://www.code-red-tech.com/red-probe-plus.php
http://support.code-red-tech.com/CodeRedWiki/HardwareDebugConnections

私はBlackTank(20ピン JTAGが出ている)でもこいつを使用する予定なのでアダプタを使用します。
ちょっとケーブル部分が長いです。

かかった費用はこちら。

なかなか大きな出費です。

気になる使用感やLPC-LINKとの違いなどは後日レポートしたいと思います。

有償のIDEであるRed Suiteを使った時に最大限メリットが出るような製品設計です。
LPCXpressoと組み合わせた場合、どの程度メリットを享受する事ができるのでしょうか。
その点を知りたいがためだけに購入したという人柱的企画です。

LPC-LINKと同じだったらどうしよう・・・。

FusionPCBの基板発注から到着までの日数（DHL発送選択時）

2012-01-09T20:03:00.000+09:00

工程を振り返ってみる

昨年末の12/29にFusionPCBへ発注した基板が手元に届きました。
今回はできるだけ早く基板が欲しかったのでDHLによる発送を指定。

ちょっと工程を振り返ってみましょう。

12/29：発注
12/30：オーダー受付 (1日目)
12/31：土曜
01/01：日曜
01/02：月曜 (2日目)
01/03：火曜 (3日目)
01/04：発送 (4日目)
01/05：運送
01/06：運送
01/07：到着

発注してから4営業日で発送された事になります。
なかなか早いですね。

中国は旧正月がお休みです。
ということで日本のお正月とは関係なくお仕事をされているわけです。

年末からお正月にかけての発注は、仕事量も減っていて例年素早く対応可能なのかもしれません。
お正月にこたつでぬくぬくしながら研究したい場合、この時期の発注は検討の価値がありそうです。

費用

ちなみに費用は5cmx10cm MaxのコースでDHL送料込みで5千円前後でした。
気長に基板の到着を待つ事を前提にDHLを選択しなければ半分くらいの費用で済みます。

おまけ

一緒に入っていたシートがこれ。

一昔前、「中国」と「イノベーション」が一緒になるなんて誰も考えもしませんでした。
「Innovate with China」がなんとなく真実味を帯びてきているような気もします。

がんばれニッポン！
（と言いながら中国の企業に基板を発注しているので、何とも言えません。）

小規模組み込みシステムプラットフォーム研究開発温泉プレビュー

2012-01-09T15:22:00.000+09:00

小規模組み込みシステムプラットフォーム研究開発温泉プレビューって何？

来週末に行なう小規模組み込みシステムプラットフォーム研究部会のノリで、温泉に一泊しながらグダグダ（ダラダラ？）各自が好きな研究に没頭する為の企画、小規模組み込みシステムプラットフォーム研究温泉なるものを検討しています。

この企画は、伊豆か熱海かそこいらの温泉旅館に詰めかけて泊まり、研究専用部屋を設け、集ってガサゴソ研究するというもの。集うと言っても、同じ目標に向かってガサゴソするわけではなく、各自がやりたい事をやりたいようにやるモクモク会のようなものです。

企画の性質上、どのくらい人が集まるのか？とか、そもそも泊まり込みでやる意味があるのか？とか色んな疑問が湧いてくるのでまずは実地実験する事にしました。
名付けて「小規模組み込みシステムプラットフォーム研究温泉プレビュー」です。

はっきり言って、泊まって作業してみないとどんな具合かなんてわかりません。
なかなかお金のかかる実地実験ですが、面白そうなのでやってみる事にしました。

どこまで行ったの？

今回は横浜から伊豆急下田までの遠征です。

実地実験会場は「下田ベイクロシオ」を選びました。
ペリー艦隊が来航した湾の直ぐ近くです。
伊豆あたりであれば何でも良かったので、今回は適当に選びました。

旅の様子

まずは電車に乗り込んで移動します。

単なる移動では勿体ないので、早速コーディング。
集中すればするほど酔いそうです。自分のコードに・・・ではなく、電車に・・・。

横浜から伊豆急下田までは、JR踊り子号を使って約2時間40分の旅です。
黒船来航の港に到着。

ちょうどお昼時に到着したので、駅前でお食事。

一夜干しをお土産に・・・なんて考えていると何しに来たんだか。

今回のホテルはチェックインが3時だったので、しばし散策。
ペリー艦隊にまつわる色々を見て回ります。

こちらは1837年製のカノン砲。

下田開国博物館を見学。

ひなびた風景も楽しめます。

そうこうしているうちにチェックイン可能な時間になったので移動！
ホテルからの景色を眺めてしばし休憩です。

休憩もつかの間、早速研究開発温泉の開始です。

今回は小規模組み込みシステムで使用可能なBMP入出力モジュール、「Tiny BMP I/Oモジュール」の設計と実装から。随分前から登録して放置していたプロジェクトです。このモジュールの詳細に関しては、また後日取り上げたいと思います。

集中して取り組んでいるとあっという間に時間が過ぎていきます。
外の景色を見ると様子が変わっています。

作業の成果が出たところで気持ちの良い温泉や美味しい食事が待っているなんてなかなか洒落ています。

海の幸で食事を楽しみます。
普段の生活圏から離れ、普段と異なる食事。
いつもと違う発想もここから生まれます。

食事や温泉を楽しんだ後は、またまたコーディングです。
Tiny BMP I/O Moduleも元気に育ちました。

実現するとしたら気になるところ

今回のプレビュー工程によって得られた気になるところを挙げてみましょう。

あまり遠すぎない方が良い。
単なる宿泊施設でうまくやろうとしても無理。
一泊でやれることは限られている。
泊まり込む意義って？

「あまり遠すぎない方が良い」

今回は伊豆急下田まで行きましたが、片道約3時間は正直言って遠すぎました。

横浜から9時過ぎの列車に乗って到着するのが12時過ぎです。

仮に土日にかけて開催するとした場合、片道の移動だけで1/4の工程を過ぎてしまう事になります。これは勿体ない気がします。一泊ですから、時間を有効に使いたいところです。

電車の中でコーディングもしましたが、気持ち悪くなったりして「何やってんだか」という感じです。

「単なる宿泊施設でうまくやろうとしても無理」

宿泊施設は、「勉強会や会議をやる前提」になっている施設が必須と言えそうです。

今回のホテルは本当に「泊まるだけ」の前提でサービスが設計されています。

チェックインが3時でチェックアウトが10時です。

これでは温泉に入って食事をして寝る時間を差し引くと数時間しか作業時間が残りません。

どこかの部屋を「作業部屋」に設定する案もありますが、やはり寝室ともなる部屋は休む場所としてキープしたいところです。

単なる宿泊施設では、コンセントも少ないし、通信インフラも整っていない事も懸念材料の一つです。

ちなみに、チェックアウト後に部屋を借りる相談をしたところ「１時間3,150円です。」とのこと。

まぁ、そうですよね。でも、これではちょっと辛いです。

「一泊でやれることは限られている」

一泊でやれることは限られています。

私の場合、「今回はこれをやろう」とある程度材料を持ち込んで作業しました。

材料は3つくらい用意して現地入りしましたが、実現できたのは1つだけ。

放置作業だったので気分はスッキリしました。

人ひとりが一泊でやれることは限られています。

次に挙げる「泊まり込む意義って？」と合わせて価値を見出すのが良さそうです。

「泊まり込む意義って？」

普段長い時間話す事のできない人たちと、ノンビリした雰囲気の中で情報交換ができるという事でしょう。湯船の中で組み込み談義なんて普通はあり得ません。ちょっと違った視点で物事を見るチャンスと言えます。

一泊でやれることは限られますが、周囲の参加者が取り組んでおられる事や問題を観察する事で、自分にない異なる視点やアプローチを見つける事ができるかもしれません。

実現で得られるメリット

今回のプレビュー工程で感じられたメリットについて整理してみましょう。

着手できていなかった事に着手する絶好の機会。
温泉が良い！食事が美味しい！景色が良い！
その他

「着手できていなかった事に着手する絶好の機会。」

やはり一泊の工程で何かをやろうとした場合、それなりの目的意識が必要です。

そういえば「あれ」やってないな、といった素材を持ち寄れば気になっていた事が片付いたりしてスッキリできます。

一泊のバッチサイズですから規模は限られます。

ですが、目的を明確にし、他の参加者との交流もできると考えると、かなり身になる機会と言えるでしょう。

「温泉が良い！食事が美味しい！景色が良い！」

もうネタですね。でも、これがあるから目的達成への動機にも成り得ます。

普段の生活から離れてリフレッシュできるメリットも。

「その他」

これはもう参加者の相乗効果によるものです。

意図をもって提供できない何かが得られる可能性があります。

ちょっと良さそうな場所

以前、@ssciさんから熱海温泉「芳泉閣」をお勧め頂きました。

チェックインが12時でチェックアウトが11時。

「学生合宿企業向け少人数研修宿泊施設」とあって、そのために行けるところが嬉しいです。

無料のLAN接続設備やホワイトボード、プロジェクタなども完備です。

これは良さそう。

まとめ

今回の企画、「小規模組み込みシステムプラットフォーム研究開発温泉」を、思い立ちのまま実現するとわけがわからなくなりそうです。

今回はプレビュー版として実地調査をしてみました。

色んな気分転換にもなりますし、普段の生活圏を離れる効果もあって集中できる環境が用意できる事は間違いありません。

機会があれば是非実現してみたい企画の一つです。

あ、以前考えていた名称は「小規模組み込みシステム開発温泉」なのですね・・・。

まぁ、どちらでも良いか・・・。

略称は「組み込み開発温泉」かな。

筺体設計で自作機器のお洒落度をアップしよう！

2012-01-07T06:45:00.000+09:00

先日の記事への突っ込み

先日の記事で「こんなの作っていました」と書きましたが、記事を見て頂いた人にとって有益になる情報は一つもありませんでした。
「こんなの出来るでぇ～。」という感じで「何だそれ？」と言いたくなります。
本来、CuBeatSystemsのブログは皆様の物作りに役立つ何かを発信したいわけです。

そこで、「どこに発注したの？」とか「どんなツールで図面を書いたの？」とかそんなところを「よくある質問に対する回答」という形で明らかにしたいと思います。

よくある質問

▼どこに発注したの？
山形県にある有限会社長井技研さんにお願いしました。

▼どんなスペックですか？
長井技研さんの管理されているサイト(板金加工eye)に掲載されています。
「アルミボックス電気回路収納用（個人様趣味用）」を御覧下さい。

このページには、私が最初に出した設計と、それに対する改善提案の内容が記載されています。
長井技研さんからの提案によって、より安価に安定した品質で仕上げる事が可能になりました。

▼CADは何を使ったの？
RootPro CADのFree版を使用しました。(このアプリケーションは、当時別名前でした。)

▼どのくらいの費用がかかりましたか？
赤アルマイト加工を含めて数万円です。(すみません。詳細は本当に忘れました。ごめんなさい。)

▼試作やリピートに対応してくれましたか？
はい。
私は先の設計を試作で１台、リピートでもう１台作りました。

筺体設計で自作機器のお洒落度をアップするメリット

所詮自分だけが使うもの・・・と割り切るのも良いのですが、基板むき出しのままですと気分が盛り上がりません。
筺体設計を行なった上で良い対応をしてくれる板金屋さんが見つかれば、自作機器の仕上がりを満足のいくまで高める事も夢ではありません。

数万円は時に非常に高価な投資です。
しかし、他人の作った誰でも持っている電子機器を数万円で購入する事を考えれば、満足のいく仕上がりを自作機器でも得られる良い投資と言える気がします。

CuBeatSystemsの製作事例 (2006年の品)

2012-01-05T21:08:00.003+09:00

先日の大掃除で出てきたデータの中からもう一つ。

この装置は2006年の設計。

管楽器の修理屋さんから頼まれた装置です。

板金は加工業者に図面を渡して作ってもらった物。

赤アルマイト仕上げでお金がかなりかかっています。

現場のハードな使用にも耐えられるように設計しました。

こんな感じで外装に気を配ると結構良い感じの仕上がりに見えます。

大掃除で過去のプロジェクトを見てみると「昔の方が気合いが入っていたのでは？」なんて思ってしまいます。ちょっと反省モード。

でも色々と見えてくるものもあります。

この頃は機械図面も書いていました。

しばらくご無沙汰しているのですが「本当のユーザが使う装置」も設計してみたいですね。

CuBeatSystemsの名前の由来

2012-01-02T08:34:00.001+09:00

CuBeatSystemsとは、CubeとBeatとSystemsによる造語で、「キュービートシステムズ」と読みます。
キューブ形状のビートを発生させる装置の開発を始めたのがきっかけで付いた名称です。

年末の大掃除できっかけとなった装置の写真が見つかったので掲載します。
撮影は2002年3月31日ということなのでもう10年前ですね。

まぁ、メトロノームなのですが、モンテューノを練習するためのシーケンスを出力できたり、ありがちな耳の痛い電子音を排除したりと独自の工夫を凝らした物になっていました。
この装置は実際にお二人にお譲りして使って頂きました。

EXIFを見ると当時の時代を反映しています。
OLYMPUSのC990Zで撮影した画像です。
当時学生だった私は、デジタルカメラなど持っているはずもなく、実家にあったデジタルカメラを借用してドキュメントなどを手作りしていました。

会社を作る予定もないのに会社のロゴを考えたりしていたものです。

こうして見ると古い記録というのは、面白いですね。
当時実現していたものとか、何を考えていたのかの一端が見えて懐かしくなったりします。

本年もよろしくお願い致します

2012-01-02T07:24:00.003+09:00

今年は、「小規模組み込みシステムプラットフォーム研究部会～近代文学施設でモクモクと組み込みシステムプラットフォームを研究しよう～」からスタートです。

その前の週は、徐々に構想を温めつつある企画、組み込みエンジニアが温泉を楽しみながらダラダラ研究をする「組み込み温泉」のシミュレーションをしてくる予定です。

本年もよろしくお願い致します。

ディジタル・オーディオ実験用基板BlackTankの進捗状況

2011-12-11T17:51:00.001+09:00

BlackTankは忘れた頃にやってくる・・・

MTM07で勢い余って展示しておいたBlackTankですが、急にやる気が出てきました。

私は、基板をスクエアーに作ってその中に機能を美しく詰め込むのが大好きです。

BlackTankも例に漏れずそんな感じで作ったオーディオ基板です。

と言っても、音質などは二の次で、とにかく色々楽しもうと色々欲張った感じになっています。

以下は、部品面、内層１、内層２、半田面の配線です。

この基板は、酔漢さんが進められておられるオーディオ・フレームワークUZUMEを利用できるように設計してあります。どうもMTM08には出展されるという事なので、BlackTankとしても出撃できるように準備をゆっくり開始する事にしました。

今日は久しぶりの通電と開発環境の確認です。

以前はOpenOCDを使ってデバッグしていたのですが、SWDを使った開発環境の方が手軽でした。

そこで、LPCXpressoのデバッガ側とターゲット側を切り離し、デバッガ側からそのままBlackTankに接続してデバッグする方針に変更です。

BlackTankでは、20ピンのJTAGを出しておいたので、そのままSWDによるデバッグも可能です。

このまま具合が良ければ、次回以降の設計でSWDの10ピンコネクタだけにするかもしれません。

MTM07出展報告

2011-12-11T17:26:00.001+09:00

もう１週間が過ぎてしまいましたが、MTM07の出展報告です。

UZUMEオーディオ・フレームワーク開発用基板

UZUMEは、酔漢さんが進められているオーディオ・フレームワークで、リアルタイム処理をフレームワーク側で遮蔽して、ユーザがオーディオ・アルゴリズムの実装に集中できるという素敵なコンセプトを持っています。

BlackTankは、オーディオ・コーデックを搭載したオーディオ・フレームワーク開発用基板で、パラメータ調整に必要な４系統のスイッチやボリューム、ちょっとした息抜きに便利な有機ELディスプレイなどを搭載しています。

実は一か所バグがあってファームウェア開発のテンションが下がり気味でした。
MTM07への出展によって幾つかの気づきがあったので開発再開の予定です。

Natural Tiny Shell

Natural Tiny Shellは、MTMには全く相応しくない「地味すぎるネタ」として展示しました。

殆どの人は「何これ？」という感じでしたが、スタッフが熱心に説明してくれたのと、「おっ！VT100というのに惹かれましたがこれは？」というその筋の方によって意外に人気のあった展示です。

LPCXpresso Clock

こちらはLPCXpresso Clockです。
今年は５月頃から全く身動きが取れないくらい色々忙しかったので、息抜きプロジェクトで作りました。GT-720Fで受信した時刻情報をそのまま表示という展示。

お菓子コーナー

そして、CuBeatSystemsブース恒例のお菓子コーナー。
間違って夫についてきてしまった奥様方やお子様に人気でした。

今回は積極的に色々してくれるスタッフに助けられました。
スタッフさんありがとう。

薄暗くなること間違いなし！MTM07の展示内容

2011-12-02T21:06:00.001+09:00

さて、明日から２日間に渡って東京工業大学にてMake: Tokyo Meeting 07が開催されます。
CuBeatSystemsも半ば惰性で出展します。おぉ、こんなはずでは。

先日触れたとおり、「LPCXpresso横浜お楽しみ部会」の勢いに乗る予定でしたが、ついでに「小規模組み込みシステムプラットフォーム研究部会」も触れておこうとか、「日頃のマイコンいじりできない欲求を解消しよう」とかで、既に何者なのかわからなくなっています。

当日は、歩き回ってお疲れの皆様を癒すべく、「素敵な笑顔のスタッフと、むさ苦しい私がパソコンと睨めっこ。」というシュールな設定のブースでお出迎えする予定です。

以下はブースの完成イメージ図です。

プログラムガイドは「こちら」をご覧下さい。
オライリージャパンさんの公式サイトは「こちら」です。

当日は二人とも「うーん。」とか「あれぇ～。」とか言いながら、さして難しくもない課題に永遠と悩み続ける姿を皆様にお届けする予定です。

会場でお会いできる事を楽しみにしております。

GPSモジュールGT-720Fの設定コマンドと応答

2011-11-27T20:33:00.001+09:00

忘却の彼方のGPSモジュール

いつだったか忘れましたが、随分前に購入してそれっきりだったGPSモジュールGT-720Fを引っ張り出してきました。

特にこのモジュールを使いたい強い動機はないのですが、TOPPERS/ASP for LPCのUART系のデバッグに色々繋いで確かめたいというのと、どうせデバッグするなら「何か本当に使っている感じが欲しい」という事からの再登場です。（本当に使っている感じにするのは、成果物をより実用的なものにする意図があります。）

先日の「LPCXpresso横浜お楽しみ部会」にあわせて適当に仕立てた時、（どうでも良いけど）気になる事があったので調べる事にしました。（私の場合、本当に些細でどうでも良い事が気になって大事な時間を使ってしまったりして何だか残念な感じです。）

（どうでも良いけど）気になる事

「データ・シート」と言われているPDFに設定コマンドの仕様が書かれていない。
「SkyTraq(付属アプリケーション)では設定できるけど、マイコンからはできない。」と主張している人がいる。
それっぽいPDFは見つかるが、GT-720Fで使えるのかわからない。
誰もあまり調べてない。

まぁ、GPSと言えばu-bloxでしょという感じで、このモジュールにそれほど時間をかける意味もないのですが、気にしなくて良いや、と思えば思うほど、どんどん気になってくるのです。

とりあえず調べる

コマンドのやり取りに関する「それっぽいPDF」は見つかったので、それを参考にアプリケーションとGPSの通信を見てみます。

下のやりとりは、Configuration NMEA Messageコマンドです。

以下のメッセージは、SkyTraqのNMEAメッセージ編集画面で設定を実行した時に、アプリケーションからGPSモジュールに投げられるコマンドです。

さて、GPSモジュールからは２つのパケットが返ってきました。

さて、ウェブに転がっていたApplication Note AN0003 Binary Messages Of SkyTraq Venus 5 GPS Receiver Ver 0.3 Feb. 1, 2007と比較してみます。(Start of SequenceとEnd of Sequenceを黄色で囲ってあります。)

以下の通り、メッセージのフォーマットが一致している事がわかります。

Configure NMEA Messageのペイロードの仕様は、以下のように記述されていました。

どうやらこのPDFの内容と完全に一致するようです。

ACKの場合、要求に応じてACK応答の後に情報を返してくるようになっています。

これは、先の結果どおりです。

このように、それっぽいPDFの内容と一致していそうという事がわかりました。

それではということで、マイコンに以下のようなインターフェースを実装してみました。

とにかくマイコン上のアプリケーションからこのインターフェースを呼べば、SkyTraqと同じ設定が可能になるというわけです。

試しにVTGのみ1秒に設定し、その他を0(出力なし)にしてみました。

どうやら制御できているようです。

ということで

ということで、GT-720Fの設定はSkyTraqからだけでなく、当然のようにマイコンからも可能である事がわかりました。

まぁ、だからなんだという感じですが、特別に摩訶不思議なシーケンスがあるわけではない、という事がわかってスッキリしました。

モジュールに対して、永続的に設定を書き込みたいわけではないけど使いたい設定がある場合には、やはりマイコンから直接操作してやりたいものです。

コマンドの中にはバージョンを取得するインターフェースもあるので、GPSモジュールのバージョンを調べるのも良いかもしれません。

タダ同然で自分専用のバグ・トラッキング・システムを立てたい (レンタル・サーバー「ロリポップ」上にRedmineを仕立てる)

2011-11-27T09:37:00.001+09:00

タダ同然で自分専用のバグ・トラッキング・システムを立てたい

開発に欠かせないバグ・トラッキング・システムですが、以前から公開ウェブ・サーバー上に自分専用のサービスが欲しいなと考えていました。

自分が進行しているプライベートなプロジェクトの色々なアイデアやTODOをいつでもどこでも更新出来たら嬉しいなぁと考えたわけです。個人的にgithubやsourceforgeを使う事はありますが、バグ・トラッキング・システムを自分の好みで変更できないのが残念なところです。

また、プライベートなアイデアやプロジェクトが、ダダ漏れになるのも、それを避けるためにお金を払うのも、自分が好きなバグ・トラッキング・システムを使えない事と相まってお得な感じがしません。

単にアイデアをメモするだけならばその手のツールがあるのですが、それは単なるメモとしてしか役立ちません。後々見返してみた時に、「これ何だっけ？」とか「アイデアとアイデアの関係がどうだったのか？」とか、そもそもメモなのできちんと管理できないわけです。（少なくとも私は。）
それらのアイデアがどのようにコードになったのか知るすべもありません。

そんな事を考えていた時、自分が約10年前からレンタルしているサーバーの契約更新がありました。状況を調査してみたところ、以前に比べてバグ・トラッキング・システムを導入する為の環境が整いつつある事に気付きました。（プランの変更によって最大の障壁だったsshログインが可能という事がわかった。）

そこで、今回は私が使用しているレンタル・サーバー「ロリポップ」上に、バグ・トラッキング・システムRedmineを導入する過程を簡単に御紹介します。使用するプランは「チカッパプラン」です。このプランは月額525円で30GBの容量を確保できます。更に今回の作業で重要なsshが使えます。

この手の作業の何が面倒なのか？

この手の作業でとにかく一番面倒なのは「やってみて、うまくいくまで試行錯誤する過程。」です。
ウェブ・アプリケーションを導入する場合、沢山の依存関係の解決と細かなバージョン差異による影響を取り除くような作業が欠かせません。（あ、組み込みも同じか。）

開発をスムーズに進めるための環境作りに時間がかかりすぎて、開発がスムーズに進まないなんて笑うに笑えません。（実は今回そんな感じ。来週はMTM07です。出展の準備をしたい。）

本当に「何やってるの自分？」と自分に突っ込みたくなってきます。
更にRailsって何？とかRubyGemsって何？とかやってるとどうしようもなく時間がかかります。

この記事は「できる」という事実を示し、試行錯誤を少しでも取り除こうという狙いで書きました。

バグ・トラッキング・システムによる製品開発フロー

バグ・トラッキング・システムを使って製品を開発するフローは、背景にある考えによって様々ですが、大抵の場合は以下のようになるでしょう。

製品の仕様を考える。
「やること」を洗い出す。
「この日までに実現するんだ！」と決める。
「やること」と「この日までに実現するんだ！」を見ながら進捗や状況を管理する。
製品が完成したらリリースを決める。
市場から得られるフィードバックを集める。
最初に戻る。（要するに無限ループ。）

上記のループは、必ずしも1から始まるとは限りません。

もしかしたら6から始まるかもしれないし、もしかしたら3から始まる場合もあるかもしれません。

大切なのは「繰り返しの中で製品を改善する過程」です。

Redmineを使った機能追加の管理の実例を以下に示します。
Redmineの開発は、Redmineで管理されています。
以下に挙げるチケットは「ユーザの削除機能」に関するものです。

http://www.redmine.org/issues/7296 （機能追加の管理）
http://www.redmine.org/projects/redmine/repository/revisions/4729 （チケットに対するコミット）

メジャーなツールと僕の好きなRedmine

国内ではやたらとTracがメジャーな感があります。
私は以下の理由でRedmineを好んで使用しています。

一回構築すれば複数のプロジェクトで使用できる。
ビューがシンプルで美しい。
画像を貼ったりファイルを貼ったりが簡単。
その他（色々な事が自然にできるところなど。）

もしかしたら、現在ではその他のツールも同様の事ができるのかもしれませんが、一度Redmineに慣れてしまうと他のツールに積極的に移行する気になれません。これは、数年前にTracとMantisをつまみ食いしているので、自分にとってどちらが好ましいと感じるかを知っているせいかもしれません。

ロリポップでRedmine

さて、長い前置きはさておき、ロリポップでRedmineを実現します。

今回は手始めとしてcgiモードを使ってまずは実現する事を念頭に、ハマりそうなところだけを列挙しする事にしました。

出来上がるとアクセスした時に以下のようなページが表示されます。

使用した各ツールのバージョンを挙げておきます。

rubyはロリポップのサーバーにインストールされているruby 1.8.7を使用しました。

RubyGems 1.3.7
rails 2.1.2
rack Redmine 0.8.xを使用するので依存しない。
Redmine 0.8.7

上記のバージョンの関係はRedmine本家のインストール・ガイドのページに記載されています。

新しいバージョンのRedmineをインストールしたい場合、上記バージョン関係を把握してから行ないましょう。上記の依存関係を見てもわかるように、細かなバージョンの違いで動作しない事が十分に考えられます。

RubyGemsのセットアップ

初めにRubyGems 1.3.7をwgetでダウンロードして展開します。

展開したディレクトリにあるsetup.rbに「--prefix $HOME」を与えてセットアップを実行します。

ロリポップが提供するサーバにsshでログインした場合、LolipopUserというIDが割り当てられています。(当然ながらroot権限ではありません。)

これでRubyGemsのインストールは完了です。

私はこの時点で.bash_profileに以下を追加しました。

export RUBYLIB=~/lib
export GEM_HOME=~/lib/ruby/gem
export RAILS_ROOT=~/rails/redmine
export PATH=$PATH:~/bin:~/lib/ruby/gem/bin

「source ~/.bash_profile」したら念のためホームで「gem -v」してバージョンを確認します。

「1.3.7」と出れば狙いの環境になっています。エラーが出たらパスが通って無いとかsetup.rbでの環境構築に失敗しているとかが考えられます。

Railsのセットアップ

次にrailsをgemを使ってインストールします。

「gem install -v=2.1.2 rails」とすればバージョンを指定してインストールする事ができます。

以上でRedmineが依存する環境を作り上げた事になります。

Redmineのインストールとセットアップ

次にRedmine本体のインストールです。

Redmine 0.8.7をダウンロードして、展開します。

私は$HOME/rails/redmineに展開しました。

config/database.yml

展開したらconfigディレクトリに移動してセットアップを行ないます。

初めにconfig/database.yml.exampleをコピーしてconfig/database.ymlを作ります。

(ハマりどころ)設定はロリポップの管理ページにある情報をそのまま記載します。

(ハマりどころ)socketの項目はテンプレートに無いので追加して下さい。

(ハマりどころ)socketの設定はロリポップのmysqladminを使って確認して下さい。サーバの変数という項目にsocketがあります。

(ハマりどころ)production設定を使う為の作業をしていると頭の片隅に入れておいて下さい。

データーベースを初期化する

この作業は展開したredmineのディレクトリで行います。
rakeがRakefileを参照して作業するからです。

rake db:migrate RAILS_ENV=production
rake redmine:load_default_data RAILS_ENV=production

config/environments/production.rb

ウェブ・サーバが持つルートの配下にディレクトリを作って構成する場合には、config/environments/production.rbに以下を追加します。

ActionController::AbstractRequest.relative_url_root = '/あなたのディレクトリパス

config/environment.rb

config/environment.rbにパスの設定などを追加します。

(下記の設定は最適でないかもしれません。環境に合わせて最適な記述をして下さい。)

また、productionを使うのでコメント・アウトされている部分を有効にします。

もう、このあたりで「動くのかなぁ～。」と不安になります。

dispatch.cgi

最後にディスパッチャの設定です。

今回は遅い遅いと評判のdispatch.cgiを使っています。

一行目のrubyへのパスを環境に合わせて「/usr/bin/ruby」としました。

.htaccess

最後に.htaccessの編集です。

「Options +FollowSymLinks +ExecCGI」をコメントアウト。
「AddHandler cgi-script .cgi」を追加。
「RewriteRule ^(.*)$ dispatch.cgi [QSA,L]」を追加。

公開ディレクトリにあるファイルのパーミッション

公開ディレクトリにあるファイルのパーミッションを整えます。

ロリポップのサポート・サイトの情報も参考にしてください。

とりあえず動かすようにした作業のまとめ

今回は「とにかく実現してみるんだ」という方向で作業しました。

レンタル・サーバでRedmineというと何故だかさくらインターネットでの事例ばかりです。

もしかしたらきちんと運用する人は「ロリポップなんて使わない。」ということかもしれません。

今回は「ロリポップでもRemineを動作可能」を示すためだけにかなり適当に作業しました。

メールの設定やバージョン管理システムとの連携が残っていますが、動作する事がわかったので後はゆっくりとやっていこうという感じです。

タダ同然じゃない！

「タダ同然で」と書きましたが、全然タダではありません。

冒頭に書いたとおり月額払う事になりますが、「ホームページを運用していたサーバで、実は動作させられる。」と考えれば安いと考えられなくもありません。

ET2011でNatural Tiny Shell (NT-Shell)のデモ・キットを展示しました

2011-11-24T21:39:00.001+09:00

御報告が遅くなりましたが、ET2011でNatural Tiny Shell (NT-Shell)のデモ・キットを展示しました。
以下の写真が展示の様子です。

物凄く地味なデモですし、内容も内容ですから、本当に興味を持った人しか立ち止まらない感じで、逆にそれが個人的に面白かったです。

私のプレゼンテーションを聞いてくれた人からも「実は私も同じようにシェルに不満を持っていました。」と声をかけてくれた人もいました。

さて、肝心の成果物ですが、本日Version 0.0.8をリリースしました。
http://sourceforge.jp/projects/ntshell/releases/ からダウンロードできます。

以前はシェル用ライブラリだけでしたが、今回から「ライブラリ」と「サンプル」の二本立て構成にしました。今のところ「サンプル」にはTOPPERS用の実装のみ追加しています。

今回プレゼンテーションを作成するにあたって設計を振り返ったところ、まだまだ改良できる点が多くある事に気付きました。

今後も継続的に改善を行ない、よりコンパクトで使いやすいシェルライブラリにする予定です。

プレゼンテーションにもいらしてくれたmayaさんがBlackfinに移植したレポートをあげてくれています。感謝感謝です。

小規模組み込みシステム向けシェル・タスク『Natural Tiny Shell Task』のデモ・キットをET2011のTOPPERSブースで展示します。

2011-11-09T05:16:00.002+09:00

小規模組み込みシステム向けシェル・タスク『Natural Tiny Shell Task』のデモ・キットをEmbedded Technology 2011のTOPPERSブースで展示します。

先日から「Natural Tiny Shell Taskがどうのこうの。」と煩いわけですが、実際に触っていない人にとっては「何がそんなに嬉しいんだ？」という感じです。

そこで、今回は実際に動作を体験して頂けるようにしようと考えました。
下の写真がデモ・キットの外観です。

NXPセミコンダクターズ社のARM Cortex-M3が搭載されたLPCXpresso LPC1768にUSB-UART変換基板が接続されたものです。今回はシェルのデモなのでこれだけでも良いのですが、あまり面白いデモと言えなかったので、カラーLEDを付けてシェルから操作できるようにしてみました。

組み込みシステムのデバッグでは、コマンドをシステムに与えてデバッグする事がよくあります。今回はcolorコマンドに表示色を与えることで、カラーLEDの色が変化するというデモを用意しました。システムに対する要求が視覚的に判断できるので、楽しんでいただけるのではないでしょうか。

また、TOPPERSを触った事のない人にとって「きちんと動いているシェルっぽいもの」を見ても「何がそんなに良いわけ？」となります。そこで、このデモ・キットは、「適当に実装したシェル」と「Natural Tiny Shell」の二つを同時に体験できるように設計してあります。

「適当に実装したシェル」は、それこそ本当に適当で文字の入力を誤ると酷い事になるような実装になっています。「そんなのあるわけ？」と思うかもしれませんが、残念ながら小規模組み込みシステムでは実際によくある話です。

当日は２つの端末を並べて実際に操作しながら比較する事ができるようにする予定です。

ET2011の最終日である18日(金)の15時過ぎから「TOPPERS活用アイデア・アプリケーション開発コンテスト表彰式」と「コンテスト受賞作品の紹介」も行われる予定です。紹介のプレゼンテーションは私自身が担当する予定ですので皆様是非お越し下さい。

小規模組み込みシステム向けシェル・タスク『Natural Tiny Shell Task』が、TOPPERS活用アイデア・アプリケーション開発コンテストのアプリケーション開発部門で銀賞を受賞

2011-10-29T10:10:00.004+09:00

小規模組み込みシステム向けシェル・タスク『Natural Tiny Shell Task』が、2011年度のTOPPERS活用アイデア・アプリケーション開発コンテストのアプリケーション開発部門で銀賞を受賞しました。

関連してET2011のTOPPERS/SESSAMEパビリオンにおいて、アプリケーションについてのショート・プレゼンテーションとデモンストレーションも予定しています。TOPPERS（や、その他RTOS）を使った小規模組み込みシステムでシェルのようなものが欲しいけど、あまり良い物が見つからないとお困りの方は是非御来場下さい。

詳しくはTOPPERSプロジェクト／ET2011のページを御覧下さい。

「小規模組み込みシステムプラットフォーム研究部会」開催のお知らせ

2011-10-29T09:01:00.000+09:00

『小規模組み込みシステムプラットフォーム研究部会』開催のお知らせです。

小規模の定義は参加者の方々それぞれで構いません。
とにかくシステムのプラットフォームを考えるのが好きという方のための会です。

詳しくはATNDを御覧下さい。
http://atnd.org/events/21520

MTM07出展のお知らせ

2011-10-23T11:26:00.003+09:00

MTM07出展します。

今回は「LPCXpresso横浜お楽しみ部会」併設「小規模組み込みシステムプラットフォーム研究部会」での出展です。(出展者名はCuBeatSystemsです。)

小規模組み込みシステムを愛してやまない人達に向けた展示を目指しています。
皆様とお会いできることを楽しみにしております。

汎用BluetoothモジュールWT32搭載WCA-009を購入。

2011-10-13T07:29:00.002+09:00

WCA-009とは、Bluegiga社のBluetooth Audio ModuleであるWT32を搭載したモジュールです。
マイコン工作実験日記の大野さんが頒布しています。

私はというと「Bluetoothって何だべなぁ～。」という感じで素人もいいところなのですが、Bluetoothで繋がるということは手持ちのIS03と連携させて何かできるかもね！ということで購入して試してみる事にしました。

このモジュールは名称こそ「Bluetooth Audio Module」となっているものの、GPIOやUARTが出ていてマイコン基板のインターフェースとして色々な応用ができるようになっています。

うーん。
MTM07でもこれを使った物がチラホラ見かけられるかもしれませんね！

「LPCXpresso横浜お楽しみ部会」を開催しました～。

2011-10-08T22:21:00.003+09:00

「LPCXpresso横浜お楽しみ部会」を開催しました。

本日は、もくもく会の傍らプレゼンテーション３本をゆるゆるとこなすという会でした。

ライブな感じを味わっていただくための写真を掲載しておきます。

会場は神奈川県民活動サポートセンター 15階会議室(1501)でした。

この会は「ゆるゆる」な会なので、イラストで来場者の方を和ませる作戦です。

とびっきりの風景・・・とはいきませんが、遠くに見える海を眺めながらのもくもく会でした。

こちらは @h-kenken さん。
シェルからコマンドで操作できる組み込み装置な感じが好きです！

こちらは @tabriSyu39 さん。
気合十分で周辺デバイスの実装が完了しています。
プログラムの実装フェーズに入っていました。

こちらは @todotani さん。
どこかで見た事のある・・・と思った方。
はい。あのブログのお方です。
３階建ての構造ですが、シンプルに纏まっていて良い感じ。
当日取り組んでいらっしゃった成果を「XBee APIモードライブラリのLPCXpressoへの移植」で公開して下さっています。

こちらは @suikan_blackfin さん。
オーディオプラットフォームUzumeの第１版のデバッグの様子です。
プレゼンテーションでもプラットフォームの狙いについて熱く語って頂きました。

こちらは @noztos さん。
おっと～。Androidとの連携か？！

こちらは @hellslonghorn さん。
おっと～。Smart Fusionとの連携か？！

私はというと、すっかり自分の物を撮影するのを忘れてしまいました。
なので家に帰って撮影です。
LPCXpresso ClockをGPS時計にしてみました。
TOPPERS/ASP for LPCを使っています。

色々なサプライズがありましたが、本編より夜の会合の方が盛り上がってしまったのは内緒です。

皆様お忙しい中の御参加ありがとうございました。
非常に有意義な時間を過ごす事ができました。

makeを楽しく学ぶある１つの方法「makeで確認。幸せを作る方法。」

2011-09-28T23:33:00.000+09:00

makeで確認。幸せを作る方法。

makeについて考えていた時に、ふと閃いたある１つのアイデアを共有したいと思います。

エンジニアの卵達から耳にする事の多い「makeに慣れない。」という言葉。
以前からどうすれば楽しく伝えられるかなぁと考えていました。

先ほど少しだけ面白い方法を考えついたので御紹介します。
名付けて「makeで確認。幸せを作る方法。」です。

用意するもの

GNU make
テキストエディタ

基本ルール

Makefileという名前のファイルをテキストエディタで作りましょう。
コロンを境に、左側に得たい事、右側に必要な事を書きましょう。
得たい事と必要な事の組は複数あっても構いません。
得たい事を実現するための記述は、組み合わせの下に書きます。

やってみよう（実例）

私は、最終的に「幸せ」を手に入れたいと考えました。
基本ルールによると、コロンの左側に得たい事を書きますから以下のようになります。

happy :

次に「幸せ」のために必要な要素を、コロンの右側に書きます。

happy : time dream family friends

私は、幸せの実現のために、時間、夢、家族、友達を挙げることにしました。

次に、幸せに必要な各要素にも、必要な事があるかもしれません。
それについて書いてみます。

time :

dream :

family :

friends :

本当はこれらの要素にも必要な事があるのですが、無尽蔵に広がってしまうので、ここでは「いずれの要素についても、何も必要無し。」という事にします。

実際にmakeを実行した時に楽しくなるように、上記の結果に加えて実際の動作を行うコードを付け加えます。

実際の動作はコロンで結んだ関係図の一行下に記述するようになっています。
この行だけ特別にTABを頭に入れるルールになっています。

完成したのが以下のリストです。 (コードの中の「>-------」はTABに置き換えて下さい。)

happy : time dream family friends
>-------cat elm_time elm_dream elm_family elm_friends > my_happy

time :
>-------echo "The time." > elm_time

dream :
>-------echo "The dream." > elm_dream

family :
>-------echo "The family." > elm_family

friends :
>-------echo "The friends." > elm_friends

それでは実際に動作させてみましょう。

> make
echo "The time." > elm_time
echo "The dream." > elm_dream
echo "The family." > elm_family
echo "The friends." > elm_friends
cat elm_time elm_dream elm_family elm_friends > my_happy

見事に「私の幸せ(my_happy)」が完成しました。
ちょっと幸せの中身を覗いてみましょう。

> cat my_happy 
The time.
The dream.
The family.
The friends.

こんな感じで幸せが完成しました。

Makefileは基本的に「コロンで結んだ依存関係」を「解決するための実行」を記述するようになっています。上記の例のように最終的に欲しいものが４つから構成されていても、１つずつ丁寧に依存関係とその解決方法を書いてあげれば良いのです。

ここでもう１つ実験してみましょう。

必要な要素が足りないケースを作ってみます。
先ほどの「幸せ」に必要な要素に「お金」を加えてみます。世知辛いですね。

(コードの中の「>-------」はTABに置き換えて下さい。)

happy : time dream family friends money
>-------cat elm_time elm_dream elm_family elm_friends > my_happy

time :
>-------echo "The time." > elm_time

dream :
>-------echo "The dream." > elm_dream

family :
>-------echo "The family." > elm_family

friends :
>-------echo "The friends." > elm_friends

上記にお金の作り方は示されていません。
この状態でmakeを実行してみます。

> make
echo "The time." > elm_time
echo "The dream." > elm_dream
echo "The family." > elm_family
echo "The friends." > elm_friends
make: *** `happy' に必要なターゲット `money' を make するルールがありません.  中止.

あらら。

幸せの生成が中止されてしまいました。
お金の作り方がわからなかったからです。

実際にお金の作り方を教えてあげます。
(コードの中の「>-------」はTABに置き換えて下さい。)

happy : time dream family friends money
>-------cat elm_time elm_dream elm_family elm_friends elm_money > my_happy

time :
>-------echo "The time." > elm_time

dream :
>-------echo "The dream." > elm_dream

family :
>-------echo "The family." > elm_family

friends :
>-------echo "The friends." > elm_friends

money :
>-------echo "The money." > elm_money

これで改造版の幸せが生成されるはずです。

> make 
echo "The time." > elm_time
echo "The dream." > elm_dream
echo "The family." > elm_family
echo "The friends." > elm_friends
echo "The money." > elm_money
cat elm_time elm_dream elm_family elm_friends elm_money > my_happy
> cat my_happy 
The time.
The dream.
The family.
The friends.
The money.

幸せの中身に「お金」が追加されていますね。
成功です。

こんな風にmakeはシンプルなルールの組み合わせで多彩な出来事を作り出すことができるようになっています。プログラムのコンパイルのためだけでなく、様々な事に応用して楽しむことができるのです。

今回の記事では、構造に慣れ親しむ要素に絞って御紹介しました。
上記要素が骨格を成して、様々な便利な機能を実現できるようになっています。
次の機会にそれらについても触れてみたいと思います。

是非みなさんもmakeで遊んでみて下さい。
そして、makeで悩んでいるエンジニアの卵達には、是非楽しい教え方を試してみて下さい。

LX9 MicroBoardでSoCを体験しよう！

2011-09-16T19:08:00.002+09:00

米国Avnet社のLX9サポートページには、使い始めるのに必要な資料が殆ど揃っています。
今日はその中から面白そうな物をピックアップして試してみることにしました。

LX9で遊びたい事の一つはやはりSoC(System On Chip)ということになるでしょう。

そこで登場するのが「uC/OS-III Example Application - Software 301 for the Spartan-6 LX9 MicroBoard」というチュートリアルです。

このチュートリアルを辿ればLX9を使ってSoCに関連する一連の作業（の一部）を楽しむことができます。

ハードウェア定義ファイル(system.xml)を読み込んでハードウェアプロジェクトを作成する。
ハードウェアプロジェクトを指定して新しいボードサポートパッケージプロジェクトを作成する。
ソフトウェアプロジェクトを作成する。

と書いてしまえば３段階なのですが、資料なしでこのステップをIDEのインターフェースのみから汲み取ることはできません。そういう意味でこの資料は有用な内容になっています。

この資料では、Xilinx Software Development Kitを使ったRTOS上でのLEDチカチカを行います。

まずはXilinx Software Development Kitを起動します。

資料に従って作業するとワークスペースには形態の異なる３つのプロジェクトが出来上がります。

例えば、以下のケースでは、上からハードウェアプロジェクト、ボードサポートパッケージ、ソフトウェアプロジェクトです。

Xilinx ToolsからProgram FPGAを選択して、予め用意されたビットストリームファイルを使って回路を定義します。

ダイアログにはハードウェアプロジェクトを作成する時に与えたxmlによって必要な値が与えられていますので、特に何も入力する必要はないはずです。

ちなみに、このビットストリームを流し込む事によってボード上のLEDをチカチカさせるための回路やレジスタが定義され、プログラムのブート待ち状態にすることができます。

やってしまいがちな誤りが、このビットストリームを流し込む前にプログラムのデバッグを始めようとしてしまうこと。それは動きませんです。

Doneを確認したらプログラムを動作させてみましょう。

これで仲良く並んだ２つのLEDが適当な間隔で点滅することが確認できるはずです。

ふむふむと動作を楽しんだ後は、コードを見て楽しみましょう。

BSPには主にMicroBlazeのレジスタを操作するインターフェースを定義したヘッダファイルが配置されています。

OS側はプロセッサ周り、ライブラリ、カーネル、アプリケーションと綺麗に階層化されていますね。

このように、従来では色々な環境整備に時間がかかりがちだったSoC体験を、いとも簡単に実現してしまうのがLX9 MicroBoardなのです。

LX9のXilinx SDKからの書き込み

2011-09-14T20:20:00.005+09:00

LX9にビットファイルを流し込む方法

LX9は何と言ってもお手軽にSoCを試す事が出来るのが魅力の１つです。

Xilinx SDKから書き込む場合には予め設定が必要なのですが、どっからどうすんだ？となった方のために整理してみましょう。

まずはhttp://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,768&Prod=DIGILENT-PLUGINからプラグインをダウンロードします。
今日現在ではISE 11, ISE 12, ISE 13に対するプラグインが完備されていました。

後は付属のPDFに従ってインストールすれば完了！です。（え？）
プラグインをISEのプラグインディレクトリにコピーする作業の実行です。

後は各種ツールでの設定を残すのみです。
（このページの設定において、シリアルナンバー指定は割愛しています。詳しくは付属のPDFをご覧ください。）

例えば、Xilinx SDKの場合。

iMPACTの場合。

こんな感じで設定することでJTAG接続ができるようになります。

AVNET Spartan-6 FPGA LX9 MicroBoardの電源を入れてみる

2011-09-03T09:35:00.001+09:00

付属する2つのUSBケーブル

LX9 MicroBoardには2つのUSBケーブルが付属しています。

1つは延長ケーブルになっていて、「Direct USB Programming」用のUSBコネクタに接続します。
このコネクタは主にFPGAをプログラムするときに使用し、ボード上のAtmel AT90USB162に接続されています。

もう1つのUSBケーブルは小さい方のUSBコネクタに接続して使用します。
こちらはボード上のSilicon Laboratories CP2102に接続されています。

LX9 MicroBoardに予め書き込まれたデザインはMicroBlazeを使ったものになっていて、CP2102経由でブートの様子を見ることができるようです。
今回はこれを試してみましょう。

使っているOSによって、CP2102に対するデバイスドライバが必要になることがあります。
ちなみにWindows7の場合には特別なインストールなしで使用することができます。

ブートさせる

シリアルポート（115200/8/n/1)を開いてSW4を押すとリセットがかかるようになっています。

ブートした時の様子は以下のようになります。

私は他人の作ったコマンドを見るのが大好きです。

見てみましょう。

と、こんな感じのコマンドが並んでいます。

まぁ、だから何だという話ですが、組み込み装置として見た場合、この手のコマンドが整備されているかいないかで、メインテナンスやデバッグなどの効率を左右します。
ここまでのサンプルを用意することで、敷居を下げようとしている感じが見てとれます。回路図やUCFなどは米国AVNETのサイトへログインすることでダウンロードできます。

AVNET Spartan-6 FPGA LX9 MicroBoardの開発環境をセットアップする

2011-09-02T21:15:00.006+09:00

安価なFPGA開発プラットフォーム

FPGA評価ボードと言えば一万円前後の物が簡単に入手できるような贅沢な時代です。
Spartan-6 FPGA LX9 MicroBoardはソフトコアマイクロプロセッサ開発環境を付属して一万円を切る値段です。
実はこの評価ボードとEDKの特別パッケージなんて噂もあったので購入を控えていましたが、限定的なSDKでも良いかということで購入に踏み切ることにしました。

市場に出回るFPGA評価ボードの中ではかなり小さい部類に入ります。

従来の評価ボードにあるような機能がかなり盛り込まれています。
ソフトコアマイクロプロセッサを動作させる事を念頭に置いたDDR SDRAMもあります。

開発環境のセットアップ

開発環境のセットアップはXilinx社のツールに慣れている人であれば戸惑うことはありません。

が、このボードが初めてのXilinxという方は少し戸惑うかもしれません。

何せセットアップのドキュメントが・・・どこにあるの？という感じです。

参考までに幾つかのシーンをピックアップしてポイントを示しておきます。

まず、LX9 MicroBoardには開発ツールのライセンスが付いてきます。

これは「Spartan-6 LX9 MicroBoard Kit - ISE Design Suite: WebPack and SDK Device Locked, Node-Locked License」という名称が付けられています。

パッケージを開けると付いてくる「重要！(IMPORTANT!)」と書かれた養子に書いてあるコードがユーザ固有のライセンスコードです。これは間違っても捨てないように。

付属していたISEのバージョンは12.4でした。

インストールするエディションを選択する画面が出ます。

これは「ISE Design Suite : System Edition」が正解です。

インストールするオプションの選択が促されると思います。

私はとりあえず全部入れておきました。

LX9 MicroBoardにはRJ-45が付いています。

ネットワークを絡めた何かができるはずです。

インストーラもネットワークのあれこれに備えてネットワークパケットキャプチャツールのインストールを促してきます。

この後ライセンスを登録して完了です。

まず、Xilinx社のサイトで自分用のアカウントを取得しておいてください。

これは無償でできます。

ツールのインストールが完了するとライセンスマネージャが起動します。

ライセンスを登録する場合、以下のようにライセンスマネージャ経由でウェブサイトにアクセスすることで簡単に行なえます。

ログインしていない場合、ログイン画面が表示されます。

ログインするとライセンスを入れる画面がブラウザに表示されるはずです。

ここに箱に同梱されていたライセンス番号を入力し、「Redeem Now」を押します。

ノードライセンスの生成画面が表示されます。

ノードロックのハードウェア固有情報は「ディスク」と「ネットワーク」から選択できます。

過去にライセンスを取得した事がある場合、複数のノードが表示されますので、今回のライセンスを使って開発するマシンを選んで下さい。

生成が終わるとライセンスファイルがメールで送られてきます。

これを先ほどのライセンスマネージャで読み込んで完了です。

ライセンスの状態が気になればライセンスマネージャでいつでも確認することができます。

今回のライセンスには「Xilinx Software Development Kit」のライセンスも含まれるようです。

気になる人はこちらも起動して問題ないことを確認しましょう。

まとめ

今回は勢いで購入したLX9 MicroBoardの開発環境セットアップについて触れました。EDKのシュリンク版っぽいものは、デバイスロックだけが制限かと思っていました。ですが、実際にインストールしてみると１年の限定ライセンスのように見えますね。このあたりはどうなんでしょうか？個人的に期間限定ライセンスには何の魅力も感じないので少し気になります。

ライセンス周りは意外に面倒ですね。
このあたり、私は考えすぎるとやらなくなるので、細かいことを気にせずにザクザクやるようにしています。
今回の記事もかなり適当ですので、参考にする場合にはくれぐれも自己責任でお願いします。
何があっても責任は取れません。

Proteus 7のデモバージョンを試す（EAGLEの上にも10年）

2011-08-21T19:07:00.004+09:00

EAGLEの上にも10年

まだ日本国内でEALGEの知名度がそんなに高くなかった頃からのノン・プロフィット・ライセンス・ユーザなのですが、最近は色んな事を考えて他のCADかあるいはライセンス形態を変更しようと検討を進めています。

具体的には

作った基板を販売できるようにしたい。
階層化設計に対応したCADを使いたい。
もうちょっと楽に配線できたらなぁ。
ネットリストでPCB CADにデザインを渡したい！（どんな欲求だ！）
実はEAGLE・・・ちょっと設計が大きくなると重い。
その他。

など、どれも切実とは言えませんが、少し前に設計したARM Cortex-M3基板設計時に「もうちょっと楽したいなぁ。」というのが発端になっています。

EAGLEの気になるところ

どんな事がネックになったのかをちょっと整理してみましょう。
回路図はA3のシートにゆったり書いて8ページのデザインです。

気になる事の1点目はクロスリファレンスです。

複数ページに渡る図面で「いつも何か気になる事。」の1つはクロスリファレンスの扱いです。
現行のバージョン(バージョン5系)までのEAGLEにおいて、クロスリファレンスは「ULPでなんとかがんばりましょう。」というものです。ULPを使って最終的に仕上がる図面としては「それっぽく」なるのですが、所詮ULPで付けたクロスリファレンス、後からネット名を変えた日には即座に破たんです。本来であれば変更に追従して欲しいところです。

最近のバージョンでは、ネットにラベル名を付ける機能に「クロスリファレンスっぽいタグ」が選択できるようになりました。が、これは現状のバージョンでバスには使えませんでした。

次に気になるのはデザインの再利用性です。

一度設計してデバッグが完了した回路ブロックは、より大きなデザインに対しての単一モジュールとして再利用したいものです。しかし、EAGLEにそんな機能はありません。

例えば、「このオーディオ回路ブロックを再利用したいなぁ。」なんていう時、まぁなんというかコピーするしかないのです。で、よくある間違いが電源系だけ間違えたとか、そんな話です。そもそもコピーなんていうのは対処法としてお世辞にも良いと言える理由が見つかりません。

基板側は4層基板でデザインは小さい部類に入ります。

例えば、EAGLEで基板配線している時に気になるのは、DRCを通すまで重なりに気付かない事があるという点。CADにもよりますが自動的にピンなりビアなりを避けてルーティングして欲しいものです。最近はEAGLEにもFollow-me配線があるのですが、なんというかちょっと違うような気がしています。（適当な書き方ですいません。）

DRCを通さない事ありませんので良いと言えば良いのですが、本当は既存の配線に沿ってルーティングしてくれれば4層の基板を趣味とはいえ引くのに1週間もかかったりしないのでは？と考えたりしています。

Proteus 7

Proteus 7はhttp://www.labcenter.com/index.cfmが製造販売しているCADです。

スターターキットは150ユーロからと導入の敷居はかなり低そうです。

一部の機能に制限があるというデモ版をダウンロードできるようなので試してみる事にしました。

電気設計はISISという名称のツールを使います。

基板設計はARESというツールです。

基板設計側を見る

この手のツールは個人的に、電気設計側が良いと基板設計側がダメだったりとバランスが悪い印象があります。まずは基板設計側で思った通りに操作できるかどうかを確かめます。

黄色の矢印は「主にこっち側に配線が伸びているよ。」というものを示すもののようです。

ルーティングはルーティング用アイコンを選択してピンをクリックすれば始まります。

「おっと。意外にも良い感じだ。」なんてこの時点で感じました。

で、情けない話ですが・・・

引いたところでネット名が即座に確認できる！なんて感動してしまうわけです。

まぁ、EAGLEの常識がCADの常識なんてこれっぽっちも思っていないわけですが、それでも「なんだかなぁ、自分。」という感じです。

当然のようにデザインルールで定めた範囲で的確にルーティングさせるようになっています。

配線できない所には行かせません。

当然のように予めネットにつけておいたアトリビュートに従って配線幅も適切なものになるようになっています。EAGLEだと後から自分で修正したり、引く前に選択したりしていました。で、最後にDRCの結果を見て修正するなど・・・。これが時間がかかるのと神経質な操作になったりして意外にストレスになったりします。

電気設計側を見る

基板設計側が「パッ見て」良さそうなので電気設計側も見てみる事にしました。

既存の電気図面にシートを1枚追加して、コンポーネントを適当に配置し、配線してみます。

配線したネットにネット名を付けて「デザインエクスプローラ」なるものでネットの配線状況を確認してみました。

どこのCADとは言いませんがネットに名前を付ける程度で戸惑うようなユーザインターフェースになっているCADも少なくありません。まともに機能しないというのもその一つです。

ですが、少なくともISISにはそういった点は見つかりませんでした。

事前調査に進む為の第1関門突破といったところでしょうか。

そして、嬉しいのが階層化設計が表現できる機能。
回路ブロックを定義し、「Goto Child Sheet」でそのブロックに飛べるようになっています。

子シートに飛ぶと内部設計が表示されますね。

これが実現できているのですから、きっとクロスリファレンスもうまくやってくるでしょうと期待してしまいます。

いずれにせよ

そうは言ってもEAGLEは私にとって身分相応のCADで、費用対効果はこれまでの実績から十分なものと言えるでしょう。本当に小規模な設計であれば、道具として使えない事は全くありません。道具は使う人によって生きたり死んだりしますから、CADの選択が全てを決めるわけではないというのは言うまでもありません。

今回のProteus 7の評価は最初の一歩ですが、時間を見てもう少し触ってみたいものです。

番外編

このCADにはシミュレーション機能もあるのですが、これが気持ち悪い。

どうやって実現しているのかまだよくわかっていませんが、例えばuClinuxが走ります。

私個人的には「自分で作ったライブラリ類」でできない限り、この手の機能は「ふーん。」程度にしか見ないのですが、それにしても気になります。

3D表示はなかなか使えそうです。

設計基板にアクリルを付けてお洒落度アップ！「アクリ屋ドットコム」さんにアクリルを発注してみる。

2011-08-10T21:51:00.001+09:00

外装にも少しは気を配りたい

おもてなしの心は日本人の得意分野かと思っていましたが、コスト削減要求の嵐の中そんなことは忘れ去られてしまったかのように見える今日。
ちょっとした評価基板の天面にアクリル板なんかが載っていると思わず「おぉー。」なんて思ってしまうのも情けない話です。

例えば、Terasic Technologiesのボードなんかの仕上がりは、かなり私好みです。

それはともかく、今回設計したLPCXpresso Clockでは、予め簡単な外装を付ける事を前提に設計を進めていました。

アクリルなどで簡単な養生があるだけでも何かのメリットがあるわけです。

基板の隅々に埃が被るような事がない。
埃が被りにくいので「何か古臭くなったなぁ」なんて感じる事がない。
水滴が飛んでもある程度大丈夫。
少しおしゃれ。
その他。

少し無理矢理ですが色々なメリットが考えられますね。

アクリ屋ドットコムさん

基板製造が海外で数十ドルから出来るようになった今、相対的に外装にかかる費用は大きくなっていると言わざるを得ないのが現状です。

そんな中、国内で面白いサービスを展開されている企業があります。
私は今回「アクリ屋ドットコム」さんにアクリルの加工依頼をしてみました。

アクリル板加工でセミオーダー形式でウェブから注文ができるサービスを展開しています。
ちょっとした加工までをウェブから行う事ができ、その場で値段がわかるのが特徴です。

LPCXpresso Clockの場合

「アクリ屋ドットコム」さんのセミオーダーの場合、穴位置などの指定単位が0.5mm単位です。
また、アクリル端からの穴位置に若干の制約があります。

LPCXpresso Clockの場合、以下のようにして対応しました。

穴位置はアクリル板の端面からの距離で指定することになっている。
0.5mm単位のグリッドに載せると若干ずれる。
穴位置が許容される誤差に収まるようにアクリル板のサイズを調整する。

要するに穴位置がアクリル板の端からの位置で決まるので、アクリル板のサイズを調整して許容される範囲に穴位置を調整しようという対応です。（こんなのは機械屋さんから見ると最低だろうと思うのですが、私は機械に関して詳しいとは言えないのでよくわかりません。）

出来上がってきたアクリルを付けると以下のようになります。

基板だけの時と比べると、与える印象がまるで違いますね。

今回のアクリルパネルは一枚で約700円程度です。
基板の原価と同じくらいの費用が外装にかかるわけですが、実際に完成してみると良い効果を生み出していると言えるのではないでしょうか。

LPCXpresso Clockに部品を搭載して動作させてみる

2011-08-09T21:42:00.001+09:00

動作させてみる

先日到着したLPCXpresso Clock基板に部品を搭載してLED周辺回路の動作確認を行いました。
点灯させた状態で以下のようになります。

まだ基板だけの状態なのです。
これにアクリルパネルを取り付けて外装の完成となる予定です。

もちろんLPCXpresso IDEを使ったデバッグを行うこともできます。

LPCXpresso IDEでデバッグもできる他、外部電源で独立運転もできるように設計しました。
デバッグを楽しんだ後は普通に時計として使用する事ができるようになっています。

Eagle3D + POV-RayによるCGとの比較

折角なので先日Eagle3D + POV-Rayで作ったCGとも見比べてみましょう。

そっくりですね。
Eagle3D + POV-Rayでの確認は、なかなか有用そうです。

Eagle3D + POV-Rayをもっと活用してリアルな完成イメージ図を得る

2011-08-05T17:14:00.000+09:00

Eagle3Dって何だっけ？

Eagle3Dは、EAGLEで設計した基板データから写真で撮影したようなリアルな３次元CG画像を作る事のできるツールです。
実際に基板製造をする前に完成イメージ図が得られますので、好んで使用しています。

リアルな３次元CG画像を得るためには３次元モデルが欠かせませんが、EAGLEに標準で添付されているライブラリの多くに対応しているのもEagle3Dが人気の理由の一つになっています。

裏を返すと、標準で添付されていないような自作ライブラリなどの部品は、生成された３次元CG画像に含まれないことになります。
何を隠そう私も先日まで「面倒だなぁ。」とか「良いんですよ、基板の感じが掴めれば。」とか思う事にして、自作ライブラリに対するケアは全くしていない状態でした。
そして、自作ライブラリだけ歯抜けになっているとかっこ悪いので、「部品を載せない」設定にして出力です。

ですから、以下のように何か足りない寂しい出力になっていたわけです。

しかし、所詮は四角や丸の多い電子部品の３次元モデル。
POV-Rayのスクリプトを実装するのもそんなに難しいはずがありません。

基板だけの出力に甘んじている現状にも我慢できなくなってきたので「もっと活用してリアルな完成イメージ図を得る」という目標を立てて実践する事にしました。

Eagle3Dの処理構成

Eagle3Dの処理構成についておさらいしてみましょう。

大まかにみると２段階の構成になっていて、EAGLE上でPOV-Rayで実行するレンダリング用スクリプトファイルを生成し、POV-Rayで実際にレンダリングを実行するという形になっています。

整理すると

EAGLE側：部品のパッケージ名とレンダリング処理の関連付け。
POV-Ray側：レンダリング処理の実行。

ということになります。

コンポーネントの追加

EAGLE

Eagle3Dを展開するとulpディレクトリがあります。
この中にある3dusrpac.datというファイルがユーザパッケージ情報を定義することのできるファイルとして用意されています。
ここにパッケージ名とレンダリング処理を関連付けるための記述を1行追加します。

A-551UB:0:1:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:DIODE_LED_7SEG_A551UB(::

上記の場合、「A-551UB」というパッケージと「DIODE_LED_7SEG_A551UB」というレンダリング処理が関連付けられた事になります。

これでEAGLE側の準備は完了です。
早速Eagle3DのULPを実行してPOVファイルを生成します。

POV-Ray

POV-Ray側は指定されたレンダリング処理に対する実装が必要です。
Eagle3Dを展開したディレクトリにあるe3d_user.incがユーザ拡張用に設けられたファイルです。

先ほどDIODE_LED_7SEG_A551UBというレンダリング処理と結びつけたので、ここにマクロとして実装します。

#declare e3d_environment = off;

#macro DIODE_LED_7SEG_A551UB(value)

    // ピンオブジェクトを定義する。
    #local leg = object{
 cylinder {<0,-3,0>,<0,1,0>,0.25 texture{col_silver}}
    }

    // コーナーを作る。
    #local corner = object{
 box {<0,0,0><2.5,1,2.5> pigment{White}}
    }

    union{
 // ピンを配置する。
 object{ leg translate< -5.08,0,7.935>}
 object{ leg translate< -2.54,0,7.935>}
 object{ leg translate<     0,0,7.935>}
 object{ leg translate<  2.54,0,7.935>}
 object{ leg translate<  5.08,0,7.935>}
 object{ leg translate< -5.08,0,-7.935>}
 object{ leg translate< -2.54,0,-7.935>}
 object{ leg translate<     0,0,-7.935>}
 object{ leg translate<  2.54,0,-7.935>}
 object{ leg translate<  5.08,0,-7.935>}

 // 本体を作る。
 box {
     <-6.35,1,-9.5>,<6.35,8,9.5> pigment{White}
 }

 // ４つのコーナーを配置する。
 object{ corner translate<-6.35,0,-9.5>}
 object{ corner rotate<0,90,0> translate<-6.35,0,9.5>}
 object{ corner rotate<0,180,0> translate<6.35,0,9.5>}
 object{ corner rotate<0,270,0> translate<6.35,0,-9.5>}

 // 本体の情面に７セグメントLEDの画像ファイルを貼る。
 box {
     <-6.35,8,-9.5>,<6.35,8.1,9.5>
     pigment{
  image_map{png "a551ub.png" once}  rotate<90,0,0> scale<12.7,0,19> 
  // 左下に画像を貼ってから全てのオブジェクトを移動させて中心にもっていく。
  translate<-6.35,0,-9.5>
     }
 }
    }
#end

こんな風に２つのファイルを編集するだけで、手軽に自作コンポーネントに対する３次元モデルを生成できるようになります。
部品面の描画を記述するのが面倒なら、部品をデジタルカメラなどで撮影し、その映像を貼りつけるだけで構いません。

先ほどの例では以下のような画像を部品本体に貼りつけています。

上記の手順を経て得られた出力画像を見てみましょう。

これで先日までの基板だけの完成イメージよりもリアリティを感じられるようになりました。

動画

POV-Rayではレンダリング用のiniファイルを作ってアニメーションを生成するための複数画像ファイル生成ができるようになっています。

例えば、以下のようなiniファイルを作ってPOV-Rayで使用してみます。

Initial_Frame = 1
Final_Frame = 360
Initial_Clock = 0
Final_Clock = 360
Cyclic_Animation=off

ここでポイントとなるのは、POVファイルの変更です。
clockという変数は描画毎にカウントアップされる値で、これを基板の回転変数に入れる事で基板を回転させて見る事ができるようになります。
先ほどのiniファイルでは「初期クロック=0」、「最終クロック=360」としました。

今回はPCBをX軸を中心に回転させてみました。

画像は複数枚のBMPファイルになって出てきます。
これを動画に変換してみたものが以下です。

動画にすることで更に実在する物体として認識しやすくなりました。
基板を製造に出す前に「どんな感じになるのかなぁ。」と体感したい時に便利ですね。

更なる応用も可能

今回は手始めに自作部品に対するレンダリングについてのみ触れました。
実はPOV-Rayのレンダリングスクリプトをもっと有効に活用すれば、任意の表示パターンを作るようにできたりします。
これを使えば取り扱い説明書の画像を作ったり、オペレーションガイドのような動画を生成したりすることもできるでしょう。
使いこなせば従来ではできなかった品質をドキュメントの領域でも発揮できるかもしれません。

僕たちのファームウェア戦略 (LPCXpresso Clockを使って、組み込み機器開発特有の問題解決を楽しもう！)

2011-08-02T19:32:00.004+09:00

戦略なしではいられない

LPCXpresso Clockは、現状でほぼ全てのLPCXpressoにドッキングする事を考えています。
この時、LPCXpressoの各モデルに対するライブラリを個別に提供しても構わないのですが、管理や設計から見ると美しいとは言えません。

例えば・・・

「このウルトラミラクル輝度制御機能は全モデルに搭載されている機能なんだけど、あのモデルでは"ABC"になっていて、このモデルでは"DEF"になっている。」
「あぁ、そのモデルは全然保守されていなくて、別のインターフェースになっているんだ。」
「え？このモデルでしか動かせないハッピータイマー機能を加えたけどだめだった？」

など、実際の製品開発においては、シリーズとして相応しいインターフェースを提供しているのかなどの検討も欠かせないのです。
「あのモデルのためにABCインターフェースを追加したら、別のモデルで致命的な矛盾が生じた。」なんて笑うに笑えないわけです。

今回の設計に関して言うと、殆どの機能は共通なのですから、アプリケーションロジックは共通にしておきたいところです。そのためには、下層ライブラリを適切なインターフェースで切って、実体を抽象的に扱う事が欠かせません。これは今後触れていくであろう「僕たちのクロスプラットフォーム戦略」にも関連があります。

考えられる様々な要求を簡単に箇条書きにしてみましょう。

使いやすいライブラリを提供して欲しい。(ユーザ要求)
インターフェースの学習コストを最小限にしたい。(ユーザ要求)
アプリケーションロジックは共通化して、開発コスト対効果を最大限に高めたい。(ユーザ要求)
優先度の高いモデルや機能から実装して、要求に応じて他のモデルも開発したい。(開発者要求)
「私はCで書きたいんだ。」、「私はC++で書きたいんだ。」(ユーザ要求)
その他

他にも様々な要求が考えられるわけです。
要求は、顧客から来るもの、設計から来るもの、実装から来るもの、様々です。

いずれにせよ言えるのは重複するような内容が物事に含まれている場合、何かと問題が生じるという事実です。

ここを美しく解決する事が「僕たちのファームウェア戦略」であり、１つの製品設計で複数のラインナップを揃える事のできる土台となるわけです。

設計の土台を作る(分割し、整理し、統治する)

では、具体的にどうすれば良いのかという話になります。
基本的には「分割し、整理し、統治する」という流れです。

分割(あるいは統合)

同じものと違うものを分割します。あるいは同じものを統合します。
分類に迷ったら、基準となる視点を定めて分割するか統合するかを判定します。

例えば、LPCXpresso Clockの場合、分割可能な要素の例には以下の２つがあります。

LPCXpresso Clock基板固有の機能。 (時計のインターフェースを実現するハードウェア。)
ドッキングさせるLPCXpresso基板固有の機能。 (時計の制御を実現するハードウェア。)

簡単ですね？
ドッキングして使用するのですが、2つの基板の役割は明確にわかれています。

LPCXpresso Clock基板+LPCXpresso基板=LPCXpresso Clockですから、上記の視点は非常にシンプルなものです。
(一見下らない要素を大げさに取り上げているように見えるかもしれませんが、これが後々の設計と綿密な関わりを持ってきます。)

整理(あるいは破棄)

分割した要素の詳細を整理します。
詳細といっても実装レベルの詳細ではなく、「だいたいこんな感じかなぁ？」程度の整理で構いません。

例えば、LPCXpresso Clockの場合、以下のような感じです。

LPCXpresso Clock基板

7セグメントLED (出力)
赤外線受信回路 (入力)
照度センサ (入力)
スイッチ (入力)

LPCXpresso基板

GPIO (入出力)
RTC (入力) - 無いモデルもある。

統治(あるいは留保)

統治の段階でインターフェースを定義してみます。

Cならヘッダファイルにインターフェースを定義します。
C++ならヘッダファイルにクラスを定義します。

この時点で統治できないような内容があっても構いません。
意味不明な物体は、この時点で無理して統治する必要はありません。
少し変な名前を付けて残したりすれば良いです。

これは検討の方向性を確認するためのプロトタイプ実装です。
実際に動作させるところまで持っていく必要はありません。

これが「僕たちのファームウェア戦略」における実用的な出発点です。

そ・れ・で・？

子供騙しのような整理をしてどうなるのか？と感じる方もいるでしょう。
でも、上記の３ステップの整理をするだけで

システムが何を提供しようとしているのかが明確になる。
シリーズ並行展開の視野を身につける事ができる。
自身の設計が何のプラットフォームに依存しているのかを明確に認識できる。
その他

様々な効果が得られます。

今回は「僕たちのファームウェア戦略」の出発点を示し、その効果について概略を解説しました。

EAGLEで設計した基板の製造をFusion PCB Serviceに頼む。(EAGLE用の一発生成CAMファイルや、ガーバデータの検証方法もあります。)

2011-07-23T21:11:00.002+09:00

概要

LPCXpresso Clockを設計して早くも1週間が経ちました。
その間に色々な試行錯誤を経て若干の機能追加をしたりしました。

今回の基板(LPCXpresso Clock)の製造は、激安基板製造でお馴染みのFusion PCB Serviceに頼むことにしました。

EAGLE用の一発生成CAMファイル

EAGLEでガーバを出力する場合にはCAMプロセッサというものを使います。

まずは基板設計側の画面を表示します。

CAMプロセッサのアイコンをクリックします。

CAMプロセッサのダイアログが表示されます。
ここでCAMプロセッサに対する作業を定義したファイルを読み込みます。

ここでは、Funsion PCB Service向けのCAMプロセッサ用ファイルを自作してガーバ出力作業に使用することにしました。

名付けてFusionPCB-gerb274x-excellon.camです。

それでは読み込んでみます。

Fusion PCB Serviceでは生成したガーバデータの拡張子名が指定されています。

自作したCAMプロセッサ用ファイルには以下の特徴があります。

Fusion PCB Serviceで指定された拡張子名で自動生成してくれるようにしました。
CAMプロセッサジョブ名は、Fusion PCB Serviceで指定された名称にしてあります。
ドリルデータも一緒に生成するようにしました。

「Process」ボタンを押したら出力されたファイルをFusion PCB Serviceに書かれた内容で照合します。

ドリルラックファイルなどは不要なのかもしれませんが、添付しても問題ないでしょう。

出力されたデータを確かめる

この手の作業は、複数のツールを組み合わせたダブルチェックが欠かせません。
出力したデータファイルのみで(←ここ重要)期待した結果が得られるのか？が確認するポイントとなります。

私は工場に提出するガーバデータの確認をGraphiCode社のGC-Prevueで行っています。
早速先ほど出力したデータファイルを開いてみましょう。

「ファイル」メニューから「インポート」を選択します。

GC-Prevueのインポート機能は非常に手軽で、Ctrlキーを押しながら所望のファイルを選択することで複数のファイルを一括読み込みすることができるようになっています。

インポートを実行するとファイル情報の検証が行われます。

その後、ツールの管理テーブルへのマッピングが表示されるようになっています。

最後にファイル毎のインポート結果の詳細が示されるダイアログが出現します。
ここで表示色や形式などを選択する事ができるようになっています。
この時点でお気に入りのツールと表示色をあわせると見やすいですね。

ガーバデータは複数のファイルで1つの基板の情報を管理しますので、「間違って同じデータを違う拡張子で送っちゃった！」とか、「全然関係ないデータを送っちゃったよ！」なんてあるかもしれません。

読み込み時に画面で確認しながら読み込めるGC-Prevueはそういう意味で非常に便利です。
例えば、シルクレイヤを見てみると以下のようになります。

こちらは部品面のガーバ。
ベタ面の描画が粗いように見えますが、拡大すればきちんと表示されます。

レイヤー毎の表示・非表示は画面左側のツリー表示の部分で切り換えることができます。

リソース

EAGLE用のFusion PCB Service向けCAMプロセッサファイルはこちらからダウンロードできます。
自己責任でお使い下さい。

まとめ

今回はEAGLEで設計した基板の製造をFusion PCB Serviceに頼む過程を示してみました。

LPCXpresso Clockの設計

2011-07-18T20:21:00.003+09:00

概要

LPCXpresso横浜お楽しみ部会(LPCXpressoでモクモクしよう！)は、参加者の方々が各自で取り組んでいることを持ち込んでモクモクと何かをしようという会合ですが、具体的なTODOがない方にとっては参加しづらいものです。

そこで、今回はLPCXpressoを手にしてみたけど具体的なTODOが思いつかないなぁという方でも参加しやすいような小道具を考えてみました。

名付けて「LPCXpresso Clock」です。
先の部会に参加される方の中で、希望される方に基板を無償で配布します。（先着５名様）

LPCXpresso Clockの特徴

LPCXpresso Clockの特徴を以下に示します。

リアルLPCXpressoサイズ。
製作後は完全なスタンドアロン動作が可能。
見やすい7セグメントLEDによるディジタル表示時計。
4つの入力スイッチ付き。
LEDのダイナミック表示を学びたい方に最適。

LPCXpressoに合体させるだけでオリジナルクロックの出来上がりという算段です。
LPCXpressoを使って小規模組み込みシステム開発を楽しんだ後はリビングのおしゃれ時計に変身するという1粒で2度美味しい作戦です。

以下は完成した時のイメージ図です。

現在のところ基板設計の初版を終わらせた状態。

LPCXpressoはCPU周辺回路が完成しているので、こういった試作基板は簡単に設計が済んでしまいます。
この回路も約1時間ほどで電気設計と基板設計が完了しました。
忙しい毎日でも時間を作って試してみることができるのが嬉しいところ。

単なるディジタル時計ですが、自分でプログラムを組めるし、基板外形はLPCXpressoとピッタンコ同じで、少しカッコイイ！・・・というのが目論見です。

今回は「リアルLPCXpressoサイズ」に（だけ）こだわって設計しています。
完成したらどんな風になるのか楽しみです。

備考

この基板はLPCXpresso横浜お楽しみ部会(LPCXpressoでモクモクしよう！)にも持っていこうと考えています。
興味のある方は@shintamainjpまで御連絡下さい。

LPCXpresso横浜お楽しみ部会(LPCXpressoでモクモクしよう！)

2011-07-03T21:24:00.001+09:00

LPCXpresso横浜お楽しみ部会(LPCXpressoでモクモクしよう！)は横浜近郊に在住していて、「都内に出てモクモクする気力はないけれど横浜なら行ってもいいかな？」という方のためのLPCXpressoモクモク会です。もちろん都内からの参加も歓迎です。

詳しくはATNDで！
http://atnd.org/events/17595

LPC11U14 LPCXpressoを使ってUSBを研究しよう！ - USB研究部会 - (LPCXpresso週間)

2011-07-03T19:39:00.006+09:00

USB! USB! USB!

以前の記事、LPCXpressoの放置を防ぐお勧め取り組み方法(LPCXpresso週間)では、放置を防ぐアイデアの１つとして「具体的な目標に繋げる」というものを挙げました。
今回はLPC11U14 LPCXpressoを使って、USBを研究する例を取り上げてみましょう。

LPC11U14の概要

LPC11U14は最大クロック周波数50MHzのARM Cortex-M0をコアに持つNXPセミコンダクターズ社のプロセッサです。
LPC11U14の場合、内臓フラッシュは32KB、SRAMは6KBあり、そのうち2KBがUSB用となっています。

GPIOは40本、ADCも8チャンネル搭載されており、USBも接続できるため様々な応用例が考えられます。

まずはデータシートからブロック図を見てみましょう。
おっと、データシートはまだドラフトのようですね。

USARTやI2C、SPI(SSP)はもとより、SMARTCARD INTERFACEやPMU(Power Management Unit)が搭載されています。
PMUはLPC11U14では特徴的な機能の１つと言えそうです。

メモリマップは以下のようになっています。

メモリマップを見てもわかるように6KBのSRAMは連続した領域ではなく、2KBのUSB用RAMと残りの4KBに分かれていることがわかります。

で？USBは？

ひとくにちUSBといってもホストやらデバイスやら色々あるわけです。
LPC11U14で言うUSBは「USB 2.0デバイス」を指します。

LPC11U14に搭載されたUSB 2.0デバイス・コントローラの機能は以下の通りです。

USB 2.0フル・スピード・デバイス・コントローラ搭載。
1つのコントロール・エンド・ポイントを含む、10個の物理(5個の論理)エンド・ポイントをサポート。
シングル・バッファリングとダブル・バッファリングをサポート。
非コントロール・エンド・ポイントはそれぞれ、バルク、インタラプトかアイソクロナス・エンド・ポイントをサポートします。
USB動作におけるディープ・スリープ・モードからのウェイク・アップとリモート・ウェイク・アップをサポートします。
ソフト・コネクトをサポートします。

LPC11U14のUSBハードウェア

ここで、ハードウェア・ブロック図を見てみましょう。

アナログ・トランシーバが内臓されているおかげで、外付けデバイスなしでUSB接続ができます。
DMAエンジンはAHB_MASTERに接続されています。

SERIAL INTERFACE ENGINE(SIE)はUSBプロトコル層をハードウェアで実現したものです。
このため、ソフトウェアの介在なしにUSBプロトコル層を処理できるようになっています。
USB用RAMとUSBバスにおけるエンド・ポイント・バッファ間のデータ転送はこのハードウェアによって処理されます。

LPC11U14のUSBソフトウェア

エンド・ポイント・リスト・ポインタはアドレス0x20004000にあるUSB用RAMブロック内を指すようにします。
データはどのSRAMにも格納することができます。

これらを図示したのが以下の図です。

上記のようにレジスタにアドレスを設定しておけば、SRAMにデータが格納するまでを勝手にやってくれるという仕組みです。
このUSBコントローラにはUSB IRQ割り込み(USB_Int_Req_IRQ)とUSB FIQ割り込み(USB_Int_Req_FIQ)の2つの割り込み線が存在します。
リクエストの処理は通常これらの割り込みを使って処理することになります。

どこから手を付ける？

「じゃあ、始めましょう！」と言って笑顔でコーディングを始めても良いのですが、出来上がるまでに何回くらい日が暮れるのかわかりません。

幸いにもNXPセミコンダクターズがLPC11U14で使えるUSB HIDのサンプルを提供してくれています。
今回はこれを使ってUSBの研究を始めることにします。

情報が豊富で頻繁にアップデートされているサポートサイトは http://ics.nxp.com/support/lpcxpresso/ にあります。

上記ページにある「LPCXpresso USB HID Example Project for LPC11U14」を選択してクリックして下さい。
アーカイブされたプロジェクトをダウンロードすることができます。
アーカイブされたプロジェクトの使い方は私の記事「LPCXpressoのサンプルを使ってみよう(LPCXpresso週間)」も参考にして下さい。

先ほどのアーカイブ・プロジェクトにはCMSISが含まれていませんが、実際には必要です。
これも http://ics.nxp.com/support/lpcxpresso/zip/CMSISv2p00_LPC11Uxx.zip からダウンロードして読み込んでおきましょう。

ビルドしたバイナリを書き込んで、LPC11U14側に接続されたUSBコネクタに接続するとUSB入力デバイスとして認識されることがわかります。

デバイス・ディスクリプタのソースコードと見比べてみても、ふむふむ確かに同じだということがわかると思います。

USB HIDサンプル・プロジェクトの中身

今度はUSB HIDサンプル・プロジェクトの中身について調べてみます。
まずは「一体このサンプルは何をすることができるのか？」興味のあるところです。

HIDと言っても色々あるので、一体何と主張しているのかを調べます。
これはディスクリプタを見ればすぐにわかるはずです。

キーボードかマウスかな？と思いましたが、両方外れでした。
HID_PROTOCOL_NONE(値：0)が指定されています。

では、具体的にどんな実装になっているのかプロジェクトからdemo.cを見てみましょう。
demo.cのGetInReportとSetOutReportはリクエストがあった時点で呼ばれる処理関数です。
これを見る限り1ビットの入力と4ビットの出力をサポートしているようです。

1つずつ調べていくと色々なことがわかってきます。
楽しいですね。

やりたいのはPCとの連携(USBなんだから)

さて、先ほどのSetOutReportに気になる記述があります。

/* port1, bit 14~17 are used as LED indication from
HID utility. */

HIDユティリティとは何だ？ということで調べてみました。
が、それが何を指すのかいまいちよくわかりません。

今、非常にやりたいのはこの独自デバイス(今は評価基板ですが)をPCから制御できるようにしたいわけです。

実はWindows Driver Kit (WDK)にUSB HIDクライアントのサンプルがあります。
今回はターゲットがUSB HIDとして動作しているので、デバイスドライバを開発する必要はありません。

今回はUSB HIDクライアントのサンプル目当てでWDKを使います。

まずは Windows Driver Kit (WDK) をダウンロードします。(2011/07/03現在、バージョンは7600.16385.1 でした。)
ダウンロードしたisoファイルに含まれるセットアップを実行します。
isoファイルをファイルシステムをマウントするツールもあるのですが、そのツールの信頼性を確認したりするのが面倒なので私はCD-Rに焼いてから実行しました。

次に VisualStudio 2010 Express から Visual C++ 2010 Express をダウンロードします。

VisualStudioも通常通りインストールしておきましょう。

次にWDKに含まれるHIDのサンプルをビルドします。
USB HIDのサンプルは幾つかあります。
今回は C:\WinDDK\7600.16385.1\src\hid\hclient を試します。

コンソール画面が出ます。
先ほどのディレクトリにcdしてbuildを実行します。

これで hclient なるサンプルのビルドが完了しました。
ターゲットディレクトリの下を見るとディレクトリが生成されていると思います。
その中の hclient.exe を実行して下さい。
以下のような画面が現れます。

さて、LPC11U14の入力ポートの状態をこのクライアントアプリケーションで見てみましょう。
まずは、接続したLPC11U14を探し出します。

見つかったら、VID、PIDを確認して、同じVIDとPIDを持つデバイスをSample HID client appのウィンドウ上で探します。

これで準備ができました。
早速ポートの値を読んでみましょう。

ウィンドウにある「Blocked Read Data」を選択します。

以下のようなダイアログが出現します。
このダイアログの「連続読みだし」ボタンを押すとデバイスからのブロック・データ読みだしが実行できます。

それではLPCXpressoの入力ポートの状態を変化させてみましょう。
基板上にある「P0_1」ポートに対して入力を与えると、上記のダイアログのように出力内容が変化します。

要するにターゲットのHIDがホスト上のアプリケーションの要求に応答してポートの状態を返しているのです。

Sample HID client appはMicrosoftからソースコードが公開されているアプリケーションで、今回は提供されているサンプルをそのまま使いました。
この中で使われているAPIを調べる事で、自分のデバイスに対する自分だけのライブラリやアプリケーションを仕立てることも可能になります。

まとめ(何が揃ったのか)

我々は、LPCXpresso評価基板１つの投資で以下の物を手に入れました。

自由にいじれるUSB HIDのデバイス側。
自由にいじれるUSB HIDのホスト側アプリケーション。

マイコンの世界でクローズするのではなく、今回のようにアプリケーションを組み合わせることで沢山の応用例に発展させることができるようになります。

デバイス・ドライバを開発することなく、独自のUSBデバイスを接続できる手軽さは、かなり魅力的です。また、今回のようにホスト側もターゲット側も自由に改造して楽しむことができますので、USBをもっと身近に感じてみたいエンジニアにとっては格好の材料となりそうです。

皆さんも是非「USBは難しそう」と思わずに気軽に挑戦してみませんか？

他にどんな情報が必要ですか？

何か必要な情報があれば、本家も訪ねてみてください。

LPCXpressoのサンプルを使ってみよう(LPCXpresso週間)

2011-07-03T06:34:00.000+09:00

はじめに

LPCXpressoを始めた人にとって、「IDEが立ち上がった後どうすれば良いか？」は大きな問題です。
ここでは、プリインストールされたサンプルプログラムを読み込んで実行するまでをご紹介します。

プロジェクトの読み込み

LPCXpresso IDEには便利な「Quickstart Panel」というものがあります。
LPCXpresso用の専用パネルで、カテゴリ別に操作可能な項目が並べられています。

今回はここから、アーカイブされたプロジェクトの実行機能を試してみましょう。
実はLPCXpresso IDEをインストールすると幾つかのサンプルプログラムが含まれています。

Windowsにインストールした場合、通常はシステムドライブの直下にnxpというディレクトリを作ってインストールしていると思います。この中に含まれるLPCXpresso IDEのExamplesディレクトリがサンプルが含まれるディレクトリです。

ファイルを選択後にFinishボタンを押すとプロジェクト画面にプロジェクトが出現します。

プロジェクトのビルドと実行

それではさっそくプロジェクトをビルドしてみましょう。

以上でサンプルプロジェクトを実行するための準備ができました。
早速LPCXpressoを接続します。

初回接続時にはドライバが自動的にロードされると思います。

「Quickstart Panel」は状況に応じて表示内容や操作可能な項目が変化する仕組みです。
サンプルプロジェクトを使ってデバッグを実行する時には以下のようにします。

Windowsの場合、ファイアウォールに関する警告が出るかもしれません。
この時には「アクセスを許可する」を選択して下さい。

これでめでたくソースコード表示付きのデバッグが楽しめます。

デバッグしてみる

ソースコードをステップ毎に実行したい時には・・・

こんな風に簡単にステップ実行できます。

続けて実行したい場合には、「Resume」を選択します。
通常の実行に近い形で実行することができます。
この時、ブレークポイントを設定してあれば、そこで停止させることができます。

デバッグを終了したい時には「Terminate」を選択して下さい。

まとめ

前回のLPCXpressoのライセンス登録方法(LPCXpresso週間)に続き、初めてマイコン開発される方のためのコンテンツとしてサンプルプロジェクトの実行について触れてみました。

LPCXpressoは3千円ほどで購入できるARMマイコンが搭載された評価基板です。
みなさんも今年の夏休みはLPCXpressoで何か新しいことに挑戦してみませんか？

LPCXpressoのライセンス登録方法(LPCXpresso週間)

2011-07-02T19:35:00.000+09:00

概要

LPCXpressoは低価格(3千円程度)で購入できることから、中学生、高校生など、エンジニアの卵達にも教材としてもお勧めしたい一品です。

このIDEですが、単にインストールした状態では8Kバイトを超えるコードを生成実行することはできません。例えば、mbedに搭載されているプロセッサLPC1768の場合、512KBのフラッシュロムを持ちますから、単純計算で1/64しか楽しめないのです。

しかし、ライセンス登録するだけで128Kバイトまでのコードを生成実行することができるようになります。

先の例ですと1/2まで楽しめるようになるわけです。

エンジニアの卵達の中には、英語がネックになってライセンス登録を躊躇しているかもしれません。
ということで、今回はライセンスを取って128KBまでのコードに対応できるようにしましょう。

初回起動時のメッセージ

初回起動時、ライセンス登録が行われていない事を示すダイアログが表示されます。

これには

未登録LPCXpressoは評価目的のみで使用可能であること。
登録とアクティベートによって上記制限が取り除かれること。

と書かれています。

ライセンスの登録方法

まずはシリアル番号を生成します。

「Help(ヘルプ)」メニューから「Product activation(製品活性化)」を選択します。
そこにある「Create Serial number and Activate...(シリアル番号の生成と活性化)」を実行します。

以下のようなダイアログが表示されます。
ここに表示されたSerial number(シリアル番号)は、LPCXpresso IDEが自動的に生成したシリアル番号です。
このシリアル番号を選択してCtrl + Cなどで、クリップボードにコピーしておきます。

Copy Serial Number to clipboard(クリップボードへシリアル番号をコピーする)にチェックを付けておけばOKボタンを押した時にクリップボードにシリアル番号を自動的にコピーしてくれます。

次にcode_redのサイトにログインします。

ログイン後にメニューにある「My Registrations(登録)」を選択します。

「Enter serial number here(シリアル番号をここに入力)」と表示されています。
ここに先ほどコピーしたシリアル番号をペーストします。

シリアル番号をペーストしたら「Send me my activation code(活性化コードを送る)」ボタンを押します。

code_redのサイトに登録してあるメールアカウントに活性化コードが送信されます。

英文のメールですので、日本国内のメールサービスの中には誤ってスパムメールとして識別されてしまうかもしれません。

メールの中にある「Your activation code is:（あなたの活性化コードは：）」の下に書いてある文字列が活性化コードです。

「Help(ヘルプ)」から「Product activation(製品活性化)」を選択し、今度は「Enter Activation code(活性化コードを入力)」を実行します。

ダイアログが表示されますので、先ほどコピーした活性化コードをペーストして下さい。

活性化コードを入力してOKボタンを押すと製品活性化が完了します。

以上でめでたく128KBまでのコード生成とデバッグができるようになりました。

まとめ

今回は、エンジニアの卵達にも気軽に使ってほしいとの思いで、ライセンス登録について触れてみました。

LPCXpressoの放置を防ぐお勧め取り組み方法(LPCXpresso週間)

2011-06-25T18:57:00.001+09:00

購入後に放置してしまいがちな評価ボード

評価ボードの類は書籍などと同様で取り組むための時間の捻出が欠かせません。
購入したものの部品箱の奥底に埋もれてしまう事はよくあることです。

ありそうな理由を挙げてみましょう。

本当に忙しくて時間を捻出できない。(それって本当？)
購入した時点で興味を失ってしまった。(何がしたかったの？)
LEDをチカチカさせた後、どうして良いかわからない。(いかにもありそう。)
XXXを試したら興味を失ってしまった。(そのXXXを試す事が目的なら良いけど・・・。)

流石に沢山の人が毎年同じようなループに陥るのは地球資源にも優しくありません。
まず、上記のようになってしまう原因を探ってみましょう。

自分のためになる何かを考える

マイコン評価ボードは「そのマイコンを使ってみる」というところの主眼を置くと、ほとんどの場合触らなくなってしまいます。その触らなくなる瞬間までに何かが得られれば良いのですが、用意された環境を実行して終わりになってしまっては勿体無い限りです。

そこで、評価ボードを使うということに必然性のある理由を追加します。
例を挙げてみましょう。

この評価ボードを使ってネットワーク機能の実装方法を習得しよう。
この評価ボードを使ってUSBに関する理解を深めよう。
この評価ボードを使ってCANに関する理解を深めよう。
この評価ボードを使ってOSをポーティングし、アセンブラやOSに関する理解を深めよう。

「この評価ボードに搭載されたXXXというマイコンを使う」というだけでは漠然とした目的になってしまいがちです。これでは忙しい毎日の生活の中で時間の捻出に繋がる動機を生み出せません。

そこで、各自の「最終的に実現したいこと(学習のターゲット)」を要素として加えることで具体的な目標にします。
これにより時間の捻出をしようという動機に繋げるという仕組みです。

例えば、上記は「FATファイルシステムの動作を確かめればそれで良い。」という方向で使用した例です。（ぐちゃぐちゃですが、きれいに実装することが目的ではないので気にしません。）

LPCXpressoがなぜお勧めなの？

単に「マイコンを使う」という視点で見た場合、もっと他に楽しいボードが沢山ありそうです。
LPCXpressoをお勧めするのは、

「具体的な目標」に適切なボードが存在。
開発環境のセットアップに比較的容易。
実現したいことに対する投資としては安価。
可搬性に優れた設計。
ターゲット回路構成がシンプル。

など妥当な理由が存在するからです。

例えばLPCXpressoの場合であれば、以下のような選択肢が考えられます。

最終的に実現したいこと (学習のターゲット)	ボード
ネットワーク	LPC1769 LPCXpresso
USB	LPC11U14 LPCXpresso
CAN	LPC11C24 LPCXpresso
OS	LPCXpresso全般

組み込みエンジニアとしてネットワークやUSB、そしてOSに関する学習は外したくないところです。
車載系装置のエンジニアならばCANも加わることでしょう。

こんな風に、最終的に実現したいことを学習のターゲットとして設定し、LPCXpressoを購入することで、学習への第１段階に到達することができるのがLPCXpressoをお勧めする１つの理由です。

もし、ご自宅で眠っているLPCXpressoがあれば、視点を変えて再度取り組んでみませんか？
次回以降は環境の構築と具体的な学習への取り組みについて触れて行こうと思います。

LPCXpressoを選ぶ(LPCXpresso週間)

2011-06-24T05:04:00.003+09:00

色々あるけど全部一緒でしょ？

前回の記事で現状で６つのLPCXpressoが存在することをお伝えしました。
実は、単に搭載されているプロセッサが異なるだけというわけではありません。

モデルによって搭載されている外部デバイスが異なったり、興味深い工夫が施されていたりします。今回はそれらを１つずつ見て行くことにしましょう。

LPC1769 LPCXpresso

現在のラインナップでの兄貴分と言えるのがLPC1769 LPCXpressoです。
このボードにはイーサネット物理層デバイスも搭載されています。
要するにRJ-45コネクタを外部に接続するだけでネットワーク機能を試す事ができます。
搭載されているデバイスはSMSCのLAN8720Aです。
ボード上にはネットワーク動作確認用のLEDも搭載されています。

回路図から少し抜粋してみます。

LAN8720AとLPC1769との間は、RMII(Reduced Media Independent Interface)で接続されています。RMIIは、主にMII(Media Independent Interface)の接続端子数を削減するために作られたものです。この辺りは興味深い事が沢山ありますので、色々と調べてみると面白そうです。

また、EEPROMも搭載されています。

I2Cペリフェラルを使ってみたい人は、このボード１つ購入するだけで試す事ができます。

LPC1343 LPCXpresso

幾つかのデバイスが搭載されていたLPC1769 LPCXpressoと対象的なのがLPC1343 LPCXpressoです。
ターゲット側の回路図を見てみましょう。

デバイスに接続されているのはLEDのみです。

LPC1227 LPCXpresso

LPC1227 LPCXpressoはパッと見ると何も面白くないのですが、中々興味深い工夫が施されています。
その部分を回路図から抜粋します。

低消費電力アプリケーション向けに意図されている事もあって、この評価ボードで簡単に消費電力を計測できるように意図されています。

チカチカさせたい人のためのLEDももちろんあります。

LPC11C24 LPCXpresso

LPC11C24 LPCXpressoのターゲットにはCANが実装されています。
そうです。LPC11C24のCはCANのCなんです。

この評価ボードでお手軽にCANが試せると言うわけです。

LPC11U14 LPCXpresso

LPC11C24 LPCXpressoのCはCANのCでした。
このLPC11U14 LPCXpressoに搭載されているデバイス、LPC11U14のUは何でしょうか？
答えは・・・

USBなのです。
LPC11U14 LPCXpressoにはターゲット側にUSBコネクタまでが搭載されています。
小型アプリケーションをプロセッサで実現したい時にUSBデバイスとして扱いたい事があります。
そんな実験にもってこいなのがLPC11U14 LPCXpressoというわけです。

LPC11U14 LPCXpressoの回路図にも低消費電力アプリケーション向けを意識した工夫を見つける事ができます。

LPC1114 LPCXpresso

LPC1114 LPCXpressoはC(CAN)もU(USB)もない普通のLPC1100シリーズのデバイスです。
回路図にはLPC1343 LPCXpressoとの互換性に関する配慮がされています。

今回のまとめ

一口にLPCXpressoと言っても、ご覧の通りデバイスの特徴に合わせてちょっとした工夫が施されているのがLPCXpresso評価基板の特徴です。(LPC1343 LPCXpressoやLPC1114 LPCXpressoでさえも、際立った特徴を持たせないのが特徴だったりします。)

LPCXpressoには沢山の種類があってどれを選んで良いのかわからなくなりそうですが、実際にやってみたい事や評価してみたい事を思い浮かべて回路図を眺めてみると、「これかな？」という候補が浮かんできたりします。

是非みなさんも「これがやってみたい！」ということを頭に思い浮かべて、モデル選択を楽しんでみませんか？
全ての回路図はボードを設計されているEmbedded Artists社のサイトからダウンロードすることができます。

参考までに簡単な比較表を用意しました。

名称	搭載プロセッサ	シリーズ	SRAM[KB]	Flash[KB]	最大クロック周波数[MHz]	デバッグLED
LPC1114 LPCXpresso	LPC1114	Cortex-M0	8	32	50	PIO0_7
LPC11U14 LPCXpresso	LPC11U14	Cortex-M0	6	32	50	PIO0_7
LPC11U24 LPCXpresso	LPC1124	Cortex-M0	8	32	50	PIO0_7
LPC1227 LPCXpresso	LPC1227	Cortex-M0	8	128	45	PIO0_7
LPC1343 LPCXpresso	LPC1343	Cortex-M3	8	32	72	PIO0_7
LPC1769 LPCXpresso	LPC1769	Cortex-M3	64	512	120	PIO0_22

LPCXpressoを皆でいじり倒そう！(LPCXpresso週間)

2011-06-22T06:35:00.002+09:00

LPCXpresso週間のイントロダクション

ここ最近Embedded Artists社のLPCXpressoシリーズの動きが活発です。
気付いたら６つものプロセッサから選択できるようになっていました。

そこでCuBeatSystemsとしても何かやろうということで、「LPCXpressoを皆でいじり倒そう！」と題してLPCXpresso週間を始めることにしました。

8ビット、16ビットマイコンを使っているけれど、ARMマイコンにも興味がある。
とりあえずARMマイコンを使っているけれど、もっと中身を知りたい。
その他。

色々な方に楽しんで頂けるようなメニュー構成で進めたいと思います。

LPCXpressoって何？

事前知識の無い方に「LPCXpresso」と言っても何が何だかですので、簡単に特徴を整理しておきましょう。

NXPセミコンダクターズ社のARMマイコンが搭載された評価ボードです。
デバッガとターゲットが１つのコンパクトな基板になっています。（持ち運びが便利です。）
パソコンのUSBポートに接続するだけで使えます。（どこでもデバッグが楽しめます。）
国内でも秋月電子通商、マルツパーツ館などから容易に購入できます。
評価ボードの部類ではかなり安いです。（３０００円前後）
ダウンロード可能な開発環境が便利です。（Windows, Linuxで使えます。）
お手元のお気に入りな開発環境も使用可能です。
FreeRTOSやTOPPERS/ASPなどの動作も可能。

近年、多くのマイコン評価ボードが出現しています。
その中でも、ARM Cortex-M0やARM Cortex-M3を試すならLPCXpressoはかなりお勧めの選択肢です。

インチキ・セレクション・マップ

今回は私の体験を基にしたインチキなセレクション・マップを作ってみました。

LPCXpressoやmbedが手元にあると「ちょっと何かを試したい時」に便利です。
事前評価などでいちいち基板設計する必要もありません。
また、価格も３０００円前後と安く、気軽に様々な事を試す事ができるのも嬉しいポイントです。

次回以降はその魅力に触れながら様々な活用方法について触れていきたいと思います。

フリスクJTAGデバッガーをデバッグする（またバグを・・・編）

2011-06-20T21:49:00.002+09:00

先の記事でフリスクJTAGデバッガーのデバッグを始めたわけですが、実は「これだ！」と思っていたSI/WU信号をVCCIOに釣っても現象は変わりませんでした。

涙ぐましい改造をしてみましたが・・・。

「他にも問題が・・・」と思い回路図を見てみるとさらに怪しい所がありました。
この基板にはEEPROMとしてマイクロチップテクノロジー社の（←ここ大事です。理由は追記に。）93C56が搭載されています。

まさか８ピンのデバイスで接続の誤りなんて・・・とスルーしていました。

まずはデータシートからピンの概要を見てみましょう。

6ピンを見て下さい。
NCと書いてあります。

NCはNo Connectの略で・・・まぁ、「何も繋がないでね。」というピンです。
言うまでもなく・・・。

それでは回路図を見てみましょう。

あぁ・・・。
VCCに繋がれています。

これも何と言いますか、現象に関わらず修正した方が良さそうです。
少なくともデータシートの指示と実装が異なります。
(それとも何か理由があるのでしょうか？)

試しに6ピンをVCCから切り離してみましたが、相変わらず現象は収束する気配がありません。
うぅ。悔しい・・・。

こうなったら意地でも原因を突き止めたくなってきました。

2011/06/21追記：
93C56という型名の付いたデバイスは少なくともMicrochip Technology、ST micro、ATMELから出ているようです。6ピンの扱いは各社のデバイスによって異なるように見えます。

フリスクJTAGデバッガーをデバッグする（問題のあたりを付ける編）

2011-06-20T00:14:00.001+09:00

前回までの記事でフリスクJTAGデバッガについて触れました。

実は使用する上で「何かおかしいな。」と思っていて要調査マークが付いていたのですが、なかなか着手できずに今日に至ってしまいました。

私が経験した気になる現象は、openocdで接続時にかなりの頻度で「Error: unable to open ftdi device: unable to fetch product description」というエラーメッセージが表示されて使用することができないというもの。

フリスクJTAGにはFT2232Dが搭載されています。
どうもFT2232Dに接続されているEEPROMに記録されたProduct Descriptionが読み出せないために、openocdが結果的にJTAGアダプタを見つける事が出来ず、それ以上処理されないようです。

（openocdはこの読み出したProduct Descriptionとopenocd用の設定ファイルに記述されたProduct Descriptionのテキストを比較し、一致した場合にのみ自分が使用するJTAGアダプタであると認識します。）

フリスクJTAGは数人の方がお使いのようで誰も困っていないようなのですが、少なくとも私の手元ではLPC1768に接続する時点で困った現象に何度も遭遇しました。

これは調査しないわけにいきません。（香ばしい人柱の香りがするからです。）

ターゲットとデバッガの電源投入順序や電源のドロップやあれやこれやと仮説を立てたのですが、一向に当たりません。

昨夜は思い返して回路図をじーっと眺めるデバッグに切り替えてみました。

なんだか最近はデバッグツールのデバッグばかりしている気がしますが、気にしません。

データーシートと回路図を睨めっこした結果、フリスクJTAGの回路にバグを見つけてしまいました。
SI/WUAとSI/WUB端子を見て下さい。

二つともオープンになっています。

では、FT2232Dのデータシートでこの端子について調べてみましょう。
フリスクJTAGアダプタでは245FIFOモードでポートが使用されています。
この設定はFTDIから提供されているFT Progで確認しました。

データシートには各モードに対する接続について表になって記されています。
今回は「245FIFOインターフェースモード」の記述を参照することになります。

さて、問題のピンの記述を抜粋してみました。

このピンのディレクションは入力で、「未使用時にはVCCIOへ釣れ」と書いてあります。
先ほどの回路図はこのピンがオープンになっていました。

これは明らかにデータシートの指示と異なります。
先の問題の真の原因がこれかどうかは別として、少なくともこのピンの処理はきちんとしておいたほうが良さそうです。

何だかこの端子をVCCIOに釣るだけで先に記した動作が改善されそうな気がしてきました。
次回の記事ではこのピンの処理を実機に施して動作を見てみたいと思います。

フリスクJTAGデバッガーをLPC1768で使ってみる

2011-06-14T23:17:00.001+09:00

「遂に購入。ARM Cortex-M3用OpenOCDフリスクJTAGデバッカーを準備する。」ではフリスクJTAGデバッガーの準備を行いました。

この手の道具はケースに入れて準備しただけでは何も役立ちません。
ちょっと試しにNXPセミコンダクターズのARM Cortex-M3が搭載された基板で動作を見てみる事にしました。

この基板に搭載されているデバイスはLPC1769です。
openocd(Open On-Chip Debugger)の0.4.0を使ってデバイスが見えるところまでを確認してみました。

Open On-Chip Debugger 0.4.0 (2011-05-14-21:51)
Licensed under GNU GPL v2
For bug reports, read
 http://openocd.berlios.de/doc/doxygen/bugs.html
jtag_ntrst_delay: 200
100 kHz
Info : clock speed 100 kHz
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1768.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc

見えているようです。
ちなみにopenocdのインターフェース設定ファイルは以下のようにしました。

#
# FRISK JTAG Debugger
#
# http://www.tacinc.jp/frisk/frisk.htm
#

interface ft2232
ft2232_device_desc "myJTAG"
ft2232_layout "jtagkey"
ft2232_vid_pid 0x0403 0x6010
ft2232_latency 2

過去の幾つかの試作機では

ft2232_device_desc "myJTAG"

ではなく、

ft2232_device_desc "myJTAG A"

となっているようです。

この記述が実際のデバイスと異なるとopenocdはJTAGインターフェースの検出に失敗します。
私はこれで30秒ほど悩みました。

幾つか気になる点があるのですが、まだまだもう少し使い込んでみないとわかりません。
暫くはJTAGKey2PとフリスクJTAG(FRISK JTAG Debugger)の二本立てでデバッグを楽しもうと思います。

今回試しに設定したopenocd用のファイルはこちらからダウンロードできます。

遂に購入。ARM Cortex-M3用OpenOCDフリスクJTAGデバッカーを準備する。

2011-06-14T22:16:00.001+09:00

本日はJTAGデバッガに関する話題です。

私自身はJTAGKey2Pを購入して愛用しているのですが、購入前の事前調査時には色々と調査して「あれが良いかも。」、「これが良いかも。」、「いや・・・待てよ・・・。」なんてやっていました。

実はこの調査の過程ですごく気になっていたのが、今回のフリスクJTAGデバッガーです。
とにかく美しい基板が大好きなので、この手の製品を見かけるとついつい手にとって眺めたくなります。

今回は株式会社ティーエーシーさんにお願いし、発売予定の物を１つ販売して頂きました。
これがそのフリスクJTAGデバッガーです。

この基板の感じがたまりません。
ケースは付属しませんので、自分でフリスクを購入して食べた後（別に食べなくても良いですけど・・・。）でケースを再利用することになります。

ケースの加工はニッパーとやすりがあれば形になります。
まず、ボックス上になった箇所の壁を切り取ります。

次にJTAGコネクタが出る箇所の穴を開けます。

ケースに入れてみて収まり具合を確認します。
同時にUSBコネクタの位置を確認します。

USBコネクタが出る箇所の穴を開けます。

後は今まで開けた穴のバリをやすりで取り除くとケースは完成です。
ここで一工夫。

基板をそのまま収めた場合、ケース内部で基板が暴れます。
そこで、スコッチから販売されている剥がす事もできるゲル状の両面吸着材を基板に貼りつけてケースに収めます。

私は高さを合わせるために２枚重ねて貼りつけました。

以上でケースへの実装が完了です。

後はリセットスイッチの穴を開けて完了です。
リセットスイッチの穴位置は現物合わせにしました。

まず、ケース上部の裏面に先ほどのゲル状の両面吸着材を貼り、一度ケースを閉じます。
スイッチの頭の形状がゲルに残りますので、その部分に穴を開けました。

私は彫刻刀を使って円形の穴を開けました。

完成写真はこちら。

世界で１台、自分だけのJTAGデバッガ（外見だけね。）が完成です。
次の投稿では実際にこのJTAGデバッガを使用してみてレポートしようかと考えています。

野良管理していたソフトウェアをsourceforgeでホスティングする事にしました。

2011-05-28T10:56:00.001+09:00

先日まで野良管理していたソフトウェアですが、sourceforgeで正式に（？）ホスティングすることにしました。バージョン管理はgitを採用しています。

Natural Tiny Shell (NT-Shell)

以下のウェブページからアクセス可能です。

http://sourceforge.jp/projects/ntshell/

H8/3069F writer for KOZOS (kz_h8write)

以下のウェブページからアクセス可能です。

http://sourceforge.jp/projects/kz-h8write/

ドキュメントなどもこれから充実させていく予定です。

H8/3069F writer for KOZOS - kz_h8write 「h8writeリベンジ解決編」

2011-05-26T22:15:00.016+09:00

概要

先日の記事で勢いよく「改良しました！」と宣言したh8writeですが、やっぱり書き込みに失敗するという事がわかりました。
そもそも真の原因を掴めないまま改良したと言っても、何を改良したのか意味がわかりません。
自分でもそんな突っ込みを入れたくなるのですが、その日はグングン快調に書けていた上、オリジナルで実行するとやっぱり書けないという状態で、完全に勘違いモードに突入していました。

既に行く先の見えているH8/3069Fに肩入れするつもりはなかったのですが、KOZOS本（と著者！）が楽しくて仕方がないのと、宣言して出来なかった悔しさから本格的に問題を追及すべく、データーシートを片手にh8writeのソースコードを本格レビューしていくことにしました。

判明した事実

データーシートのプログラミングシーケンスを数分眺めていて、すぐに気付いたことがあります。

先日までは、プログラミングシーケンスなど気にも留めていなかったのです。
なぜなら１０年もの間、皆さんが使い倒していて、正常に動いていたからです。
そこにあえて突っ込みを入れる必要はないだろうと思っていたのですが、ここが肝心な部分でした。

問題となっているのはホスト側のボーレートをマイコンが自動検出するメカニズムの部分です。

まずはデーターシートを見てみましょう。

このシーケンスで重要なのはホストからブートプログラムに送られる0x00です。

図にもあるように「MAX30回」です。
この意味が重要です。
決して、「いつも30回」ではありません。

それでは、h8write.cを見てみます。

関連する定義は以下のようになっています。

上記でお分かりのとおり、「最大30回」ではなく、「常に30回」送信しています。
これの何がいけないのでしょう？

答えはデーターシートに書いてあります。

要するにブートローダが合わせ込み完了を通知したら、次の状態に遷移しているのです。
では、遷移した先の問い合わせ選択コマンドとは何なのか？見てみましょう。

デバイスに関する様々な情報をホストが問い合わせするためのコマンドを受け付ける状態のようです。

要するに既にブートプログラム側は「ビットレート合わせ込みシーケンス完了」を宣言し、全く異なるシーケンスを持つ次の状態に遷移しようとているのに、ホスト側がだらだらとビットレート合わせ込み用データをまだまだ垂れ流しているというわけです。

これはいけません。

本来は、ブートプログラムから「ビットレート合わせ込み完了」が来た時点で、以下の図の赤で囲ったシーケンスを実行しなくてはならないからです。
だらだら0x00を送っているということは、本来確認用コード0x55を送るべきところで、0x00を送っている事を意味します。

オリジナルのh8writeの出力をもう一度確認してみます。

当然ながら実装の通り、ブートローダから「合わせ込み完了」が返ってきているにも関わらず、どんどん0x00を送出しています。

上記例は”たまたま”うまく動作している時の例です。

”たまたま”の根拠は先ほど挙げたデータシートの通りです。

明らかにデータシートで示唆されたシーケンスとは異なる事がわかります。

次に示すのは互いのシーケンスが一致していない事による失敗の例です。

失敗する時と明らかなタイミングの違いがあるかと思ったのですが、そのようには見えないのが不思議です。紙一重で動いていると言う事なのでしょうか？

ここで、ふと疑問に思われる事でしょう。
「なぜ皆はうまくいっているんだ？」
システムではよくある話ですが、おそらく偶然動いているだけです。

これにはいくつものタイミングが絡んでいます。

ソフトウェアが処理を行うまでの時間。
シリアルポートドライバが処理を開始するまでの時間。
カーネルが処理を開始するまでの時間。
H8側のブートプログラムが合わせ込みを完了するまでの時間。
H8側のブートプログラムが次の状態へ遷移するまでの時間。

特に、近年はレガシーポートが姿を消しています。
USBの先にシリアルポートデバイスが接続されるような場合には更にタイミングが従来より異なるでしょう。

まさに今回のh8writeの問題はここに原因がありました。
従来は偶然書けていたのです。

h8writer for KOZOS - kz_h8write

h8writeは長年沢山の方々がお使いになっていて実績という意味では申し分ないのですが、実装が美しくありません。
車輪の再開発をするつもりはないのですが、頭の整理も兼ねて綺麗に実装しなおすことにしました。

プログラムは「KOZOS本と一緒に使う」という意味でkz_h8writeと名付けました。

kz_h8writeは以下の要素から構成されています。

motモジュール（motファイルを読み込むモジュールです。）
serialモジュール（シリアルポートを制御するモジュールです。）
kz_h8write（全体の制御を行うモジュールです。）

オリジナルh8writeの実装は各機能が癒着気味で修正の影響が見えにくくなっていました。
また、失敗した時に何の処理で失敗したのか見当がつきにくかった問題もあります。

問題のビットレート合わせ込みは以下のように実装しました。
データーシートにあるように計測用マーカーを送信して、ブートプログラムからの返答を確認した時点でこちらも応答を返すという手順にしてあります。

実際のやりとりもロジックアナライザで観察してみました。
ホストからのビットレート合わせ込み用コード(0x00)に対して３回目には応答が返ってきています。

kz_h8writeは応答があった時点でデータシート通り、確認用のコード(0x55)を送出しH8から返答(0xE6)を受けています。

これでホストとH8は合わせ込まれたビットレートで正しく通信できるわけです。

kz_h8writeコマンドツールにはmotファイル名、クロック周波数[MHz]、シリアルポート名を与えて使用します。

kz_h8write kzload.mot 20 /dev/ttyUSB0

各シーケンスが実行されていく様子を確認する事ができます。

=======================================
 KOZOS H8/3069F Flash Writer.          
 Copyright(C) 2011 Shinichiro Nakamura 
=======================================
Bitrate sequence: Done.
Inquiry device: Done.
Select device: Done.
Inquiry clock mode: Done.
Select clock mode: Done.
Select bitrate: Done.
Write erase: Done.
Complete.

全ての作業が完了した時には「Complete.」と表示が行われます。

今回の実装で複数の環境で昨日今日と試していますが、期待通りに動いています。
※まれに電源投入後１回目は失敗するのですが、もう一度実行するとうまくいきます。

前回と異なるのは明らかにおかしい箇所を修正したバージョンだということです。
原因（の１つ）を解明して修正していますので、先日の「何だかわからないけど動くようになりました！」とは意味が違います。

このkz_h8writeを暫く使ってみようと思っています。

ソースコード

LinuxとWindows上で動作させることができます。
ソースコード：ここからダウンロードして下さい。

(2011/05/28追記)
http://sourceforge.jp/projects/kz-h8write/で管理することにしました。
最新版は上記サイトからダウンロードして下さい。

ライセンス

MITライセンスを適用します。
商用、非商用を問わず自由にお使い頂けます。

Linux上でH8/3069の書き込みに失敗する件 (h8write for KOZOSを実装しました)

2011-05-23T22:50:00.022+09:00

(2011/05/25追記)
この記事で取り上げられているh8write for KOZOSの対策は本質的な解決策を示していません。
後日取り上げる別の記事で「リベンジ解決編」をお届けする予定です。
暫くお待ち下さい。

(2011/05/26追記)
この投稿記事で取り上げられている内容は本質的な解決策を示しているとは言えませんでした。
そこでH8/3069F writer for KOZOS - kz_h8write 「h8writeリベンジ解決編」を公開しました。

h8write for KOZOSって何？
h8writeはMitsuiwa Yukioさんが実装したH8書き込み用ツールです。
(ウェブ：Open SH/H8 writer)
このh8write for KOZOSは三岩さんが実装したオリジナルのh8writeの実装修正バージョンです。

主にKOZOSをLinux上で体験したい方に向けて公開します。

KOZOSとは坂井弘亮さんがフルスクラッチで設計実装されたＯＳで「組み込みＯＳ自作入門」という書籍の題材にもなっているＯＳです。

これがかなり面白い内容で、坂井さんのオリジナリティ溢れる視点で最後まで楽しく読む事ができます。ちなみにこんな勢いで読み進める事ができます。

KOZOSについては以下のページもご覧下さい。
http://kozos.jp/kozos/

さて、本題です。

この書籍ではプラットフォームに秋月電子通商のH8/3069Fネット対応マイコンLANボードが使われています。

実は、H8がプラットフォームとして選択されていたので、敬遠していたのですが、「これはやっぱり面白い」と書籍の内容を一目見て衝動買いしてしまいました。それも、随分と前・・・。

随分と前に購入しておきながら、なぜ触れなかったかと言うと、書き込みツールであるh8writeで書き込みができなかったからなのです。

私は個人的に開発環境にUbuntuを好きで利用しています。Windowsの端末環境では開発がスムーズに進まないからです。実際にh8writeをコンパイルして動作させてみると、稀に書き込みに成功するものの、殆ど失敗します。

私は「OSを作りたかった」わけなので、「h8writeのデバッグがしたかった」わけではありません。
プライオリティの関係から少しずつ放置状態になっていました。
（皆さんの中にもこういう方はきっといるはず。）

ふと思い立ちh8writeのソースコードを調べてみたところ、実装があまり美しいとは言えません。

シリアルポート周辺の実装を見るとなんだかごちゃごちゃしています。
そして、今回問題となっているのはシリアルポート周辺処理です。

問題を後々整理できるようにと、第１段階としてシリアルポート周辺処理を整理することにしました。
また、この過程で気になる実装を修正して完成したのがserial.cとserial.hです。

このserial.cとserial.hにシリアルポートの処理を任せた実装が私の改良実装版です。
そして、「ダメ元」で試してみたところ、かなりの確率で書き込みに成功することがわかりました。

そこで、この実装をh8write for KOZOSと名付け、早々に公開することにしました。

どうしてオリジナルではいけないの？

オリジナルではいけないということはありません。
このh8write for KOZOSはオリジナルのh8writeで書き込みに失敗する方のためのツールです。

近年、レガシーポートがコンピュータから姿を消し、結果的に当該ボードにはUSB-シリアル変換ケーブルを使って書き込む事が多くなっているように思います。

KOZOSの書籍で扱っているH8は3069です。

実は、オリジナルのh8writeでは、USB-シリアル変換ケーブルを使うケースにおいて、一部の環境で書き込めない問題が発生しています。

実際に調べてみるとH8/3069の書き込み時には、ボーレート9600でCPU情報を確認した後、COMポートを一度クローズし、ボーレート19200で再オープンして書き込みを行っている事がわかりました。

オリジナルのコードではこのボーレートを指定しながらのオープン・クローズ処理周辺の実装に問題があるように見えました。

と言っても、ツールの実装当時から見ると、カーネル側の処理も随分変わりましたし、USB-シリアル変換ケーブルに搭載されたデバイスのドライバの実装の甘さも関連があるかもしれません。

そこでシリアルポートの処理を中心に実装を試験的に見直し、書き込みに失敗する幾つかの環境で試行してみたところ、うまく書き込めることがわかりました。

ダウンロード

こちらからソースコードをダウンロードして下さい。
簡単なMakefile付きです。

Ubuntu 10.10上でのみコンパイルと動作を確認しています。
その他の環境での動作確認等が出来ましたら、是非御報告頂ければ幸いです。

(2011/05/26追記)
この投稿記事で取り上げられている内容は本質的な解決策を示しているとは言えませんでした。
そこでH8/3069F writer for KOZOS - kz_h8write 「h8writeリベンジ解決編」を公開しました。

何が違うの？(実装面)

シリアルポートの実装を分離しました。
シリアルポートの実装を見直しました。
関数名を一部変更しました。
Windowsに対する実装サポートはバッサリ削除してあります。

何が違うの？(実動作)

うまく動作することがわかったら、どんな風に実動作が異なるのか知りたくなります。

オリジナルのh8writeを使って書き込みに失敗する環境を用意し、観察してみます。
確認したのは「最初にH8にデータを送信する箇所」です。

NG: オリジナルのh8write

OK: 改良実装版h8write

最初に送信するデータはボーレート9600で送信されます。
なんだか、最後の方が異なります。
もう一度書いておきますが、シリアル周辺の実装を修正しただけです。

続くパケットではプロセッサの種別を確認するのですが、オリジナルの実装ではこの時点で動作していないことがわかりました。

まとめ

h8writeの実装には気になる点がいくつもあります。
今回は深追いをせずにシリアル周辺の実装のみを修正して効果を確かめました。

今のところノートパソコン、デスクトップに作った２つの環境で書き込みが出来ています。
実は、この２つの環境はオリジナルのh8writeでは書き込みに失敗します。

本来であれば、もう少し丁寧に追い込まなければならない点が残っています。
しかし、かなり多くの方が「書き込めない」で困っている様子（私自身がそう）でしたので、早めに公開することにしました。

皆さんのh8writeの問題が解決し、KOZOSを楽しんで頂ければ幸いです。

（検証に御協力頂ける方）Linuxディストリビューション名と使ったUSB-シリアル変換ケーブルなどもろもろの情報と共にhttp://groups.google.com/group/kozos_tomonokaiまで動作結果を御連絡下さい。

(2011/05/26追記)
この投稿記事で取り上げられている内容は本質的な解決策を示しているとは言えませんでした。
そこでH8/3069F writer for KOZOS - kz_h8write 「h8writeリベンジ解決編」を公開しました。

ライセンス等

ライセンスはオリジナルに従います。
但し、serial.cとserial.hをh8write.cと切り離して用いる場合、MITライセンスを適用します。
使用した如何なる結果についても、当方は責任を持ちません。

Natural Tiny Shell (NT-Shell)をmbedで使ってみる (Eating your own dog food)

2011-05-22T12:06:00.008+09:00

「自分のドッグフードを喰う(Eating your own dog food)」はソフトウェア開発の世界で有名な台詞です。

自身で作ったソフトウェアを自身で使うことで、それがどのように有用か（あるいはそうでないか）を知る事ができるというわけです。

例にならってNatural Tiny Shell (NT-Shell)をmbedで使ってみることにしました。
目論見は簡単に移植できるというところです。

しかし、実際に移植してみると幾つか気になる点がありました。
これは興味のある方のために後述。

移植した結果はmbed.orgにアップロードしました。
興味がございましたら、ご自由にお使い下さい。

http://mbed.org/users/shintamainjp/notebook/ntshell_ja/

参考までに「自分で自分のドッグフードを食べた」結果、どんな事がわかったのか記しておきます。

シリアルポートのリード及びライト関数の引数の型がvoidだった。（なんでそんな実装になっちゃってたんだ？）

CTRL+A, CTRL+Eへの対応が未実装のままだった。（ドキュメントではできることになっていた。）

コマンドを受け付けた時の改行をアプリケーション層で行う事を期待した実装になっていた。（誰もわからないよ！）

受け付けるコマンドの長さが微妙に小さかった。（もう少し実用的な値を選んでおけば良かった。）

サンプルコードがなくて、どうやって使っていいのかわからなかった。（この点は後日もっと改善したい。）

こんな風に、自分で作って公開した物でも、少し時間を経てから見直してみると気になる点は多々あります。いざ利用者の立場に立って見ると「何だこれ？」と自分でも感じてしまうのですから、面白いものです。

是非、この「自分で自分のドッグフードを食べる」は継続して進めたいところです。

Natural Tiny Shell (NT-Shell) ライブラリを更新しました。

2011-05-19T23:51:00.006+09:00

Natural Tiny Shell (NT-Shell) ライブラリは小規模組み込みシステムの為のシェルライブラリです。
本日新しい機能（入力補完機能）を加えて更新しました。

入力補完と１口で言っても色々な種類の補完が考えられます。
今回の入力補完機能は過去に入力した文字列の中から候補をTABキーで選出する事ができるというものです。

デモ映像を用意しましたのでご覧下さい。

ソースコード： Natural Tiny Shell (NT-Shell) Version 0.0.6

インターフェースはかなりシンプルです。
ntshell.hのntshell_executeインターフェースのみ知っているだけで使用することができます。
このため、様々なシステムに簡単にポーティングする事ができます。
是非みなさんの小規模組み込みシステムでお楽しみ下さい。

Natural Tiny Shell (NT-Shell) library was updated.

2011-05-19T23:47:00.003+09:00

Natural Tiny Shell (NT-Shell) library is a tiny shell library for a small embedded system.
Today, I just updated the library.
The new feature is historical input.

Please see the demo movie.

The source codes : Natural Tiny Shell (NT-Shell) Version 0.0.6

The interface is really simple.
You should only know ntshell_execute in ntshell.h.
So you can port it to any embedded system easily.
Please enjoy your small embedded system with it. :)

LPC1769の内蔵ブートローダを使って書き込みに失敗する環境がある（lpc21isp使用時）

2011-05-14T20:03:00.008+09:00

概要

ARM Cortex-M3で遊ぼうということで設計したNXP LPC1769搭載基板。
グダグダと色々なファームウェア部品を作ったりして楽しんでいるわけです。

このボードには「いつでもどこでもLPC1769」という裏コンセプトがあり、

「だいたいパスポートサイズ」
「USBバスパワーで動作する」
「内蔵ブートローダで書き込みができる」

といった特徴があります。
ノートパソコンとこのボードとUSBケーブルさえあれば、開発を楽しむ事ができる仕組みです。
「ちょっとしたデモ」であれば十分対応できます。

この特徴を生かして今日の今までノートパソコンを使った開発で楽しんでいました。
ふと思い立って自宅の大画面環境で作業した方が効率も良いし・・・と思った時の事です。

なんと、LPC1769の内蔵ブートローダを使った書き込みに失敗します。
何度やっても再現性100%で。

どちらもVMware Player上に仕立てたUbuntu 10.10で行っています。
プロジェクトのリポジトリから書き込みスクリプトを含む全てのリソースをチェックアウトして作業しています。

異なる可能性があるとすれば、ローカル環境設定とツールのバージョンくらいでしょう。
これに依存する何かが書き込み時の起こっているとは考えにくかったのですが、「おかしい、おかしい」と言っているだけでは前に進みません。

そこで先日購入したロジックアナライザでちょっと見てみることにしました。

正しく動作する環境

まずは正しく動作する環境の方です。
lpc21ispのバージョンは1.79です。

正しく動作しない環境
次に正しく動作しない環境の方です。
lpc21ispのバージョンは1.64です。

さて、何か変ですね？
ちょっと見比べてみましょう。
上側は動作する時、下側は動作しない時の要求と応答です。

整理してみます。

lpc21ispのバージョン	状況	lpc21isp	LPC1769	Synchronized確認トークンの補足説明
1.79	正しく動作する	Synchronized\n	Synchronized\nOK\r\n	lpc21ispとLPC1769で一致している。
1.64	正しく動作しない	Synchronized\r\n	Synchronized\rOK\r\n	lpc21ispは\r\nをセパレータとして使用している。LPC1769はそれとは異なるセパレータを返す。(ように見える)

「ように見える」と書いたのは、ここがポイントだからなのですが、それは後述します。

この手の書き込みプロトコルは、ターゲット上の内蔵ブートローダとホスト側のアプリケーションの協調動作で成り立ちます。
例えばアプリケーション側から「ＸＸＸだぜ！」と要求を受けて、内蔵ブートローダが「おっけー！」という具合です。
例に漏れずLPCシリーズの内蔵ブートローダもそのようになっています。

上記２つの環境間で異なるのはトークンセパレータのようです。
では、どちらが本来の実装なのでしょうか？

データシートを見てみます。

「全てのISPコマンドは単一のASCII文字列で送られなければならない。」
「文字列はキャリッジリターン と/か ラインフィードによって終端されなければならない。」

原文の「and/or」を「と/か」と訳しました。
要するに正解は

CR
LF
CR + LF

と、どれでも良さそうに書いてあります。

何かこの辺りの問題がありそうなのはわかりました。
では、立ち返って現象を見てみます。

user@ubuntu:~/Projects/TOPPERS-ASP-for-BlackTank-LPC1769$ ./devwrite.sh 
lpc21isp version 1.64
File TOPPERS-ASP_BlackTank-LPC1769.hex:
loaded...
converted to binary format...
image size : 115032
Synchronizing (ESC to abort). OK
No answer on Oscillator-Command

「オシレータコマンドの返答がない。」と言っていますね。
これが最後のやり取りのようです。

応答がないため、アプリケーション(lpc21isp)がそれ以降の処理を中止して終了するわけです。
でも、実際にはLPC1769から応答が返ってきています。

先ほど見た「Synchronized」は非同期シリアル通信の通信速度を自動判別する部分です。
これは書き込み動作の前の最初の操作ですから、オシレータコマンドとは関連ありません。

オシレータコマンドのやりとりを探すために、トリガがかかってからのサンプル数を増やしてみます。
以下は正しく動作しない環境でのやりとりです。

やりとりは以下のようになります。

アプリケーション：「4000で頼む。」
内蔵ブートローダ：「4000ね。おっけー！」

さて、正しく動作する環境で見てみましょう。

面白いのはアプリケーション側からやってくるセパレータによって、内蔵ブートローダ自身が用いるセパレータも変えてくるという点です。

但し、上記動作を見て下さい。
アプリケーション側が２つのセパレータを送った場合、内蔵ブートローダは先頭のキャラクタのみを採用するようです。
また、「OK\r\n」という固定的な返答も見られる事から、混在しているようにも見えます。

この動作は、アプリケーション側がデータシートに書いてある通り「CR」でも、「LF」でも、「CR + LF」でも正しく動作するよう実装してあれば問題ありません。

ですが、私の手元にあった古いlpc21isp (Version 1.64)ではそうなっていないということがわかりました。

本来であれば、このコマンドに続いてアプリケーション側から書き込み用のデータが送られてきます。
しかし、失敗する環境では「返答がない。」と判定されていました。
恐らくセパレータの解釈に問題があるのでしょう。
もしかしたら、受信側のセパレータの解釈に問題がありながら、送信側で対応したのかもしれません。その証拠に２つのバージョンでは送信するセパレータが異なる事がわかります。

この件に関して言えば、最近のバージョン (Version 1.79)では修正されているので心配ありません。
LPC1768やLPC1769を使う方の御参考までに。

おわりに

この手の問題は実際に色んな調査をしてみなければ原因がわからないことが多いので大変です。

今回のケースでは「あぁ、lpc21ispが古いのだなぁ」と片付ける事もできます。
ですが、「２つのバージョンでどのように異なり、その差異の何が問題となるのか？」を調べることで安心して使用できるようになります。

ウェブ上にある情報は断片的なものが多いのですが、「どのような問題があり」、「それをどのように解決したのか？」を自分のために整理すると意外に面白い発見になるのかもしれません。

B028 : LED MATRIX 100 差し上げます。

2011-05-04T18:53:00.003+09:00

(2011/06/02追記)
締め切りました。
沢山の御応募ありがとうございました。

MTM05で販売していた(そして１台売れた！)ATMEGA8L搭載のLED電光掲示板の基板とケースをセットで差し上げます。

* AVRを使った電光掲示板の実験ができます。
* 無保証です。サポートもありません。
* 送料は御負担下さい。

回路図はこちら。
役に立たないファームウェアはこちら。

それでも欲しいと言う方は @shintamainjp まで御連絡下さい。
あと３台あります。

ぞうさんとかくるまとか表示できます。

B041 : SD CARD MODULE 差し上げます。

2011-05-04T18:42:00.002+09:00

(2011/06/02追記)
締め切りました。
沢山の御応募ありがとうございました。

MTM05で販売していた(そして１台も売れなかった！)ATMEGA8L搭載のSDカード実験基板を差し上げます。

* マイクロＳＤカードスロットを搭載しています。
* AVRを使ったFATファイルシステムの実験ができます。
* 無保証です。サポートもありません。
* 送料は御負担下さい。

回路図はこちら。
役に立たないファームウェアはこちら。(でも、ChaNさんのPetit FatFSは素敵ですよ。)

それでも欲しいと言う方は @shintamainjp まで御連絡下さい。

B051 : WAV MODULE 差し上げます

2011-05-04T18:28:00.003+09:00

(2011/06/02追記)
締め切りました。
沢山の御応募ありがとうございました。

ATMEGA328P搭載の基板を差し上げます。
MTM05で販売していた(そして１台も売れなかった！)ものです。

* マイクロＳＤカードスロットを搭載しています。
* オーディオ用ステレオ16ビット D / Aコンバータ(BU9480F)を搭載しています。
* AVRを使った簡単なオーディオの実験ができます。
* 無保証です。サポートもありません。
* 送料は御負担下さい。

回路図はこちら。
役に立たないファームウェアはこちら。(でも、ChaNさんのPetit FatFSは素敵ですよ。)

それでも欲しいと言う方は @shintamainjp まで御連絡下さい。