CuBeatSystems

というのも、数年前に公開したパッケージは、フラットにソースコードが格納されているのみで、正直言ってどうやって使うのかイメージできるようなものではありません。

当時はおそらく「まぁ、こんな感じでmain関数に組み込んでおけばわかるかな？」くらいにしか考えなかったのですが、今見てみると「これは考えていることが伝わらないよ・・・」という印象。

おまけに、詳しい説明は月刊Interfaceにしか掲載されておらず、そして、そのInterfaceの記事はNatural Tiny Monitor (NT-Monitor)がメインになっているような構成です。

現在、ライブラリのパッケージングを工夫して、コアライブラリファイルと、ユーティリティライブラリファイルを分離する方向で調整を進めています。(調整って言っても、ちょこちょこっとやるだけなんですが・・・)


加えて、幾つかのプラットフォーム向けのサンプルプログラムを同梱することで、具体的な活用イメージをお伝えしようとの考え。例えば、Blackfin向けのDSPのサンプルプログラムは、以下のような呼び出し関係を持ちます。


プラットフォームを初期化してNT-Shellを呼び出せば、もうばっちりシェルインターフェースを持つ立派な組み込みシステム！というパッケージにしようという考え。

やるやると言いながらなかなか公開していないNT-Shellですが、幾つかのバグフィックスも含める予定ですので、今しばらくお待ち頂ければ幸いです。

あらまし

約二年も前の話ですが、「割と適当に動作するOS「誰得OS」のCortex-M0+版であるUOS-LPC800を作りました」で 、LPC810でも動作するリアルタイム・オペレーティング・システムを作りました。LPC800シリーズの厳しい制約(ROM: 4KB、RAM: 1KB)の中でOSを動作させてみたいという欲求と、実際にこのような制約の中で何が出来るのか、単純に技術的な興味があったからです。

当初のバージョンにおいて、タスク側から操作可能なAPIはuos_task_yieldとuos_task_sleepのみで、OSと呼ぶならば欲しいであろうタスク間通信すら追加しませんでした。 サンプル・プログラムは、片方のタスクでLEDを点滅させ、もう片方のタスクでシリアル通信を扱うだけのものです。まさに「誰得OS」の名前に相応しいアプリケーション。


なかなか思い切った割り切りだと当時は考えましたが、先日から実アプリケーションにUOS-LPC800を適用してみようと考え始めた時点で、タスク間通信の必要性を改めて感じる事になりました。各タスクがそれぞれの仕事をこなしつつ、他のタスクと協調して動作させようと考えた場合、タスク間通信は必須とも言える機能です。 やっぱり欲しいよね・・・。

設計

タスク間通信を追加する前のUOS-LPC800におけるタスクの状態遷移は以下です。タスクは、基本的にRunningとReadyを行ったり来たりしており、uos_task_sleepによってスリープ状態に遷移するようにしました。非常にシンプルな作りです。


今回、タスク間通信を追加するにあたって、方針を「出来るだけ現状の設計には手を加えないで追加する」とし、スリープ処理に手を加えない形でタスク間通信を追加する事にしました。

今回のタスク間通信(メッセージ・パッシング)のモデルは以下のようなものです。 Task Aからuos_task_event_sendに対して「送信先タスクID番号」と「32ビットの値」を渡すと、あーら不思議、uos_task_event_recvを使って待ち状態に入っているTask Bに値が渡って実行状態に遷移するというものです。モデルは至って単純。


今回、上記の単純なモデルを実現するために、カーネル内部にブロック状態を管理するタスク・コンテキスト・ブロックのキューを新設し、送信待ちタスクと受信待ちタスクをブロック状態のキューに入れてから処理する事にしました。状態遷移は以下のようになります。


本当は、スリープ状態もブロック状態の一種として扱え、相当な理由が無い限り分離する意味はなさそうなのですが、今回は既存機能に手を加えない事にしたのでそのまま。もしかしたら次のアップデートではブロック状態をBlockedに変更して、現在のBlockとSleepと統合するかもしれません。

