TMS320C6000用行列ライブラリ

Texas Instrumentsの浮動小数点DSP TMS320C6713を使ってみようかと考えています。以前からSH4もやっているのですが、やはり汎用プロセッサだと色々とシステムが煩雑になりつつあるので、用途を特化した上でDSPもいいのではないかと考えている今日この頃です。
ということでこのDSPの開発環境や関連書籍を集めていたりしたのですが、ようやく実際にプログラムを走らせたりできるようになってきたので、その一部を紹介したいと思います。なお利用しているのは開発環境として純正のDSK(DSP Starter Kit)のTMS320C6713 DSKを、参考書籍としてCQ出版のインターフェイスの2006年増刊号『C++活用DSPプログラミング　TechI vol.33』を活用しています。

このDSPですが、開発環境(Code Composer Studio)についてくるコンパイラがC++をサポートしているので、コーディング効率はなかなか良好です。ISO C++のフルサポートではないので、Expression Templateなどの高度な機能の利用や、iostream等のストリームサポートがないなど、一般的なC++に比べると見劣りしますが、基本的な部分はだいたい抑えられているのでDSPでできることは一通りC++で実装できると思います。

とりあえずDSP事始として、PCで利用している自作行列ライブラリを移植してみることにしました。この行列ライブラリ、uBlasなどの高度なパッケージに比べると低速で機能的にも見劣りしますが、なかなか移植性が高いので気に入って使っています。
移植は簡単に完了しました。exceptionがないのでassertを利用したり、複素数ライブラリの移植が未完なので固有値・固有ベクトル等の計算がまだできませんが、基本的な転置や逆行列、分解はできているので使い出はあると思います。動作は開発環境付属のシミュレータと実機の両方で確認しました。ソースを公開します。(バグフィックス版があります)

使い方ですが、

すれば、すべての定義が利用できます。また、TIから6700用のサポートライブラリが提供されているので、これらのヘッダを今回のコード以前にincludeすれば若干かなり性能があがると思います。

最後に。利用される方がいましたら、是非感想をお聞かせ願いたく思います。

※その後、恒例になりつつある基板設計をはじめました。

※※その後、バグが確認されましたm(_ _)m バグフィックス版をリリースしました。

Boost::SpiritでCMS計画 (3)

Boost::spiritという変態的なライブラリを用いてWIkiライクなContents Management System(CMS)を作ろうという計画、前回の記事からかなり間があいてしまいましたが、ぼちぼち作業を再開しました。今回はその経過をお知らせしようと思います。

この計画の肝は、いかに楽をして構造化された文章を作るかというところにあるわけで、その為の記法、並びにその実装が重要となってくるわけですが、気がつけばその核の技術たる記法に名前をつけていませんでした。
そこで名前をつけることにしました。記法の名前ですが、完全俺様記法ということでFenrir Document、略してFDocにしました。以降FDocと表記します。

現段階でのFDoc記法は、前回の記事で書いたのとほぼ同じですが、

• FDocエリア(処理される部分)は=beginで始まって=endで終わる
• インライン要素は
  • 下線 __ (下線を引きたい言葉) __
  • 打ち消し線 == (打ち消したい言葉) ==
  • 強調 '' 強調したい言葉 ''
  • リンク [[ リンク先 (空白 エイリアス) ]]
• ブロック要素は
  • 順序付リスト +で段階数指定 最後に&をつけることで継続
  • 順序なしリスト -で段階数指定 最後に&をつけることで継続
  • 見出し !で段階数指定
• ""(文字列)""はヒアドキュメントとして機能
• トップレベルで自動改行挿入、ただし直後がブロック要素の際は挿入されない

せっかく定めた記法なので、生涯長く付き合っていこうかと考えていますが、そのためには単一のFDocを元にHTMLやらPDF(の元となるTeX)やらが生成できて欲しいところです。こうなるためには、FDocを読み込んで文章構造を認識するパーサの部分と、パーサによって生成したモデルを元にHTMLやらTeXやらを出力するレンダリングエンジン(レンダラー)の部分を切り離す必要があります。そこで今回は、前のコードを改造してパーサとレンダラー(例えばHTML)を切り分けました。プロジェクト全体のソースはこの辺りにおいておきます。

この計画の今後の展開ですが、2つのことを考えています。

• 当初の計画がCMSを作るということだったので、webアプリケーションとして動作するような仕組みを考えています。普通のCGIでは少し面白みがないのでApacheのモジュールとして実装することを考えました。幸いにもmod_blosxomという、軽量CMS blosxomのApacheモジュール版が公開されているので、それを参考にモジュール化しようかと考えています。
• FDoc自体でも数式もサポートしようかと考えています。書式はTeXの記法を採用する予定で、その部分のパーサとレンダラーを開発中です。HTMLレンダラーでは画像では汚いので、Flashに落とし込もうかと考えています。そういうわけで『ActionScript 2.0メモ』等を参考に、EclipseでのAction Scriptの開発環境を整備しました。

Googleブランドの不正使用

このサイトではGoogle AdSenseという広告バナーを掲載しているのですが、少し前にそのGoogle AdSenseチームからメールが来ました。

Google では、AdSense プログラムにご参加いただいているサイトが Google のプログラム ポリシーに従っているかどうかを定期的に審査しております。

お客様のアカウントを確認しましたところ、Google 広告の掲載方法が次のプログラム ポリシーに違反していることが確認されました。

