携帯型端末で学ぶ、はじめてのコンポーネントベース開発

3月10日(木)、11日(金)の2日間、NCES人材育成プログラム(NEP)の公開講座「端末で学ぶ、はじめてのコンポーネントベース開発 」が名古屋大学で開催されます。

今回は、Raisonance社の携帯型端末「STM32Primer2」の上に、TECS(TOPPERS Embedded Component System)を用いた
演習があります。
STM32Primer2のLED、JOYSTICK、LCD画面表示、タッチパネル、AUDIOを操作するソフトウェアをTECSのコンポーネントとして段階的に開発していくというカリキュラムです。
受講者一人に対して、STM32Primer2、開発用PCが用意されているので、しっかりと取り組めると思います。

お申込みはこちらからできます。 –

ちなみにSTM32Primer2を用いたTECSの教材は、TOPPERSプロジェクトのサイトからも公開されています(「TECS 教材(STM32 Primer2 を用いてTECS を学ぶ)」)。

STM32Primer2については、以下のサイトが詳しいです。
http://www.stm32circle.com/hom/index.php

また「STM32Primer2」で検索すれば、日本語でも情報が見つかります。

オントロジー工学による機能モデリングツール「OntoGear」

MetaMoji、オントロジー工学による機能モデリングツール「OntoGear」を提供へ – Enterprise Watch

私が今かかわっているTECSは、ソフトウェア開発における設計の観点からみると、抽象度のレベルは、ソースコードに落とし込む直前ぐらいに当たります。

つまり、TECSで表現されるものは、かなり(ソースコードによる)実装に近いものになるということです。
TECSのレベルでの設計の良し悪しは、さらにその上流に当たる部分の良し悪しや、上流での意図や決定をどれだけ反映しているかが大きく影響してきます。

TECSによる開発も、TECSとして提供される技術だけで完結するものではなく、より良い結果を得るためにはやはり上流でのより良い設計が必要です。

その意味で、今回のモデリングツールといのは興味深いです。
無償提供ということですので、早速入手して試してみようと思います。

追記:提供は5月10日からの予定でした。それまで待つことにします。

[TECS]コンポーネントWGのミーティングに参加

昨日(2010/02/23)はTOPPERSプロジェクト コンポーネント仕様WGのミーティングに参加しました。
今回のミーティングは3月11、12日に開催されるNEP(エヌイーピー。名古屋大学組込みシステム人材育成プログラム)の公開講座「TECSを用いたコンポーネントベース開発入門」の準備です。
コンポーネント化した制御プログラムで動くPUPPY2の動作を確認したり、講座のテキストの見直し、修正を行いました。
私はもっぱらテキストのレビュワーをつとめました。

PUPPYは一軸駆動、PUPPY2は2軸独立駆動であり、共通部分と差分という視点での設計を通して、コンポーネント化の利点を実感してもらいたいと思っています。
またTOPPERS/ASPのサービスコールを、直接C言語の関数として呼び出すのではなく、コンポーネントの提供する機能として利用することで、こまごまとしたことを気にせず(そのあたりはコンポーネント内部で面倒を見てくれます)便利に使えることも気が付いてほしいです。

今回は近来になく時間を費やし、いつもなら飲み会が終わって解散するぐらいの時間にやっと退出することになりました。
私も駅の改札の前で、次に来るのが終電だと気がつき、あわててとび乗って安堵することが出来ました。

raccのparser.rbとcparseの違い

さらに引き続き(raccのエラー回復モードは頑張りすぎ?tecsgen の Exerb版, Jruby 版の障害について)、raccのparser.rbとcparseの動作の違いを調べています.

昨日は、parser.rbがエラー回復モードで、定義された文法を満たすトークンの並びを得ようとして、(入力が終わっているのに)延々と次のトークンを得ようとして、無限ループに陥っているようだと書きました。
このことを指して「頑張りすぎ」と評していました。

そして、同じ不完全な内容の入力(不完全故に文法エラーになる)に対して、正常終了して文法エラーを報告するcparseは「頑張らない」ようにしているのではないかと予想していました.

今回、cparseを用いて、同じくtecsgen -yを指定してデバッグ表示させて見たところ、以外な結果になりました。

celltype tTaskMain {};

に対して、’}’を読み込むと文法エラーになります。
そしてエラー回復モードに入ります。

ここでcparseの場合、いったん読み込んだトークンを
捨てて、$endというトークンを読み込みます。
その次のトークンとして「}」を読み込みます。
後は、入力の通りにトークンを読み込みます。

エラー回復モードに入ったときに(入力には存在しない)仮想的なトークンを読み込んでいます。

この影響で、必要なトークンが不足しているために発生した文法エラーから回復することができていました。

先日以下の入力なら、parser.rbでも無限ループにはいらないと書きました.

celltype tTaskMain {}};

