2013年2月24日日曜日

nanoKONTROL2を小規模組み込みシステムのユーザインターフェースとして使うお手軽な方法

便利だったけど・・・

2012年初頭からネチネチネチネチ続けているオーディオ・プラットフォーム開発。

オーディオ・プラットフォーム開発用にでっち上げたベース基板には、予めオーディオ・プラットフォームで使用するであろう「何らかのパラメータ設定手段」を提供するために、LCDとロータリースイッチを搭載しました。


ロータリースイッチでクルクル回転させてグシッと押せば、即座に設定完了という操作系です。
これはこれで便利だったのですが、パラメータが複数に渡ってくると操作性に不満が出てきます。

今回ご紹介する新しいアイデアは、2012年の11月の時点で試作まで完了していました。
すっかり別件で忙しくて忘れていたのですが、どのようなものなのか御紹介しようと思います。

nanoKONTROL2

nanoKONTROL2とは、KORGが販売している音楽制作環境向けのコントロール・サーフェースです。
USB経由でパソコンに接続し、音楽制作環境で色々操作できるというもの。


このように沢山のスライダーとノブが搭載され、複数のパラメータを調整するにはもってこいです。


この手のコントローラはMIDIイベントを送受信できるように設計されています。
MIDIイベントを受信するソフトウェアをホスト上に仕立て、組み込みシステムに指令を与えれば完成というわけです。
組み込みシステムはホスト上から制御出来れば、特別に何かする必要はありません。お手軽ですね。


単にホストに接続できるコントローラを購入しさえすれば、複数のパラメータを直感的に操作可能なユーザインターフェースをシステムのサービスとして提供できるようになるのです。

動作の様子

それでは動作の様子を動画で御紹介します。



上記のように複数のパラメータをサクサクゴニョゴニョする事ができます。

同時に複数のパラメータを直感的に操作できるのが嬉しいポイント。
癖になってしまいそうな感覚です。

まとめ

今回のアイデアは様々なところに応用する事ができます。

このようなコントローラは安価で入手しやすいというのも嬉しいメリットの一つ。
これらのインターフェースを直接組み込みシステムに搭載しようと考えたら大変です。
直感的なインターフェースを実現するための部品コストは馬鹿になりません。

お手軽に使えるところを使う事で、素早くシステムとしてのサービスに仕立てる事が可能です。

2013年2月17日日曜日

簡単便利なBlackfin用フラッシュ書き込みツール「Blackfin BlueBoot」のVersion 0.3.0をリリースしました。

Blackfin BlueBootってなぁに?

Blackfin BlueBootってなぁに?という方は、「Blackfin BlueBoot - Blackfinに接続されたブート用外付けフラッシュ・ロムを書き換える事ができるソフトウェアのデビューです!」を御覧下さい。

Blackfin BlueBootの開発プラットフォーム

2012年の12月に最初のリリースBlackfin BlueBoot Version 0.2.0をリリースしました。

このBlackfin BlueBootは、「DSPに興味はあるけど環境整備の敷居が高くて手を出せない!」という人のために設計実装した開発ツールです。メーカー純正ツールなら外付けフラッシュに書き込めるけど、それはまぁだいたい10万円です・・・なんて簡単に手を出せる物ではありません。

Blackfin BlueBootによって、無償の外付けフラッシュ書き込み環境を実現しています。


Blackfin BlueBootの開発には、市販されているDSPボードとオーディオコーデックボード用を搭載できるベース基板BlueTankを開発して使用していました。これ一台さえあればオーディオ入出力プラットフォームになるという算段です。これはなかなか便利なものでした。例えば、以下のようにオーディオアプリケーションを簡単に楽しめるようになっています。


「これ一台で」というのがポイント。

ベース基板BlueTankは自分で設計しているのでI/Oの取捨選択は自分でできます。
自分が欲しくないI/Oがてんこ盛りになった評価基板なんていらないのです。

