2011年5月28日土曜日

野良管理していたソフトウェアをsourceforgeでホスティングする事にしました。

先日まで野良管理していたソフトウェアですが、sourceforgeで正式に（？）ホスティングすることにしました。バージョン管理はgitを採用しています。

Natural Tiny Shell (NT-Shell)

以下のウェブページからアクセス可能です。

http://sourceforge.jp/projects/ntshell/

H8/3069F writer for KOZOS (kz_h8write)

以下のウェブページからアクセス可能です。

http://sourceforge.jp/projects/kz-h8write/

ドキュメントなどもこれから充実させていく予定です。

2011年5月26日木曜日

H8/3069F writer for KOZOS - kz_h8write 「h8writeリベンジ解決編」

概要

先日の記事で勢いよく「改良しました！」と宣言したh8writeですが、やっぱり書き込みに失敗するという事がわかりました。
そもそも真の原因を掴めないまま改良したと言っても、何を改良したのか意味がわかりません。
自分でもそんな突っ込みを入れたくなるのですが、その日はグングン快調に書けていた上、オリジナルで実行するとやっぱり書けないという状態で、完全に勘違いモードに突入していました。

既に行く先の見えているH8/3069Fに肩入れするつもりはなかったのですが、KOZOS本（と著者！）が楽しくて仕方がないのと、宣言して出来なかった悔しさから本格的に問題を追及すべく、データーシートを片手にh8writeのソースコードを本格レビューしていくことにしました。

判明した事実

データーシートのプログラミングシーケンスを数分眺めていて、すぐに気付いたことがあります。

先日までは、プログラミングシーケンスなど気にも留めていなかったのです。
なぜなら１０年もの間、皆さんが使い倒していて、正常に動いていたからです。
そこにあえて突っ込みを入れる必要はないだろうと思っていたのですが、ここが肝心な部分でした。

問題となっているのはホスト側のボーレートをマイコンが自動検出するメカニズムの部分です。

まずはデーターシートを見てみましょう。

このシーケンスで重要なのはホストからブートプログラムに送られる0x00です。

図にもあるように「MAX30回」です。
この意味が重要です。
決して、「いつも30回」ではありません。

それでは、h8write.cを見てみます。

関連する定義は以下のようになっています。

上記でお分かりのとおり、「最大30回」ではなく、「常に30回」送信しています。
これの何がいけないのでしょう？

答えはデーターシートに書いてあります。

要するにブートローダが合わせ込み完了を通知したら、次の状態に遷移しているのです。
では、遷移した先の問い合わせ選択コマンドとは何なのか？見てみましょう。

デバイスに関する様々な情報をホストが問い合わせするためのコマンドを受け付ける状態のようです。

要するに既にブートプログラム側は「ビットレート合わせ込みシーケンス完了」を宣言し、全く異なるシーケンスを持つ次の状態に遷移しようとているのに、ホスト側がだらだらとビットレート合わせ込み用データをまだまだ垂れ流しているというわけです。

これはいけません。

本来は、ブートプログラムから「ビットレート合わせ込み完了」が来た時点で、以下の図の赤で囲ったシーケンスを実行しなくてはならないからです。
だらだら0x00を送っているということは、本来確認用コード0x55を送るべきところで、0x00を送っている事を意味します。

オリジナルのh8writeの出力をもう一度確認してみます。

当然ながら実装の通り、ブートローダから「合わせ込み完了」が返ってきているにも関わらず、どんどん0x00を送出しています。

上記例は”たまたま”うまく動作している時の例です。

”たまたま”の根拠は先ほど挙げたデータシートの通りです。

明らかにデータシートで示唆されたシーケンスとは異なる事がわかります。

次に示すのは互いのシーケンスが一致していない事による失敗の例です。

失敗する時と明らかなタイミングの違いがあるかと思ったのですが、そのようには見えないのが不思議です。紙一重で動いていると言う事なのでしょうか？

ここで、ふと疑問に思われる事でしょう。
「なぜ皆はうまくいっているんだ？」
システムではよくある話ですが、おそらく偶然動いているだけです。

これにはいくつものタイミングが絡んでいます。

ソフトウェアが処理を行うまでの時間。
シリアルポートドライバが処理を開始するまでの時間。
カーネルが処理を開始するまでの時間。
H8側のブートプログラムが合わせ込みを完了するまでの時間。
H8側のブートプログラムが次の状態へ遷移するまでの時間。

