2011年3月20日日曜日

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

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

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

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

例えば、今回の基板ではオーディオをコーデック経由でスルーさせながら、バックグラウンドでデバッグ用シェルが走っていたり、マイクロ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搭載オーディオ基板のデバッグを開始して１時間後、とんでもない実装ミスを発見してがっくりしていました。

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

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

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

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

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

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

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

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

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

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

2011年3月3日木曜日

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

先月の中旬に基板が上がってきてからダラダラと行なっていたLPC1769搭載オーディオ基板のデバッグ用１号機の組み立てがやっとこさ完了しました。
大した事ないハンダ付けのはずでしたが、その前に基板がおかしいだろうとか、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);

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

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

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

システム

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

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

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

もう１つは開発対象システムの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;
}

実際に使ってみる

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

リソース

今回は３千円で楽しめる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

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

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

しかしながらきちんとシェルの動作を実現しようとすると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

2011年2月23日水曜日

３千円で楽しめるARMマイコンとRTOSの世界 (TOPPERS/ASP on LPCXpresso LPC1768)

= 謝辞 =
TOPPERS/ASP for LPCは@suikan_blackfinさんによってポーティングされました。
氏は様々な鋭い洞察力で過去にも沢山の偉業を成し遂げている方です。
ここに過去の沢山の偉業を挙げることは出来ませんが、素晴らしいポーティングに感謝すると共に、厚くお礼を申し上げます。
ありがとうございます。

氏のウェブサイトはhttp://d.hatena.ne.jp/suikan+embedded/にあります。

また、LPCXpressoはNXPセミコンダクターズジャパンさんが積極的に国内市場への展開を行って下さっています。このような安価で優れたツールを手に入れることのできるのは、嬉しい限りです。
NXPセミコンダクターズジャパンさんが運営されている日本語サイト(LPCZone)はhttp://www.nxp-lpc.com/cgi-bin/linkv.htmlにあります。

いずれのサイトも沢山の面白い情報が盛り沢山ですので是非ご覧下さい。

= はじめに =
TOPPERS/ASP for LPCはTOPPERS/ASPをNXPセミコンダクターズのLPCシリーズ上で
動作するようにしたもので@suikan_blackfinさんがメインテナンスされています。
http://sourceforge.jp/projects/toppersasp4lpc/

公開当初から完成度が高く、私も簡単に動作させて楽しむことができました。

TOPPERS/ASPはプロジェクトの性質上、商用のツールを使う前提でソースコードや周辺ファイルが公開されている事が多いのですが、これが障壁となって沢山の人が挫折するような状況でした。

そこで、今回は沢山の方にTOPPERS/ASP for LPCを楽しんで頂くためにLPCXpressoさえあれば楽しめるようにしようと考えました。

従来は評価用ボードに加えて、JTAGデバッガ、環境構築など様々な準備が必要でしたが、TOPPERS/ASP on LPCXpressoを使えばLPCXpresso上で簡単に動作させることができるようになります。

そうです。
LPCXpresso LPC1768(あるいはLPC1769)さえあれば良いのです。
従来のように高価なデバッガやRTOSを購入する必要はありません。

= 対応環境について =
ホストOS環境はLPCXpressoが対応しているLinux環境に今回は限定しました。
TOPPERS/ASPのビルドシステムにはシェルとperlに依存する箇所があります。
Windowsでも様々な外部ツールを使って、依存する環境に近い状況を作り出す事が可能ですが、今回は作業負担を軽減させるために割愛しました。

最近ですとVMware Player上で簡単にLinux環境が構築できますし、WindowsとLinuxの両環境で対応できるように沢山の時間をかけるよりも、早く提供したいという思いが先行した結果でもあります。

参考までに動作を確認した環境を記します。

* Ubuntu 10.10
* LPCXpresso 3.8.2 [Build 129][31/01/2011]
* LPCXpresso LPC1768 REV A

今回公開するプロジェクトの源流になったものは、TOPPERS/ASP for LPCのリリースのうちMisc. / LEDBLINK LPCXPRESSO 1768 1.6.0です。

= オリジナルからの変更点 =
@suikan_blackfinさんがお作りになったオリジナルから行った変更について記します。
変更は
* デバッグをIDE上でできるようにすること。
* 極力TOPPERS/ASPのオリジナルとの差分を小さくすること。
* LPCXpressoのみで実現可能なこと。
を念頭に作業しました。