サンプル・アプリケーション

サンプル・アプリケーションは、従来通り二つのタスクを用意しました。タスク間通信を使用する場合は、task_ttyからtask_ledに向かってタスク間通信機能を使ってLEDの点灯指令を発行します。外から見た動作は従来のサンプルと何ら変わらないのですが、タスク間通信で指令するようになったところが従来と異なります。

ちなみに、タスク間通信を使う場合、直接タスク間通信の関数を呼び出しても良いのですが、受信側タスクにサービス要求用のAPIを作って、送信側のタスクがそのサービス要求用のAPIを呼び出す方が筋が良い設計です。


巷に溢れる数多くのリアルタイム・オペレーティング・システムを使った実装例には、受信側タスクの内部事情を送信側タスクが知らなければ実装出来ないような記述が多く見られます。これではタスク間通信によって得られるはずの抽象化度を上げる事によるメリットの多くを享受出来ません。受信側タスクの事情を変更した場合(例えば、送信側に期待する送信内容を変更したとか)に、送信側タスクの実装を修正しなければならないとしたら、規模の大きな設計ではたちまちバグになります。

ダウンロード

• ソースコードはhttp://cubeatsystems.com/uos-lpc800/index.htmlからダウンロード出来ます。
• ライセンスはThe BSD 2-Clause Licenseです。
• LPC800 Mini BoardとLPCXpresso LPC812で動作します。
• 「使っているよ！」とお声がけ頂くと、作者がとても喜びます。

「Blackfin MiniConfig for IFX-49 | 音遊び!Blackfin DSP基板でディジタル信号処理初体験」のサポート情報ページを更新しました。

1つ目は「Makefileからminiconfig-cuiを呼び出す」で、書籍に付属しているソースコードに添付されているMakefileにwriteとbootというターゲットを追加し、make一発でコンパイルから書き込みまでを実現する方法をまとめたものです。修正済みのMakefileをまとめたパッケージもダウンロードできるようにしておきました。


2つ目は「Eclipseを使ったビルド環境構築」の続編とも言える「Eclipseからminiconfig-cuiを呼び出す」で、ビルド後に自動的にminiconfig-cui.exeを呼び出してターゲットに書き込みを実行できるというものです。アプリケーション間を行ったり来たりする事なく、Eclipseから1クリックで書き込みまで実行できるお勧めの設定を記述しました。フラッシュロムに書き込む方法とSRAM上で直接実行する方法の両方に対応しています。

■書籍について

CQ出版社から「音遊び！Blackfin DSP基板でディジタル信号処理初体験」が発売されました。

先月の事ですが、Make: Japanさんの記事「Arduinoでちょっと長めの音楽を再生する方法」でA tiny MML parserを御紹介頂きました。Make: Japanさんありがとうございます。

LPC810でもMMLでスーパーマリオを演奏させたい!
先日A tiny MML parserを使ったスーパーマリオ演奏アプリケーションを公開しました。

折角なので眠っているLPC810への移植を試みたところ、4KBのフラッシュ・ロムに収まらない事がわかりました。実装したスーパーマリオのMMLを眺めると繰り返し処理をべた書きしています。MMLの処理を削る事は有り得ないので、安直に曲データを圧縮する事を考えました。A tiny MML parserに繰り返し処理を追加する事で曲データを圧縮を可能にし、LPC810でもスーパーマリオを演奏出来るようにしようと考えたわけです。


そんなにスーパーマリオに拘っているわけではないのですが、8ビットのマイコンにやらせていた事を32ビットのマイコンに移植して「残念！」みたいな結果になるのが嫌だったわけです。それがたとえフラッシュ・ロムの容量が原因だったとしても！(いや、それは無理・・・なんですけど)