特に、近年はレガシーポートが姿を消しています。
USBの先にシリアルポートデバイスが接続されるような場合には更にタイミングが従来より異なるでしょう。

まさに今回のh8writeの問題はここに原因がありました。
従来は偶然書けていたのです。

h8writer for KOZOS - kz_h8write

h8writeは長年沢山の方々がお使いになっていて実績という意味では申し分ないのですが、実装が美しくありません。
車輪の再開発をするつもりはないのですが、頭の整理も兼ねて綺麗に実装しなおすことにしました。

プログラムは「KOZOS本と一緒に使う」という意味でkz_h8writeと名付けました。

kz_h8writeは以下の要素から構成されています。

motモジュール（motファイルを読み込むモジュールです。）
serialモジュール（シリアルポートを制御するモジュールです。）
kz_h8write（全体の制御を行うモジュールです。）

オリジナルh8writeの実装は各機能が癒着気味で修正の影響が見えにくくなっていました。
また、失敗した時に何の処理で失敗したのか見当がつきにくかった問題もあります。

問題のビットレート合わせ込みは以下のように実装しました。
データーシートにあるように計測用マーカーを送信して、ブートプログラムからの返答を確認した時点でこちらも応答を返すという手順にしてあります。

実際のやりとりもロジックアナライザで観察してみました。
ホストからのビットレート合わせ込み用コード(0x00)に対して３回目には応答が返ってきています。

kz_h8writeは応答があった時点でデータシート通り、確認用のコード(0x55)を送出しH8から返答(0xE6)を受けています。

これでホストとH8は合わせ込まれたビットレートで正しく通信できるわけです。

kz_h8writeコマンドツールにはmotファイル名、クロック周波数[MHz]、シリアルポート名を与えて使用します。

kz_h8write kzload.mot 20 /dev/ttyUSB0

各シーケンスが実行されていく様子を確認する事ができます。

=======================================
 KOZOS H8/3069F Flash Writer.          
 Copyright(C) 2011 Shinichiro Nakamura 
=======================================
Bitrate sequence: Done.
Inquiry device: Done.
Select device: Done.
Inquiry clock mode: Done.
Select clock mode: Done.
Select bitrate: Done.
Write erase: Done.
Complete.

全ての作業が完了した時には「Complete.」と表示が行われます。

今回の実装で複数の環境で昨日今日と試していますが、期待通りに動いています。
※まれに電源投入後１回目は失敗するのですが、もう一度実行するとうまくいきます。

前回と異なるのは明らかにおかしい箇所を修正したバージョンだということです。
原因（の１つ）を解明して修正していますので、先日の「何だかわからないけど動くようになりました！」とは意味が違います。

このkz_h8writeを暫く使ってみようと思っています。

ソースコード

LinuxとWindows上で動作させることができます。
ソースコード：ここからダウンロードして下さい。

(2011/05/28追記)
http://sourceforge.jp/projects/kz-h8write/で管理することにしました。
最新版は上記サイトからダウンロードして下さい。

ライセンス

MITライセンスを適用します。
商用、非商用を問わず自由にお使い頂けます。

どうしてオリジナルではいけないの？

オリジナルではいけないということはありません。
このh8write for KOZOSはオリジナルのh8writeで書き込みに失敗する方のためのツールです。

近年、レガシーポートがコンピュータから姿を消し、結果的に当該ボードにはUSB-シリアル変換ケーブルを使って書き込む事が多くなっているように思います。

KOZOSの書籍で扱っているH8は3069です。

実は、オリジナルのh8writeでは、USB-シリアル変換ケーブルを使うケースにおいて、一部の環境で書き込めない問題が発生しています。

実際に調べてみるとH8/3069の書き込み時には、ボーレート9600でCPU情報を確認した後、COMポートを一度クローズし、ボーレート19200で再オープンして書き込みを行っている事がわかりました。

オリジナルのコードではこのボーレートを指定しながらのオープン・クローズ処理周辺の実装に問題があるように見えました。

と言っても、ツールの実装当時から見ると、カーネル側の処理も随分変わりましたし、USB-シリアル変換ケーブルに搭載されたデバイスのドライバの実装の甘さも関連があるかもしれません。

そこでシリアルポートの処理を中心に実装を試験的に見直し、書き込みに失敗する幾つかの環境で試行してみたところ、うまく書き込めることがわかりました。

ダウンロード

こちらからソースコードをダウンロードして下さい。
簡単なMakefile付きです。

Ubuntu 10.10上でのみコンパイルと動作を確認しています。
その他の環境での動作確認等が出来ましたら、是非御報告頂ければ幸いです。

