arduinoとrtcの接続…判明！

arduinoにI2C(TWI）で秋月のrtcを繋いでみようという
お話の続きです。

以前実験してみて上手く動かなかった原因が判りました。
スレーブアドレスの指定がおかしかったというのが
原因でした。

Ｉ２Ｃのスレーブアドレスの最下位ビットはＲ／Ｗビット
といって、対象のスレーブに対して読み出しリクエスト
なのか書き込みリクエストなのかを指定するビット
なのですが、これが最下位にあるため、言語によっては
あらかじめ1ビット空けておいたり、空けずに詰めて
おいたり…といった方言みたいのがあって、今回
そこにハマッたようです。

ちなみにarduinoの場合は詰めておく派です。
（アセンブラは詰めない派です）

tokoyaさんのスケッチ
http://tokoya.justblog.jp/blog/2008/11/arduinortc-6cdd.html
を眺めていて、アドレス指定の0xa2を1ビットシフト
しているのに気付いて、間違えを発見しました。

いやぁ。思い込みはいけませんね。

で、直したらあっさり動きました…
それにしてもこれまでの苦労は…（TへT）


というわけで、話し変わってネコロジー。ロジスコではなく
ロジアナと名づけたからにはシリアルモニター機能くらいは
つけてしまいたいと思います。

そうすれば、今回みたいなアドレスの不備などは
画面上で見て判るはずなので。
（いつになるかは判りませんが…）

あとで、rtcの接続についてもarduinoのページに
纏めておきたいと思います。

色々買い物

秋月の八潮店、特価セールだそうで…
http://akizukidenshi.com/yashio/

色々お買い物。



コンポーネント－Ｄ端子ケーブルが何と100円！
安すぎです。というわけで、必要だったわけじゃない
のに1本購入。あとは圧電スピーカーが5個入り40円。
これも安すぎ。で、せっかくなので3袋購入。




あいとさんに教えてもらった秋月の300円カラー液晶。
まだ残っていたので早速買ってきました。
あとは消耗品のピンソケット（両オス）、14.318Mhzの
オシレータ。

そして秋月といえばこれ。

レンズ。

…レンズ？？？

なぜにレンズ…？？？


意外な掘り出し物です。

まぁ以前から色々な口径、焦点距離のレンズが欲しかった
んですが、丁度秋月にいっぱい並んでいたので
買ってきました。凸レンズだけじゃなく、凹レンズも
何種類かありました。

100円ショップの怪しげなプラスティックレンズよりは
精度が高いようで、フニャフニャのひずみは有りません。
細かいキズとかは有りますけどね。
まぁ1個数十円と考えれば全然許せるレベル。
（一番大きいのが80円、一番小さいのが20円です）

これとＬＥＤとか組み合わせて、文字を壁や天井に
映し出すようなプロジェクター的なものを作りたいなぁ
という計画に少し前進。

試しに、携帯電話の画面を壁に映し出してみたら、
そこそこ読めました。夜中に天井に時刻を表示する
ような代物は簡単に作れそうです。


というわけで、ただでさえ安い秋月ですが、ここに挙げた
もの以外にも破格値の掘り出し物がたくさんでした。

今日はいつもよりもお客さんが多かった気がするな…。

arduinoとrtc

以前、arduinoと秋月のrtcを繋いでみようというスケッチ
を書いてみたんですが、ＰＩＣとＣＣＳ－Ｃの時の様には
うまく動かなくて、放置してありました。
http://brown.ap.teacup.com/nekosan0/227.html

確か、rtcの内部レジスタに時刻や日付を書き込むところ
までは上手く動いたんだけど、rtcの内部レジスタを
読み出すところでackの有無が上手く行かなくて
コケたと記憶していたんですが…


今日tokoyaさんのサイトを覗いたところ、duemilanoveに
rtc繋いで動かしたスケッチが公開されてました。
http://tokoya.justblog.jp/blog/2008/11/arduinortc-6cdd.html

これ。すんなり動いたそうです。（ＴへＴ）そうですか…


ひとまず以前自分で書いたスケッチと見比べてみます…
うん。大枠では1箇所違っているなぁ。

さきほど問題に挙げた「読み出し処理」のところ。rtcに
読み出す先頭レジスタの番号を送った後、一端
　　Wire.endTransmission();
で切っておいて、それから
　　Wire.requestFrom(～);
で読み出してるんですねぇ。私のスケッチでは
Wire.endTransmission();で切らずに読み出そうと
しているなぁ。ここか？？？

以前実験してたときにも色々手変え品変え試して
見たはずなんだけど、これはやってないのかな？
やったと思うんだけどな…。

早速配線して、この1行を追加して、コンパイル～
アップロード。

…やっぱり状況変わらず。


なんだろうねぇ？やっぱりわからん。
ここ以外で違うところって、基本的には無いんだけどなぁ。
強いて言えば、tokoyaさんのスケッチを眺めると
rtc内の全部のレジスタ弄っているわけじゃなくて、
２～８の７個だけみたい。

私のは０～１５の１６個（つまり全レジスタ）を読み書き
するような内容なんだけど、これが悪さしてるのかな？
　　「読み出せないレジスタがある？？？」
ってこと？考え難いなぁ…。


まぁ、あとでもういっぺんrtcのデータシートを
読み返してみよう…


ちなみに、tokoyaさんのスケッチを私の環境（reduino-nano）
でも実行してみたところ、すんなりと動きました。
すばらしい。

少なくとも、私の手元のrtcが壊れているってことは
無いわけですね。スケッチの内容に問題がある…と。

まだ発売されないんでしょうかねぇ？

いつ売り出されるんだろうって、ずーっと待ってるのが
http://www.switch-science.com/trac/wiki/W5100-SPI
スイッチサイエンスオリジナルのethernet sheildコンパチ
ボード。

arduinoのethernetライブラリがそのまま使えるって
書いてあるのが魅力。（W5100使ってるからね…）

なにより小さいし、いつも使っているのが
マイクロファンのreduino-nanoなので、ブレッドボード
のサイズに相性が良さそうな、スイッチサイエンスの
このボード、いいんだよなぁ…。

0.5mmの表面実装は頑張ってやっつけるとしても、
あまりに小さいチップ抵抗とかは…自分では
やりたくないなぁ。

表面実装部品がハンダ付け済みになっているか、
もしくはＩＣ以外は表面実装使わない方向だと
嬉しいんだけどな…

いずれにしても、早く出てこないかな…

マイクロステップの励磁パターンと振動

ＭＷさんから教えていただいた情報を元に、先日の
http://nekosan0.bake-neko.net/connection_stepper.html
このマイクロステップの励磁パターンについてもう少し
考えてみました。

上記ページでは、台形の励磁波形を使うことでそこそこの
トルクと、振動や回転速度の緩急を取り除くことを
目指したのですが、若干の不満も残ったままでした。

「磁気は距離の2乗に反比例する」

ということらしいので、仮にＸ極、Ｙ極に磁力を
按分したとしても、磁極からの距離がその磁力の
按分した値に従った場所には位置付けられない
だろうというのがその懸念点。


（補記：図が変だったので差し替えました）
たとえばこの図で、Ｘに３割Ｙに７割の磁力が掛かって
いると仮定します。磁力を按分した位置は赤い矢印の
あたりになるんですが、ＸよりもＹの方が近いので、
より近いＹから大きく影響を受けるはずだろう、と。

その結果、実際の位置は水色の矢印の位置付近に
なったりするんじゃないかな…と思うわけです。


その結果、マイクロステップを使ったからといって、
ステップとステップの間はリニアリティーが
若干劣るということになります。
　→位置決めが不正確になったり、振動が出たり…

で、教えていただいたこのｐｄｆ
http://www.topic.ad.jp/sice/papers/217/217-9.pdf#search=%27%E3%82%B9%E3%83%86%E3%83%83%E3%83%94%E3%83%B3%E3%82%B0%E3%83%A2%E3%83%BC%E3%82%BF%E3%81%AE%E9%AB%98%E3%83%88%E3%83%AB%E3%82%AF%E9%AB%98%E7%B2%BE%E5%BA%A6%E5%BD%A2%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B9%E3%83%86%E3%83%83%E3%83%97%E9%A7%86%E5%8B%95%27

このｐｄｆ中のｆｉｇ４がまさにそのことを指して
いるんだと思いますが…　（ほんとかな？）

で、先ほどの「２乗に反比例する」という件を元に
考えると、それを打ち消すための波形というのが
必要になると思います。

きっとこんな感じ。



問題は、どうやってこの曲線部分を作り出すか…
という話でしょうかね。

距離と角度はモーターによって特性が異なってくる
だろうから、個別のモーター毎に補正波形を
作り出さないといけないだろうし、もっと言うと
回転速度が速くなると、入力波形と回転軸の位相に
ズレが出てくるので、それに合わせて補正値も
変えていく必要があるでしょう…。厳密に言うと。

なので、究極的に誤差を小さくするためには、
モーター別に、そして速度毎に補正値の計算式、
もしくは補正用マトリックスを求める必要が
あるのかなぁと思います。
（もっと言うと、軸に掛ける負荷によっても
　補正が必要になるかな…）

そんなところまで行うと、かなりいい成績が
得られるんだと思いますが、まぁ、必要に応じて
適材適所の補正方法を組み込めばよろしいかと。

あまりやりすぎると、時間を浪費するだけで
オーバースペックになっちゃうので…