便利なオーディオプラットフォームが登場


さて、前述の市販されているDSPボードとオーディオコーデックボードは、金子システム社製のものでした。これ一台(一枚?)でDSPが楽しめますなシンプルなボード構成がとても気に入っていました。


前述のBlueTankには同社製「DSP基板」と「オーディオコーデック基板」が搭載される形式でした。

そんな折、新しく仕入れたのがTUNA-CANと呼ばれる新しいオーディオプラットフォームです。
なんと、このTUNA-CAN基板は「DSP」と「オーディオコーデック」の2つが1枚の基板にコンパクトにまとめられています。

以下がその写真です。


これにLCDとロータリースイッチを付ければもう「BlueTankいらず」です。
この新しいプラットフォームに触発され、新しいバージョンをリリースする事にしました。

Blackfin BlueBoot Version 0.3.0

新しいBlackfin BlueBoot Version 0.3.0では、主に以下の変更を行ないました。

  • 書き込みセクタ数の算出バグを修正。
  • LDRファイル選択時にLDR情報が更新されないバグを修正。
  • TUNA-CAN用ブートローダをリリースに同梱。
  • ホスト側I/Oライブラリのソースコードを同梱。
  • 日本語ローカライズに対応。
ダウンロードはこちらからどうぞ。

まだまだ修正したい事は沢山あるのですが、それを待っていたらリリースができません。
今回はタイミング重視で、小さく更新してリリースする事にしました。

その他

実はBlackfin BlueBootの初版をリリースした後、別の類似ツールを作っていました。
その話と関連したあれこれは、別途機会を見てご紹介する予定です。

酔漢さんが運営されているDSP空挺団では、「ブレッドボードで作るオーディオ信号処理」が公開されています。
こちらの投稿もお勧めです。

2013年2月10日日曜日

小規模組み込みシステムの入出力ライブラリntstdioモジュール

簡単便利なChaNさんのxprintfモジュール

libcの存在が期待出来ないような小規模組み込みシステム開発において、意外に億劫なのは端末入出力です。newlibなど便利なライブラリが世の中には存在しますが、フットプリントと使用する関数がバランスしないケースも多々あります。

実際にここで代替関数を作ってニンマリしたいところですが、「本当に開発したいものはそれじゃない」ということで後回しにしていました。その類の物は沢山作っていて、そちらが忙しいというのもあったりします。

