SWEST14参加報告

勢い余って参加申し込みしておいたSWESTですが、あっという間に過ぎ去っていきました。
下呂までは長い道のりでしたが、コードを書いていたらあっという間です。

参加者数は200名弱でしょうか。
水明館はなかなか素敵な宿でした。

初参加という事もあって意味もわからず出したので、ちょっと場違いな感じもします。
次回以降、参加するなら再考したいです。

ポスターはズームランドさんに印刷を頼みました。
これはなかなか良かったかも。印刷内容はともかく。

今回は金子システムさんのところのDSP基板を搭載したBlueTankでNT-Loggerを、LPCXpressoを使った基板でNT-Shellのデモでお届けしました。

今回のDSP基板、とても気に入ったのでちょこっと宣伝もさせて頂きました。

NT-Loggerのデモでは、リアルタイム性を維持しながらシステムのロギングを実行する様子を展示しました。48KHzステレオサンプリングの音声を処理しながらロギングしてシステムの挙動を観察できます。

NT-Shellのデモは、「適当に作ったシェル」と「NT-Shell」による動作の違いを示し、適当に作ると何が問題なのか、NT-Shellで何を解決したのかを提示しました。

お越しいただいた皆様ありがとうございました。
様々な方と色々な意見交換ができてとても有用でした。

GPSモジュールGT-720Fの設定コマンドと応答

忘却の彼方のGPSモジュール

いつだったか忘れましたが、随分前に購入してそれっきりだったGPSモジュールGT-720Fを引っ張り出してきました。 

特にこのモジュールを使いたい強い動機はないのですが、TOPPERS/ASP for LPCのUART系のデバッグに色々繋いで確かめたいというのと、どうせデバッグするなら「何か本当に使っている感じが欲しい」という事からの再登場です。（本当に使っている感じにするのは、成果物をより実用的なものにする意図があります。）

先日の「LPCXpresso横浜お楽しみ部会」にあわせて適当に仕立てた時、（どうでも良いけど）気になる事があったので調べる事にしました。 （私の場合、本当に些細でどうでも良い事が気になって大事な時間を使ってしまったりして何だか残念な感じです。）

（どうでも良いけど）気になる事

• 「データ・シート」と言われているPDFに設定コマンドの仕様が書かれていない。
• 「SkyTraq(付属アプリケーション)では設定できるけど、マイコンからはできない。」と主張している人がいる。
• それっぽいPDFは見つかるが、GT-720Fで使えるのかわからない。
• 誰もあまり調べてない。

まぁ、GPSと言えばu-bloxでしょという感じで、このモジュールにそれほど時間をかける意味もないのですが、気にしなくて良いや、と思えば思うほど、どんどん気になってくるのです。

とりあえず調べる

コマンドのやり取りに関する「それっぽいPDF」は見つかったので、それを参考にアプリケーションとGPSの通信を見てみます。

下のやりとりは、Configuration NMEA Messageコマンドです。

以下のメッセージは、SkyTraqのNMEAメッセージ編集画面で設定を実行した時に、アプリケーションからGPSモジュールに投げられるコマンドです。

さて、GPSモジュールからは２つのパケットが返ってきました。

さて、ウェブに転がっていたApplication Note AN0003 Binary Messages Of SkyTraq Venus 5 GPS Receiver Ver 0.3 Feb. 1, 2007と比較してみます。(Start of SequenceとEnd of Sequenceを黄色で囲ってあります。)

以下の通り、メッセージのフォーマットが一致している事がわかります。

Configure NMEA Messageのペイロードの仕様は、以下のように記述されていました。

どうやらこのPDFの内容と完全に一致するようです。

ACKの場合、要求に応じてACK応答の後に情報を返してくるようになっています。

これは、先の結果どおりです。

このように、それっぽいPDFの内容と一致していそうという事がわかりました。

それではということで、マイコンに以下のようなインターフェースを実装してみました。

とにかくマイコン上のアプリケーションからこのインターフェースを呼べば、SkyTraqと同じ設定が可能になるというわけです。

試しにVTGのみ1秒に設定し、その他を0(出力なし)にしてみました。

どうやら制御できているようです。

ということで

ということで、GT-720Fの設定はSkyTraqからだけでなく、当然のようにマイコンからも可能である事がわかりました。

まぁ、だからなんだという感じですが、特別に摩訶不思議なシーケンスがあるわけではない、という事がわかってスッキリしました。

モジュールに対して、永続的に設定を書き込みたいわけではないけど使いたい設定がある場合には、やはりマイコンから直接操作してやりたいものです。

コマンドの中にはバージョンを取得するインターフェースもあるので、GPSモジュールのバージョンを調べるのも良いかもしれません。

「LPCXpresso横浜お楽しみ部会」を開催しました～。

「LPCXpresso横浜お楽しみ部会」を開催しました。

本日は、もくもく会の傍らプレゼンテーション３本をゆるゆるとこなすという会でした。

ライブな感じを味わっていただくための写真を掲載しておきます。

