2009年12月

イメージ 1

Ｖｏｌ．１に引き続き、００８０、００８３、ＺのＭＳを収録している。
００８０はともかく、少しずつビックリドッキリメカに近づいていくのがわかる。
メカとしては、やっぱり一年戦争もののほうが興味深い。
とはいえ、Ｖのバイク戦艦みたいにぶっ飛んだものはそれはそれですごいと思うが・・・
ということで、Ｖｏｌ．３が出ているはずなので探しに行こう。
タグ ：
#アニメーション

イメージ 1

結構前に出たものだが、先日オクでＧＥＴした。

高さ１０センチに満たないが１個７００円もするだけあって、ＧＦＦテイストのイカしたフィギュアだ。
フルアーマーが２色、ブラッディマリーが２色とシークレット、キャリアースーツが２色、ドクロザクが１～３号機。
１０種類１２個入りで、ダブりは２個ということになる（フルアーマーとキャリアースーツ）。

とりあえず４箱だけ開けてみたら、よりによって妖怪大戦争になってしまった・・・
タグ ：
#アニメーション

イメージ 1

このまえ、玉砕したI2Cである。
アイ・スクエア・シーと呼ぶのが正解らしい。
クロックとデータの２線式の通信方式だ。

PICDEM2PLUS の温度センサーと EEPROM がこの方式で接続されている。
PIC のポートは RC3/4 になる。
microBasic ではハードウエア機能の場合ポート指定はないようだ。
ということは、RC3/SCK/SCL と RC4/SDA/SDI の組み合わせになるわけだな。

この前と違うのは、I2C の通信仕様について一晩各サイトを読んで回ったのだ。
まず、アドレスの概念がわかった。
この温度センサ、マニュアルには「1001101」番地だよと書いてある。
実はこれだけじゃだめで、末尾に書き込みなら「0」、読み込みなら「1」を付加しなきゃいけない。
上位７ビットが実アドレスで、最下位ビットがリード・ライトの指定だったわけだ。
道理でサンプルプログラムが変な指定をしていると思った。

通信仕様は相変わらずよくわからない。
なんかデータがきたみたいなのだが、文字化けしている。
いろいろ試しているうちに、データを文字列に返還後に格納する文字配列が５桁以上だと正常になることがわかった。
データシートを読もうと思い立ったが、メーカーのサイトからダウンロードできない。
少々腑に落ちないところもあるが、写真のように冷やすとそれなりに表示温度が下がる。
逆に、指で体温を伝えると表示があがるので動いているようだ。
表示桁数は小数点以下はないみたいだ。

RS-232C に次いで、I2C も動かすことができた。
こういった実験には、メーカー製のデモボードが確実だ。
付属のサンプルプログラムが動くのであれば、回路は絶対的に正しいのが証明されている。
だめなのは自分とわかっているので、安心してプログラムを疑える。
自作回路ではこうはいかない。
つまらない配線ミスはあるし、イモハンダやショートだってあり得る（いや、よくある）。
オークションで買っておいてよかったな～と思う、今日この頃であった。


・・・書き込みの後、思いついた。
「文字配列が５桁以上」というのは、microBasic の変換ライブラリのせいだった。
もともと BYTE 型を MORD 型として扱っていたからだった。
５桁必要な訳だ（BYTE なら３桁）。

TC74 のデータシートも何とか手に入れて、今読んでるとこ。
タグ ：
#工学

イメージ 1

今日は仕事納め、半ドンだったので午後は自主研究タイム。

ソフトウエアによるシリアル通信を試してみる。
先日の加速度センサ基板に、ボリュームを２個と温度センサを追加した。
アナログはＡＮＯ～５の、計６ポート仕様となる。
とりあえず全ポート問題なく動くことを確認。

これだけ増えると、表示が１６文字２行ではちょっと切ない。
どうせならと、ＭＡＸの２３２ＣＩＦチップを載せてみた。
しかし、８７７ＡのＲＣ６／７ポートは配線済み。
変更してもかまわないが、この際ソフトでＵＡＲＴライブラリを試すことにした。
とりあえず、余っているＥポートの１と２に配線しておく（０はＡＮ５）。

クロック設定やらボーレートやら、つまらないミスを修正して通信に成功！
「Ａ」とＰＣから入力すると、ＰＣに「Ａ」返信すると同時にＬＣＤに「Ａ」と表示。
ここまでできると、ＰＩＣはＰＣの支配下になったということだ。

ただし、残念なことが一つ。
ｍｉｃｒｏＢａｓｉｃのソフトＵＡＲＴライブラリでは、送信が１文字単位しかできない。
ハードウエア利用のＵＳＡＲＴライブラリでは文字列で送れるのが違う。
もちろん自分でルーチンを書いて、文字列の先頭から１文字ずつ送信すればいいだけなのだが。
面倒くさいので、配線を直すことにしよう。
タグ ：
#工学

イメージ 1

ＰＩＣとＰＣ間の通信である。
これで、推移するデータのロギングができる。

できるのは当たり前なのだ、いくらでもサンプル回路がありプログラムがある。
そっくりそのまま作って、ＨＥＸファイルを書き込めば動くのが当たり前なのだ。

そうじゃなくて、自分の作った回路で、得意のｍｉｋｒｏｂａｓｉｃで動かせてこそなのだ。
この言語、詳細の仕様がよくわからないのだ。
パリティがどーたらとかマニュアルには書いてない「よーに」見えるのだ。
もちろんトライアルバージョンのせいかもしれない。
それでも動いてくれないと困っちゃうのだ。

自作というのはリスクの固まりだ。
ソフトが完全に動く可能性が保証されているわけではない。
用意したケーブルも、ストレートでいいのかクロスなのか判断に困る。
プログラムだって初めて作るわけで、全然動かないのかもしれない。
ソフト・ハードともに完璧でも、通信設定が悪ければだめだ。
この組み合わせでデバッグするのは、正直言って大変だった。

まず、通信ソフトで躓いた。
そもそもちゃんとつながっているということが、どうやったらわかるのだろう？
さっそくｍｉｋｒｏｂａｓｉｃの内蔵ツールでやってみたら、接続したよとメッセージが帰ってきた。
［Ａ］という文字を送ったら、同じ文字が帰ってくるというプログラムに反応。
それではと文字列を送ってみたら、適当な位置で分断されてしまう。
Ｗｉｎ標準のハイパーターミナルでも同じだ。
昔使ったＴＥＲＡＴＡＲＭをググったが、バージョンが古くてＣＯＭ４までしか選択できない。
うちのＰＣにはシリアルポートがないので、ＵＳＢ変換ケーブルなのだがＣＯＭ７なのだ。
しばし検索していたら、新バージョンがあることがわかった。
なんで頭の方に出てこないのだ？

それでも、いったん接続が確認できたら、あとは一気呵成だ。
ボリュームの電圧変化を逐次変換して送信することにした。
送信文字列のフォーマットを整え、通信ソフトのロギング機能で記録。
エクセルに取り込んでグラフ化までできるようになった。
これはいい、開発効率が超アップするぜ。

調子に乗ってＩ２Ｃ通信にもトライしたが、こちらは玉砕。
シリアルＥＥＰＲＯＭは読み書きできている「よう」だが、温度センサーの読み取りができていない。
なぜに？？？
まあ、倒しがいのある敵の方がワクワクするのが世の常。
倒すまで誰も殺すんじゃねーぞ・・・と、オラも言ってみる。
タグ ：
#工学

↑このページのトップヘ