CuBeatSystems

PS/2 mini-DINコネクタのピン配置について気になることがあったので調べてみました。

Spartan-3 Starter Kit Board User Guide - UG130 (v1.0.1) June 7, 2004によると以下のようなピン配置です。

これに従い配線した様子が以下の写真です。
上記の資料に合わせるならば、黄色がデータ、緑がクロックということになりそうです。


オシロスコープで波形を確認してみます。


接続を整理すると

• Ch.1 (YELLOW) : PS/2 DATA (The document said.)
• Ch.2 (CYAN) : PS/2 CLOCK (The document said.)

となります。

実際にキーを押して波形を観察してみると・・・。


え？

先ほどの資料と接続状態から得られる期待値、それに実際に観測した結果を整理します。

• Ch.1 (YELLOW) : PS/2 DATA (The document said.) -> It's a clock!
• Ch.2 (CYAN) : PS/2 CLOCK (The document said.) -> It's a data!

なんだかクロックとデータが逆ですね。
気になってXilinxが提供しているボードの資料を調べてみました。
まずはSpartan-3E FPGA Starter Kit Board User Guide - UG230 (v1.1) June 20, 2008から。


次にSpartan-3A/3AN FPGA Starter Kit Board User Guide - UG334 (v1.1) June 19, 2008です。


全部違います。
そして、XLVDSPro Demonstration Boards - UG037 (v1.4) June 03, 2004は・・・。
あってるんですね～、これが。


一度作った資料がどんどん使いまわされた結果、間違いを量産する形になっているのでしょう。
自分の作る資料も気をつけたいところです。

参考までにALTERAから提供されているDE0(Terasic社の物)も確認してみました。



こちらは正解です。
後で忘れるといけないので手元の資料に訂正を書き込みます。


気になった事を調べておくと色々後でハマらずに済みます。
そして、それを共有しておけば皆さんの時間もきっと節約できるはず。

参考までに詳しい資料は

• http://en.wikipedia.org/wiki/PS/2_connector
• http://www.computer-engineering.org/ps2protocol/

などにあります。

なんだか怪しい挙動を繰り返していたmbedライブラリ revision 24 ですが、
先ほど修正版がアップデートされていました。
http://mbed.org/forum/bugs-suggestions/topic/990/


少なくとも私の書いたバグ出しテストプログラムでは現象が再現しませんでした。
http://mbed.org/users/shintamainjp/programs/TestProgramForBugTopic990/latest

まずはひと段落というところでしょうか。
ありがとうJon Wardさん。

先日の活用事例2では赤外線受信機能を設計実装して、赤外線リモコンでmbedを制御するというものでした。

今回の活用事例3では赤外線送信機能を追加し、デモアプリケーションとしてチョロQハイブリッドを制御するプログラムを御紹介します。

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


今回設計した赤外線送受信ライブラリを使えば、受信した信号と同じものを送信することができるようになります。家庭にある赤外線リモコンを片っ端に調べてみると面白いことがわかるかもしれません。


ちなみにチョロQハイブリッドはタカラトミーが作ったものですが、赤外線リモコンのフォーマットはソニーのもの。両者の関係がこんなところにも見えるのは面白いものです。

今回はwiiヌンチャクを使ってチョロQを運転できるようにしました。
mbedを寝かせっぱなしの方がいましたら、是非お試し下さい。

開発環境を起動します。
起動時に「評価目的に限ります」と表示されますが、これは登録することで表示されなくなります。
ここでは気にする必要はありません。
まずはNetduino用のプロジェクトを作成しましょう。
「ファイル」から「新しいプロジェクト」を選択します。
Visual C#のMicro Frameworkを選択し、「Netduino Application」をクリックして次に進みます。
プロジェクトが作成されると画面左下に以下のようなメッセージが表示されます。
プロジェクトにあるProgram.csを開いてみてください。
以下のようなスケルトンが生成されていると思います。
スケルトンの// write your code hereの下に以下のようなコードを挿入します。

// write your code here
OutputPort led = new OutputPort(Pins.ONBOARD_LED, false);
while (true)
{
led.Write(true); // turn on the LED
Thread.Sleep(250); // sleep for 250ms
led.Write(false); // turn off the LED
Thread.Sleep(250); // sleep for 250ms
}

コードを記述したらビルドしてみましょう。
ここで慌てて実行しないように。
以下のようなエミュレータが起動しますが、今回これは使いません。
エミュレータは終了して下さい。
Netduinoにアプリケーションを配置して（Microsoft流に言うとこうなるのか・・・）実行するにはいかの設定を施します。
プロジェクトからアプリケーションのプロパティを選択します。
次に「.NET Micro Framework」を選択し、「Transport:」を「USB」に設定します。
この時点で「Device:」には「Netduino_Netduino」が挿入されていると思います。
これでOKです。
それでは改めてアプリケーションを実行しましょう。
「デバッグ」から「デバッグ開始」を選択します。

