2013年8月31日土曜日

A capacitive touch sensing using an analog input port for mbed

先日のことですが、mbed用の静電容量式タッチセンサライブラリを公開しました。

[フレーム]

http://mbed.org/components/Touch-Sensor-using-an-analog-input-port/

まだまだ改良したい感もありますが、「ひとまずこれで公開！」というバージョンです。

2013年7月28日日曜日

Markdown記法を使ってプロジェクトの関連文書生成を効率的にする

Markdownって何ですか？

Markdownとは、John Gruberさんによって作られたマークアップ言語で、記述したテキストファイルをスクリプトで処理して二次生成物としてHTML出力する事ができます。
最近ではリポジトリに設置する文書にMarkdown記法を用いるケースを多く見るようになりました。
「README.mdって何だ？」っていうアレです。

今回はUOS-LPC800プロジェクトにおけるMarkdownの活用をご紹介します。

UOS-LPC800におけるMarkdownの活用



UOS-LPC800では、プロジェクト開始当初からMarkdownで一次文書を構成し、二次生成物としてウェブ用ファイルを作ることを考えていました。

Markdownのファイルをダウンロードすると変換用のPerlスクリプトが同梱されています。
Markdown.plを使用した事のある人にはわかるかもしれませんが、このスクリプトは単に書かれた事を書かれたように変換するだけのスクリプトです。

UOS-LPC800のウェブページを作るにあたって、Markfileやシェルスクリプトでラッパーを作りました。
これにより
  1. Markdown記法でテキストファイルを記述
  2. 端末でmake
するだけでウェブブラウザが開いて生成物の内容を確認できるようになります。

今回のラッパーでは以下を実現しています。
  • ページで使用する画像はimagesに置いておけば良い。
  • ページで使用するリソースはresourcesに置いておけば良い。
  • Markdown.plで処理されないヘッダの類はhead.htmlとtail.htmlで付与する。
とこんな感じです。

ダウンロード

今回のファイル一式をこちらからダウンロードできるようにしておきました。

2013年6月23日日曜日

割と適当に動作するOS「誰得OS」のCortex-M0+版であるUOS-LPC800を作りました

割と適当に動作するOS「誰得OS」のCortex-M0+版を作りました。

32ビットプロセッサとしては極めて小さいNXPセミコンダクターズ社のLPC810 (RAM=1KB、ROM=4KB) でもなんとか動作します。名付けてUOS-LPC800です。


以下の動画では、LED点滅タスクとUART送受信タスクが動作しているところを示しています。


LPC800 MiniBoardをお持ちの方はHEXファイルをダウンロードして試してみる事ができます。
「割と適当に動作する」などと言いながらも、スケジューリング・アルゴリズムはラウンド・ロビンと優先度ベースで選択できたりします。そして、カーネルの中核を成すコードはわずか300行で誰にも読み切れるサイズです。

今年中に「茶室で楽しむKOZOS拡張基板」のような企画をやりたいなぁ～と考えているところです。

2013年5月5日日曜日

ARM Cortex-M3のアセンブラ学習に最適なインストラクションを簡単に調べるツールを超適当に作ってみた

何それ？

ARM Cortex-M3のCソースコードから注釈付きアセンブラリストを得るスクリプトです。

先日の投稿で「誰得OS」を作る事を考え、インターフェースの設計を行いました。
このOSのターゲットとしてARM Cortex-M3を最初に選択しました。
ARM Cortex-M3のアセンブラを記述するのは初めてなので、カーネル内部コードを記述する際に役立つであろうインストラクションを簡単に調べるツールを超適当に作ってみた次第です。


このツールのフローは以下のようになっています。
  1. ソースコードをC言語で記述する
  2. ソースコードをコンパイルしてオブジェクトファイルにする
  3. オブジェクトファイルを逆アセンブルしてインストラクションリストにする
  4. インストラクションリストを走査して注釈を付ける
このツールで最終的に得られる出力は逆アセンブルされた命令に注釈が付いたテキストです。


上記のように、逆アセンブル結果から対応するインストラクションを列挙してくれます。
わざわざ辞書のようにインストラクションセットを引く必要もありません。

アセンブラを記述する場合、単純な「やりたい事」と「インストラクション」を繋げていく作業が大半を占めます。予めC言語で書いたソースをコンパイルし、それを逆アセンブルした結果をインストラクションセットと一緒に眺めれば学習効果が高まるだろうと考えたわけです。

ダウンロード

ダウンロードはこちらからどうぞ。
自己責任でお使い下さい。

テスト用のサンプルCソースとMakefile付き。
実行後の結果も一緒にまとめてあります。

実行したい場合、単にmakeと打つだけです。
地味ながらこれは便利。

2013年4月30日火曜日

割と適当に動作するOS「誰得OS」を作る事を考える No.1 (まずはインターフェースを考えるだけ)

先日から色々と思うことがあって、「割と適当に動作する」OSを作る事を考え始めました。
「割と適当に動作する」というのは、まぁ言ってみれば「オモチャとして動作します」という事です。

考えているOSは、リアルタイム性もないし、タスク間通信も最小限。
でも、自分が作ったからよくわかるという、その名も「誰得OS」です。

私の場合、ソフトウェアは基本的にインターフェースの設計から始めます。
この基本方針はOSになっても変わりません。

まずは「誰得OS」のインターフェースを考える事にしました。


「誰得OS」は、
  1. daretoku_kernel_initでカーネル・オブジェクトを初期化。
  2. daretoku_task_initでタスクを初期化。
  3. daretoku_kernel_startでカーネルを動作開始。
と最低限3つのインターフェースを知っていれば動作させる事ができます。
「できます」と書いていますが、まだできていないので、そうなるように作る事にします。

ただ単にマルチ・タスクなだけではOSとしてあんまりなので、タスク間通信もdaretoku_msg_send_waitとdaretoku_msg_recv_waitで実現する事にします。

優先度とかは後で考える事にして今は放置。
当然のようにリアルタイム性に対する考慮なんてしません。

残念なOS、それが「誰得OS」なのです。
という事で、インターフェースを考えるだけなら簡単です。

これからチマチマと実際に動作するOSに仕立てていく作業が始まります。
適当に作る割に先は長そうです。

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を使用する場合、入力と出力の処理スレッドは別々に設計する。
  • キューから取り出せない場合、どのように振舞うべきか？
    • 制御系が何を期待するのかによって挙動を決めます。
  • 全体をリセットする場合、どのようにリセットすべきか？
    • これは意外に難しい問題です。
    • ハードウェアがどのように振舞うのかによっても大きく変わります。
  • その他。（色々あります）

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

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

AltStyle によって変換されたページ (->オリジナル) /