2011年3月20日日曜日

LPC1769搭載オーディオ基板のハードウェアデバッグが完了

先月からダラダラと進めているARM Cortex-M3(LPC1769)搭載オーディオ基板のハードウェアデバッグが完了しました。
回避不能となるような致命的なバグはなく一安心というところです。


今回のプロジェクトでARM Cortex-M3の感じが大体つかめました。
@suikan_blackfinさんによるオーディオトークスルーもこのとおり動作しています。


会社で周りの人と話していると「マイコン=低機能」という思い込みを持っている人が意外に多いことに気づきます。
確かに業務で少し触れただけの過去の経験から現状を見ると「何が違うの?」ということになるのかもしれません。
これは非常に勿体無い話です。
10年、20年前とは状況が大きく変わっているのだということを実感するには、実際に触ってみるのが一番です。

例えば、今回の基板ではオーディオをコーデック経由でスルーさせながら、バックグラウンドでデバッグ用シェルが走っていたり、マイクロSDカードにアクセスしたり、有機ELディスプレイの表示をしたり、ユーザのスイッチ入力を監視したりしています。これらの仕事をワンチップのマイコンで実現できるわけです。

マイコンのシステムだからと言って、わざわざ周辺環境までチープにする必要はありません。
ストレージ(今回はマイクロSDカード)も欲しいし、デバッグにはシェルが欠かせません。

ARM Cortex-M3はこういった小規模開発の既存概念を変える道具として最適です。
データシート上で見る性能だけでなく、「実際にどこまでできるのか?」を自分で考えてみることで、誰も考えていなかった応用への発展が期待できそうです。

なお、このプロジェクトは引き続きファームウェア開発を行う予定です。

2011年3月16日水曜日

Japan / Earthquake Donation


Dear community peoples.

Sorry about this post.
This is not an electronics contents.

The situation of my country is not good you know.
So I need your help.

But I'm Okey.
It's just for the disaster area.

Please donate for them if you can.
http://www.jrc.or.jp/english/relief/l4/Vcms4_00002070.html

Best regards,
Shin.

2011年3月7日月曜日

LPC1769搭載オーディオ基板のとんでもない実装ミス

昨日のこと、LPC1769搭載オーディオ基板のデバッグを開始して1時間後、とんでもない実装ミスを発見してがっくりしていました。

「なんだかSWDで繋がらないなぁ〜。」なんて思っていたんです。
前日までは「まぁ、デバッガの接続が間違っているんだろう。」なんて思っていました。

さてさて、データシートのパッケージ情報にはきちんと「1ピンはココ!」と当然示されていますね。


で、取り付けた状態の写真が以下です・・・。


ですが、冷静に基板を見て愕然・・・。
「1ピンはそこじゃない!」
なんと、1ピンは左上なのです!


もう全く意味がわかりません。

データシートを何のために見て実装したのでしょうか・・・。
シルクによる心理効果か、はたまた大きい穴に騙されたのでしょうか。

とにかくもう一台作り直しです。
今度はさすがに間違えません。


なんだかんだで2時間のハンダ付けを行ない2台目が完成。
あっさりSWDによる認識も完了しました。


なんと言いますか、一日働いた後で深夜のハンダ付けは避けようかと考えた出来事でした。

P.S. この方のようなユーモアを交えてお伝えするセンスを持ちあわせていないのが残念。

2011年3月3日木曜日

LPC1769搭載オーディオ基板のデバッグ用1号機が組み立て完了

先月の中旬に基板が上がってきてからダラダラと行なっていたLPC1769搭載オーディオ基板のデバッグ用1号機の組み立てがやっとこさ完了しました。
大した事ないハンダ付けのはずでしたが、その前に基板がおかしいだろうとか、FPCのハンダ付けでギャフンと言ったりしてなかなか進んでいませんでした。

ボリュームとスイッチは高さを合わせてあります。
最終的にアクリル板を上部に取り付けるようにする計画。


今回の基板は少しだけ奮発して値段のはるスイッチを使ってます。
左上の有機ELも表示させるのも楽しみ。


今日はショートチェックを済ませた後、通電を数十秒だけ行ないました。
デバッグ用シリアルインターフェースに接続したFT232RLを、パソコン側で認識できるのは確認しました。


