約3年ぶりとなるNatural Tiny Shell (NT-Shell)の新しいバージョン0.3.0をリリースしました

数ヶ月前からやろうやろうと思っているだけで進んでいなかったNatural Tiny Shell (NT-Shell)の新しいバージョン0.3.0のリリースを実施しました。今回のバージョンからライブラリとサンプルのディレクトリを分離し、何がライブラリで何がサンプルなのか一目で理解できるようにしました。現在のところ、ACB-BF592のベアメタルなプログラムがサンプルとして追加してあります。

また、これを機にA tiny MML parserのリリース活動で得たヒントも踏まえてウェブサイトも少し新しくしました。今までのサイトは、何と言うか一応公開してありますという雰囲気で、何が何だかさっぱり意味分かりませんでした。

http://www.cubeatsystems.com/ntshell/index.html

このブログを通じて幾つか改良のヒントも頂いているので、今後の開発の中で何らかの回答が出せるようにしていければ良いなぁと考えています。

ACB-BF592とUMB-SGTL5000を使ったTalk ThroughをTOPPERS/JSP上で実現する

オーディオ・プラットフォーム・プロジェクトであるBlueTankも、ベース基板が上がってきて半年が経とうとしています。その間にベア・メタルなアプリケーションは幾つか実装したのですが、そろそろ色々な不満が出てきました。

Blackfin BF592は、ARM Cortex-Mシリーズ等と比較しても有り余るプロセッサ能力を持っています。簡単なサンプル・プログラムならともかく、システムとして様々なサービスを提供するのにRTOSを使って楽をしたくなってきました。RTOSを使えばNatural Tiny Shell (NT-Shell)もシステム・シェルとして提供できます。「ビデオやオーディオのDMAバッファの管理手法 (動かして遊べるソースコード付き!)」をRTOS上で試してみたいというのもあります。

プロジェクトを始めた当初はフラッシュ・ロムへの書き込みも出来なかったため独立した組み込みシステムとして動作しませんでした。Blackfin BlueBootを実現した事で独立した組み込みシステムとしての道筋が見え、だんだんと欲も出てきました。

幸いにも、DSP空挺団の酔漢さんが「ACB-BF592とTLV320AICを使ったTalkthroughサンプル。TOPPERS/JSPベース。 (bf592_tlv320aic23b_talkthrough) 」というものを公開して下さっています。このプロジェクトは、TOPPERS/JSP for Blackfin上に、使いやすいI2C制御層が組み込まれた上、オーディオ・フレームワークUZUMEが実装されています。

BlueTankプロジェクトにおけるRTOS環境の出発点として、この酔漢さんの成果物をふんだんに活用させて頂く事にしました。これは本当に有難い話です。

TLV320AIC23BもI2Cインターフェースを持つデバイスですから、UMB-SGTL5000に搭載されているオーディオ・コーデックに対する処理も、少しの改造で可能だろうという算段。実際に酔漢さんの丁寧な設計実装のおかげで、ものの３分でBlueTankでもTalk Throughが動作するようになりました。ちなみに、オリジナルのコードは、レジスタ互換のSSM2603が搭載されたUMB-SSM2603でも動作します。

唯一変更したソースコード : uzume.c

対応は至って簡単で、init_codec関数の中身を少し変更しただけです。

今回のTalk Throughは、氏の進めているUZUMEフレームワーク上に構成された物です。

BlueTankプロジェクトも、UZUMEフレームワークを使って色々と実験を進めようと考えています。

素晴らしいプロジェクトを公開して頂いているDSP空挺団の酔漢さんには感謝感謝です。

マルツパーツ館さんでDSP基板とオーディオコーデック基板が販売になりました

BlueTankで愛用しているDSP基板とオーディオコーデック基板がマルツパーツ館さんで販売になりました。

http://www.marutsu.co.jp/shohin_158707/

http://www.marutsu.co.jp/shohin_158709/

「DSPってもっと遠い世界の事だと思っていた」という人でも安心して手を伸ばせる価格設定。