(2011/05/26追記)
この投稿記事で取り上げられている内容は本質的な解決策を示しているとは言えませんでした。
そこでH8/3069F writer for KOZOS - kz_h8write 「h8writeリベンジ解決編」を公開しました。

何が違うの？(実装面)

シリアルポートの実装を分離しました。
シリアルポートの実装を見直しました。
関数名を一部変更しました。
Windowsに対する実装サポートはバッサリ削除してあります。

何が違うの？(実動作)

うまく動作することがわかったら、どんな風に実動作が異なるのか知りたくなります。

オリジナルのh8writeを使って書き込みに失敗する環境を用意し、観察してみます。
確認したのは「最初にH8にデータを送信する箇所」です。

NG: オリジナルのh8write

OK: 改良実装版h8write

最初に送信するデータはボーレート9600で送信されます。
なんだか、最後の方が異なります。
もう一度書いておきますが、シリアル周辺の実装を修正しただけです。

続くパケットではプロセッサの種別を確認するのですが、オリジナルの実装ではこの時点で動作していないことがわかりました。

まとめ

h8writeの実装には気になる点がいくつもあります。
今回は深追いをせずにシリアル周辺の実装のみを修正して効果を確かめました。

今のところノートパソコン、デスクトップに作った２つの環境で書き込みが出来ています。
実は、この２つの環境はオリジナルのh8writeでは書き込みに失敗します。

本来であれば、もう少し丁寧に追い込まなければならない点が残っています。
しかし、かなり多くの方が「書き込めない」で困っている様子（私自身がそう）でしたので、早めに公開することにしました。

皆さんのh8writeの問題が解決し、KOZOSを楽しんで頂ければ幸いです。

（検証に御協力頂ける方）Linuxディストリビューション名と使ったUSB-シリアル変換ケーブルなどもろもろの情報と共にhttp://groups.google.com/group/kozos_tomonokaiまで動作結果を御連絡下さい。

(2011/05/26追記)
この投稿記事で取り上げられている内容は本質的な解決策を示しているとは言えませんでした。
そこでH8/3069F writer for KOZOS - kz_h8write 「h8writeリベンジ解決編」を公開しました。

ライセンス等

ライセンスはオリジナルに従います。
但し、serial.cとserial.hをh8write.cと切り離して用いる場合、MITライセンスを適用します。
使用した如何なる結果についても、当方は責任を持ちません。

2011年5月22日日曜日

Natural Tiny Shell (NT-Shell)をmbedで使ってみる (Eating your own dog food)

「自分のドッグフードを喰う(Eating your own dog food)」はソフトウェア開発の世界で有名な台詞です。

自身で作ったソフトウェアを自身で使うことで、それがどのように有用か（あるいはそうでないか）を知る事ができるというわけです。

例にならってNatural Tiny Shell (NT-Shell)をmbedで使ってみることにしました。
目論見は簡単に移植できるというところです。

しかし、実際に移植してみると幾つか気になる点がありました。
これは興味のある方のために後述。

移植した結果はmbed.orgにアップロードしました。
興味がございましたら、ご自由にお使い下さい。

http://mbed.org/users/shintamainjp/notebook/ntshell_ja/

2011年5月19日木曜日

Natural Tiny Shell (NT-Shell) ライブラリを更新しました。

Natural Tiny Shell (NT-Shell) ライブラリは小規模組み込みシステムの為のシェルライブラリです。
本日新しい機能（入力補完機能）を加えて更新しました。

入力補完と１口で言っても色々な種類の補完が考えられます。
今回の入力補完機能は過去に入力した文字列の中から候補をTABキーで選出する事ができるというものです。

デモ映像を用意しましたのでご覧下さい。

ソースコード： Natural Tiny Shell (NT-Shell) Version 0.0.6

インターフェースはかなりシンプルです。
ntshell.hのntshell_executeインターフェースのみ知っているだけで使用することができます。
このため、様々なシステムに簡単にポーティングする事ができます。
是非みなさんの小規模組み込みシステムでお楽しみ下さい。

Natural Tiny Shell (NT-Shell) library was updated.

Natural Tiny Shell (NT-Shell) library is a tiny shell library for a small embedded system.
Today, I just updated the library.
The new feature is historical input.

Please see the demo movie.

The source codes : Natural Tiny Shell (NT-Shell) Version 0.0.6

