2013年3月31日日曜日

DMAバッファ管理手法の続編

シンプルな制御モデル

昨年10月の投稿「ビデオやオーディオのDMAバッファの管理手法 (動かして遊べるソースコード付き!)」では、ビデオやオーディオなどを扱うファームウェアで、DMAバッファをどのように扱うと良いのかについて述べました。

先の投稿で上げた制御モデルは以下のようなシンプルなものでした。



この制御モデルは、巷でよく見かける配列のインデックスを使って制御する方法よりも抽象化が可能で、チャネル数の変更や遅延量の制御などを簡単に実現する事が可能です。

このシンプルな制御モデルの応用可能範囲は、ビデオやオーディオに限りません。

例えば、データロガー等の場合、出力側にSDカードのような書き込み処理に時間がかかる物を配置する事があります。
この場合、viproc側でデータ収集設定(DMA設定)、voproc側でSDカードへの書き込みという事になります。

何がポイントですか?

先の制御モデルのポイントの一つは「queueによって入出力の関係が切れている」事です。
実は先日のシンプルな制御モデルは非常にシンプルにした一例で、実際に使用する場合にはもう少し思考を進める必要があります。

話を先に進める前に簡単にポイントを振り返っておきましょう。
  1. 遅延器(DELAY)は、DMAリクエスト発行からDMA完了までの時間を保証する。
  2. キュー(QUEUE)は、処理時間が一定でない後段に前段が影響を受けないようにする。
  3. 遅延器(DELAY)とキュー(QUEUE)によって、入力と出力の時間依存関係を緩いものにする。
入力側と出力側の両方でDMAを使用する場合も考慮して、先のシンプルな制御モデルに対して少し思考を進めてみましょう。


今回は対象領域も明確にしておきました。

入力処理では、入力キューからバッファを取得し、DMAリクエストを発行した後、入力遅延器にバッファを格納します。加えて、入力遅延器から出力キューに過去のバッファを移動させます。
出力処理では、出力キューからバッファを取得し、DMAリクエストを発行した後、出力遅延器にバッファを格納します。加えて、出力遅延器から入力キューに過去のバッファを移動させます。

上記文面を見ておわかり頂けると思いますが、入出力で完全に対称系になっています。

上記モデルを使用する事で、先に挙げたようなチャネル数の変更や遅延量の制御だけでなく、入出力の位相が曖昧な場合でも制御が破綻するような事がありません。

上記の制御モデルを使用する場合、以下のような事も考慮すると良いでしょう。
  • 入力と出力は別々のハードウェアが担当しているのが普通。
    • 入力割り込み、出力割り込みは非同期系として設計する。
    • RTOSを使用する場合、入力と出力の処理スレッドは別々に設計する。
  • キューから取り出せない場合、どのように振舞うべきか?
    • 制御系が何を期待するのかによって挙動を決めます。
  • 全体をリセットする場合、どのようにリセットすべきか?
    • これは意外に難しい問題です。
    • ハードウェアがどのように振舞うのかによっても大きく変わります。
  • その他。(色々あります)

    動かして遊べるソースコード

    今回も動かして遊べるソースコードを用意しました。
    先の投稿のソースコードと見比べてみるのも楽しいと思います。

    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さんに感謝いたします。

    2013年1月24日木曜日

    安価な基板CAD、Proteusの新バージョンが予想通り登場しました。

    Proteus 7のデモバージョンを試す(EAGLEの上にも10年)では、気になっていたProteusというCADの簡単な評価を行ないました。
    暫く購入を検討していましたが、「待てよ。そろそろメジャー番号が変わるようなタイミングだなぁ。」と思って慌てて購入する必要はないと判断していました。

    そして予想通り、新しいバージョンが発表になっています。
    その名もProteus 8です。


    起動時の画面は、以下のように新しいデザインが採用されています。



    画面の基本デザインは一切変わりませんが、Proteus 7では別々のウィンドウで扱っていた回路設計と基板設計が、一つのウィンドウ内で実現できるように改良されています。タブで回路と基板を行き来できるようになっています。



    このように回路も基板も同じウィンドウで。



    上位クラスから実行可能な3D表示も健在です。



    BOMメニューはそういえば評価していませんでしたが、きっと新しくなっているのでしょう。
    部品毎にコストを登録しておけば簡単に算出できるようになっています。



    気になるラインナップとお値段ですが、コマーシャルライセンスで見ると以前より少しだけ高くなった気がします。
    特にネットリスト中のピン数が2000ピンを超えるライセンスからでしょうか?




    何だか暫くしたら購入してしまいそうです。

    2013年1月20日日曜日

    ドキュメンテーションプロジェクト始めます (LCD Toolのドキュメントで感触を掴む)

    プロジェクト進行の再考

    昨年末から色々なプロジェクトの進行について再考していました。

    現在もフォーカスを続けているプロジェクトを挙げると・・・
    と小粒ながら、同様の問題で困っている人にはとてもよくわかるツール群を公開しています。

    で?何を再考?

    さて。
    どのプロジェクトのウェブを御覧頂いてもわかるように、ドキュメントの品質たるや酷いものです。

    そこで、2013年の注力事項の一つとしてドキュメンテーションプロジェクトを開始する事にしました。
    どんなに素晴らしいツールを作っても、それが世の中で認知されなければユーザも増えません。

    どんな課題があり、それをどのように解決するのか。
    そして、副次的なメリットとしてどんな嬉しい事があるのか。
    これらを適切に説明し、まずは使ってもらおうという事なのです。

    手始めに

    いきなり全部のドキュメントを改良する事なんて現実的ではありません。
    いずれのツールも最初に設計してから少し時間が経っているので見直したい箇所もあります。
    そこで、手始めに何となく形になりそうなものから着手する事にしました。

    ここ最近のツールの中でLCD Toolというユティリティがあります。
    「LCDの画面表示ってドキュメントで作るの面倒だよねー。」という方の為に作ったツールです。

    以下のような感じで第1バージョンを仕立ててみました。



    まだまだざっくりですが、以前のドキュメントとは比べ物にならないくらい印象が変わりました。
    新しい製品の場合、「使ってみようと思えるかどうか?」が第1ポイントのような気がしています。

    あらためて「ドキュメントは重要」という認識。
    もう「そうは言っても面倒」なんて言っている場合ではありません。

    ダウンロード

    作業中のファイルのスナップショットをこちらからダウンロードできます。

    2013年1月1日火曜日

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

    2013年、本年もよろしくお願い致します。
    CuBeatSystemsは、日本の物作りを少し明るくしたいという方向で情報公開しています。
    今年も引き続き微力ながら活動を続けますので皆様何卒よろしくお願い致します。