先日実装したBlackfin BlueBootもこの基板で使えるようになっています。

VisualDSP++が無くてもフラッシュロムの書き込みに困る事はありません。

Blackfin BlueBoot - Blackfinに接続されたブート用外付けフラッシュ・ロムを書き換える事ができるソフトウェアのデビューです！

このプロジェクトって何なの？

Blackfin BlueBootとは、Blackfinに接続されたブート用フラッシュ・ロムを書き換える事のできるソフトウェアです。

ターゲット用の専用ブート・ローダとホスト用の専用アプリケーションから構成され、両者が協調動作する事でBlackfinに接続されたブート用フラッシュ・ロムの書き換えを実行します。

Blackfinは、SPIに接続された外部フラッシュ・ロムからブートさせる事ができます。
しかし、Blackfinは予めどんな外付けフラッシュ・ロムが接続されるのか知るよしもありません。

当然のようにBlackfinが外付けフラッシュ・ロムの書き換え機能を持つわけもなく、「一体どうやったら書き換えができるの？」というわけです。

Analog Devices社は、同社純正ソフトウェアであるVisualDSP++でこの問題を解決しており、Blackfinに接続されたフラッシュ・ロムの型式を選択する事で、GUIから書き換えができるようなサービスを提供しています。

うーん、さすが有償ツール！なんて感動している場合ではありません。
VisualDSP++はとても高価なツールです。
業務で使うならまだしも、趣味のDSP開発で手の出せる金額ではない事がわかりました。

Blackfin BlueBootは、このような背景から高価なツールを購入せずともBlackfinに接続されたフラッシュ・ロムを書き換えられるようにしようというプロジェクトです。

プロジェクトのゴール

このプロジェクトは、以下のゴールを設定しました。

• Blackfin搭載のターゲットに対応可能な事。
• 幅広いフラッシュ・ロムに対応可能な事。
• とにかく簡単に使える事。
• ユーザが自由にターゲットを追加できる事。
• 業務でも趣味でも少ない制約で利用できる事。
• 入手性の良いDSPボードを使って実例を示す事。
• CUIとGUIでホスト側ツールを用意する事。
• 将来的にWindows、Linux、Mac OSのプラットフォームをサポートする事。
• ターゲット側のコードは公開し、幅広く利用してもらえるようにする事。
• その他。

上記のゴールを基に設計したのが、今回公開するBlackfin BlueBootです。

簡単に使える

Blackfin BlueBootが標準でサポートするBlackfin基板を使う場合、特に簡単に使う事ができます。

最初にリリースされるWindows版における動作を見てみましょう。

インストーラでソフトウェアをインストールすると、デスクトップにアイコンが作られます。

ダブルクリックしてソフトウェアを起動します。

ソフトウェアを起動すると、以下のような画面が出現します。

初めに行なうのは、ターゲットとホストを接続するシリアル・ポートの設定です。

次に標準的にサポートされているターゲット・ボードの選択を行ないます。

このリストにないターゲット・ボードの場合、インストール先ディレクトリに公開されているターゲット用ソース・コードと設定ファイルの更新により、独自にブート・ローダを記述する事で対応させる事ができます。（これは後日、別途記事を書きたいなぁ。）

最後に、使用するブートローダとアプリケーションを指定して選択は完了です。

Boot Loaderとは、初段でターゲットに流し込むフラッシュ・ロム書き換え用プログラムです。

Boot Loaderを流し込んで書き込みを行なう場合、ターゲットをUARTブート・モードにしておく必要があります。

Applicationとは、ターゲット上のフラッシュ・ロムに書き込むバイナリを指します。

Applicationは、初段で流し込んだブート・ローダを経由してフラッシュ・ロムに書き込まれます。

こんな風に「シリアル・ポート」、「ターゲット・ボード」、「ファイル」の３つの選択をするだけで、即座に書き込みを実行できるのがBlackfin BlueBootです。

ちょっと便利なLDR表示機能

