MicroShellをArduinoにも対応させ、Version 0.0.2として公開しました！

小規模組み込みシステムのシリアル・コンソール・インターフェースとして便利に使えるミドルウェアMicroShellをArduinoにも対応させ、Version 0.0.2として公開しました。
https://www.cubeatsystems.com/microshell/download.html からダウンロードできます。

熱血！アセンブラ入門に感化されてARM Cortex-M0で動作する小さなオペレーティング・システムUOS-LPC800のパッケージを更新しました！

ARM Cortex-M0で動作する小さなオペレーティング・システムUOS-LPC800のパッケージを更新しました。今回はとても地味にコンパイル・オプションの更新を行っただけのパッケージです。

今回の更新は完全に「熱血！アセンブラ入門」に感化されたもので、今回のパッケージを展開してLPCXpressoでコンパイルすればアセンブラまで確認できるというものになっています。

ビルドすると.hexなどの他に.asmが出力されるようにしました。

中身を見るとソースコードとアセンブラを同時に確認できます。
熱血！アセンブラ入門と同時に活用できる便利なパッケージです。

ダウンロードは以下からどうぞ。
http://cubeatsystems.com/uos-lpc800/download.html

ARM Cortex-M0でもラクラク使えるNT-Shellよりもコンパクトな端末入出力ミドルウェアMicroShellライブラリを開発しました (NXP LPC824用サンプルプロジェクト付き)

あらまし

昨年のこと、NXP LPC824を使ったサウンドモジュールMicroSoundModuleを開発していました。このサウンドモジュールは、コマンドを受け取って色々な再生を行うもので、当初はこのコマンド処理部分の実装にNT-Shellを用いる計画でした。しかし、最小10KBのROM、最小1KBのRAMを要求するNT-ShellはNXP LPC824の小さなリソースに対して厳しいものです。仮に入ったとしてもアプリケーション側に大きな制約を課すことになります。

よくよく見まわしてみると、様々な面白そうなマイクロコントローラがNXP LPC824と同クラスで存在します。ARM Cortex-M0のような小さなマイコンを使ったシステムにおいて、NT-Shellほどの機能は要らない、でも、きっちり入力は出来るようにしたい、といったニーズはありそうです。

そこで、NXP LPC824のような小さなサイズのマイコンにも導入可能な端末入出力ミドルウェアを開発することにしました。名付けてMicroShellです。

使い方

使い方はmicroshell_initという関数にハンドラの実体へのポインタと、ブロッキング型のシリアル送受信関数のポインタを渡すだけという至って単純なもの。このコードだけできっちり動作する入力系が得られます。とても簡単ですね。

内部構造

内部構造は、以下の図に示すようにcoreとutilの二つから成り立っています。本当に最小限の構成にしたい場合にはcore側のmicroshellを用い、この場合には1行の入力処理が得られます。これに加えてコマンドのパースなどを行いたい場合には、util側のmscmdを用います。

ダウンロード

ダウンロードは専用サイトからできます。

• https://cubeatsystems.com/microshell/index.html

塩漬けになっている「Micro Sound Module」をなんとかしようと思い立つ

試作してから塩漬けになっているMicro Sound Moduleですが、年末年始のちょっとした時間で取り組もうかと考えています。そもそも、塩漬けにしすぎて何をどこまでやったのか忘れてしまった。

元々、アートインスタレーションで使えるような小さなモジュールにしたかったので、仕様から様々なこだわりを切り捨てて作りました。LPC824を選択したのも、「このくらいのマイコンを選べばアレコレやろうとしても欲張れないだろう」という斜め上(下?)の動機があったりします。

ということで、ちょっと成果物を眺めてから色々と取り組んでみようと思います。

リアルタイムOS教材について思う事(をちょっとだけ書いてみる)

■あらまし

学生の頃からリアルタイム・システムに興味があって様々な書籍を読んでいた自分ですが、エンジニア・ライフを約一周ほど楽しんで、そろそろ思うことあってリアルタイムOS教材についても触れなければならないなと考え始めました。というのも、世の中に溢れる教材の中には、初学者に与えるべきでない間違った例が数あまたあり、それらが実開発の現場で様々な問題を生んでいるからです。今日はその中からひとつだけ取り上げてショート・ブレイクとして書いてみます。