会場は神奈川県民活動サポートセンター 15階会議室(1501)でした。

この会は「ゆるゆる」な会なので、イラストで来場者の方を和ませる作戦です。

とびっきりの風景・・・とはいきませんが、遠くに見える海を眺めながらのもくもく会でした。

こちらは @h-kenken さん。
シェルからコマンドで操作できる組み込み装置な感じが好きです！

こちらは @tabriSyu39 さん。
気合十分で周辺デバイスの実装が完了しています。
プログラムの実装フェーズに入っていました。

こちらは @todotani さん。
どこかで見た事のある・・・と思った方。
はい。あのブログのお方です。
３階建ての構造ですが、シンプルに纏まっていて良い感じ。
当日取り組んでいらっしゃった成果を「XBee APIモードライブラリのLPCXpressoへの移植」で公開して下さっています。

こちらは @suikan_blackfin さん。
オーディオプラットフォームUzumeの第１版のデバッグの様子です。
プレゼンテーションでもプラットフォームの狙いについて熱く語って頂きました。

こちらは @noztos さん。
おっと～。Androidとの連携か？！

こちらは @hellslonghorn さん。
おっと～。Smart Fusionとの連携か？！

私はというと、すっかり自分の物を撮影するのを忘れてしまいました。
なので家に帰って撮影です。
LPCXpresso ClockをGPS時計にしてみました。
TOPPERS/ASP for LPCを使っています。

色々なサプライズがありましたが、本編より夜の会合の方が盛り上がってしまったのは内緒です。

皆様お忙しい中の御参加ありがとうございました。
非常に有意義な時間を過ごす事ができました。

僕たちのファームウェア戦略 (LPCXpresso Clockを使って、組み込み機器開発特有の問題解決を楽しもう！)

戦略なしではいられない

LPCXpresso Clockは、現状でほぼ全てのLPCXpressoにドッキングする事を考えています。
この時、LPCXpressoの各モデルに対するライブラリを個別に提供しても構わないのですが、管理や設計から見ると美しいとは言えません。

例えば・・・

• 「このウルトラミラクル輝度制御機能は全モデルに搭載されている機能なんだけど、あのモデルでは"ABC"になっていて、このモデルでは"DEF"になっている。」
• 「あぁ、そのモデルは全然保守されていなくて、別のインターフェースになっているんだ。」
• 「え？このモデルでしか動かせないハッピータイマー機能を加えたけどだめだった？」

など、実際の製品開発においては、シリーズとして相応しいインターフェースを提供しているのかなどの検討も欠かせないのです。
「あのモデルのためにABCインターフェースを追加したら、別のモデルで致命的な矛盾が生じた。」なんて笑うに笑えないわけです。

今回の設計に関して言うと、殆どの機能は共通なのですから、アプリケーションロジックは共通にしておきたいところです。そのためには、下層ライブラリを適切なインターフェースで切って、実体を抽象的に扱う事が欠かせません。これは今後触れていくであろう「僕たちのクロスプラットフォーム戦略」にも関連があります。

考えられる様々な要求を簡単に箇条書きにしてみましょう。

• 使いやすいライブラリを提供して欲しい。(ユーザ要求)
• インターフェースの学習コストを最小限にしたい。(ユーザ要求)
• アプリケーションロジックは共通化して、開発コスト対効果を最大限に高めたい。(ユーザ要求)
• 優先度の高いモデルや機能から実装して、要求に応じて他のモデルも開発したい。(開発者要求)
• 「私はCで書きたいんだ。」、「私はC++で書きたいんだ。」(ユーザ要求)
• その他

他にも様々な要求が考えられるわけです。
要求は、顧客から来るもの、設計から来るもの、実装から来るもの、様々です。

いずれにせよ言えるのは重複するような内容が物事に含まれている場合、何かと問題が生じるという事実です。

ここを美しく解決する事が「僕たちのファームウェア戦略」であり、１つの製品設計で複数のラインナップを揃える事のできる土台となるわけです。

設計の土台を作る(分割し、整理し、統治する)

では、具体的にどうすれば良いのかという話になります。
基本的には「分割し、整理し、統治する」という流れです。

分割(あるいは統合)

同じものと違うものを分割します。あるいは同じものを統合します。
分類に迷ったら、基準となる視点を定めて分割するか統合するかを判定します。

例えば、LPCXpresso Clockの場合、分割可能な要素の例には以下の２つがあります。

• LPCXpresso Clock基板固有の機能。 (時計のインターフェースを実現するハードウェア。)
• ドッキングさせるLPCXpresso基板固有の機能。 (時計の制御を実現するハードウェア。)

簡単ですね？
ドッキングして使用するのですが、2つの基板の役割は明確にわかれています。

LPCXpresso Clock基板+LPCXpresso基板=LPCXpresso Clockですから、上記の視点は非常にシンプルなものです。
(一見下らない要素を大げさに取り上げているように見えるかもしれませんが、これが後々の設計と綿密な関わりを持ってきます。)