繰り返し処理の仕様を考える
ひとくちにMMLと言っても様々な仕様、様々な実装が存在します。
A tiny MML parserに追加する繰り返し処理の仕様を以下のように定めました。

• []の記号を用いて繰り返し処理の区間を定義するものとする。
• 繰り返し処理の区間はネストさせる事ができるものとする。
• 繰り返し処理の区間は二回繰り返し処理されるものとする。

一見簡単そうに見えます。

乱暴なプログラマの場合、いきなり実装に入ってしまうかもしれません。
ちょっと考えて「出来るんじゃね？」と思う訳ですが、この記事では「簡単そうに見える処理が実際もそうなのか？」という視点でも見てみたいと思います。

最初にテストデータを定義する
A tiny MML parserに繰り返し処理を追加するにあたって、最初にテストデータを定義しました。このテストデータを新しいバージョンのA tiny MML parserに与えて、期待する結果が得られれば新たに加えられた処理は正しいという理路整然としたアプローチです。

• [CDE]
• [CDE[FGA]]
• [[CDE]FGA]
• [[]]
• [C[D]E]
• [CD[EF]GA]

上記のテストデータは正常系のテストデータです。異常系は以下のようにしました。

• [[[[[[[[[[[[[[[[[[[[
• ]]]]]]]]]]]]]]]]]]]]
• [ ]]
• [[ ]
• ][

このようにちょっと単純すぎるテストデータですが、そもそもこの程度のテストデータを正しく処理出来ないとしたら論外です。そういう意味でも正常系と異常系のテストデータを簡単なもので良いから両方用意しておくというのは重要です。

安直な設計でどうなるのか考えてみる
それではここで、めちゃくちゃ安直に設計無しで実装に取りかかった場合、どのようになるのかシミュレーションしてみましょう。

新人A君の場合
新人A君は、学生時代にマイコンでプログラミングを楽しんでいた意欲的な新人です。
与えられた仕様に対して直感で「これは位置を記憶する変数とループ状態を保持するフラグがあれば解決出来る！」と意気込み、早速プログラミングに取りかかる事にしました。


新人A君は、とりあえず実装しながら動作を確認し、ちょこちょこ修正していくアプローチで、学生時代には沢山の作品(製品ではない事に注意)を作ってきました。今回の新人A君の設計は仕様を満たせるでしょうか？

新人A君は、ざざざーとプログラムを意気揚々と書き上げました。
彼の最初のバージョンは、以下のテストデータを正しく処理しました。

• [CDE]

概要

A tiny MML parserのアプリケーションを考える過程で、LPC810が手元で眠っている事に気付きました。8ピンのARM Cortex-M0+でA tiny MML parserなんて素敵です。

さっそく調べてみたところ、先日のArduinoと同様に動作させる事を考えた場合には、State Configurable Timer(SCT)を使ってPWMを構成すれば良い事がわかりました。

あちこちで大不評のSCTですが、実は簡単に使えるのではないかと思っていました。
が、実際にやってみてやっぱり大撃沈。レジスタマップと機能説明を読んでも、どんな風に設定すれば自分が欲しい動作になるのか、全然意味がわかりません。

そんな中、LEDをステートマシンで点滅させるエクセサイズを見つけたので、頭からやってみる事にしました。これを応用すれば出力をトグルさせるだけのPWMにも適用できるというわけです。

リソース

エクセサイズのリソース：http://www.nxp-lpc.com/updated_materials/sct/lpc81x/LPC81x_SCT_code_examples.zip

エクセサイズのプレゼン：https://onedrive.live.com/view.aspx?resid=7AE40E5A5F1EC907!24470&ithint=file%2cpptx&app=PowerPoint&authkey=!ACDxmgRtdAZZdXE (スライド30ページから)

エクセサイズのリソース

ダウンロードしたエクセサイズのリソースは、説明に従って実際にプロジェクトを仕上げるために、作業開始時点の内容になっています。プロジェクトをセットアップし、スライド30ページを開きます。

Red State Machine file generator

「Choose Target」ボタンを押してターゲットを選択します。


上記で準備は完了。
エクセサイズのスタートです。

ステップ1

• U_ALWAYS状態を削除する
• State Tableタブで状態を構成する

次に状態を管理するState Tableタブに二つの状態を入力します。
このState Tableに状態名や次の状態名を入力すると、画面中央にある状態編集用GUIにも自動的に反映されます。


上記編集直後の画面は以下。


ちょっと配置が汚いので状態を示すボックスをマウスでドラッグして移動させて下さい。
矢印が双方向に見えるかもしれませんが、そんな事はありません。
きちんと二本に見えるように配置して下さい。

ステップ2

次にステート・マシンに対する入力、delayとmatch0を定義します。

ステップ3

動作の定義を追加します。

EVENT 0

始めにAction Listタブの右上にあるプラスボタンを押して新しい動作を追加し、名前をEVENT 0に変更します。


EVENT 0に対する動作を定義します。
追加は、Operationと書かれたテーブルの上にカーソルを移動させて右クリックして行ないます。

Setオペレーションに対して「Output pin 0」を選択します。


Callオペレーションに対して「Limit unified counter」を選択します。

EVENT 1

同様にEVENT 1を定義します。


名前をEVENT 1に変更して、以下の動作を追加します。
EVENT 1は、EVENT 0に対して逆の動作Clear Output pin 0を選択します。


EVENT 0の時と同様にCall Limit unified counterも追加します。

ステップ4

動作を定義したら、状態に関連づけます。
State Tableタブに戻ってActionカラムをクリックすると、先ほど定義したイベントを選択できます。


出来上がると以下のようになります。


念のため、ここでSignalsタブの内容も確認しておきましょう。
この値は、最初にState TableにSignal名を入れた時点で自動的に追加されています。


この時点で、画面中央のステートマシン編集画面は以下のようになっています。

ステップ5

Outputs for State Machineタブを開いてプリロード値を設定します。

Generate Codeボタンを押してコードを生成します。

ステップ6

ワークスペースを切り替え、SCT初期化コードを有効にする。


エクセサイズのコードで予め実装されたコメントアウト済みの箇所のコメントアウトを外します。


次に、sct_user.hを開いて下さい。

吐き出されたコードは「#include "board.h"」なる定義が実装されています。
ここを「#include "LPC8xx.h"」に書き換えます。このエクセサイズに内包されたCMSISの中にこの定義ファイルがあります。


何故このような作業が必要になるかというと、ツールが自動生成したsct_fsm.cからsct_fsm.hが参照されており、このsct_fsmの内部実装でLPC_SCTという定義を使っているからです。


上記のファイル名は、State Machine SettingsのHeader in sct_user.hに対して予め設定可能です。

ステップ7

最終調整です。
まず、SCTに制御させるピンを決定します。
今回はLPC800 MiniボードのLEDを点滅させる事にしましょう。
このボードは、PIO0_2にLEDが接続されています。


SWMのピン割当レジスタを設定します。
SWM PINASSIGN6レジスタのビット31:24がCTOUT_0の選択レジスタになっています。


PIO0_0が0x00、PIO0_17が0x11と順に値を加える事で出力を選択します。
今回はPIO0_2ですから、0x02を設定すれば良いことになります。


これで準備完了です。

その他の注意点

CMSISのクロック選択

CMSISのクロック選択は、system_LPC8xx.cの実装側に含まれます。
動作させるボードに応じて設定する必要があります。


この選択を間違えると「何で動かないんだ？」と混乱します。

対象プロセッサ

対象プロセッサを正しく選択して下さい。
この設定は、プロジェクトのプロパティに含まれます。


この選択によって、ツールチェインに与えられるリンカスクリプトが変わります。

実行結果

まとめ