単に書き込めるだけでは面白くないのでBlackfinで使用しているLDRファイルの属性も表示できるようにしました。

Version 0.2.0ではBF592形式しか対応していませんが、順次対応を拡大しようと考えています。

あ、DEADBEEFなんて洒落ていますね。

ダウンロード

• こちらからダウンロードできます。
• 2016年2月27日現在：ウェブサーバーを変更し http://cubeatsystems.com/software/bfin-blueboot/bfin-blueboot_ja.html で公開しています。 @GarageStyleMscさんにお問い合わせ頂きました。ありがとうございます。
• ライセンスはMITです。
• 業務の開発に、趣味の開発に存分に御活用下さい。
• 無保証です。使用した結果起きる如何なる損害も当方は責任を負いません。

関連文書

• 先日の記事でM25P16の書き換えコードを公開しました。
• DSPいじりを楽しみたい方には、金子システム株式会社さんが販売されているACB-BF592をお勧めします。
• DSPなどの話題が盛りだくさんの酔漢さんのページ、DSP空挺団もお勧めです。

まとめ

今回のBlackfin BlueBootツールは、これからBlackfinを使ってみたいけどツールは高価で手が届かないという人にも、手軽にDSPを体験して頂く事のできるツールとして設計しました。

Blackfin BlueBootで用いた、「第１段階に書き換え機能を持ったプログラムを流し込み」、「本当にやりたい事を第２段階でやる」という手法は、一般的に用いられる手法の一つです。
実はXilinx社のFPGAツールでもプラットフォーム・フラッシュの書き換えで同様の手法が用いられていたりします。

世の中の色々なツールの動作を観察してみるのも意外に面白いかもしれませんね。

BlueTank BF592 FFT Graphical Spectrum Analyzer

Analog Devices社Blackfin BF592搭載オーディオ・プラットフォームBlueTank BF592を使ったグラフィカル・スペクトラム・アナライザーです。



2x8文字のLCDですが、都合の良い事に8文字のユーザ・フォントを登録する事ができます。
1文字1バンドで考えてしまうと8バンドしか表示できません。

でも、1ピクセル1バンドとして考えると5ドットx8文字で最大40バンドの表示が可能になります。
この基板設計時に考えた事をようやく実現する事ができました。
8文字表示のLCDを選択したのは、単に「コンパクトだから」というわけではなかったのです。

今回のサンプリング周波数は48,000[Hz]でFFT計算サイズは64です。
なので周波数軸での分解能は750[Hz]という事になります。

750[Hz]の分解能で40バンドまで表示できる事を考えると、ナイキスト周波数の範囲まで十分に表示できる事がわかります。
FFT計算サイズの内部定義を一行書きかえるだけで、表示側も連動するように実装しました。
折り返し成分を表示しないようなガードも入れてあります。

BlueTank BF592に対するオーディオ・フレームワークの実装もかなり進みました。
上記のコードはフレームワーク層のコードを除くとコメントを含んで約300行の実装で済みます。
(コメントが何行なんだ！)

アプリケーション共通の処理は全てオーディオ・フレームワーク側に隠ぺいしました。
main.cみたいな小さなアプリケーションの実装のみで上記のような処理を実現する事ができます。

ちなみに、上記のアプリケーションは天ノ岩戸のmayaさんが実装したFFTアナライザを改造して作りました。この場を借りてお礼申し上げます。

そして、オーディオ・フレームワークについてはDSP空挺団の酔漢さんの作られたUZUMEにかなり影響を受けています。最初はUZUMEのミニマム・プラットフォームとしてBlueTank BF592を仕立てる計画でしたが、似ても似つかない物になってしまったのでもじってUZURAというフレームワーク名を付けました。変なフレームワークで本家や市場に混乱や迷惑をかけない措置です。

ちょっと借り物競走みたいなプロジェクトになってきましたが、まだまだBlueTank BF592遊びは続けようと考えています。

オーディオ・プラットフォームBlueTankの始まりとUZUMEオーディオ・フレームワーク