とある開発作業を進めるうちに、ChaNさんが便利なライブラリ(http://elm-chan.org/fsw/strf/xprintf.html)を提供されている事を思い出し、組み込んで楽をしていました。
ChaNさん、ありがとう。


RTOSベースのシステムでxprintfを使う

ライブラリというのは、ざっくり言うと上層が楽をするために存在するものです。
便利なライブラリというのは、あっちにもこっちにも使うようになります。
xprintfも例に漏れず、対象システムの中で活用箇所が増えていきました。
「あぁ、これは便利だ。」となるわけです。

使っていたシステムの概略を示すと以下のようになります。
本当は他にも色々と付いているのですが、今回の説明に必要ないので省略しています。


UIOは、システム操作子の動作を監視して、ユーザの要求をシステム制御タスクに伝達するタスクです。
Shellは、シェル用インターフェース(今回の場合、シリアルポート)経由で行なわれるユーザの要求をシステム制御タスクに伝達するタスクです。
Systemは、外界からの要求を基に、システムを望む状態に制御するタスクです。
Displayは、内部タスクからの表示要求を基にディスプレイを制御します。

ちなみに、上記のシステムで使用しているRTOSはスレッドモデルを採用したOSです。
なので、タスクと言っても中身はスレッドです。

さて、当初xprintfはShellタスクの表示用として使用していました。
少し開発が進んだところで他のタスクでも使いたくなってきました。

システムの全体統括を行なっているSystemタスクは、メニューコンテキスト生成も行なっています。
文字列の整形があるので「ここで使えば便利だな」という算段でした。



おっと。
だんだんと話の雲行きが怪しくなってきましたね。


もうお気付きかもしれませんが、xprintfはスレッドセーフではありません。
入出力関数へのポインタは処理によって書き換えられます。
加えて、出力箇所を指し示す文字列へのポインタも状態によって書き換えられます。


ここでxprintfモジュールが内部でどのような依存関係になっているのか見てみます。
(2011年4月14日に公開されたバージョン)


xprintfは、内部エンジンxvprintfに書式解釈と出力を委任する形をとっています。
上記依存関係への視点は、Shellタスクでの使用のみを考えた場合に限っては悪くありません。

では、Systemタスクで文字列整形に使った場合、どうなるでしょうか?
先ほど検討した依存関係の範囲は、全く役に立たなくなります。


例えば、Systemタスクでxsprintfを使い始めた場合、競合操作が起きる結果になります。
これはxputcが何をやっているのか見る事ですぐにわかります。


xputcには、「outptrが0でない時にoutptrが指し示す箇所に文字を入れて戻る」があります。
それ以外の場合、xfunc_out関数で文字を出力ですね。

一方でxsprintfを見ると、「与えられたバッファへのポインタをoutptrに代入してxvprintfを呼ぶ」という処理が記述されています。


先ほどの依存関係を見れば明らかですが、xprintfもxsprintfも内部ではxvprintfを呼び出しています。両者は、xvprintfの先で同じロジックを通過しており、その先でグローバル変数を見ている以上、操作競合は避けられません。

最初にシステムで使用し始めた時は「このタスクのみで使用」と割り切って使っていました。それを忘れてひょいひょい使い始めたからさぁ大変。シェル経由で状態取得しながら操作子いじると、時折システムがおかしな挙動になる始末でした。

趣味で作るような単純なシステムの場合、疑いのある箇所への着目は比較的簡単です。
今回はかなりのデバイスが制御対象になっていたので、他の要素に気を取られすぎていました。


まぁ気付けば簡単、話に書いてしまうのも恥ずかしいような内容です。

xprintfをベースにしたntstdioモジュール

さて、現場で起きた問題を基に、何かを考えるのがCuBeatSystemsのお仕事です。

そのまま当初の方針に従いShellタスクでのみの使用として解決しても構いません。
が、それでは未来の自分や他の開発者が同じような間違いをしかねません。
そこで、xprintfをベースに、RTOSベースシステムでも使用可能な物を試作してみる事にしました。

名付けてntstdio。
ハンドラ毎にI/O関数を設定可能な構成としました。
RTOSベースシステムでも安心して複数の箇所に使用する事ができます。

使い方は簡単です。

ntstdio_initにハンドラへのポインタ、出力関数、入力関数へのポインタを渡します。
ハンドラへのポインタを呼び出しに加えるだけで、ChaNさんのxprintfと同様に使う事ができます。


冒頭で挙げたシステムの場合は以下のようになるでしょう。
  • Displayタスクでは出力関数にLCD表示関数を設定して使用。
    • xprintfするだけでLCD表示が可能!
  • Shellタスクでは入出力関数にUART入出力関数を設定して使用。
    • xprintfするだけでUART出力が可能!
  • Systemタスクでは書式整形関数のみを使用。
    • 他の操作と競合せずに書式整形が可能!
従来のxprintfの実装の場合、RTOSの複数の箇所で美味しく頂く事は出来ませんでしたが、ntstdioを使えば上記のように色々な箇所でChaNさんのxprintfを楽しめます。

ダウンロード

試作したntstdioモジュールのダウンロードはこちらからどうぞ。

2013/02/16追記
公開当初よりちょっぴりアップデートしています。
最初にダウンロードされた方は再度ダウンロードされる事をお勧めします。

謝辞

常に素晴らしいアイデアとナレッジと実装を公開して下さるChaNさんに感謝いたします。