cparseの場合、エラー回復モード時に、あたかも上記のような入力がされていたかのように振る舞います。

$endが追加されるのは、他の文法エラーになる入力でも確かめてみました。

最初の私の予想(入力の終わりを特別扱いして、頑張らない)は外れていました。
cparseが採用しているエラー回復処理の方針は、どこかで聞いた覚えがあるのですが、思い出せません。またちょっとググってみても分かりませんでした。

(追記)
上の書き方ですと、parser.rbとcparse.soがまるっきりエラー回復モードのやりかたが違っているように受け取られるかも知れません。
しかし、rubyとC言語の違いはありますが、アルゴリズムとしては、(私が今まで調べて、理解した範囲では)どちらも同じに見えます。
動作の違いは、微妙な判定条件の違いとか、参照するテール(テーブルはそれぞれ用に作成されます)の内容の違いによるのではないかと感じています。

raccのエラー回復モードは頑張りすぎ?

昨日の続きで、TECSジェネレータでの文法定義と、CDLファイルでのエラーになる書き方を調べています。

今回も途中報告です。

前回に書いたerror-7.cdlは、以下の文法の記述に誤りがある場合のテスト-ケースでした.

文法定義

celltype
: CELLTYPE celltype_name ‘{‘ celltype_statement_list ‘}’ ‘;’

error-7.cdlの内容

celltype TaskMain {
/* attributeの定義が空でならsyntax error */
/*    attr {

x = 0;

};
*/
};

これはコメントを無視すると、以下と同等です。

celltyope TaskMain {};

文法定義と比較すると、celltype_statement_listという要素が不足しているため、文法エラーとなります。

実際、raccの生成したパーザはこの文法エラーを認識して、on_error()を呼び出しています.

ここで、on_error()とは、raccを用いてパーザを作成する人が、エラー処理を行うために自由に定義できるメソッドです。

on_error()でパース自体を中止することもできます。

また中止せずに、raccが生成したパーザにエラー回復モードで処理を続行させることができます。

エラー回復モードは、文法エラーが見つかった箇所を、エラーだとは認識しつつも、そこに正しい記述があったものとみなして、パース処理をつづけることです。

今回の文法定義の場合を例にとると、celltype_statement_listが存在するべきところに、「}」があったため、エラーとなります.

この後エラー回復モードで処理を続けようとして、「}」をcelltype_statement_listだとみなします。

文法では、この後に「}」と「;」がこの順番に記述されていなければなりません。

しかし、入力としては「;」しか存在しません。

raccは入力の終わりを$endというトークンとして扱います。

しかし、これが来ても、文法エラーが解消されません.パーザは次の入力を求めますが、実際の入力は終わっているので、$endしか渡してもらえません.

結局ここで無限ループが発生してしまいます。

実は、同じエラー内容でも以下の場合は、パーザは文法エラーを報告し、正常に終了します.

(文法としてはエラーになるが、正常終了する場合の記述)

celltyope TaskMain {}};

最初の「}」が来た時点でエラーと判断されますが、エラー回復モードになっても「}」、「;」と続くため、celltypeの文法定義に合致し、エラー回復モードは終了します。その後入力の終わり$endが来て、パーザは正常終了します。

エラー回復モードが(期待するより)頑張りすぎているのかもしれません.

ただし、入力の終わりがきたら必ず打ち切るようにするには、入力の終わりを特別扱いし、どんな状態であっても終了するルーチンをつくるか、どの状態からでも入力の終わりが来たら終了する状態遷移テーブルを作成する必要があると思います。

後、raccが手本にしたyaccの仕様がどうだったのか、確認したほうがいいかな。

raccの動作が、yaccの仕様の通りであれば、on_error()で対処するのがbetterだと思います.

TECSとは

TECS(TOPPERS Embedded Component System)とはTOPPERSプロジェクトにて開発された、組込み向けコンポーネントシステムです.

5月のESECの時に公開され、6月のTOPPERSカンファレンスのテーマにもなっていました。

TOPPERSプロジェクトのサイトの「TECSとは」というページで、ソースもダウンロードできます。

その他の場所でもCodeZineの連載記事(「【第1回】TOPPERSプロジェクトとTECS」、「【第2回】TECSによるアプリケーション開 」、「【第3回】コンポーネント記述言語TECS CDL」、「【第4回】コンポーネントの実装コード 」)や、「組込みプレス Vol.15」の「OSSの組込みコンポーネントシステム TECSを使ってみよう」などの記事を読むことできます。

公式サイト以外にも、いつのまにか「TECS 開発ブログ」という開発者のブログが始まっています。

などと書いている私も、TOPPERSプロジェクトのコンポーネント仕様WGに参加しており、開発者の一員です.

今後はこのブログで、TECSも含めてRTOSとか、プログラミングについて書いていこうと思っています.