Arduinoの処理速度

Arduinoって1つのコマンドに1クロックで処理できるようです。
ただ、ライブラリ関数は1つの関数でたくさんのコマンドを実行するので遅くなるようです。

digitalWrite(10, HIGH)　　…Arduinoの出力
→ 44 CPUクロックサイクル
PORTD = i; …AVRのレジスタ直接操作による出力
→ 3 CPUクロックサイクル
だそうです。
こうなるとレジスタにアクセスするほうが格段に速いですね。

数学関数とかとにかく関数が充実しているので、Arduinoはすごいと思います。

STM32マイコン徹底入門が発売されますが、どんどん本・マイコンが増えていきますね。すばらしい!!

僕はSTM32を使おうかArduinoのどちらを使おうかと迷ってますが、そんなに処理速度を求めないと思うので、Arduinoかなとも思っています。なにしろArduinoは三角関数から液晶まで関数化されていてだいぶ楽ですから。

プレゼンテーションについて少しネットサーフィンしてたら、
http://www.youtube.com/watch?v=L0XeQhSnkHg&feature=player_embedded
こんな動画がありました。
さすがアップル社です!細かい性能を言うとかじゃなくて、人を引きこんでいくこのプレゼンテーションはすごいと思いました。
観客を笑わせるとかは僕には不可能ですが、もう少し分かりやすい発表とかできたらなと思います。

明日から12月ですね。もう今年が終わりそうな気がします。
時間がたつのは早いものです。

LPFやってみたが・・

PSoCマイコンのLPFブロックを使ってみたのですが全くうまくいかず・・
LPFブロックに与えるクロックを全く何も考えずにやったからだと思います。
うまくいかないのも当然です・・・
クロック周波数をきちんと考えて設定しようと思います。

簡単なミスほど見つかりにくく時間がかかる！？

PSoCでのADCのデーターをI2C通信でArduinoに送って液晶に表示させようとしたら、80035とか　　　-2405とか出たのであります(アラビックリ!!)。
なぜかを簡潔にいうと
バグその①PSoCのADCのデーターは12ビットの場合「-2048 ～ +2047」で表される。だからそのまま使うとマイナスが出るのは当たり前。
このバグはまだ納得できるのですが・・・
バグその②液晶でいちいちクリアしなきゃならなかった。いちいちクリアしないと、例えば"12345"と表示した後"800"と表示しようとすると、重なって"80045"と表示される。
そりゃ～変な値がでるはずです！
これを見つけるのに4時間くらいかかりました。ADCからは正しいデータが出ているかとか1つずつ原因をつぶしていっても奇妙なことが起こるので、う～～んとうなり、PSoCとArduinoにそれぞれ液晶につなげてどういう風にデーターが曲げられているかを眺めたら、あぁぁ～～なるほど！！となりました。
もう爆笑しました！何時間もバグを探し続けてこれですから！
同時に後悔と自分を責めるという気持ちとでもいいますか・・とにかくひどい！

でも、今日中に見つかってよかったかな？とポジティブになりつつ(?)、これを書いている次第でございます。
I2Cのエラーは今のところ出ていないです・・(たぶん)

明日もボチボチ頑張ります！

(あとちなみに、前の記事のI2C日本語仕様書はやはり誤植で原文が正しいようです)

I2Cの仕様書の日本語バージョン????

英語のI2C仕様書の図を見てください↓(クリックすると拡大します)

 
出典：http://www.nxp.com/acrobat_download2/literature/9398/39340011.pdf
　　　　の14ページ目

次に日本語バージョンを見てください↓(クリックすると拡大します)

出典：http://www.nxp.com/documents/other/39340011_jp.pdf
　　　　の同じく14ページ目

日本語バージョンなのですが斜線部分にすべきところがなっていない気がするのですが・・・
いきなりスレーブがマスタにしゃべりかけるなんてOKでしたっけ？
(実は前の記事で同じ図を出していて自分はその時はスルーしてたんですが・・よく考えると・・・)

微妙に不安なのでどなたかコメントお願いします。

ArduinoとPSoCのI2C通信(複数バイト)

2バイトでのArduinoとPSoCのI2C通信をしてみました。

PSoCではI2CHWブロックを使い、Arduinoがマスタ、PSoCがスレーブというように設定しました。

ここで注意すべきことがありまして、

たとえばPSoC側を
  dat = 1234;             //16進数で4D2になります
  buf_tx[0] = dat >> 8; //この場合0x04になります
  buf_tx[1] = dat;        //この場合0xD2になります
(buf_tx[n]とは送信するためのバッファ変数です。またdatはintでbuf_txはBYTEです。)
(PSoCマイコンではバッファ変数に送りたいものをあらかじめ入れておいて、マスタから送信しなさいと言われたら何も考えずにバッファ変数の内容を答えます。だから、マスタからいつ「送信しなさい！」といわれても良いようにあらかじめ言うことを準備しておきます。これらは、その準備のコードです。)