まえがき

先日からBlueTankだとか何とか書いていて、経緯を知らない人にとっては「何を言っているの？」という感じです。この記事では、オーディオ・プラットフォームBlueTankの始まりとUZUMEオーディオ・フレームワークについて触れたいと思います。

前々からオーディオ装置の開発をやりたいなぁと考えているわけですが、それっぽい入口を仕立てる度にシェルを作るのに忙しくなったり、デバッグ用ツールを作るのに忙しくなったりと何をやっているんだという状態です。

そうは言えども、徐々に何をどう進めようかという指針が明確になってきました。

まずは下回りを固めようという事でオーディオを簡単に扱うためのフレームワークを構築しようと考えるわけですが、実はDSP空挺団をホストされている酔漢さんが既に完成度の高いフレームワークを構築されています。

ということで、後はお手頃なハードウェア・プラットフォームを構築して、その上でフレームワークを使って楽しめば良いじゃないかとなるわけなのです。

ハードウェア・プラットフォーム

以前にBlackTankを設計した時に面倒な思いをして、「これを続けるのは大変だなぁ」と考えていました。
もっと手軽なプラットフォームで開発したいと考えたわけです。

そこに現れたのが金子システム社のDSP基板です。
お値段とサイズがコンパクトなのでほぼリスクなし。

こいつを載せるベース基板を作りさえすればスタートできるなぁと考えていました。

で、作ってみたのが以下の写真・・・。（え？）

基板マニアの私としては、この手作り感がどうしても許せません。
そして、複数個作れと言われても作る気になれません。
要するに、手作業でユニバーサル基板に配線する事に手軽さを感じませんでした。

結局のところ簡単なベース基板を設計する事にしました。
それがBlueTankとなったのです。
とはいえ、DSP基板上にほとんど必要な部品が搭載されているため、ベース基板の回路はスカスカです。

BlueTankで実現するかどうかわかりませんが、装置モノとして筺体設計も考えています。
BlueTankの基板はTAKACHIのLCS135-Hに収まるように設計してあります。

UZUMEオーディオ・フレームワーク

UZUMEオーディオ・フレームワークは、オーディオ処理に必要なリアルタイム制御部分を遮蔽し、オーディオの処理のみに注力できるように考えられているフレームワークです。

フレームワークでは、予め想定された用途の範囲でAPIが整備されています。

一部はBlueTankに適用できないので、対応はこれから考えますが、UZUMEオーディオ・フレームワークの比較的小さなプラットフォームの部類にBlueTankを該当させたい考えです。

「コンパクトなハードウェアで各種オーディオ処理の実験が可能！」というのがBlueTankの位置付けでしょうか。

プロジェクト・ページ

オーディオ・プラットフォームBlueTankにも、UZUMEオーディオ・フレームワークにも、プロジェクト・ページが存在します。興味のある人は訪れてみて下さい。

• オーディオ・プラットフォームBlueTank
• UZUMEオーディオ・フレームワーク

BlueTank ACB-BF592 (ACB-BF592とUMB-SSM2603のベース基板)

「ACB-BF592とUMB-SSM2603のベース基板を設計する」とか「外装から考えるDSPオーディオプラットフォーム - BlueTank ACB-BF592」で検討した金子システム社製DSP基板を使ったオーディオ実験用プラットフォームBlueTankの進捗状況です。

金子システムさんのコンパクトで使いやすいDIP型モジュールのお陰で、殆ど何も無いベース基板を作ればDSPを使ったオーディオ実験ができるようになりました。

組み立てた様子を示したのが以下の写真です。

転がっているSDカードと比較して頂くと、そのコンパクトな感じが伝わるのではないでしょうか。

USBのバスパワーで動作させる設計なので、これ1台を持てば色々な実験ができます。
単に2つのモジュールを接続して「使えます」と言うだけでは面白くないので、空きピンを使ってSDカードやLED内蔵ロータリーエンコーダーや赤外線受光素子なども搭載してあります。