The interface is really simple.
You should only know ntshell_execute in ntshell.h.
So you can port it to any embedded system easily.
Please enjoy your small embedded system with it. :)

2011年5月14日土曜日

LPC1769の内蔵ブートローダを使って書き込みに失敗する環境がある（lpc21isp使用時）

概要

ARM Cortex-M3で遊ぼうということで設計したNXP LPC1769搭載基板。
グダグダと色々なファームウェア部品を作ったりして楽しんでいるわけです。

このボードには「いつでもどこでもLPC1769」という裏コンセプトがあり、

「だいたいパスポートサイズ」
「USBバスパワーで動作する」
「内蔵ブートローダで書き込みができる」

といった特徴があります。
ノートパソコンとこのボードとUSBケーブルさえあれば、開発を楽しむ事ができる仕組みです。
「ちょっとしたデモ」であれば十分対応できます。

この特徴を生かして今日の今までノートパソコンを使った開発で楽しんでいました。
ふと思い立って自宅の大画面環境で作業した方が効率も良いし・・・と思った時の事です。

なんと、LPC1769の内蔵ブートローダを使った書き込みに失敗します。
何度やっても再現性100%で。

どちらもVMware Player上に仕立てたUbuntu 10.10で行っています。
プロジェクトのリポジトリから書き込みスクリプトを含む全てのリソースをチェックアウトして作業しています。

異なる可能性があるとすれば、ローカル環境設定とツールのバージョンくらいでしょう。
これに依存する何かが書き込み時の起こっているとは考えにくかったのですが、「おかしい、おかしい」と言っているだけでは前に進みません。

そこで先日購入したロジックアナライザでちょっと見てみることにしました。

正しく動作する環境

まずは正しく動作する環境の方です。
lpc21ispのバージョンは1.79です。

正しく動作しない環境
次に正しく動作しない環境の方です。
lpc21ispのバージョンは1.64です。

さて、何か変ですね？
ちょっと見比べてみましょう。
上側は動作する時、下側は動作しない時の要求と応答です。

整理してみます。

lpc21ispのバージョン	状況	lpc21isp	LPC1769	Synchronized確認トークンの補足説明
1.79	正しく動作する	Synchronized\n	Synchronized\nOK\r\n	lpc21ispとLPC1769で一致している。
1.64	正しく動作しない	Synchronized\r\n	Synchronized\rOK\r\n	lpc21ispは\r\nをセパレータとして使用している。LPC1769はそれとは異なるセパレータを返す。(ように見える)

「ように見える」と書いたのは、ここがポイントだからなのですが、それは後述します。

この手の書き込みプロトコルは、ターゲット上の内蔵ブートローダとホスト側のアプリケーションの協調動作で成り立ちます。
例えばアプリケーション側から「ＸＸＸだぜ！」と要求を受けて、内蔵ブートローダが「おっけー！」という具合です。
例に漏れずLPCシリーズの内蔵ブートローダもそのようになっています。

上記２つの環境間で異なるのはトークンセパレータのようです。
では、どちらが本来の実装なのでしょうか？

データシートを見てみます。

「全てのISPコマンドは単一のASCII文字列で送られなければならない。」
「文字列はキャリッジリターン と/か ラインフィードによって終端されなければならない。」

原文の「and/or」を「と/か」と訳しました。
要するに正解は

CR
LF
CR + LF

と、どれでも良さそうに書いてあります。

何かこの辺りの問題がありそうなのはわかりました。
では、立ち返って現象を見てみます。

user@ubuntu:~/Projects/TOPPERS-ASP-for-BlackTank-LPC1769$ ./devwrite.sh 
lpc21isp version 1.64
File TOPPERS-ASP_BlackTank-LPC1769.hex:
loaded...
converted to binary format...
image size : 115032
Synchronizing (ESC to abort). OK
No answer on Oscillator-Command

「オシレータコマンドの返答がない。」と言っていますね。
これが最後のやり取りのようです。

応答がないため、アプリケーション(lpc21isp)がそれ以降の処理を中止して終了するわけです。
でも、実際にはLPC1769から応答が返ってきています。

先ほど見た「Synchronized」は非同期シリアル通信の通信速度を自動判別する部分です。
これは書き込み動作の前の最初の操作ですから、オシレータコマンドとは関連ありません。

オシレータコマンドのやりとりを探すために、トリガがかかってからのサンプル数を増やしてみます。
以下は正しく動作しない環境でのやりとりです。

やりとりは以下のようになります。

アプリケーション：「4000で頼む。」
内蔵ブートローダ：「4000ね。おっけー！」