NetduinoにあるLEDが点滅を開始したと思います。

「本当にこのプログラムが動いているのかな？」と感じた場合には・・・。
試しにアプリケーションに対してブレークポイントを設定してみましょう。
今回の例では二箇所のled.Write()に対して設定しました。
「デバッグ」から「続行」を選択するとブレークポイントで停止します。
Netduino本体のLEDの状態がブレークポイント停止個所によって変化していることが見えると思います。

このようにNetduinoでは.NET Micro Frameworkを使ってハードウェアを簡単に制御する可能になっています。今回はプログラミング初めの一歩編として簡単な紹介をしました。

ちなみに今回の内容は本家Netduinoページのdownloadsにあるgetting start guideをベースにしています。http://www.netduino.com/downloads/gettingstarted.pdf

最近はフィジカルコンピューティング？の分野が激しい新製品ラッシュです。

• http://www.tinyclr.com/hardware/1/fez-domino/
• http://leaflabs.com/devices/maple/
• http://www.makingthings.com/
• http://mbed.org/
• http://www.netduino.com/

この中で最も新しく知ったNetduinoをスイッチサイエンスさんから購入しました。
事始めということでどうやって始めるのかを書いてみましょう。

表面
裏面

インストールする。
Netduinoのアプリケーションを書くにはフリーのツールを3つインストールすることになります。
以下の順番でインストールします。

1. Microsoft Visual C# Express 2010
• http://www.microsoft.com/express/downloads/
2. Microsoft .NET Micro Framework v4.1 SDK
• http://www.netduino.com/downloads/MicroFrameworkSDK.msi
3. Netduino SDK v4.1
• http://www.netduino.com/downloads/netduinosdk_32bit.exe (for 32-bit Windows)
• http://www.netduino.com/downloads/netduinosdk_64bit.exe (for 64-bit Windows)

以上でアプリケーション構築の準備は完了です。

mbedのページに実用ライブラリシリーズ：赤外線送受信ライブラリを記載しました。
これは赤外線の送受信に対応したライブラリです。
以下のようなAPIで簡単に操作することができるようにしました。
☆ボードオレンジでも使用可能：☆ボードオレンジ：「活用事例2：赤外線リモコンで楽々操作しよう！」

Revision 24のmbedライブラリにおいて、TickerとTimeoutにバグがありそうです。
いずれもattachとdetachの動作に問題がありそうで、他のTickerの動作を壊したりします。

現在ARM社のmbedチームの方とやり取りをしています。
http://mbed.org/forum/bugs-suggestions/topic/990/

当初こちらで作成していた赤外線受信クラスのバグかと思っていました。
腑に落ちない点があり簡単な動作テストプログラムを記述したところmbedライブラリのバグが発覚。

これは皆さんも遭遇しそうなバグなので積極的にバグフィックスのためのサポートをしたいと思います。

サンハヤト株式会社　小型ユニバーサル基板　ICB-293Gの穴位置について調べてみました。

実は、私の手元にあるもの（15年位前に購入）と現在流通しているもので穴位置が異なるのです。
☆ボードの拡張性を示すノートブック、☆ボード「拡張性を見てみましょう！」を記載していたのですが、私が試したものと同じ型名の基板で「使えるはず」との御指摘を頂きました。

私の手元にある293Gと書かれた基板を☆ボードにあてると、確かに穴は外側にずれています。
これを根拠に記事を書いたのですが、何かが違うようです。


http://www.sunhayato.co.jp/products/details.php?u=177&id=07001 にある図面を見ると基板の端から5mmの位置に穴があいていることがわかります。


ノギスで測ってみた所、手元にある293Gと名乗る基板は明らかに穴位置が図面と異なります。
あらら。なんで？


そこで秋葉原へ向かい現在流通しているものを入手して調べてみることにしました。
購入した基板は確かに293Gです。

下の写真の基板は穴位置が合わなかった古い物。
文字の感じをよく見てください。


そして、下の写真は今回購入した物です。
なんだか文字の雰囲気が異なりますね。
穴位置も中央に寄っている事が見てとれます。


ノギスで測ってみると（ずいぶんいい加減に測りますが・・・）図面に近い形になっています。


両者を並べると違いは歴然としています。
左側は昔の物、右側は現在の物。(穴位置が全然違う！)


今回購入した物であれば☆ボードの穴位置にもきっちりあいました。


今回の件を整理すると・・・

• Sunhayato 293Gという基板は世の中に少なくとも2種類ある。
• 穴位置変更の経緯は不明。

といった感じでしょうか。

結果的に間違った情報を提供する事態を招いてしまっただけに、なんだか釈然としない気分です。
できれば型名を変えてほしかったなぁというのが正直な気持ちです。