SDカードから読み込んだ波形データを使ってオーディオ信号を発生させるアプリケーションを赤外線リモコンを使って操作するとか、そんな物をやってみると面白いかもと考えています。

ちなみに、「BlueTank ACB-BF592の印象に残るロゴを考える」でロゴまで考え、お洒落な?アイコンも基板に記されているわけですが、名称に反してどこも全然青くありません・・・。

あえて言うと、液晶とDSP基板が青い。
ちなみに、この名称はBlackTank LPC1769から始まりました。

BlueTank ACB-BF592の印象に残るロゴを考える

自分の設計した成果物が一体何であるのかを事前知識の無い人に伝えるのは結構大変です。

印象に残る物にするならなおさら。

名前は聞いた事があるけど何だっけ？みたいな物は数多くあります。

BlueTank ACB-BF592の場合、ACB-BF592とUMB-SSM2603というモジュールを使ったオーディオプラットフォームなのですが、単にオーディオプラットフォームと言ってしまうと何だか印象に残りません。

そこで、今回は「リモコンで制御できるオーディオプラットフォーム」という事にしました。

今回はちょこっとロゴを作ってみました。

スケッチはこんな感じです。
できるだけダサい感じを醸し出す為に何回かスケッチしてからCADに移行しました。

設計当初、リモコンでしか制御できない「リモコンで制御するオーディオプラットフォーム」でした。

よくよく考えてみると、ボードを使いたいユーザが同じリモコンを使えるとは限りません。
本体だけで手軽にデバッグしたい事だってあります。

これをふまえてロータリーエンコーダーを付けた為、キャッチフレーズも少し変更。

「リモコンで制御できるオーディオプラットフォーム」になりました。

振り返ってみるとどっちでも（どうでも？）良い気もします。

いや、もしかしたら「リモコンで制御するオーディオプラットフォーム」の方がゴロが良かったかも。

外装から考えるDSPオーディオプラットフォーム - BlueTank ACB-BF592

先日の記事「ACB-BF592とUMB-SSM2603のベース基板を設計する」で基板設計者の視点でベース基板を仕立てたわけですが、「EAGLEの図面からアクリ屋ドットコムさんに頼むアクリル外装部品のサイズを簡単に得る方法」とか「KOZOS EXPBRDの最終組み立て (廣杉計器さんのスペーサが届いたので組み立てた)」の作業をするうちに、別の視点から検討してみたくなりました。

以前から株式会社タカチ電機工業さんのプラスチックケースに基板を収める事をやっているわけですが、気付いたら何年もやっていません。

今回のオーディオプラットフォームの基板設計は「お気楽ベース基板設計」なわけですが、単にお気楽ベース基板設計だけというのもなんだかなぁという感じです。

そこで、寝かせておいた成果物を少し変更してプラスチックケースに収める事を考えてみました。

先日設計したベース基板のサイズを基に、近いサイズのプラスチックケースを洗い出します。

どうもLCS135H-Nという新しいシリーズに含まれるモデルが良い具合に該当しそうです。

基板外形を変更し、LCS135H-Nにぴったり収まるようにしました。

ケースの穴加工ですが、以下の部品に対する加工が必要です。

• LCD
• ロータリーエンコーダー
• 赤外線受光素子
• USB
• SDカード

加工穴数によって工賃が幾分変わるわけですが、今回の場合はどの程度になるでしょうか。

こればかりは頼んでみないとわかりません。

基板上がりと動作確認後までケースの発注は待ちなので、暫く保留です。

LCSシリーズにはシリコンラバーが付いてきます。

シリコンラバーに対する加工も場所によっては必要です。

ちなみにメーカのカタログには加工例として以下のような写真が掲載されていました。

ケースに合わせてシリコンラバー側も加工できると気持ちが良いですね。

これはなかなか良さそうです。

タカチ電機工業さんのホームページからは、DXFでケース外形をダウンロードする事ができます。

