2014CuBeatSystems2014年12月31日水曜日mrubyをBlackfinボード(UCB-BF512-B)で動かすおひとりハッカソン大晦日ハッカソン2014大晦日ハッカソン2014なるものを見つけてひっそり参加する事にしました。テーマは「mrubyをBlackfinボード(UCB-BF512-B)で動かす」という事に決定。1.1.0を使用します。(NT-Basic)を使ってやっつける事にしたのですが、NT-Basicのウェブの説明が、最新の機能と説明が食い違うなど、まったく酷い感じでした。自分で作っていながら、「あぁ、何だこりゃ」という感じ。lcdtoolに組み込み作業を始めた時点で「あぁ、抽象化層に外部オブジェクトへの参照を渡したいなぁ」とか「ウェブをもっと綺麗にしたいなぁ」とか、本来のlcdtoolの機能追加とは本来関係ない事を考え始めました。OS、Linux、組み込みシステム、様々な環境で動作させる事ができるように設計してあるのですが、あらゆる環境に組み込む時の理解のしやすさも重要なポイントになります。従来のウェブには理解の助けになる情報が殆ど存在せず、実際に組み込みたい気持ちになるには何らかの積極的な動機が必要でした。ただでさえ「いまさらBASIC感」が溢れているのに、積極的な動機を見つけるのは難しいものです。いえ、教材としての面白さもあるので、NT-Basicの小さな改良とウェブの更新を先に行なう事にしました。0.3.0では、NT-Basicの初期化時にextobjに渡したポインタをhal.c内部で受け取る事ができます。これにより、NT-Basicのインスタンス毎に別々の処理を実行させる事も可能です。新しくなったウェブには従来よりもわかり易い説明を追加しました。遊んでみたい人には参考になると思います。昨年2013年の組込み総合技術展におけるプレゼンテーションの内容について「ET2013のTOPPERSパビリオンでショートプレゼンテーションをさせて頂きました」で簡単に触れました。今日は、この中でお話させて頂いたロジックアナライザを使ってジッタ計測を行ない、システムの安定性を検証する方法について述べたいと思います。現代の組み込みシステムでは、ソフトウェアがシステム制御の一部を担う事が非常に多くなりました。ソフトウェアで発生するジッタというのは、リアルタイムシステムを構築する上で必ず評価しなければならない項目です。現場でお仕事をしていると、意外にも「どうやって評価して良いのかわからない」、「機材がない」といった内容の話をよく聞きますが、ちょっとした工夫と道具で指標となるデータを簡単に得る事ができます。題材として用意したのは、7セグメントLEDが複数付いたデジタル時計です。このデジタル時計は、6桁の数値表示をソフトウェアで制御する設計になっています。シンクドライバは各桁共通になっており、ソースドライバを選択的に駆動しながら各桁の数値を順次表示する仕組みです。各桁の表示時間は、そのまま表示輝度に影響を与えますから、バラツキが大きすぎるのは問題です。それでは、このシステムをリアルタイム制御する場合について考えてみましょう。■計測システムの安定性を検証するにはデータが必要です。先ほどのシステムで、各桁の駆動時間間隔を調べることにします。Logicを愛用しています。先に述べたように、ソースドライバの駆動時間によって輝度にばらつきが出ることがわかっていますから、今回はソースドライバの各チャネルのタイミングを計測してリアルタイム性について確認を行います。以下に示すのが計測した結果です。言ってもこれではわかりませんよね。良さそうに見えますが、これで「良し」というわけにはいきません。先に示した膨大な量の計測結果に、処理遅延が発生していない事をこれらのデータで判別する事は出来ません。この計測結果からデータを整理抽出して欲しいデータを得るのがこれからの作業です。■整理それでは先ほど得た計測結果を整理して欲しい情報を抽出してみます。Logicのアプリケーションは、データをCSVにエクスポートする機能が付いています。この機能を使って計測データをCSVに変換します。変換するのかというと、後でシェルで自分の都合に合わせて加工するためです。エクスポートしたデータは、イベントが発生した時間と、その時の各チャネルの信号状態が記述された形式になっています。このまとまったデータから各チャネルのOnの状態だけを抽出してみましょう。以下のようなスクリプトを書けば、簡単にチャネル毎のデータに分割できます。先のデータを使ってチャネル0のOnの状態だけを抽出したファイルは以下のようになります。このデータは、まさにOnになった瞬間のリストで、後から述べる方法を使うことで、処理のバラツキを知ることができます。■工夫ここまでの作業で、各桁のピンの状態がOnになる瞬間の時刻の羅列を得ることができました。今回の題材では基準となるクロックが外部に存在しません。そこで、今回は処理のバラツキについて、前後のイベントの間隔で見ることにしました。計測したデータの分析にはScilabを用いると便利です。基本となる操作は、ファイルになったデータを読み込む事と、前後のイベントの間隔を抽出する事で、以下に示すたった二つの記述で実行できます。一行目でデータを読み込み、二行目で各値の差分を抽出します。この操作を行ったデータを可視化すると、以下のようなグラフが得られます。この可視化されたデータは、ドライバの特定ピンがOnになった瞬間のイベント間隔のバラツキを時間軸方向に見たものです。これでは望んでいるリアルタイム性が確保できているのか判断しづらいので、異なる表現のデータも得てみましょう。上記で示したScilab用の記述は、時間軸方向に並べられたイベント差分データを、単にヒストグラムに展開するものです。何か特別な加工をしているわけではありませんが、データの表現方法を変えるだけで、ずいぶんとわかりやすくなりました。求め、システムが十分に安定したリアルタイム性を有しているのかどうかを判定します。■まとめ今回使用したのは、安価なロジックアナライザとLinux環境のみです。高価な専用機器を購入しなくても、工夫次第で今まで見ることの出来なかったシステムの性能を計測し把握できます。いったちょっとした工夫で今までと違う結果を得られるのが、組み込みシステムの面白いところなのかもしれません。■玩具ちょっと楽しくしたい場合、いろんなシチュエーションのデータを使ってアニメーションgifなどにすると面白いです。組込み総合技術展のプレゼンテーションでお見せしたアニメーションは、まさに上記で示した作業を経て作りました。手間が・・・かかってないか。■ダウンロード今回の「ロジックアナライザを使ってジッタ計測を行ない、システムの安定性を検証する」を実際に体験してみたい方のために、データ一式をダウンロードできるようにしました。こちらからダウンロード無保証です。上記内容に関しての無断転載は御遠慮下さい。地味なlcdtoolの地味な改良を考える(だけ)lcdtoolとは、テキストLCDの表示内容を模擬してBMPファイルを生成してくれるツールです。LCDプロファイルとLCDフォントファイルを作れば、様々なタイプのテキストLCDを模擬できます。~ドキュメント制作時に便利なLCD画像生成ツールを作ってみた~」で述べたように、取り扱い説明書やらで便利に使えるツールなのですが、割と色々なところに使い始めて、スクリプトのような機能を内包したくなってきました。いうのも、世の中には文字列だけの表示器だけではなく、記号や図形を組み合わせた表示器が存在します。このような場合、従来のlcdtoolではうまく対応できません。そこでアレコレ考えた結果、lcdtoolにNT-Basicを組み込んでBasicで描画処理を記述できるようにしようと思い立ちました。(なんでBasicなんですか?とか聞かないで下さい・・・)NT-Basicを使った描画処理は、従来から存在するLCDプロファイルにスクリプトファイル指定を追加し、外部のNT-Basicスクリプトを実行する形式で実現する予定です。この機能追加が実現すれば、lcdtoolを使って更に柔軟な表現が可能になります。この機能追加を行なったlcdtoolは、遅くとも年内にリリースする予定。現在、GUI化も検討しており、楽しみな改良計画です。0.5.0へアップデートしました。"BlacKOZOS"の設計方針」で始めたBlacKOZOSの作業です。BlueBootを使っていたのですが、稀に書き込みに失敗する事がわかりました。なんだろうな?」と思って設計を見返したところ、手を抜いて気にしていた部分を見つけました。0.4.0までは、ターゲット上でフラッシュロムへの書き込みがまさに終わったかどうかの確認は行なわず、ターゲット上に搭載されているフラッシュロムのデータシートに規定された書き込みにかかる最大時間をホスト側で待ってから、その次の動作に移行するという設計になっていました。イメージ図にすること以下のようになります。ホスト側の処理を台詞にすると、以下のように随分と乱暴な感じ。言うと「データシートに書かれた最大時間は待ったんだから終わってんだろ?」という話ですが、これには幾つか問題があります。常に最大時間待つので、必然的に書き込みが遅くなる。ソフトウェア上で待つという事は、必然的にバラツキを生む事になる。待つ処理に対するバラツキは、実行環境によっても異なる上、それは予想し難い。目に挙げた「最大時間待つ」問題は、実はセクタ消去にも適用していたので、のっけから劇遅な状態を生んでいました。これは本来、フラッシュロムのステータスレジスタを参照して、次の処理に移行可能か確認するようにすれば高速ですし、そもそも次の処理が失敗する可能性もなくなります。二番目に挙げた「待つ処理のバラツキ」問題は、根拠としているデータシート上の最大時間を保証できない可能性もあるという意味で大問題です。これも、先のフラッシュロムのステータスレジスタを参照してから次の処理に移行する事で解決できます。0.5.0では、プロトコルバージョンを2に変更した上で、フラッシュロムのステータス取得コマンドを追加しました。これにより、ターゲット側のブートローダも更新が必要になりましたが、これによって安定動作が得られるならば何の問題もありません。新しくflash_busyというインターフェースがflash.hに追加され、各ターゲットはこの定義に対する実装を要求されるようになります。改良版のホスト側の動作をイメージ図にするとこんな感じでしょうか?ホスト側のコントローラは、ターゲットからフラッシュロムのお仕事が完了したのか、逐次必要に応じて問い合わせるようにしました。余計な待ち時間が不要となり、従来よりも動作が高速になりました。書き込み処理の安定性が向上しました。環境に依存せずに書き込みができるようになりました。