■良くない例：タスク・スリープで排他処理

世の中には不思議な例を取り上げてリアルタイムOSの機能を紹介する例を見かけます。その代表例がタスク・スリープで排他処理やシステムの状態を管理する例です。

この例を取り上げる教材の多くは、リアルタイムOSの機能を紹介したいようでもあるのですが、よくよく読んでみると、結局のところどれも「こういうときはこうするのだ」と実際のアプリケーションについて触れています。しかし、このような設計で実システムを実現されてはひとたまりもありません。

リアルタイムOSの使い方として間違ったアイデア、「タスク・スリープで排他処理やシステムの状態を管理」が何を言っているのか図示してみます。

タスクAとタスクBは、それぞれグローバル変数であるint valueを操作します。もうグローバル変数が出てくる時点で完全に失格なのですが、問題はそこではありません。この典型的な間違ったアイデアは、よく以下のような方法で紹介されています。

①システム起動直後、タスクAは動作し、タスクBは寝ています。

②タスクAはint valueを操作し、タスクBを起こして自分は寝ます。

③起床したタスクBはint valueを操作後、タスクAを起こして自分は寝ます。

例えば、この設計には以下の疑問がつきまといます。

A. タスクAとタスクBが非同期で双方動作している瞬間について考慮されていない。

B. タスクAがタスクBを知っている。タスクBがタスクAを知っている。つまり循環参照関係にある。

C. やっている内容から考えると、そもそも単一タスクで良い。(説明に必然性が全く無い)

D. その他。

上の例、int valueと書いてあるものは物理デバイスであることもあります。となると、なおさら問題は複雑になります。というのも、物理デバイスは動作に時間がかかります。状態遷移中の物理デバイスの状態を適切に扱う場合、上記の例では対処できません。

■例えばどうすれば良いのか？

リアルタイムOSを使うのは、抽象化レベルを上げつつ、キビキビとした動作を実現できるからです。上記の例で言うと、int value(物理デバイスかもしれない)は、操作対象ですが、これはあるタスク内部で操作される操作対象と見ることができます。つまり、タスクAやタスクBから操作される新たなタスクCのようなものが内部で操作する対象とすることができます。

そして、タスクAやタスクBからメッセージ通信でタスクCに操作を依頼する形式を取ります。

「ちょっと待って！さっきの例で出来ていたタスクAとタスクBの同期ができないじゃない！」と言われるかもしれませんが、タスクCは単一スレッド上でメッセージ受信処理を行っているので操作は競合しません。

加えて、タスクCのAPIを工夫しておけば、操作自体も抽象化された表現で扱うことが可能になります。

• アームを上に上げろ！
• アームを下に下げろ！
• 緊急停止！

上記のような操作を抽象的に表現したAPIにするだけで、グンとシステムで操作する内容がわかりやすくなってきます。そして、実装の詳細はタスクCに隠ぺいされるというメリットも生まれます。タスクAとタスクBが循環参照状態になる事もありません。

■ということで・・・

リアルタイムOSの教材でタスクのスリープを使って状態をコントロールするような例を見かけたら、「この教材は怪しいな」と疑って内容をレビューしてみて下さい。

ちょうど100円玉サイズ！NXP LPC824を使ったとっても小さなWAV File Player「Micro Sound Module」を作りました！

■KiCadへの移行

2016年2月にCADをEAGLEからKiCadに移行する練習を兼ねて、何か実際に作ってみようと考えていました。でも、あまり大きな設計はしたくない。そこで小ピンでも何か面白いことが出来そうなマイコンを使うことを考え、LPC824を使ったとっても小さなWAV Player「Micro Sound Module」を作ることにしました。こちらが完成品。じゃん！

EAGLEからKiCadに移行する人の中には、独特なユーザーインターフェースに戸惑いを感じる事もあるようですが、OrCADなどの業務でも使われているCADに馴染みのある人にとっては、逆に自然に移行できるのかも。私の場合、KiCadへの移行に合わせて、回路図、基板、3Dモデルを3画面で同時に見れるようにPC環境を更新しました。これはとても便利。