(自己解凍形式になっていて少し気持ち悪いのですが気にしません。)

EAGLEからDXFでエクスポートした後、RootPro CADを使ってメーカー提供のDXFと組み合わせ検証をする事もできますね。やってみましょう。

ダウンロードしたファイルをインポートすると以下のような感じの図面が得られます。

ズームアップしてみましょう。

検証で欲しい箇所をコピーして使用すれば良いですね。

こんな感じできっちり収まりそうな感じが確認できました。

最終的には現物で確かめるまで何が起こるかわからないという立場を取るのが良いわけですが、

少なくともCAD上で検証しておかないと狙って正しいのか偶然正しいのかわかりません。

今回の場合、現物で問題なければ狙って正しい結果を出したという事になります。

高さ方向の検証は少し考えている事があるので、これはまた別の機会に。

今回の基板をケースに収める時の事を妄想するために「Eagle3D + POV-Rayをもっと活用してリアルな完成イメージ図を得る」にならって動画にしてみました。

うーん。

基板だけ回転させてもわからないですね・・・。

ACB-BF592とUMB-SSM2603のベース基板を設計する

金子システム株式会社さんのコンパクトで高性能なDSP基板ACB-BF592の準備を随分前の記事で始めたわけですが、なかなか納得のいく進め方を見つけられずに放置状態でした。

先日のKOZOS EXPBRD #00を考えるうちに「こんな風にやってみようか。」という方針を自分の中で決める事ができたので前進開始です。

第1段階として、オーディオ・コーデックが搭載された基板UMB-SSM2603も使って、オーディオ・プラットフォームの実験用基板を設計する事にしました。

設計時に考えた事を列挙すると・・・

• 2つのモジュールのコンパクトさを生かそう。
• UARTブートのためのインターフェースは最低限欲しいなぁ。
• バス・パワー動作させたい。
• 使う時に楽しめるようにプチ・ディスプレイを搭載しよう。
• ハードウェア・スイッチはアプリケーションによって要求が異なる。リモコンにしてしまえ！
• SDカードでブートできたら嬉しいなぁ。
• リセット・スイッチくらいはいるだろ。
• 基板製造費用は安く抑えたい。
• その他。

こんな感じでうだうだ考えて一日。

設計完了した基板は以下のようになりました。

ハードウェア・スイッチを取り除いたお陰でコンパクトに仕上がっています。

そして、遊べるようにディスプレイを付けておきました。

UARTインターフェースとSDカード・スロットは、UMB-SSM2603の下に隠してあります。

シンプルな見た目とは裏腹にというのが、設計の裏コンセプトです。

このベース基板を使えば、これ一つでDSPを気軽に楽しめちゃうという算段。

金子システムさんの安価なDSP基板シリーズのお陰で、気軽に始められるのが嬉しいです。

さて、コンパクトさを生かす設計には、基板製造費用を抑制するという効果もあります。

FusionPCBでは、基板外形の最大寸法で費用が決まります。

今回の基板の外形寸法は、約92x62mmなので、10cm Max * 10cm Maxで収まり、+$15.00で済みます。これが、仮に横方向15cm以上となるといきなり+$60.00です。

DSP基板がコンパクトなお陰で、ベース基板も安く設計する事ができるのが嬉しい限り。

少し寝かせて基板製造工程に進む予定です。

WAVファイルを手軽にきちんと扱いたい！

WAVファイルを手軽にきちんと扱いたい！

WAVファイルを手軽にきちんと扱いたくなったので仕様や巷の実装を調べていました。

WAVファイルはチャンク構造になっていて、内部データ表現を自由に選ぶ事ができます。
自由に選ぶ事が出来ると言う事は、それなりにきちんと設計実装したプログラムでなければ正しく扱えない事を意味します。

手元にあった書籍（名前は出しませんが）や巷の実装を見ると、随分と厳しい暗黙の前提条件が用いられていて、色々なWAVファイルをあまり正しく読める事を期待できないなぁという感じでした。