というコードにして、Arduino側で
  Wire.requestFrom(18,2);//１バイト要求することを宣言
  rd_data[1] = Wire.receive();//受信してrd_data[1]に代入
  rd_data[0] = Wire.receive();//受信してrd_data[0]に代入
という風に受信すると、
rd_data[1]には0x04が入り、rd_data[0]には0xD2が入ります。

つまり、PSoCでは「変数名[0]」にMSBを入れて、「変数名[n]」にLSBを入れなければいけないと考えられます。

普通上位バイトから受信して、後で下位バイトを受信すると思い込んでいるのですが、ArduinoのWire関数は少々ブラックボックス化されているので、確実ではありません。
ただ、PSoCのバッファ変数の[0]は、Arduinoでは最初に受信されるのは確かです。

配列の[n]のnが少ないほうが下位バイトで後から送信するのだと思っていた僕は混乱しました。

ともかく、Wire.receive();で最初に返されたデーター(つまり最初に何らかの変数に代入したデーター)は、I2Cで実際に最初に受信したデーターであるということがはっきりすればこれらが確実になるということでございます。

分かりにくい文章ですみませんが、Wire.receive();で最初に返されたデーターが、I2Cで実際に最初に受信したデーターであるかどうか分かる方は御教授ください。お願いします。

さて、ちなみに僕がなぜこんなにPSoCマイコンとArduinoとのI2C通信をやっているかというと、
IRセンサー　―　PSoC ========== Arduino (===はI2Cでつなぐと思ってください)
という感じでつないで、
利点①Arduinoの少ないアナログ入力を節約でき、1つのArduinoでたくさんのIRセンサーと2本の線だけでつなぐことができる
利点②アナログでないので、(PSoCとArduinoの間の線が長くても)モーターからの外部ノイズの影響を受けにくい(たぶん・・)
利点③外付け部品がほとんどいらない
と考えているからです。
といいながら想像だけでIRセンサー部分がまったくできていないのですが・・・
早くI2C通信を終えてLPF(ローパスフィルタ)に移りたいと思います。

I2C通信について

I2C通信をしたくて調べて、いろいろ少しづつ分かってきたのですが、まだわからないところがあります。
だれか教えてください。お願いします。

まず、Arduinoでのことなのですが、Wireライブラリを使ってマスタの場合です。
Wire.recuestFrom(address,quantity);関数のことなのですが、
ここでいう要求するってどういうことでしょうか？

というのは、マスタはまず最初にスレーブのアドレス(7bit)を送信して、R/Wを送信しますよね。
R/Wのところを１にしてやると、ACKの後にスレーブからデータが来ますよね。
そのあとに何バイト受信したらACKを出さないで停止条件を出すんですよね。
要求するとはこのことなのですか？
パラメータのquantitiyつまり要求するデータのバイト数っていうのは、（マスタが）ACKを出さないようにするまでのバイト数を示すのですか？
つまり、「何バイト欲しい」っていうのをスレーブに伝えるのではなく、何バイトか受信したら強制的に終了するためのバイト数なのですか？

下はI2Cの仕様書です↓(クリックすると拡大します）

もう１つ疑問があります。
PSoCでのI2CHWのAPI関数についてなのですが、（スレーブに設定した場合）

①マスターからスレーブ（ここでいうPSoC)への書き込み
PSoCにとっては読み込みなのに関数がWriteって書いてあるそうなのです（ややこしい）。
PSoCがマスタからの信号を自動的に読み取って、I2CHW_1_bReadI2CStatus();がI2CHW_WR_COMPLETEに変化する
→I2CHW_1_ClrWrStatus();する
→I2CHW_1_InitWrite(バッファ名,バッファサイズ);で「バッファ名」にマスタから受け取った信号が入る
→「バッファ名」を読み取ったらOK！
　という流れで合っていますか？

②スレーブ（ここでいうPSoC)からマスタへの読み込み
PSoCにとっては書き込みなのに関数がreadって書いてあるそうなのです。
例えばbuf_rdという変数をつくる
→I2CHW_1_InitRamRead(buf_rd, バッファサイズ);でRAMに移しておく
→マスタから送信を要求されたら自動的にRAMに入っているのを送信する
→I2CHW_1_bReadI2CStatus();がI2CHW_RD_COMPLETEになる
という流れで合っていますか？

どなたか知っている方、コメントしていただけたら幸いです。

オフライン環境でのmbed

mbedとLPCXpresso(LPC1768)はマイコンが同じなので開発環境も同じと思っていたら、全然違いました。
mbedのクラウド上でコンパイルできる関数はmbed専用で、LPCXpressoでは使えません。
mbedの関数のありがたさを感じました。かなり簡単になっています。
ぼくはLPCXpressoではプログラムできません(難しい)。

さて、オフラインでmbedのコンパイルに成功した方がいらっしゃってこれで使える！と思いました。
実際にやってみたら成功しました。

