CuBeatSystems

小規模組み込みシステムデバッグ用シェル - Natural Tiny Shell (NT-Shell)で紹介した小規模組み込みシステムデバッグ用シェルですが、現在は以下のように公開先の変更やフォローアップ記事の掲載などが行なわれています。特に、NT-Shellを使ったモニタ・プログラムNT-Monitorは実践的な活用事例として有効ですので是非ご覧下さい。

2017年4月1日追記。
公開サイトを変更しています。以下から最新版をダウンロードできます。
https://www.cubeatsystems.com/ntshell/
CQ出版社の月刊誌インターフェース2013年1月号に記事を書きました。
http://www.kumikomi.net/interface/sample/201301/if01_174.pdf
インターフェース2013年1月号のソースコードは、CQ出版社のダウンロードサービスで入手できます。
http://www.cqpub.co.jp/interface/download/contents.htm
TOPPERS活用アイデア・アプリケーション開発コンテストでの資料はこちら。
https://www.toppers.jp/docs/contest/presen2011_NaturalTinyShellTask.pdf 

MML (Music Macro Language)

MMLは、音楽記法をテキストで簡易的に扱うための記述言語です。
例えば、「ド・レ・ミ」と四分音符で歌う場合には「C4 D4 E4」と書く事で表現できます。

経緯

先日、大晦日ハッカソン2014なるものを見つけ、mrubyをBlackfinボード(UCB-BF512-B)で動かすおひとりハッカソンを企画し実行したわけですが、実は色々な小道具を整備しないとmrubyに辿りつけないとわかり何故か寄り道。Windows、Mac OS、Linuxで動作可能なChaNさんのFM音源モジュールの簡易シミュレーターの流れもあって、MMLパーサーがあれば自由に自動演奏させられるなぁという考えから実装したい衝動に負けてしまいました。

'A tiny MML parser'

'A tiny MML parser'は、Cで記述されたMMLパーサーです。


特徴をざっと挙げると

• シンプルなAPI
• 可搬性に優れたソースコード (C89準拠)
• 外部ライブラリに非依存 (libcも不要)
• 小さなフットプリント
• シャープ、フラット、ダブル・シャープ、ダブル・フラットなどにも正しく対応可能
• 複数の符点音符にも正しく対応可能
• 三連符に対応

どういう風に使えるの？

'A tiny MML parser'を使うには、要求されている唯一のコールバック関数を実装するだけです。
このコールバック関数は、「typedef void (*MML_CALLBACK)(MML_INFO *p, void *extobj);」と宣言されており、mml_fetch関数を呼ぶ度に一つのMMLコマンドが解釈されてコールバックが呼ばれる仕組みです。


ライブラリのインターフェースは以下に示すようにたったの三つです。


まず、初期化関数mml_initでコールバック関数を渡して初期化します。
この時、extobjに外部オブジェクトへのポインタを渡してやると、コールバック関数で受け取れます。

次に設定関数mml_setupで演奏時に必要となるオプションとMMLを渡します。
「オプションなんてわけわからん！」という人は「(MML_OPTION *)0」を渡して下さい。

最後に呼び出し関数mml_fetchでMMLのパースを実行します。
このmml_fetchを呼び出す度に、一つのMMLコマンドが解釈されます。

ちなみに、このライブラリは「何が書いてあるのか？」について解釈する機能を提供します。
「それをどうするのか？」については一切関知しません。
実際のシステムに導入する場合、これを意識して使う事が結構ポイントになってきます。

デモ

ライセンス

ダウンロード

• https://www.cubeatsystems.com/tinymml/index.html

大晦日ハッカソン2014

大晦日ハッカソン2014なるものを見つけてひっそり参加する事にしました。


テーマは「mrubyをBlackfinボード(UCB-BF512-B)で動かす」という事に決定。


mrubyはVersion 1.1.0を使用します。


今回のハッカソンの作業は https://github.com/shintamainjp/MISO-DEV-2014 で公開します。

「割と地味なlcdtoolの地味な改良を考える(だけ)」でlcdtoolにスクリプト機能を追加する事を考え、手っ取り早くNatural Tiny Basic (NT-Basic)を使ってやっつける事にしたのですが、NT-Basicのウェブの説明が、最新の機能と説明が食い違うなど、まったく酷い感じでした。自分で作っていながら、「あぁ、何だこりゃ」という感じ。

lcdtoolに組み込み作業を始めた時点で「あぁ、抽象化層に外部オブジェクトへの参照を渡したいなぁ」とか「ウェブをもっと綺麗にしたいなぁ」とか、本来のlcdtoolの機能追加とは本来関係ない事を考え始めました。

そもそもNT-Basicは、Windows、Mac OS、Linux、組み込みシステム、様々な環境で動作させる事ができるように設計してあるのですが、あらゆる環境に組み込む時の理解のしやすさも重要なポイントになります。