また、データ保持の方式が「スタックにずんっと置く」ような実装だったり、「ファイルサイズに応じて超巨大なメモリをヒープから取る」ような実装だったりと、いくら巨大なメモリがPCに搭載されている昨今とは言え、何だかなぁ～という感じです。

そこで、巷の実装例を少し紹介した後で、設計実装したWAVファイルライブラリを御紹介します。

巷の実装を見てみる

今回設計したライブラリの紹介の前に、巷の実装を見てみましょう。
実装をそのまま掲載する事はできないので、ちょっと修正してあります。

巷の実装例（とある書籍のサンプルコード）

この実装は、出現するチャンク構造の順序に暗黙の前提条件が使用されている例です。

  fp = fopen(file_name, "rb");
  fread(riff_chunk_ID, 1, 4, fp);
  fread(&riff_chunk_size, 4, 1, fp);
  fread(riff_form_type, 1, 4, fp);
  fread(fmt_chunk_ID, 1, 4, fp);
  fread(&fmt_chunk_size, 4, 1, fp);
  fread(&fmt_wave_format_type, 2, 1, fp);
  fread(&fmt_channel, 2, 1, fp);
  fread(&fmt_samples_per_sec, 4, 1, fp);
  fread(&fmt_bytes_per_sec, 4, 1, fp);
  fread(&fmt_block_size, 2, 1, fp);
  fread(&fmt_bits_per_sample, 2, 1, fp);
  fread(data_chunk_ID, 1, 4, fp);
  fread(&data_chunk_size, 4, 1, fp);

この実装の場合、出現するチャンク構造の順序が異なるだけで全く正しい処理ができません。
そして、この後の処理が以下のようになっています。

  pcm->fs = fmt_samples_per_sec;
  pcm->bits = fmt_bits_per_sample;
  pcm->length = data_chunk_size / 2;
  pcm->s = calloc(pcm->length, sizeof(double));

data_chunk_sizeに期待するチャンク構造のチャンク・データ・サイズが格納されているとは限りません。そしてその値をそのまま使ってcallocしているので危ないです。

このコードは落第点です。

でも音を扱うという書籍のサンプル実装です。

この実装の危ない点は、間違っていても処理がどんどん進んでしまう事です。

そして、間違っている場合、何がどう間違っているのか検知していないので、APIの外から見た場合にどうしようもありません。

巷の適当に実装されたコードは意外にこういうのばかりであまり再利用には向いていません。
仮に入門者がこのコードを見て育った時に、「いつこの設計実装レベルから抜け出せるのだろう？」と考えると少し心配になってしまいます。

Tiny WAV I/O Moduleプロジェクト

Tiny WAV I/O Moudleプロジェクトとは、小規模組み込みシステムで使用可能なWAVファイルライブラリを作ろうという目的で作られたプロジェクトです。

今回実装したライブラリは、その設計の前段にあたるもので、「どういったインターフェースなら使いやすいかなぁ」というのを検討する為のもの。libcが使用可能な環境でのみ使用可能です。成果物はTiny WAV I/O Moduleプロジェクトのlibc-basedに追加しました。

まぁ、ざっくり言うとlibc-basedは「パソコンで使えるお手軽WAVライブラリ」ですね。

wavfileモジュールの特徴

以下に今回設計実装したお手軽WAVライブラリ、wavfileモジュールの特徴を示します。

• 省メモリ設計。（ライブラリ側では巨大なメモリを要求しない。）
• ファイル形式に依らず0.0から1.0で正規化されたデータ入出力インターフェースを採用。
• 複数チャネルデータに対応。
• ヘッダの実装詳細を把握しなくても使える。

データをどこに配置するのかについてはアプリケーション層が決めたい事の一つです。

巨大なメモリを勝手にアロケーションするようなライブラリは使いづらくて仕方ありません。

よってwavfileモジュールでは、これらに関知しないようにインターフェースを設計しました。

また、WAVファイルの処理を実装する時に意外に面倒なのが、データ形式の違いです。

