Tool)」でも取り上げたように、リアルタイムシステムでは、ある作業単位を設計し、タスクに落とし込んでいく形でシステムを実現するのが通例です。先の記事では、タスク間通信の関係を実装から簡単に明らかにする方法を紹介しました。タスク間通信の関係が明らかになることで、システムの中の複数のモジュールの依存関係が明確になり、システムに与える刺激(入力)とシステムから得られる反応(出力)を推測できるようになります。先のタスク間通信の関係を明らかにするツールは、あくまでもソースコードから得られる静的な情報を基にしたものでした。実際のリアルタイムシステムの場合、複数のタスクの相互関係性が常に変化するため、ソースコードから得られる静的な情報だけでは、見て取れない動作が膨大に存在します。そこで、今回は上記の可視化ツールに加えて、実際のシステムの挙動を観察する事のできるロギングツールを設計実装しました。本ツールの特徴を挙げます。シリアルポートのある組み込みシステムなら、どんなシステムでも使用可能。組み込みシステム側に巨大なメモリが不要。記録時間はホスト側のストレージの容量に依存。シンプルな設計で移植や改造が容易。Linuxと3つのプラットフォームに対応。(NT-Logger)による最終出力はブラウザ上で確認する事ができます。マウスホイールで時間軸を伸ばしたり縮めたりしながら、システムの全体挙動を確認できます。Visualizerを使用したのですが、その時からNT-Loggerのプロジェクトがスタートしました。Visualizerは、ターゲット側のメモリにイベント情報を記録し、あるタイミングでホスト側に記録したデータを出力するという仕組みでした。この場合、ターゲット側に巨大なメモリが存在していなくてはならず、TOPPERSのように小規模組み込みシステムで使用したいOSのロギングツールとして魅力をあまり感じませんでした。(NT-Shell)の設計実装を開始したのでなかなか手が回りませんでした。(NT-Logger)の対象外NT-Loggerは、上記に記した特徴示すと同時に、幾つかのトレードオフについてユーザに説明する必要があります。ターゲットとホスト間の通信経路においてのバッファリング等による遅延などの影響は考えない。対して十分に小さく無視できるものとして扱う。絶対時間情報を必要とするようなデバッグには使用できないが、メッセージパッシングで駆動するリアルタイムシステムにおいて、通常は因果関係が明らかであるので問題ないものとして扱う。非同期システムのデバッグに使用できない事を意味するが、因果関係のはっきりしないような不確定要素を含むリアルタイムシステムは、そもそも設計してはならないものとして、これを無視する。ロギングのためのオーバーヘッドは無視できるほどに小さいものとして扱う。中には少し過激なトレードオフに見えるものもあるかもしれません。これはNT-Loggerが「無いより遥かに便利!」、「しかも無償で使える!」というところを念頭に置いているからです。「そんなロギング意味がない!使い物にならない!」というケースでは、こんな中途半端なツールは使うべきではないでしょう。それは、NT-Loggerがとったトレードオフに含まれる種々の問題を解決したツールを使うべきです。いうのが、NT-Loggerの立場です。どんな組み込みシステムでも使える組み込みシステムの全体挙動を確認するためのツールは、市販品を中心に星の数ほど存在します。多く見られる実現形態の一つが、ターゲットとホストの間に専用のハードウェアを介入させて、忠実にイベントをロギングする形態です。確かに忠実なイベントのロギングには、これが一番信頼性の高い方法でしょう。中間装置が正確な時刻情報を付与すると共に、データをバッファリングし、ホストコンピュータの処理能力に影響されずに正確にロギングする事ができます。これらの中間装置を必要とするロギングツールの場合、導入コストがかなりかかる事が多いです。実際の開発では、システムの全体挙動の概要を確認するだけで、どんな問題があるのかわかる事も多々あります。調べたいだけの時に高価なロギングツールを購入できるかどうかは状況によります。先のトレードオフでも述べたとおり、組み込みシステムの場合はイベント駆動型で設計するのが普通のアプローチです。原因と結果の依存関係を緩い依存関係で留める事ができるわけです。NT-Loggerは、多くの組み込みシステムに搭載されているシリアルポートを有効に活用し、必要最低限のロギング機能で最大限の効果を挙げることを目的に設計されています。因果関係が明らかになっている組み込みシステムの場合、簡単なロギングメカニズムを追加するだけでも十分な効果が得られるというわけです。設計と概念などここで、設計や概念などを記しておきます。基本設計と概念イベントは、「イベント発生源」から発生する。イベントは、イベント情報で表現される。イベント情報には、「始まり」と「終わり」を示す「タイプ番号」がある。イベント情報には、「イベント発生源」を示す「トラック番号」がある。イベント情報には、イベント内容を示す「イベント番号」がある。ターゲットから送られるイベント情報には、「トラック番号」と「イベント番号」と「タイプ番号」が含まれる。ホストは、ターゲットから送られるイベント情報に時間情報を付与して記録する。ホストは、記録されたデータを基にした可視化データを生成する事ができる。NT-Loggerの使用手順ターゲット側プログラムにロギング用APIを埋め込み動作させる。ホスト側でキャプチャプログラムを実行する。キャプチャされたデータからHTMLを生成するジェネレータを実行する。ブラウザで結果を確認する。最大トラック数は16トラック。1トラックあたり8つのイベントを記録可能。(単純計算で16x8=128事象が扱える事になる。)記録イベントの分解能はマイクロ秒単位。RAMが1KBを切るようなシステムでも使用可能。ターゲット側は最小限のAPIの実装のみで移植可能。データはブラウザで閲覧可能。現在初版のリリースに向けて作業を開始しています。このブログもNT-Loggerまみれにしようと考えています。秋の特別企画「茶室で楽しむKOZOS拡張基板」の基板実装を完了させました一点一点お家で手作りATNDで大募集していた「茶室で楽しむKOZOS拡張基板」の実装を完了させました。ミスタードーナツさんではないですけど、本当に一点一点お店で、じゃなくてお家で手作りしました。この基板は、総部品点数が68で、半田付け箇所は300箇所を超えます。今回は10台製造したので、総部品点数は680個、半田付け箇所は3,000箇所を超えるということになります。これはしんどいわけです。10台、されど10台。意外に動作確認も大変なのでブートローダ側も機能検証用の機能を盛り込みました。スタートアップ時の動作を見ると基本機能が動作しているのかわかる仕組みです。LEDを点灯させ、音声を出力し、SDカードの有無を検出し、SDカードからデータを読み、ディスプレイに表示を行ない、と初期化の後であれこれのデバイスを使うようになっています。ブートローダの段階で基板の基本機能検証ができますから、わざわざOSをブートさせなくても済むという仕組みです。後はエイジングと最終機能検証を行って、「茶室で楽しむKOZOS拡張基板」に挑む事になります。この基板実装を外注に出した時の試算これを外注さんに出した時の事を考えて(出す予定はありませんけど)、P板さんの実装サービスで試算してみました。昨今、思ったほどの驚き価格ではないのですね。パッケージちょっと余談ですが、半田付けに飽きた時に現実逃避でパッケージも考えました。皆様にお届けするのに「基板だけぽーん」とか「段ボール箱にボコン」なんてしません。こんなパッケージに収めて参加者の皆様にお届けします。EXPBRDのサンプル・ファームウェアを設計と実装を行なっていました。サンプル・ファームウェアでは、SDカード上にあるmp3ファイル読み込みながら、mp3デコーダを制御し、赤外線リモコンやユーザ入力を受け付け、ディスプレイの表示をし・・・と沢山の仕事をKOZOSを使ってこなしています。組み込みシステムでは、システムが提供する機能をある処理単位に分け、複数のタスクに分割した上で所望の機能を実現するために協調動作させるように設計します。複雑な制御も、単純な動作になるまで分けて考えていく事で設計と実装を容易にする事が出来ます。組み込みシステムの場合、ある出来事(イベント)を中心に動作を実行するイベント駆動型としてファームウェアを設計するのが通例です。タスクは基本的に他のタスクから受けたイベントを起点に動作します。Communication)」と言ったり、OSによっては「メッセージ・パッシング」と呼びます。上記のように設計する事で、タスクとタスクの間の依存関係は非常に緩いものにする事ができる他、新たな機能を付け加えやすくなったり、デバッグが容易になったりします。設計文書でいくら図示してあったとしても、実際にコードに落とし込んだ段階でそれらの情報は失われてしまうため、後からコードを見た第三者がファームウェア全体の挙動を把握するのには非常に時間がかかります。今回は、このような時に便利な方法として内部タスク間コミュニケーションを可視化するツールを作ってみましたのでご紹介します。今回は茶室で楽しむKOZOS拡張基板の企画もあるので、KOZOSを題材に実装してみました。実例1KOZOSの作者である坂井さんがお作りになったTCP/IPアプリケーションを題材にしました。http://kozos.jp/kozos/h8_2_06.htmlまずは下の図をクリックして大きくしてご覧下さい。KOZOSのタスク間通信は、kz_sendとkz_recvとkx_sendから構成されています。図を見てわかるように、タスク(及びそれっぽいもの)が丸枠で囲われたもので表現されています。メッセージ通信の橋渡しとなるメッセージボックスが長方形で表現されています。それっぽいものと書いたのは、ソースファイル名で抽出しているので必ずしもタスク名とイコールでないこともあるからです。上記を見てわかるように、ソースコードを眺めて関係性を把握するよりも遥かに直感的です。実行方法は簡単でシェル・スクリプトをKOZOSアプリケーション・ディレクトリで実行するだけ。EXPBRDのサンプル・ファームウェアにも適用してみました。こちらは少し改造したシェル・スクリプトですが、だいたい同じものです。こんな感じでKOZOSで構成した各タスク間のタスク間通信の関係をひと目で把握できます。実行方法リソースからサンプル・コンテンツをダウンロードして下さい。ipcrvt.shをKOZOSアプリケーション・ディレクトリで実行して下さい。外部依存は幾つかのコマンドとGraphviz/dotのみ。簡単なシェルで構成されているので改造も容易です。オプションは取りません。リソース坂井さんが実装されたTCP/IPアプリケーションのコードと、可視化スクリプトipcrvt.shを同梱したパッケージです。ipcrvt.tar.gzをダウンロードまとめ現状のipcrvt.shは、まだまだ表示したい情報が欠けいていますし、随分と荒削りな設計と実装です。ソースコードを目視で把握するよりも遥かに早いスピードで関係性の概要を把握する事ができるという点で、第1段階のアプローチとしてはまずまずな結果と言えるでしょう。このツールを使って関係性の概要を把握した上で、ソースコードを読み解いていけば理解が素早く理解を深める事ができる気がします。組み込みシステムで特に意識する必要のあるタスク間通信の学習においても、有用なツールの一つとして役立てることができそうです。今回はKOZOS向けにシェル・スクリプトを構成していますが、同様の考えを使って他のRTOSでも使用する事ができます。(Atom)自己紹介shinta基板が大好きな組み込み系エンジニア。電気図面を描いてPCB上に美しく配線できた時に何とも言えない快感を覚える。ソフトウェアとドライバが一式になったパッケージをダウンロードします。インストール後に本体を接続してソフトウェアを起動すると以下のような画面が表示されます。勢いよく「改良しました!」と宣言したh8writeですが、やっぱり書き込みに失敗するという事がわかりました。そもそも真の原因を掴めないまま改良したと言っても、何を改良したのか意味がわかりません。自分でもそんな突っ込みを入れたくなるのですが、その日はグ...システムにおけるレイテンシーとスループットの話題レイテンシーとは、あるシステムに何らかの入力を与え、それに対応する何らかの出力が出てくるまでの時間(遅延量)を指します。ある処理の実行を指令してから実際の結果が得られるまでに250ミリ秒かかったとすると、それは250ミリ秒のレイテンシーを持つシステムという事になります。放置を防ぐアイデアの1つとして「具体的な目標に繋げる」というものを挙げました。アップデートしました。このアップデートにより、以下の動画で示すような長い曲でも難なく再生させる事ができるようになりました。mkIIは便利なのですがオンフィールドで書き換えるには不便ですし、ユーザに書き変えを頼むわけにもいきません。Atmelが公開しているアプリケーションノートAVR109に自己プログラミングがありましたので試してみました。LPC824を使ったサウンドモジュールMicroSoundModuleを開発していました。このサウンドモジュールは、コマンドを受け取って色々な再生を行うもので、当初はこのコマンド処理部分の実装にNT-Shellを用いる計画でした。BlackTankには有機EL液晶が搭載される予定です。接続部分はFPCになっていて、例によってFPC用コネクタなのですが、最初の実装は思いっきり失敗してしまいました。猫も杓子もIoTと皆さんが仰るので、その声が大きくなればなるほど自分は遠ざかる方向で生きていたのですが、そうすると完全に煙に巻かれたお爺さんのようになりまして、今は世の中が進んでおるんじゃのぉと言うだけの人です。moduleにブートローダを載せる(AVR109対応)随分前に対応しようと思い立っていたAVR109にようやく対応させた。以前やった時にうまく書けなかったのはボードのクロック精度が原因。ここ数日モニタを実装していて、思った以上にRC内蔵クロックの精度が悪いことが分かった。エコーバックのテストでやたらと文字が化ける。