パッド名やネット名の確認が簡単に出来たり、リアルタイムでルールチェックを行なってくれるところも素敵です。EAGLEの場合には後からデザインルールチェックをかけるわけですが、これを忘れてしまうととんでもない状態で基板を作ってしまう事になります。そういう事は起こらないのが良いなぁと思いました。

私が使ったKiCadのバージョンでは、フットプリント側で配線禁止エリアや配置禁止エリアを指定できず、これはちょっと困ったことになりましたが、この苦しい制限があってもEAGLEには戻れない気持ちになっています。そのうちこの苦しい状況も改善されるでしょうと期待。

■Micro Sound Moduleの企画

マイコンがそもそも小さいのでコンパクトに面白いことができそう、と企画したのがMicro Sound Moduleです。本体のデザインは以下のようなもの。

Micro Sound Moduleですが、とにかく小さくて便利な機能満載！と行きたかったのですが、現状でROMがパンパンでI2Cスレーブ機能が入りません。苦し紛れにI2C端子をGPIにしてスイッチで制御出来るようにしました。

Micro Sound Moduleプロジェクトの副産物。

某企業さんに行ったプレゼンテーション資料の中で何故か好評だったシリアル通信の説明文・・・。

■ファームウェア

ファームウェアには色々な仕掛けが施されていて、面白いことが出来るので何処かでお見せできるように準備したいなぁと考えています。コマンドの例を挙げると・・・

• ディスクコマンド（マウント、アンマウント、情報取得）
• ファイルコマンド（ディレクトリ指定、リスト取得、オープン、クローズ、情報取得）
• トランスポートコマンド（再生、停止、ジャンプ、情報取得）
• マーカーコマンド（設定、解除、ジャンプ、情報取得）

こんな感じでひととおりの制御が可能なコマンドを装備しています。

コマンドパーサーにはNT-Shell (Natural Tiny Shell)を使用する予定でしたが、ROM容量の都合であえなく断念し、新しくコンパクトなパーサーを書きました。そろそろこれも公開したい。

Artistic Style (astyle) でコードを整形する

■インデントって重要

最近、色々な人のコードを眺めるにつけ、インデントまできちんと目を配って実装している人とそうでない人との間に、とてつもなく大きな壁がある事に気付きました。前者、インデントまできちんと目を配って実装している人の多くは、不要な実装、余計な実装は一切無く、終始一貫した表現で実装されています。対して、後者のインデントに気を使わない人の多くは、未使用変数や未使用関数、全く意味のないコメントやデバッグ文の散乱、ハードタブとソフトタブの同居・・・その他たくさんの危険な香りのする実装が残されています。ここ数年で見ていく中でインデントと成果物の内容に相関性があるのでは？という疑問に至り、インデントをきちんと行う姿勢に変えるだけでもその人のアウトプットが改善されるようにすら思えてきました。(今は単にそう思っているだけ)

■最近はArtistic Styleなの?

私の場合、ソースコードは常にvimで編集しています。autoindentは常にonですし、整形する際も組み込まれた整形機能をパパッと充てて済ませていました。ふとしたことから「最近では皆さんどうしているのかな？」と疑問に至り調べてみたところ、Artistic Style (astyle)というツールが割と最近では使われているようです。メジャーなLinuxディストリビューションではパッケージ管理システムから簡単にインストールできますし、Windows版はsourceforge.netのプロジェクトページから入手可能なようです。

■"One True Brace Style"が使える!

Artistic Styleでは、様々なコーディングスタイルを実現できるように豊富なオプションが用意されています。自分たちのコーディングスタイルに合わせてオプションを加えて実行できるのは嬉しい点です。"One True Brace Style"は、条件分岐などで一行で完結する命令の場合でも波括弧を付けて実装するスタイルのひとつで、私が好んで使用しているスタイルのひとつです。Artistic Styleでは、「--style=otbs」という引数を与えるだけで、One True Brace Styleになっていないコードでも自動的に波括弧を加えて整形してくれます。他にも様々な代表的なコーディングスタイルに対応しているので、きっと自分の気に入ったスタイリングオプションを見つける事ができるでしょう。