ですがコンパイルが90秒以上かかりました。
mbedのクラウド上でもそのくらいはかかるのでしょうか？(mbedを買っていないので分かりません)
ぼくは書き込みが速いことを知ったからmbedをベースにロボットを作ろうと思っていました。
なぜなら、試合当日のときの調整に試行錯誤を何回もするので、書き込みの時間というのは惜しいからです。
試合当日でないときはゆっくり開発するのですが・・
書き込みの時間はオフラインでも同じく速いんでしょうが、コンパイルで90秒取られると試合当日の調整が少し厳しくなりそうです。

というわけでmbedはオンラインが前提なので、ロボカップサッカー用ロボットのベースには厳しい気がしてきました。(携帯を使うデータ通信(つまり試合会場でインターネットを使う)はお金がかかる)

Arduinoも関数で簡単に使えるようになっているので、mbedはあきらめて、結局Arduinoでやってみようと思います。
ArduinoのI2Cはスレーブアドレスが7bitということが気になりますが・・・
でもArduinoでロボットを作れそうなので。

さてさて話は変わりまして超音波センサーの周波数干渉防止についてですがPSoCというマイコンは中にアナログ回路を作ることができるそうで(ぽよこまだんな様Reverse父様ありがとうございます)、こちらもやってみようと思います(定期テスト後)。
うまくできれば25kHzと32.8kHzの超音波センサーを作れそうな気がします(想像)。

火曜から2学期中間定期テスト1週間前に突入するのでしばらくお休みします。

にほんブログ村

新しい32bitマイコン

今日ダイセン電子工業に行ったら、新しいmbedという32bitマイコンの紹介をしていらっしゃいました。
mbedは開発環境がインターネット上にありコンパイルもインターネット上で行います。
マイコンとはUSBケーブルでつなぎ、マイコンはUSBメモリとして認識されます。
マイコンへのダウンロードは、USBメモリと認識されているのでコンパイルされたファイルをコピーするだけ。
書き込み機なんていらないのです。

開発環境をパソコンにインストールできるもの(ＬＰＣ１７６８)もあります。

PIC,H8と並ぶ低価格さで、かなり高性能ですごい時代になってきたと感じます。
ただ、解説書やデーターシートなどは英語になります。

新しくダイセンで発売された方位センサーについて、
I2C通信はできそうなのですが、どうやら0～359度の方位のデーターは自動的に、加速度センサー(3軸)と3軸の方位センサーのデーターから計算されていて詳しくは分からないようです。
また、モーターの磁気の影響は受けにくいようですが受けないことはないようです。
しかし、1度刻みで分かる方位センサーが発売されてかなり有難いです。

ロボットが自分の位置を知るためのセンサーとモーターをどうしようか困ってます。
位置情報を得るためには
①超音波センサーと方位センサーを使う
②画像解析を行う
の２つしかありません。それ以外にあれば教えてください!
ところが超音波センサーは干渉します。
また、方位センサーは大きいモーターを使えば誤動作します。

今タミヤの380ギヤードモーターのモーター部分だけを取り出しギヤ部分を自作して直径22ｃｍ以内に収めようと考えています。しかし、もし方位センサーが使えないほど磁気を出していれば(未確認です)、方位センサーは使えません。
すると画像解析をするかモーターを変えなければ行けません。
マクソンモーターは高すぎて手が出せません。
ダイセンはたくさん使っていると焼ききれてしまいます。

やはり画像解析するしかないのでしょうか。
高性能のマイコンもしくはパソコンが要ります。
予選は2月です。4ヶ月しかありません。

と・・いうわけで・・・やらないと始まらないのでとりあえずいろいろやってみます。

にほんブログ村

H8を出してきた

H8Tinyで液晶を表示させるために配線作業中であります。
ちなみにH8の3694(秋月)を使っております。

前の記事のピーってなる装置はH8でやってみてたんです。
意外とADC(アナログ-デジタル コンバータ)は正確!
1/3オームをeneloopに直接つないで1.000Vまで放電させます。
その放電するまでの時間を電池ごとに比較!
だが・・・1本の電池でやってみたら時間が1回目と2回目で違う!なぜ？

以下　メモ(あまり気にしないでください)
電池番号　 hours:minutes
No.5 ( : ) 13:58 32:53
No.18 ( : ) 33:30
No.20 ( : ) 32:25
No.22 ( : ) 13:35 08:30
No.15 (29:13) 31:40
No.9 (10:25) 08:25
No.34 (05:45) 08:30

うーん。
もう少しほかの番号の電池も調べて適当に6本組み合わせて超急速充電器で充電してみよっかな

話は変わりまして、いつもは23Wの半田ごてを使っておるのですが、消耗してきたみたいでうまく半田付けができない・・・(こて先を交換すれば復活する!と思う)(過去に復活した!)
というわけで30Wの半田ごてを出してきて半田付けしてみたら・・・
ビックリするくらい楽にできました!
30Wだと鉛フリーでも楽にできますね!

あと、液晶をH8で表示するため配線作業中なのでありますが、最近コネクタで基盤と基盤をつなぐと線がちぎれないということに気づきXHハウジングを愛用しています。

なぜ液晶を使おうとしているかというと早くパルスボール用の(階段状になってるのを使って距離をだいたい出す)プログラムを作りたいから!
38kHzの赤外線受光素子を使う予定です!