基板のデバッグはまだまだこれから。
今週末にでもデバッグを進めようと思います。

2011年3月2日水曜日

Natural Tiny Shell(NT-Shell)のポーティング事例。LPCXpressoとTOPPERS/ASPで小規模組み込みシステムの開発をもっと便利に!

はじめに

前回の記事でVT100仮想端末を小規模組み込みシステムで実現するためのライブラリを公開しました。
中には「これが何の役に立つのだろう?」と疑問に思われた方も少なくないでしょう。

この手のツールは実際の開発作業が進むにつれて利便性を再認識することが少なくありません。
(逆に言うと実際に開発作業で相当に困らないと不便な事に気付かない事が多いのです。)

今回はLPCXpresso上でTOPPERS/ASPを動作させるシステムを実際に開発するシステムと見立てて、Natural Tiny Shell(NT-Shell)をポーティングして活用した時のメリットについて御紹介します。


TOPPERS/ASPでNatural Tiny Shell(NT-Shell)を使う

今回はRTOS上にシェルを実装することでシステム開発をもっと便利にしてみましょう。
題して「LPCXpressoとTOPPERS/ASPで小規模組み込みシステムの開発をもっと便利に!」です。
小規模組み込みシステムでありがちな「この程度の規模だからいいや。」と諦めている方におすすめです。
きちんと動作するデバッグ用シェルがあるだけでシステムが見違えるように良くなったように感じます。
デバッグも楽しくなって作業効率が向上すること間違いなし!
是非皆さんも挑戦してみませんか?

エコーバックを行わないようにする

受信した文字列をエコーバックする設定を取り除く。

TOPPERS/ASPでは受信した文字列をエコーバックすることができるようになっています。
Natural Tiny Shell(NT-Shell)を使用する時、エコーバックは都合が悪いので設定を外します。
これはシリアルインターフェースドライバで行うことができます。

syssvc/serial.c の serial_opn_por 関数でIOCTL_ECHOの指定を取り除きます。
serial.cの240行目付近です。


/*
 *  変数の初期化
 *  エコーバックさせたい時にはIOCTL_ECHOを追加すると良い。
 */
p_spcb->ioctl = (IOCTL_CRLF | IOCTL_FCSND | IOCTL_FCRCV);


なぜ受信した文字列をそのまま返してはいけないかという話です。

システムに接続されたシリアル端末が送信してくるコードの中には制御コードが含まれる事があります。
今回のシェルを設計実装した目的の1つは「制御コードをうまく処理してシリアル端末ユーザに便利な機能を提供しよう」です。
受信したコードをそのまま送信した結果、シリアル端末上で制御コードが解釈されてしまっては従来と何も変わらない事になってしまいます。
これを避ける為にエコーバックをしないようにします。

例えば、「おっ。上方向キーだな。じゃあ、過去のコマンドを表示してあげよう。」といった具合です。

システム

今回のシステムは以下のようになっています。
実際に開発するシステムに見立てていると考えてみて下さい。


システムと開発用ホストは2つのUSBで接続されています。

1つはLPCXpresso用でこれはLPCXpresso上のデバッガに接続されています。
実際に開発するシステムによってはここは他のデバッガに置き換わる事もあるでしょう。

もう1つは開発対象システムのUARTをUSBで入出力するための変換器との接続です。
今回は秋月電子通商で販売されているFT2232Dを使った変換器を使用しました。

実際の接続した状態は以下のようになっています。


内部タスクの構成

今回の内部タスク構成を以下のようにしました。
  • task_ledblink: LEDを一定間隔でトグルするLED点滅タスク
  • task_ntshll: Natural Tiny Shellをフロントエンドとするシェルタスク

LED点滅タスクを作る

LED点滅タスクは一定時間間隔で動作しLEDの状態をトグルさせるタスクです。
点滅の間隔は100[ms]ですが、データキューから値を受け取って変化させることができるようにしてあります。
外部からデータキュー経由で点滅の速度(正確にいうとタスクの動作間隔)を変化させることができるようにしてあります。