今回のwavfileモジュールでは、ファイルのデータ形式によらず0.0から1.0で正規化されたデータ入出力インターフェースを採用しました。これによって、「8ビット形式のファイルは0から255で1バイトだよね。」とか「16ビット形式のファイルは-32768から32767で2バイトだよね。」とか考えなくて済みます。とにかくサンプルを1つ得るインターフェースを呼ぶだけで良いのです。

typedef struct {

    uint16_t num_channels;

    double channel_data[WAVFILE_MAXIMUM_CHANNELS];

} wavfile_data_t;

wavfile_read_dataを呼ぶと上記の構造体にサンプルデータが格納されて返ってきます。

channel_dataの中身は先の規格化された値が入っている事になります。

wavfileモジュールのインターフェース

wavfileモジュールを使うために必要なインターフェースは、リード用、ライト用と合わせてもたったの6つです。

WAVFILE *wavfile_open(const char *filename, WavFileMode mode, WavFileResult *result);

WavFileResult wavfile_read_info(WAVFILE *p, wavfile_info_t *info);

WavFileResult wavfile_read_data(WAVFILE *p, wavfile_data_t *data);

WavFileResult wavfile_write_info(WAVFILE *p, const wavfile_info_t *info);

WavFileResult wavfile_write_data(WAVFILE *p, const wavfile_data_t *data);

WavFileResult wavfile_close(WAVFILE *p);

基本思想

infoとdataの2段階で簡単に実現しちゃうよ！というのが本ライブラリの基本思想です。

読み込み

• wavfile_openにファイル名とWavFileModeReadを与えてオープン。
• wavfile_read_infoでヘッダ情報を読み込む。
• wavfile_read_dataでデータを読み込む。 （必要に応じて繰り返す）
• wavfile_closeでクローズ。

書き込み

• wavfile_openにファイル名とWavFileModeWriteを与えてオープン。
• ヘッダ情報を設定する。
• wavfile_write_infoでヘッダ情報を書き込む。
• データを設定する。
• wavfile_write_dataでデータを書き込む。（必要に応じて繰り返す）
• wavfile_closeでクローズ。

どんな風に使えるの？

単にデータを読みたい場合

よくあるやりたい仕事の１つが、とにかくデータを読んでみたい！というものです。
Tiny WAV I/O Moduleのlibc-based実装を使えば簡単に実現できてしまいます。

WavFileResult result;
wavfile_info_t info;
wavfile_data_t data;
WAVFILE *wf = wavfile_open("YourWavFileName.WAV", WavFileModeRead, &result);
if (wf != NULL) {
    wavfile_read_info(wf, &info);
    while (1) {
        wavfile_read_data(wf, &data);
        if (data.num_channels == 0) {
            // 読むべきデータが無くなったらチャネル数に０を返してくる。
            break;
        }
        // ここでデータを確認すれば良い。
    }
    wavfile_close(wf);
}

ソースコード

ソースコードは、以下からダウンロード可能です。
http://pt.sourceforge.jp/projects/tinywavio/

ライセンスはMITです。

今後の計画

最近は色々と忙しくて基板設計まで手が回らないので、今年は中途半端に拘るのを諦め、外販されているモジュールを活用してシステム物をやりたいなぁと計画しています。

実は、金子システム株式会社さんからUMB-SSM2603なるものが販売されています。

そうなのです。
このモジュールはACB-BF592と組み合わせてもミニサイズなのです。

動作も高速なので、実は今回のlibc-basedな実装もそのまま動かせたりして？！なんて甘い考えを持っていたりします。ファイルシステム周辺は何らかの抽象化層に乗せようかなぁ。

とにかく組み込み装置としてエレガントにWAVを扱えるようしていこうと考えています。

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

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

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

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

実装するとこんな具合。

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

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

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

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

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

うーん。

私も早くやってみたい！

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

このブログを読んでいらっしゃる方の中にも「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のウェブを見た」と言うと・・・おそらく特典は無いと思います。