でも、従来のウェブには理解の助けになる情報が殆ど存在せず、実際に組み込みたい気持ちになるには何らかの積極的な動機が必要でした。そして、ただでさえ「いまさらBASIC感」が溢れているのに、積極的な動機を見つけるのは難しいものです。

とはいえ、教材としての面白さもあるので、NT-Basicの小さな改良とウェブの更新を先に行なう事にしました。


新しくリリースしたNatural Tiny Basic (NT-Basic)のVersion 0.3.0では、NT-Basicの初期化時にextobjに渡したポインタをhal.c内部で受け取る事ができます。これにより、NT-Basicのインスタンス毎に別々の処理を実行させる事も可能です。

また、新しくなったウェブには従来よりもわかり易い説明を追加しました。
ちょっと遊んでみたい人には参考になると思います。

■概要

昨年2013年の組込み総合技術展におけるプレゼンテーションの内容について「ET2013のTOPPERSパビリオンでショートプレゼンテーションをさせて頂きました」で簡単に触れました。今日は、この中でお話させて頂いたロジックアナライザを使ってジッタ計測を行ない、システムの安定性を検証する方法について述べたいと思います。

現代の組み込みシステムでは、ソフトウェアがシステム制御の一部を担う事が非常に多くなりました。ソフトウェアで発生するジッタというのは、リアルタイムシステムを構築する上で必ず評価しなければならない項目です。現場でお仕事をしていると、意外にも「どうやって評価して良いのかわからない」、「機材がない」といった内容の話をよく聞きますが、ちょっとした工夫と道具で指標となるデータを簡単に得る事ができます。

■題材

題材として用意したのは、7セグメントLEDが複数付いたデジタル時計です。


このデジタル時計は、6桁の数値表示をソフトウェアで制御する設計になっています。シンクドライバは各桁共通になっており、ソースドライバを選択的に駆動しながら各桁の数値を順次表示する仕組みです。
各桁の表示時間は、そのまま表示輝度に影響を与えますから、バラツキが大きすぎるのは問題です。それでは、このシステムをリアルタイム制御する場合について考えてみましょう。

■計測

システムの安定性を検証するにはデータが必要です。
先ほどのシステムで、各桁の駆動時間間隔を調べることにします。


チャネル毎の計測結果をファイルとして吐き出せるツールならば何でも構わないのですが、私はWindows、Linux、Mac OS Xと三つのプラットフォームで使用可能な上、GUIもサクサク軽快に動作するSaleae Logicを愛用しています。

先に述べたように、ソースドライバの駆動時間によって輝度にばらつきが出ることがわかっていますから、今回はソースドライバの各チャネルのタイミングを計測してリアルタイム性について確認を行います。

以下に示すのが計測した結果です。


と言ってもこれではわかりませんよね。
少し拡大してみましょう。


一見良さそうに見えますが、これで「良し」というわけにはいきません。
先に示した膨大な量の計測結果に、処理遅延が発生していない事をこれらのデータで判別する事は出来ません。

この計測結果からデータを整理抽出して欲しいデータを得るのがこれからの作業です。

■整理

それでは先ほど得た計測結果を整理して欲しい情報を抽出してみます。
Saleae Logicのアプリケーションは、データをCSVにエクスポートする機能が付いています。


この機能を使って計測データをCSVに変換します。
何故変換するのかというと、後でシェルで自分の都合に合わせて加工するためです。
エクスポートしたデータは、イベントが発生した時間と、その時の各チャネルの信号状態が記述された形式になっています。


このまとまったデータから各チャネルのOnの状態だけを抽出してみましょう。
以下のようなスクリプトを書けば、簡単にチャネル毎のデータに分割できます。


先のデータを使ってチャネル0のOnの状態だけを抽出したファイルは以下のようになります。
このデータは、まさにOnになった瞬間のリストで、後から述べる方法を使うことで、処理のバラツキを知ることができます。

■工夫

ここまでの作業で、各桁のピンの状態がOnになる瞬間の時刻の羅列を得ることができました。しかし、今回の題材では基準となるクロックが外部に存在しません。そこで、今回は処理のバラツキについて、前後のイベントの間隔で見ることにしました。

計測したデータの分析にはScilabを用いると便利です。基本となる操作は、ファイルになったデータを読み込む事と、前後のイベントの間隔を抽出する事で、以下に示すたった二つの記述で実行できます。


一行目でデータを読み込み、二行目で各値の差分を抽出します。この操作を行ったデータを可視化すると、以下のようなグラフが得られます。


この可視化されたデータは、ドライバの特定ピンがOnになった瞬間のイベント間隔のバラツキを時間軸方向に見たものです。しかし、これでは望んでいるリアルタイム性が確保できているのか判断しづらいので、異なる表現のデータも得てみましょう。