整理(あるいは破棄)

分割した要素の詳細を整理します。
詳細といっても実装レベルの詳細ではなく、「だいたいこんな感じかなぁ？」程度の整理で構いません。

例えば、LPCXpresso Clockの場合、以下のような感じです。

• LPCXpresso Clock基板
• 7セグメントLED (出力)
• 赤外線受信回路 (入力)
• 照度センサ (入力)
• スイッチ (入力)
• LPCXpresso基板
• GPIO (入出力)
• RTC (入力) - 無いモデルもある。

統治(あるいは留保)

統治の段階でインターフェースを定義してみます。

Cならヘッダファイルにインターフェースを定義します。
C++ならヘッダファイルにクラスを定義します。

この時点で統治できないような内容があっても構いません。
意味不明な物体は、この時点で無理して統治する必要はありません。
少し変な名前を付けて残したりすれば良いです。

これは検討の方向性を確認するためのプロトタイプ実装です。
実際に動作させるところまで持っていく必要はありません。

これが「僕たちのファームウェア戦略」における実用的な出発点です。

そ・れ・で・？

子供騙しのような整理をしてどうなるのか？と感じる方もいるでしょう。
でも、上記の３ステップの整理をするだけで

• システムが何を提供しようとしているのかが明確になる。
• シリーズ並行展開の視野を身につける事ができる。
• 自身の設計が何のプラットフォームに依存しているのかを明確に認識できる。
• その他

様々な効果が得られます。

今回は「僕たちのファームウェア戦略」の出発点を示し、その効果について概略を解説しました。

EAGLEで設計した基板の製造をFusion PCB Serviceに頼む。(EAGLE用の一発生成CAMファイルや、ガーバデータの検証方法もあります。)

概要

LPCXpresso Clockを設計して早くも1週間が経ちました。
その間に色々な試行錯誤を経て若干の機能追加をしたりしました。

今回の基板(LPCXpresso Clock)の製造は、激安基板製造でお馴染みのFusion PCB Serviceに頼むことにしました。

EAGLE用の一発生成CAMファイル

EAGLEでガーバを出力する場合にはCAMプロセッサというものを使います。

まずは基板設計側の画面を表示します。

CAMプロセッサのアイコンをクリックします。

CAMプロセッサのダイアログが表示されます。
ここでCAMプロセッサに対する作業を定義したファイルを読み込みます。

ここでは、Funsion PCB Service向けのCAMプロセッサ用ファイルを自作してガーバ出力作業に使用することにしました。

名付けてFusionPCB-gerb274x-excellon.camです。

それでは読み込んでみます。

Fusion PCB Serviceでは生成したガーバデータの拡張子名が指定されています。

自作したCAMプロセッサ用ファイルには以下の特徴があります。

• Fusion PCB Serviceで指定された拡張子名で自動生成してくれるようにしました。
• CAMプロセッサジョブ名は、Fusion PCB Serviceで指定された名称にしてあります。
• ドリルデータも一緒に生成するようにしました。

「Process」ボタンを押したら出力されたファイルをFusion PCB Serviceに書かれた内容で照合します。

ドリルラックファイルなどは不要なのかもしれませんが、添付しても問題ないでしょう。

出力されたデータを確かめる

この手の作業は、複数のツールを組み合わせたダブルチェックが欠かせません。
出力したデータファイルのみで(←ここ重要)期待した結果が得られるのか？が確認するポイントとなります。

私は工場に提出するガーバデータの確認をGraphiCode社のGC-Prevueで行っています。
早速先ほど出力したデータファイルを開いてみましょう。

「ファイル」メニューから「インポート」を選択します。

GC-Prevueのインポート機能は非常に手軽で、Ctrlキーを押しながら所望のファイルを選択することで複数のファイルを一括読み込みすることができるようになっています。

インポートを実行するとファイル情報の検証が行われます。

その後、ツールの管理テーブルへのマッピングが表示されるようになっています。

最後にファイル毎のインポート結果の詳細が示されるダイアログが出現します。
ここで表示色や形式などを選択する事ができるようになっています。
この時点でお気に入りのツールと表示色をあわせると見やすいですね。

ガーバデータは複数のファイルで1つの基板の情報を管理しますので、「間違って同じデータを違う拡張子で送っちゃった！」とか、「全然関係ないデータを送っちゃったよ！」なんてあるかもしれません。

読み込み時に画面で確認しながら読み込めるGC-Prevueはそういう意味で非常に便利です。
例えば、シルクレイヤを見てみると以下のようになります。

こちらは部品面のガーバ。
ベタ面の描画が粗いように見えますが、拡大すればきちんと表示されます。

レイヤー毎の表示・非表示は画面左側のツリー表示の部分で切り換えることができます。

リソース

EAGLE用のFusion PCB Service向けCAMプロセッサファイルはこちらからダウンロードできます。
自己責任でお使い下さい。

まとめ

今回はEAGLEで設計した基板の製造をFusion PCB Serviceに頼む過程を示してみました。