- お客様のサイトにおいて、Google の検索結果または Google ブランドが不正に使用されていることが確認されました。Google のポリシーにより、サイト運営者様が Google の検索結果をフレーム化および表示することは禁止されております。また、Google による事前の許可なしに、お客様のサイトに Google ブランド (Google の商標、ロゴ、ウェブ ページ、スクリーン ショット、その他の特徴的なアイテムなど) を表示することも禁止されております。このため、Google の検索結果の不正なフレーム化や、Google ブランドの使用を中止していただきますようお願いいたします。

お客様のご理解に感謝いたします。必要な変更を加えていただきましたら、このメールへの返信として、その旨をお知らせください。お客様のアカウントを再度確認させていただきます。

この機会に、Google のプログラム ポリシー(https://www.google.com/adsense/policies?hl=ja) および利用規約(https://www.google.com/adsense/localized-terms?hl=ja) をご覧になり、お客様のすべてのページがこれらの基準に従っているかどうか確認することをお勧めします。

よろしくお願いいたします。

Google AdSense チーム

なにやら『Googleブランドの不正使用』をしてしまっているらしく、このままだとAdSenseの利用を停止される恐れがあるようです。いちおう対策を講じたことにより、現在この問題は解決しましたが、同じ問題に遭遇されている方もいるかもしれないので、解決に至るまでに行った対策や考察を残しておきたいと思います。

続きをどうぞ。

続きを読む "Googleブランドの不正使用"

室内飛行機 自律旋回飛行に成功?

室内飛行機の自律飛行を検討していたわけですが、基板等の各コンポーネントがとりあえず完成し実験をすることになりました。当初の予定では、それらを活用して体育館内で室内飛行機を自律旋回飛行させようということだったわけですが、あっけなく自律旋回飛行してしまいました。といっても問題点が激しくあるのですが(笑)
とりあえずその飛行実験の様子の動画をご覧ください。再生をすると人の声が聞こえると思いますが、『自動』と言っているところ(上昇する手前まで)は自律飛行をしています。

何が問題なのかは続きをどうぞ。

続きを読む "室内飛行機 自律旋回飛行に成功?"

コマクサ

足の靭帯を怪我して今年の山シーズン前半は絶望的でしたが、ようやく回復してたのでリハビリを兼ねて蔵王にハイキングに行ってきました。道を少し外れるとコマクサが咲いていました。
天候はあいにくだったので、撮影は生活防水機能付のデジカメでお茶を濁しています。Olympus u710、F:9.0、1/50、f:7mm、スーパーマクロ。

Flashで組版

Eclipseで作業中。

FDocがらみの話です。FlashもといActionScriptで組版をしてみています。ActionScriptは浮動小数点の扱いや画面上の文字サイズの扱いが微妙なので、はやくも限界は見えつつありますが、組版事自体非常に楽しいので、実用性なしでもぼちぼち作業していこうかと考えています。

ちなみに一番目の式は航空関係の人にはお馴染みのやつです。

ワードをTeX化するテクニック(位置あわせ編)

最近、提出する文章の最終出力がPDFで要求されることが多くなりました。そういうわけで、文章は品質にこだわってTeXで作成、dvipdfmxで出力するようにし、M$のワードからは卒業しました。単にAdobeのAcrobatが手元になくて困っているだけ、という話もありますが(笑)。
そんなときに困るのが、テンプレートがワードだけで提供されている場合です。おそらくTeX派は圧倒的にワード派よりも少ない(研究室はほぼ全員ワード派)ので、何でワードだけ提供してTeXがないんだと文句を言っても仕方がないと思われます。ということで、ここは泣きながら元のワードファイルをTeX化します。

その際特に問題になるのが位置あわせです。元のワードファイルには嫌な奴がいて、例えば入力欄が表形式になっていて、空白の位置指定(例えばここの空白は縦に何mm空けてね)等がばっちりされているものがあります。そこで今回はTeXで如何に位置あわせを行うか考えてみました。

続きをどうぞ。

続きを読む "ワードをTeX化するテクニック(位置あわせ編)"

makeでソースとバイナリを違うディレクトリに

先日、室内飛行機の自律飛行プロジェクトの成果物としてH8/3694のフレームワークを公開しましたが、その際、自動コンパイル(ビルド)をどのように構成するかで少し悩みました。

オープンソース系の大きなプロジェクト(apacheなど)をみると、ソースとそのコンパイル結果であるバイナリは同じ場所に展開されるのが常套手段のようです。これはコンパイラが分割コンパイルをサポートしており、ビルドを行うのにメジャーなプログラムであるmakeがこのような方法を簡単に実現できるためだと思います。
例えば、あるフォルダ内にあるc言語のソースを全てまとめてhogeというプログラムを生成するmakeスクリプト(Makefile)は、以下のように簡単に書けます。

このスクリプトを使ってmakeを実行すると、(ソース).cは同じディレクトリに分割コンパイルされて(ソース).oというバイナリとして生成されます。そして(ソース).oが合わさって最終的にhogeという目的のブツが手に入ります。

ところがソースを書くのに別にeclipseなどの統合開発環境(IDE)を使用している場合、ソースとバイナリが同じディレクトリにあると、使用上鬱陶しいことがあります(例えばファイルを選択する際など)。eclipseならフィルターで消すことができますが、根本的な解決にはならないので、Visual Studioのようにバイナリを別ディレクトリに生成した方がよいのではないかと考えました。

続きをどうぞ。

続きを読む "makeでソースとバイナリを違うディレクトリに"