上記で示したScilab用の記述は、時間軸方向に並べられたイベント差分データを、単にヒストグラムに展開するものです。何か特別な加工をしているわけではありませんが、データの表現方法を変えるだけで、ずいぶんとわかりやすくなりました。


このバラツキのデータから中心値、最悪値、標準偏差を求め、システムが十分に安定したリアルタイム性を有しているのかどうかを判定します。

■まとめ

今回使用したのは、安価なロジックアナライザとLinux環境のみです。高価な専用機器を購入しなくても、工夫次第で今まで見ることの出来なかったシステムの性能を計測し把握できます。
こういったちょっとした工夫で今までと違う結果を得られるのが、組み込みシステムの面白いところなのかもしれません。

■玩具

ちょっと楽しくしたい場合、いろんなシチュエーションのデータを使ってアニメーションgifなどにすると面白いです。組込み総合技術展のプレゼンテーションでお見せしたアニメーションは、まさに上記で示した作業を経て作りました。結構手間が・・・かかってないか。

■ダウンロード

今回の「ロジックアナライザを使ってジッタ計測を行ない、システムの安定性を検証する」を実際に体験してみたい方のために、データ一式をダウンロードできるようにしました。

こちらからダウンロード

• 無保証です。
• 上記内容に関しての無断転載は御遠慮下さい。

lcdtoolとは、テキストLCDの表示内容を模擬してBMPファイルを生成してくれるツールです。
LCDプロファイルとLCDフォントファイルを作れば、様々なタイプのテキストLCDを模擬できます。





「リアルな操作画面のキャプチャが欲しい！ ～ドキュメント制作時に便利なLCD画像生成ツールを作ってみた～」で述べたように、取り扱い説明書やらで便利に使えるツールなのですが、割と色々なところに使い始めて、スクリプトのような機能を内包したくなってきました。

というのも、世の中には文字列だけの表示器だけではなく、記号や図形を組み合わせた表示器が存在します。このような場合、従来のlcdtoolではうまく対応できません。

そこでアレコレ考えた結果、lcdtoolにNT-Basicを組み込んでBasicで描画処理を記述できるようにしようと思い立ちました。(なんでBasicなんですか？とか聞かないで下さい・・・)

NT-Basicを使った描画処理は、従来から存在するLCDプロファイルにスクリプトファイル指定を追加し、外部のNT-Basicスクリプトを実行する形式で実現する予定です。この機能追加が実現すれば、lcdtoolを使って更に柔軟な表現が可能になります。

この機能追加を行なったlcdtoolは、遅くとも年内にリリースする予定。
現在、GUI化も検討しており、楽しみな改良計画です。

■概要

今年に入って地味にアップデートを続けているBlackfin BlueBootですが、前回のVersion 0.4.0に引き続き、これまた地味にVersion 0.5.0へアップデートしました。

きっかけとなったのは「KOZOS for Blackfin "BlacKOZOS"の設計方針」で始めたBlacKOZOSの作業です。この中で、コールドスタート時の動作確認用にターゲットにイメージを書き込むためにBlackfin BlueBootを使っていたのですが、稀に書き込みに失敗する事がわかりました。

■どんな失敗？

Blackfin BlueBootの場合、書き込み後に読み込みを実施して比較検証まで実施しているのですが、比較検証段階でターゲットから応答が無い(ような)状態に陥るというのが発生現象でした。現象発生時、表出現象には幾つか種類があるものの、書き込み直後の操作である事は共通した表出現象・・・。

「なんだろうな？」と思って設計を見返したところ、手を抜いて気にしていた部分を見つけました。

というのも、Blackfin BlueBoot Version 0.4.0までは、ターゲット上でフラッシュロムへの書き込みがまさに終わったかどうかの確認は行なわず、ターゲット上に搭載されているフラッシュロムのデータシートに規定された書き込みにかかる最大時間をホスト側で待ってから、その次の動作に移行するという設計になっていました。

イメージ図にすること以下のようになります。
ホスト側の処理を台詞にすると、以下のように随分と乱暴な感じ。
これはいけません。


ざっくり言うと「データシートに書かれた最大時間は待ったんだから終わってんだろ？」という話ですが、これには幾つか問題があります。

1. 常に最大時間待つので、必然的に書き込みが遅くなる。
2. ソフトウェア上で待つという事は、必然的にバラツキを生む事になる。
3. 待つ処理に対するバラツキは、実行環境によっても異なる上、それは予想し難い。
4. その他。

■改良版

1. 余計な待ち時間が不要となり、従来よりも動作が高速になりました。
2. 書き込み処理の安定性が向上しました。
3. より環境に依存せずに書き込みができるようになりました。
4. その他。

■ダウンロード