void task_ledblink(intptr_t exinf)
{
    syslog(LOG_NOTICE, "task_ledblink: Started.");

    int ledspd = 100;
    while(1)
    {
        uint_t value;
        while (prcv_dtq(DTQ_LEDSPD, (intptr_t *)&value) == E_OK) {
            if (value > 0) {
                ledspd = value;
                // syslog(LOG_NOTICE, "new value is %d.", value);
            }
        }
        LPC_GPIO0->FIOPIN ^= ACTLED;
        tslp_tsk(ledspd);
    }
}


シェルタスクを作る

次にNatural Tiny Shell(NT-Shell)を組み込んだシェルタスクを立てます。
シェルタスクはUARTに対する入出力を管理しながら、ユーザの要求をシステムに伝達する役目を果たします。


void task_ntshell(intptr_t exinf)
{
    syslog(LOG_NOTICE, "task_ntshell: Started.");
    serial_opn_por(SIO_PORTID);

    ntshell_execute(&parser,
            &editor, &history,
            func_read, func_write, func_cb);
}


ntshell_executeは処理を戻さない関数です。
UARTからの入出力関数を受け取って処理を行ないます。

今回の例ではfunc_readは以下のようになっています。


int func_read(void *buf, int cnt)
{
    return serial_rea_dat(SIO_PORTID, buf, cnt);
}


同様にfunc_writeは以下のようになっています。


int func_write(const void *buf, int cnt)
{
    return serial_wri_dat(SIO_PORTID, buf, cnt);
}


ユーザが操作を決定するとコールバック関数(上記ではfunc_cb)が呼ばれるようになっています。
ユーザが入力を完了後、エンターキーを押した時の入力文字列が渡されるようになっています。

ここでユーザの要求に応じて処理を行えば良い事になります。


int func_cb(const unsigned char *text)
{
    // TODO 入力されたコマンドに応じて処理を行う。
}


ちなみに、この関数内部の実行スレッドはシェルタスクのスレッドです。
今回のアプリケーションでは以下のように実装してみました。
ntop_compareはNatural Tiny Shellに含まれるユティリティ関数で、文字列の比較を行うものです。


int func_cb(const unsigned char *text)
{
    static int ledspd = 100;
    if (ntopt_compare(text, "INTERVAL UP") == 0) {
        if (ledspd < 500) {
            ledspd++;
            snd_dtq(DTQ_LEDSPD, (intptr_t)ledspd);
        }
    } else if (ntopt_compare(text, "INTERVAL DOWN") == 0) {
        if (ledspd > 1) {
            ledspd--;
            snd_dtq(DTQ_LEDSPD, (intptr_t)ledspd);
        }
    } else if ((ntopt_compare(text, "HELP") == 0)
            || (ntopt_compare(text, "?") == 0)) {
        text_puts("\r\nINTERVAL UP   : Task interval time increase.");
        text_puts("\r\nINTERVAL DOWN : Task interval time decrease.");
    } else {
        if (ntopt_get_count(text) > 0) {
            text_puts("\r\nUnknown command found. (HELP: display help.)");
        }
    }

    return 0;
}


実際に使ってみる

実際に使用している様子を動画で御紹介します。


リソース

今回は3千円で楽しめるARMマイコンとRTOSの世界 (TOPPERS/ASP on LPCXpresso LPC1768)のプロジェクトに小規模組み込みシステムデバッグ用シェル - Natural Tiny Shell (NT-Shell)を追加する形で作業しました。
プロジェクトはここからダウンロードできます。

2011/03/08追記。
公開当初のサンプルプロジェクトが使用しているNT-Shellにはバックスペース処理にバグがありました。
修正したライブラリに差し替えました

まとめ

ターゲットに対して対話型で操作要求ができるとちょっとした確認をする時に非常に便利です。
今回はLPCXpresso(Cortex-M3搭載)でRTOS(TOPPERS/ASP)を動作させるという比較的小さな組み込みシステムでの応用例を示しました。

システム内部の値を外部から変更することは当然デバッガなどでも可能です。
しかし、ちょっとしたパラメータを変更したい場合や複数のパラメータを同時に変更したい時には不便です。

対話型のシェルインターフェースがあれば、開発ホスト並の利便性を確保することも可能になります。

補足

念の為補足しておくと、LEDの点灯間隔を変化させるという行為が主眼ではありません。
おそらく点灯間隔を変えるための実装にはもっと相応しいものがあるでしょう。