ソースコードとビルド用ファイルについては以下の変更を行っています。
* 元々あったlpc1768_sram.ldとlpc1768_rom.ldを削除しました。
* LPCXpressoが生成したDebugとReleaseのリンカスクリプトを使用しました。
-> ENTRY(ResetISR)をENTRY(_start)に変更しました。
-> STARTUP(start.o)を追加しました。
-> __bss_start, __bss_endを追加しました。
-> __idata_start, __idata_end, __data_startを追加しました。
-> init_hook関数をPROVIDEで追加しました。
-> .isr_vectorを.vectorに名称を変更しました。
* kernel/target/lpc1768_generic_gcc/Makefile.targetに以下を追加しました。
-> CDEFS=-DDEBUG -D__CODE_RED -D__REDLIB__
* Makefileで生成されるオブジェクトの名称を変更しました。
* Makefileで生成されるオブジェクトの拡張子を変更しました。

LPCXpressoのプロジェクトに対しては以下の変更を行っています。
* Debug ConfigurationsのDebuggerタブでStop on startup at: main_taskに変更しました。
* Debug ConfigurationsのDebuggerタブでVector catch: Trueに変更しました。
* PropertiesのC/C++ BuildでGenerate Makefiles automaticallyのチェックを外しました。これによりLPCXpressoは外部Makefileを参照するようになります。
* PropertiesのC/C++ BuildでBuild directoryからDebugとReleaseを削除しました。
これによりプロジェクトのルートディレクトリを参照する形になりMakefileとの整合性が確保されます。

= 使い方 =
Linux上のLPCXpressoで使用できます。
ダウンロードしたzipファイルは展開せずにLPCXpressoの「Import Example project(s)」で使用します。

Browseボタンを押してダウンロードしたzipファイルを選択します。

Nextボタンを押すとzipファイル内にあるプロジェクトが表示されます。

Finishボタンを押すとワークスペースにプロジェクトがインポートされます。

インポートができたらLPCXpresso上でビルドして下さい。

場合によって、コンフィギュレータのビルドが必要かもしれません。
展開したディレクトリのトップにconfigureがありますので、それを実行して下さい。

ビルドが完了したらDebug 'TOPPERS-ASP_LPCXpresso-LPC1768'でデバッグできます。

Debugを選択してOKボタンを押してください。
以下のようにmain_taskで実行が停止すると思います。

ここまで来れば色んな事がIDE上で楽しめるようになっています。

RunメニューからResumeを選択してみて下さい。
LPCXpresso上のLEDがチカチカ点滅すると思います。

次にRunメニューからSuspendを選択して下さい。
実行が停止し、停止した箇所のソースコードが表示されます。

Disassemblyパネルを見ればC言語のソースとアセンブラの両方を確認しながらデバッグできます。

また、RTOS関連では欠かせないCPUレジスタも以下のように簡単に確認することができます。

上記のようにLPCXpresso購入後、今回のTOPPERS/ASP on LPCXpresso LPC1768のzipファイルをダウンロードするだけで、TOPPERS/ASPのアプリケーション開発を体験することができます。
IDE上でソースコードを見ながらResume, Suspendなど便利な機能が使用できる点も見逃せません。

皆さんご存知のとおりLPCXpressoを購入することで使用できるLPCXpresso IDEはコードサイズ128KBの制限があります。
しかしながら、手軽にRTOSを楽しむことのできる環境を構築できることを考えると、なかなか優れた投資効果が得られると言えるのではないでしょうか。

= ダウンロード =
このファイルを使ったことによる如何なる結果も当方では責任を負えませんので、この点を御了承頂いた上で御利用下さい。
ファイルのダウンロード：こちらをクリック
（今後バージョン管理システムへの移行を考えています。）

= 最後に =
今回の対応は既存のTOPPERS/ASPのビルドの枠組みを超えない形で行ないました。
本来であれば、LPCXpresso上のプリビルドやポストビルドを駆使してカーネルに
対するコンフィギュレーションなどを行うのが筋ですが、先に述べたとおり早めの
公開を目指して割愛したものです。

もし、何かシンプルな方法でコンフィギュレータまでを包括的に処理させることが
できる方法を思いついた場合、是非ご一報頂ければと思います。

= お勧め書籍 =
今回の対応作業で参考にさせて頂いた書籍を紹介します。
* 起動プログラムブート・ローダ入門
邑中雅樹さんの「TOPPERSで学ぶuITRONのブート・シーケンス」は必携です。