さて、正しく動作する環境で見てみましょう。

面白いのはアプリケーション側からやってくるセパレータによって、内蔵ブートローダ自身が用いるセパレータも変えてくるという点です。

但し、上記動作を見て下さい。
アプリケーション側が２つのセパレータを送った場合、内蔵ブートローダは先頭のキャラクタのみを採用するようです。
また、「OK\r\n」という固定的な返答も見られる事から、混在しているようにも見えます。

この動作は、アプリケーション側がデータシートに書いてある通り「CR」でも、「LF」でも、「CR + LF」でも正しく動作するよう実装してあれば問題ありません。

ですが、私の手元にあった古いlpc21isp (Version 1.64)ではそうなっていないということがわかりました。

本来であれば、このコマンドに続いてアプリケーション側から書き込み用のデータが送られてきます。
しかし、失敗する環境では「返答がない。」と判定されていました。
恐らくセパレータの解釈に問題があるのでしょう。
もしかしたら、受信側のセパレータの解釈に問題がありながら、送信側で対応したのかもしれません。その証拠に２つのバージョンでは送信するセパレータが異なる事がわかります。

この件に関して言えば、最近のバージョン (Version 1.79)では修正されているので心配ありません。
LPC1768やLPC1769を使う方の御参考までに。

おわりに

この手の問題は実際に色んな調査をしてみなければ原因がわからないことが多いので大変です。

今回のケースでは「あぁ、lpc21ispが古いのだなぁ」と片付ける事もできます。
ですが、「２つのバージョンでどのように異なり、その差異の何が問題となるのか？」を調べることで安心して使用できるようになります。

ウェブ上にある情報は断片的なものが多いのですが、「どのような問題があり」、「それをどのように解決したのか？」を自分のために整理すると意外に面白い発見になるのかもしれません。

2011年5月4日水曜日

B028 : LED MATRIX 100 差し上げます。

(2011/06/02追記)
締め切りました。
沢山の御応募ありがとうございました。

MTM05で販売していた(そして１台売れた！)ATMEGA8L搭載のLED電光掲示板の基板とケースをセットで差し上げます。

* AVRを使った電光掲示板の実験ができます。
* 無保証です。サポートもありません。
* 送料は御負担下さい。

回路図はこちら。
役に立たないファームウェアはこちら。

それでも欲しいと言う方は @shintamainjp まで御連絡下さい。
あと３台あります。

ぞうさんとかくるまとか表示できます。

B041 : SD CARD MODULE 差し上げます。

(2011/06/02追記)
締め切りました。
沢山の御応募ありがとうございました。

MTM05で販売していた(そして１台も売れなかった！)ATMEGA8L搭載のSDカード実験基板を差し上げます。

* マイクロＳＤカードスロットを搭載しています。
* AVRを使ったFATファイルシステムの実験ができます。
* 無保証です。サポートもありません。
* 送料は御負担下さい。

回路図はこちら。
役に立たないファームウェアはこちら。(でも、ChaNさんのPetit FatFSは素敵ですよ。)

それでも欲しいと言う方は @shintamainjp まで御連絡下さい。

B051 : WAV MODULE 差し上げます

(2011/06/02追記)
締め切りました。
沢山の御応募ありがとうございました。

ATMEGA328P搭載の基板を差し上げます。
MTM05で販売していた(そして１台も売れなかった！)ものです。

* マイクロＳＤカードスロットを搭載しています。
* オーディオ用ステレオ16ビット D / Aコンバータ(BU9480F)を搭載しています。
* AVRを使った簡単なオーディオの実験ができます。
* 無保証です。サポートもありません。
* 送料は御負担下さい。

回路図はこちら。
役に立たないファームウェアはこちら。(でも、ChaNさんのPetit FatFSは素敵ですよ。)

それでも欲しいと言う方は @shintamainjp まで御連絡下さい。

自宅ラボの大掃除を始めました(今回捨てる思い出の品)

自宅ラボの大掃除を始めました。
懐かしい物が沢山出てきます。
下らない物ばかりなのですが、思い出ということでなかなか捨てられません。
こんな事をしていては将来ゴミの山になってしまいます。
そこで、写真に撮ってどんどん捨てる事にしました。

まずは「B011: Digital Design Board」という名前の基板。
１０年くらい前に某大学のオープンキャンパス用に設計したもの。
約２０台（だったかな？）製造してお渡したやつ。

うーん。懐かしい。