（2010年08月20日追記）
メーカの方に確認をしたところ「ICB-293シリーズは、姉妹品のICB-93シリーズとの共通化の為、2002年に取り付け穴位置の変更を行いました。」とのことです。確かに姉妹品の中で穴位置が異なってもあまり嬉しくありませんから妥当な対応でしょう。

http://mbed.org/users/shintamainjp/notebook/starboard_example2_ja/に記事を記載しました。

☆ボードはmbedを活用する上で最高に便利な基板ですが、スイッチがありません。
スイッチを取りつける事を考えてみましたが、せっかく☆ボードがコンパクトにまとまっているので、あまり積極的になれません。


どこに付けよう・・・。


そこで、今回はスイッチを取りつける代わりに赤外線受光モジュールを取りつけ、外部からリモートコントロールできるようにしてみました。こうすれば、以下のようなモジュールを1つ付けるだけで沢山のスイッチ入力に対応することが可能になります。


こんな風に・・・。


詳しくはリンク先をご覧ください。

http://mbed.org/users/shintamainjp/notebook/starboard_example1_ja/に記事を記載しました。


簡単に言うとmbedを使って温度センサの値を読み取りTwitterにポストし、それをGoogleChartでグラフ化できる活用事例です。例えば以下のようなグラフを自動的に作成することができます。


手元に☆ボードが届いてからはこういった実験が手間無く非常に素早くできるようになりました。
mbed NXP LPC1768を購入する際には一緒に購入すると良いかもしれません。


今回のケースでは温度センサを二つブレッドボードに搭載しての実験でした。
お手軽な割に綺麗なグラフが出力されて嬉しかったりします。


プロトタイピングツールは意外に放置してしまう傾向にあるのですが、今回は色々活用できています。
他のソリューションと違ってmbedコミュニティの力が関係しているのかもしれません。

mbedには世界中の様々な人達が作った便利なライブラリが集結しています。
ですから簡単に色々な事が試せるのです。

が、「世界中の様々な人達が作っている」がために問題が露呈することもあります。
今回遭遇した問題もその類。

SDFileSystemを使おうとコーディングしてコンパイルに通すと

"Expected an identifier (E40)" in file "/YourProgramName/lib/FATFileSystem/integer.h" (Line: 27, Col: 15)

と怒られてしまいました。

「他に困っている人はいないかな？」とmbedのフォーラムを調べてみると、やっぱりいます。

Forum ≫ mbed ≫ Expected an identifier (E40)

しかも、投稿者は有力な回答が得られないままになっている様子です。
(追記：これは勘違いでした。先ほど文面を再確認したところ「And thank you, it now compiles, I moved up the include for the SDFileSystem in front of everything else.」と自己解決した事が書かれていました。但し、なぜこれで解決できたのかは記されていません。興味のある人は下記解説もご覧下さい。)

mbedのFATFileSystemはChaNさんの実装したPetit FAT File System Moduleを起点にしているようです。
integer.hがhttp://mbed.org/projects/libraries/svn/FATFileSystem/trunk/integer.hにあります。

integer.hの27行目は

typedef enum { FALSE = 0, TRUE } BOOL;

となっています。

ごく稀にライブラリでこの手の実装を見かけますが、これはあまり良い実装とは言えません。
なぜなら、他の誰かが同じような定義を異なる手段で提供している可能性もあるからです。
これは通常、良くてコンパイルエラー、悪くて設計と異なる挙動を生みます。

私の場合、他に幾つかのライブラリを組み合わせていました。
怪しそうなライブラリのソースコードをダウンロードして調べます。


そうするとありました。
EthernetNetIfを使っているのですが、LPC1768/lwip/arch/cc.hに定義があります。

#ifndef TRUE
#define TRUE 1
#endif

#ifndef FALSE
#define FALSE 0
#endif

cc.hが先にプリプロセッサに通ってしまうと、integer.hの方は

typedef enum { 0 = 0, 1 } BOOL; 

となってしまいます。当然これではコンパイル不能です。

ライブラリは私の設計実装ではないので仕方ありません。
インクルード順序を変更してみます。

#include "EthernetNetIf.h"
#include "SDFileSystem.h"

を

#include "SDFileSystem.h"
#include "EthernetNetIf.h"

に変更しました。
今回の場合、これによってコンパイルエラーを回避できます。



Davidさんの場合、SDFileSystem.hをなぜか2回（11行目でも）インクルードしています。
最初の記述ではこの位置でインクルードしていたのでしょう。
彼の自己レスにもあるように、最初の方にインクルードを移動することでコンパイルが通ります。

#include "mbed.h"
#include "SDFileSystem.h"
#include "HTTPServer.h"
#include "HTTPRPC.h"
#include "HTTPFS.h"
#include "HTTPStaticPage.h"

といった感じですね。

ライブラリの実装は他の人も参加することを前提に設計しなくてはと改めて考えさせられる出来事でした。