今回はあくまでシステム内部の挙動をシェルを介して変化させるというところに視点をおいてあります。
今回の実装では点灯間隔が狭くなるにつれてプロセッサの使用率も相当上がります。
システムがどの程度の負荷を許容するのかを外部でパラメータを変更させながら見ることもできるでしょう。

2011年3月1日火曜日

小規模組み込みシステムデバッグ用シェル - Natural Tiny Shell (NT-Shell)

2014/11/02追記。
公開サイトを変更しています。以下から最新版をダウンロードできます。
http://www.cubeatsystems.com/firmware/ntshell/ntshell_ja.html
CQ出版社の月刊誌インターフェース2013年1月号に記事を書きました。
http://www.kumikomi.net/interface/sample/201301/if01_174.pdf
インターフェース2013年1月号のソースコードは、CQ出版社のダウンロードサービスで入手できます。
http://www.cqpub.co.jp/interface/download/contents.htm
TOPPERS活用アイデア・アプリケーション開発コンテストでの資料はこちら。
https://www.toppers.jp/docs/contest/presen2011_NaturalTinyShellTask.pdf
2012/10/18追記。
公開サイトを変更しています。以下から最新版をダウンロードできます。
http://shinta.main.jp/firmware/ntshell/ntshell_ja.html

小規模組込み機器を設計している時に必ずと言っていいほど欲しくなるのが、シェル端末のようなインターフェースです。
シェル端末があれば、対話形式でシステムの状態制御や状態取得を行うことが可能になります。

最近のプロセッサは小規模組み込み用途でも20年前のパソコンを超える性能を持っているのが現状です。
また、シェルのような動作を実現するのに高性能なプロセッサが必要というわけではありません。

しかしながらきちんとシェルの動作を実現しようとするとVT100のような端末をエミュレーションする必要がでてきます。
シェル端末が送信する多くの制御コードの解釈を正しく行うコードを実装するのは意外に面倒な作業です。
このため、多くの小規模組み込み機器の開発においてなかなか実現されることが少ないのが現状でした。

そこで、今回は小規模組み込みシステム向けのデバッグ用シェルNatural Tiny Shell (NT-Shell)を設計実装してみました。


このシェルを使えば、キー入力でおかしな制御コードが入ったりすることはありません。
コマンドの入力時に左右にカーソルを移動させてスムーズに編集できるのも特徴です。
また、上下方向キーによるヒストリ機能も搭載しています。
デバッグ時のキー入力で慎重になる必要がなくなりますので、スムーズな作業ができるようになります。

ソースコードはCランタイムライブラリに非依存で、小規模リアルタイムシステムなどへのポーティングも容易です。
ポーティング時にはソースコードを変更する必要はありません。
シェルの実行関数にシリアル通信ポートのI/O関数のポインタを渡すだけで済むようにしてあります。

詳しくは付属のドキュメントを参照して下さい。
ダウンロードはこちら:ntshell-0.0.4.tar.gz

2011/03/08追記。
公開当初のVersion 0.0.1にはバックスペース処理にバグがありました。
修正したVersion 0.0.3に差し替えました。

2011/04/30追記。
Version 0.0.3にはntoptとntlibcが含まれていませんでした。
また、vtparseのテーブルがRAMに配置されるようなになっていたので、static const属性に変更した上でvtpraseの実装を一部修正しました。
以上の修正を行ったVersion 0.0.4に差し替えました。

2011/05/20追記。
その後、入力補完機能を追加し、インターフェースをシンプルにしたバージョンを公開しました。
http://shinta-main-jp.blogspot.com/2011/05/natural-tiny-shell-nt-shell.htmlをご覧下さい。
動作の様子を記した動画もご覧頂けます。

2011/05/22追記。
mbedでも使えるようにしました。
http://shinta-main-jp.blogspot.com/2011/05/natural-tiny-shell-nt-shellmbed.htmlNatural Tiny Shell (NT-Shell)をmbedで使ってみる (Eating your own dog food)をご覧下さい。

2012/10/18追記。
公開サイトを変更しています。
以下から最新版をダウンロードできます。
http://shinta.main.jp/firmware/ntshell/ntshell_ja.html