そしてその頃の別基板。
PICをアセンブラでゴリゴリ使っていたころの物。

この棒を横に振ると文字が出るっていうものですね。
で、これがパターンのフィルム。

当時は確かPCBEなんかを使って、片面基板を自分で作ったりしていました。
「基板が出来た。嬉しい。」とか言って。

これはどうやって作っていたんだろう。
今となっては思い出せません。
部品配置を検討した時の図だと思いますが。

これもひどい。
大量に在庫している赤色ＬＥＤを活用しようというＬＥＤマトリックス独自設計。

「思い立ったらやらずにいられないたち」なのですが、高い、作りにくい、使いにくいの三重苦でした。
こういうのは市販品を買えば良い、と学んだ一品。
手元にある部品を有効活用どころか、時間という最大資源を大量浪費しました。

次にmp3プレイヤー。
これはつい最近の物のはずだけど、自分の中でかなり陳腐化。

元々、RTOSを使ったアプリケーションを構築するつもりで設計。
実際にFreeRTOSをATmega328で動作させるところまでは出来ていて「面白さ」を感じていたのです。
が、プロセッサのパワーから言うとあまり実用的とは言い難い感じでやめてしまいました。
（もうちょっとやっても良かったかな？）

そして、他の人が見ると意味がわからないのがこれ。

ROLANDかBOSSか忘れてしまったのですが、1Uのディジタルリバーブのパネル部材。
高校生の時に中古を買ったような気がします。ROLANDのSE-70に憧れつつ、高価で購入を断念。

当時から組み込み装置に憧れていた自分は、「どうやったら機器を美しく見せられるんだろう。」と考えていました。
この装置は単なる７セグが表示器として採用されていたのですが、それでもやはり美しく見せる工夫はしてあるんだなぁと思ったものです。

やっている時や見ている時は凄く真剣なんですけど、後から見ると恥ずかしい物ばかりです。

2011年5月1日日曜日

Saleae LLCのロジックアナライザを使ってみた

まずはhttp://www.saleae.com/downloads/からソフトウェアとドライバが一式になったパッケージをダウンロードします。

インストール後に本体を接続してソフトウェアを起動すると以下のような画面が表示されます。
[Connected]と状態が表示されていますね。

被測定対象にプローブを取り付けます。
今回はUART, I2C, SPIと三種類に対してプローブを付けてみました。

手始めにUARTでその機能を試してみましょう。

まず、測定ポイントに対する名前を付けます。

次にチャンネルに対するプロトコルを選択します。

プロトコルに対する設定が出てきます。

トリガをかけることもできます。
トリガをかけたいチャンネルのトリガ選択ボタンを押してからStartを押すとトリガ待ち状態になります。

この状態でUART TXからデータが出力されると・・・

上記のように確かに指定した条件でトリガがかかっているのがわかります。
取得したデータに対する値が表示されていませんが、御安心下さい。

ここで、マウスのホイールをクリクリ回転してズームアップしてみます。
（ついでにウインドウを少し横に伸ばしました。）

例えば、嬉しいのはデータビットに「●」が付いている事。
これでスタートビットやストップビットに惑わされる事もありません。

こんな感じでUARTの状態を簡単に見る事ができました。
うーん。便利。

また、解析結果をテキストファイルで出力することもできます。

txtとcsvを選べるようですが、どちらも出力内容は同じようです。

Time [s],Value
0,0x0D
0.000173,0x0A
0.000345,0x54
0.000518,0x4F
0.000691,0x50
0.000864,0x50

同じようにI2CやSPIなども簡単に確認することができます。
先ほどと同様、プロトコル解析の追加を行なうだけです。

I2Cの設定画面。

SPIの設定画面。

例えば、以下の画像はSDカードをSPIモードで読み出している場合の例です。
まぁ、何と言いますか「あれ？何でクロックがこんなにもたついてるんだ？」とか、そういうのも見れます・・・。

UARTやI2CやSPIなどプロトコル上のデバッグをする場合、「データの値が何であるのか？」を抽出するのに頭を使いたくありません。
むしろ、デバッグ時には「何が原因で問題を起こしているのか？」を突きとめる為に頭を使いたいところです。

データを可視化する部分はこういった便利な道具を使って効率よくデバッグしたいものです。

もう１つ面白いのはアナライザのソースコードをSDKと合わせて一緒にダウンロードできる点です。
これを起点にオリジナルプロトコルの解析を追加することもできるでしょう。

登録: 投稿 (Atom)

CuBeatSystems